1. European Electronic Signature Standardization
Hans Nilsson, iD2 Technologies, S
Patrick van Eecke, ICRI, University of Leuven, B
Nick Pope, Security & Standards, UK
Denis Pinkas, Bull, F
For more information:

2. EESSI: European Electronic Signature Standardization
Industry Initiative led by ICT Standards Board (CEN, ETSI, ...)
Based on a mandate from European Commission
Support the requirements of the EU Directive AND
The requirements for standards from users and industry
First phase: Inventory and work programme
Supported by an expert team, reported on July 1
Next phase: Implementation of work programme

3. Agenda for today
The EU Directive and its implications for standardization
A standardization framework for electronic signature
Standards for CSPs
Standards for signature creation and verification products
Interoperability standards
Proposed work programme and how to participate

4. The EU Directive and its implications for Standardization
Presented by
Patrick Van Eecke, ICRI
K.U.Leuven
This presentation is not a formal interpretation of the Directive on Electronic Signatures and thus does not represent the position of the European Commission

5. Status of the directive
13 May 1998: Proposal of draft directive by the Commission
23 October 1998: Publication of draft directive in O.J.
13 January 1999: European Parliament opinion in First Reading
22 April 1999: Political agreement on the Common Position by Telecommunications Council
24 June 1999: Common position of the Council
Autumn 1999: Second reading by the Parliament and Council
End 1999: Final adoption
Implementation: within 18 months after adoption (2001)

6. Definitions Electronic signature Certification service provider (CSP)
Advanced electronic signature
Signature creation/verification data
Signature creation/verification device
Qualified certificate
“Qualified Signature”

7. Scope of the Directive

8. CSP issuing qualified certificates
Internal market
1. Authorisation (obligatory)
2. Accreditation (voluntary)
forbidden
allowed
3. Supervision
CSP issuing qualified certificates
to the public
Obligation for Member States to control via supervision
E.g. self-declaration scheme with subsequent control by governmental body or private institution

9. Legal Recognition Electronic signatures
General principle (art. 5.2): Legal effect for all electronic signatures
Second principle (art.5.1): certain electronic signatures get the same legal effect as hand-written signature
Electronic signatures
Advanced electronic signatures
Qualified signature:
advanced electronic signature
+ qualified certificate
+ secure signature creation device
Qualified signatures

10. The Annexes Requirements Recommendations
Annex I: Qualified certificate
Annex II: Certification Service Providers issuing qualified certificates
Annex III: Secure Signature Creation Device
Recommendations
Annex IV: Signature Verification

11. Liability
Only for CSP fulfilling Annex II and issuing/guaranteeing qualified certificates to the public
Liability causes
Incorrect contents of the certificate
Person identified in certificate does not hold corresponding signature creation data
Incorrect matching of signature creation and verification data (if CSP provides these data)
Malfunctioning of the CRL
Exemptions
CSP can prove he has not acted negligently
Certificate is used contrary to the limits on the use of the certificate

12. International aspects
Foreign certificates = Qualified certificates
if:
Foreign CA fulfils same requirements + accreditation by Member State or
A European CA guarantees for the foreign CA
Recognition by treaty with EU

13. Electronic signature committee
Representatives of the Member States and chaired by a representative of the Commission
Clarifying the requirements of the annexes;
Establishing the criteria for the designation of national bodies which determine the conformity of secure signature creation devices with Annex III (see Article 3.2b);
Determining the generally recognised standards for electronic signature products which would comply with the requirements laid down in point (e) of Annex II and Annex III (see Article 3.3).
EESSI recommendation:
Adding an advisory group to the Committee
consisting of industry experts

14. A Standardization Framework for Electronic Signature
Presented by
Hans Nilsson
iD2 Technologies

15. Types of Electronic Signatures

