PKI applications (C2)

Standards and protocols

Pascal Steichen (MSSI-uni.lu) - 12/01/2008

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

1.1. CEN/ISSS E-sign workshop

Successful implementation of European Directive 1999/93/EC on a Community framework for electronic signatures [Dir.1999/93/EC] requires standards for services, processes, systems and products related to electronic signatures as well as guidance for conformity assessment of such services, processes, systems and products.

In 1999 the European ICT Standards Board, with the support of the European Commission, undertook an initiative bringing together industry and public authorities, experts and other market players, to create the European Electronic Signature Standardisation Initiative (EESSI).

Within this framework the CEN/ISSS Workshop on Electronic Signatures and the ETSI TC on Electronic Signatures and Infrastructures (ETSI/ESI) were entrusted with the execution of a work programme in support of the implementation of the Directive1999/93/EC and the development of a European electronic signature infrastructure.

1.2. ETSI TC/ESI

1.3. Examples

1.3.1. CWA 14167-1

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

Annex II of [Dir.1999/93/EC] provides the requirements for a Certificate Service Provider (CSP) issuing Qualified Certificates (QCs). This CWA principally concentrates on providing all the technical security requirements for the Trustworthy Systems (TWSs) a CSP needs to deploy.

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

Non-Qualified Certificates (NQCs) used for Electronic Signatures may require less security provisions when compared to QCs and therefore this CWA caters for both and indicates the areas where differentiation is required.

  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)

1.3.2. ETSI TS 101 456

Policy requirements for certification authorities issuing qualified certificates

A certificate policy is 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".

The policy requirements are defined in the present document in terms of certificate policies. These certificate policies are for qualified certificates, as defined the Directive [1], and hence are called qualified certificate policies. Certificates issued in accordance with the present document include a certificate policy identifier which can be used by relying parties in determining the certificates suitability and trustworthiness for a particular application. The present document specifies two qualified certificate policies:

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

    NOTE 1: The exact meaning of public is left to interpretation within the context on national legislation. A CA may be considered to be issuing qualified certificates to the public if the certificates are not restricted to uses governed by voluntary agreements under private law among participants.

  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

The present document includes options for supporting the same level of quality by certification authorities issuing qualified certificates (as required article 5.1 of the Electronic Signature Directive 1999/93/EC [16]) but "normalized" for wider applicability and for ease of alignment with other similar specifications and standards from other sources and institutions. Through such harmonization the quality level set by the Electronic Signature Directive can become embodied in more widely recognized and accepted specifications.

The policy requirements are defined in terms of three reference certificates policies and a framework from which CAs can produce a certificate policy targeted at a particular service.

  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.

    NOTE 2: The certificate policy NCP+ is particularly suited to the support of Advanced Electronic Signatures, as defined by the Electronic Signature Directive (1999/93/EC), for human beings as well as legal entities since the use of a secure user device provides confidence that the signing key remains under the sole control of the signatory.

  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.

    NOTE 1: The certificate policy NCP is particularly suited to the support of Advanced Electronic Signatures, as defined by the Electronic Signature Directive (1999/93/EC), for legal entities if they use physical means to provide reasonable confidence that the signing key remains under their sole control.

  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

2. X.509 Public Key Certificate - RFC 3280

A 'certificate' is a digitally signed, structured message that asserts an association between specific data and a particular public key. An 'identity certificate' is then a particular class of certificate that associates a particular identifier with a particular public key.

The dominant standard at present is the family of CCITT X.500 standards, in particular X.509 (X.509 (1988, 1997) 'The Directory - Authentication Framework', Volume VIII of CCITT Blue Book, pages 48-81, CCITT/ITU, 1988, 1997). The current version of X.509 is number 3, usually referred to as X.509v3, which was finalised in 1997. A set of standards, dubbed PKIX (Internet X.509 Public Key Infrastructure), enables use of X.509.

