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 RFC2630 and RFC
2634, where, when appropriate additional signed and unsigned
attributes have been defined.
The contents of this Informational RFCis 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 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].
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:
* RFC2459 [RFC2459] Internet X.509 Public Key Infrastructure
Certificate and CRL Profile (PKIX);
* RFC2630 [CMS] Crytographic Message Syntax (CMS);
* RFC2634 [ESS] Enhanced Security Services (ESS);
* RFC2439 [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 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.
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 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.
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.
3. Data structure of an Electronic Signature
This clause uses and builds upon the Cryptographic Message Syntax
(CMS), as defined in RFC2630 [CMS], and Enhanced Security Services
(ESS), as defined in RFC2634 [ESS]. The overall structure of
Electronic Signature is as defined in [CMS]. The Electronic
Signature (ES) uses attributes defined in [CMS], [ESS] and this
document. This document defines in full the ES attributes which it
uses and are not defined elsewhere.
The mandated set of attributes and the digital signature value is
defined as the minimum Electronic Signature (ES) required by this
document. A signature policy MAY mandate other signed attributes to
be present.
3.1 General Syntax
The general syntax of the ES is as defined in [CMS].
3.2 Data Content Type
The data content type of the ES is as defined in [CMS].
The data content type is intended to refer to arbitrary octet
strings, such as ASCII text files; the interpretation is left to the
application. Such strings need not have any internal structure
(although they could have their own ASN.1 definition or other
structure).
3.3 Signed-data Content Type
The Signed-data content type of the ES is as defined in [CMS].
The signed-data content type consists of a content of any type and
zero or more signature values. Any number of signers in parallel can
sign any type of content. The typical application of the signed-data
content type represents one signer's digital signature on content of
the data content type.
To make sure that the verifier uses the right certificate, this
document mandates that the hash of the signers certificate is always
included in the Signing Certificate signed attribute.
3.4 SignedData Type
The syntax of the SignedData type of the ES is as defined in [CMS].
The fields of type SignedData have the meanings defined [CMS] except
that:
* version is the syntax version number. The value of version
must be 3.
* The identification of signer's certificate used to create the
signature is always present as a signed attribute.
* The degenerate case where there are no signers is not valid in
this document.
3.5 EncapsulatedContentInfo Type
The syntax of the EncapsulatedContentInfo a type of the ES is as
defined in [CMS].
For the purpose of long term validation as defined by this document,
it is advisable that either the eContent is present, or the data
which is signed is archived in such as way as to preserve the any
data encoding. It is important that the OCTET STRING used to generate
the signature remains the same every time either the verifier or an
arbitrator validates the signature.
The degenerate case where there are no signers is not valid in this
document.
3.6 SignerInfo Type
The syntax of the SignerInfo a type of the ES is as defined in [CMS].
Per-signer information is represented in the type SignerInfo. In the
case of multiple independent signatures, there is an instance of this
field for each signer.
The fields of type SignerInfo have the meanings defined in [CMS]
except that signedAttributes must, as a minimum, contain the
following attributes:
* ContentType as defined in clause 3.7.1.
* MessageDigest as defined in clause 3.7.2.
* SigningTime as defined in clause 3.7.3.
* SigningCertificate as defined in clause 3.8.1.
* SignaturePolicyId as defined in clause 3.9.1.
3.6.1 Message Digest Calculation Process
The message digest calculation process is as defined in [CMS].
3.6.2 Message Signature Generation Process
The input to the digital signature generation process is as defined
in [CMS].
3.6.3 Message Signature Verification Process
The procedures for CMS signed data validation are as defined in [CMS]
and enhanced in this document.
The input to the signature verification process includes the signer's
public key verified as correct using either the ESS Signing
Certificate attribute or the Other Signing Certificate attribute.
3.7 CMS Imported Mandatory Present Attributes
The following attributes MUST be present with the signed-data defined
by this document. The attributes are defined in [CMS].
3.7.1 Content Type
The syntax of the content-type attribute type of the ES is as defined
in [CMS].
3.7.2 Message Digest
The syntax of the message-digest attribute type of the ES is as
defined in [CMS].
3.7.3 Signing Time
The syntax of the message-digest attribute type of the ES is as
defined in [CMS] and further qualified by this document.
The signing-time attribute type specifies the time at which the
signer claims to have performed the signing process.
This present document recommends the use of GeneralizedTime.
3.8 Alternative Signing Certificate Attributes
One, and only one, of the following two alternative attributes MUST
be present with the signed-data defined by this document to identify
the signing certificate. Both attributes include an identifier and a
hash of the signing certificate. The first, which is adopted in
existing standards, may be only used with the SHA-1 hashing
algorithm. The other shall be used when other hashing algorithms are
to be supported.
The signing certificate attribute is designed to prevent the simple
substitution and re-issue attacks, and to allow for a restricted set
of authorization certificates to be used in verifying a signature.
3.8.1 ESS Signing Certificate Attribute Definition
The syntax of the signing certificate attribute type of the ES is as
defined in [ESS], and further qualified and profile in this document.
The ESS signing certificate attribute must be a signed attribute.
This document mandates the presence of this attribute as a signed CMS
attribute, and the sequence must not be empty. The certificate used
to verify the signature must be identified in the sequence, the
Signature Validation Policy may mandate other certificate references
to be present, that may include all the certificates up to the point
of trust. The encoding of the ESSCertID for this certificate must
include the issuerSerial field.
The issuerAndSerialNumber present in the SignerInfo must be
consistent with issuerSerial field. The certificate identified must
be used during the signature verification process. If the hash of
the certificate does not match the certificate used to verify the
signature, the signature must be considered invalid.
The sequence of policy information field is not used in this
document.
NOTE: Where an attribute certificate is used by the signer to
associate a role, or other attributes of the signer, with the
electronic signature this is placed in the Signer Attribute attribute
as defined in clause 3.12.3.
3.8.2 Other Signing Certificate Attribute Definition
The following attribute is identical to the ESS SigningCertificate
defined above except that this attribute can be used with hashing
algorithms other than SHA-1.
This attribute must be used in the same manner as defined above for
the ESS SigningCertificate attribute.
The following object identifier identifies the signing certificate
attribute:
id-aa-ets-otherSigCert OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-aa(2) 19 }
The signing certificate attribute value has the ASN.1 syntax
OtherSigningCertificate
OtherSigningCertificate ::= SEQUENCE {
certs SEQUENCE OF OtherCertID,
policies SEQUENCE OF PolicyInformation OPTIONAL
-- NOT USED IN THIS DOCUMENT
}
OtherCertID ::= SEQUENCE {
otherCertHash OtherHash,
issuerSerial IssuerSerial OPTIONAL
}
OtherHash ::= CHOICE {
sha1Hash OtherHashValue, -- This contains a SHA-1 hash
otherHash OtherHashAlgAndValue
}
OtherHashValue ::= OCTET STRING
OtherHashAlgAndValue ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
hashValue OtherHashValue
}
3.9 Additional Mandatory Attributes
3.9.1 Signature policy Identifier
This document mandates that a reference to the signature policy, is
included in the signedData, this reference is either explicitly
identified or implied by the semantics of the signed content and
other external data. A signature policy defines the rules for
creation and validation of an electronic signature, is included as a
signed attribute with every signature. The signature policy
identifier must be a signed attribute.
The following object identifier identifies the signature policy
identifier attribute:
id-aa-ets-sigPolicyId OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-aa(2) 15 }
Signature-policy-identifier attribute values have ASN.1 type
SignaturePolicyIdentifier.
SignaturePolicyIdentifier ::= CHOICE{
SignaturePolicyId SignaturePolicyId,
SignaturePolicyImplied SignaturePolicyImplied }