1. "Implementing" the directive (1999/93/EC)

• European Electronic Signature Standardization Initiative (EESSI)
  • CEN (Comité Européen de Normalisation) / ISSS (Information Society Standardization System) E-sign workshop
  • ETSI (European Telecommunications Standards Institute) TC (Technical Committee) / ESI (Electronic Signatures and Infrastructures)
  

"Implementing" the directive (1999/93/EC)

• European Commission
  1. Annex II of Directive 1999/93/EC (Requirements for certification-service-providers issuing qualified certificates):
     • CWA 14167-1 (March 2003): security requirements for trustworthy systems managing certificates for electronic signatures — Part 1: System Security Requirements
     • CWA 14167-2 (March 2002): security requirements for trustworthy systems managing certificates for electronic signatures — Part 2: cryptographic module for CSP signing operations — Protection Profile (MCSO-PP)
  2. Annex III of Directive 1999/93/EC (Requirements for secure signature-creation devices):
     • CWA 14169 (March 2002): secure signature-creation devices

1.1. CEN/ISSS E-sign workshop

• CWA 14167 (Multipart) - Security Requirements for Trustworthy Systems Managing Certificates for Electronic Signatures
• CWA 14169 - Secure Signature-creation devices "EAL 4+"
• CWA 14170 - Security requirements for signature creation applications
• CWA 14171 - General guidelines for electronic signature verification
• CWA 14172 (Multipart) - EESSI Conformity Assessment Guidance
• CWA 14355 - Guidelines for the implementation of Secure Signature-Creation Devices
• CWA 14365 (Multipart) - Guide on the Use of Electronic Signatures
• CWA 14890 (Multipart) - Application Interface for smart cards used as Secure Signature Creation Devices

1.2. ETSI TC/ESI

• ETSI TS 101 733 V1.7.3 - CMS Advanced Electronic Signatures (CAdES)
• ETSI TS 101 862 V1.3.3 - Qualified Certificate profile
• ETSI TS 101 456 V1.4.3 - Policy requirements for certification authorities issuing qualified certificates
• ETSI TS 102 042 V1.3.4 - Policy requirements for certification authorities issuing public key certificates
• ETSI TS 101 861 V1.3.1 - Time stamping profile
• ETSI TS 101 903 V1.3.2 - XML Advanced Electronic Signatures (XAdES)
• ETSI TR 102 605 V1.1.1 - Registered E-Mail
• ...

1.3. Examples

• CWA 14167-1 - Security Requirements for Trustworthy Systems Managing Certificates for Electronic Signatures - Part 1: System Security Requirements
• ETSI TS 101 456 - Policy requirements for certification authorities issuing qualified certificates
• ETSI TS 102 042 - Policy requirements for certification authorities issuing public key certificates
• CWA 14355 - Guidelines for the implementation of Secure Signature-Creation Devices

1.3.1. CWA 14167-1

Security Requirements for Trustworthy Systems Managing Certificates for Electronic Signatures - Part 1: System Security Requirements

According to Annex II of Dir.1999/93/EC, CSPs must:

"use trustworthy systems and products which are protected against modification and which must ensure the technical and cryptographic security of the processes supported by them".

CWA 14167-1

• Overall architecture:
  

CWA 14167-1

• Security levels:
  1. Non-Qualified Certificates (NQCs):
     • Used for Electronic Signatures, meeting [Dir.1999/93/EC], Article 5.2
     • Used for Electronic Signatures in internal tasks of the TWS (Trustworthy System)
  2. Qualified Certificates (QCs):
     • Used for Advanced Electronic Signatures (AES) which are created by a Secure-Signature-Creation Device (SSCD), meeting Dir.1999/93/EC, Article 5.1
     • Used for Advanced Electronic Signatures (AES) which are created by a Signature-Creation Device (SCDev)

CWA 14167-1

• Security Requirements
  • General Security Requirements
    • Management
    • Systems & Operations
    • Identification & Authentication
    • System Access Control
    • Key Management
    • Accounting & Auditing
    • Archiving
    • Backup & Recovery

CWA 14167-1