Carl M. Ellison describes the history this way: "the X.500 proposal was published in the late 1980s. It was to be a global directory of named entities. To tie a public key to some node or sub-directory of that structure, the X.509 certificate was defined. The Subject of such a certificate was a path name indicating a node in the X.500 database - a so-called 'Distinguished Name'. The X.500 dream has effectively died but the X.509 certificate has lived on. The distinguished name took the place of a person's name and the certificate was called an 'identity certificate', assumed to bind an identity to a public key ...". In short, X.509 was the hammer that came to hand when the nail was discovered.

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 extensions defined for X.509 v3 certificates provide methods for associating additional attributes with users or public keys and for managing a certification hierarchy. The X.509 v3 certificate format also allows communities to define private extensions to carry information unique to those communities. Each extension in a certificate is designated as either critical or non-critical. A certificate using system MUST reject the certificate if it encounters a critical extension it does not recognize; however, a non-critical extension MAY be ignored if it is not recognized. The following sections present recommended extensions used within Internet certificates and standard locations for information. Communities may elect to use additional extensions; however, caution ought to be exercised in adopting any critical extensions in certificates which might prevent use in a general context.

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

2.1.2. informations on the certificat usages

2.1.3. user and CA attributes

2.1.4. co-certification constraints

2.2. Example

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

PKIX standardisation areas:

It describes the basic certificate fields and the extensions to be supported for the Certificates and the Certificate Revocation Lists. Then, it talks about the basic and extended Certificate Path Validation. Finally, it covers the supported cryptographic algorithms.

The relevant Request For Comments (RFC) documents are depicted in the following table

Subject RFC
Certificate and Certificate Revocation List (CRL) Profile RFC 3280
Certificate Management Protocol (CMP) RFC 4210
Operational protocols RFC 3494 (LDAP), RFC 2585, RFC 2560 (OCSP)
Certificate Policy and Certification Practices Framework RFC 3647
Time–stamping and data–certification services RFC 3628, RFC 3161

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)

The End–entity, using management transactions, sends its certificate request to the Registration Authority for approval. If it is actually approved, it is forwarded to the Certification Authority for signing. The Certification Authority verifies the certificate request and if it passes the verification, it is signed and the Certificate is produced. To public the Certificate, the CA sends it to Certificate Repository for collection from the End–entity.

The diagram shows that the End–entity can communicate directly with the CA. According to the PKIX recommendations, it is possible to implement the functionality within the CA. Although it is a bit confusing, the diagram shows all possible communications, regardless of the implementation decisions.

Additionally, both the CA and RA are shown to deliver Certificates to the repository. Depending on the implementation, one of the two is chosen.

For the issue of the revocation of the certificates, a similar course with the generation of the Certificates is taken. The End–entity asks the RA to have its Certificate revoked, the RA decides and possibly forwards it to the CA, the CA updates the revocation list and publishes it on the CRL repository.

Finally, the End–entities can check the validity of a specific Certificate using an operational protocol.

The following diagram shows the relationship between the entities defined above in terms of the PKI management operations. The letters in the diagram indicate "protocols" in the sense that a defined set of PKI management messages can be sent along each of the lettered lines.

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

4. Certificate revocation list (CRL) - RFC 3280

  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.

    This may be determined by obtaining the appropriate CRL status information, or by out-of-band mechanisms.

  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

The Online Certificate Status Protocol (OCSP) enables applications to determine the (revocation) state of an identified certificate. OCSP may be used to satisfy some of the operational requirements of providing more timely revocation information than is possible with CRLs and may also be used to obtain additional status information. An OCSP client issues a status request to an OCSP responder and suspends acceptance of the certificate in question until the responder provides a response.

This protocol specifies the data that needs to be exchanged between an application checking the status of a certificate and the server providing that status.

If any one of the prior conditions are not met, the OCSP responder produces an error message; otherwise, it returns a definitive response.