16. Levels of standardization and regulation
EU Directive
National implementation
National Legislation
Signature Law
Directive
Level 1
Ordinance
Annexes
National Decree (high-level reqs)
Level 2
Supervision
Technical Rules
International functional and quality standards
Level 3
Conformity assessment
Standards
International interoperability standards
Level 4

17. International Conformity Assessment
Accreditation body for
Certification bodies
EN 45010
Assessment of Certification bodies
Certification body
Certification body
for products
for management systems
EN 45011
EN 45012
Certification of
Certification of
Products
Management Systems
Manufacturer/
Manufacturer/
Supplier
Supplier

18. Formal certification vs Manufacturer’s Declarations
New Approach directives
only “essential requirements”
Detailed standards published in Official Journal
Conformity assessment “modules”:
Formal evaluation by Notified Body, or
Manufacturer’s Declaration
The ES Directive is not strictly a New Approach directive !
Formal evaluation required for
Secure signature creation devices (Annex III)
Trustworthy systems used by CSPs (Annex Iie)
Industry would like to see the use of both Formal evaluations and Manufacturer’s Declarations!

19. Technical Framework for Qualified Electronic Signatures
Although “technology neutral”, the Directive implicitly defines a technical framework
We need to define a “first sets of components” that can be used
A proposed first set that can be used:
Asymmetric cryptography (digital signatures)
Certificate based verification using X.509
Public Key Infrastructure with CAs and Directories
Smart cards and other hardware tokens for private key protection
Reasons for this selection:
Generally accepted, existing standards
Urgent need for standardized use of these technologies!
Other sets of components can be introduced as soon as there is a need and basis for standardization

20. Quality & Functional Standards for Certification Service Providers
Presented by
Nick Pope
Security & Standards Consultancy Ltd

21. Certification Service Provider (CSP) Services
Certification Authority
Registration Authority
Directory
Time-stamping
Attribute Authority
Trusted Archive
Notarisation

22. General Requirements Security Management of CSPs
Technology / service independent requirements
Reliability
Personnel, management administration
Policy documentation
e.g BS 7799, ISO TR (GMITS)

23. CSP Issuing Qualified Certificates
Annex II - Requirements
Reliability
Revocation & timing of revocations
Verify subject identity / attributes
Personnel and management
Trustworthy systems, cryptographic modules
Financial / liability
Protect against forgery, confidentiality
Record relevant information
Keep keys secret

24. CSP Issuing Qualified Certificates
Minimum Policy Requirements
Security Management
Technical Requirements
“Qualified” Certificate Policy
Internet RFC 2527 Framework for Certificate Policies

25. CSP Issuing Qualified Certificates
Trustworthy systems & cryptographic modules
Standard for Trusted Systems
e.g. Common Criteria Protection Profile CS-2
Standard for Cryptographic Security
e.g. Equivalent to FIPS 140-1

26. Certification Service Provider (CSP) Services
CSP Service Relating to Qualified Certificates
Certification Authority
Registration Authority
Directory
Other CSP Services
Time-stamping
Attribute Authority
Trusted Archive
Notarisation

27. CSP Issuing Time Stamps
Security Management Requirements
Technical Requirements
Use of Trusted Systems

28. Other CSP Services
Attribute Authorities
Trusted Archive
Notarisation
Needs better understanding of requirements

29. Requirement for CSP Quality & Functional Standards
CSP Security Management
Security Management & Certificate Policy for CSPs Issuing Qualified Certificates
Use of Trusted Systems for CSPs Issuing Qualified Certificates
Security Management & Policy for CSPs Issuing Time Stamps

30. Presented by Hans Nilsson iD2 Technologies
Functional and Quality Standards for Signature Creation and Verification Products
Presented by
Hans Nilsson
iD2 Technologies

31. Secure Signature Creation Devices (Annex III)
“Practically occur once, secrecy reasonably assured”
high quality key generation and key protection
strong algorithms, sufficient key length
PIN/password, resistant to dictionary attacks and exhaustive search
Signature created inside device, key never leaves device?
no backup copy, or copy of device?
=> smart card or other hardware device!
Security requirement standard needed
Germany, Italy: ITSEC security target
US, Canada: FIPS cryptographic module
Eurosmart Common Criteria Protection Profiles:
Smartcard Integrated Circuit
Smartcard IC with embedded software

