tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 3126


Pages: 84
Top     in Index     Prev     Next
 

Electronic Signature Formats for long term electronic signatures

Part 1 of 3, p. 1 to 21
None       Next RFC Part

Obsoleted by:    5126


Top       ToC       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       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      ToC       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      ToC       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      ToC       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      ToC       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      ToC       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      ToC       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      ToC       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      ToC       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      ToC       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      ToC       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      ToC       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      ToC       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      ToC       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      ToC       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      ToC       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      ToC       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      ToC       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      ToC       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      ToC       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 RFC Part