Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3126

Electronic Signature Formats for long term electronic signatures

Pages: 84
Obsoleted by:  5126
Part 1 of 3 – Pages 1 to 21
None   None   Next

ToP   noToC   RFC3126 - Page 1
Network Working Group                                          D. Pinkas
Request for Comments: 3126                                      Integris
Category: Informational                                          J. Ross
                                                                 N. Pope
                                                    Security & Standards
                                                          September 2001


                      Electronic Signature Formats
                  for long term electronic signatures

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

This document defines the format of an electronic signature that can remain valid over long periods. This includes evidence as to its validity even if the signer or verifying party later attempts to deny (i.e., repudiates the validity of the signature). The format can be considered as an extension to RFC 2630 and RFC 2634, where, when appropriate additional signed and unsigned attributes have been defined. The contents of this Informational RFC is technically equivalent to ETSI TS 101 733 V.1.2.2. The ETSI TS is under the ETSI Copyright (C). Individual copies of this ETSI deliverable can be downloaded from http://www.etsi.org
ToP   noToC   RFC3126 - Page 2

Table of Contents

1. Introduction 4 2 Overview 5 2.1 Aim 5 2.2 Basis of Present Document 5 2.3 Major Parties 6 2.4 Electronic Signatures and Validation Data 7 2.5 Forms of Validation Data 8 2.6 Extended Forms of Validation Data 11 2.7 Archive Validation Data 13 2.8 Arbitration 15 2.9 Validation Process 15 2.10 Example Validation Sequence 16 2.11 Additional optional features 21 3. Data structure of an Electronic Signature 22 3.1 General Syntax 22 3.2 Data Content Type 22 3.3 Signed-data Content Type 22 3.4 SignedData Type 22 3.5 EncapsulatedContentInfo Type 23 3.6 SignerInfo Type 23 3.6.1 Message Digest Calculation Process 23 3.6.2 Message Signature Generation Process 24 3.6.3 Message Signature Verification Process 24 3.7 CMS Imported Mandatory Present Attributes 24 3.7.1 Content Type 24 3.7.2 Message Digest 24 3.7.3 Signing Time 24 3.8 Alternative Signing Certificate Attributes 24 3.8.1 ESS Signing Certificate Attribute Definition 25 3.8.2 Other Signing Certificate Attribute Definition 25 3.9 Additional Mandatory Attributes 26 3.9.1 Signature policy Identifier 26 3.10 CMS Imported Optional Attributes 28 3.10.1 Countersignature 29 3.11 ESS Imported Optional Attributes 29 3.11.1 Content Reference Attribute 29 3.11.2 Content Identifier Attribute 29 3.11.3 Content Hints Attribute 29 3.12 Additional Optional Attributes 30 3.12.1 Commitment Type Indication Attribute 30 3.12.2 Signer Location attribute 32 3.12.3 Signer Attributes attribute 33 3.12.4 Content Time-Stamp attribute 34 3.13 Support for Multiple Signatures 34 3.13.1 Independent Signatures 34 3.13.2 Embedded Signatures 34
ToP   noToC   RFC3126 - Page 3
   4.  Validation Data                                                35
   4.1  Electronic Signature Time-Stamp                               36
   4.1.1  Signature Time-Stamp Attribute Definition                   36
   4.2  Complete Validation Data                                      37
   4.2.1  Complete Certificate Refs Attribute Definition              38
   4.2.2  Complete Revocation Refs Attribute Definition               38
   4.3  Extended Validation Data                                      40
   4.3.1  Certificate Values Attribute Definition                     40
   4.3.2  Revocation Values Attribute Definition                      41
   4.3.3  ES-C Time-Stamp Attribute Definition                        42
   4.3.4  Time-Stamped Certificates and CRLs Attribute Definition     42
   4.4  Archive Validation Data                                       43
   4.4.1  Archive Time-Stamp Attribute Definition                     43
   5.  Security Considerations                                        44
   5.1  Protection of Private Key                                     44
   5.2  Choice of Algorithms                                          44
   6.  Conformance Requirements                                       45
   6.1  Signer                                                        45
   6.2  Verifier using time-stamping                                  46
   6.3  Verifier using secure records                                 46
   7. References                                                      47
   8. Authors' Addresses                                              48
   Annex A (normative): ASN.1 Definitions                             49
   A.1  Definitions Using X.208 (1988) ASN.1 Syntax                   49
   A.2  Definitions Using X.680 1997 ASN.1 Syntax                     57
   Annex B (informative): General Description                         66
   B.1  The Signature Policy                                          66
   B.2  Signed Information                                            67
   B.3  Components of an Electronic Signature                         68
   B.3.1  Reference to the Signature Policy                           68
   B.3.2  Commitment Type Indication                                  69
   B.3.3  Certificate Identifier from the Signer                      69
   B.3.4.  Role Attributes                                            70
   B.3.4.1  Claimed Role                                              71
   B.3.4.2  Certified Role                                            71
   B.3.5  Signer Location                                             72
   B.3.6  Signing Time                                                72
   B.3.7  Content Format                                              73
   B.4  Components of Validation Data                                 73
   B.4.1  Revocation Status Information                               73
   B.4.2  CRL Information                                             74
   B.4.3  OCSP Information                                            74
   B.4.4  Certification Path                                          75
   B.4.5  Time-Stamping for Long Life of Signature                    76
   B.4.6  Time-Stamping before CA Key Compromises                     77
   B.4.6.1  Time-Stamping the ES with Complete validation data        77
   B.4.6.2  Time-Stamping Certificates and Revocation Information     78
   B.4.7  Time-Stamping for Long Life of Signature                    79