OCSP responses can be of various types. An OCSP response consists of a response type and the bytes of the actual response. There is one basic type of OCSP response that MUST be supported by all OCSP servers and clients. The rest of this section pertains only to this basic response type.

6. Certificate Policy and Certification Practices Framework - RFC 3647

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

    1. Overview
    2. Document name and identification
    3. PKI participants
      1. Certification authorities
      2. Registration authorities
      3. Subscribers
      4. Relying parties
      5. Other participants
    4. Certificate usage
      1. Appropriate certificate uses
      2. Prohibited certificate uses
    5. Policy administration
      1. Organization administering the document
      2. Contact person
      3. Person determining CPS suitability for the policy
      4. CPS approval procedures
    6. Definitions and acronyms

  2. PUBLICATION AND REPOSITORY RESPONSIBILITIES

    1. Repositories
    2. Publication of certification information
    3. Time or frequency of publication
    4. Access controls on repositories

  3. IDENTIFICATION AND AUTHENTICATION

    1. Naming
      1. Types of names
      2. Need for names to be meaningful
      3. Anonymity or pseudonymity of subscribers
      4. Rules for interpreting various name forms
      5. Uniqueness of names
      6. Recognition, authentication, and role of trademarks
    2. Initial identity validation
      1. Method to prove possession of private key
      2. Authentication of organization identity
      3. Authentication of individual identity
      4. Non-verified subscriber information
      5. Validation of authority
      6. Criteria for interoperation
    3. Identification and authentication for re-key requests
      1. Identification and authentication for routine re-key
      2. Identification and authentication for re-key after revocation
    4. Identification and authentication for revocation request

  4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS

    1. Certificate Application
      1. Who can submit a certificate application
      2. Enrollment process and responsibilities
    2. Certificate application processing
      1. Performing identification and authentication functions
      2. Approval or rejection of certificate applications
      3. Time to process certificate applications
    3. Certificate issuance
      1. CA actions during certificate issuance
      2. Notification to subscriber by the CA of issuance of certificate
    4. Certificate acceptance
      1. Conduct constituting certificate acceptance
      2. Publication of the certificate by the CA
      3. Notification of certificate issuance by the CA to other entities
    5. Key pair and certificate usage
      1. Subscriber private key and certificate usage
      2. Relying party public key and certificate usage
    6. Certificate renewal
      1. Circumstance for certificate renewal
      2. Who may request renewal
      3. Processing certificate renewal requests
      4. Notification of new certificate issuance to subscriber
      5. Conduct constituting acceptance of a renewal certificate
      6. Publication of the renewal certificate by the CA
      7. Notification of certificate issuance by the CA to other entities
    7. Certificate re-key
      1. Circumstance for certificate re-key
      2. Who may request certification of a new public key
      3. Processing certificate re-keying requests
      4. Notification of new certificate issuance to subscriber
      5. Conduct constituting acceptance of a re-keyed certificate
      6. Publication of the re-keyed certificate by the CA
      7. Notification of certificate issuance by the CA to other entities
    8. Certificate modification
      1. Circumstance for certificate modification
      2. Who may request certificate modification
      3. Processing certificate modification requests
      4. Notification of new certificate issuance to subscriber
      5. Conduct constituting acceptance of modified certificate
      6. Publication of the modified certificate by the CA
      7. Notification of certificate issuance by the CA to other entities
    9. Certificate revocation and suspension
      1. Circumstances for revocation
      2. Who can request revocation
      3. Procedure for revocation request
      4. Revocation request grace period
      5. Time within which CA must process the revocation request
      6. Revocation checking requirement for relying parties
      7. CRL issuance frequency (if applicable)
      8. Maximum latency for CRLs (if applicable)
      9. On-line revocation/status checking availability
      10. On-line revocation checking requirements
      11. Other forms of revocation advertisements available
      12. Special requirements re key compromise
      13. Circumstances for suspension
      14. Who can request suspension
      15. Procedure for suspension request
      16. Limits on suspension period
    10. Certificate status services
      1. Operational characteristics
      2. Service availability
      3. Optional features
      4. End of subscription
      5. Key escrow and recovery
      6. Key escrow and recovery policy and practices
      7. Session key encapsulation and recovery policy and practices

  5. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS

    1. Physical controls
      1. Site location and construction
      2. Physical access
      3. Power and air conditioning
      4. Water exposures
      5. Fire prevention and protection
      6. Media storage
      7. Waste disposal
      8. Off-site backup
    2. Procedural controls
      1. Trusted roles
      2. Number of persons required per task
      3. Identification and authentication for each role
      4. Roles requiring separation of duties
    3. Personnel controls
      1. Qualifications, experience, and clearance requirements
      2. Background check procedures
      3. Training requirements
      4. Retraining frequency and requirements
      5. Job rotation frequency and sequence
      6. Sanctions for unauthorized actions
      7. Independent contractor requirements
      8. Documentation supplied to personnel
    4. Audit logging procedures
      1. Types of events recorded
      2. Frequency of processing log
      3. Retention period for audit log
      4. Protection of audit log
      5. Audit log backup procedures
      6. Audit collection system (internal vs. external)
      7. Notification to event-causing subject
      8. Vulnerability assessments
    5. Records archival
      1. Types of records archived
      2. Retention period for archive
      3. Protection of archive
      4. Archive backup procedures
      5. Requirements for time-stamping of records
      6. Archive collection system (internal or external)
      7. Procedures to obtain and verify archive information
    6. Key changeover
    7. Compromise and disaster recovery
      1. Incident and compromise handling procedures
      2. Computing resources, software, and/or data are corrupted
      3. Entity private key compromise procedures
      4. Business continuity capabilities after a disaster
    8. CA or RA termination

  6. TECHNICAL SECURITY CONTROLS

    1. Key pair generation and installation
      1. Key pair generation
      2. Private key delivery to subscriber
      3. Public key delivery to certificate issuer
      4. CA public key delivery to relying parties
      5. Key sizes
      6. Public key parameters generation and quality checking
      7. Key usage purposes (as per X.509 v3 key usage field)
    2. Private Key Protection and Cryptographic Module Engineering Controls
      1. Cryptographic module standards and controls
      2. Private key (n out of m) multi-person control
      3. Private key escrow
      4. Private key backup
      5. Private key archival
      6. Private key transfer into or from a cryptographic module
      7. Private key storage on cryptographic module
      8. Method of activating private key
      9. Method of deactivating private key
      10. Method of destroying private key
      11. Cryptographic Module Rating
    3. Other aspects of key pair management
      1. Public key archival
      2. Certificate operational periods and key pair usage periods
    4. Activation data
      1. Activation data generation and installation
      2. Activation data protection
      3. Other aspects of activation data
    5. Computer security controls
      1. Specific computer security technical requirements
      2. Computer security rating
    6. Life cycle technical controls
      1. System development controls
      2. Security management controls
      3. Life cycle security controls
    7. Network security controls
    8. Time-stamping

  7. CERTIFICATE, CRL, AND OCSP PROFILES

    1. Certificate profile
      1. Version number(s)
      2. Certificate extensions
      3. Algorithm object identifiers
      4. Name forms
      5. Name constraints
      6. Certificate policy object identifier
      7. Usage of Policy Constraints extension
      8. Policy qualifiers syntax and semantics
      9. Processing semantics for the critical Certificate Policies extension
    2. CRL profile
      1. Version number(s)
      2. CRL and CRL entry extensions
    3. OCSP profile
      1. Version number(s)
      2. OCSP extensions

  8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS

    1. Frequency or circumstances of assessment
    2. Identity/qualifications of assessor
    3. Assessor’s relationship to assessed entity
    4. Topics covered by assessment
    5. Actions taken as a result of deficiency
    6. Communication of results

  9. OTHER BUSINESS AND LEGAL MATTERS

    1. Fees
      1. Certificate issuance or renewal fees
      2. Certificate access fees
      3. Revocation or status information access fees
      4. Fees for other services
      5. Refund policy
    2. Financial responsibility
      1. Insurance coverage
      2. Other assets
      3. Insurance or warranty coverage for end-entities
    3. Confidentiality of business information
      1. Scope of confidential information
      2. Information not within the scope of confidential information
      3. Responsibility to protect confidential information
    4. Privacy of personal information
      1. Privacy plan
      2. Information treated as private
      3. Information not deemed private
      4. Responsibility to protect private information
      5. Notice and consent to use private information
      6. Disclosure pursuant to judicial or administrative process
      7. Other information disclosure circumstances
    5. Intellectual property rights
    6. Representations and warranties
      1. CA representations and warranties
      2. RA representations and warranties
      3. Subscriber representations and warranties
      4. Relying party representations and warranties
      5. Representations and warranties of other participants
    7. Disclaimers of warranties
    8. Limitations of liability
    9. Indemnities
    10. Term and termination
      1. Term
      2. Termination
      3. Effect of termination and survival
    11. Individual notices and communications with participants
    12. Amendments
      1. Procedure for amendment
      2. Notification mechanism and period
      3. Circumstances under which OID must be changed
    13. Dispute resolution provisions
    14. Governing law
    15. Compliance with applicable law
    16. Miscellaneous provisions
      1. Entire agreement
      2. Assignment
      3. Severability
      4. Enforcement (attorneys’ fees and waiver of rights)
      5. Force Majeure
    17. Other provisions

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

