European Electronic Signature Standardization Hans Nilsson, iD2 Technologies, S Patrick van Eecke, ICRI, University of Leuven, B Nick Pope, Security &

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: www.ict.etsi.org

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

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

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

5EESSI Expert team report

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)


Definitions

Electronic signature

Certification service provider (CSP)

Advanced electronic signature

Signature creation/verification data

Signature creation/verification device

Qualified certificate

“Qualified Signature”


Scope of the Directive

The two main objectives of the directive

Free internal market for electronicsignatures and certification services

Legal equivalence of electronicsignatures with hand-written signatures

All kinds of electronic signatures

All kinds of certification services

All kinds of signature products

Only under certain conditions

Only for specific purposes

with many exceptions

Broad scope

Limited scope


forbidden

allowed

Internal market

1. Authorisation (obligatory)

2. Accreditation (voluntary)

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

3. Supervision


Legal Recognition 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


The Annexes

Requirements

Annex I: Qualified certificate

Annex II: Certification Service Providers issuing qualified certificates

Annex III: Secure Signature Creation Device

Recommendations

Annex IV: Signature Verification


Liability

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

Only for CSP fulfilling Annex II and issuing/guaranteeing qualified certificates to the public


International aspects

if: Foreign CA fulfils same requirements + accreditation by Member State

or

A European CA guarantees for the foreign CA

or

Recognition by treaty with EU

Foreign certificates = Qualified certificatesForeign certificates = Qualified certificates


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

A Standardization Framework for Electronic Signature

Presented by

Hans Nilsson

iD2 Technologies


Types of Electronic Signatures

Type ofsignature:

General electronicsignature asrequired in 5.2

Qualified electronicsignature - as specified in5.1 (2.1 a, 2.3 a, Annex I,II, III)

Enhanced electronicsignature (applicable toboth general and qualifiedelectronic signatures)

Level of legalcertainty:

Can not be deniedlegal effect (art 5.2)

Same legal effect as hand-written signature (art 5.1)

Enhancement of legalcertainty (additionalevidence)

Explanation: Any electronicsignature that is nota qualifiedelectronic signature.

Minimum technical levelrequired for the signer sothat his electronicsignature can beconsidered as legallyequivalent with a hand-written signature.

Additional technicalrequirements for a verifier,such as time-stamping, butalso for the signer, toenhance technical securityand obtain protectionagainst certain threats.


Ordinance

Signature Law

Technical Rules

Standards

National Decree(high-level reqs)

National Legislation

International functional and

quality standards

Internationalinteroperability

standards

National implementation

Annexes

Directive

EU Directive

Level 2

Level 3

Level 4

Supervision

Conformityassessment

Level 1

Levels of standardization and regulation


Accreditation body forCertification bodies

Assessment of Certification bodies

EN 45010

Manufacturer/Supplier

Manufacturer/Supplier

Certification bodyfor management systems

EN 45012

Certification bodyfor productsEN 45011

Certification ofManagement Systems

Certification ofProducts

International Conformity Assessment


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!


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

Technical Framework for Qualified Electronic Signatures

Quality & Functional Standards forCertification Service Providers

Presented by

Nick Pope

Security & Standards Consultancy Ltd


Certification Service Provider (CSP) Services

Certification Authority

Registration Authority

Directory

Time-stamping

Attribute Authority

Trusted Archive

Notarisation


General Requirements

Security Management of CSPs

Technology / service independent requirements

Reliability

Personnel, management administration

Policy documentation

e.g BS 7799, ISO TR 13335 (GMITS)


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



Minimum Policy Requirements

Security Management

Technical Requirements

“Qualified” Certificate Policy

Internet RFC 2527 Framework for Certificate Policies



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


Certification Service Provider (CSP) Services

CSP Service Relating to Qualified CertificatesCSP Service Relating to Qualified Certificates

Certification Authority

Registration Authority

Directory

Other CSP ServicesOther CSP Services

Time-stamping

Attribute Authority Authority

Trusted Archive

Notarisation


CSP Issuing Time Stamps

Security Management Requirements

Technical Requirements

Use of Trusted Systems


Other CSP Services

Attribute Authorities

Trusted Archive

Notarisation

Needs better understanding of requirements


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

Functional and Quality Standards forSignature Creation and Verification Products

Presented by

Hans Nilsson

iD2 Technologies


“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 140-1 cryptographic module

Eurosmart Common Criteria Protection Profiles:

Smartcard Integrated Circuit

Smartcard IC with embedded software

Secure Signature Creation Devices (Annex III)


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

Secure signature creation process and environment


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

Signature verification (Annex IV)

Interoperability standardization requirements for Electronic Signatures

Presented by

Denis Pinkas

Bull


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: http://www.id2tech.com/news/pdf/ES_validation.pdf http://www.openmaster.com/whitepapers/es_validation.pdf


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.


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)


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 2459 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.


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.


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.


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.

Work programme and participation


Prio-rity

Work item ResponsibleBody

Directive-releated standardization:

Urgent Standard for the use of X.509 public key certificates as qualified certificates (AnnexI)

ETSI

High Security management and certificate policy for CSP issuing qualified certificates(Annex II)

ETSI

Urgent Security requirements for trusted systems used by CSPs issuing qualified certificates(Annex II e)

CEN

Urgent Security requirements for hardware devices used as secure signature creationdevices (Annex III)

CEN

High Recommendations for signature creation and verification (includes Annex IV) CEN

Urgent Certification/registration of products and services for electronic signatures EA & others

High Electronic Signature syntax and encoding formats ETSI

Interoperability standardization:

High Technical aspects of signature policies ETSI

High Protocol to interoperate with a Time Stamping Authority ETSI

High Interoperability trials of proposed standards (possible financing through EU ISISprogramme)

User andindustry

High-priority work areas


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: [email protected] or [email protected]

ETSI SEC: Electronic Signatures Infrastructure WG

Information on October 11

ESI WG meeting: November 23

Result: ETSI Standards

Contact: [email protected]

Documents

European Electronic Signature Standardization Hans Nilsson, iD2 Technologies, S Patrick van Eecke, ICRI, University of Leuven, B Nick Pope, Security &