ToP   noToC   RFC3126 - Page 4
   B.4.8  Reference to Additional Data                                80
   B.4.9  Time-Stamping for Mutual Recognition                        80
   B.4.10  TSA Key Compromise                                         81
   B.5  Multiple Signatures                                           81
   Annex C (informative):  Identifiers and roles                      82
   C.1  Signer Name Forms                                             82
   C.2  TSP Name Forms                                                82
   C.3  Roles and Signer Attributes                                   83
   Full Copyright Statement                                           84

1. Introduction

This document is intended to cover electronic signatures for various types of transactions, including business transactions (e.g., purchase requisition, contract, and invoice applications) where long term validity of such signatures is important. This includes evidence as to its validity even if the signer or verifying party later attempts to deny (i.e., repudiates, see [ISONR]) the validity of the signature). Electronic signatures can be used for any transaction between an individual and a company, between two companies, between an individual and a governmental body, etc. This document is independent of any environment. It can be applied to any environment e.g., smart cards, GSM SIM cards, special programs for electronic signatures etc. An electronic signature produced in accordance with this document provides evidence that can be processed to get confidence that some commitment has been explicitly endorsed under a signature policy, at a given time, by a signer under an identifier, e.g., a name or a pseudonym, and optionally a role. The European Directive on a community framework for Electronic Signatures defines an electronic signature as: "data in electronic form which is attached to or logically associated with other electronic data and which serves as a method of authentication". An electronic signature as used in the current document is a form of advanced electronic signature as defined in the Directive. The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase, as shown) are to be interpreted as described in [RFC2119].
ToP   noToC   RFC3126 - Page 5

2 Overview

2.1 Aim

The aim of this document is to define an Electronic Signature (ES) that remains valid over long periods. This includes evidence as to its validity even if the signer or verifying party later attempts to deny (repudiates) the validity of the signature. This document specifies the use of trusted service providers (e.g., Time-Stamping Authorities (TSA)), and the data that needs to be archived (e.g., cross certificates and revocation lists) to meet the requirements of long term electronic signatures. An electronic signature defined by this document can be used for arbitration in case of a dispute between the signer and verifier, which may occur at some later time, even years later. This document uses a signature policy, referenced by the signer, as the basis for establishing the validity of an electronic signature.

2.2 Basis of Present Document

This document is based on the use of public key cryptography to produce digital signatures, supported by public key certificates. A Public key certificate is a public keys of a user, together with some other information, rendered unforgeable by encipherment with the private key of the Certification Authority (CA) which issued it (ITU-T Recommendation X.509 [1]). This document also specifies the uses of time-stamping services to prove the validity of a signature long after the normal lifetime of critical elements of an electronic signature and to support non- repudiation. It also, as an option, defines the use of additional time-stamps to provide very long-term protection against key compromise or weakened algorithms. This document builds on existing standards that are widely adopted. This includes: * RFC 2459 [RFC2459] Internet X.509 Public Key Infrastructure Certificate and CRL Profile (PKIX); * RFC 2630 [CMS] Crytographic Message Syntax (CMS); * RFC 2634 [ESS] Enhanced Security Services (ESS); * RFC 2439 [OCSP] One-line Certificate Status Protocol (OCSP); * ITU-T Recommendation X.509 [1] Authentication framework; * RFC (to be published) [TSP] PKIX Time Stamping protocol (TSP). NOTE: See clause 8 for a full set of references.
ToP   noToC   RFC3126 - Page 6

2.3 Major Parties