In creating reliable and manageable digital evidence it is necessary to have an agreed upon method of associating time data to transaction so that they might be compared to each other at a later time. The quality of this evidence is based on creating and managing the data structure that represent the events and the quality of the parametric data points that anchor them to the real world. In this instance this being the time data and how it was applied.

A typical transaction is a digitally signed document, where it is necessary to prove that the digital signature from the signer was applied when the signer’s certificate was valid.

A timestamp or a time mark (which is an audit record kept in a secure audit trail from a trusted third party) applied to a digital signature value proves that the digital signature was created before the date included in the time-stamp or time mark.

To prove the digital signature was generated while the signer’s certificate was valid, the digital signature must be verified and the following conditions satisfied:

  1. the time-stamp (or time mark) was applied before the end of the validity period of the signer’s certificate,
  2. the time-stamp (or time mark) was applied either while the signer’s certificate was not revoked or before the revocation date of the certificate.

The electronic time stamp is gaining interest from the business sector as an important component of electronic signatures. It is also featured by the ETSI Electronic Signature Format standard (TS 101 733) or Electronic Signature Formats for long term electronic signatures (RFC 3126), built upon the Time-Stamp Protocol (RFC 3161). Agreed minimum security and quality requirements are necessary in order to ensure trustworthy validation of long-term electronic signatures.

