draft-ietf-smime-esformats-02.txt   draft-ietf-smime-esformats-03.txt 
Internet Draft Electronic Signature Formats
Internet Draft ETSI TC-SEC (ETSI) Internet Draft ETSI TC-SEC (ETSI)
S/MIME Working Group D. Pinkas (Bull) S/MIME Working Group D. Pinkas (Bull)
expires in six months J. Ross (Security & Standards) expires in six months J. Ross (Security & Standards)
Target Category: Informational N. Pope (Security & Standards) Target Category: Informational N. Pope (Security & Standards)
July 2000 November 2000
Electronic Signature Formats Electronic Signature Formats
for long term electronic signatures for long term electronic signatures
<draft-ietf-smime-esformats-02.txt> <draft-ietf-smime-esformats-03.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is NOT offered in This document is an Internet-Draft and is NOT offered in
accordance with section of RFC 2026, and the author does not accordance with section of RFC 2026, and the author does not
provide the IETF with any rights other than to publish as an provide the IETF with any rights other than to publish as an
Internet-Draft. Internet-Draft.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 47 skipping to change at page 1, line 48
The informational RFC defines the format of an electronic signature The informational RFC defines the format of an electronic signature
that can remain valid over long periods. This includes evidence as to that can remain valid over long periods. This includes evidence as to
its validity even if the signer or verifying party later attempts to its validity even if the signer or verifying party later attempts to
deny (i.e. repudiates, see [ISONR]) the validity of the signature. deny (i.e. repudiates, see [ISONR]) the validity of the signature.
The format can be considered as an extension to RFC 2630 [CMS] and RFC The format can be considered as an extension to RFC 2630 [CMS] and RFC
2634 [ESS], where, when appropriate additional signed and unsigned 2634 [ESS], where, when appropriate additional signed and unsigned
attributes have been defined. attributes have been defined.
The contents of this Informational RFC is technically equivalent to The contents of this Informational RFC is technically equivalent to
ETSI ES 201 733 V.1.1.3 Copyright (C). Individual copies of this ETSI TS 101 733 V.1.2.2 Copyright (C). Individual copies of this
ETSI deliverable can be downloaded from http://www.etsi.org ETSI deliverable can be downloaded from http://www.etsi.org
1. Introduction 1. Introduction
This document is intended to cover electronic signatures for various This document is intended to cover electronic signatures for various
types of transactions, including business transactions (e.g. purchase types of transactions, including business transactions (e.g. purchase
requisition, contract, and invoice applications) where long term requisition, contract, and invoice applications) where long term
validity of such signatures is important. validity of such signatures is important.
Internet Draft Electronic Signature Formats Internet Draft Electronic Signature Formats
skipping to change at page 2, line 39 skipping to change at page 2, line 39
TABLE OF CONTENTS TABLE OF CONTENTS
1. Introduction 1 1. Introduction 1
2 Overview 4 2 Overview 4
2.1 Aim 4 2.1 Aim 4
2.2 Basis of Present Document 4 2.2 Basis of Present Document 4
2.3 Major Parties 5 2.3 Major Parties 5
2.4 Electronic Signatures and Validation Data 6 2.4 Electronic Signatures and Validation Data 6
2.5 Forms of Validation Data 7 2.5 Forms of Validation Data 7
2.6 Extended Forms of Validation Data 9 2.6 Extended Forms of Validation Data 10
2.7 Archive Validation Data 11 2.7 Archive Validation Data 12
2.8 Arbitration 12 2.8 Arbitration 13
2.9 Validation Process 12 2.9 Validation Process 13
2.10 Example Validation Sequence 13 2.10 Example Validation Sequence 14
2.11 Additional optional features 18 2.11 Additional optional features 19
3. Data structure of an Electronic Signature 19 3. Data structure of an Electronic Signature 20
3.1 General Syntax 19 3.1 General Syntax 20
3.2 Data Content Type 19 3.2 Data Content Type 20
3.3 Signed-data Content Type 19 3.3 Signed-data Content Type 20
3.4 SignedData Type 19 3.4 SignedData Type 20
3.5 EncapsulatedContentInfo Type 20 3.5 EncapsulatedContentInfo Type 21
3.6 SignerInfo Type 20 3.6 SignerInfo Type 21
3.6.1 Message Digest Calculation Process 20 3.6.1 Message Digest Calculation Process 21
3.6.2 Message Signature Generation Process 20 3.6.2 Message Signature Generation Process 21
3.6.3 Message Signature Verification Process 20 3.6.3 Message Signature Verification Process 21
3.7 CMS Imported Mandatory Present Attributes 21 3.7 CMS Imported Mandatory Present Attributes 22
3.7.1 Content Type 21 3.7.1 Content Type 22
3.7.2 Message Digest 21 3.7.2 Message Digest 22
3.7.3 Signing Time 21 3.7.3 Signing Time 22
Internet Draft Electronic Signature Formats Internet Draft Electronic Signature Formats
3.8 Alternative Signing Certificate Attributes 21 3.8 Alternative Signing Certificate Attributes 22
3.8.1 ESS Signing Certificate Attribute Definition 21 3.8.1 ESS Signing Certificate Attribute Definition 22
3.8.2 Other Signing Certificate Attribute Definition 22 3.8.2 Other Signing Certificate Attribute Definition 23
3.9 Additional Mandatory Attributes 23 3.9 Additional Mandatory Attributes 24
3.9.1 Signature policy Identifier 23 3.9.1 Signature policy Identifier 24
3.10 CMS Imported Optional Attributes 24 3.10 CMS Imported Optional Attributes 26
3.10.1 Countersignature 25 3.10.1 Countersignature 26
3.11 ESS Imported Optional Attributes 25 3.11 ESS Imported Optional Attributes 26
3.11.1 Content Reference Attribute 25 3.11.1 Content Reference Attribute 27
3.11.2 Content Identifier Attribute 25 3.11.2 Content Identifier Attribute 27
3.12 Additional Optional Attributes 25 3.11.3 Content Hints Attribute 27
3.12.1 Commitment Type Indication Attribute 25 3.12 Additional Optional Attributes 28
3.12.2 Signer Location attribute 27 3.12.1 Commitment Type Indication Attribute 28
3.12.3 Signer Attributes attribute 28 3.12.2 Signer Location attribute 30
3.12.4 Content Timestamp attribute 28 3.12.3 Signer Attributes attribute 31
3.13 Support for Multiple Signatures 29 3.12.4 Content Timestamp attribute 31
3.13.1 Independent Signatures 29 3.13 Support for Multiple Signatures 32
3.13.2 Embedded Signatures 29 3.13.1 Independent Signatures 32
4. Validation Data 29 3.13.2 Embedded Signatures 32
4.1 Electronic Signature Timestamp 30 4. Validation Data 32
4.1.1 Signature Timestamp Attribute Definition 30 4.1 Electronic Signature Timestamp 33
4.2 Complete Validation Data 31 4.1.1 Signature Timestamp Attribute Definition 33
4.2.1 Complete Certificate Refs Attribute Definition 32 4.2 Complete Validation Data 34
4.2.2 Complete Revocation Refs Attribute Definition 32 4.2.1 Complete Certificate Refs Attribute Definition 35
4.3 Extended Validation Data 34 4.2.2 Complete Revocation Refs Attribute Definition 35
4.3.1 Certificate Values Attribute Definition 34 4.3 Extended Validation Data 37
4.3.2 Revocation Values Attribute Definition 35 4.3.1 Certificate Values Attribute Definition 37
4.3.3 ES-C Timestamp Attribute Definition 35 4.3.2 Revocation Values Attribute Definition 38
4.3.4 Time-Stamped Certificates and CRLs Attribute Definition 36 4.3.3 ES-C Timestamp Attribute Definition 38
4.4 Archive Validation Data 36 4.3.4 Time-Stamped Certificates and CRLs Attribute Definition 39
4.4.1 Archive Timestamp Attribute Definition 37 4.4 Archive Validation Data 39
5. Security considerations 38 4.4.1 Archive Timestamp Attribute Definition 40
5.1 Protection of Private Key 38 5. Security considerations 41
5.2 Choice of Algorithms 38 5.1 Protection of Private Key 41
6. Conformance Requirements 38 5.2 Choice of Algorithms 41
6.1 Signer 38 6. Conformance Requirements 41
6.2 Verifier 39 6.1 Signer 41
7. References 40 6.2 Verifier using timestamping 42
8. Authors' Addresses 40 6.3 Verifier using secure records 42
9. Full Copyright Statement 41 7. References 43
Annex A (normative): ASN.1 Definitions 43 8. Authors' Addresses 44
A.1 Definitions Using X.208 (1988) ASN.1 Syntax 43 9. Full Copyright Statement 45
A.2 Definitions Using X.680 1997 ASN.1 Syntax 52 Annex A (normative): ASN.1 Definitions 46
Annex B (informative): General Description 61 A.1 Definitions Using X.208 (1988) ASN.1 Syntax 46
B.1 The Signature Policy 61 A.2 Definitions Using X.680 1997 ASN.1 Syntax 54
B.2 Signed Information 62 Annex B (informative): General Description 64
B.3 Components of an Electronic Signature 62 B.1 The Signature Policy 64
B.3.1 Reference to the Signature Policy 62 B.2 Signed Information 65
B.3.2 Commitment Type Indication 63 B.3 Components of an Electronic Signature 65
B.3.3 Certificate Identifier from the Signer 64 B.3.1 Reference to the Signature Policy 65
B.3.2 Commitment Type Indication 66
B.3.3 Certificate Identifier from the Signer 67
Internet Draft Electronic Signature Formats Internet Draft Electronic Signature Formats
B.3.4. Role Attributes 64 B.3.4. Role Attributes 68
B.3.4.1 Claimed Role 65 B.3.4.1 Claimed Role 68
B.3.4.2 Certified Role 65 B.3.4.2 Certified Role 68
B.3.5 Signer Location 66 B.3.5 Signer Location 69
B.3.6 Signing Time 66 B.3.6 Signing Time 69
B.4 Components of Validation Data 67 B.3.7 Content Format 70
B.4.1 Revocation Status Information 67 B.4 Components of Validation Data 70
B.4.2 CRL Information 67 B.4.1 Revocation Status Information 70
B.4.3 OCSP Information 68 B.4.2 CRL Information 71
B.4.4 Certification Path 69 B.4.3 OCSP Information 72
B.4.5 Timestamping for Long Life of Signature 69 B.4.4 Certification Path 72
B.4.6 Timestamping before CA Key Compromises 70 B.4.5 Timestamping for Long Life of Signature 73
B.4.6.1 Timestamping the ES with Complete validation data 71 B.4.6 Timestamping before CA Key Compromises 74
B.4.6.2 Timestamping Certificates and Revocation Information 72 B.4.6.1 Timestamping the ES with Complete validation data 75
B.4.7 Timestamping for Long Life of Signature 72 B.4.6.2 Timestamping Certificates and Revocation Information 75
B.4.8 Reference to Additional Data 73 B.4.7 Timestamping for Long Life of Signature 76
B.4.9 Timestamping for Mutual Recognition 73 B.4.8 Reference to Additional Data 77
B.4.10 TSA Key Compromise 74 B.4.9 Timestamping for Mutual Recognition 77
B.5 Multiple Signatures 74 B.4.10 TSA Key Compromise 78
Annex C (informative): Identifiers and roles 75 B.5 Multiple Signatures 79
C.1 Signer Name Forms 75 Annex C (informative): Identifiers and roles 79
C.2 TSP Name Forms 75 C.1 Signer Name Forms 79
C.3 Roles and Signer Attributes 75 C.2 TSP Name Forms 79
C.3 Roles and Signer Attributes 80
2 Overview 2 Overview
2.1 Aim 2.1 Aim
The aim of this document is to define an Electronic Signature (ES) that The aim of this document is to define an Electronic Signature (ES) that
remains valid over long periods. This includes evidence as to its remains valid over long periods. This includes evidence as to its
validity even if the signer or verifying party later attempts to deny validity even if the signer or verifying party later attempts to deny
(repudiates) the validity of the signature. (repudiates) the validity of the signature.
This document specifies use of trusted service providers (e.g. This document specifies the use of trusted service providers (e.g.
TimeStamping Authorities (TSA)), and the data that needs to be archived TimeStamping Authorities (TSA)), and the data that needs to be archived
(e.g. cross certificates and revocation lists) to meet the requirements (e.g. cross certificates and revocation lists) to meet the requirements
of long term electronic signatures. An electronic signature defined by of long term electronic signatures. An electronic signature defined by
this document can be used for arbitration in case of a dispute between 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 the signer and verifier, which may occur at some later time, even years
later. This document uses a signature policy, referenced by the signer, later. This document uses a signature policy, referenced by the signer,
as the basis for establishing the validity of an electronic signature. as the basis for establishing the validity of an electronic signature.
2.2 Basis of Present Document 2.2 Basis of Present Document
This document is based on the use of public key cryptography to produce This document is based on the use of public key cryptography to produce
digital signatures, supported by public key certificates. digital signatures, supported by public key certificates.
A Public key certificate is a public keys of a user, together with some A Public key certificate is a public keys of a user, together with some
other information, rendered unforgeable by encipherment with the other information, rendered unforgeable by encipherment with the
private key of the Certification Authority (CA) which issued it (ITU-T private key of the Certification Authority (CA) which issued it (ITU-T
Recommendation X.509 [1]). Recommendation X.509 [1]).
Internet Draft Electronic Signature Formats Internet Draft Electronic Signature Formats
This document also uses timestamping services to prove the validity of This document also specifies the uses of timestamping services to prove
a signature long after the normal lifetime of critical elements of an the validity of a signature long after the normal lifetime of critical
electronic signature and to support non-repudiation. It also, as an elements of an electronic signature and to support non-repudiation. It
option, uses additional timestamps to provide very long-term protection also, as an option, defines the use of additional timestamps to provide
against key compromise or weakened algorithms. very long-term protection against key compromise or weakened
algorithms.
This document builds on existing standards that are widely adopted. This document builds on existing standards that are widely adopted.
This includes: This includes:
* RFC 2459 [RFC2459] Internet X.509 Public Key Infrastructure * RFC 2459 [RFC2459] Internet X.509 Public Key Infrastructure
Certificate and CRL Profile (PKIX); Certificate and CRL Profile (PKIX);
* RFC 2630 [CMS] Crytographic Message Syntax (CMS); * RFC 2630 [CMS] Crytographic Message Syntax (CMS);
* RFC 2634 [ESS] Enhanced Security Services (ESS); * RFC 2634 [ESS] Enhanced Security Services (ESS);
* RFC 2439 [OCSP] One-line Certificate Status Protocol (OCSP); * RFC 2439 [OCSP] One-line Certificate Status Protocol (OCSP);
* ITU-T Recommendation X.509 [1] Authentication framework; * ITU-T Recommendation X.509 [1] Authentication framework;
skipping to change at page 5, line 36 skipping to change at page 5, line 37
2.3 Major Parties 2.3 Major Parties
The following are the major parties involved in a business transaction The following are the major parties involved in a business transaction
supported by electronic signatures as defined in this document: supported by electronic signatures as defined in this document:
* the Signer; * the Signer;
* the Verifier; * the Verifier;
* the Arbitrator; * the Arbitrator;
* Trusted Service Providers (TSP). * Trusted Service Providers (TSP).
A Signer is an entity that creates the electronic signature. When A Signer is an entity that initially creates the electronic signature.
the signer digitally signs over data using the prescribed format, this When the signer digitally signs over data using the prescribed format,
represents a commitment on behalf of the signing entity to the data this represents a commitment on behalf of the signing entity to the
being signed. data being signed.
A verifier is an entity that verifies an evidence. (ISO/IEC 13888-1 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 [13]). Within the context of this document this is an entity that
validates an electronic signature. validates an electronic signature.
An arbitrator, is an entity which arbitrates disputes between a signer An arbitrator, is an entity which arbitrates disputes between a signer
and a verifier when there is a disagreement on the validity of a and a verifier when there is a disagreement on the validity of a
digital signature. digital signature.
Trusted Service Providers (TSPs) are one or more entities that help Trusted Service Providers (TSPs) are one or more entities that help
to build trust relationships between the signer and verifier. Use of to build trust relationships between the signer and verifier. Use of
skipping to change at page 7, line 37 skipping to change at page 7, line 37
following attributes provided by the signer: following attributes provided by the signer:
* hash of the user data (message digest); * hash of the user data (message digest);
* signature Policy Identifier; * signature Policy Identifier;
* other signed attributes * other signed attributes
The other signed attributes include any additional information which The other signed attributes include any additional information which
must be signed to conform to the signature policy or this document must be signed to conform to the signature policy or this document
(e.g. signing time). (e.g. signing time).
The Validation Data may be collected by the signer and/or the verifier According to the requirements of a specific signature policy in use,
and must meet the requirements of the signature policy. Additional various Validation Data shall be collected and attached to or
data includes CA certificates as well as revocation status information associated with the signature structure by the signer and/or the
in the form of Certificate Revocation Lists (CRLs) or certificate verifier. The validation data includes CA certificates as well as
status information provided by an on-line service. Additional data revocation status information in the form of certificate revocation
also includes timestamps and other time related data used to provide lists (CRLs) or certificate status information provided by an on-line
evidence of the timing of given events. It is required, as a minimum, service. Additional data also includes timestamps and other time
that either the signer or verifier obtains a timestamp over the related data used to provide evidence of the timing of given events. It
signer's signature. is required, as a minimum, that either the signer or verifier obtains a
timestamp over the signer's signature or a secure time record of the
A digital signature (not to be confused with an electronic signature) electronic signature must be maintained. Such secure records must not
is data appended to, or a cryptographic transformation of, a data unit be undetectably modified and must record the time close to when the
that allows a recipient of the data unit to prove the source and signature was first validated.
integrity of the data unit and protect against forgery, e.g. by the
recipient (ISO 7498-2 [12])
2.5 Forms of Validation Data 2.5 Forms of Validation Data
An electronic signature may exist in many forms including: An electronic signature may exist in many forms including:
* the Electronic Signature (ES), which includes the digital * the Electronic Signature (ES), which includes the digital
signature and other basic information provided by the signer; signature and other basic information provided by the signer;
Internet Draft Electronic Signature Formats Internet Draft Electronic Signature Formats
skipping to change at page 8, line 19 skipping to change at page 8, line 19
long term validity; long term validity;
* the ES with Complete validation data (ES-C), which adds to the * the ES with Complete validation data (ES-C), which adds to the
ES-T references to the complete set of data supporting the ES-T references to the complete set of data supporting the
validity of the electronic signature (i.e. revocation status validity of the electronic signature (i.e. revocation status
information). information).
The signer must provide at least the ES form, but in some cases may 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 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 the ES-C form. If the signer does not provide ES-T, the verifier must
create the ES-T on first receipt of an electronic signature. The ES-T either create the ES-T on first receipt of an electronic signature or
provides independent evidence of the existence of the signature at the shall keep a secure time record of the ES. Either of these two
time it was first verified which should be near the time it was approaches provide independent evidence of the existence of
created, and so protects against later repudiation of the existence of the signature at the time it was first verified which should be near
the signature. If the signer does not provide ES-C the verifier must the time it was created, and so protects against later repudiation of
create the ES-C when the complete set of revocation and other the existence of the signature. If the signer does not provide ES-C the
validation data is available. 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 The ES satisfies the legal requirements for electronic signatures as
defined in the European Directive on electronic signatures, see Annex C defined in the European Directive on electronic signatures, see Annex C
for further discussion on relationship of this document to the for further discussion on relationship of this document to the
Directive. It provides basic authentication and integrity protection Directive. It provides basic authentication and integrity protection
and can be created without accessing on-line (timestamping) services. and can be created without accessing on-line (timestamping) services.
However, without the addition of a timestamp the electronic signature However, without the addition of a timestamp or a secure time record
does not protect against the threat that the signer later denies having the electronic signature does not protect against the threat that the
created the electronic signature (i.e. does not provide non-repudiation signer later denies having created the electronic signature (i.e. does
of its existence). not provide non-repudiation of its existence).
The ES-T time-stamp should be created close to the time that ES was The ES-T time-stamp or time record should be created close to the time
created to provide protection against repudiation. At this time all that ES was created to provide protection against repudiation. At this
the data needed to complete the validation may not be available but time all the data needed to complete the validation may not be
what information is readily available may be used to carry out some of available but what information is readily available may be used to
the initial checks. For example, only part of the revocation carry out some of the initial checks. For example, only part of the
information may be available for verification at that point in time. revocation information may be available for verification at that point
Generally, the ES-C form cannot be created at the same time as the ES, in time. Generally, the ES-C form cannot be created at the same time as
as it is necessary to allow time for any revocation information to be the ES, as it is necessary to allow time for any revocation information
captured. Also, if a certificate is found to be temporarily suspended, to be captured. Also, if a certificate is found to be temporarily
it will be necessary to wait until the end of the suspension period. 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 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 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 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 verifier can be presented with the complete set of data supporting
the validity of the ES. the validity of the ES.
Support for ES-C by the verifier is mandated (see clause 6 for Support for ES-C by the verifier is mandated (see clause 6 for
specific conformance requirements). specific conformance requirements).
skipping to change at page 9, line 24 skipping to change at page 9, line 24
||||Signature| | Other | | Digital || |over digital|| |certificate|| ||||Signature| | Other | | Digital || |over digital|| |certificate||
||||Policy ID| | Signed | |Signature|| |signature || |and || ||||Policy ID| | Signed | |Signature|| |signature || |and ||
|||| | |Attributes| | || +------------+| |revocation || |||| | |Attributes| | || +------------+| |revocation ||
|||+---------+ +----------+ +---------+| | |references || |||+---------+ +----------+ +---------+| | |references ||
||+------------------------------------+ | +-----------+| ||+------------------------------------+ | +-----------+|
|+-----------------------------------------------------+ | |+-----------------------------------------------------+ |
+---------------------------------------------------------------------+ +---------------------------------------------------------------------+
Figure 1: Illustration of an ES, ES-T and ES-C Figure 1: Illustration of an ES, ES-T and ES-C
The verifiers conformance requirements of an ES with a timestamp 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
timestamping 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).
Internet Draft Electronic Signature Formats
+-------------------------------------------------------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 timestamp 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 timestamp 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 2.6 Extended Forms of Validation Data
The complete validation data (ES-C) described above may be extended to The complete validation data (ES-C) described above may be extended to
form an ES with eXtended validation data (ES-X) to meet following form an ES with eXtended validation data (ES-X) to meet following
additional requirements. additional requirements.
Firstly, when the verifier does not has access to, Firstly, when the verifier does not has access to,
* the signer's certificate, * the signer's certificate,
* all the CA certificates that make up the full certification * all the CA certificates that make up the full certification
skipping to change at page 9, line 51 skipping to change at page 11, line 5
Secondly, if there is a risk that any CA keys used in the certificate Secondly, if there is a risk that any CA keys used in the certificate
chain may be compromised, then it is necessary to additionally chain may be compromised, then it is necessary to additionally
timestamp the validation data by either: timestamp the validation data by either:
* timestamping all the validation data as held with the ES(ES-C), * timestamping all the validation data as held with the ES(ES-C),
this eXtended validation data is called a Type 1 X-Timestamp; or this eXtended validation data is called a Type 1 X-Timestamp; or
* timestamping individual reference data as used for complete * timestamping individual reference data as used for complete
validation. validation.
Internet Draft Electronic Signature Formats
This form of eXtended validation data is called a Type 2 X-Timestamp. This form of eXtended validation data is called a Type 2 X-Timestamp.
NOTE: The advantages/drawbacks for Type 1 and Type 2 X-Timestamp are NOTE: The advantages/drawbacks for Type 1 and Type 2 X-Timestamp are
discussed in this document (see clause B.4.6.) discussed in this document (see clause B.4.6.)
Internet Draft Electronic Signature Formats
If all the above conditions occur then a combination of the two formats 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 above may be used. This form of eXtended validation data is called
a X-Long-Timestamped. a X-Long-Timestamped.
Support for the extended forms of validation data is optional. Support for the extended forms of validation data is optional.
An Electronic Signature (ES) , with the additional validation data An Electronic Signature (ES) , with the additional validation data
forming the ES-X long is illustrated in Figure 2: forming the ES-X long is illustrated in Figure 4:
+------------------------------------------------------- ES-X Long--+ +------------------------------------------------------- ES-X Long--+
|+--------------------------------------- EC-C --------+ | |+--------------------------------------- EC-C --------+ |
||+---- Elect.Signature (ES)----+ +--------+| +--------+ | ||+---- Elect.Signature (ES)----+ +--------+| +--------+ |
|||+-------+-+-------+-+-------+| +---------+|Complete|| |Complete| | |||+-------+-+-------+-+-------+| +---------+|Complete|| |Complete| |
||||Signa- | |Other | |Digital|| |Timestamp||certi- || |certi- | | ||||Signa- | |Other | |Digital|| |Timestamp||certi- || |certi- | |
||||ture | |Signed | |Signa- || |over ||ficate || |ficate | | ||||ture | |Signed | |Signa- || |over ||ficate || |ficate | |
||||Policy | |Attri- | |ture || |digital ||and || |and | | ||||Policy | |Attri- | |ture || |digital ||and || |and | |
||||ID | |butes | | || |signature||revoc. || |revoc. | | ||||ID | |butes | | || |signature||revoc. || |revoc. | |
|||+-------+ +-------+ +-------+| +---------+|refs || |data | | |||+-------+ +-------+ +-------+| +---------+|refs || |data | |
||+-----------------------------+ +--------+| +--------+ | ||+-----------------------------+ +--------+| +--------+ |
|+-----------------------------------------------------+ | |+-----------------------------------------------------+ |
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
Figure 2: Illustration of an ES and ES-X long. Figure 4: Illustration of an ES and ES-X long.
An Electronic Signature (ES) , with the additional validation data An Electronic Signature (ES) , with the additional validation data
forming the eXtended Validation Data - Type 1 is illustrated in forming the eXtended Validation Data - Type 1 is illustrated in
Figure 3: Figure 5:
+---------------------------------------------------------- ES-X 1 -+ +---------------------------------------------------------- ES-X 1 -+
|+---------------------------------------- EC-C --------+ | |+---------------------------------------- EC-C --------+ |
|| +---- Elect.Signature (ES)----+ +--------+| +-------+ | || +---- Elect.Signature (ES)----+ +--------+| +-------+ |
|| |+-------+ +-------+ +-------+| +---------+|Complete|| | | | || |+-------+ +-------+ +-------+| +---------+|Complete|| | | |
|| ||Signa- | |Other | |Digital|| |Timestamp||certifi-|| | Time- | | || ||Signa- | |Other | |Digital|| |Timestamp||certifi-|| | Time- | |
|| ||ture | |Signed | |Signa- || |over ||cate and|| | stamp | | || ||ture | |Signed | |Signa- || |over ||cate and|| | stamp | |
|| ||Policy | |Attri- | |ture || |digital ||revoc. || | over | | || ||Policy | |Attri- | |ture || |digital ||revoc. || | over | |
|| ||ID | |butes | | || |signature||refs || | CES | | || ||ID | |butes | | || |signature||refs || | CES | |
|| |+-------+ +-------+ +-------+| +---------+| || | | | || |+-------+ +-------+ +-------+| +---------+| || | | |
|| +-----------------------------+ +--------+| +-------+ | || +-----------------------------+ +--------+| +-------+ |
|+------------------------------------------------------+ | |+------------------------------------------------------+ |
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
Figure 3: Illustration of ES with ES-X Type 1 Figure 5: Illustration of ES with ES-X Type 1
Internet Draft Electronic Signature Formats Internet Draft Electronic Signature Formats
An Electronic Signature (ES) , with the additional validation data An Electronic Signature (ES) , with the additional validation data
forming the eXtended Validation Data - Type 2 is illustrated in forming the eXtended Validation Data - Type 2 is illustrated in
Figure 4: Figure 6:
+-------------------------------------------------------- ES-X 2 ---+ +-------------------------------------------------------- ES-X 2 ---+
|+--------------------------------------- EC-C --------+ | |+--------------------------------------- EC-C --------+ |
||+---- Elect.Signature (ES)----+ +--------+| +--------+ | ||+---- Elect.Signature (ES)----+ +--------+| +--------+ |
|||+-------+ +-------+ +-------+| +---------+|Complete|| |Times | | |||+-------+ +-------+ +-------+| +---------+|Complete|| |Times | |
||||Signa- | |Other | |Digital|| |Timestamp||certs || |Stamp | | ||||Signa- | |Other | |Digital|| |Timestamp||certs || |Stamp | |
||||ture | |Signed | |Signa- || |over ||and || |over | | ||||ture | |Signed | |Signa- || |over ||and || |over | |
||||Policy | |Attri- | |ture || |digital ||revoc. || |Complete| | ||||Policy | |Attri- | |ture || |digital ||revoc. || |Complete| |
||||ID | |butes | | || |signature||refs || |certs | | ||||ID | |butes | | || |signature||refs || |certs | |
|||+-------+ +-------+ +-------+| +---------+| || |and | | |||+-------+ +-------+ +-------+| +---------+| || |and | |
||+-----------------------------+ +--------+| |revoc. | | ||+-----------------------------+ +--------+| |revoc. | |
|| | |refs | | || | |refs | |
|+-----------------------------------------------------+ +--------+ | |+-----------------------------------------------------+ +--------+ |
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
Figure 4: Illustration of ES with ES-X Type 2 Figure 6: Illustration of ES with ES-X Type 2
2.7 Archive Validation Data 2.7 Archive Validation Data
Before the algorithms, keys and other cryptographic data used at the Before the algorithms, keys and other cryptographic data used at the
time the ES-C was built become weak and the cryptographic functions time the ES-C was built become weak and the cryptographic functions
become vulnerable, or the certificates supporting previous timestamps become vulnerable, or the certificates supporting previous timestamps
expires, the signed data, the ES-C and any additional information expires, the signed data, the ES-C and any additional information
(ES-X) should be timestamped. If possible this should use stronger (ES-X) should be timestamped. If possible this should use stronger
algorithms (or longer key lengths) than in the original timestamp. algorithms (or longer key lengths) than in the original timestamp.
This additional data and timestamp is called Archive Validation Data This additional data and timestamp is called Archive Validation Data
(ES-A). The Timestamping process may be repeated every time the (ES-A). The Timestamping process may be repeated every time the
protection used to timestamp a previous ES-A become weak. An ES-A protection used to timestamp a previous ES-A become weak. An ES-A
may thus bear multiple embedded time stamps. may thus bear multiple embedded time stamps.
An example of an Electronic Signature (ES), with the additional 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 validation data for the ES-C and ES-X forming the ES-A is illustrated
in Figure 5. in Figure 7.
+-------------------------------- ES-A --------- ----------+ +-------------------------------- ES-A --------- ----------+
| +-------------------- ES-A -----------------+ | | +-------------------- ES-A -----------------+ |
| | +--------- ES-X -------------- + | | | | +--------- ES-X -------------- + | |
| | |..............................| +-----+ | +-----+ | | | |..............................| +-----+ | +-----+ |
| | |..............................| |Time | | |Time | | | | |..............................| |Time | | |Time | |
| | |..............................| |Stamp| | |Stamp| | | | |..............................| |Stamp| | |Stamp| |
| | | | +-----+ | +-----+ | | | | | +-----+ | +-----+ |
| | +----------------------------- + | | | | +----------------------------- + | |
| +-------------------------------------------+ | | +-------------------------------------------+ |
+----------------------------------------------------------+ +----------------------------------------------------------+
Figure 5: Illustration of ES -A Figure 7: Illustration of ES -A
Support for ES-A is optional. Support for ES-A is optional.
Internet Draft Electronic Signature Formats Internet Draft Electronic Signature Formats
2.8 Arbitration 2.8 Arbitration
The ES-C may be used for arbitration should there be a dispute between The ES-C may be used for arbitration should there be a dispute between
the signer and verifier, provided that: the signer and verifier, provided that:
skipping to change at page 13, line 35 skipping to change at page 14, line 35
user to decide what to do with partially correct electronic signatures. user to decide what to do with partially correct electronic signatures.
The validation process may also output validation data : The validation process may also output validation data :
* a signature timestamp; * a signature timestamp;
* the complete validation data; * the complete validation data;
* the archive validation data. * the archive validation data.
2.10 Example Validation Sequence 2.10 Example Validation Sequence
As described earlier the signer or verifier may collect all the Figure 8, and subsequent description, describes how the validation
additional data that forms the Electronic Signature. Figure 6, and process may build up a complete electronic signature over time.
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), Soon after receiving the electronic signature (ES) from the signer (1),
the digital signature value may be checked, the validation process the digital signature value may be checked, the validation process
must at least add a time-stamp (2), unless the signer has provided one 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 which is trusted by the verifier. The validation process may also
validate the electronic signature, as required under the identified validate the electronic signature, as required under the identified
signature policy, using additional data (e.g. certificates, CRL, etc.) signature policy, using additional data (e.g. certificates, CRL, etc.)
provided by trusted service providers. If the validation process is not provided by trusted service providers. If the validation process is not
complete then the output from this stage is the ES-T. complete then the output from this stage is the ES-T.
skipping to change at page 14, line 39 skipping to change at page 15, line 39
+----------+ \--->| Validation Process |---> |- Valid | +----------+ \--->| Validation Process |---> |- Valid |
+---|--^-------|--^--+ 4 |- Invalid | +---|--^-------|--^--+ 4 |- Invalid |
| | | | |- Validation| | | | | |- Validation|
v | v | | Incomplete| v | v | | Incomplete|
+---------+ +--------+ +------------+ +---------+ +--------+ +------------+
|Signature| |Trusted | |Signature| |Trusted |
| Policy | |Service | | Policy | |Service |
| Issuer | |Provider| | Issuer | |Provider|
+---------+ +--------+ +---------+ +--------+
Figure 6: Illustration of an ES with Complete validation data (ES-C) Figure 8: Illustration of an ES with Complete validation data (ES-C)
Internet Draft Electronic Signature Formats Internet Draft Electronic Signature Formats
At the same time as the validation process creates the ES-C, the At the same time as the validation process creates the ES-C, the
validation process may provide and/or record the values of certificates validation process may provide and/or record the values of certificates
and revocation status information used in ES-C, called the ES-X Long and revocation status information used in ES-C, called the ES-X Long
(5). This is illustrated in figure 7: (5). This is illustrated in figure 9:
+---------------------------------------------------- ES-X ---------+ +---------------------------------------------------- ES-X ---------+
|+--------------------------------------- ES-C --------+ +--------+ | |+--------------------------------------- ES-C --------+ +--------+ |
||+--- Elect.Signature (ES) ----+ +--------+ | |Complete| | ||+--- Elect.Signature (ES) ----+ +--------+ | |Complete| |
|||+-------+ +-------+ +-------+|+---------+|Complete| | |certifi-| | |||+-------+ +-------+ +-------+|+---------+|Complete| | |certifi-| |
||||Signa- | |Other | |Digital|||Timestamp||certifi-| | |cate | | ||||Signa- | |Other | |Digital|||Timestamp||certifi-| | |cate | |
||||ture | |Signed | |Signa- |||over ||cate and| | |and | | ||||ture | |Signed | |Signa- |||over ||cate and| | |and | |
||||Policy | |Attri- | |ture |||digital ||revoca- | | |revoca- | | ||||Policy | |Attri- | |ture |||digital ||revoca- | | |revoca- | |
||||ID | |butes | | |||signature||tion | | |tion | | ||||ID | |butes | | |||signature||tion | | |tion | |
|||+-------+ +---|---+ +-------+|+---------+|referen-| | |Data | | |||+-------+ +---|---+ +-------+|+---------+|referen-| | |Data | |
skipping to change at page 15, line 40 skipping to change at page 16, line 40
+----------+ \--->| Validation Process |---> | - Valid | +----------+ \--->| Validation Process |---> | - Valid |
+---|--^-------|--^--+ 4 | - Invalid | +---|--^-------|--^--+ 4 | - Invalid |
| | | | +-----------+ | | | | +-----------+
v | v | v | v |
+---------+ +--------+ +---------+ +--------+
|Signature| |Trusted | |Signature| |Trusted |
| Policy | |Service | | Policy | |Service |
| Issuer | |Provider| | Issuer | |Provider|
+---------+ +--------+ +---------+ +--------+
Figure 7: Illustration ES with eXtended validation data (Long) Figure 9: Illustration ES with eXtended validation data (Long)
Internet Draft Electronic Signature Formats Internet Draft Electronic Signature Formats
When the validation process creates the ES-C it may also create When the validation process creates the ES-C it may also create
extended forms of validation data. A first alternative is to timestamp extended forms of validation data. A first alternative is to timestamp
all data forming the Type 1 X-Timestamp (6). This is illustrated in all data forming the Type 1 X-Timestamp (6). This is illustrated in
figure 8: figure 10:
+---------------------------------------------------- ES-X -------+ +---------------------------------------------------- ES-X -------+
|+--------------------------------------- ES-C --------+ +------+ | |+--------------------------------------- ES-C --------+ +------+ |
||+--- Elect.Signature (ES) ----+ +--------+ | |Time- | | ||+--- Elect.Signature (ES) ----+ +--------+ | |Time- | |
|||+-------+ +-------+ +-------+|+---------+|Complete| | |stamp | | |||+-------+ +-------+ +-------+|+---------+|Complete| | |stamp | |
||||Signa- | |Other | |Digital|||Timestamp||certifi-| | |over | | ||||Signa- | |Other | |Digital|||Timestamp||certifi-| | |over | |
||||ture | |Signed | |Signa- |||over ||cate and| | |CES | | ||||ture | |Signed | |Signa- |||over ||cate and| | |CES | |
||||Policy | |Attri- | |ture |||digital ||revoca- | | +------+ | ||||Policy | |Attri- | |ture |||digital ||revoca- | | +------+ |
||||ID | |butes | | |||signature||tion | | ^ | ||||ID | |butes | | |||signature||tion | | ^ |
|||+-------+ +--|----+ +-------+|+---------+|referen-| | | | |||+-------+ +--|----+ +-------+|+---------+|referen-| | | |
skipping to change at page 16, line 40 skipping to change at page 17, line 40
+----------+ \--->| Validation Process |---> | - Valid | +----------+ \--->| Validation Process |---> | - Valid |
+---|--^-------|--^--+ 4 | - Invalid | +---|--^-------|--^--+ 4 | - Invalid |
| | | | +-----------+ | | | | +-----------+
v | v | v | v |
+---------+ +--------+ +---------+ +--------+
|Signature| |Trusted | |Signature| |Trusted |
| Policy | |Service | | Policy | |Service |
| Issuer | |Provider| | Issuer | |Provider|
+---------+ +--------+ +---------+ +--------+
Figure 8: Illustration of ES with eXtended validation data - Type 1 X- Figure 10: Illustration of ES with eXtended validation data - Type 1 X-
Timestamp Timestamp
Internet Draft Electronic Signature Formats Internet Draft Electronic Signature Formats
Another alternative is to timestamp the certificate and revocation Another alternative is to timestamp the certificate and revocation
information references used to validate the electronic signature (but information references used to validate the electronic signature (but
not the signature) (6'); this is called Type 2 X-Timestamped. This is not the signature) (6'); this is called Type 2 X-Timestamped. This is
illustrated in figure 9: illustrated in figure 11:
+---------------------------------------------------- ES-X ----------+ +---------------------------------------------------- ES-X ----------+
|+--------------------------------------- ES-C --------+ +---------+ | |+--------------------------------------- ES-C --------+ +---------+ |
||+--- Elect.Signature (ES) ----+ +--------+ | |Timestamp| | ||+--- Elect.Signature (ES) ----+ +--------+ | |Timestamp| |
|||+-------+ +-------+ +-------+|+---------+|Complete| | |over | | |||+-------+ +-------+ +-------+|+---------+|Complete| | |over | |
||||Signa- | |Other | |Digital|||Timestamp||certifi-| | |Complete | | ||||Signa- | |Other | |Digital|||Timestamp||certifi-| | |Complete | |
||||ture | |Signed | |Signa- |||over ||cate and| | |Certifi- | | ||||ture | |Signed | |Signa- |||over ||cate and| | |Certifi- | |
||||Policy | |Attri- | |ture |||digital ||revoc. | | |cate and | | ||||Policy | |Attri- | |ture |||digital ||revoc. | | |cate and | |
||||ID | |butes | | |||signature||refs | | |revoc. | | ||||ID | |butes | | |||signature||refs | | |revoc. | |
|||+-------+ +---^---+ +-------+|+----^----++---^----+ | |refs | | |||+-------+ +---^---+ +-------+|+----^----++---^----+ | |refs | |
skipping to change at page 17, line 38 skipping to change at page 18, line 38
+----------+ \--->| Validation Process |---> | - Valid | +----------+ \--->| Validation Process |---> | - Valid |
+---|--^-------|--^--+ 4 | - Invalid | +---|--^-------|--^--+ 4 | - Invalid |
| | | | +-----------+ | | | | +-----------+
v | v | v | v |
+---------+ +--------+ +---------+ +--------+
|Signature| |Trusted | |Signature| |Trusted |
| Policy | |Service | | Policy | |Service |
| Issuer | |Provider| | Issuer | |Provider|
+---------+ +--------+ +---------+ +--------+
Figure 9: Illustration of ES with eXtended validation data - Type 2 X- Figure 11: Illustration of ES with eXtended validation data - Type 2 X-
Timestamp Timestamp
Internet Draft Electronic Signature Formats Internet Draft Electronic Signature Formats
Before the algorithms used in any of electronic signatures become or Before the algorithms used in any of electronic signatures become or
are likely, to be compromised or rendered vulnerable in the future, it are likely, to be compromised or rendered vulnerable in the future, it
is necessary to timestamp the entire electronic signature, including is necessary to timestamp the entire electronic signature, including
all the values of the validation and user data as an ES with Archive all the values of the validation and user data as an ES with Archive
validation data (ES-A) validation data (ES-A)
An ES-A is illustrated in figure 10: An ES-A is illustrated in figure 12:
-------------------------------------------- ES-A --------------------+ -------------------------------------------- ES-A --------------------+
----------------------------------------------------------------+ | ----------------------------------------------------------------+ |
+------------------------------- EC-C --------++-----+ | | +------------------------------- EC-C --------++-----+ | |
| ||Time-| | | | ||Time-| | |
|+-- Elect.Signature (ES) -+ +--------+||stamp| +-------+ | |+-- Elect.Signature (ES) -+ +--------+||stamp| +-------+ |
||+------++-------++-------|+------+|Complete|||over | Complete| | ||+------++-------++-------|+------+|Complete|||over | Complete| |
|||Signa-||Other ||Digital||Time- ||certifi-|||CES | |certi- |+----| |||Signa-||Other ||Digital||Time- ||certifi-|||CES | |certi- |+----|
|||ture ||Signed ||Signa- ||stamp ||cate and||+-----+ |ficate |Arch-| |||ture ||Signed ||Signa- ||stamp ||cate and||+-----+ |ficate |Arch-|
|||Policy||Attri- ||ture ||over ||revoca- ||+------+ |and |ive | |||Policy||Attri- ||ture ||over ||revoca- ||+------+ |and |ive |
skipping to change at page 18, line 50 skipping to change at page 19, line 50
\------>| Validation Process |---> | - Valid | \------>| Validation Process |---> | - Valid |
+---|--^-------|--^--+ 4 | - Invalid | +---|--^-------|--^--+ 4 | - Invalid |
| | | | +-----------+ | | | | +-----------+
v | v | v | v |
+---------+ +--------+ +---------+ +--------+
|Signature| |Trusted | |Signature| |Trusted |
| Policy | |Service | | Policy | |Service |
| Issuer | |Provider| | Issuer | |Provider|
+---------+ +--------+ +---------+ +--------+
Figure 10: Illustration of an ES with Archive validation data (ES-A) Figure 12: Illustration of an ES with Archive validation data (ES-A)
2.11 Additional optional features 2.11 Additional optional features of an ES
This document also defines additional optional features to: This document also defines additional optional features of
an electronic signature to:
* indicate a commitment type being made by the signer; * indicate a commitment type being made by the signer;
* indicate the role under which a signature was created; * indicate the role under which a signature was created;
* support multiple signatures. * support multiple signatures.
Internet Draft Electronic Signature Formats Internet Draft Electronic Signature Formats
3. Data structure of an Electronic Signature 3. Data structure of an Electronic Signature
This clause uses and builds upon the Cryptographic Message Syntax This clause uses and builds upon the Cryptographic Message Syntax
skipping to change at page 23, line 16 skipping to change at page 24, line 16
OtherHashAlgAndValue ::= SEQUENCE { OtherHashAlgAndValue ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier, hashAlgorithm AlgorithmIdentifier,
hashValue OtherHashValue hashValue OtherHashValue
} }
3.9 Additional Mandatory Attributes 3.9 Additional Mandatory Attributes
3.9.1 Signature policy Identifier 3.9.1 Signature policy Identifier
This document mandates that a reference to the signature policy, which This document mandates that a reference to the signature policy, is
defines the rules for creation and validation of an electronic included in the signedData, this reference is either explicitly
signature, is included as a signed attribute with every signature. The identified or implied by the semantics of the signed content and other
signature policy identifier must be a signed attribute. 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 The following object identifier identifies the signature policy
identifier attribute: identifier attribute:
id-aa-ets-sigPolicyId OBJECT IDENTIFIER ::= { iso(1) id-aa-ets-sigPolicyId OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-aa(2) 15 } smime(16) id-aa(2) 15 }
Signature-policy-identifier attribute values have ASN.1 type Signature-policy-identifier attribute values have ASN.1 type
SignaturePolicyIdentifier. SignaturePolicyIdentifier.
SignaturePolicyIdentifier ::= SEQUENCE { SignaturePolicyIdentifier ::= CHOICE{
SignaturePolicyId SignaturePolicyId,
SignaturePolicyImplied SignaturePolicyImplied }
SignaturePolicyId ::= SEQUENCE {
sigPolicyIdentifier SigPolicyId, sigPolicyIdentifier SigPolicyId,
sigPolicyHash SigPolicyHash, sigPolicyHash SigPolicyHash,
sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF
SigPolicyQualifierInfo OPTIONAL SigPolicyQualifierInfo OPTIONAL
} }
The sigPolicyIdentifier field contains an object-identifier which SignaturePolicyImplied ::= NULL
The presence of the NULL type indicates that the signature policy is
implied by the semantics of the signed data and other external data.
Internet Draft Electronic Signature Formats
The sigPolicyId field contains an object-identifier which
uniquely identifies a specific version of the signature policy. The uniquely identifies a specific version of the signature policy. The
syntax of this field is as follows: syntax of this field is as follows:
SigPolicyId ::= OBJECT IDENTIFIER SigPolicyId ::= OBJECT IDENTIFIER
The sigPolicyHash field contains the identifier of the hash algorithm The sigPolicyHash field contains the identifier of the hash algorithm
and the hash of the value of the signature policy. and the hash of the value of the signature policy.
If the signature policy is defined using a computer processable If the signature policy is defined using a computer processable
notation like ASN.1, then the hash is calculated on the value without notation like ASN.1, then the hash is calculated on the value without
the outer type and length fields and the hashing algorithm must be as the outer type and length fields and the hashing algorithm must be as
specified in the field signPolicyHshAlg. specified in the field signPolicyHshAlg.
If the signature policy is defined using another structure, the type of If the signature policy is defined using another structure, the type of
structure and the hashing algorithm must be either specified as part structure and the hashing algorithm must be either specified as part
of the signature policy, or indicated using a signature policy of the signature policy, or indicated using a signature policy
qualifier. qualifier.
SigPolicyHash ::= ETSIHashAlgAndValue SigPolicyHash ::= ETSIHashAlgAndValue
Internet Draft Electronic Signature Formats
A signature policy identifier may be qualified with other information A signature policy identifier may be qualified with other information
about the qualifier. The semantics and syntax of the qualifier is as about the qualifier. The semantics and syntax of the qualifier is as
associated with the object-identifier in the sigPolicyQualifierId associated with the object-identifier in the sigPolicyQualifierId
field. The general syntax of this qualifier is as follows: field. The general syntax of this qualifier is as follows:
SigPolicyQualifierInfo ::= SEQUENCE { SigPolicyQualifierInfo ::= SEQUENCE {
sigPolicyQualifierId SigPolicyQualifierId, sigPolicyQualifierId SigPolicyQualifierId,
sigQualifier ANY DEFINED BY sigPolicyQualifierId sigQualifier ANY DEFINED BY sigPolicyQualifierId
} }
This document specifies the following qualifiers: This document specifies the following qualifiers:
* spuri: This contains the web URI or URL reference to the * spuri: This contains the web URI or URL reference to the
signature policy signature policy
* spUserNotice: This contains a user notice which should be * spUserNotice: This contains a user notice which should be
displayed whenever the signature is validated. displayed whenever the signature is validated.
Internet Draft Electronic Signature Formats
-- sigpolicyQualifierIds defined in this document -- sigpolicyQualifierIds defined in this document
SigPolicyQualifierId ::= OBJECT IDENTIFIER SigPolicyQualifierId ::= OBJECT IDENTIFIER
id-spq-ets-uri OBJECT IDENTIFIER ::= { iso(1) id-spq-ets-uri OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-spq(5) 1 } smime(16) id-spq(5) 1 }
SPuri ::= IA5String SPuri ::= IA5String
skipping to change at page 25, line 5 skipping to change at page 26, line 42
visibleString VisibleString (SIZE (1..200)), visibleString VisibleString (SIZE (1..200)),
bmpString BMPString (SIZE (1..200)), bmpString BMPString (SIZE (1..200)),
utf8String UTF8String (SIZE (1..200)) utf8String UTF8String (SIZE (1..200))
} }
3.10 CMS Imported Optional Attributes 3.10 CMS Imported Optional Attributes
The following attributes MAY be present with the signed-data defined by The following attributes MAY be present with the signed-data defined by
this document. The attributes are defined in ref [CMS] and are imported this document. The attributes are defined in ref [CMS] and are imported
Internet Draft Electronic Signature Formats
into this specification and were appropriate qualified and profiling by into this specification and were appropriate qualified and profiling by
this document. this document.
3.10.1 Countersignature 3.10.1 Countersignature
The syntax of the countersignature attribute type of the ES is as The syntax of the countersignature attribute type of the ES is as
defined in [CMS]. The countersignature attribute must be an unsigned defined in [CMS]. The countersignature attribute must be an unsigned
attribute. attribute.
3.11 ESS Imported Optional Attributes 3.11 ESS Imported Optional Attributes
The following attributes MAY be present with the signed-data defined by The following attributes MAY be present with the signed-data defined by
this document. The attributes are defined in ref [ESS] and are imported this document. The attributes are defined in ref [ESS] and are imported
into this specification and were appropriate qualified and profiling into this specification and were appropriate qualified and profiling
by this document. by this document.
Internet Draft Electronic Signature Formats
3.11.1 Content Reference Attribute 3.11.1 Content Reference Attribute
The content reference attribute is a link from one SignedData to The content reference attribute is a link from one SignedData to
another. It may be used to link a reply to the original message to another. It may be used to link a reply to the original message to
which it refers, or to incorporate by reference one SignedData into which it refers, or to incorporate by reference one SignedData into
another. another.
The content reference attribute MUST be used as defined in [ESS]. The The content reference attribute MUST be used as defined in [ESS]. The
content reference MUST be a signed attribute. content reference MUST be a signed attribute.
skipping to change at page 25, line 53 skipping to change at page 27, line 37
The content identifier must be a signed attribute. The content identifier must be a signed attribute.
The syntax of the content identifier attribute type of the ES is as The syntax of the content identifier attribute type of the ES is as
defined in [ESS]. defined in [ESS].
The minimal signedContentIdentifier should contain a concatenation of The minimal signedContentIdentifier should contain a concatenation of
user-specific identification information (such as a user name or public user-specific identification information (such as a user name or public
keying material identification information), a GeneralizedTime string, keying material identification information), a GeneralizedTime string,
and a random number. and a random number.
3.11.3 Content Hints Attribute
The content hints attribute provides information that describes the
format of the signed content. It may be used by the signer to indicate
to a verifier the precise format that MUST be used to present the data
(e.g. text, voice, video) to a verifier. This attribute MUST be
present when it is mandatory to present the signed data to human users
on verification.
The syntax of the content hints attribute type of the ES is as defined
in ESS (RFC 2634, section 2.9 [9]).
When used to indicate the precise format of the data to be presented to
the user the following rules apply:
The contentType (defined in RFC 2630 [8]) indicates the type of the
associated content. It is an object identifier (i.e. a unique string of
integers) assigned by an authority that defines the content type.
Internet Draft Electronic Signature Formats
The UTF8String shall define the presentation format. The format may be
defined by MIME types as indicated below.
Note 1: The contentType can be id-data defined in CMS (RFC 2630 [8]).
The UTF8String can be used to indicate the encoding of the data, like
MIME type. RFC 2045 [25] provides a common structure for encoding a
range of electronic documents and other multi-media types, see annex B
for further information, a system supporting verification of electronic
signature may present information to users in the form identified by
the MIME type.
id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs7(7) 1 }
3.12 Additional Optional Attributes 3.12 Additional Optional Attributes
3.12.1 Commitment Type Indication Attribute 3.12.1 Commitment Type Indication Attribute
There may be situation were a signer wants to explicitly indicate to a There may be situation were a signer wants to explicitly indicate to a
verifier that by signing the data, it illustrates a type of commitment verifier that by signing the data, it illustrates a type of commitment
on behalf of the signer. The commitmentTypeIndication attribute conveys on behalf of the signer. The commitmentTypeIndication attribute conveys
such information. such information.
Internet Draft Electronic Signature Formats
The commitmentTypeIndication attribute must be a signed attribute. The commitmentTypeIndication attribute must be a signed attribute.
The commitment type may be: The commitment type may be:
* defined as part of the signature policy, in which case the * defined as part of the signature policy, in which case the
commitment type has precise semantics that is defined as part of commitment type has precise semantics that is defined as part of
the signature policy. the signature policy.
* be a registered type, in which case the commitment type has * be a registered type, in which case the commitment type has
precise semantics defined by registration, under the rules of the precise semantics defined by registration, under the rules of the
registration authority. Such a registration authority may be a registration authority. Such a registration authority may be a
trading association or a legislative authority. trading association or a legislative authority.
The signature policy specifies a set of attributes that it The signature policy specifies a set of attributes that it
"recognizes". This "recognized" set includes all those commitment types "recognizes". This "recognized" set includes all those commitment types
defined as part of the signature policy as well as any externally defined as part of the signature policy as well as any externally
defined commitment types that the policy may choose to recognize. Only defined commitment types that the policy may choose to recognize. Only
recognized commitment types are allowed in this field. recognized commitment types are allowed in this field.
Internet Draft Electronic Signature Formats
The following object identifier identifies the commitment type The following object identifier identifies the commitment type
indication attribute: indication attribute:
id-aa-ets-commitmentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-aa-ets-commitmentType OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 16} us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 16}
Commitment-Type-Indication attribute values have ASN.1 type Commitment-Type-Indication attribute values have ASN.1 type
CommitmentTypeIndication. CommitmentTypeIndication.
CommitmentTypeIndication ::= SEQUENCE { CommitmentTypeIndication ::= SEQUENCE {
skipping to change at page 27, line 5 skipping to change at page 29, line 43
The following generic commitment types are defined in this document: The following generic commitment types are defined in this document:
id-cti-ets-proofOfOrigin OBJECT IDENTIFIER ::= { iso(1) member- id-cti-ets-proofOfOrigin OBJECT IDENTIFIER ::= { iso(1) member-
body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
cti(6) 1} cti(6) 1}
id-cti-ets-proofOfReceipt OBJECT IDENTIFIER ::= { iso(1) member- id-cti-ets-proofOfReceipt OBJECT IDENTIFIER ::= { iso(1) member-
body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
cti(6) 2} cti(6) 2}
Internet Draft Electronic Signature Formats
id-cti-ets-proofOfDelivery OBJECT IDENTIFIER ::= { iso(1) id-cti-ets-proofOfDelivery OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) cti(6) 3} smime(16) cti(6) 3}
id-cti-ets-proofOfSender OBJECT IDENTIFIER ::= { iso(1) member- id-cti-ets-proofOfSender OBJECT IDENTIFIER ::= { iso(1) member-
body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
cti(6) 4} cti(6) 4}
id-cti-ets-proofOfApproval OBJECT IDENTIFIER ::= { iso(1) id-cti-ets-proofOfApproval OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) cti(6) 5} smime(16) cti(6) 5}
id-cti-ets-proofOfCreation OBJECT IDENTIFIER ::= { iso(1) id-cti-ets-proofOfCreation OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) cti(6) 6} smime(16) cti(6) 6}
Internet Draft Electronic Signature Formats
These generic commitment types have the following meaning: These generic commitment types have the following meaning:
Proof of origin indicates that the signer recognizes to have created, Proof of origin indicates that the signer recognizes to have created,
approved and sent the message. approved and sent the message.
Proof of receipt indicates that signer recognizes to have received the Proof of receipt indicates that signer recognizes to have received the
content of the message. content of the message.
Proof of delivery indicates that the TSP providing that indication has Proof of delivery indicates that the TSP providing that indication has
delivered a message in a local store accessible to the recipient of the delivered a message in a local store accessible to the recipient of the
skipping to change at page 28, line 5 skipping to change at page 30, line 45
[PTS]). [PTS]).
The signer-location attribute must be a signed attribute. The signer-location attribute must be a signed attribute.
The following object identifier identifies the signer-location The following object identifier identifies the signer-location
attribute: attribute:
id-aa-ets-signerLocation OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-aa-ets-signerLocation OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 17} us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 17}
Internet Draft Electronic Signature Formats
Signer-location attribute values have ASN.1 type SignerLocation. Signer-location attribute values have ASN.1 type SignerLocation.
SignerLocation ::= SEQUENCE { SignerLocation ::= SEQUENCE {
-- at least one of the following must be present -- at least one of the following must be present
countryName [0] DirectoryString OPTIONAL, countryName [0] DirectoryString OPTIONAL,
-- as used to name a Country in X.500 -- as used to name a Country in X.500
localityName [1] DirectoryString OPTIONAL, localityName [1] DirectoryString OPTIONAL,
-- as used to name a locality in X.500 -- as used to name a locality in X.500
postalAdddress [2] PostalAddress OPTIONAL postalAdddress [2] PostalAddress OPTIONAL
} }
PostalAddress ::= SEQUENCE SIZE(1..6) OF DirectoryString PostalAddress ::= SEQUENCE SIZE(1..6) OF DirectoryString
Internet Draft Electronic Signature Formats
3.12.3 Signer Attributes attribute 3.12.3 Signer Attributes attribute
The signer-attributes attribute is an attribute which specifies The signer-attributes attribute is an attribute which specifies
additional attributes of the signer (e.g. role). additional attributes of the signer (e.g. role).
It may be either: It may be either:
* claimed attributes of the signer; or * claimed attributes of the signer; or
* certified attributes of the signer; * certified attributes of the signer;
skipping to change at page 29, line 5 skipping to change at page 31, line 48
Recommendations X.501 [16] and ITU-T Recommendation X.509 : Draft Recommendations X.501 [16] and ITU-T Recommendation X.509 : Draft
Amendment on Certificate Extensions, October 1999. Amendment on Certificate Extensions, October 1999.
3.12.4 Content Timestamp attribute 3.12.4 Content Timestamp attribute
The content timestamp attribute is an attribute which is the timestamp The content timestamp attribute is an attribute which is the timestamp
of the signed data content before it is signed. of the signed data content before it is signed.
The content timestamp attribute must be a signed attribute. The content timestamp attribute must be a signed attribute.
Internet Draft Electronic Signature Formats
The following object identifier identifies the signer-attribute The following object identifier identifies the signer-attribute
attribute: attribute:
id-aa-ets-contentTimestamp OBJECT IDENTIFIER ::= { iso(1) id-aa-ets-contentTimestamp OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) id-aa(2) 20} smime(16) id-aa(2) 20}
Content timestamp attribute values have ASN.1 type ContentTimestamp: Content timestamp attribute values have ASN.1 type ContentTimestamp:
ContentTimestamp::= TimeStampToken ContentTimestamp::= TimeStampToken
Internet Draft Electronic Signature Formats
The value of messageImprint field within TimeStampToken must be a hash The value of messageImprint field within TimeStampToken must be a hash
of the value of eContent field within encapContentInfo within the of the value of eContent field within encapContentInfo within the
signedData. signedData.
For further information and definition of TimeStampToken see [TSP]. For further information and definition of TimeStampToken see [TSP].
3.13 Support for Multiple Signatures 3.13 Support for Multiple Signatures
3.13.1 Independent Signatures 3.13.1 Independent Signatures
skipping to change at page 30, line 5 skipping to change at page 32, line 48
signature value, plus references to all the certificates and signature value, plus references to all the certificates and
revocation information used for full validation of the electronic revocation information used for full validation of the electronic
signature. signature.
The following optional eXtended forms of validation data are also The following optional eXtended forms of validation data are also
defined: defined:
* X-timestamp: There are two types of timestamp used in extended * X-timestamp: There are two types of timestamp used in extended
validation data defined by this document. validation data defined by this document.
Internet Draft Electronic Signature Formats
- Type 1 -Timestamp which comprises a timestamp over the ES - Type 1 -Timestamp which comprises a timestamp over the ES
with Complete validation data (ES-C). with Complete validation data (ES-C).
- Type 2 X-Timestamp which comprises of a timestamp over the - Type 2 X-Timestamp which comprises of a timestamp over the
certification path references and the revocation information certification path references and the revocation information
references used to support the ES-C. references used to support the ES-C.
Internet Draft Electronic Signature Formats
* X-Long : This comprises a Complete validation data * X-Long : This comprises a Complete validation data
plus the actual values of all the certificates and plus the actual values of all the certificates and
revocation information used in the ES-C. revocation information used in the ES-C.
* X-Long-Timestamp: This comprises a Type 1 or Type 2 * X-Long-Timestamp: This comprises a Type 1 or Type 2
X-Timestamp plus the actual values of all the X-Timestamp plus the actual values of all the
certificates and revocation information used in the certificates and revocation information used in the
ES-C. ES-C.
This clause also specifies the data structures used in Archive This clause also specifies the data structures used in Archive
skipping to change at page 39, line 18 skipping to change at page 42, line 18
- SigningCertificate: This must be set as defined - SigningCertificate: This must be set as defined
in clauses 3.8.1 and 3.8.2. in clauses 3.8.1 and 3.8.2.
* The following Attributes as defined in clause 3.9: * The following Attributes as defined in clause 3.9:
- SignaturePolicyIdentifier; This must always be present. - SignaturePolicyIdentifier; This must always be present.
* Public Key Certificates as defined in ITU-T Recommendation * Public Key Certificates as defined in ITU-T Recommendation
X.509 [1] and profiled in RFC 2459 [7] (see clause 9.1). X.509 [1] and profiled in RFC 2459 [7] (see clause 9.1).
6.2 Verifier 6.2 Verifier using timestamping
A system supporting verifiers according to this document must, at a A system supporting verifiers according to this document with
minimum, support: timestamping facilities must, at a minimum, support:
* Verification of the mandated components of an electronic * Verification of the mandated components of an electronic
signature, as defined in clause 14.1. signature, as defined in clause 5.1.
* Signature Timestamp attribute, as defined in clause 4.1.1. * Signature Timestamp attribute, as defined in clause 4.1.1.
* Complete Certificate Refs attribute, as defined in * Complete Certificate Refs attribute, as defined in
clause 4.2.1. clause 4.2.1.
* Complete Revocation Refs Attribute, as defined in * Complete Revocation Refs Attribute, as defined in
clause 4.2.2. clause 4.2.2.
* Public Key Certificates, as defined in ITU-T * Public Key Certificates, as defined in ITU-T
skipping to change at page 40, line 5 skipping to change at page 42, line 46
* Either of: * Either of:
- Certificate Revocation Lists. as defined in ITU-T - Certificate Revocation Lists. as defined in ITU-T
Recommendation X.509 [1] and profiled in RFC 2459 [7]; Recommendation X.509 [1] and profiled in RFC 2459 [7];
or or
- On-line Certificate Status Protocol responses, as - On-line Certificate Status Protocol responses, as
defined in RFC 2560. defined in RFC 2560.
6.3 Verifier using secure records
A system supporting verifiers according to the present document shall,
at a minimum, support:
* Verification of the mandated components of an electronic
signature, as defined in subclause 5.1.
* Complete Certificate Refs attribute, as defined in
subclause 4.2.1.
Internet Draft Electronic Signature Formats Internet Draft Electronic Signature Formats
* Complete Revocation Refs Attribute, as defined in
subclause 9.2.2.
* A record shall be maintained, which cannot be undetectably
modified, of the electronic signature and the time when the
signature was first validated using the referenced
certificates and revocation information.
* Public Key Certificates, as defined in ITU-T Recommendation
X.509 [1] and profiled in RFC 2459 [7] (see subclause 10.1).
* Either of:
- Certificate Revocation Lists. as defined in ITU-T
Recommendation X.509 [1] and profiled in RFC 2459 [7]
Or
- On-line Certificate Status Protocol, as defined
in RFC 2560 [8] (see subclause 10.3).
7. References 7. References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[ESS] P. Hoffman, "Enhanced Security Services for S/MIME", [ESS] P. Hoffman, "Enhanced Security Services for S/MIME",
[CMS] R. Housley, "Cryptographic Message Syntax", RFC 2630, [CMS] R. Housley, "Cryptographic Message Syntax", RFC 2630,
June 1999. June 1999.
skipping to change at page 40, line 40 skipping to change at page 44, line 5
(PKCS)", RSA Data Security Inc., Redwood City, California, November (PKCS)", RSA Data Security Inc., Redwood City, California, November
1993 Release. 1993 Release.
[ISONR] ISO/IEC 10181-5: Security Frameworks in Open Systems. [ISONR] ISO/IEC 10181-5: Security Frameworks in Open Systems.
Non-Repudiation Framework. April 1997. Non-Repudiation Framework. April 1997.
[ES201733] ETSI Standard ES 201 733 V1.1.3 (2000-05) Electronic [ES201733] ETSI Standard ES 201 733 V1.1.3 (2000-05) Electronic
Signature Formats. Note: copies of ETSI ES 210 733 can be freely Signature Formats. Note: copies of ETSI ES 210 733 can be freely
downloaded from the ETSI web site www.etsi.org. downloaded from the ETSI web site www.etsi.org.
Internet Draft Electronic Signature Formats
8. Authors' Addresses 8. Authors' Addresses
This Informational RFC has been produced in ETSI TC-SEC. This Informational RFC has been produced in ETSI TC-SEC.
ETSI ETSI
F-06921 Sophia Antipolis, Cedex - FRANCE F-06921 Sophia Antipolis, Cedex - FRANCE
650 Route des Lucioles - Sophia Antipolis 650 Route des Lucioles - Sophia Antipolis
Valbonne - France Valbonne - France
Tel: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Tel: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
secretariat@etsi.fr secretariat@etsi.fr
http://www.etsi.org http://www.etsi.org
Internet Draft Electronic Signature Formats
Contact Point Contact Point
Harri Rasilainen Harri Rasilainen
ETSI ETSI
650 Route des Lucioles 650 Route des Lucioles
F-06921 Sophia Antipolis, Cedex F-06921 Sophia Antipolis, Cedex
FRANCE FRANCE
harri.rasilainen@etsi.fr harri.rasilainen@etsi.fr
Denis Pinkas Denis Pinkas
skipping to change at page 41, line 40 skipping to change at page 45, line 5
ross@secstan.com ross@secstan.com
Nick Pope Nick Pope
Security & Standards Security & Standards
192 Moulsham Street 192 Moulsham Street
Chelmsford, Essex Chelmsford, Essex
CM2 0LG CM2 0LG
United Kingdom United Kingdom
pope@secstan.com pope@secstan.com
Internet Draft Electronic Signature Formats
9. Full Copyright Statement 9. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of developing Internet organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights defined Internet standards in which case the procedures for copyrights defined
in the Internet Standards process must be followed, or as required to in the Internet Standards process must be followed, or as required to
translate it into languages other than English. translate it into languages other than English.
Internet Draft Electronic Signature Formats
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
skipping to change at page 45, line 55 skipping to change at page 49, line 5
otherHash OtherHashAlgAndValue otherHash OtherHashAlgAndValue
} }
OtherHashValue ::= OCTET STRING OtherHashValue ::= OCTET STRING
OtherHashAlgAndValue ::= SEQUENCE { OtherHashAlgAndValue ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier, hashAlgorithm AlgorithmIdentifier,
hashValue OtherHashValue hashValue OtherHashValue
} }
Internet Draft Electronic Signature Formats
-- Signature Policy Identifier -- Signature Policy Identifier
id-aa-ets-sigPolicyId OBJECT IDENTIFIER ::= { iso(1) id-aa-ets-sigPolicyId OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-aa(2) 15 } smime(16) id-aa(2) 15 }
Internet Draft Electronic Signature Formats "SignaturePolicy CHOICE {
SignaturePolicyId SignaturePolicyId,
SignaturePolicyImplied SignaturePolicyImplied
}
SignaturePolicyIdentifier ::= SEQUENCE { SignaturePolicyId ::= SEQUENCE {
sigPolicyIdentifier SigPolicyId, sigPolicyIdentifier SigPolicyId,
sigPolicyHash SigPolicyHash, sigPolicyHash SigPolicyHash,
sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF
SigPolicyQualifierInfo OPTIONAL SigPolicyQualifierInfo OPTIONAL
} }
SignaturePolicyImplied ::= NULL
SigPolicyId ::= OBJECT IDENTIFIER SigPolicyId ::= OBJECT IDENTIFIER
SigPolicyHash ::= ETSIHashAlgAndValue SigPolicyHash ::= ETSIHashAlgAndValue
SigPolicyQualifierInfo ::= SEQUENCE { SigPolicyQualifierInfo ::= SEQUENCE {
sigPolicyQualifierId SigPolicyQualifierId, sigPolicyQualifierId SigPolicyQualifierId,
sigQualifier ANY DEFINED BY sigPolicyQualifierId sigQualifier ANY DEFINED BY sigPolicyQualifierId
} }
SigPolicyQualifierId ::= SigPolicyQualifierId ::=
skipping to change at page 46, line 36 skipping to change at page 50, line 5
id-spq-ets-uri OBJECT IDENTIFIER ::= { iso(1) id-spq-ets-uri OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-spq(5) 1 } smime(16) id-spq(5) 1 }
SPuri ::= IA5String SPuri ::= IA5String
id-spq-ets-unotice OBJECT IDENTIFIER ::= { iso(1) id-spq-ets-unotice OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-spq(5) 2 } smime(16) id-spq(5) 2 }
Internet Draft Electronic Signature Formats
SPUserNotice ::= SEQUENCE { SPUserNotice ::= SEQUENCE {
noticeRef NoticeReference OPTIONAL, noticeRef NoticeReference OPTIONAL,
explicitText DisplayText OPTIONAL explicitText DisplayText OPTIONAL
} }
NoticeReference ::= SEQUENCE { NoticeReference ::= SEQUENCE {
organization DisplayText, organization DisplayText,
noticeNumbers SEQUENCE OF INTEGER noticeNumbers SEQUENCE OF INTEGER
} }
DisplayText ::= CHOICE { DisplayText ::= CHOICE {
visibleString VisibleString (SIZE (1..200)), visibleString VisibleString (SIZE (1..200)),
bmpString BMPString (SIZE (1..200)), bmpString BMPString (SIZE (1..200)),
utf8String UTF8String (SIZE (1..200)) utf8String UTF8String (SIZE (1..200))
} }
Internet Draft Electronic Signature Formats
-- Optional Electronic Signature Attributes -- Optional Electronic Signature Attributes
-- Commitment Type -- Commitment Type
id-aa-ets-commitmentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-aa-ets-commitmentType OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 16} us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 16}
CommitmentTypeIndication ::= SEQUENCE { CommitmentTypeIndication ::= SEQUENCE {
commitmentTypeId CommitmentTypeIdentifier, commitmentTypeId CommitmentTypeIdentifier,
commitmentTypeQualifier SEQUENCE SIZE (1..MAX) OF commitmentTypeQualifier SEQUENCE SIZE (1..MAX) OF
skipping to change at page 47, line 39 skipping to change at page 51, line 5
cti(6) 1} cti(6) 1}
id-cti-ets-proofOfReceipt OBJECT IDENTIFIER ::= { iso(1) member- id-cti-ets-proofOfReceipt OBJECT IDENTIFIER ::= { iso(1) member-
body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
cti(6) 2} cti(6) 2}
id-cti-ets-proofOfDelivery OBJECT IDENTIFIER ::= { iso(1) member- id-cti-ets-proofOfDelivery OBJECT IDENTIFIER ::= { iso(1) member-
body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
cti(6) 3} cti(6) 3}
Internet Draft Electronic Signature Formats
id-cti-ets-proofOfSender OBJECT IDENTIFIER ::= { iso(1) member- id-cti-ets-proofOfSender OBJECT IDENTIFIER ::= { iso(1) member-
body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
cti(6) 4} cti(6) 4}
id-cti-ets-proofOfApproval OBJECT IDENTIFIER ::= { iso(1) member- id-cti-ets-proofOfApproval OBJECT IDENTIFIER ::= { iso(1) member-
body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
cti(6) 5} cti(6) 5}
id-cti-ets-proofOfCreation OBJECT IDENTIFIER ::= { iso(1) member- id-cti-ets-proofOfCreation OBJECT IDENTIFIER ::= { iso(1) member-
body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
cti(6) 6} cti(6) 6}
Internet Draft Electronic Signature Formats
-- Signer Location -- Signer Location
id-aa-ets-signerLocation OBJECT IDENTIFIER ::= { iso(1) member- id-aa-ets-signerLocation OBJECT IDENTIFIER ::= { iso(1) member-
body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
id-aa(2) 17} id-aa(2) 17}
SignerLocation ::= SEQUENCE { SignerLocation ::= SEQUENCE {
-- at least one of the following must be present -- at least one of the following must be present
countryName [0] DirectoryString OPTIONAL, countryName [0] DirectoryString OPTIONAL,
-- as used to name a Country in X.500 -- as used to name a Country in X.500
skipping to change at page 48, line 39 skipping to change at page 52, line 5
SignerAttribute ::= SEQUENCE OF CHOICE { SignerAttribute ::= SEQUENCE OF CHOICE {
claimedAttributes [0] ClaimedAttributes, claimedAttributes [0] ClaimedAttributes,
certifiedAttributes [1] CertifiedAttributes certifiedAttributes [1] CertifiedAttributes
} }
ClaimedAttributes ::= SEQUENCE OF Attribute ClaimedAttributes ::= SEQUENCE OF Attribute
CertifiedAttributes ::= AttributeCertificate -- as defined in X.509 : CertifiedAttributes ::= AttributeCertificate -- as defined in X.509 :
see section 10.3 see section 10.3
Internet Draft Electronic Signature Formats
-- Content Timestamp -- Content Timestamp
id-aa-ets-contentTimestamp OBJECT IDENTIFIER ::= { iso(1) member- id-aa-ets-contentTimestamp OBJECT IDENTIFIER ::= { iso(1) member-
body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
id-aa(2) 20} id-aa(2) 20}
ContentTimestamp::= TimeStampToken ContentTimestamp::= TimeStampToken
-- Validation Data -- Validation Data
-- Signature Timestamp -- Signature Timestamp
id-aa-signatureTimeStampToken OBJECT IDENTIFIER ::= { iso(1) id-aa-signatureTimeStampToken OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
id-aa(2) 14} id-aa(2) 14}
SignatureTimeStampToken ::= TimeStampToken SignatureTimeStampToken ::= TimeStampToken
Internet Draft Electronic Signature Formats
-- Complete Certificate Refs. -- Complete Certificate Refs.
id-aa-ets-certificateRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-aa-ets-certificateRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 21} us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 21}
CompleteCertificateRefs ::= SEQUENCE OF OTHERCertID CompleteCertificateRefs ::= SEQUENCE OF OTHERCertID
-- Complete Revocation Refs -- Complete Revocation Refs
id-aa-ets-revocationRefs OBJECT IDENTIFIER ::= { iso(1) member- id-aa-ets-revocationRefs OBJECT IDENTIFIER ::= { iso(1) member-
skipping to change at page 49, line 36 skipping to change at page 53, line 5
} }
CRLListID ::= SEQUENCE { CRLListID ::= SEQUENCE {
crls SEQUENCE OF CrlValidatedID} crls SEQUENCE OF CrlValidatedID}
CrlValidatedID ::= SEQUENCE { CrlValidatedID ::= SEQUENCE {
crlHash ETSIHash, crlHash ETSIHash,
crlIdentifier CrlIdentifier OPTIONAL crlIdentifier CrlIdentifier OPTIONAL
} }
Internet Draft Electronic Signature Formats
CrlIdentifier ::= SEQUENCE { CrlIdentifier ::= SEQUENCE {
crlissuer Name, crlissuer Name,
crlIssuedTime UTCTime, crlIssuedTime UTCTime,
crlNumber INTEGER OPTIONAL crlNumber INTEGER OPTIONAL
} }
OcspListID ::= SEQUENCE { OcspListID ::= SEQUENCE {
ocspResponses SEQUENCE OF OcspResponsesID} ocspResponses SEQUENCE OF OcspResponsesID}
OcspResponsesID ::= SEQUENCE { OcspResponsesID ::= SEQUENCE {
skipping to change at page 50, line 5 skipping to change at page 53, line 28
ocspRepHash ETSIHash OPTIONAL ocspRepHash ETSIHash OPTIONAL
} }
OcspIdentifier ::= SEQUENCE { OcspIdentifier ::= SEQUENCE {
ocspResponderID ResponderID, ocspResponderID ResponderID,
-- as in OCSP response data -- as in OCSP response data
producedAt GeneralizedTime producedAt GeneralizedTime
-- as in OCSP response data -- as in OCSP response data
} }
Internet Draft Electronic Signature Formats
OtherRevRefs ::= SEQUENCE { OtherRevRefs ::= SEQUENCE {
otherRevRefType OtherRevRefType, otherRevRefType OtherRevRefType,
otherRevRefs ANY DEFINED BY otherRevRefType otherRevRefs ANY DEFINED BY otherRevRefType
} }
OtherRevRefType ::= OBJECT IDENTIFIER OtherRevRefType ::= OBJECT IDENTIFIER
-- Certificate Values -- Certificate Values
id-aa-ets-certValues OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-aa-ets-certValues OBJECT IDENTIFIER ::= { iso(1) member-body(2)
skipping to change at page 50, line 33 skipping to change at page 54, line 5
id-aa-ets-revocationValues OBJECT IDENTIFIER ::= { iso(1) member- id-aa-ets-revocationValues OBJECT IDENTIFIER ::= { iso(1) member-
body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
id-aa(2) 24} id-aa(2) 24}
RevocationValues ::= SEQUENCE { RevocationValues ::= SEQUENCE {
crlVals [0] SEQUENCE OF CertificateList OPTIONAL, crlVals [0] SEQUENCE OF CertificateList OPTIONAL,
ocspVals [1] SEQUENCE OF BasicOCSPResponse OPTIONAL, ocspVals [1] SEQUENCE OF BasicOCSPResponse OPTIONAL,
otherRevVals [2] OtherRevVals otherRevVals [2] OtherRevVals
} }
Internet Draft Electronic Signature Formats
OtherRevVals ::= SEQUENCE { OtherRevVals ::= SEQUENCE {
otherRevValType OtherRevValType, otherRevValType OtherRevValType,
otherRevVals ANY DEFINED BY otherRevValType otherRevVals ANY DEFINED BY otherRevValType
} }
OtherRevValType ::= OBJECT IDENTIFIER OtherRevValType ::= OBJECT IDENTIFIER
-- ES-C Timestamp -- ES-C Timestamp
id-aa-ets-escTimeStamp OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-aa-ets-escTimeStamp OBJECT IDENTIFIER ::= { iso(1) member-body(2)
skipping to change at page 51, line 5 skipping to change at page 54, line 29
ESCTimeStampToken ::= TimeStampToken ESCTimeStampToken ::= TimeStampToken
-- Time-Stamped Certificates and CRLs -- Time-Stamped Certificates and CRLs
id-aa-ets-certCRLTimestamp OBJECT IDENTIFIER ::= { iso(1) member- id-aa-ets-certCRLTimestamp OBJECT IDENTIFIER ::= { iso(1) member-
body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
id-aa(2) 26} id-aa(2) 26}
TimestampedCertsCRLs ::= TimeStampToken TimestampedCertsCRLs ::= TimeStampToken
Internet Draft Electronic Signature Formats
-- Archive Timestamp -- Archive Timestamp
id-aa-ets-archiveTimestamp OBJECT IDENTIFIER ::= { iso(1) member- id-aa-ets-archiveTimestamp OBJECT IDENTIFIER ::= { iso(1) member-
body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
id-aa(2) 27} id-aa(2) 27}
ArchiveTimeStampToken ::= TimeStampToken ArchiveTimeStampToken ::= TimeStampToken
END -- ETS-ElectronicSignatureFormats-88syntax -- END -- ETS-ElectronicSignatureFormats-88syntax --
skipping to change at page 54, line 51 skipping to change at page 57, line 51
hashAlgorithm AlgorithmIdentifier, hashAlgorithm AlgorithmIdentifier,
hashValue OtherHashValue hashValue OtherHashValue
} }
-- Signature Policy Identifier -- Signature Policy Identifier
id-aa-ets-sigPolicyId OBJECT IDENTIFIER ::= { iso(1) id-aa-ets-sigPolicyId OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-aa(2) 15 } smime(16) id-aa(2) 15 }
SignaturePolicyIdentifier ::= SEQUENCE { "SignaturePolicy CHOICE {
SignaturePolicyId SignaturePolicyId,
SignaturePolicyImplied SignaturePolicyImplied
}
Internet Draft Electronic Signature Formats
SignaturePolicyId ::= SEQUENCE {
sigPolicyIdentifier SigPolicyId, sigPolicyIdentifier SigPolicyId,
sigPolicyHash SigPolicyHash, sigPolicyHash SigPolicyHash,
sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF
SigPolicyQualifierInfo OPTIONAL SigPolicyQualifierInfo OPTIONAL
} }
SigPolicyId ::= OBJECT IDENTIFIER SignaturePolicyImplied ::= NULL
Internet Draft Electronic Signature Formats SigPolicyId ::= OBJECT IDENTIFIER
SigPolicyHash ::= ETSIHashAlgAndValue SigPolicyHash ::= ETSIHashAlgAndValue
SigPolicyQualifierInfo ::= SEQUENCE { SigPolicyQualifierInfo ::= SEQUENCE {
sigPolicyQualifierId SIG-POLICY-QUALIFIER.&id sigPolicyQualifierId SIG-POLICY-QUALIFIER.&id
({SupportedSigPolicyQualifiers}), ({SupportedSigPolicyQualifiers}),
qualifier SIG-POLICY-QUALIFIER.&Qualifier qualifier SIG-POLICY-QUALIFIER.&Qualifier
({SupportedSigPolicyQualifiers} ({SupportedSigPolicyQualifiers}
{@sigPolicyQualifierId})OPTIONAL } {@sigPolicyQualifierId})OPTIONAL }
skipping to change at page 55, line 41 skipping to change at page 59, line 5
pointerToSigPolSpec SIG-POLICY-QUALIFIER ::= { pointerToSigPolSpec SIG-POLICY-QUALIFIER ::= {
SIG-POLICY-QUALIFIER-ID id-sqt-uri SIG-QUALIFIER-TYPE SPuri } SIG-POLICY-QUALIFIER-ID id-sqt-uri SIG-QUALIFIER-TYPE SPuri }
id-spq-ets-uri OBJECT IDENTIFIER ::= { iso(1) id-spq-ets-uri OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-spq(5) 1 } smime(16) id-spq(5) 1 }
SPuri ::= IA5String SPuri ::= IA5String
Internet Draft Electronic Signature Formats
id-spq-ets-unotice OBJECT IDENTIFIER ::= { iso(1) id-spq-ets-unotice OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-spq(5) 2 } smime(16) id-spq(5) 2 }
SPUserNotice ::= SEQUENCE { SPUserNotice ::= SEQUENCE {
noticeRef NoticeReference OPTIONAL, noticeRef NoticeReference OPTIONAL,
explicitText DisplayText OPTIONAL explicitText DisplayText OPTIONAL
} }
NoticeReference ::= SEQUENCE { NoticeReference ::= SEQUENCE {
organization DisplayText, organization DisplayText,
noticeNumbers SEQUENCE OF INTEGER noticeNumbers SEQUENCE OF INTEGER
} }
DisplayText ::= CHOICE { DisplayText ::= CHOICE {
visibleString VisibleString (SIZE (1..200)), visibleString VisibleString (SIZE (1..200)),
bmpString BMPString (SIZE (1..200)), bmpString BMPString (SIZE (1..200)),
utf8String UTF8String (SIZE (1..200)) utf8String UTF8String (SIZE (1..200))
} }
Internet Draft Electronic Signature Formats
-- Optional Electronic Signature Attributes -- Optional Electronic Signature Attributes
-- Commitment Type -- Commitment Type
id-aa-ets-commitmentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-aa-ets-commitmentType OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 16} us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 16}
CommitmentTypeIndication ::= SEQUENCE { CommitmentTypeIndication ::= SEQUENCE {
commitmentTypeId CommitmentTypeIdentifier, commitmentTypeId CommitmentTypeIdentifier,
commitmentTypeQualifier SEQUENCE SIZE (1..MAX) OF commitmentTypeQualifier SEQUENCE SIZE (1..MAX) OF
skipping to change at page 56, line 38 skipping to change at page 60, line 5
&id OBJECT IDENTIFIER UNIQUE, &id OBJECT IDENTIFIER UNIQUE,
&Qualifier OPTIONAL } &Qualifier OPTIONAL }
WITH SYNTAX { WITH SYNTAX {
COMMITMENT-QUALIFIER-ID &id COMMITMENT-QUALIFIER-ID &id
[COMMITMENT-TYPE &Qualifier] } [COMMITMENT-TYPE &Qualifier] }
id-cti-ets-proofOfOrigin OBJECT IDENTIFIER ::= { iso(1) id-cti-ets-proofOfOrigin OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) cti(6) 1} smime(16) cti(6) 1}
Internet Draft Electronic Signature Formats
id-cti-ets-proofOfReceipt OBJECT IDENTIFIER ::= { iso(1) id-cti-ets-proofOfReceipt OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) cti(6) 2} smime(16) cti(6) 2}
id-cti-ets-proofOfDelivery OBJECT IDENTIFIER ::= { iso(1) id-cti-ets-proofOfDelivery OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) cti(6) 3} smime(16) cti(6) 3}
id-cti-ets-proofOfSender OBJECT IDENTIFIER ::= { iso(1) id-cti-ets-proofOfSender OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) cti(6) 4} smime(16) cti(6) 4}
id-cti-ets-proofOfApproval OBJECT IDENTIFIER ::= { iso(1) id-cti-ets-proofOfApproval OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) cti(6) 5} smime(16) cti(6) 5}
id-cti-ets-proofOfCreation OBJECT IDENTIFIER ::= { iso(1) id-cti-ets-proofOfCreation OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) cti(6) 6} smime(16) cti(6) 6}
Internet Draft Electronic Signature Formats
-- Signer Location -- Signer Location
id-aa-ets-signerLocation OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-aa-ets-signerLocation OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 17} us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 17}
SignerLocation ::= SEQUENCE { SignerLocation ::= SEQUENCE {
-- at least one of the following must be present -- at least one of the following must be present
countryName [0] DirectoryString OPTIONAL, countryName [0] DirectoryString OPTIONAL,
-- As used to name a Country in X.500 -- As used to name a Country in X.500
localityName [1] DirectoryString OPTIONAL, localityName [1] DirectoryString OPTIONAL,
skipping to change at page 57, line 36 skipping to change at page 61, line 5
SignerAttribute ::= SEQUENCE OF CHOICE { SignerAttribute ::= SEQUENCE OF CHOICE {
claimedAttributes [0] ClaimedAttributes, claimedAttributes [0] ClaimedAttributes,
certifiedAttributes [1] CertifiedAttributes } certifiedAttributes [1] CertifiedAttributes }
ClaimedAttributes ::= SEQUENCE OF Attribute ClaimedAttributes ::= SEQUENCE OF Attribute
CertifiedAttributes ::= AttributeCertificate CertifiedAttributes ::= AttributeCertificate
-- As defined in X.509 : see section 10.3 -- As defined in X.509 : see section 10.3
Internet Draft Electronic Signature Formats
-- Content Timestamp -- Content Timestamp
id-aa-ets-contentTimestamp OBJECT IDENTIFIER ::= { iso(1) id-aa-ets-contentTimestamp OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) id-aa(2) 20} smime(16) id-aa(2) 20}
ContentTimestamp::= TimeStampToken ContentTimestamp::= TimeStampToken
-- Validation Data -- Validation Data
-- Signature Timestamp -- Signature Timestamp
id-aa-signatureTimeStampToken OBJECT IDENTIFIER ::= { iso(1) id-aa-signatureTimeStampToken OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) id-aa(2) 14} smime(16) id-aa(2) 14}
SignatureTimeStampToken ::= TimeStampToken SignatureTimeStampToken ::= TimeStampToken
Internet Draft Electronic Signature Formats
-- Complete Certificate Refs. -- Complete Certificate Refs.
id-aa-ets-certificateRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-aa-ets-certificateRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 21} us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 21}
CompleteCertificateRefs ::= SEQUENCE OF OTHERCertID CompleteCertificateRefs ::= SEQUENCE OF OTHERCertID
-- Complete Revocation Refs -- Complete Revocation Refs
id-aa-ets-revocationRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-aa-ets-revocationRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2)
skipping to change at page 58, line 40 skipping to change at page 62, line 5
CrlValidatedID ::= SEQUENCE { CrlValidatedID ::= SEQUENCE {
crlHash ETSIHash, crlHash ETSIHash,
crlIdentifier CrlIdentifier OPTIONAL} crlIdentifier CrlIdentifier OPTIONAL}
CrlIdentifier ::= SEQUENCE { CrlIdentifier ::= SEQUENCE {
crlissuer Name, crlissuer Name,
crlIssuedTime UTCTime, crlIssuedTime UTCTime,
crlNumber INTEGER OPTIONAL crlNumber INTEGER OPTIONAL
} }
Internet Draft Electronic Signature Formats
OcspListID ::= SEQUENCE { OcspListID ::= SEQUENCE {
ocspResponses SEQUENCE OF OcspResponsesID} ocspResponses SEQUENCE OF OcspResponsesID}
OcspResponsesID ::= SEQUENCE { OcspResponsesID ::= SEQUENCE {
ocspIdentifier OcspIdentifier, ocspIdentifier OcspIdentifier,
ocspRepHash ETSIHash OPTIONAL ocspRepHash ETSIHash OPTIONAL
} }
OcspIdentifier ::= SEQUENCE { OcspIdentifier ::= SEQUENCE {
ocspResponderID ResponderID, ocspResponderID ResponderID,
-- As in OCSP response data -- As in OCSP response data
producedAt GeneralizedTime producedAt GeneralizedTime
-- As in OCSP response data -- As in OCSP response data
} }
Internet Draft Electronic Signature Formats
OtherRevRefs ::= SEQUENCE { OtherRevRefs ::= SEQUENCE {
otherRevRefType OTHER-REVOCATION-REF.&id, otherRevRefType OTHER-REVOCATION-REF.&id,
otherRevRefs OTHER-REVOCATION-REF.&Type otherRevRefs OTHER-REVOCATION-REF.&Type
} }
OTHER-REVOCATION-REF ::= CLASS { OTHER-REVOCATION-REF ::= CLASS {
&Type, &Type,
&id OBJECT IDENTIFIER UNIQUE } &id OBJECT IDENTIFIER UNIQUE }
WITH SYNTAX { WITH SYNTAX {
&Type ID &id } &Type ID &id }
skipping to change at page 59, line 41 skipping to change at page 63, line 5
RevocationValues ::= SEQUENCE { RevocationValues ::= SEQUENCE {
crlVals [0] SEQUENCE OF CertificateList OPTIONAL, crlVals [0] SEQUENCE OF CertificateList OPTIONAL,
ocspVals [1] SEQUENCE OF BasicOCSPResponse OPTIONAL, ocspVals [1] SEQUENCE OF BasicOCSPResponse OPTIONAL,
otherRevVals [2] OtherRevVals } otherRevVals [2] OtherRevVals }
OtherRevVals ::= SEQUENCE { OtherRevVals ::= SEQUENCE {
otherRevValType OTHER-REVOCATION-VAL.&id, otherRevValType OTHER-REVOCATION-VAL.&id,
otherRevVals OTHER-REVOCATION-VAL.&Type otherRevVals OTHER-REVOCATION-VAL.&Type
} }
Internet Draft Electronic Signature Formats
OTHER-REVOCATION-VAL ::= CLASS { OTHER-REVOCATION-VAL ::= CLASS {
&Type, &Type,
&id OBJECT IDENTIFIER UNIQUE } &id OBJECT IDENTIFIER UNIQUE }
WITH SYNTAX { WITH SYNTAX {
&Type ID &id } &Type ID &id }
-- ES-C Timestamp -- ES-C Timestamp
id-aa-ets-escTimeStamp OBJECT IDENTIFIER ::= { iso(1) id-aa-ets-escTimeStamp OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) id-aa(2) 25} smime(16) id-aa(2) 25}
ESCTimeStampToken ::= TimeStampToken ESCTimeStampToken ::= TimeStampToken
Internet Draft Electronic Signature Formats
-- Time-Stamped Certificates and CRLs -- Time-Stamped Certificates and CRLs
id-aa-ets-certCRLTimestamp OBJECT IDENTIFIER ::= { iso(1) id-aa-ets-certCRLTimestamp OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) id-aa(2) 26} smime(16) id-aa(2) 26}
TimestampedCertsCRLs ::= TimeStampToken TimestampedCertsCRLs ::= TimeStampToken
-- Archive Timestamp -- Archive Timestamp
skipping to change at page 61, line 29 skipping to change at page 64, line 29
The signature policy is a set of rules for the creation and validation The signature policy is a set of rules for the creation and validation
of an electronic signature, under which the signature can be of an electronic signature, under which the signature can be
determined to be valid. A given legal/contractual context may determined to be valid. A given legal/contractual context may
recognize a particular signature policy as meeting its requirements. recognize a particular signature policy as meeting its requirements.
A signature policy may be issued, for example, by a party relying on A signature policy may be issued, for example, by a party relying on
the electronic signatures and selected by the signer for use with that the electronic signatures and selected by the signer for use with that
relying party. Alternatively, a signature policy may be established relying party. Alternatively, a signature policy may be established
through an electronic trading association for use amongst its members. through an electronic trading association for use amongst its members.
Both the signer and verifier use the same signature policy. Both the signer and verifier use the same signature policy.
A signature policy has a globally unique reference, which is bound to The signature policy may be explicitly identified or may be implied by
an electronic signature by the signer as part of the signature the semantics of the data being signed and other external data like a
contract being referenced which itself refers to a signature policy.
An explicit signature policy has a globally unique reference, which is
bound to an electronic signature by the signer as part of the signature
calculation. calculation.
The signature policy needs to be available in human readable form so The signature policy needs to be available in human readable form so
that it can be assessed to meet the requirements of the legal and that it can be assessed to meet the requirements of the legal and
contractual context in which it is being applied. To facilitate the contractual context in which it is being applied. To facilitate the
automatic processing of an electronic signature the parts of the automatic processing of an electronic signature the parts of the
signature policy which specify the electronic rules for the creation signature policy which specify the electronic rules for the creation
and validation of the electronic signature also needs to be in a and validation of the electronic signature also needs to be in a
computer processable form. computer processable form.
skipping to change at page 61, line 54 skipping to change at page 65, line 5
to the signer or the verifiers. to the signer or the verifiers.
* Rules, which apply to functionality, covered by this document * Rules, which apply to functionality, covered by this document
(referred to as the Signature Validation Policy). (referred to as the Signature Validation Policy).
* Rules which may be implied through adoption of Certificate * Rules which may be implied through adoption of Certificate
Policies that apply to the electronic signature (e.g. rules for Policies that apply to the electronic signature (e.g. rules for
ensuring the secrecy of the private signing key). ensuring the secrecy of the private signing key).
* Rules, which relate to the environment used by the signer, * Rules, which relate to the environment used by the signer,
e.g. the use of an agreed CAD (Card Accepting Device) used e.g. the use of an agreed CAD (Card Accepting Device) used
in conjunction with a smart card. in conjunction with a smart card.
The Signature Validation Policy may be structured so that it can be
computer processable. Any format of the signature validation policy
is allowed by this document. However, for a given signature policy
there must be one definitive form that has a unique binary encoded
value.
Internet Draft Electronic Signature Formats Internet Draft Electronic Signature Formats
An explicit Signature Validation Policy may be structured so that it
can be computer processable. Any format of the signature validation
policy is allowed by this document. However, for a given explicit
signature policy there must be one definitive form that has a unique
binary encoded value.
The Signature Validation Policy includes rules regarding use of TSPs The Signature Validation Policy includes rules regarding use of TSPs
(CA, Attribute Authorities, Time Stamping Authorities) as well as (CA, Attribute Authorities, Time Stamping Authorities) as well as
rules defining the components of the electronic signature that must be rules defining the components of the electronic signature that must be
provided by the signer with data required by the verifier to provide provided by the signer with data required by the verifier to provide
long term proof. long term proof.
B.2 Signed Information B.2 Signed Information
The information being signed may be defined as a MIME-encapsulated The information being signed may be defined as a MIME-encapsulated
message which can be used to signal the format of the content in order message which can be used to signal the format of the content in order
skipping to change at page 62, line 33 skipping to change at page 65, line 39
B.3.1 Reference to the Signature Policy B.3.1 Reference to the Signature Policy
The definition of electronic signature includes: "a commitment has The definition of electronic signature includes: "a commitment has
been explicitly endorsed under a "Signature policy", at a given time, 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 by a signer under an identifier, e.g. a name or a pseudonym, and
optionally a role". optionally a role".
When two independent parties want to evaluate an electronic signature, When two independent parties want to evaluate an electronic signature,
it is fundamental that they get the same result. To meet this it is fundamental that they get the same result. To meet this
requirement the technical components and technical aspects used in requirement same signature policy must be used by the signer and
creating the signature must be referenced, this is provided by a verifier.
reference to the "Signature Validation Policy". The "Signature
Validation Policy" defines:
* the components of an electronic signature to be provided by the
signer;
* any additional components (i.e. verifier components) used to The signature policy may be explicitly identified or may be implied by
validate an electronic signature at the time of receipt by a the semantics of the data being signed and other external data which
verifier and later by an arbitrator, auditor or other designate the signature policy to be used.
independent parties.
By signing over the signature policy identifier, the algorithm By signing over the signature policy identifier the signer explicitly
identifier and the hash of the signature policy, the signer explicitly
indicates that he or she has applied the signature policy in creating indicates that he or she has applied the signature policy in creating
the signature. Thus, undertakes any commitments implied by the the signature. Thus, undertakes any explicit or implied commitments.
signature policy, any indication of commitment type included in the
electronic signature, and the user data that is signed.
The hash algorithm identifier and value is included to ensure that In order to unambiguously identify an explicit signature policy that is
both the signer and verifier use exactly the same signature policy. to be used to verify the signature an identifier and hash of the
This unambiguously binds the signer and verifier to same definitive "Signature policy" shall be part of the signed data. Additional
form of the signature policy has a unique binary encoding. information about the explicit policy (e.g. web reference to the
document) may be carried as "qualifiers" to the signature policy
identifier.
Internet Draft Electronic Signature Formats Internet Draft Electronic Signature Formats
When the signature policy not explicitly identified, but is implied by
the semantics of the data being signed, then the signature will include
a signature policy identifier that indicates that the signature policy
is implied. In this case the verification rules must be determined by
using other external data which will designate the signature policy to
be used. If it may be determined from the context that all the
documents to be verified refer to the same signature policy, then that
policy may be predetermined or fixed within the application.
In order to identify unambiguously the "Signature Validation Policy" In order to identify unambiguously the "Signature Validation Policy"
to be used to verify the signature an identifier and hash of the to be used to verify the signature an identifier and hash of the
"Signature policy" must be part of the signed data. Additional "Signature policy" must be part of the signed data. Additional
information about the policy (e.g. web reference to the document) may information about the policy (e.g. web reference to the document) may
be carried as "qualifiers" to the signature policy identifier. be carried as "qualifiers" to the signature policy identifier.
B.3.2 Commitment Type Indication B.3.2 Commitment Type Indication
The definition of electronic signature includes: "a commitment has The definition of electronic signature includes: "a commitment has
been explicitly endorsed under a signature policy, at a given time, been explicitly endorsed under a signature policy, at a given time,
skipping to change at page 63, line 50 skipping to change at page 67, line 5
signed is outside the scope of this document. signed is outside the scope of this document.
NOTE: Examples of commitment indicated through the semantics of the NOTE: Examples of commitment indicated through the semantics of the
data being signed, are: data being signed, are:
* An explicit commitment made by the signer indicated by the type * An explicit commitment made by the signer indicated by the type
of data being signed over. Thus, the data structure being of data being signed over. Thus, the data structure being
signed can have an explicit commitment within the context of signed can have an explicit commitment within the context of
the application (e.g. EDIFACT purchase order). the application (e.g. EDIFACT purchase order).
Internet Draft Electronic Signature Formats
* An implicit commitment which is a commitment made by the signer * An implicit commitment which is a commitment made by the signer
because the data being signed over has specific semantics because the data being signed over has specific semantics
(meaning) which is only interpretable by humans, (i.e. free (meaning) which is only interpretable by humans, (i.e. free
text). text).
Internet Draft Electronic Signature Formats
B.3.3 Certificate Identifier from the Signer B.3.3 Certificate Identifier from the Signer
The definition of the ETSI electronic signature includes: "a The definition of the ETSI electronic signature includes: "a
commitment has been explicitly endorsed under a signature policy, 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 at a given time, by a signer under an identifier, e.g. a name or a
pseudonym, and optionally a role." pseudonym, and optionally a role."
In many real life environments users will be able to get from In many real life environments users will be able to get from
different CAs or even from the same CA, different certificates different CAs or even from the same CA, different certificates
containing the same public key for different names. The prime containing the same public key for different names. The prime
skipping to change at page 64, line 52 skipping to change at page 68, line 5
identified. It requires all CAs to perform a Proof Of Possession of identified. It requires all CAs to perform a Proof Of Possession of
the private key at the time of registration. The problem with that the private key at the time of registration. The problem with that
technique is that it does not provide any guarantee at the time of technique is that it does not provide any guarantee at the time of
verification and only some proof "after the event" may be obtained, if verification and only some proof "after the event" may be obtained, if
and only if the CA keeps the Proof Of Possession in audit trail. and only if the CA keeps the Proof Of Possession in audit trail.
In order to identify unambiguously the certificate to be used for the In order to identify unambiguously the certificate to be used for the
verification of the signature an identifier of the certificate from verification of the signature an identifier of the certificate from
the signer must be part of the signed data. the signer must be part of the signed data.
Internet Draft Electronic Signature Formats
B.3.4 Role Attributes B.3.4 Role Attributes
The definition of electronic signature includes: "a commitment has The definition of electronic signature includes: "a commitment has
been explicitly endorsed under a non repudiation security policy, been explicitly endorsed under a non repudiation security policy,
at a given time, by a signer under an identifier, e.g. a name or a at a given time, by a signer under an identifier, e.g. a name or a
pseudonym, and optionally a role. " pseudonym, and optionally a role. "
Internet Draft Electronic Signature Formats
While the name of the signer is important, the position of the signer While the name of the signer is important, the position of the signer
within a company or an organization can be even more important. Some within a company or an organization can be even more important. Some
contracts may only be valid if signed by a user in a particular role, contracts may only be valid if signed by a user in a particular role,
e.g. a Sales Director. In many cases whom the sales Director really e.g. a Sales Director. In many cases whom the sales Director really
is, is not that important but being sure that the signer is empowered is, is not that important but being sure that the signer is empowered
by his company to be the Sales Director is fundamental. by his company to be the Sales Director is fundamental.
This document defines two different ways for providing this feature: This document defines two different ways for providing this feature:
* by placing a claimed role name in the CMS signed * by placing a claimed role name in the CMS signed
skipping to change at page 65, line 47 skipping to change at page 69, line 5
B.3.5.2 Certified Role B.3.5.2 Certified Role
Unlike public key certificates that bind an identifier to a public Unlike public key certificates that bind an identifier to a public
key, Attribute Certificates bind the identifier of a certificate to key, Attribute Certificates bind the identifier of a certificate to
some attributes, like a role. An Attribute Certificate is NOT issued some attributes, like a role. An Attribute Certificate is NOT issued
by a CA but by an Attribute Authority (AA). The Attribute Authority by a CA but by an Attribute Authority (AA). The Attribute Authority
will be most of the time under the control of an organization or a will be most of the time under the control of an organization or a
company that is best placed to know which attributes are relevant for company that is best placed to know which attributes are relevant for
which individual. which individual.
Internet Draft Electronic Signature Formats
The Attribute Authority may use or point to public key certificates The Attribute Authority may use or point to public key certificates
issued by any CA, provided that the appropriate trust may be placed issued by any CA, provided that the appropriate trust may be placed
in that CA. Attribute Certificates may have various periods of in that CA. Attribute Certificates may have various periods of
validity. That period may be quite short, e.g. one day. While this validity. That period may be quite short, e.g. one day. While this
requires that a new Attribute Certificate is obtained every day, valid requires that a new Attribute Certificate is obtained every day, valid
for that day, this can be advantageous since revocation of such for that day, this can be advantageous since revocation of such
certificates may not be needed. When signing, the signer will have to certificates may not be needed. When signing, the signer will have to
specify which Attribute Certificate it selects. In order to do specify which Attribute Certificate it selects. In order to do
so, the Attribute Certificate will have to be included in the signed so, a reference to the Attribute Certificate will have to be included
data in order to be protected by the digital signature from the signer. in the signed data in order to be protected by the digital signature
from the signer.
Internet Draft Electronic Signature Formats
In order to identify unambiguously the attribute certificate(s) to be In order to identify unambiguously the attribute certificate(s) to be
used for the verification of the signature an identifier of the used for the verification of the signature an identifier of the
attribute certificate(s) from the signer must be part of the signed attribute certificate(s) from the signer must be part of the signed
data. data.
B.3.5 Signer Location B.3.5 Signer Location
In some transactions the purported location of the signer at the time In some transactions the purported location of the signer at the time
he or she applies his signature may need to be indicated. For this he or she applies his signature may need to be indicated. For this
skipping to change at page 66, line 48 skipping to change at page 70, line 5
advantage that electronic signatures can be generated without any on- advantage that electronic signatures can be generated without any on-
line connection to a trusted time source (i.e. they may be generated line connection to a trusted time source (i.e. they may be generated
off-line). off-line).
Thus two dates and two signatures are required: Thus two dates and two signatures are required:
* a signing time indicated by the signer and which is part of * a signing time indicated by the signer and which is part of
the data signed by the signer (i.e. part of the basic the data signed by the signer (i.e. part of the basic
electronic signature); electronic signature);
Internet Draft Electronic Signature Formats
* a time indicated by a TimeStamping Authority (TSA) which is * a time indicated by a TimeStamping Authority (TSA) which is
signed over the digital signature value of the basic electronic signed over the digital signature value of the basic electronic
signature. The signer, verifier or both may obtain the TSA signature. The signer, verifier or both may obtain the TSA
timestamp. timestamp.
In order for an electronic signature to be valid under a signature In order for an electronic signature to be valid under a signature
policy, it must be timestamped by a TSA where the signing time as policy, it must be timestamped by a TSA where the signing time as
indicated by the signer and the time of time stamping as indicated by indicated by the signer and the time of time stamping as indicated by
a TSA must be "close enough" to meet the requirements of the signature a TSA must be "close enough" to meet the requirements of the signature
validation policy. validation policy.
Internet Draft Electronic Signature Formats
"Close enough" means a few minutes, hours or even days according to "Close enough" means a few minutes, hours or even days according to
the "Signature Validation Policy". the "Signature Validation Policy".
NOTE: The need for Timestamping is further explained in clause B.4.5. NOTE: The need for Timestamping is further explained in clause B.4.5.
A further optional attribute is defined in this document to timestamp A further optional attribute is defined in this document to timestamp
the content, to provide proof of the existence of the content, at the the content, to provide proof of the existence of the content, at the
time indicated by the timestamp. time indicated by the timestamp.
Using this optional attribute a trusted secure time may be obtained Using this optional attribute a trusted secure time may be obtained
before the document is signed and included under the digital signature. before the document is signed and included under the digital signature.
This solution requires an on-line connection to a trusted timestamping This solution requires an on-line connection to a trusted timestamping
service before generating the signature and may not represent the service before generating the signature and may not represent the
precise signing time, since it can be obtained in advance. However, precise signing time, since it can be obtained in advance. However,
this optional attribute may be used by the signer to prove that the this optional attribute may be used by the signer to prove that the
signed object existed before the date included in the timestamp (see signed object existed before the date included in the timestamp (see
3.12.3, Content Timestamp). 3.12.3, Content Timestamp).
Also, the signing time should be between the time indicated by this Also, the signing time should be between the time indicated by this
timestamp and time indicated by the ES-T timestamp. timestamp and time indicated by the ES-T timestamp.
B.3.7 Content Format
When presenting signed data to a human user it may be important that
there is no ambiguity as to the presentation of the signed information
to the relying party. In order for the appropriate representation
(text, sound or video) to be selected by the relying party a content
hint may be indicated by the signer. If a relying party system does not
use the format specified in the content hints to present the data to
the relying party, the electronic signature may not be valid.
B.4 Components of Validation Data B.4 Components of Validation Data
B.4.1 Revocation Status Information B.4.1 Revocation Status Information
A verifier will have to prove that the certificate of the signer was A verifier will have to prove that the certificate of the signer was
valid at the time of the signature. This can be done by either: valid at the time of the signature. This can be done by either:
* using Certificate Revocation Lists (CRLs); * using Certificate Revocation Lists (CRLs);
* using responses from an on-line certificate status server * using responses from an on-line certificate status server
(for example; obtained through the OCSP protocol). (for example; obtained through the OCSP protocol).
Internet Draft Electronic Signature Formats
B.4.2 CRL Information B.4.2 CRL Information
When using CRLs to get revocation information, a verifier will have to When using CRLs to get revocation information, a verifier will have to
make sure that he or she gets at the time of the first verification the make sure that he or she gets at the time of the first verification the
appropriate certificate revocation information from the signer's CA. appropriate certificate revocation information from the signer's CA.
This should be done as soon as possible to minimize the time delay This should be done as soon as possible to minimize the time delay
between the generation and verification of the signature. This involves between the generation and verification of the signature. This involves
checking that the signer certificate serial number is not included in checking that the signer certificate serial number is not included in
the CRL. The signer, the verifier or any other third party may obtain the CRL. The signer, the verifier or any other third party may obtain
either this CRL. If obtained by the signer, then it must be conveyed either this CRL. If obtained by the signer, then it must be conveyed
to the verifier. It may be convenient to archive the CRL for ease of to the verifier. It may be convenient to archive the CRL for ease of
subsequent verification or arbitration. subsequent verification or arbitration.
Alternatively, provided the CRL is archived elsewhere which is Alternatively, provided the CRL is archived elsewhere which is
accessible for the purpose of arbitration, then the serial number of accessible for the purpose of arbitration, then the serial number of
the CRL used may be archived together with the verified electronic the CRL used may be archived together with the verified electronic
signature. signature.
Internet Draft Electronic Signature Formats
It may happen that the certificate serial number appears in the CRL It may happen that the certificate serial number appears in the CRL
but with the status "suspended" (i.e. on hold). In such a case, the but with the status "suspended" (i.e. on hold). In such a case, the
electronic signature is not yet valid, since it is not possible to electronic signature is not yet valid, since it is not possible to
know whether the certificate will or will not be revoked at the end know whether the certificate will or will not be revoked at the end
of the suspension period. If a decision has to be taken immediately of the suspension period. If a decision has to be taken immediately
then the signature has to be considered as invalid. If a decision can then the signature has to be considered as invalid. If a decision can
wait until the end of the suspension period, then two cases are wait until the end of the suspension period, then two cases are
possible: possible:
* the certificate serial number has disappeared from the list * the certificate serial number has disappeared from the list
skipping to change at page 68, line 30 skipping to change at page 72, line 5
* the certificate serial number has been maintained on the list * the certificate serial number has been maintained on the list
with the status definitively revoked and thus the electronic with the status definitively revoked and thus the electronic
signature must be considered as invalid and discarded. signature must be considered as invalid and discarded.
At this point the verifier may be convinced that he or she got a valid At this point the verifier may be convinced that he or she got a valid
signature, but is not yet in a position to prove at a later time that signature, but is not yet in a position to prove at a later time that
the signature was verified as valid. Before addressing this point, an the signature was verified as valid. Before addressing this point, an
alternative to CRL is to use OCSP responses. alternative to CRL is to use OCSP responses.
Internet Draft Electronic Signature Formats
B.4.3 OCSP Information B.4.3 OCSP Information
When using OCSP to get revocation information , a verifier will have When using OCSP to get revocation information , a verifier will have
to make sure that he or she gets at the time of the first verification to make sure that he or she gets at the time of the first verification
an OCSP response that contains the status "valid". This should be done an OCSP response that contains the status "valid". This should be done
as soon as possible after the generation of the signature. The signer, as soon as possible after the generation of the signature. The signer,
the verifier or any other third party may fetch this OCSP response. the verifier or any other third party may fetch this OCSP response.
Since OSCP responses are transient and thus are not archived by any Since OSCP responses are transient and thus are not archived by any
TSP including CA, it is the responsibility of every verifier to make TSP including CA, it is the responsibility of every verifier to make
sure that it is stored in a safe place. The simplest way is to store sure that it is stored in a safe place. The simplest way is to store
skipping to change at page 69, line 5 skipping to change at page 72, line 36
not possible to know whether the certificate will or will not be not possible to know whether the certificate will or will not be
revoked at the end of the suspension period. If a decision has to be revoked at the end of the suspension period. If a decision has to be
taken immediately then the electronic signature has to be considered taken immediately then the electronic signature has to be considered
as invalid. If a decision can wait until the end of the suspension as invalid. If a decision can wait until the end of the suspension
period, then two cases are possible: period, then two cases are possible:
* An OCSP response with a valid status is obtained at a later * An OCSP response with a valid status is obtained at a later
date and thus the certificate can be considered as valid and date and thus the certificate can be considered as valid and
that OCSP response must be captured. that OCSP response must be captured.
Internet Draft Electronic Signature Formats
* An OCSP response with an invalid status is obtained with a * An OCSP response with an invalid status is obtained with a
secondary status indicating that the certificate is secondary status indicating that the certificate is
definitively revoked and thus the electronic signature must be definitively revoked and thus the electronic signature must be
considered as invalid and discarded. considered as invalid and discarded.
As in the CRL case, at this point, the verifier may be convinced that As in the CRL case, at this point, the verifier may be convinced that
he or she got a valid signature, but is not yet in a position to prove he or she got a valid signature, but is not yet in a position to prove
at a later time that the signature was verified as valid. at a later time that the signature was verified as valid.
B.4.4 Certification Path B.4.4 Certification Path
skipping to change at page 69, line 29 skipping to change at page 73, line 5
at the time of the signature, up to a trust point according to the at the time of the signature, up to a trust point according to the
naming constraints and the certificate policy constraints from the naming constraints and the certificate policy constraints from the
"Signature Validation Policy". It will be necessary to capture all the "Signature Validation Policy". It will be necessary to capture all the
certificates from the certification path, starting with those from the certificates from the certification path, starting with those from the
signer and ending up with those of the self-signed certificate from signer and ending up with those of the self-signed certificate from
one trusted root of the "Signature Validation Policy". In addition, it one trusted root of the "Signature Validation Policy". In addition, it
will be necessary to capture the Authority Revocation Lists (ARLs) to will be necessary to capture the Authority Revocation Lists (ARLs) to
prove than none of the CAs from the chain was revoked at the time of prove than none of the CAs from the chain was revoked at the time of
the signature. the signature.
Internet Draft Electronic Signature Formats
As in the OCSP case, at this point, the verifier may be convinced that As in the OCSP case, at this point, the verifier may be convinced that
he or she got a valid signature, but is not yet in a position to prove he or she got a valid signature, but is not yet in a position to prove
at a later time that the signature was verified as valid. at a later time that the signature was verified as valid.
B.4.5 Timestamping for Long Life of Signature B.4.5 Timestamping for Long Life of Signature
An important property for long standing signatures is that a An important property for long standing signatures is that a
signature, having been found once to be valid, must continue to be so signature, having been found once to be valid, must continue to be so
months or years later. months or years later.
skipping to change at page 70, line 5 skipping to change at page 73, line 36
even if the keys or certificates were later compromised. Thus there even if the keys or certificates were later compromised. Thus there
is a need to be able to demonstrate that the signature keys was valid is a need to be able to demonstrate that the signature keys was valid
around the time that the signature was created to provide long term around the time that the signature was created to provide long term
evidence of the validity of a signature. evidence of the validity of a signature.
It could be the case that a certificate was valid at the time of the It could be the case that a certificate was valid at the time of the
signature but revoked some time later. In this event, evidence must be signature but revoked some time later. In this event, evidence must be
provided that the document was signed before the signing key was provided that the document was signed before the signing key was
revoked. revoked.
Internet Draft Electronic Signature Formats
Timestamping by a Time Stamping Authority (TSA) can provide such Timestamping by a Time Stamping Authority (TSA) can provide such
evidence. A time stamp is obtained by sending the hash value of the evidence. A time stamp is obtained by sending the hash value of the
given data to the TSA. The returned "timestamp" is a signed document given data to the TSA. The returned "timestamp" is a signed document
that contains the hash value, the identity of the TSA, and the time of that contains the hash value, the identity of the TSA, and the time of
stamping. This proves that the given data existed before the time of stamping. This proves that the given data existed before the time of
stamping. Timestamping a digital signature (by sending a hash of the stamping. Timestamping a digital signature (by sending a hash of the
signature to the TSA) before the revocation of the signer's private signature to the TSA) before the revocation of the signer's private
key, provides evidence that the signature has been created before the key, provides evidence that the signature has been created before the
key was revoked. key was revoked.
skipping to change at page 70, line 29 skipping to change at page 74, line 5
key (and any key involved in the validation) is revoked. The sooner key (and any key involved in the validation) is revoked. The sooner
the timestamp is obtained after the signing time, the better. the timestamp is obtained after the signing time, the better.
It is important to note that signatures may be generated "off-line" It is important to note that signatures may be generated "off-line"
and time-stamped at a later time by anyone, for example by the signer and time-stamped at a later time by anyone, for example by the signer
or any recipient interested in the value of the signature. The time or any recipient interested in the value of the signature. The time
stamp can thus be provided by the signer together with the signed stamp can thus be provided by the signer together with the signed
document, or obtained by the recipient following receipt of the signed document, or obtained by the recipient following receipt of the signed
document. document.
Internet Draft Electronic Signature Formats
The time stamp is NOT a component of the Electronic Signature, but the The time stamp is NOT a component of the Electronic Signature, but the
essential component of the ES with Timestamp. essential component of the ES with Timestamp.
It is required in this document that signer's digital signature value It is required in this document that signer's digital signature value
is timestamped by a trusted source, known as a TimeStamping Authority. is timestamped by a trusted source, known as a TimeStamping Authority.
This document requires that the signer's digital signature value is This document requires that the signer's digital signature value is
timestamped by a trusted source before the electronic signature can timestamped by a trusted source before the electronic signature can
become a ES with Complete validation data (ES-C). The acceptable TSAs become a ES with Complete validation data (ES-C). The acceptable TSAs
are specified in the Signature Validation Policy. are specified in the Signature Validation Policy.
skipping to change at page 71, line 5 skipping to change at page 74, line 33
B.4.6 Timestamping before CA Key Compromises B.4.6 Timestamping before CA Key Compromises
Timestamped extended electronic signatures are needed when there is a Timestamped extended electronic signatures are needed when there is a
requirement to safeguard against the possibility of a CA key in the requirement to safeguard against the possibility of a CA key in the
certificate chain ever being compromised. A verifier may be required certificate chain ever being compromised. A verifier may be required
to provide on request, proof that the certification path and the to provide on request, proof that the certification path and the
revocation information used a the time of the signature were valid, revocation information used a the time of the signature were valid,
even in the case where one of the issuing keys or OCSP responder keys even in the case where one of the issuing keys or OCSP responder keys
is later compromised. is later compromised.
Internet Draft Electronic Signature Formats
The current document defines two ways of using timestamps to protect The current document defines two ways of using timestamps to protect
against this compromise: against this compromise:
* Timestamp the ES with Complete validation data, when an OCSP * Timestamp the ES with Complete validation data, when an OCSP
response is used to get the status of the certificate from the response is used to get the status of the certificate from the
signer. signer.
* Timestamp only the certification path and revocation information * Timestamp only the certification path and revocation information
references when a CRL is used to get the status of the references when a CRL is used to get the status of the
certificate from the signer. certificate from the signer.
NOTE: the signer, verifier or both may obtain the timestamp. NOTE: the signer, verifier or both may obtain the timestamp.
Internet Draft Electronic Signature Formats
B.4.6.1 Timestamping the ES with Complete validation data B.4.6.1 Timestamping the ES with Complete validation data
When an OCSP response is used, it is necessary to time stamp in When an OCSP response is used, it is necessary to time stamp in
particular that response in the case the key from the responder would particular that response in the case the key from the responder would
be compromised. Since the information contained in the OCSP response be compromised. Since the information contained in the OCSP response
is user specific and time specific, an individual time stamp is needed is user specific and time specific, an individual time stamp is needed
for every signature received. Instead of placing the time stamp only for every signature received. Instead of placing the time stamp only
over the certification path references and the revocation information over the certification path references and the revocation information
references, which include the OCSP response, the time stamp is placed references, which include the OCSP response, the time stamp is placed
on the ES-C. Since the certification path and revocation information on the ES-C. Since the certification path and revocation information
skipping to change at page 72, line 5 skipping to change at page 75, line 48
data being referenced. data being referenced.
If it is desired for any reason to keep a copy of the additional data If it is desired for any reason to keep a copy of the additional data
being referenced, the additional data may be attached to the being referenced, the additional data may be attached to the
electronic signature, in which case the electronic signature becomes electronic signature, in which case the electronic signature becomes
a ES-X Long as defined by this document. a ES-X Long as defined by this document.
A ES-X Long Timestamped is simply the concatenation of a ES-X A ES-X Long Timestamped is simply the concatenation of a ES-X
Timestamped with a copy of the additional data being referenced. Timestamped with a copy of the additional data being referenced.
Internet Draft Electronic Signature Formats
B.4.6.2 Timestamping Certificates and Revocation Information B.4.6.2 Timestamping Certificates and Revocation Information
References Timestamping each ES with Complete validation data as References Timestamping each ES with Complete validation data as
defined above may not be efficient, particularly when the same set of defined above may not be efficient, particularly when the same set of
CA certificates and CRL information is used to validate many CA certificates and CRL information is used to validate many
signatures. signatures.
Internet Draft Electronic Signature Formats
Timestamping CA certificates will stop any attacker from issuing bogus Timestamping CA certificates will stop any attacker from issuing bogus
CA certificates that could be claimed to existing before the CA key CA certificates that could be claimed to existing before the CA key
was compromised. Any bogus timestamped CA certificates will show that was compromised. Any bogus timestamped CA certificates will show that
the certificate was created after the legitimate CA key was the certificate was created after the legitimate CA key was
compromised. In the same way, timestamping CA CRLs, will stop any compromised. In the same way, timestamping CA CRLs, will stop any
attacker from issuing bogus CA CRLs which could be claimed to existing attacker from issuing bogus CA CRLs which could be claimed to existing
before the CA key was compromised. before the CA key was compromised.
Timestamping of commonly used certificates and CRLs can be done Timestamping of commonly used certificates and CRLs can be done
centrally, e.g. inside a company or by a service provider. This method centrally, e.g. inside a company or by a service provider. This method
skipping to change at page 73, line 5 skipping to change at page 76, line 50
Over a period of time weaknesses may occur in the cryptographic Over a period of time weaknesses may occur in the cryptographic
algorithms used to create an electronic signature (e.g. due to the algorithms used to create an electronic signature (e.g. due to the
time available for cryptoanalysis, or improvements in cryptoanalytical time available for cryptoanalysis, or improvements in cryptoanalytical
techniques). Before this such weaknesses become likely, a verifier techniques). Before this such weaknesses become likely, a verifier
should take extra measures to maintain the validity of the electronic should take extra measures to maintain the validity of the electronic
signature. Several techniques could be used to achieve this goal signature. Several techniques could be used to achieve this goal
depending on the nature of the weakened cryptography. In order to depending on the nature of the weakened cryptography. In order to
simplify, a single technique, called Archive validation data, covering simplify, a single technique, called Archive validation data, covering
all the cases is being used in this document. all the cases is being used in this document.
Internet Draft Electronic Signature Formats
Archive validation data consists of the Complete validation data and Archive validation data consists of the Complete validation data and
the complete certificate and revocation data, time stamped together the complete certificate and revocation data, time stamped together
with the electronic signature. The Archive validation data is with the electronic signature. The Archive validation data is
necessary if the hash function and the crypto algorithms that were necessary if the hash function and the crypto algorithms that were
used to create the signature are no longer secure. Also, if it cannot used to create the signature are no longer secure. Also, if it cannot
be assumed that the hash function used by the Time Stamping Authority be assumed that the hash function used by the Time Stamping Authority
is secure, then nested timestamps of Archived Electronic Signature are is secure, then nested timestamps of Archived Electronic Signature are
required. required.
Internet Draft Electronic Signature Formats
The potential for Trusted Service Provider (TSP) key compromise should The potential for Trusted Service Provider (TSP) key compromise should
be significantly lower than user keys, because TSP(s) are expected to be significantly lower than user keys, because TSP(s) are expected to
use stronger cryptography and better key protection. It can be expected use stronger cryptography and better key protection. It can be expected
that new algorithms (or old ones with greater key lengths) will be that new algorithms (or old ones with greater key lengths) will be
used. In such a case, a sequence of timestamps will protect against used. In such a case, a sequence of timestamps will protect against
forgery. Each timestamp needs to be affixed before either the forgery. Each timestamp needs to be affixed before either the
compromise of the signing key or of the cracking of the algorithms used compromise of the signing key or of the cracking of the algorithms used
by the TSA. TSAs (TimeStamping Authorities) should have long keys (e.g. by the TSA. TSAs (TimeStamping Authorities) should have long keys (e.g.
which at the time of drafting this document was 2048 bits for the which at the time of drafting this document was 2048 bits for the
signing RSA algorithm) and/or a "good" or different algorithm. signing RSA algorithm) and/or a "good" or different algorithm.
skipping to change at page 74, line 50 skipping to change at page 79, line 5
Both the ES-T and the ES-C contain at least one time stamp over the Both the ES-T and the ES-C contain at least one time stamp over the
signer's signature. In order to protect against the compromise of the signer's signature. In order to protect against the compromise of the
private signature key used to produce that timestamp, the Archive private signature key used to produce that timestamp, the Archive
validation data can be used when a different TimeStamping Authority key validation data can be used when a different TimeStamping Authority key
is involved to produce the additional timestamp. If it is believed that is involved to produce the additional timestamp. If it is believed that
the TSA key used in providing an earlier timestamp may ever be the TSA key used in providing an earlier timestamp may ever be
compromised (e.g. outside its validity period), then the ES-A should be compromised (e.g. outside its validity period), then the ES-A should be
used. For extremely long periods this may be applied repeatedly using used. For extremely long periods this may be applied repeatedly using
new TSA keys. new TSA keys.
Internet Draft Electronic Signature Formats
B.5 Multiple Signatures B.5 Multiple Signatures
Some electronic signatures may only be valid if they bear more than one Some electronic signatures may only be valid if they bear more than one
signature. This is the case generally when a contract is signed between signature. This is the case generally when a contract is signed between
two parties. The ordering of the signatures may or may not be two parties. The ordering of the signatures may or may not be
important, i.e. one may or may not need to be applied before the other. important, i.e. one may or may not need to be applied before the other.
Internet Draft Electronic Signature Formats
Several forms of multiple and counter signatures may need to be Several forms of multiple and counter signatures may need to be
supported, which fall into two basic categories: supported, which fall into two basic categories:
* independent signatures; * independent signatures;
* embedded signatures. * embedded signatures.
Independent signatures are parallel signatures where the ordering of Independent signatures are parallel signatures where the ordering of
the signatures is not important. The capability to have more than one the signatures is not important. The capability to have more than one
independent signature over the same data must be provided. independent signature over the same data must be provided.
Embedded signatures are applied one after the other and are used where Embedded signatures are applied one after the other and are used where
the order the signatures are applied is important. The capability to the order the signatures are applied is important. The capability to
sign over signed data must be provided. sign over signed data must be provided.
These forms are described in clause 3.13. All other multiple signature These forms are described in clause 3.13. All other multiple signature
schemes, e.g. a signed document with a countersignature, double schemes, e.g. a signed document with a countersignature, double
countersignatures or multiple signatures, can be reduced to one or more countersignatures or multiple signatures, can be reduced to one or more
occurrence of the above two cases. occurrence of the above two cases.
Internet Draft Electronic Signature Formats
Annex C (informative): Identifiers and roles Annex C (informative): Identifiers and roles
C.1 Signer Name Forms C.1 Signer Name Forms
The name used by the signer, held as the subject in the signer's The name used by the signer, held as the subject in the signer's
certificate, must uniquely identify the entity. The name must be certificate, must uniquely identify the entity. The name must be
allocated and verified on registration with the Certification allocated and verified on registration with the Certification
Authority, either directly or indirectly through a Registration Authority, either directly or indirectly through a Registration
Authority, before being issued with a Certificate. Authority, before being issued with a Certificate.
skipping to change at page 75, line 33 skipping to change at page 80, line 4
C.2 TSP Name Forms C.2 TSP Name Forms
All TSP name forms (Certification Authorities, Attribute Authorities All TSP name forms (Certification Authorities, Attribute Authorities
and TimeStamping Authorities) must be in the form of a distinguished and TimeStamping Authorities) must be in the form of a distinguished
name held in the subject field of the certificate. name held in the subject field of the certificate.
The TSP name form must include the legal jurisdiction (i.e. country) The TSP name form must include the legal jurisdiction (i.e. country)
under which it operates and an identification for the organization under which it operates and an identification for the organization
providing the service. providing the service.
Internet Draft Electronic Signature Formats
C.3 Roles and Signer Attributes C.3 Roles and Signer Attributes
Where a signer signs as an individual but wishes to also identify Where a signer signs as an individual but wishes to also identify
him/herself as acting on behalf of an organization, it may be necessary him/herself as acting on behalf of an organization, it may be necessary
to provide two independent forms of identification. The first identity, to provide two independent forms of identification. The first identity,
with is directly associated with the signing key identifies him/her as with is directly associated with the signing key identifies him/her as
an individual. The second, which is managed independently, identifies an individual. The second, which is managed independently, identifies
that person acting as part of the organization, possibly with a given that person acting as part of the organization, possibly with a given
role. role.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/