The following are the major parties involved in a business transaction supported by electronic signatures as defined in this document: * the Signer; * the Verifier; * the Arbitrator; * Trusted Service Providers (TSP). A Signer is an entity that initially creates the electronic signature. When the signer digitally signs over data using the prescribed format, this represents a commitment on behalf of the signing entity to the data being signed. A verifier is an entity that verifies an evidence. (ISO/IEC 13888-1 [13]). Within the context of this document this is an entity that validates an electronic signature. An arbitrator, is an entity which arbitrates disputes between a signer and a verifier when there is a disagreement on the validity of a digital signature. Trusted Service Providers (TSPs) are one or more entities that help to build trust relationships between the signer and verifier. Use of some specific TSP services MAY be mandated by signature policy. TSP supporting services may provide the following information: user certificates, cross-certificates, time-stamping tokens, CRLs, ARLs, OCSP responses. The following TSPs are used to support the validation or the verification of electronic signatures: * Certification Authorities; * Registration Authorities; * Repository Authorities (e.g., a Directory); * Time-Stamping Authorities; * One-line Certificate Status Protocol responders; * Attribute Authorities; * Signature Policy Issuers. Certification Authorities provide users with public key certificates. Registration Authorities allows the registration of entities before a CA generates certificates.
ToP   noToC   RFC3126 - Page 7
   Repository Authorities publish CRLs issued by CAs, cross-certificates
   (i.e., CA certificates) issued by CAs, signature policies issued by
   Signature Policy Issuers and optionally public key certificates
   (i.e., leaf certificates) issued by CAs.

   Time-Stamping Authorities attest that some data was formed before a
   given trusted time.

   One-line Certificate Status Protocol responders (OSCP responders)
   provide information about the status (i.e., revoked, not revoked,
   unknown) of a particular certificate.

   A Signature Policy Issuer issues signatures policies that define the
   technical and procedural requirements for electronic signature
   creation, validation and verification, in order to meet a particular
   business need.

   Attributes Authorities provide users with attributes linked to public
   key certificates

2.4 Electronic Signatures and Validation Data

Validation of an electronic signature in accordance with this document requires: * The electronic signature; this includes: - the signature policy; - the signed user data; - the digital signature; - other signed attributes provided by the signer; - other unsigned attributes provided by the signer. Validation data which is the additional data needed to validate the electronic signature; this includes: - certificates references; - certificates; - revocation status information references; - revocation status information; - time-stamps from Time Stamping Authorities (TSAs). * The signature policy specifies the technical requirements on signature creation and validation in order to meet a particular business need. A given legal/contractual context may recognize a particular signature policy as meeting its requirements.
ToP   noToC   RFC3126 - Page 8
   For example: a specific signature policy may be recognized by court
   of law as meeting the requirements of the European Directive for
   electronic commerce.  A signature policy may be written using a
   formal notation like ASN.1 or in an informal free text form provided
   the rules of the policy are clearly identified.  However, for a given
   signature policy there shall be one definitive form which has a
   unique binary encoded value.

   Signed user data is the user's data that is signed.

   The Digital Signature is the digital signature applied over the
   following attributes provided by the signer:

      *  hash of the user data (message digest);
      *  signature Policy Identifier;
      *  other signed attributes

   The other signed attributes include any additional information which
   must be signed to conform to the signature policy or this document
   (e.g., signing time).

   According to the requirements of a specific signature policy in use,
   various Validation Data shall be collected and attached to or
   associated with the signature structure by the signer and/or the
   verifier.  The validation data includes CA certificates as well as
   revocation status information in the form of certificate revocation
   lists (CRLs) or certificate status information provided by an on-line
   service.  Additional data also includes time-stamps and other time
   related data used to provide evidence of the timing of given events.
   It is required, as a minimum, that either the signer or verifier
   obtains a time-stamp over the signer's signature or a secure time
   record of the electronic signature must be maintained.  Such secure
   records must not be undetectably modified and must record the time
   close to when the signature was first validated.

2.5 Forms of Validation Data