The European Directive 1999/93/EC defines certification service provider as "an entity or a legal or natural person who issues certificates or provides other services related to electronic signatures". One example of a certification-service-provider is a Time-Stamping Authority.

7.1. Time-Stamp Token

The TSA shall ensure that time-stamp tokens are issued securely and include the correct time. In particular:

  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.

    NOTE: The Bureau International des Poids et Mesures (BIPM) computes UTC on the basis of its local representations UTC(k) from a large ensemble of atomic clocks in national metrology institutes and national astronomical observatories round the world. The BIPM disseminates UTC through its monthly Circular T. This is available on the BIPM website (www.bipm.org) and it officially identifies all those institutes having recognized UTC(k) time scales.

  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.

    NOTE: A protocol for a time-stamp token is defined in RFC 3631 and profiled in TS 101 861.

    NOTE: In the case of a number of requests at approximately the same time, the ordering of the time within the accuracy of the TSU clock is not mandated.

  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.

A time-stamping service supports assertions of proof that a datum existed before a particular time. A TSA may be operated as a Trusted Third Party (TTP) service, though other operational models may be appropriate, e.g., an organization might require a TSA for internal time-stamping purposes.

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.

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 }

The messageImprint field SHOULD contain the hash of the datum to be time-stamped. The hash is represented as an OCTET STRING. Its length MUST match the length of the hash value for that algorithm (e.g., 20 bytes for SHA-1 or 16 bytes for MD5).

The reqPolicy field, if included, indicates the TSA policy under which the TimeStampToken SHOULD be provided.

The nonce, if included, allows the client to verify the timeliness of the response when no local clock is available. The nonce is a large random number with a high probability that the client generates it only once (e.g., a 64 bit integer). In such a case the same nonce value MUST be included in the response, otherwise the response shall be rejected.

If the certReq field is present and set to true, the TSA’s public key certificate that is referenced by the ESSCertID identifier inside a SigningCertificate attribute in the response MUST be provided by the TSA in the certificates field from the SignedData structure in that response. That field may also contain other certificates.

If the certReq field is missing or if the certReq field is present and set to false then the certificates field from the SignedData structure MUST not be present in the response.

The time-stamp request does not identify the requester, as this information is not validated by the TSA. In situations where the TSA requires the identity of the requesting entity, alternate identification/authentication means have to be used.

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 }

When the status contains the value zero or one, a TimeStampToken MUST be present. When status contains a value other than zero or one, a TimeStampToken MUST NOT be present. One of the following values MUST be contained in status: 

   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)

Version Name Comments
PKCS#1 2.1 RSA Cryptography Standard See RFC 3447. Defines the format of RSA encryption.
PKCS#3 1.4 Diffie-Hellman Key Agreement Standard A cryptographic protocol that allows two parties that have no prior knowledge of each other to jointly establish a shared secret key over an insecure communications channel.
PKCS#5 2.0 Password-based Encryption Standard See RFC 2898 and PBKDF2.
PKCS#6 1.5 Extended-Certificate Syntax Standard Defines extensions to the old v1 X.509 certificate specification. Obsoleted by v3 of the same.
PKCS#7 1.5 Cryptographic Message Syntax Standard See RFC 2315. Used to sign and/or encrypt messages under a PKI. Used also for certificate dissemination (for instance as a response to a PKCS#10 message). Formed the basis for S/MIME, which is now based on RFC 3852, an updated Cryptographic Message Syntax Standard (CMS).
PKCS#8 1.2 Private-Key Information Syntax Standard
PKCS#9 2.0 Selected Attribute Types Defines selected attribute types for use in PKCS #6 extended certificates, PKCS #7 digitally signed messages, PKCS #8 private-key information, and PKCS #10 certificate-signing requests.
PKCS#10 1.7 Certification Request Standard See RFC 2986. Format of messages sent to a certification authority to request certification of a public key. See certificate signing request.
PKCS#11 2.20 Cryptographic Token Interface (Cryptoki) An API defining a generic interface to cryptographic tokens (see also Hardware Security Module).
PKCS#12 1.0 Personal Information Exchange Syntax Standard Defines a file format commonly used to store private keys with accompanying public key certificates, protected with a password-based symmetric key.
PKCS#13 – Elliptic Curve Cryptography Standard (Under development)
PKCS#14 – Pseudo-random Number Generation (Under development)
PKCS#15 1.1 Cryptographic Token Information Format Standard Defines a standard allowing users of cryptographic tokens to identify themselves to applications, independent of the application's Cryptoki implementation (PKCS #11) or other API. RSA has relinquished IC-card-related parts of this standard to ISO/IEC 7816-15.[1]

9. Bibliographic references