• Security Requirements (cont'd)
  • Core Services Security Requirements
    • General
    • Registration Service
    • Certificate Generation Service
    • Dissemination Service
    • Certificate Revocation Management Service
    • Certificate Revocation Status Service
  • Supplementary Services Security Requirements
    • Time-Stamping Service
    • Subject Device Provision Service.

1.3.2. ETSI TS 101 456

Policy requirements for certification authorities issuing qualified certificates

1. a qualified certificate policy for qualified certificates issued to the public, requiring use of secure signature-creation devices;
2. a qualified certificate policy for qualified certificates issued to the public.

1.3.3. ETSI TS 102 042

Policy requirements for certification authorities issuing public key certificates

1. An extended Normalized Certificate Policy (NCP+) which offers
   • the same quality as that offered by the Qualified Certificate Policy (QCP) as defined in TS 101 456
   • but without the legal constraints implied by the Electronic Signature Directive (1999/93/EC)
   • and, instead of requiring the use of a Secure Signature Creation, requires the use of a secure user device.
2. A Normalized Certificate Policy (NCP) which offers
   • the same quality as that offered by the Qualified Certificate Policy (QCP) as defined in TS 101 456
   • but without the legal constraints implied by the Electronic Signature Directive (1999/93/EC)
   • and without requiring the use of a Secure Signature Creation Device.
3. A Lightweight Certificate Policy (LCP) which incorporates less demanding policy requirements (e.g. physical presence).

1.3.4. CWA 14355

Guidelines for the implementation of Secure Signature-Creation Devices

• SSCD Types:
  1. SSCD Type 1: SCD/SVD-pair generation
  2. SSCD Type 2: Signature-creation
  3. SSCD Type 3: Both SCD/SVD-pair generation and signature-creation

2. X.509 Public Key Certificate - RFC 3280

Structure of an X.509 certificate (RFC 3280):

     Certificate ::= SEQUENCE {
     	TBSCertificate ::= SEQUENCE {
          	version,		(default v1)
  	        serialNumber,
          	signature,	       	(algorithm)
          	issuer,          	(DN, e.g. c=LU,o=Uni)
          	validity,
          	subject,         	(DN, c=LU,o=Uni,cn=Pascal Steichen)
          	subjectPublicKeyInfo,	(public key and algorithms used)
          	issuerUniqueID,		(optional)
          	subjectUniqueID,	(optional)
          	extensions
          }
          signatureAlgorithm,		(algorithm)
          signatureValue			(CA's signature)
          }

2.1. Certificate Extensions

     Extension ::= SEQUENCE {
           extnID,	(identifier)
           critical,	(criticality - boolean)
           extnValue	(valeur)
     }

The standard extensions can be grouped as follows:

1. informations on keys
2. informations on the certificat usages
3. user and CA attributes
4. co-certification constraints

2.1.1. informations on keys

• Authority Key Identifier

        AuthorityKeyIdentifier ::= SEQUENCE {
            keyIdentifier             [0] KeyIdentifier           OPTIONAL,
            authorityCertIssuer       [1] GeneralNames            OPTIONAL,
            authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL }
  

• Subject Key Identifier
• Key Usage

        KeyUsage ::= BIT STRING {
               digitalSignature        (0),
               nonRepudiation          (1),
               keyEncipherment         (2),
               dataEncipherment        (3),
               keyAgreement            (4),
               keyCertSign             (5),
               cRLSign                 (6),
               encipherOnly            (7),
               decipherOnly            (8) 
               }
  

• Extended Key Usage

informations on keys

• CRL Distribution Points

        CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint
    
        DistributionPoint ::= SEQUENCE {
            distributionPoint       [0]     DistributionPointName OPTIONAL,
            reasons                 [1]     ReasonFlags OPTIONAL,
            cRLIssuer               [2]     GeneralNames OPTIONAL }
    
        DistributionPointName ::= CHOICE {
            fullName                [0]     GeneralNames,
            nameRelativeToCRLIssuer [1]     RelativeDistinguishedName }
    
        ReasonFlags ::= BIT STRING {
             unused                  (0),
             keyCompromise           (1),
             cACompromise            (2),
             affiliationChanged      (3),
             superseded              (4),
             cessationOfOperation    (5),
             certificateHold         (6),
             privilegeWithdrawn      (7),
             aACompromise            (8) }
  

2.1.2. informations on the certificat usages

• Certificate Policies
• Policy Mappings

2.1.3. user and CA attributes

• Subject Alternative Name
• Issuer Alternative Names
• Subject Directory Attributes

2.1.4. co-certification constraints

• Basic Constraints

        BasicConstraints ::= SEQUENCE {
             cA                      BOOLEAN DEFAULT FALSE,
             pathLenConstraint       INTEGER (0..MAX) OPTIONAL }
  

• Name Constraints
• Policy Constraints

2.2. Example

Example

3. IETF - Internet X.509 Public Key Infrastructure (PKIX)

PKIX standardisation areas:

• Management protocols.
  • registration of entity, that takes place prior to issuing the certificate,
  • initialisation, for example generation of key-pair,
  • certification, the issuance of the certificate,
  • key–pair recovery, the ability to recover lost keys,
  • key–pair update, when the certificate expires and a new key–pair and certificate have to be generated,
  • revocation request, when an authorised person advices the CA to include a specific certificate into the revocation list,
  • cross-certification, when two CAs exchange information in order to generate a cross–certificate.
• Operational protocols.
  • required to deliver certificates and CRLs to certificate–using client systems.

IETF - Internet X.509 Public Key Infrastructure (PKIX)

• Certificate policies and Certificate Practice Statements.
  The Certificate Policies and the Certificate Practice Statements are recommendations of documents that will describe the obligations and other rules with regard the usage of the Certificate.

• Time–stamping and data–certification/validation services.

3.1. PKI - Public-Key Infrastructure

A PKI is a set of hardware, software, people, policies and procedures needed to create, manage, store, distribute and revoke PKCs based on public–key cryptography.

A PKI consists of five types of components.

Type of component	Description
Certification Authorities (CAs)	to issue and revoke PKCs
Registration Authorities (RAs)	to vouch for the binding between public keys and certificate holder identities and other attributes
Certificate holders (end entities, EE)	to sign and encrypt digital documents
Clients (end entities, EE)	to validate digital signatures and their certification path from a known public key of a trusted CA
Repositories	to store and make available certificates and Certificate Revocation Lists (CRLs)

PKI Management Operations

At a high level, the set of operations for which management messages are defined can be grouped as follows.

• CA establishment
• End entity initialization
• Certification
  • initial registration/certification
  • key pair update
  • certificate update
  • CA key pair update
  • cross-certification request
    A "cross-certificate" is a certificate in which the subject CA and the issuer CA are distinct and SubjectPublicKeyInfo contains a verification key (i.e., the certificate has been issued for the subject CA’s signing key pair).
  • cross-certificate update

PKI Management Operations

• Certificate/CRL discovery operations
  • certificate publication
  • CRL publication
• Recovery operations
  • key pair recovery
• Revocation operations
  • revocation request

PKI Management Operations

4. Certificate revocation list (CRL) - RFC 3280

• A complete CRL: lists all unexpired certificates, within its scope, that have been revoked for one of the revocation reasons covered by the CRL scope.

• A delta CRL: only lists those certificates, within its scope, whose revocation status has changed since the issuance of a referenced complete CRL.

    CertificateList ::= SEQUENCE {
  	TBSCertList ::=    SEQUENCE  {
  		version,	(optional)
       		signature,      (algorithm)
       		issuer,
       		thisUpdate,
       		nextUpdate,	(optional)
       		revokedCertificates       SEQUENCE OF SEQUENCE {
            		userCertificate,	(certificate serial number),
            		revocationDate,         
            		crlEntryExtensions      (optional)
           	},		(optional)
       		crlExtensions,	(optional)
  	}
       	signatureAlgorithm, 	(algorithm)
       	signatureValue,
    }

4.1. CRL Entry Extensions

      reasonCode ::= < CRLReason >
  
      CRLReason ::= ENUMERATED {
           unspecified             (0),
           keyCompromise           (1),
           cACompromise            (2),
           affiliationChanged      (3),
           superseded              (4),
           cessationOfOperation    (5),
           certificateHold         (6),
           removeFromCRL           (8),
           privilegeWithdrawn      (9),
           aACompromise           (10) }

4.2. Basic Certificate Processing

The basic path processing actions to be performed for a certificate validation:

1. The certificate was signed with the working_public_key_algorithm using the working_public_key and the working_public_key_parameters.
2. The certificate validity period includes the current time.
3. At the current time, the certificate is not revoked and is not on hold status.
4. The certificate issuer name is the working_issuer_name.

5. Online Certificate Status Protocol (OCSP) - RFC 2560

In lieu of or as a supplement to checking against a periodic CRL, it may be necessary to obtain timely information regarding the revocation status of a certificate (e.g. high-value funds transfer or large stock trades). -> OCSP

• An OCSP request contains the following data:
  • protocol version
  • service request
  • target certificate identifier
  • optional extensions
• Upon receipt of a request, an OCSP Responder determines if:
  1. the message is well formed
  2. the responder is configured to provide the requested service and
  3. the request contains the information needed by the responder

Online Certificate Status Protocol (OCSP) - RFC 2560

• All definitive response messages SHALL be digitally signed. The key used to sign the response MUST belong to one of the following:
  • the CA who issued the certificate in question
  • a Trusted Responder whose public key is trusted by the requester
  • a CA Designated Responder (Authorized Responder)
• A definitive response message is composed of:
  • version of the response syntax
  • name of the responder
  • responses for each of the certificates in a request
  • optional extensions
  • signature algorithm OID
  • signature computed across hash of the response

Online Certificate Status Protocol (OCSP) - RFC 2560

• The response for each of the certificates in a request consists of:
  • target certificate identifier
  • certificate status value
  • response validity interval
  • optional extensions
• This specification defines the following definitive response indicators for use in the certificate status value:
  • good
  • revoked
  • unknown

Online Certificate Status Protocol (OCSP) - RFC 2560

• Functional Requirements :
  • Certificate Content (via AuthorityInfoAccess extension)
  • Signed Response Acceptance Requirements
    Prior to accepting a signed response as valid, OCSP clients SHALL confirm that:
    1. The certificate identified in a received response corresponds to that which was identified in the corresponding request;
    2. The signature on the response is valid;
    3. The identity of the signer matches the intended recipient of the request.
    4. The signer is currently authorized to sign the response.
    5. The time at which the status being indicated is known to be correct (thisUpdate) is sufficiently recent.
    6. When available, the time at or before which newer information will be available about the status of the certificate (nextUpdate) is greater than the current time.

6. Certificate Policy and Certification Practices Framework - RFC 3647

• Certificate policy (CP)
  The X.509 standard defines a CP as "a named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements".
  • CPs typically fall into two major categories:
    • some CPs "indicate the applicability of a certificate to a particular community"
    • the second category "indicate the applicability of a certificate to a ... class of application with common security requirements"
  • CPs also constitute a basis for an audit, accreditation, or another assessment of a CA (cross-certification).

Certificate Policy and Certification Practices Framework - RFC 3647

• Certification Practice Statement (CPS)
  The term certification practice statement (CPS) is defined as: "A statement of the practices which a certification authority employs in issuing certificates".
  • "A certification practice statement may take the form of a declaration by the certification authority of the details of its trustworthy system and the practices it employs in its operations and in support of issuance of a certificate ..."
  • CPSs do not automatically constitute contracts and do not automatically bind PKI participants as a contract would (dual-purpose however possible).

Certificate Policy and Certification Practices Framework - RFC 3647

• The main differences between CPs and CPSs can be summarized as follows:
  1. A PKI uses a CP to establish requirements that state what participants within it must do. A single CA or organization can use a CPS to disclose how it meets the requirements of a CP or how it implements its practices and controls.
  2. A CP facilitates interoperation through cross-certification, unilateral certification, or other means. Therefore, it is intended to cover multiple CAs. By contrast, a CPS is a statement of a single CA or organization. Its purpose is not to facilitate interoperation (since doing so is the function of a CP).
  3. A CPS is generally more detailed than a CP and specifies how the CA meets the requirements specified in the one or more CPs under which it issues certificates.
• In addition to populating the certificate policies extension with the applicable CP object identifier, a certification authority may include, in certificates it issues, a reference to its certification practice statement.

6.1. Recommended CP or CPS outline

In order to comply with the RFC, the drafters of a compliant CP or CPS are strongly advised to adhere to the following outline:

1. INTRODUCTION
2. PUBLICATION AND REPOSITORY RESPONSIBILITIES
3. IDENTIFICATION AND AUTHENTICATION
4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS
5. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS
6. TECHNICAL SECURITY CONTROLS
7. CERTIFICATE, CRL, AND OCSP PROFILES
8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS
9. OTHER BUSINESS AND LEGAL MATTERS

7. Time-Stamping Authorities (TSAs) - RFC 3628

7.1. Time-Stamp Token

1. The time-stamp token shall include an identifier for the time-stamp policy;
2. Each time-stamp token shall have a unique identifier;
3. The time values the TSU uses in the time-stamp token shall be traceable to at least one of the real time values distributed by a UTC(k) laboratory.
4. The time included in the time-stamp token shall be synchronized with UTC within the accuracy defined in this policy and, if present, within the accuracy defined in the time-stamp token itself;
5. If the time-stamp provider’s clock is detected as being out of the stated accuracy then time-stamp tokens shall not be issued.
6. The time-stamp token shall include a representation (e.g., hash value) of the datum being time-stamped as provided by the requestor;

7. The time-stamp token shall be signed using a key generated exclusively for this purpose.
8. The time-stamp token shall include further :
   • where applicable, an identifier for the country in which the TSA is established;
   • an identifier for the TSA;
   • an identifier for the unit which issues the time-stamps.

Time-Stamping Authorities (TSAs)

Non-repudiation services require the ability to establish the existence of data before specified times. This protocol may be used as a building block to support such services.

• The TSA is REQUIRED:
  • to use a trustworthy source of time.
  • to include a trustworthy time value for each time-stamp token.
  • to include a unique integer for each newly generated time-stamp token.
  • to produce a time-stamp token upon receiving a valid request from the requester, when it is possible.
  • to include within each time-stamp token an identifier to uniquely indicate the security policy under which the token was created.
  • to only time-stamp a hash representation of the datum
  • to examine the OID of the one-way collision resistant hash-function and to verify that the hash value length is consistent with the hash algorithm.

Time-Stamping Authorities (TSAs)

• The TSA is REQUIRED (cont'd):
  • not to examine the imprint being time-stamped in any way (other than to check its length, as specified in the previous bullet).
  • not to include any identification of the requesting entity in the time-stamp tokens.
  • to sign each time-stamp token using a key generated exclusively for this purpose and have this property of the key indicated on the corresponding certificate.
  • to include additional information in the time-stamp token, if asked by the requester using the extensions field, only for the extensions that are supported by the TSA. If this is not possible, the TSA SHALL respond with an error message.

7.2. Time-Stamp Protocol (TSP) - RFC 3161 - Request Format

     TimeStampReq ::= SEQUENCE {
          version                      INTEGER < v1(1) >,
          messageImprint               MessageImprint,
            --a hash algorithm OID and the hash value of the data to be
            --time-stamped
          reqPolicy             TSAPolicyId               OPTIONAL,
          nonce                 INTEGER                   OPTIONAL,
          certReq               BOOLEAN                   DEFAULT FALSE,
          extensions            [0] IMPLICIT Extensions   OPTIONAL }
  
     MessageImprint ::= SEQUENCE   {
          hashAlgorithm               AlgorithmIdentifier,
          hashedMessage               OCTET STRING }

7.3. Time-Stamp Protocol (TSP) - RFC 3161 - Response Format

     TimeStampResp ::= SEQUENCE {
          status                    PKIStatusInfo,
          timeStampToken            TimeStampToken   OPTIONAL  }
  
     PKIStatusInfo ::= SEQUENCE {
          status         PKIStatus,
          statusString PKIFreeText        OPTIONAL,
          failInfo       PKIFailureInfo   OPTIONAL }

     PKIStatus ::= INTEGER {
          granted                 (0),
          -- when the PKIStatus contains the value zero a TimeStampToken, as
             requested, is present.
          grantedWithMods         (1),
           -- when the PKIStatus contains the value one a TimeStampToken,
             with modifications, is present.
          rejection               (2),
          waiting                 (3),
          revocationWarning       (4),
           -- this message contains a warning that a revocation is
           -- imminent
          revocationNotification (5)
           -- notification that a revocation has occurred }

8. Public-Key Cryptography Standards (PKCS)