An electronic signature may exist in many forms including: * the Electronic Signature (ES), which includes the digital signature and other basic information provided by the signer; * the ES with Time-Stamp (ES-T), which adds a time-stamp to the Electronic Signature, to take initial steps towards providing long term validity;
ToP   noToC   RFC3126 - Page 9
      *  the ES with Complete validation data (ES-C), which adds to the
         ES-T references to the complete set of data supporting the
         validity of the electronic signature (i.e., revocation status
         information).

   The signer must provide at least the ES form, but in some cases may
   decide to provide the ES-T form and in the extreme case could provide
   the ES-C form.  If the signer does not provide ES-T, the verifier
   must either create the ES-T on first receipt of an electronic
   signature or shall keep a secure time record of the ES.  Either of
   these two approaches provide independent evidence of the existence of
   the signature at the time it was first verified which should be near
   the time it was created, and so protects against later repudiation of
   the existence of the signature.  If the signer does not provide ES-C
   the verifier must create the ES-C when the complete set of revocation
   and other validation data is available.

   The ES satisfies the legal requirements for electronic signatures as
   defined in the European Directive on electronic signatures, see Annex
   C for further discussion on relationship of this document to the
   Directive.  It provides basic authentication and integrity protection
   and can be created without accessing on-line (time-stamping)
   services. However, without the addition of a time-stamp or a secure
   time record the electronic signature does not protect against the
   threat that the signer later denies having created the electronic
   signature (i.e., does not provide non-repudiation of its existence).

   The ES-T time-stamp or time record should be created close to the
   time that ES was created to provide protection against repudiation.
   At this time all the data needed to complete the validation may not
   be available but what information is readily available may be used to
   carry out some of the initial checks.  For example, only part of the
   revocation information may be available for verification at that
   point in time.  Generally, the ES-C form cannot be created at the
   same time as the ES, as it is necessary to allow time for any
   revocation information to be captured.  Also, if a certificate is
   found to be temporarily suspended, it will be necessary to wait until
   the end of the suspension period.

   The signer should only create the ES-C in situations where it was
   prepared to wait for a sufficient length of time after creating the
   ES form before dispatching the ES-C.  This, however, has the
   advantage that the verifier can be presented with the complete set of
   data supporting the validity of the ES.

   Support for ES-C by the verifier is mandated (see clause 6 for
   specific conformance requirements).
ToP   noToC   RFC3126 - Page 10
   An Electronic Signature (ES), with the additional validation data
   forming the ES-T and ES-C is illustrated in Figure 1:

+------------------------------------------------------------ES-C-----+
|+--------------------------------------------ES-T-----+              |
||+------Elect.Signature (ES)----------+ +------------+| +-----------+|
|||+---------+ +----------+ +---------+| |Time-Stamp  || |Complete   ||
||||Signature| |  Other   | | Digital || |over digital|| |certificate||
||||Policy ID| |  Signed  | |Signature|| |signature   || |and        ||
||||         | |Attributes| |         || +------------+| |revocation ||
|||+---------+ +----------+ +---------+|               | |references ||
||+------------------------------------+               | +-----------+|
|+-----------------------------------------------------+              |
+---------------------------------------------------------------------+

         Figure 1: Illustration of an ES, ES-T and ES-C

   The verifiers conformance requirements of an ES with a time-stamp of
   the digital signature is defined in subclause 6.2.

   The ES on its own satisfies the legal requirements for electronic
   signatures as defined in the European Directive on electronic
   signatures.  The signers conformance requirements of an ES are
   defined in subclause 6.1, and are met using a structure as indicated
   in figure 2:

               +------Elect.Signature (ES)-----------|
               |+---------+ +----------+ +---------+ |
               ||Signature| |  Other   | | Digital | |
               ||Policy ID| |  Signed  | |Signature| |
               ||         | |Attributes| |         | |
               |+---------+ +----------+ +---------+ |
               |+-----------------------------------+|

                  Figure 2: Illustration of an ES
ToP   noToC   RFC3126 - Page 11
   Where there are requirements for long term signatures without time-
   stamping the digital signature, then a secure record is needed of the
   time of verification in association with the electronic signature
   (i.e., both must be securely recorded).  In addition the certificates
   and revocation information used at the time of verification should to
   be recorded as indicated in figure 3 as an ES-C(bis).

   +-------------------------------------------------------ES-C-----+
   |                                                                |
   | +------Elect.Signature (ES)----------+|           +-----------+|
   | |+---------+ +----------+ +---------+||           |Complete   ||
   | ||Signature| |  Other   | | Digital |||           |certificate||
   | ||Policy ID| |  Signed  | |Signature|||           |and        ||
   | ||         | |Attributes| |         |||           |revocation ||
   | |+---------+ +----------+ +---------+||           |references ||
   | +------------------------------------+|           +-----------+|
   |                                                                |
   +----------------------------------------------------------------+

                Figure 3: Illustration of an ES-C(bis)

   The verifiers conformance requirements of an ES-C(bis) is defined in
   subclause 6.3.

   Note: A time-stamp attached to the electronic signature or a secure
   time record helps to protect the validity of the signature even if
   some of the verification data associated with the signature become
   compromised AFTER the signature was generated.  The time-stamp or a
   secure time record provides evidence that the signature was generated
   BEFORE the event of compromise; hence the signature will maintain its
   validity status.

2.6 Extended Forms of Validation Data