32. Secure signature creation process and environment
Not required in the Directive, but guidelines are still needed for:
User interface
User urged to verify the information before signing
Willful act: PIN every time? Mouse-click enough?
Handling of signing device and PIN (in contract with CSP) ……
Operating environment and management
Secure or unsecure card reader
Protection against malicious software

33. Signature verification (Annex IV)
Only recommendations in the Directive, but guidelines needed for:
Human and computer-based verification
Short-term authentication:
All information used for verification shall be “displayed”
Certificate chain shall be verified
Revocation checks shall be performed
Long-term validation of electronic signatures:
evidence for independent adjudicator
requires time-stamping

34. Presented by Denis Pinkas Bull
Interoperability standardization requirements for Electronic Signatures
Presented by
Denis Pinkas
Bull

35. Syntax and encoding
Specification of the syntax and encoding format of an Electronic Signature, including support for multiple signatures and roles
Enhance CMS – S/MIME and add “ time-stamping ” to support long term validation (*).
ETSI TC Security is working in this area.
Standard for the use of X.509 public key certificates as qualified certificates
Support of the on-going work in IETF PKIX and after its completion, consider if any item is missing
(*) For long term Electronic Signature validation see:

36. Syntax and encoding (continued)
Profile for Certificates Revocation Lists (CRLs), Authority Revocation Lists (ARLs), OSCP responses and Time Stamps.
ETSI TC Security should address this requirement.
Standard for storing private keys and other PKI objects on smart cards
The PKCS#15 standard may provide the starting point, but this might be continued by ISO/ JTC1/ SC17.
Standard for description of the constituents of a signature policy understandable both by a human being and a computer.
ETSI TC Security should address this requirement
Standard to reference signature policies.

37. Additional needs
Establish a repository for certificate policies, signature policies or contract types.
The ICC repository being set up under the E-terms initiative could be used.
Define generic roles relevant to current transactions or contracts
An appropriate international organization should define them (ICC or UNICITRAL)

38. Studies are needed for ...
Solving name forms and name collisions both from a technical and legal point of view.
topic partly addressed by the PKIX WG that may have to be complemented.
The handling of name and certificate policy constraints in the verification of a certification path.
RFC does not fully address this concern and an extension to that document should be studied and then proposed to the PKIX working group.
A better understanding of the signature policies.

39. Studies are also needed for (continued) ...
The way to handle large numbers of revoked certificates.
The way to handle suspended certificates in the context of their use in Electronic Signatures.
The roles of notaries in an electronic world both from a technical perspective and a business perspective.

40. Protocols For access to a Time Stamping service.
For access to a repository holding time-stamped certificates and scalable revocation information.
To allow registration without the need to exchange a secret by out-of-bands means.
To allow registration involving smart cards and in particular smart cards being able to generated key pairs.
A profiling of the On Line Certificate Status protocol issued by the IETF may be needed.
A profiling of the Time Stamping protocol under study by the PKIX working group may be needed, once this protocol is published by the IETF.

41. Application Program Interfaces (API)
Define APIs to allow access to various PKI infrastructures on top of the operational and management PKIX protocols.
Experiment the IDUP non repudiation APIs in conjunction with a standard format for electronic signatures in order to test both portability and interoperability.

42. Work programme and participation

43. High-priority work areas

44. How can YOU participate??
CEN/ISSS Workshop for Electronic Signatures
Initial planning meeting: October 11, Brussels
Workshop kickoff: December 16-17, Brussels
Result: CEN Workshop Agreements
Contact: or
ETSI SEC: Electronic Signatures Infrastructure WG
Information on October 11
ESI WG meeting: November 23
Result: ETSI Standards
Contact: