RFC 3126
Electronic Signature Formats for long term electronic signatures
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
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
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
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 841. 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].
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.
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.
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 certificates2.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.
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;
* 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).
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
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.
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.
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 22.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.
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.
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.
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.
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)
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:
+----------------------------------------------------- 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
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)
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)