The complete validation data (ES-C) described above may be extended to form an ES with eXtended validation data (ES-X) to meet following additional requirements. Firstly, when the verifier does not has access to, * the signer's certificate, * all the CA certificates that make up the full certification path, * all the associated revocation status information, as referenced in the ES-C.
ToP   noToC   RFC3126 - Page 12
   then the values of these certificates and revocation information may
   be added to the ES-C.  This form of extended validation data is
   called a X-Long.

   Secondly, if there is a risk that any CA keys used in the certificate
   chain may be compromised, then it is necessary to additionally time-
   stamp the validation data by either:

      *  time-stamping all the validation data as held with the ES(ES-
         C), this eXtended validation data is called a Type 1 X-Time-
         Stamp; or
      *  time-stamping individual reference data as used for complete
         validation.

   This form of eXtended validation data is called a Type 2 X-Time-
   Stamp.

   NOTE:  The advantages/drawbacks for Type 1 and Type 2 X-Time-Stamp
   are discussed in this document (see clause B.4.6.)

   If all the above conditions occur then a combination of the two
   formats above may be used.  This form of eXtended validation data is
   called a X-Long-Time-Stamped.

   Support for the extended forms of validation data is optional.

   An Electronic Signature (ES) , with the additional validation data
   forming the ES-X long is illustrated in Figure 4:

  +-------------------------------------------------------- ES-X Long--+
  |+---------------------------------------- EC-C --------+            |
  ||+---- Elect.Signature (ES)----+             +--------+| +--------+ |
  |||+-------+-+-------+-+-------+| +----------+|Complete|| |Complete| |
  ||||Signa- | |Other  | |Digital|| |Time-Stamp||certi-  || |certi-  | |
  ||||ture   | |Signed | |Signa- || |over      ||ficate  || |ficate  | |
  ||||Policy | |Attri- | |ture   || |digital   ||and     || |and     | |
  ||||ID     | |butes  | |       || |signature ||revoc.  || |revoc.  | |
  |||+-------+ +-------+ +-------+| +----------+|refs    || |data    | |
  ||+-----------------------------+             +--------+| +--------+ |
  |+------------------------------------------------------+            |
  +--------------------------------------------------------------------+

          Figure 4: Illustration of an ES and ES-X long.
ToP   noToC   RFC3126 - Page 13
   An Electronic Signature (ES) , with the additional validation data
   forming the eXtended Validation Data - Type 1 is illustrated in
   Figure 5:

  +----------------------------------------------------------- ES-X 1 -+
  |+----------------------------------------- EC-C --------+           |
  || +---- Elect.Signature (ES)----+             +--------+| +-------+ |
  || |+-------+ +-------+ +-------+| +----------+|Complete|| |       | |
  || ||Signa- | |Other  | |Digital|| |Time-Stamp||certifi-|| | Time- | |
  || ||ture   | |Signed | |Signa- || |over      ||cate and|| | stamp | |
  || ||Policy | |Attri- | |ture   || |digital   ||revoc.  || | over  | |
  || ||ID     | |butes  | |       || |signature ||refs    || | CES   | |
  || |+-------+ +-------+ +-------+| +----------+|        || |       | |
  || +-----------------------------+             +--------+| +-------+ |
  |+-------------------------------------------------------+           |
  +--------------------------------------------------------------------+

          Figure 5: Illustration of ES with ES-X Type 1

   An Electronic Signature (ES) , with the additional validation data
   forming the eXtended Validation Data - Type 2 is illustrated in
   Figure 6:

  +--------------------------------------------------------- ES-X 2 ---+
  |+---------------------------------------- EC-C --------+            |
  ||+---- Elect.Signature (ES)----+             +--------+| +--------+ |
  |||+-------+ +-------+ +-------+| +----------+|Complete|| |Times   | |
  ||||Signa- | |Other  | |Digital|| |Time-Stamp||certs   || |Stamp   | |
  ||||ture   | |Signed | |Signa- || |over      ||and     || |over    | |
  ||||Policy | |Attri- | |ture   || |digital   ||revoc.  || |Complete| |
  ||||ID     | |butes  | |       || |signature ||refs    || |certs   | |
  |||+-------+ +-------+ +-------+| +----------+|        || |and     | |
  ||+-----------------------------+             +--------+| |revoc.  | |
  ||                                                      | |refs    | |
  |+------------------------------------------------------+ +--------+ |
  +--------------------------------------------------------------------+

          Figure 6: Illustration of ES with ES-X Type 2

2.7 Archive Validation Data

Before the algorithms, keys and other cryptographic data used at the time the ES-C was built become weak and the cryptographic functions become vulnerable, or the certificates supporting previous time- stamps expires, the signed data, the ES-C and any additional information (ES-X) should be time-stamped. If possible this should use stronger algorithms (or longer key lengths) than in the original time-stamp.
ToP   noToC   RFC3126 - Page 14
   This additional data and time-stamp is called Archive Validation Data
   (ES-A).  The Time-Stamping process may be repeated every time the
   protection used to time-stamp a previous ES-A become weak.  An ES-A
   may thus bear multiple embedded time stamps.

   An example of an Electronic Signature (ES), with the additional
   validation data for the ES-C and ES-X forming the ES-A is illustrated
   in Figure 7.

         +-------------------------------- ES-A --------- ----------+
         |  +-------------------- ES-A -----------------+           |
         |  |  +--------- ES-X -------------- +         |           |
         |  |  |..............................| +-----+ |  +-----+  |
         |  |  |..............................| |Time | |  |Time |  |
         |  |  |..............................| |Stamp| |  |Stamp|  |
         |  |  |                              | +-----+ |  +-----+  |
         |  |  +----------------------------- +         |           |
         |  +-------------------------------------------+           |
         +----------------------------------------------------------+

                      Figure 7: Illustration of ES -A

   Support for ES-A is optional.
ToP   noToC   RFC3126 - Page 15

2.8 Arbitration

The ES-C may be used for arbitration should there be a dispute between the signer and verifier, provided that: * a copy of the signature policy referenced by the signer is available; * the arbitrator knows where to retrieve the signer's certificate (if not already present), all the cross-certificates and the required CRLs and/or OCSPs responses referenced in the ES-C; * none of the issuing key from the certificate chain have ever been compromised; * the cryptography used at the time the ES-C was built has not been broken at the time the arbitration is performed. When the second condition is not met, then the plaintiff must provide an ES-X Long. When it is known by some external means that the third condition is not met, then the plaintiff must provide an ES-X Time-Stamped. When the two previous conditions are not met, the plaintiff must provide the two above information (i.e., an ES-X Time-Stamped and Long). When the last condition is not met, the plaintiff must provide an ES-A. It should be noticed that a verifier may need to get two time stamps at two different instants of time: one soon after the generation of the ES and one soon after some grace period allowing any entity from the certification chain to declare a key compromise.

2.9 Validation Process

The Validation Process validates an electronic signature in accordance with the requirements of the signature policy. The output status of the validation process can be: * valid; * invalid; * incomplete verification. A Valid response indicates that the signature has passed verification and it complies with the signature validation policy.
ToP   noToC   RFC3126 - Page 16
   A signature validation policy is a part of the signature policy which
   specifies the technical requirements on the signer in creating a
   signature and verifier when validating a signature.

   An Invalid response indicates that either the signature format is
   incorrect or that the digital signature value fails verification
   (e.g., the integrity checks on the digital signature value fails or
   any of the certificates on which the digital signature verification
   depends is known to be invalid or revoked).

   An Incomplete Validation response indicates that the format and
   digital signature verifications have not failed but there is
   insufficient information to determine if the electronic signature is
   valid under the signature policy.  This can include situations where
   additional information, which does not effect the validity of the
   digital signature value, may be available but is invalid.

   In the case of Incomplete Validation, it may be possible to request
   that the electronic signature be checked again at a later date when
   additional validation information might become available.  Also, in
   the case of incomplete validation, additional information may be made
   available to the application or user, thus allowing the application
   or user to decide what to do with partially correct electronic
   signatures.

   The validation process may also output validation data:

      *  a signature time-stamp;
      *  the complete validation data;
      *  the archive validation data.

2.10 Example Validation Sequence

Figure 8, and subsequent description, describes how the validation process may build up a complete electronic signature over time. Soon after receiving the electronic signature (ES) from the signer (1), the digital signature value may be checked, the validation process must at least add a time-stamp (2), unless the signer has provided one which is trusted by the verifier. The validation process may also validate the electronic signature, as required under the identified signature policy, using additional data (e.g., certificates, CRL, etc.) provided by trusted service providers. If the validation process is not complete then the output from this stage is the ES-T.
ToP   noToC   RFC3126 - Page 17
   When all the additional data (e.g., the complete certificate and
   revocation information) necessary to validate the electronic
   signature first becomes available, then the validation process:

      *  obtains all the necessary additional certificate and revocation
         status information;

      *  completes all the validation checks on the ES, using the
         complete certificate and revocation information  (if a time-
         stamp is not already present, this may be added at the same
         stage combining ES-T and ES-C process);

      *  records the complete certificate and revocation references (3);

      *  indicates the validity status to the user (4).

         +----------------------------------------- ES-C ----------+
         |+----------------------------- ES-T --------+            |
         ||+--- Elect.Signature (ES) ----+            | +--------+ |
         |||+-------+ +-------+ +-------+|+----------+| |Complete| |
         ||||Signa- | |Other  | |Digital|||Time-Stamp|| |certifi-| |
         ||||ture   | |Signed | |Signa- |||over      || |cate and| |
         ||||Policy | |Attri- | |ture   |||digital   || |revoca- | |
         ||||ID     | |butes  | |       |||signature || |tion    | |
         |||+-------+ +-------+ +-------+|+----------+| |referen-| |
         ||+------------\----------------+    ^       | |ces     | |
         ||              \                    |       | +--------+ |
         ||               \ 1                /        |      ^     |
         |+----------------\----------------/---------+      |     |
         +------------------\--------------/--------------- /------+
                             \            /2    ----3------/
          +----------+        |          /     /
          | Signed   |\       v         /     |
          |User data | \     +--------------------+     +------------+
          +----------+  \--->| Validation Process |---> |- Valid     |
                             +---|--^-------|--^--+ 4   |- Invalid   |
                                 |  |       |  |        |- Validation|
                                 v  |       v  |        |  Incomplete|
                             +---------+ +--------+     +------------+
                             |Signature| |Trusted |
                             | Policy  | |Service |
                             | Issuer  | |Provider|
                             +---------+ +--------+

   Figure 8: Illustration of an ES with Complete validation data (ES-C)
ToP   noToC   RFC3126 - Page 18
   At the same time as the validation process creates the ES-C, the
   validation process may provide and/or record the values of
   certificates and revocation status information used in ES-C, called
   the ES-X Long (5).  This is illustrated in figure 9:

  +----------------------------------------------------- ES-X ---------+
  |+---------------------------------------- ES-C --------+ +--------+ |
  ||+--- Elect.Signature (ES) ----+            +--------+ | |Complete| |
  |||+-------+ +-------+ +-------+|+----------+|Complete| | |certifi-| |
  ||||Signa- | |Other  | |Digital|||Time-Stamp||certifi-| | |cate    | |
  ||||ture   | |Signed | |Signa- |||over      ||cate and| | |and     | |
  ||||Policy | |Attri- | |ture   |||digital   ||revoca- | | |revoca- | |
  ||||ID     | |butes  | |       |||signature ||tion    | | |tion    | |
  |||+-------+ +---|---+ +-------+|+----------+|referen-| | |Data    | |
  ||+--------------\--------------+    ^       |ces     | | +--------+ |
  ||                \                  |       +--------+ |      ^     |
  ||                 \ 1             2/           ^       |      |     |
  |+------------------\--------------/------------|-------+     /      |
  +--------------------\------------/------------/-------------/-------+
                        \          /    ---3----/             /
   +----------+          |        /    /   ------------5-----/
   | Signed   |\         v       |     |  /
   |User data | \     +--------------------+     +-----------+
   +----------+  \--->| Validation Process |---> | - Valid   |
                      +---|--^-------|--^--+ 4   | - Invalid |
                          |  |       |  |        +-----------+
                          v  |       v  |
                      +---------+ +--------+
                      |Signature| |Trusted |
                      | Policy  | |Service |
                      | Issuer  | |Provider|
                      +---------+ +--------+

    Figure 9: Illustration ES with eXtended validation data (Long)

   When the validation process creates the ES-C it may also create
   extended forms of validation data.  A first alternative is to time-
   stamp all data forming the Type 1 X-Time-Stamp (6).  This is
   illustrated in figure 10:
ToP   noToC   RFC3126 - Page 19
   +----------------------------------------------------- ES-X -------+
   |+---------------------------------------- ES-C --------+ +------+ |
   ||+--- Elect.Signature (ES) ----+            +--------+ | |Time- | |
   |||+-------+ +-------+ +-------+|+----------+|Complete| | |Stamp | |
   ||||Signa- | |Other  | |Digital|||Time-Stamp||certifi-| | |over  | |
   ||||ture   | |Signed | |Signa- |||over      ||cate and| | |CES   | |
   ||||Policy | |Attri- | |ture   |||digital   ||revoca- | | +------+ |
   ||||ID     | |butes  | |       |||signature ||tion    | |     ^    |
   |||+-------+ +--|----+ +-------+|+----------+|referen-| |     |    |
   ||+-------------|---------------+     ^      |ces     | |     |    |
   ||              |                     |      +--------+ |     |    |
   ||               \ 1                 2/         ^       |     |    |
   |+----------------\------------------/----------|-------+     |    |
   +------------------\----------------/-----------/-------------/----+
                       \              /   ----3---/             /
    +----------+        |            /   /  ---------------6---/
    | Signed   |\       v           |   |  /
    |User data | \     +--------------------+     +-----------+
    +----------+  \--->| Validation Process |---> | - Valid   |
                       +---|--^-------|--^--+ 4   | - Invalid |
                           |  |       |  |        +-----------+
                           v  |       v  |
                       +---------+ +--------+
                       |Signature| |Trusted |
                       | Policy  | |Service |
                       | Issuer  | |Provider|
                       +---------+ +--------+

      Figure 10: Illustration of ES with eXtended validation data -
                 Type 1 X-Time-Stamp
ToP   noToC   RFC3126 - Page 20
   Another alternative is to time-stamp the certificate and revocation
   information references used to validate the electronic signature (but
   not the signature) (6'); this is called Type 2 X-Time-Stamped.  This
   is illustrated in figure 11:

  +----------------------------------------------------- ES-X -----------+
  |+---------------------------------------- ES-C --------+ +----------+ |
  ||+--- Elect.Signature (ES) ----+            +--------+ | |Time-Stamp| |
  |||+-------+ +-------+ +-------+|+----------+|Complete| | |over      | |
  ||||Signa- | |Other  | |Digital|||Time-Stamp||certifi-| | |Complete  | |
  ||||ture   | |Signed | |Signa- |||over      ||cate and| | |Certifi-  | |
  ||||Policy | |Attri- | |ture   |||digital   ||revoc.  | | |cate and  | |
  ||||ID     | |butes  | |       |||signature ||refs    | | |revoc.    | |
  |||+-------+ +---^---+ +-------+|+----^-----++---^----+ | |refs      | |
  ||+--------------\--------------+     |          |      | +----------+ |
  |+----------------\------------------/-----------|------+      ^       |
  +----------------1-\----------------/-----------/--------------|-------+
                      \              /  -----3---/               |
   +----------+        |           2/  /   ---------------6'-----/
   | Signed   |\       v           |  |   /
   |User data | \     +--------------------+     +-----------+
   +----------+  \--->| Validation Process |---> | - Valid   |
                      +---|--^-------|--^--+ 4   | - Invalid |
                          |  |       |  |        +-----------+
                          v  |       v  |
                      +---------+ +--------+
                      |Signature| |Trusted |
                      | Policy  | |Service |
                      | Issuer  | |Provider|
                      +---------+ +--------+

    Figure 11: Illustration of ES with eXtended validation data -
               Type 2 X-Time-Stamp

   Before the algorithms used in any of electronic signatures become or
   are likely, to be compromised or rendered vulnerable in the future,
   it is necessary to time-stamp the entire electronic signature,
   including all the values of the validation and user data as an ES
   with Archive validation data (ES-A)
ToP   noToC   RFC3126 - Page 21
   An ES-A is illustrated in figure 12:

-------------------------------------------- ES-A --------------------+
----------------------------------------------------------------+     |
+------------------------------- EC-C --------++-----+          |     |
|                                             ||Time-|          |     |
|+-- Elect.Signature (ES) -+        +--------+||Stamp|  +-------+     |
||+------++-------++-------|+------+|Complete|||over |  Complete|     |
|||Signa-||Other  ||Digital||Time- ||certifi-|||CES  |  |certi- |+----|
|||ture  ||Signed ||Signa- ||Stamp ||cate and||+-----+  |ficate |Arch-|
|||Policy||Attri- ||ture   ||over  ||revoca- ||+------+ |and    |ive  |
|||ID    ||butes  ||       ||digit.||tion    |||Time- | |revoca-|Time |
||+------++---|---++-------||signa-||referen-|||Stamp-| |tion   |stamp|
|+------------|------------+|ture  ||ces     |||over  | |data   |+----|
|             |             +------++--------+|Complete\+-------+  ^  |
|             |                ^         ^    ||cert.  |        |  |  |
+-------------|----------------|---------|----+|and rev|        |  |  |
               \               |         /     |refs.  |        |  |  |
                \              |        /      +-------+        |  |  |
-----------------\-------------|-------/------------------------+  |  |
+----------+      \            |      /                            /  |
| Signed   |       \2          |3    /     /--------------7-------/   |
|User data |        \          |    |     /                           |
+-------\--+         \         |    |    /                            |
---------\------------|--------|----|---/-----------------------------+
          \           v        |    |   |
          1\        +--------------------+     +-----------+
            \------>| Validation Process |---> | - Valid   |
                    +---|--^-------|--^--+ 4   | - Invalid |
                        |  |       |  |        +-----------+
                        v  |       v  |
                    +---------+ +--------+
                    |Signature| |Trusted |
                    | Policy  | |Service |
                    | Issuer  | |Provider|
                    +---------+ +--------+

   Figure 12: Illustration of an ES with Archive validation data (ES-A)

2.11 Additional optional features of an ES

This document also defines additional optional features of an electronic signature to: * indicate a commitment type being made by the signer; * indicate the role under which a signature was created; * support multiple signatures.


(next page on part 2)

Next Section