draft-ietf-smime-esformats-00.txt   draft-ietf-smime-esformats-01.txt 
Internet Draft ETSI TC-SEC (ETSI) Internet Draft ETSI TC-SEC (ETSI)
S/MIME Working Group J Ross (Security & Standards) S/MIME Working Group D. Pinkas (Bull)
expires in six months D Pinkas (Bull) expires in six months J. Ross (Security & Standards)
Target Category: Informational N Pope (Security & Standards) Target Category: Informational N. Pope (Security & Standards)
March 2000 July 2000
Electronic Signature Formats Electronic Signature Formats
for long term electronic signature for long term electronic signatures
<draft-ietf-smime-esformats-00.txt> <draft-ietf-smime-esformats-01.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 other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
Months and may be updated, replaced, or obsoleted by other Months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts as documents at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
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 (repudiates) 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
2634 [ESS], where, when appropriate additional signed and unsigned
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.1 Copyright (C). Individual copies of this ETSI ES 201 733 V.1.1.3 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. Electronic signatures can validity of such signatures is important.
be used for any transaction between an individual and a company,
between two companies, between an individual and a governmental body,
etc. This document is independent of any environment. It can be applied
to any environment e.g. smart cards, GSM SIM cards, special programs
for electronic signatures etc.
Internet Draft Electronic Signature Formats Internet Draft Electronic Signature Formats
Electronic signatures can be used for any transaction between an
individual and a company, between two companies, between an individual
and a governmental body, etc. This document is independent of any
environment. It can be applied to any environment e.g. smart cards, GSM
SIM cards, special programs for electronic signatures etc.
An electronic signature produced in accordance with this document An electronic signature produced in accordance with this document
provides evidence that can be processed to get confidence that some provides evidence that can be processed to get confidence that some
commitment has been explicitly endorsed under a Signature policy, at a 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 given time, by a signer under an identifier, e.g. a name or a
pseudonym, and optionally a role. pseudonym, and optionally a role.
The European Directive on a community framework for Electronic The European Directive on a community framework for Electronic
Signatures defines an electronic signature as: "data in electronic form Signatures defines an electronic signature as: "data in electronic form
which is attached to or logically associated with other electronic data which is attached to or logically associated with other electronic data
and which serves as a method of authentication". An electronic and which serves as a method of authentication". An electronic
signature as used in the current document is a form of advanced signature as used in the current document is a form of advanced
electronic signature as defined in the Directive. electronic signature as defined in the Directive.
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase, "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase,
as shown) are to be interpreted as described in [RFC2119]. as shown) are to be interpreted as described in [RFC2119].
TABLE OF CONTENTS
1. Introduction 1
2 Overview 4
2.1 Aim 4
2.2 Basis of Present Document 4
2.3 Major Parties 5
2.4 Electronic Signatures and Validation Data 6
2.5 Forms of Validation Data 7
2.6 Extended Forms of Validation Data 9
2.7 Archive Validation Data 11
2.8 Arbitration 12
2.9 Validation Process 12
2.10 Example Validation Sequence 13
2.11 Additional optional features 18
3. Data structure of an Electronic Signature 19
3.1 General Syntax 19
3.2 Data Content Type 19
3.3 Signed-data Content Type 19
3.4 SignedData Type 19
3.5 EncapsulatedContentInfo Type 20
3.6 SignerInfo Type 20
3.6.1 Message Digest Calculation Process 20
3.6.2 Message Signature Generation Process 20
3.6.3 Message Signature Verification Process 20
3.7 CMS Imported Mandatory Present Attributes 21
3.7.1 Content Type 21
3.7.2 Message Digest 21
3.7.3 Signing Time 21
Internet Draft Electronic Signature Formats
3.8 Alternative Signing Certificate Attributes 21
3.8.1 ESS Signing Certificate Attribute Definition 21
3.8.2 Other Signing Certificate Attribute Definition 22
3.9 Additional Mandatory Attributes 23
3.9.1 Signature policy Identifier 23
3.10 CMS Imported Optional Attributes 24
3.10.1 Countersignature 25
3.11 ESS Imported Optional Attributes 25
3.11.1 Content Reference Attribute 25
3.11.2 Content Identifier Attribute 25
3.12 Additional Optional Attributes 25
3.12.1 Commitment Type Indication Attribute 25
3.12.2 Signer Location attribute 27
3.12.3 Signer Attributes attribute 28
3.12.4 Content Timestamp attribute 28
3.13 Support for Multiple Signatures 29
3.13.1 Independent Signatures 29
3.13.2 Embedded Signatures 29
4. Validation Data 29
4.1 Electronic Signature Timestamp 30
4.1.1 Signature Timestamp Attribute Definition 30
4.2 Complete Validation Data 31
4.2.1 Complete Certificate Refs Attribute Definition 32
4.2.2 Complete Revocation Refs Attribute Definition 32
4.3 Extended Validation Data 34
4.3.1 Certificate Values Attribute Definition 34
4.3.2 Revocation Values Attribute Definition 35
4.3.3 ES-C Timestamp Attribute Definition 35
4.3.4 Time-Stamped Certificates and CRLs Attribute Definition 36
4.4 Archive Validation Data 36
4.4.1 Archive Timestamp Attribute Definition 37
5. Security considerations 38
5.1 Protection of Private Key 38
5.2 Choice of Algorithms 38
6. Conformance Requirements 38
6.1 Signer 38
6.2 Verifier 39
7. References 40
8. Authors' Addresses 40
9. Full Copyright Statement 41
Annex A (normative): ASN.1 Definitions 43
A.1 Definitions Using X.208 (1988) ASN.1 Syntax 43
A.2 Definitions Using X.680 1997 ASN.1 Syntax 52
Annex B (informative): General Description 61
B.1 The Signature Policy 61
B.2 Signed Information 62
B.3 Components of an Electronic Signature 62
B.3.1 Reference to the Signature Policy 62
B.3.2 Commitment Type Indication 63
B.3.3 Certificate Identifier from the Signer 64
Internet Draft Electronic Signature Formats
B.3.4. Role Attributes 64
B.3.4.1 Claimed Role 65
B.3.4.2 Certified Role 65
B.3.5 Signer Location 66
B.3.6 Signing Time 66
B.4 Components of Validation Data 67
B.4.1 Revocation Status Information 67
B.4.2 CRL Information 67
B.4.3 OCSP Information 68
B.4.4 Certification Path 69
B.4.5 Timestamping for Long Life of Signature 69
B.4.6 Timestamping before CA Key Compromises 70
B.4.6.1 Timestamping the ES with Complete validation data 71
B.4.6.2 Timestamping Certificates and Revocation Information 72
B.4.7 Timestamping for Long Life of Signature 72
B.4.8 Reference to Additional Data 73
B.4.9 Timestamping for Mutual Recognition 73
B.4.10 TSA Key Compromise 74
B.5 Multiple Signatures 74
Annex C (informative): Identifiers and roles 75
C.1 Signer Name Forms 75
C.2 TSP Name Forms 75
C.3 Roles and Signer Attributes 75
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.
A signer is the entity that creates an electronic signature.
This document specifies use of trusted service providers (e.g. This document specifies 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.
A Trusted Service Provider (TSP) is an entity that helps to build trust
relationships by making available or providing some information upon
request.
A verifier is an entity that verifies an evidence. (ISO/IEC 13888-1
[13]). Within the context of this document this is an entity that
validates an electronic signature.
A signature policy is a set of rules for the creation and validation of
an electronic signature, under which the signature can be determined to
be valid
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.
Internet Draft Electronic Signature Formats
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
This document also uses timestamping services to prove the validity of This document also uses timestamping services to prove the validity of
a signature long after the normal lifetime of critical elements of an a signature long after the normal lifetime of critical elements of an
electronic signature and to support non-repudiation. It also, as an electronic signature and to support non-repudiation. It also, as an
option, uses additional timestamps to provide very long-term protection option, uses additional timestamps to provide very long-term protection
against key compromise or weakened algorithms. 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 2630 [9] Crytographic Message Syntax (CMS); * RFC 2459 [RFC2459] Internet X.509 Public Key Infrastructure
Certificate and CRL Profile (PKIX);
* RFC 2630 [CMS] Crytographic Message Syntax (CMS);
* RFC 2634 [ESS] Enhanced Security Services (ESS);
* RFC 2439 [OCSP] One-line Certificate Status Protocol (OCSP);
* ITU-T Recommendation X.509 [1] Authentication framework; * ITU-T Recommendation X.509 [1] Authentication framework;
* RFC 2459 [7] Internet X.509 Public Key Infrastructure (PKIX) * RFC (to be published) [TSP] PKIX Time Stamping protocol (TSP).
Certificate and CRL Profile;
* RFC (to be published) PKIX Timestamping protocol.
NOTE: See clause 2 for a full set of references. NOTE: See clause 8 for a full set of references.
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;
* Trusted Service Providers (TSP); * the Arbitrator;
* the Arbitrator. * Trusted Service Providers (TSP).
The arbitrator is an entity that may be used to arbitrate a dispute
between a signer and verifier when there is a disagreement on the
validity of a digital signature.
The Signer is the entity that creates the electronic signature. When A Signer is an entity that creates the electronic signature. When
the signer digitally signs over data using the prescribed format, this the signer digitally signs over data using the prescribed format, this
represents a commitment on behalf of the signing entity to the data represents a commitment on behalf of the signing entity to the data
being signed. being signed.
The Verifier is the entity that validates the electronic signature, it A verifier is an entity that verifies an evidence. (ISO/IEC 13888-1
may be a single entity or multiple entities. [13]). Within the context of this document this is an entity that
validates an electronic signature.
An arbitrator, is an entity which arbitrates disputes between a signer
and a verifier when there is a disagreement on the validity of a
digital signature.
The 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. They to build trust relationships between the signer and verifier. Use of
support the signer and verifier by means of supporting services some specific TSP services MAY be mandated by signature policy. TSP
including: user certificates, cross-certificates, timestamping tokens, supporting services may provide the following information: user
CRLs, ARLs, OCSP responses. certificates, cross-certificates, timestamping tokens, CRLs, ARLs,
OCSP responses.
Internet Draft Electronic Signature Formats Internet Draft Electronic Signature Formats
The following TSPs are used to support the The following TSPs are used to support the validation or
functions defined in this document: the verification of electronic signatures :
* Certification Authorities; * Certification Authorities;
* Registration Authorities; * Registration Authorities;
* Repository Authorities (e.g. a Directory); * Repository Authorities (e.g. a Directory);
* TimeStamping Authorities; * TimeStamping Authorities;
* One-line Certificate Status Protocol responders;
* Attribute Authorities;
* Signature Policy Issuers. * Signature Policy Issuers.
Certification Authorities provide users with public key certificates. Certification Authorities provide users with public key certificates.
Registration Authorities allows the registration of entities before a Registration Authorities allows the registration of entities before a
CA generates certificates. CA generates certificates.
Repository Authorities publish CRLs issued by CAs, signature policies Repository Authorities publish CRLs issued by CAs, cross-certificates
issued by Signature Policy Issuers and optionally public key (i.e. CA certificates) issued by CAs, signature policies issued by
certificates. Signature Policy Issuers and optionally public key certificates (i.e.
leaf certificates) issued by CAs.
TimeStamping Authorities attest that some data was formed before a TimeStamping Authorities attest that some data was formed before a
given trusted time. given trusted time.
Signature Policy Issuers define the technical and procedural One-line Certificate Status Protocol responders (OSCP responders)
requirements for electronic signature creation and validation, in order provide information about the status (i.e. revoked, not revoked,
to meet a particular business need. unknown) of a particular certificate.
In some cases the following additional TSPs are needed:
* Attribute Authorities. A Signature Policy Issuer issues signatures policies that define the
technical and procedural requirements for electronic signature
creation, validation and verification, in order to meet a particular
business need.
Attributes Authorities provide users with attributes linked to public Attributes Authorities provide users with attributes linked to public
key certificates key certificates
An Arbitrator is an entity that arbitrates disputes between a signer
and a verifier.
A signature policy issuer is an entity that defines the technical and
procedural requirements for electronic signature creation and
validation, in order to meet a particular business need
2.4 Electronic Signatures and Validation Data 2.4 Electronic Signatures and Validation Data
Validation of an electronic signature in accordance with this document Validation of an electronic signature in accordance with this document
requires: requires:
* The electronic signature; this includes: * The electronic signature; this includes:
- the signature policy; - the signature policy;
- the signed user data; - the signed user data;
- the digital signature; - the digital signature;
- other signed attributes provided by the signer. - other signed attributes provided by the signer;
. - other unsigned attributes provided by the signer.
Internet Draft Electronic Signature Formats
* Validation data which is the additional data needed to validate * Validation data which is the additional data needed to validate
the electronic signature; this includes: the electronic signature; this includes:
- certificates references;
- certificates; - certificates;
- revocation status information,
- trusted time-stamps from Trusted Service Providers (TSPs). Internet Draft Electronic Signature Formats
- revocation status information references;
- revocation status information;
- time-stamps from Time Stamping Authorities (TSAs).
* The signature policy specifies the technical requirements on * The signature policy specifies the technical requirements on
signature creation and validation in order to meet a particular signature creation and validation in order to meet a particular
business need. A given legal/contractual context may recognize a business need. A given legal/contractual context may recognize a
particular signature policy as meeting its requirements. particular signature policy as meeting its requirements.
For example: a specific signature policy may be recognized by court of For example: a specific signature policy may be recognized by court
law as meeting the requirements of the European Directive for electronic of law as meeting the requirements of the European Directive for
commerce. A signature policy may be written using a formal notation like electronic commerce. A signature policy may be written using a formal
ASN.1 (see 6.1) or in an informal free text form provided the rules of notation like ASN.1 or in an informal free text form provided the
the policy are clearly identified. However, for a given signature policy rules of the policy are clearly identified. However, for a given
there shall be one definitive form which has a unique binary encoded signature policy there shall be one definitive form which has a unique
value. binary encoded value.
Signed user data is the user's data that is signed. Signed user data is the user's data that is signed.
The Digital Signature is the digital signature applied over the The Digital Signature is the digital signature applied over the
following attributes provided by the signer: following attributes provided by the signer:
* hash of the user data; * 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 The Validation Data may be collected by the signer and/or the verifier
and must meet the requirements of the signature policy. Additional and must meet the requirements of the signature policy. Additional
data includes CA certificates as well as revocation status information data includes CA certificates as well as revocation status information
in the form of Certificate Revocation Lists (CRLs) or certificate in the form of Certificate Revocation Lists (CRLs) or certificate
status information provided by an on-line service. Additional data status information provided by an on-line service. Additional data
also includes timestamps and other time related data used to provide also includes timestamps and other time related data used to provide
evidence of the timing of given events. It is required, as a minimum, evidence of the timing of given events. It is required, as a minimum,
that either the signer or verifier obtains a timestamp over the that either the signer or verifier obtains a timestamp over the
signer's signature. signer's signature.
A Certificate Revocation List (CRL) is signed list indicating a set of A digital signature (not to be confused with an electronic signature)
certificates that are no longer considered valid by the certificate is data appended to, or a cryptographic transformation of, a data unit
issuer [X.509 FPAM]digital signature: data appended to, or a that allows a recipient of the data unit to prove the source and
cryptographic transformation of, a data unit that allows a recipient of integrity of the data unit and protect against forgery, e.g. by the
the data unit to prove the source and integrity of the data unit and recipient (ISO 7498-2 [12])
protect against forgery, e.g. by the recipient (ISO 7498-2 [12])
Internet Draft Electronic Signature Formats
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
* the ES with Timestamp (ES-T), which adds a timestamp to the * the ES with Timestamp (ES-T), which adds a timestamp to the
Electronic Signature, to take initial steps towards providing Electronic Signature, to take initial steps towards providing
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 create the ES-T on first receipt of an electronic signature. The ES-T
provides independent evidence of the existence of the signature at the provides independent evidence of the existence of the signature at the
time it was first verified which should be near the time it was time it was first verified which should be near the time it was
created, and so protects against later repudiation of the existence of created, and so protects against later repudiation of the existence of
the signature. If the signer does not provide ES-C the verifier must the signature. If the signer does not provide ES-C the verifier must
create the ES-C when the complete set of revocation and other validation create the ES-C when the complete set of revocation and other
data is available. 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 the electronic signature
does not protect against the threat that the signer later denies having does not protect against the threat that the signer later denies having
created the electronic signature (i.e. does not provide non-repudiation created the electronic signature (i.e. does not provide non-repudiation
of its existence). of its existence).
The ES-T time-stamp should be created close to the time that ES was The ES-T time-stamp should be created close to the time that ES was
created to provide maximum protection against repudiation. At this time created to provide protection against repudiation. At this time all
ll the data needed to complete the validation may not be available but the data needed to complete the validation may not be available but
what information is readily available may be used to carry out some of what information is readily available may be used to carry out some of
the initial checks. For example, only part of the revocation the initial checks. For example, only part of the revocation
information may be available for verification at that point in time. information may be available for verification at that point in time.
Generally, the ES-C form cannot be created at the same time as the ES, Generally, the ES-C form cannot be created at the same time as the ES,
as it is necessary to allow time for any revocation information to be as it is necessary to allow time for any revocation information to be
captured. Also, if a certificate is found to be temporarily suspended, captured. Also, if a certificate is found to be temporarily suspended,
it will be necessary to wait until the end of the suspension period. 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.
skipping to change at page 7, line 5 skipping to change at page 8, line 54
as it is necessary to allow time for any revocation information to be as it is necessary to allow time for any revocation information to be
captured. Also, if a certificate is found to be temporarily suspended, captured. Also, if a certificate is found to be temporarily suspended,
it will be necessary to wait until the end of the suspension period. 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.
Internet Draft Electronic Signature Formats Support for ES-C by the verifier is mandated (see clause 6 for
Support for ES-C by the verifier is mandated (see clause 14 for
specific conformance requirements). specific conformance requirements).
An Electronic Signature (ES), with the additional validation data forming the Internet Draft Electronic Signature Formats
ES-T and ES-C is illustrated in Figure 1:
An Electronic Signature (ES), with the additional validation data
forming the ES-T and ES-C is illustrated in Figure 1:
+------------------------------------------------------------ES-C-----+ +------------------------------------------------------------ES-C-----+
|+--------------------------------------------ES-T-----+ | |+--------------------------------------------ES-T-----+ |
||+------Elect.Signature (ES)----------+ +------------+| +-----------+| ||+------Elect.Signature (ES)----------+ +------------+| +-----------+|
|||+---------+ +----------+ +---------+| |Timestamp || |Complete || |||+---------+ +----------+ +---------+| |Timestamp || |Complete ||
||||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 ||
||+------------------------------------+ | +-----------+| ||+------------------------------------+ | +-----------+|
skipping to change at page 8, line 5 skipping to change at page 9, line 53
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.
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.
Internet Draft Electronic Signature Formats
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 4.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 2:
skipping to change at page 9, line 41 skipping to change at page 11, line 41
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.
Support for ES-A is optional.
Internet Draft Electronic Signature Formats
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 5.
+-------------------------------- 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 5: Illustration of ES -A
Support for ES-A is optional.
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:
* a copy of the signature policy referenced by the signer is
available;
* the arbitrator knows where to retrieve the signer's certificate * the arbitrator knows where to retrieve the signer's certificate
(if not already present), all the cross-certificates and the (if not already present), all the cross-certificates and the
required CRLs and/or OCSPs responses referenced in the ES-C; required CRLs and/or OCSPs responses referenced in the ES-C;
* none of the issuing key from the certificate chain have ever * none of the issuing key from the certificate chain have ever
been compromised; been compromised;
* the cryptography used at the time the ES-C was built has not * the cryptography used at the time the ES-C was built has not
been broken at the time the arbitration is performed. been broken at the time the arbitration is performed.
When the first condition is not met, then the plaintiff must provide When the second condition is not met, then the plaintiff must provide
an ES-X Long. an ES-X Long.
When it is known by some external means that the second condition is When it is known by some external means that the third condition is
not met, then the plaintiff must provide an ES-X Timestamped. not met, then the plaintiff must provide an ES-X Timestamped.
When the two previous conditions are not met, the plaintiff must When the two previous conditions are not met, the plaintiff must
provide the two above information (i.e. an ES-X Timestamped and Long). provide the two above information (i.e. an ES-X Timestamped and Long).
When the last condition is not met, the plaintiff must provide an ES- When the last condition is not met, the plaintiff must provide an
A. ES-A.
It should be noticed that a verifier may need to get two time stamps at
two different instants of time: one soon after the generation of the ES
and one soon after some grace period allowing any entity from the
certification chain to declare a key compromise.
Internet Draft Electronic Signature Formats It should be noticed that a verifier may need to get two time stamps
at two different instants of time: one soon after the generation of
the ES and one soon after some grace period allowing any entity from
the certification chain to declare a key compromise.
2.9 Validation Process 2.9 Validation Process
The Validation Process validates an electronic signature in accordance The Validation Process validates an electronic signature in accordance
with the requirements of the signature policy. The output status of the with the requirements of the signature policy. The output status of
validation process can be: the validation process can be:
* valid; * valid;
* invalid; * invalid;
... * incomplete verification. * incomplete verification.
A Valid response indicates that the signature has passed verification A Valid response indicates that the signature has passed verification
and it complies with the signature validation policy. and it complies with the signature validation policy.
A signature validation policy is a part of the signature policy which A signature validation policy is a part of the signature policy which
specifies the technical requirements on the signer in creating a specifies the technical requirements on the signer in creating a
signature and verifier when validating a signature signature and verifier when validating a signature.
Internet Draft Electronic Signature Formats
An Invalid response indicates that either the signature format is An Invalid response indicates that either the signature format is
incorrect or that the digital signature value fails verification incorrect or that the digital signature value fails verification
(e.g. the integrity checks on the digital signature value fails or any (e.g. the integrity checks on the digital signature value fails or
of the certificates on which the digital signature verification depends any of the certificates on which the digital signature verification
is known to be invalid or revoked). depends is known to be invalid or revoked).
An Incomplete Validation response indicates that the format and digital An Incomplete Validation response indicates that the format and
signature verifications have not failed but there is insufficient digital signature verifications have not failed but there is
information to determine if the electronic signature is valid under the insufficient information to determine if the electronic signature
signature policy. is valid under the signature policy. This can include situations
where additional information, which does not effect the validity of
the digital signature value, may be available but is invalid.
This can include situations where additional information, which does In the case of Incomplete Validation, it may be possible to request
not effect the validity of the digital signature value, may be that the electronic signature be checked again at a later date when
available but is invalid. In the case of Incomplete Validation, it may additional validation information might become available. Also, in the
be possible to request that the electronic signature be checked again case of incomplete validation, additional information may be made
at a later date when additional validation information might become available to the application or user, thus allowing the application or
available. Also, in the case of incomplete validation, additional user to decide what to do with partially correct electronic signatures.
information may be made available to the application or user, thus
allowing the application or user to decide what to do with partially
correct electronic signatures.
The validation process may also output validation data : 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.
Internet Draft Electronic Signature Formats
2.10 Example Validation Sequence 2.10 Example Validation Sequence
As described earlier the signer or verifier may collect all the As described earlier the signer or verifier may collect all the
additional data that forms the Electronic Signature. Figure 6, and additional data that forms the Electronic Signature. Figure 6, and
subsequent description, describes how the validation process may build subsequent description, describes how the validation process may build
up a complete electronic signature over time. up a complete electronic signature over time.
Soon after receiving the electronic signature (ES) from the signer (1),
the digital signature value may be checked, the validation process
must at least add a time-stamp (2), unless the signer has provided one
which is trusted by the verifier. The validation process may also
validate the electronic signature, as required under the identified
signature policy, using additional data (e.g. certificates, CRL, etc.)
provided by trusted service providers. If the validation process is not
complete then the output from this stage is the ES-T.
When all the additional data (e.g. the complete certificate and
revocation information) necessary to validate the electronic signature
first becomes available, then the validation process:
* obtains all the necessary additional certificate and revocation
status information;
* completes all the validation checks on the ES, using the
complete certificate and revocation information (if a timestamp
is not already present, this may be added at the same stage
combining ES-T and ES-C process);
Internet Draft Electronic Signature Formats
* records the complete certificate and revocation references (3);
* indicates the validity status to the user (4).
+---------------------------------------- ES-C ----------+ +---------------------------------------- ES-C ----------+
|+----------------------------- ES-T -------+ | |+----------------------------- ES-T -------+ |
||+--- Elect.Signature (ES) ----+ | +--------+ | ||+--- Elect.Signature (ES) ----+ | +--------+ |
|||+-------+ +-------+ +-------+|+---------+| |Complete| | |||+-------+ +-------+ +-------+|+---------+| |Complete| |
||||Signa- | |Other | |Digital|||Timestamp|| |certifi-| | ||||Signa- | |Other | |Digital|||Timestamp|| |certifi-| |
||||ture | |Signed | |Signa- |||over || |cate and| | ||||ture | |Signed | |Signa- |||over || |cate and| |
||||Policy | |Attri- | |ture |||digital || |revoca- | | ||||Policy | |Attri- | |ture |||digital || |revoca- | |
||||ID | |butes | | |||signature|| |tion | | ||||ID | |butes | | |||signature|| |tion | |
|||+-------+ +-------+ +-------+|+---------+| |referen-| | |||+-------+ +-------+ +-------+|+---------+| |referen-| |
||+------------\----------------+ ^ | |ces | | ||+------------\----------------+ ^ | |ces | |
skipping to change at page 12, line 44 skipping to change at page 15, line 5
| | | | |- 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 6: Illustration of an ES with Complete validation data (ES-C)
Soon after receiving the electronic signature (ES) from the signer (1),
the digital signature value may be checked, the validation process
must at least add a time-stamp (2), unless the signer has provided one
which is trusted by the verifier. The validation process may also
validate the electronic signature, as required under the identified
signature policy, using additional data (e.g. certificates, CRL, etc.)
provided by trusted service providers. If the validation process is not
complete then the output from this stage is the ES-T.
Internet Draft Electronic Signature Formats Internet Draft Electronic Signature Formats
When all the additional data (e.g. the complete certificate and
revocation information) necessary to validate the electronic signature
first becomes available, then the validation process:
* obtains all the necessary additional certificate and revocation
status information;
* completes all the validation checks on the ES, using the
complete certificate and revocation information (if a timestamp
is not already present, this may be added at the same stage
combining ES-T and ES-C process);
* records the complete certificate and revocation references (3);
* indicates the validity status to the user (4).
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 7:
+---------------------------------------------------- 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 | |
skipping to change at page 16, line 55 skipping to change at page 18, line 55
|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 10: Illustration of an ES with Archive validation data (ES-A)
2.11 Additional optional features 2.11 Additional optional features
This document also defines additional optional features to: This document also defines additional optional features 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 Crypographic Message Syntax (CMS), This clause uses and builds upon the Cryptographic Message Syntax
as defined in RFC 2630, REF [CMS] , and Enhanced Security Services (CMS), as defined in RFC 2630 [CMS], and Enhanced Security Services
(ESS), as defined in RFC 2634 [10], REF [ESS] . The overall structure (ESS), as defined in RFC 2634 [ESS]. The overall structure
of Electronic Signature is as defined in [CMS]. The Electronic of Electronic Signature is as defined in [CMS]. The Electronic
Signature (ES) uses attributes defined in [CMS], [ESS] and Signature (ES) uses attributes defined in [CMS], [ESS] and
this document. This document defines in full the ES attributes which it this document. This document defines in full the ES attributes which it
uses and are not defined elsewhere. uses and are not defined elsewhere.
The mandated set of attributes and the digital signature value is The mandated set of attributes and the digital signature value is
defined as the minimum Electronic Signature (ES) required by this defined as the minimum Electronic Signature (ES) required by this
document. A signature policy MAY mandate other signed attributes are document. A signature policy MAY mandate other signed attributes to be
present. present.
3.1 General Syntax 3.1 General Syntax
The general syntax of the ES is as defined in [CMS]. The general syntax of the ES is as defined in [CMS].
3.2 Data Content Type 3.2 Data Content Type
The data content type of the ES is as defined in [CMS]. The data content type of the ES is as defined in [CMS].
The data content type is intended to refer to arbitrary octet strings,
such as ASCII text files; the interpretation is left to the
application. Such strings need not have any internal structure
(although they could have their own ASN.1 definition or other
structure).
3.3 Signed-data Content Type 3.3 Signed-data Content Type
The Signed-data content type of the ES is as defined in [CMS]. The Signed-data content type of the ES is as defined in [CMS].
To make sure that the verifier uses the right signers key, this The signed-data content type consists of a content of any type and zero
or more signature values. Any number of signers in parallel can sign
any type of content. The typical application of the signed-data content
type represents one signer's digital signature on content of the data
content type.
To make sure that the verifier uses the right certificate, this
document mandates that the hash of the signers certificate is always document mandates that the hash of the signers certificate is always
included in the Signing Certificate signed attribute. included in the Signing Certificate signed attribute.
3.4 SignedData Type 3.4 SignedData Type
The syntax of the SignedData type of the ES is as defined in [CMS]. The syntax of the SignedData type of the ES is as defined in [CMS].
The fields of type SignedData have the meanings defined [CMS] except The fields of type SignedData have the meanings defined [CMS] except
that: that:
* version is the syntax version number. The value of version must * version is the syntax version number. The value of version must
be 3. be 3.
Internet Draft Electronic Signature Formats
* The identification of signer's certificate used to create the * The identification of signer's certificate used to create the
signature is always signed. The validation policy may specify signature is always present as a signed attribute.
requirements for the presence of certain certificates.
* The degenerate case where there are no signers is not valid in * The degenerate case where there are no signers is not valid in
this document. this document.
Internet Draft Electronic Signature Formats
3.5 EncapsulatedContentInfo Type 3.5 EncapsulatedContentInfo Type
The syntax of the EncapsulatedContentInfo a type of the ES is as defined The syntax of the EncapsulatedContentInfo a type of the ES is as
in [CMS]. defined in [CMS].
For the purpose of long term validation as defined by this document, it For the purpose of long term validation as defined by this document, it
is advisable that either the eContent is present, or the data which is is advisable that either the eContent is present, or the data which is
signed is archived in such as way as to preserve the any data encoding. signed is archived in such as way as to preserve the any data encoding.
It is important that the OCTET STRING used to generate the signature It is important that the OCTET STRING used to generate the signature
remains the same every time either the verifier or an arbitrator remains the same every time either the verifier or an arbitrator
validates the signature. validates the signature.
The degenerate case where there are no signers is not valid in this The degenerate case where there are no signers is not valid in this
document. document.
3.6 SignerInfo Type 3.6 SignerInfo Type
The syntax of the SignerInfo a type of the ES is as defined in [CMS]. The syntax of the SignerInfo a type of the ES is as defined in [CMS].
Per-signer information is represented in the type SignerInfo. In the Per-signer information is represented in the type SignerInfo. In the
case of multiple independent signatures, there is an instance case of multiple independent signatures, there is an instance
of this field for each signer. of this field for each signer.
The fields of type SignerInfo have the meanings defined in [CMS} except The fields of type SignerInfo have the meanings defined in [CMS]
that: except that signedAttributes must, as a minimum, contain the following
attributes:
signedAttributes must, as a minimum,
contain the following attributes:
* ContentType as defined in clause 3.7.1. * ContentType as defined in clause 3.7.1.
* MessageDigest as defined in clause 3.7.2. * MessageDigest as defined in clause 3.7.2.
* SigningTime as defined in clause 3.7.3. * SigningTime as defined in clause 3.7.3.
* SigningCertificate as defined in clause 3.8.1. * SigningCertificate as defined in clause 3.8.1.
* SignaturePolicyId as defined in clause 3.9.1. * SignaturePolicyId as defined in clause 3.9.1.
3.6.1 Message Digest Calculation Process 3.6.1 Message Digest Calculation Process
The message digest calculation process is as defined in [CMS]. The message digest calculation process is as defined in [CMS].
3.6.2 Message Signature Generation Process 3.6.2 Message Signature Generation Process
The input to the digital signature generation process is as defined in The input to the digital signature generation process is as defined in
[CMS]. [CMS].
3.6.3 Message Signature Verification Process 3.6.3 Message Signature Verification Process
The procedures for CMS signed data validation are as defined in The procedures for CMS signed data validation are as defined in
[CMS] and enhanced in this document. [CMS] and enhanced in this document.
The input to the signature verification process includes the signer's
public key verified as correct using the ESS Signing Certificate or
Other Signing Certificate attribute.
Internet Draft Electronic Signature Formats Internet Draft Electronic Signature Formats
The input to the signature verification process includes the signer's
public key verified as correct using either the ESS Signing
Certificate attribute or the Other Signing Certificate attribute.
3.7 CMS Imported Mandatory Present Attributes 3.7 CMS Imported Mandatory Present Attributes
The following attributes MUST be present with the signed-data defined The following attributes MUST be present with the signed-data defined
by this document. The attributes are defined in [CMS]. by this document. The attributes are defined in [CMS].
3.7.1 Content Type 3.7.1 Content Type
The syntax of the content-type attribute type of the ES is as defined The syntax of the content-type attribute type of the ES is as defined
in [CMS]. in [CMS].
3.7.2 Message Digest 3.7.2 Message Digest
The syntax of the message-digest attribute type of the ES is as defined The syntax of the message-digest attribute type of the ES is as defined
in [CMS]. in [CMS].
3.7.3 Signing Time 3.7.3 Signing Time
The syntax of the message-digest attribute type of the ES is as defined The syntax of the message-digest attribute type of the ES is as defined
in [CMS]and further qualified by this document. in [CMS]and further qualified by this document.
The signing-time attribute type specifies the time at which the signer The signing-time attribute type specifies the time at which the signer
claims to have performed the signing process. claims to have performed the signing process.
skipping to change at page 19, line 36 skipping to change at page 21, line 42
claims to have performed the signing process. claims to have performed the signing process.
This present document recommends the use of GeneralizedTime. This present document recommends the use of GeneralizedTime.
3.8 Alternative Signing Certificate Attributes 3.8 Alternative Signing Certificate Attributes
One, and only one, of the following two alternative attributes MUST be One, and only one, of the following two alternative attributes MUST be
present with the signed-data defined by this document to identify the present with the signed-data defined by this document to identify the
signing certificate. Both attributes include an identifier and a hash signing certificate. Both attributes include an identifier and a hash
of the signing certificate. The first, which is adopted in existing of the signing certificate. The first, which is adopted in existing
standards, may be used if with the SHA-1 hashing algorithm. The other standards, may be only used with the SHA-1 hashing algorithm. The
hall be used for other hashing algorithms are to be supported. other shall be used when other hashing algorithms are to be supported.
The signing certificate attribute is designed to prevent the simple The signing certificate attribute is designed to prevent the simple
substitution and re-issue attacks, and to allow for a restricted set of substitution and re-issue attacks, and to allow for a restricted set of
authorization certificates to be used in verifying a signature. authorization certificates to be used in verifying a signature.
3.8.1 ESS Signing Certificate Attribute Definition 3.8.1 ESS Signing Certificate Attribute Definition
The syntax of the signing certificate attribute type of the ES is as The syntax of the signing certificate attribute type of the ES is as
defined in [ESS], and further qualified and profile in this document. defined in [ESS], and further qualified and profile in this document.
The ESS signing certificate attribute must be a signed attribute. The ESS signing certificate attribute must be a signed attribute.
This document mandates the presence of this attribute as a signed CMS This document mandates the presence of this attribute as a signed CMS
attribute, and the sequence must not be empty. The certificate used to attribute, and the sequence must not be empty. The certificate used to
verify the signature must be identified in the sequence, the Signature verify the signature must be identified in the sequence, the Signature
Validation Policy may mandate other certificates be present, that may Validation Policy may mandate other certificate references to be
include all the certificates up to the point of trust. The encoding of present, that may include all the certificates up to the point of
the ESSCertID for this certificate must include the issuerSerial
field.
Internet Draft Electronic Signature Formats Internet Draft Electronic Signature Formats
trust. The encoding of the ESSCertID for this certificate must include
the issuerSerial field.
The issuerAndSerialNumber present in the SignerInfo must be The issuerAndSerialNumber present in the SignerInfo must be
consistent with issuerSerial field. The certificate identified must be consistent with issuerSerial field. The certificate identified must be
used during the signature verification process. If the hash of the used during the signature verification process. If the hash of the
certificate does not match the certificate used to verify the certificate does not match the certificate used to verify the
signature, the signature must be considered invalid. signature, the signature must be considered invalid.
The sequence of policy information field is not used in this document. The sequence of policy information field is not used in this document.
NOTE: Where an attribute certificate is used by the signer to associate NOTE: Where an attribute certificate is used by the signer to associate
a role, or other attributes of the signer, with the electronic a role, or other attributes of the signer, with the electronic
skipping to change at page 20, line 47 skipping to change at page 22, line 50
OtherSigningCertificate OtherSigningCertificate
OtherSigningCertificate ::= SEQUENCE { OtherSigningCertificate ::= SEQUENCE {
certs SEQUENCE OF OtherCertID, certs SEQUENCE OF OtherCertID,
policies SEQUENCE OF PolicyInformation OPTIONAL policies SEQUENCE OF PolicyInformation OPTIONAL
-- NOT USED IN THIS DOCUMENT -- NOT USED IN THIS DOCUMENT
} }
OtherCertID ::= SEQUENCE { OtherCertID ::= SEQUENCE {
otherCertHash OtherHash, otherCertHash OtherHash,
issuerSerial IssuerSerial OPTIONAL } issuerSerial IssuerSerial OPTIONAL
}
OtherHash ::= CHOICE { OtherHash ::= CHOICE {
sha1Hash OtherHashValue, -- This contains a SHA-1 hash sha1Hash OtherHashValue, -- This contains a SHA-1 hash
otherHash OtherHashAlgAndValue} otherHash OtherHashAlgAndValue
}
OtherHashValue ::= OCTET STRING OtherHashValue ::= OCTET STRING
Internet Draft Electronic Signature Formats
OtherHashAlgAndValue ::= SEQUENCE { OtherHashAlgAndValue ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier, hashAlgorithm AlgorithmIdentifier,
hashValue OtherHashValue } hashValue OtherHashValue
}
Internet Draft Electronic Signature Formats
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, which
defines the rules for creation and validation of an electronic defines the rules for creation and validation of an electronic
signature, is included as a signed attribute with every signature. The signature, is included as a signed attribute with every signature. The
signature policy identifier must be a signed attribute. signature policy identifier must be a signed attribute.
skipping to change at page 21, line 25 skipping to change at page 23, line 30
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 ::= 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 The sigPolicyIdentifier 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 ASN.1 (see 6.1) the hash is If the signature policy is defined using a computer processable
calculated on the value without the outer type and length fields and notation like ASN.1, then the hash is calculated on the value without
the hashing algorithm must be as specified in the field the outer type and length fields and the hashing algorithm must be as
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 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.
-- sigpolicyQualifierIds defined in this document -- sigpolicyQualifierIds defined in this document
SigPolicyQualifierId ::= SigPolicyQualifierId ::= OBJECT IDENTIFIER
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
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
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]. defined in [CMS]. The countersignature attribute must be an unsigned
attribute.
The countersignature attribute must be an unsigned 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 by into this specification and were appropriate qualified and profiling
this document. by this document.
3.11.1 Signed 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 content reference attribute MUST be used as defined in [ESS]. The
content reference MUST be a signed attribute.
The content reference MUST be a signed attribute.
The syntax of the content reference attribute type of the ES is as The syntax of the content reference attribute type of the ES is as
defined in [ESS]. defined in [ESS].
3.11.2 Content Identifier Attribute 3.11.2 Content Identifier Attribute
The content identifier attribute provides an identifier for the signed The content identifier attribute provides an identifier for the signed
content for use when reference may be later required to that content, content for use when reference may be later required to that content,
for example in the content reference attribute in other signed data sent for example in the content reference attribute in other signed data
later. sent later.
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.
Internet Draft Electronic Signature Formats
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.
The commitmentTypeIndication attribute must be a signed attribute Internet Draft Electronic Signature Formats
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
skipping to change at page 24, line 43 skipping to change at page 26, line 34
recognized commitment types are allowed in this field. recognized commitment types are allowed in this field.
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 {
commitmentTypeId CommitmentTypeIdentifier, commitmentTypeId CommitmentTypeIdentifier,
commitmentTypeQualifier SEQUENCE SIZE (1..MAX) OF commitmentTypeQualifier SEQUENCE SIZE (1..MAX) OF
CommitmentTypeQualifier CommitmentTypeQualifier OPTIONAL
OPTIONAL} }
CommitmentTypeIdentifier ::= OBJECT IDENTIFIER CommitmentTypeIdentifier ::= OBJECT IDENTIFIER
CommitmentTypeQualifier ::= SEQUENCE { CommitmentTypeQualifier ::= SEQUENCE {
commitmentTypeIdentifier CommitmentTypeIdentifier, commitmentTypeIdentifier CommitmentTypeIdentifier,
qualifier ANY DEFINED BY commitmentTypeIdentifier } qualifier ANY DEFINED BY
commitmentTypeIdentifier
}
The use of any qualifiers to the commitment type is outside the scope The use of any qualifiers to the commitment type is outside the scope
of this document. of this document.
Internet Draft Electronic Signature Formats
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)
skipping to change at page 25, line 53 skipping to change at page 27, line 44
Proof of sender indicates that the entity providing that indication has Proof of sender indicates that the entity providing that indication has
sent the message (but not necessarily created it). sent the message (but not necessarily created it).
Proof of approval indicates that the signer has approved the content of Proof of approval indicates that the signer has approved the content of
the message. the message.
Proof of creation indicates that the signer has created the message Proof of creation indicates that the signer has created the message
(but not necessarily approved, nor sent it). (but not necessarily approved, nor sent it).
NOTE: See clause A.3 for a full description of the commitment types 3.12.2 Signer Location attribute
defined above.
Internet Draft Electronic Signature Formats
3.12.2 Signer Location
The signer-location attribute is an attribute which specifies a The signer-location attribute is an attribute which specifies a
mnemonic for an address associated with the signer at a particular mnemonic for an address associated with the signer at a particular
geographical (e.g. city) location. The mnemonic is registered in the geographical (e.g. city) location. The mnemonic is registered in the
country in which the signer is located and is used in the provision of country in which the signer is located and is used in the provision of
the Public Telegram Service (according to ITU-T Recommendation F.1 the Public Telegram Service (according to ITU-T Recommendation F.1
[5?????]). [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}
Signer-location attribute values have ASN.1 type SignerLocation: Internet Draft Electronic Signature Formats
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
3.12.3 Signer Attributes 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;
* claimed attributes of the signer; or
* certified attributes of the signer; * certified attributes of the signer;
* the signer-attribute attribute must be a signed attribute
attributes.
The signer-attributes attribute must be a signed attribute. The signer-attributes attribute must be a signed attribute.
The following object identifier identifies the signer-attribute The following object identifier identifies the signer-attribute
attribute: attribute:
id-aa-ets-signerAttr OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-aa-ets-signerAttr OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 18} us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 18}
signer-attribute attribute values have ASN.1 type SignerAttribute. signer-attribute attribute values have ASN.1 type SignerAttribute.
SignerAttribute ::= SEQUENCE OF CHOICE { SignerAttribute ::= SEQUENCE OF CHOICE {
claimedAttributes [0] ClaimedAttributes, claimedAttributes [0] ClaimedAttributes,
certifiedAttributes [1] CertifiedAttributes } certifiedAttributes [1] CertifiedAttributes
}
Internet Draft Electronic Signature Formats
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
NOTE: The claimed and certified attribute are imported from ITU-T NOTE: The claimed and certified attribute are imported from ITU-T
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.3 Content Timestamp 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
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 ref .. temp For further information and definition of TimeStampToken see [TSP].
note; need to add the reference to the timestamping RFC.
3.13 Support for Multiple Signatures 3.13 Support for Multiple Signatures
3.13.1 Independent Signatures 3.13.1 Independent Signatures
Multiple independent signatures (see clause 55) are supported by Multiple independent signatures are supported by independent SignerInfo
independent SignerInfo from each signer. from each signer.
Each SignerInfo must include all the attributes required under this Each SignerInfo must include all the attributes required under this
document and must be processed independently by the verifier. document and must be processed independently by the verifier.
3.13.2 Embedded Signatures 3.13.2 Embedded Signatures
Multiple embedded signatures (see clause B.6) are supported using the Multiple embedded signatures are supported using the counter-signature
counter-signature unsigned attribute (see clause 10.1). Each counter unsigned attribute (see clause 3.10.1). Each counter signature is
signature is carried in Countersignature held as an unsigned attribute carried in Countersignature held as an unsigned attribute to the
to the SignerInfo to which the counter-signature is applied. SignerInfo to which the counter-signature is applied.
Internet Draft Electronic Signature Formats
4. Validation Data 4. Validation Data
This clause specifies the validation data structures which builds on This clause specifies the validation data structures which builds on
the electronic signature specified in clause 3. This includes: the electronic signature specified in clause 3. This includes:
* Timestamp applied to the electronic signature value. * Timestamp applied to the electronic signature value.
* Complete validation data which comprises the timestamp of the * Complete validation data which comprises the timestamp of the
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.
* 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.
skipping to change at page 28, line 53 skipping to change at page 30, line 35
* Archive validation data comprises a Complete validation data, * Archive validation data comprises a Complete validation data,
the certificate and revocation values (as in a X-Long the certificate and revocation values (as in a X-Long
validation data), any other existing X-timestamps, plus the validation data), any other existing X-timestamps, plus the
Signed User data and an additional archive timestamp over all Signed User data and an additional archive timestamp over all
that data. An archive timestamp may be repeatedly applied that data. An archive timestamp may be repeatedly applied
after long periods to maintain validity when electronic after long periods to maintain validity when electronic
signature and timestamping algorithms weaken. signature and timestamping algorithms weaken.
The additional data required to create the forms of electronic The additional data required to create the forms of electronic
signature identified above is carried as unsigned attributes associated signature identified above is carried as unsigned attributes
with an individual signature by being placed in the unsignedAttrs field associated with an individual signature by being placed in the
of SignerInfo (see clause 6????). Thus all the attributes defined in unsignedAttrs field of SignerInfo. Thus all the attributes defined
clause 9?? are unsigned attributes. in clause 4 are unsigned attributes.
Internet Draft Electronic Signature Formats
NOTE: Where multiple signatures are to be supported, as described in NOTE: Where multiple signatures are to be supported, as described in
clause 3.13, each signature has a separate SignerInfo. Thus, each clause 3.13, each signature has a separate SignerInfo. Thus, each
signature requires its own unsigned attribute values to create ES-T, signature requires its own unsigned attribute values to create ES-T,
ES-C etc. ES-C etc.
4.1 Electronic Signature Timestamp 4.1 Electronic Signature Timestamp
An Electronic Signature with Timestamp is an Electronic Signature for An Electronic Signature with Timestamp is an Electronic Signature for
which part, but not all, of the additional data required for validation which part, but not all, of the additional data required for validation
is available (i.e. some certificates and revocation information is is available (e.g. some certificates and revocation information is
available but not all). The minimum structure Timestamp validation data available but not all).
is:
* The Signature Timestamp Attribute as defined in clause 4.1.1 The minimum structure Timestamp validation data is the Signature
over the ES signature value. Timestamp Attribute as defined in clause 4.1.1 over the ES signature
value.
4.1.1 Signature Timestamp Attribute Definition 4.1.1 Signature Timestamp Attribute Definition
The Signature Timestamp attribute is timestamp of the signature value. The Signature Timestamp attribute is timestamp of the signature value.
It is an unsigned attribute. Several instances of this attribute may It is an unsigned attribute. Several instances of this attribute from
occur with an electronic signature, from different TSAs. different TSAs may occur with an electronic signature.
Internet Draft Electronic Signature Formats
The Signature Validation Policy specifies, in the The Signature Validation Policy specifies, in the
signatureTimestampDelay field of TimestampTrustConditions, an maximum signatureTimestampDelay field of TimestampTrustConditions, a maximum
acceptable time difference which is allowed between the time indicated acceptable time difference which is allowed between the time indicated
in the signing time attribute and the time indicated by the Signature in the signing time attribute and the time indicated by the Signature
Timestamp attribute. If this delay is exceeded then the electronic Timestamp attribute. If this delay is exceeded then the electronic
signature must be considered as invalid. signature must be considered as invalid.
The following object identifier identifies the Signature Timestamp The following object identifier identifies the Signature Timestamp
attribute: attribute:
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}
The Signature timestamp attribute value has ASN.1 type The Signature timestamp attribute value has ASN.1 type
SignatureTimeStampToken: SignatureTimeStampToken.
SignatureTimeStampToken ::= TimeStampToken SignatureTimeStampToken ::= TimeStampToken
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 signature field within SignerInfo for the signedData of the value of signature field within SignerInfo for the signedData
being timestamped. being timestamped.
For further information and definition of TimeStampToken see [TSP] For further information and definition of TimeStampToken see [TSP]
Temp note ;ref to timestamping doc required
Internet Draft Electronic Signature Formats
4.2 Complete Validation Data 4.2 Complete Validation Data
An electronic signature with complete validation data is an Electronic An electronic signature with complete validation data is an Electronic
Signature for which all the additional data required for validation Signature for which all the additional data required for validation
(i.e. all certificates and revocation information) is available. (i.e. all certificates and revocation information) is available.
Complete validation data (ES-C) build on the electronic signature Complete validation data (ES-C) build on the electronic signature
Timestamp as defined above. Timestamp as defined above.
The minimum structure of a Complete validation data is: The minimum structure of a Complete validation data is:
skipping to change at page 31, line ? skipping to change at page 31, line 41
4.2 Complete Validation Data 4.2 Complete Validation Data
An electronic signature with complete validation data is an Electronic An electronic signature with complete validation data is an Electronic
Signature for which all the additional data required for validation Signature for which all the additional data required for validation
(i.e. all certificates and revocation information) is available. (i.e. all certificates and revocation information) is available.
Complete validation data (ES-C) build on the electronic signature Complete validation data (ES-C) build on the electronic signature
Timestamp as defined above. Timestamp as defined above.
The minimum structure of a Complete validation data is: The minimum structure of a Complete validation data is:
* the Signature Timestamp Attribute, as defined in clause 4.1.1; * the Signature Timestamp Attribute, as defined in clause 4.1.1;
* Complete Certificate Refs, as defined in clause 4.2.1; * Complete Certificate Refs, as defined in clause 4.2.1;
* Complete Revocation Refs, as defined in clause 4.2.2. * Complete Revocation Refs, as defined in clause 4.2.2.
The Complete validation data MAY also include the following additional The Complete validation data MAY also include the following additional
information, forming a X-Long validation data, for use if later information, forming a X-Long validation data, for use if later
validation processes may not have access to this information: validation processes may not have access to this information:
* Complete Certificate Values, as defined in clause 4.2.3; * Complete Certificate Values, as defined in clause 4.2.3;
* Complete Revocation Values, as defined in clause 4.2.4. * Complete Revocation Values, as defined in clause 4.2.4.
The Complete validation data MAY also include one of the following The Complete validation data MAY also include one of the following
additional attributes, forming a X-Timestamp validation data, to additional attributes, forming a X-Timestamp validation data, to
provide additional protection against later CA compromise and provide provide additional protection against later CA compromise and provide
integrity of the validation data used: integrity of the validation data used:
* ES-C Timestamp, as defined in clause 4.2.5; or * ES-C Timestamp, as defined in clause 4.2.5; or
* Time-Stamped Certificates and CRLs references, as defined in * Time-Stamped Certificates and CRLs references, as defined in
clause 4.2.6. clause 4.2.6.
Internet Draft Electronic Signature Formats
NOTE 1: As long as the CA's are trusted such that these keys cannot NOTE 1: As long as the CA's are trusted such that these keys cannot
be compromised or the cryptography used broken, the ES-C provides long be compromised or the cryptography used broken, the ES-C provides long
term proof of a valid electronic signature. term proof of a valid electronic signature.
A valid electronic signature is an electronic signature which passes A valid electronic signature is an electronic signature which passes
validation according to a signature validation policy. validation according to a signature validation policy.
NOTE 2: The ES-C provides the following important property for long NOTE 2: The ES-C provides the following important property for long
standing signatures; that is having been found once to be valid, must standing signatures; that is having been found once to be valid, must
continue to be so months or years later. Long after the validity period continue to be so months or years later. Long after the validity period
skipping to change at page 32, line 5 skipping to change at page 32, line 28
compromised. compromised.
4.2.1 Complete Certificate Refs Attribute Definition 4.2.1 Complete Certificate Refs Attribute Definition
The Complete Certificate Refs attribute is an unsigned attribute. It The Complete Certificate Refs attribute is an unsigned attribute. It
references the full set of CA certificates that have been used to references the full set of CA certificates that have been used to
validate a ES with Complete validation data (ES-C) up to (but not validate a ES with Complete validation data (ES-C) up to (but not
including) the signer's certificate. Only a single instance of this including) the signer's certificate. Only a single instance of this
attribute must occur with an electronic signature. attribute must occur with an electronic signature.
Internet Draft Electronic Signature Formats
Note: The signer's certified is referenced in the signing certificate Note: The signer's certified is referenced in the signing certificate
attribute (see clause 3.1). attribute (see clause 3.1).
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}
The complete certificate refs attribute value has the ASN.1 syntax The complete certificate refs attribute value has the ASN.1 syntax
CompleteCertificateRefs. CompleteCertificateRefs.
CompleteCertificateRefs ::= SEQUENCE OF ETSICertID CompleteCertificateRefs ::= SEQUENCE OF OTHERCertID
ETSICertID is defined in clause 3.8.2. OTHERCertID is defined in clause 3.8.2.
The IssuerSerial that must be present in ETSICertID. The certHash The IssuerSerial that must be present in OTHERCertID. The certHash
must match the hash of the certificate referenced. must match the hash of the certificate referenced.
NOTE: Copies of the certificate values may be held using the NOTE: Copies of the certificate values may be held using the
Certificate Values attribute defined in clause 4.3.1. Certificate Values attribute defined in clause 4.3.1.
4.2.2 Complete Revocation Refs Attribute Definition 4.2.2 Complete Revocation Refs Attribute Definition
The Complete Revocation Refs attribute is an unsigned attribute. Only a The Complete Revocation Refs attribute is an unsigned attribute. Only a
single instance of this attribute must occur with an electronic single instance of this attribute must occur with an electronic
signature. It references the full set of the CRL or OCSP responses that signature. It references the full set of the CRL or OCSP responses that
have been used in the validation of the signer and CA certificates have been used in the validation of the signer and CA certificates
used in ES with Complete validation data. used in ES with Complete validation data.
The following object identifier identifies the CompleteRevocationRefs The following object identifier identifies the CompleteRevocationRefs
attribute: attribute:
id-aa-ets-revocationRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-aa-ets-revocationRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 22} us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 22}
Internet Draft Electronic Signature Formats
The complete revocation refs attribute value has the ASN.1 syntax The complete revocation refs attribute value has the ASN.1 syntax
CompleteRevocationRefs CompleteRevocationRefs.
CompleteRevocationRefs ::= SEQUENCE OF CrlOcspRef CompleteRevocationRefs ::= SEQUENCE OF CrlOcspRef
CrlOcspRef ::= SEQUENCE { CrlOcspRef ::= SEQUENCE {
crlids [0] CRLListID OPTIONAL, crlids [0] CRLListID OPTIONAL,
ocspids [1] OcspListID OPTIONAL, ocspids [1] OcspListID OPTIONAL,
otherRev [2] OtherRevRefs OPTIONAL otherRev [2] OtherRevRefs OPTIONAL
} }
Internet Draft Electronic Signature Formats
CompleteRevocationRefs must contain one CrlOcspRef for the signing CompleteRevocationRefs must contain one CrlOcspRef for the signing
certificate, followed by one for each ETSICertID in the certificate, followed by one for each OTHERCertID in the
CompleteCertificateRefs attribute. the second and subsequent CrlOcspRef CompleteCertificateRefs attribute. The second and subsequent CrlOcspRef
fields must be in the same order as the ETSICertID to which they fields must be in the same order as the OTHERCertID to which they
relate. At least one of CRLListID or OcspListID or OtherRevRefs should relate. At least one of CRLListID or OcspListID or OtherRevRefs should
be present for all but the "trusted" CA of the certificate path. be present for all but the "trusted" CA of the certificate path.
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}
skipping to change at page 33, line 47 skipping to change at page 34, line 5
-- As in OCSP response data -- As in OCSP response data
producedAt GeneralizedTime producedAt GeneralizedTime
-- As in OCSP response data -- As in OCSP response data
} }
When creating an crlValidatedID, the crlHash is computed over the When creating an crlValidatedID, the crlHash is computed over the
entire DER encoded CRL including the signature. The crlIdentifier would entire DER encoded CRL including the signature. The crlIdentifier would
normally be present unless the CRL can be inferred from other normally be present unless the CRL can be inferred from other
information. information.
Internet Draft Electronic Signature Formats
The crlIdentifier is to identify the CRL using the issuer name and the The crlIdentifier is to identify the CRL using the issuer name and the
CRL issued time which must correspond to the time "thisUpdate" CRL issued time which must correspond to the time "thisUpdate"
contained in the issued CRL. The crlListID attribute is an unsigned contained in the issued CRL. The crlListID attribute is an unsigned
attribute. In the case that the identified CRL is a Delta CRL then attribute. In the case that the identified CRL is a Delta CRL then
references to the set of CRLs to provide a complete revocation list references to the set of CRLs to provide a complete revocation list
must be included. must be included.
The OcspIdentifier is to identify the OSCP response using the issuer The OcspIdentifier is to identify the OSCP response using the issuer
name and the time of issue of the OCSP response which must correspond name and the time of issue of the OCSP response which must correspond
to the time "producedAt" contained in the issued OCSP response. Since to the time "producedAt" contained in the issued OCSP response. Since
it may be needed to make the difference between two OCSP responses it may be needed to make the difference between two OCSP responses
received within the same second, then the hash of the response contained received within the same second, then the hash of the response
in the OcspResponsesID may be needed to solve the ambiguity. contained in the OcspResponsesID may be needed to solve the ambiguity.
Internet Draft Electronic Signature Formats
NOTE: Copies of the CRL and OCSP responses values may be held using the NOTE: Copies of the CRL and OCSP responses values may be held using
Revocation Values attribute defined in clause 4.3.2. the Revocation Values attribute defined in clause 4.3.2.
OtherRevRefs ::= SEQUENCE { OtherRevRefs ::= SEQUENCE {
otherRevRefType OtherRevRefType, otherRevRefType OtherRevRefType,
otherRevRefs ANY DEFINED BY otherRevRefType otherRevRefs ANY DEFINED BY otherRevRefType
} }
OtherRevRefType ::= OBJECT IDENTIFIER OtherRevRefType ::= OBJECT IDENTIFIER
The syntax and semantics of other revocation references is outside the The syntax and semantics of other revocation references is outside the
scope of this document. The definition of the syntax of the other form scope of this document. The definition of the syntax of the other form
skipping to change at page 34, line 41 skipping to change at page 34, line 55
structure but must be provided by the signer as a signer-attributes structure but must be provided by the signer as a signer-attributes
attribute (see clause 12.3). attribute (see clause 12.3).
The following object identifier identifies the CertificateValues The following object identifier identifies the CertificateValues
attribute: attribute:
id-aa-ets-certValues OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-aa-ets-certValues OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 23} us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 23}
The certificate values attribute value has the ASN.1 syntax The certificate values attribute value has the ASN.1 syntax
CertificateValues CertificateValues.
CertificateValues ::= SEQUENCE OF Certificate CertificateValues ::= SEQUENCE OF Certificate
Certificate is defined in clause 10.1 (which is as defined in ITU-T Certificate is defined in RFC2459 and ITU-T Recommendation X.509 [1])
Recommendation X.509 [1])
Internet Draft Electronic Signature Formats Internet Draft Electronic Signature Formats
4.3.2 Revocation Values Attribute Definition 4.3.2 Revocation Values Attribute Definition
The Revocation Values attribute is an unsigned attribute. Only a single The Revocation Values attribute is an unsigned attribute. Only a single
instance of this attribute must occur with an electronic signature. instance of this attribute must occur with an electronic signature. It
It holds the values of CRLs and OCSP referenced in the holds the values of CRLs and OCSP referenced in the
CompleteRevocationRefs attribute. CompleteRevocationRefs attribute.
The following object identifier identifies the CertificateValues The following object identifier identifies the Revocation Values
attribute: attribute:
id-aa-ets-revocationValues OBJECT IDENTIFIER ::= { iso(1) member- id-aa-ets-revocationValues OBJECT IDENTIFIER ::= { iso(1) member-
body(2) body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 24} id-aa(2) 24}
The revocation values attribute value has the ASN.1 syntax The revocation values attribute value has the ASN.1 syntax
RevocationValues RevocationValues.
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 OtherRevValType, otherRevValType OtherRevValType,
otherRevVals ANY DEFINED BY otherRevValType otherRevVals ANY DEFINED BY otherRevValType
} }
OtherRevValType ::= OBJECT IDENTIFIER OtherRevValType ::= OBJECT IDENTIFIER
The syntax and semantics of the other revocation values is outside the The syntax and semantics of the other revocation values is outside the
scope of this document. The definition of the syntax of the other form scope of this document. The definition of the syntax of the other form
of revocation information is as identified by OtherRevRefType. of revocation information is as identified by OtherRevRefType.
CertificateList is defined in clause 10.2 (which as defined in ITU-T CertificateList is defined in RFC 2459 [RFC2459] and in ITU-T
Recommendation X.509 [1]). Recommendation X.509 [X509]).
BasicOCSPResponse is defined in clause 10.3 (which as defined in ??? RFC BasicOCSPResponse is defined in RFC 2560 [OCSP].
2560 [8] ???).
4.3.3 ES-C Timestamp Attribute Definition 4.3.3 ES-C Timestamp Attribute Definition
This attribute is used for the Type 1 X-Timestamped validation data. This attribute is used for the Type 1 X-Timestamped validation data.
The ES-C Timestamp attribute is an unsigned attribute. It is timestamp The ES-C Timestamp attribute is an unsigned attribute. It is timestamp
of a hash of the electronic signature and the complete validation data of a hash of the electronic signature and the complete validation data
(ES-C). It is a special purpose TimeStampToken Attribute which (ES-C). It is a special purpose TimeStampToken Attribute which
timestamps the ES-C. Several instances instance of this attribute may timestamps the ES-C. Several instances instance of this attribute may
occur with an electronic signature from different TSAs. occur with an electronic signature from different TSAs.
The following object identifier identifies the ES-C Timestamp The following object identifier identifies the ES-C Timestamp
attribute: attribute:
id-aa-ets-escTimeStamp OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-aa-ets-escTimeStamp OBJECT IDENTIFIER ::= { iso(1) member-
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 25} body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
id-aa(2) 25}
Internet Draft Electronic Signature Formats Internet Draft Electronic Signature Formats
The ES-C timestamp attribute value has the ASN.1 syntax The ES-C timestamp attribute value has the ASN.1 syntax
ESCTimeStampToken. ESCTimeStampToken.
ESCTimeStampToken ::= TimeStampToken ESCTimeStampToken ::= TimeStampToken
The value of messageImprint field within TimeStampToken must be a hash The value of messageImprint field within TimeStampToken must be a hash
of the concatenated values (without the type or length encoding for of the concatenated values (without the type or length encoding for
skipping to change at page 36, line 26 skipping to change at page 36, line 26
* signature field within SignerInfo; * signature field within SignerInfo;
* SignatureTimeStampToken attribute; * SignatureTimeStampToken attribute;
* CompleteCertificateRefs attribute; * CompleteCertificateRefs attribute;
* CompleteRevocationRefs attribute. * CompleteRevocationRefs attribute.
For further information and definition of the Time Stamp Token see For further information and definition of the Time Stamp Token see
clause [TSP]. [TSP].
Temp note ;ref to timestamping doc required.
4.3.4 Time-Stamped Certificates and CRLs Attribute Definition 4.3.4 Time-Stamped Certificates and CRLs Attribute Definition
This attribute is used for the Type 2 X-Timestamp validation data. A This attribute is used for the Type 2 X-Timestamp validation data. A
TimestampedCertsCRLsRef attribute is an unsigned attribute. It is a TimestampedCertsCRLsRef attribute is an unsigned attribute. It is a
list of referenced certificates and OCSP responses/CRLs which are been list of referenced certificates and OCSP responses/CRLs which are been
timestamped to protect against certain CA compromises. Its syntax is as timestamped to protect against certain CA compromises. Its syntax is as
follows: follows:
The following object identifier identifies the TimestampedCertsCRLsRef The following object identifier identifies the TimestampedCertsCRLsRef
attribute: attribute:
id-aa-ets-certCRLTimestamp OBJECT IDENTIFIER ::= { iso(1) member- id-aa-ets-certCRLTimestamp OBJECT IDENTIFIER ::= { iso(1) member-
body(2) body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 26} id-aa(2) 26}
The attribute value has the ASN.1 syntax TimestampedCertsCRLs. The attribute value has the ASN.1 syntax TimestampedCertsCRLs.
TimestampedCertsCRLs ::= TimeStampToken TimestampedCertsCRLs ::= TimeStampToken
The value of messageImprint field within TimeStampToken must be a hash The value of messageImprint field within TimeStampToken must be a hash
of the concatenated values (without the type or length encoding for of the concatenated values (without the type or length encoding for
that value) of the following data objects as present in the ES with that value) of the following data objects as present in the ES with
Complete validation data (ES-C): Complete validation data (ES-C):
* CompleteCertificateRefs attribute; * CompleteCertificateRefs attribute;
* CompleteRevocationRefs attribute. * CompleteRevocationRefs attribute.
Internet Draft Electronic Signature Formats
4.4 Archive Validation Data 4.4 Archive Validation Data
Where an electronic signature is required to last for a very long time, Where an electronic signature is required to last for a very long time,
and a the timestamp on an electronic signature is in danger of being and a the timestamp on an electronic signature is in danger of being
invalidated due to algorithm weakness or limits in the validity period invalidated due to algorithm weakness or limits in the validity period
of the TSA certificate, then it may be required to timestamp the of the TSA certificate, then it may be required to timestamp the
Internet Draft Electronic Signature Formats
electronic signature several times. When this is required an archive electronic signature several times. When this is required an archive
timestamp attribute may be required. This timestamp may be repeatedly timestamp attribute may be required. This timestamp may be repeatedly
applied over a period of time. applied over a period of time.
4.4.1 Archive Timestamp Attribute Definition 4.4.1 Archive Timestamp Attribute Definition
The Archive Timestamp attribute is timestamp of the user data and the The Archive Timestamp attribute is timestamp of the user data and the
entire electronic signature. If the Certificate values and Revocation entire electronic signature. If the Certificate values and Revocation
Values attributes are not present these attributes must be added to Values attributes are not present these attributes must be added to
the electronic signature prior to the timestamp. The Archive Timestamp the electronic signature prior to the timestamp. The Archive Timestamp
attribute is an unsigned attribute. Several instances of this attribute attribute is an unsigned attribute. Several instances of this attribute
may occur with on electronic signature both over time and from may occur with on electronic signature both over time and from
different TSAs. different TSAs.
The following object identifier identifies the Nested Archive Timestamp The following object identifier identifies the Nested Archive Timestamp
attribute: attribute:
id-aa-ets-archiveTimestamp OBJECT IDENTIFIER ::= { iso(1) member- id-aa-ets-archiveTimestamp OBJECT IDENTIFIER ::= { iso(1) member-
body(2) body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 27} id-aa(2) 27}
Archive timestamp attribute values have the ASN.1 syntax Archive timestamp attribute values have the ASN.1 syntax
ArchiveTimeStampToken ArchiveTimeStampToken
ArchiveTimeStampToken ::= TimeStampToken ArchiveTimeStampToken ::= TimeStampToken
The value of messageImprint field within TimeStampToken must be a hash The value of messageImprint field within TimeStampToken must be a hash
of the concatenated values (without the type or length encoding for of the concatenated values (without the type or length encoding for
that value) of the following data objects as present in the electronic that value) of the following data objects as present in the electronic
signature: signature:
* encapContentInfo eContent OCTET STRING; * encapContentInfo eContent OCTET STRING;
* signedAttributes; * signedAttributes;
* signature field within SignerInfo; * signature field within SignerInfo;
* SignatureTimeStampToken attribute; * SignatureTimeStampToken attribute;
* CompleteCertificateRefs attribute; * CompleteCertificateRefs attribute;
* CompleteRevocationData attribute; * CompleteRevocationData attribute;
* CertificateValues attribute * CertificateValues attribute
(If not already present this information must be included in the (If not already present this information must be included in
ES-A); the ES-A);
* RevocationValues attribute * RevocationValues attribute
(If not already present this information must be included in the (If not already present this information must be included in
ES-A); the ES-A);
* ESCTimeStampToken attribute if present; * ESCTimeStampToken attribute if present;
* TimestampedCertsCRLs attribute if present; * TimestampedCertsCRLs attribute if present;
* any previous ArchiveTimeStampToken attributes. * any previous ArchiveTimeStampToken attributes.
Internet Draft Electronic Signature Formats For further information and definition of TimeStampToken see [TSP]
For further information and definition of TimeStampToken see see [TSP]
Temp note ;ref to timestamping doc required
The timestamp should be created using stronger algorithms (or longer The timestamp should be created using stronger algorithms (or longer
key lengths) than in the original electronic signatures and weak key lengths) than in the original electronic signatures.
algorithm (key length) timestamps .
5. Signature Policy Specification
This document mandates that:
* an electronic signature must be processed by the signer and
verifier in accordance with the signature policy as identified
by the signature policy attribute (see clause 4.1);
* the signature policy must be identifiable by an Object
Identifier;
* there must exist a specification of the signature policy;
* for a given signature policy there must be one definitive form
of the specification which has a unique binary encoding;
* a hash of the definitive specification, using an agreed
algorithm, must be provided by the signer and checked by the
verifier (see clause 4.1).
A signature policy specification includes general information about the
policy, the validation policy rules and other signature policy
information.
Clause 6 describes the kind of information to be included in a
signature policy.
The current document does not mandate the form of the signature policy
specification. The signature policy may be specified either:
* in a free form document for human interpretation; or
* in a structured form using an agreed syntax and encoding.
This document defines an ASN.1 based syntax that may be used to define
a structured signature policy.
5.1 Overall ASN.1 Structure
The overall structure of a signature policy defined using ASN.1 is
given in this clause. Use of this ASN.1 structure is optional.
This ASN.1 syntax is encoded using the Distinguished Encoding Rules
(DER).
Internet Draft Electronic Signature Formats
In this structure the policy information is preceded by an identifier
for the hashing algorithm used to protect the signature policy and
followed by the hash value which must be re-calculated and checked
whenever the policy is passed between the issuer and signer/verifier.
The hash is calculated without the outer type and length fields.
SignaturePolicy ::= SEQUENCE {
signPolicyHashAlg AlgorithmIdentifier,
signPolicyInfo SignPolicyInfo,
signPolicyHash SignPolicyHash OPTIONAL }
SignPolicyHash ::= OCTET STRING
SignPolicyInfo ::= SEQUENCE {
signPolicyIdentifier SignPolicyId,
dateOfIssue GeneralizedTime,
policyIssuerName PolicyIssuerName,
fieldOfApplication FieldOfApplication,
signatureValidationPolicy SignatureValidationPolicy,
signPolExtensions SignPolExtensions
OPTIONAL
}
SignPolicyId ::= OBJECT IDENTIFIER
The policyIssuerName field identifies the policy issuer in one or more
of the general name forms.
PolicyIssuerName ::= GeneralNames
The fieldofApplication is a description of the expected application of
this policy.
FieldOfApplication ::= DirectoryString
The signature validation policy rules are fully processable to allow
the validation of electronic signatures issued under that signature
policy. They are described in the rest of this clause.
5.2 Signature Validation Policy
The signature validation policy defines for the signer which data
elements must be present in the electronic signature he provides and
for the verifier which data elements must be present under that
signature policy for an electronic signature to be potentially valid.
Internet Draft Electronic Signature Formats
The signature validation policy is described as follows:
SignatureValidationPolicy ::= SEQUENCE {
signingPeriod SigningPeriod,
commonRules CommonRules,
commitmentRules CommitmentRules,
signPolExtensions SignPolExtensions OPTIONAL
}
The signingPeriod identifies the date and time before which the
signature policy should not be used for creating signatures, and an
optional date after which it should not be used for creating
signatures.
SigningPeriod ::= SEQUENCE {
notBefore GeneralizedTime,
notAfter GeneralizedTime OPTIONAL }
5.3 Common Rules
The CommonRules define rules that are common to all commitment types.
These rules are defined in terms of trust conditions for certificates,
timestamps and attributes, along with any constraints on attributes
that may be included in the electronic signature.
CommonRules ::= SEQUENCE {
signerAndVeriferRules [0] SignerAndVerifierRules
OPTIONAL,
signingCertTrustCondition [1] SigningCertTrustCondition
OPTIONAL,
timeStampTrustCondition [2] TimestampTrustCondition
OPTIONAL,
attributeTrustCondition [3] AttributeTrustCondition
OPTIONAL,
algorithmConstraintSet [4] AlgorithmConstraintSet
OPTIONAL,
signPolExtensions [5] SignPolExtensions
OPTIONAL
}
If a field is present in CommonRules then the equivalent field must
not be present in any of the CommitmentRules (see below). If any of the
following fields are not present in CommonRules then it must be
present in each CommitmentRule:
* signerAndVeriferRules;
* signingCertTrustCondition;
* timeStampTrustCondition.
Internet Draft Electronic Signature Formats
5.4 Commitment Rules
The CommitmentRules consists of the validation rules which apply to
given commitment types:
CommitmentRules ::= SEQUENCE OF CommitmentRule
The CommitmentRule for given commitment types are defined in terms of
trust conditions for certificates, timestamps and attributes, along
with any constraints on attributes that may be included in the
electronic signature.
CommitmentRule ::= SEQUENCE {
selCommitmentTypes SelectedCommitmentTypes,
signerAndVeriferRules [0] SignerAndVerifierRules
OPTIONAL,
signingCertTrustCondition [1] SigningCertTrustCondition
OPTIONAL,
timeStampTrustCondition [2] TimestampTrustCondition
OPTIONAL,
attributeTrustCondition [3] AttributeTrustCondition
OPTIONAL,
algorithmConstraintSet [4] AlgorithmConstraintSet
OPTIONAL,
signPolExtensions [5] SignPolExtensions
OPTIONAL
}
SelectedCommitmentTypes ::= SEQUENCE OF CHOICE {
empty NULL,
recognizedCommitmentType CommitmentType }
If the SelectedCommitmentTypes indicates "empty" then this rule applied
when a commitment type is not present (i.e.the type of commitment is
indicated in the semantics of the message). Otherwise, the electronic
signature must contain a commitment type indication that must fit one
of the commitments types that are mentioned in CommitmentType.
A specific commitment type identifier must not appear in more than one
commitment rule.
CommitmentType ::= SEQUENCE {
identifier CommitmentTypeIdentifier,
fieldOfApplication [0] FieldOfApplication OPTIONAL,
semantics [1] DirectoryString OPTIONAL }
The fieldOfApplication and semantics fields define the specific use and
meaning of the commitment within the overall field of application
defined for the policy.
Internet Draft Electronic Signature Formats
5.5 Signer and Verifier Rules
The SignerAndVerifierRules consists of signer rule and verification
rules as defined below:
SignerAndVerifierRules ::= SEQUENCE {
signerRules SignerRules,
verifierRules VerifierRules }
5.5.1 Signer Rules
The signer rules identify:
* if the eContent is empty and the signature is calculated using
a hash of signed data external to CMS structure.
* the CMS signed attributes that must be provided by the signer
under this policy;
* the CMS unsigned attribute that must be provided by the signer
under this policy;
* whether the certificate identifiers from the full certification
path up to the trust point must be provided by the signer in
the SigningCertificate attribute;
* whether a signer's certificate, or all certificates in the
certification path to the trust point must be provided by the
signer in the certificates field of SignedData.
SignerRules ::= SEQUENCE {
externalSignedData BOOLEAN OPTIONAL,
-- True if signed data is external to CMS structure
-- False if signed data part of CMS structure
-- not present if either allowed
mandatedSignedAttr CMSAttrs,
-- Mandated CMS signed attributes
mandatedUnsignedAttr CMSAttrs,
-- Mandated CMS unsigned attributed
mandatedCertificateRef [0] CertRefReq DEFAULT signerOnly,
-- Mandated Certificate Reference
mandatedCertificateInfo [1] CertInfoReq DEFAULT none,
-- Mandated Certificate Info
signPolExtensions [2] SignPolExtensions OPTIONAL
}
CMSAttrs ::= SEQUENCE OF OBJECT IDENTIFIER
The mandatedSignedAttr field must include the object identifier for
all those signed attributes required by this document as well as
additional attributes required by this policy.
Internet Draft Electronic Signature Formats
The mandatedUnsignedAttr field must include the object identifier for
all those unsigned attributes required by this document as well as
additional attributes required this policy. For example, if a signature
timestamp (see clause 1.1) is required by the signer the object
identifier for this attribute must be included.
The mandatedCertificateRef identifies whether just the signer's
certificate, or all the full certificate path must be provided by the
signer.
CertRefReq ::= ENUMERATED {
signerOnly (1),
-- Only reference to signer cert mandated
fullPath (2)
-- References for full cert path up to a trust point required
}
The mandatedCertificateInfo field identifies whether a signer's
certificate, or all certificates in the certification path to the trust
point must be provided by the signer in the certificates field of
SignedData.
CertInfoReq ::= ENUMERATED {
none (0) ,
-- No mandatory requirements
signerOnly (1) ,
-- Only reference to signer cert mandated
fullPath (2)
-- References for full cert path up to a
-- trust point mandated
}
5.5.2 Verifier Rules
The verifier rules identify:
* The CMS unsigned attributes that must be present under this policy
and must be added by the verifier if not added by the signer.
VerifierRules ::= SEQUENCE {
mandatedUnsignedAttr MandatedUnsignedAttr,
signPolExtensions SignPolExtensions OPTIONAL
}
MandatedUnsignedAttr ::= CMSAttrs
-- Mandated CMS unsigned attributed
Internet Draft Electronic Signature Formats
5.6 Certificate and Revocation Requirement
The SigningCertTrustCondition, TimestampTrustCondition and
AttributeTrustCondition (defined in subsequent sub-clauses) make use of
two ASN1 structures which are defined below: CertificateTrustTrees and
CertRevReq.
5.6.1 Certificate Requirements
The certificateTrustTrees identifies a set of self signed certificates
for the trust points used to start (or end) certificate path processing
and the initial conditions for certificate path validation as defined
RFC 2459 [7] section 5. This ASN1 structure is used to define policy
for validating the signing certificate, the TSA's certificate and
attribute certificates.
CertificateTrustTrees ::= SEQUENCE OF CertificateTrustPoint
CertificateTrustPoint ::= SEQUENCE {
trustpoint Certificate,
-- self-signed certificate
pathLenConstraint [0] PathLenConstraint OPTIONAL,
acceptablePolicySet [1] AcceptablePolicySet OPTIONAL,
-- If not present "any policy"
nameConstraints [2] NameConstraints OPTIONAL,
policyConstraints [3] PolicyConstraints OPTIONAL }
The trustPoint field gives the self signed certificate for the CA that
is used as the trust point for the start of certificate path
processing.
The pathLenConstraint field gives the maximum number of CA certificates
that may be in a certification path following the trustpoint. A value
of zero indicates that only the given trustpoint certificate and an
end-entity certificate may be used. If present, the pathLenConstraint
field must be greater than or equal to zero. Where pathLenConstraint
is not present, there is no limit to the allowed length of the
certification path.
PathLenConstraint ::= INTEGER (0..MAX)
The acceptablePolicySet field identifies the initial set of certificate
policies, any of which are acceptable under the signature policy.
AcceptablePolicySet ::= SEQUENCE OF CertPolicyId
CertPolicyId ::= OBJECT IDENTIFIER
Internet Draft Electronic Signature Formats
The nameConstraints field indicates a name space within which all
subject names in subsequent certificates in a certification path must
be located. Restrictions may apply to the subject distinguished name or
subject alternative names. Restrictions apply only when the specified
name form is present. If no name of the type is in the certificate, the
certificate is acceptable.
Restrictions are defined in terms of permitted or excluded name
subtrees. Any name matching a restriction in the excludedSubtrees field
is invalid regardless of information appearing in the ermittedSubtrees.
NameConstraints ::= SEQUENCE {
permittedSubtrees [0] GeneralSubtrees OPTIONAL,
excludedSubtrees [1] GeneralSubtrees OPTIONAL }
GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree
GeneralSubtree ::= SEQUENCE {
base GeneralName,
minimum [0] BaseDistance DEFAULT 0,
maximum [1] BaseDistance OPTIONAL }
BaseDistance ::= INTEGER (0..MAX)
The policyConstraints extension constrains path processing in two ways.
It can be used to prohibit policy mapping or require that each
certificate in a path contain an acceptable policy identifier.
The policyConstraints field, if present specifies requirement for
explicit indication of the certificate policy and/or the constraints on
policy mapping.
PolicyConstraints ::= SEQUENCE {
requireExplicitPolicy [0] SkipCerts OPTIONAL,
inhibitPolicyMapping [1] SkipCerts OPTIONAL }
SkipCerts ::= INTEGER (0..MAX)
If the inhibitPolicyMapping field is present, the value indicates the
number of additional certificates that may appear in the path
(including the trustpoint's self certificate) before policy mapping is
no longer permitted. For example, a value of one indicates that policy
mapping may be processed in certificates issued by the subject of this
certificate, but not in additional certificates in the path.
If the requireExplicitPolicy field is present, subsequent certificates
must include an acceptable policy identifier. The value of
requireExplicitPolicy indicates the number of additional certificates
that may appear in the path (including the trustpoint's self
certificate) before an explicit policy is required. An acceptable
policy identifier is the identifier of a policy required by the user of
the certification path or the identifier of a policy which has been
declared equivalent through policy mapping.
Internet Draft Electronic Signature Formats
5.6.2 Revocation Requirements
The RevocRequirements field specifies minimum requirements for
revocation information, obtained through CRLs and/or OCSP responses, to
be used in checking the revocation status of certificates. This ASN1
structure is used to define policy for validating the signing
certificate, the TSA's certificate and attribute certificates.
CertRevReq ::= SEQUENCE {
endCertRevReq RevReq,
caCerts [0] RevReq
}
Certificate revocation requirements are specified in terms of checks
required on:
* endCertRevReq: end certificates (i.e. the signers certificate,
the attribute certificate or the timestamping authority
certificate).
* caCerts: CA certificates.
RevReq ::= SEQUENCE {
enuRevReq EnuRevReq,
exRevReq SignPolExtensions OPTIONAL}
An authority certificate is certificate issued to an authority (e.g.
either to a certification authority or to an attribute authority (AA)).
A TimeStamping Authority (TSA) is a trusted third party that creates
time stamp tokens in order to indicate that a datum existed at a
particular point in time (RFC??: "Internet X.509 Public Key
Infrastructure - Time Stamp Protocol").
EnuRevReq ::= ENUMERATED {
clrCheck (0),
--Checks must be made against current CRLs
-- (or authority revocation lists (ARL))
ocspCheck (1), -- The revocation status must be checked
-- using the Online Certificate Status Protocol
-- (OCSP),RFC 2450.
bothCheck (2),
-- Both CRL and OCSP checks must be carried out
eitherCheck (3),
-- At least one of CRL or OCSP checks must be
-- carried out
noCheck (4),
-- no check is mandated
other (5)
-- Other mechanism as defined by signature poilicy
-- extension
}
Internet Draft Electronic Signature Formats
Revocation requirements are specified in terms of:
* clrCheck: Checks must be made against current CRLs (or
authority revocation lists);
* ocspCheck: The revocation status must be checked using the
Online Certificate Status Protocol (RFC 2450);
* bothCheck: Both OCSP and CRL checks must be carried out;
* eitherCheck: Either OCSP or CRL checks must be carried out;
* noCheck: No check is mandated.
5.7 Signing Certificate Trust Conditions
The SigningCertTrustCondition field identifies trust conditions for
certificate path processing used to validate the signing certificate.
SigningCertTrustCondition ::= SEQUENCE {
signerTrustTrees CertificateTrustTrees,
signerRevReq CertRevReq
}
5.8 TimeStamp Trust Conditions
The TimeStampTrustCondition field identifies trust conditions for
certificate path processing used to authenticate the timstamping
authority and constraints on the name of the timestamping authority.
This applies to the timestamp that must be present in every ES-T.
TimestampTrustCondition ::= SEQUENCE {
ttsCertificateTrustTrees [0] CertificateTrustTrees
OPTIONAL,
ttsRevReq [1] CertRevReq
OPTIONAL,
ttsNameConstraints [2] NameConstraints
OPTIONAL,
cautionPeriod [3] DeltaTime
OPTIONAL,
signatureTimestampDelay [4] DeltaTime
OPTIONAL }
DeltaTime ::= SEQUENCE {
deltaSeconds INTEGER,
deltaMinutes INTEGER,
deltaHours INTEGER,
deltaDays INTEGER }
If ttsCertificateTrustTrees is not present then the same rule as
defined in certificateTrustCondition applies to certification of the
timestamping authorities public key.
Internet Draft Electronic Signature Formats
The tstrRevReq specifies minimum requirements for revocation
information, obtained through CRLs and/or OCSP responses, to be used in
checking the revocation status of the time stamp that must be present
in the ES-T.
If ttsNameConstraints is not present then there are no additional
naming constraints on the trusted timestamping authority other than
those implied by the ttsCertificateTrustTrees.
The cautionPeriod field specifies a caution period after the signing
time that it is mandated the verifier must wait to get high assurance
of the validity of the signer's key and that any relevant revocation
has been notified. The revocation status information forming the ES
with Complete validation data must not be collected and used to
validate the electronic signature until after this caution period.
The signatureTimestampDelay field specifies a maximum acceptable time
between the signing time and the time at which the signature timestamp,
as used to form the ES Timestamped, is created for the verifier. If the
signature timestamp is later that the time in the signing-time
attribute by more than the value given in signatureTimestampDelay, the
signature must be considered invalid.
5.9 Attribute Trust Conditions
If the attributeTrustCondition field is not present then any certified
attributes may not considered to be valid under this validation policy.
The AttributeTrustCondition field is defined as follows:
AttributeTrustCondition ::= SEQUENCE {
attributeMandated BOOLEAN,
-- Attribute must be present
howCertAttribute HowCertAttribute,
attrCertificateTrustTrees [0] CertificateTrustTrees OPTIONAL,
attrRevReq [1] CertRevReq OPTIONAL,
attributeConstraints [2] AttributeConstraints OPTIONAL }
If attributeMandated is true then an attribute, certified within the
following constraints, must be present. If false, then the signature
is still valid if no attribute is specified.
The howCertAttribute field specifies whether attributes uncertified
attributes "claimed" by the signer, or certified in an attribute
certificate or either using the signer attributes attribute defined
in 4.12.3.
HowCertAttribute ::= ENUMERATED {
claimedAttribute (0),
certifiedAttribtes (1),
either (2) }
Internet Draft Electronic Signature Formats
The attrCertificateTrustTrees specifies certificate path conditions for
any attribute certificate. If not present the same rules apply as in
certificateTrustCondition.
The attrRevReq specifies minimum requirements for revocation
information, obtained through CRLs and/or OCSP responses, to be used in
checking the revocation status of Attribute Certificates, if any are
present.
If the attributeConstraints field is not present then there are no
constraints on the attributes that may be validated under this policy.
The attributeConstraints field is defined as follows:
AttributeConstraints ::= SEQUENCE {
attributeTypeConstarints [0] AttributeTypeConstraints
OPTIONAL,
attributeValueConstarints [1] AttributeValueConstraints
OPTIONAL }
If present, the attributeTypeConstarints field specifies the attribute
types which are considered valid under the signature policy. Any value
for that attribute is considered valid.
AttributeTypeConstraints ::= SEQUENCE OF AttributeType
If present, the attributeTypeConstraints field specifies the specific
attribute values which are considered valid under the signature policy.
AttributeValueConstraints ::= SEQUENCE OF AttributeTypeAndValue
5.10 Algorithm Constraints
The algorithmConstrains fields, if present, identifies the signing
algorithms (hash, public key cryptography, combined hash and public key
cryptography) that may be used for specific purposes and any minimum
length. If this field is not present then the policy applies no
constraints.
AlgorithmConstraintSet ::= SEQUENCE { -- Algorithm constrains on:
signerAlgorithmConstraints [0] AlgorithmConstraints OPTIONAL,
-- signer
eeCertAlgorithmConstraints [1] AlgorithmConstraints OPTIONAL,
-- issuer of end entity certs.
caCertAlgorithmConstraints [2] AlgorithmConstraints OPTIONAL,
-- issuer of CA certificates
aaCertAlgorithmConstraints [3] AlgorithmConstraints OPTIONAL,
-- Attribute Authority
tsaCertAlgorithmConstraints [4] AlgorithmConstraints OPTIONAL
-- TimeStamping Authority
}
Internet Draft Electronic Signature Formats Internet Draft Electronic Signature Formats
AlgorithmConstraints ::= SEQUENCE OF AlgAndLength 5. Security considerations
AlgAndLength ::= SEQUENCE {
algID OBJECT IDENTIFIER,
minKeyLength INTEGER OPTIONAL,
-- Minimum key length in bits
other SignPolExtensions OPTIONAL
}
An Attribute Authority (AA)is authority which assigns privileges by
issuing attribute certificates
5.11 Signature Policy Extensions
Additional signature policy rules may be added to:
* the overall signature policy structure, as defined in
clause 5.1;
* the signature validation policy structure, as defined in
clause 5.2;
* the common rules, as defined in clause 5.3;
* the commitment rules, as defined in clause 5.4;
* the signer rules, as defined in clause 5.5.1;
* the verifier rules, as defined in clause 5.5.2;
* the revocation requirements in clause 5.6.2;
* the algorithm constraints in clause 5.10.
These extensions to the signature policy rules must be defined using
an ASN.1 syntax with an associated object identifier carried in the
SignPolExtn as defined below:
SignPolExtensions ::= SEQUENCE OF SignPolExtn
SignPolExtn ::= SEQUENCE {
extnID OBJECT IDENTIFIER,
extnValue OCTET STRING }
The extnID field must contain the object identifier for the extension.
The extnValue field must contain the DER (see ITU-T Recommendation
X.690 [4]) encoded value of the extension. The definition of an
extension, as identified by extnID must include a definition of the
syntax and semantics of the extension.
6. Security considerations
6.1 Protection of Private Key 5.1 Protection of Private Key
The security of the electronic signature mechanism defined in this The security of the electronic signature mechanism defined in this
document depends on the privacy of the signer's private key. document depends on the privacy of the signer's private key.
Implementations must take steps to ensure that private keys cannot be Implementations must take steps to ensure that private keys cannot be
compromised. compromised.
Internet Draft Electronic Signature Formats 5.2 Choice of Algorithms
6.2 Choice of Algorithms
Implementers should be aware that cryptographic algorithms become Implementers should be aware that cryptographic algorithms become
weaker with time. As new cryptoanalysis techniques are developed and weaker with time. As new cryptoanalysis techniques are developed and
computing performance improves, the work factor to break a particular computing performance improves, the work factor to break a particular
cryptographic algorithm will reduce. Therefore, cryptographic algorithm cryptographic algorithm will reduce. Therefore, cryptographic algorithm
implementations should be modular allowing new algorithms to be readily implementations should be modular allowing new algorithms to be readily
inserted. That is, implementers should be prepared for the set of inserted. That is, implementers should be prepared for the set of
mandatory to implement algorithms to change over time. mandatory to implement algorithms to change over time.
7. Conformance Requirements 6. Conformance Requirements
This document only defines conformance requirements up to a ES with This document only defines conformance requirements up to a ES with
Complete validation data (ES-C). This means that none of the extended Complete validation data (ES-C). This means that none of the extended
and archive forms of Electronic Signature (ES-X, ES-A) need to be and archive forms of Electronic Signature (ES-X, ES-A) need to be
implemented to get conformance to this standard. implemented to get conformance to this standard.
This document mandates support for elements of the signature policy. This document mandates support for elements of the signature policy.
7.1 Signer 6.1 Signer
A system supporting signers according to this document must, at a A system supporting signers according to this document must, at a
minimum, support generation of an electronic signature consisting of minimum, support generation of an electronic signature consisting of
the following components: the following components:
* The general CMS syntax and content type as defined in RFC 2630 * The general CMS syntax and content type as defined in RFC 2630
(see clauses 4.1 and 4.2). (see clauses 4.1 and 4.2).
* CMS SignedData as defined in RFC 2630 with version set to 3 * CMS SignedData as defined in RFC 2630 with version set to 3
and at least one SignerInfo must be present and at least one SignerInfo must be present
skipping to change at page 51, line 40 skipping to change at page 38, line 49
the following components: the following components:
* The general CMS syntax and content type as defined in RFC 2630 * The general CMS syntax and content type as defined in RFC 2630
(see clauses 4.1 and 4.2). (see clauses 4.1 and 4.2).
* CMS SignedData as defined in RFC 2630 with version set to 3 * CMS SignedData as defined in RFC 2630 with version set to 3
and at least one SignerInfo must be present and at least one SignerInfo must be present
(see clauses 4.3, 4.4, 4.5, 4.6). (see clauses 4.3, 4.4, 4.5, 4.6).
* The following CMS Attributes as defined in RFC 2630 : * The following CMS Attributes as defined in RFC 2630 :
- ContentType; This must always be present - ContentType; This must always be present
(see clause 3.7.1); (see clause 3.7.1);
- MessageDigest; This must always be present - MessageDigest; This must always be present
(see clause 3.7.2); (see clause 3.7.2);
- SigningTime; This must always be present - SigningTime; This must always be present
(see clause 3.7.3). (see clause 3.7.3).
Internet Draft Electronic Signature Formats
* The following ESS Attributes as defined in RFC 2634 : * The following ESS Attributes as defined in RFC 2634 :
- 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).
Internet Draft Electronic Signature Formats 6.2 Verifier
7.2 Verifier
A system supporting verifiers according to this document must, at a A system supporting verifiers according to this document must, at a
minimum, support: 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 14.1.
* Signature Timestamp attribute, as defined in clause 5.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 5.2.1. clause 4.2.1.
* Complete Revocation Refs Attribute, as defined in * Complete Revocation Refs Attribute, as defined in
clause 5.2.2. clause 4.2.2.
* Public Key Certificates, as defined in ITU-T * Public Key Certificates, as defined in ITU-T
Recommendation X.509 and profiled in RFC 2459 Recommendation X.509 and profiled in RFC 2459.
(see clause 10.1)
* Either of: * Either of:
- Certificate Revocation Lists. as defined in ITU-T
Recommendation X.509 [1] and profiled in RFC 2459 [7]
(see clause 10.2); Or
- On-line Certificate Status Protocol, as defined in
RFC 2560 (see clause 10.3).
7.3 Signature Policy - Certificate Revocation Lists. as defined in ITU-T
Recommendation X.509 [1] and profiled in RFC 2459 [7];
or
Both signer and verifier systems must be able to process an electronic - On-line Certificate Status Protocol responses, as
signature in accordance with the specification of at least one defined in RFC 2560.
signature policy, as identified by the signature policy attribute
(see clause 4.9.1).
8. References Internet Draft Electronic Signature Formats
[RFC2510] C. Adams, S. Farrell, "Internet X.509 Public Key 7. References
Infrastructure, Certificate Management Protocols," RFC 2510, March 1999.
[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.
[RFC2246] T. Dierks, C. Allen, "The TLS Protocol, Version 1.0," RFC [ESS] P. Hoffman, "Enhanced Security Services for S/MIME",
2246, January 1999.
[RFC 2634] P. Hoffman, "Enhanced Security Services for S/MIME", [CMS] R. Housley, "Cryptographic Message Syntax", RFC 2630,
June 1999.
[RFC 2630] R. Housley, "Cryptographic Message Syntax", RFC 2630, June [OCSP] M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams.
1999. On-line Status Certificate Protocol, RFC 2560.
Internet Draft Electronic Signature Formats [TSP] C. Adams, P. Cain, D. Pinkas, R. Zuccherato. Time Stamp Protocol
(TSP), (under progress). June 2000.
[PTS] Public Telegram Service. ITU-T Recommendation F1. XXXX
[RFC2459] R. Housley, W. Ford, W. Polk, D. Solo, "Internet X.509 Public [RFC2459] R. Housley, W. Ford, W. Polk, D. Solo, "Internet X.509 Public
Key Infrastructure, Certificate and CRL Profile," RFC 2459, January Key Infrastructure, Certificate and CRL Profile," RFC 2459, January
1999. 1999.
[PKCS9] RSA Laboratories, "The Public-Key Cryptography Standards [PKCS9] RSA Laboratories, "The Public-Key Cryptography Standards
(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.
9. Authors' Addresses [ES201733] ETSI Standard ES 201 733 V1.1.3 (2000-05) Electronic
Signature Formats. Note: copies of ETSI ES 210 733 can be freely
downloaded from the ETSI web site www.etsi.org.
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
ETSI Contact Point Internet Draft Electronic Signature Formats
Contact Point
Harri Rasilainen Harri Rasilainen
ETSI ETSI
F-06921 Sophie Antipolis
650 Route des Lucioles 650 Route des Lucioles
Sophia Antipolis, Valbonne F-06921 Sophia Antipolis, Cedex
FRANCE FRANCE
harri.rasilainen@etsi.fr harri.rasilainen@etsi.fr
Additional Contact Points Denis Pinkas
Bull S.A.
12, rue de Paris
B.P. 59
78231 Le Pecq
FRANCE
Denis.Pinkas @bull.net
John Ross John Ross
Security & Standards Security & Standards
192 Moulsham Street 192 Moulsham Street
Chelmsford, Essex Chelmsford, Essex
CM2 0LG CM2 0LG
United Kingdom United Kingdom
ross@secstan.com ross@secstan.com
Denis Pinkas Nick Pope Nick Pope
Bull S.A. Security & Standards Security & Standards
12, rue de Paris 192 Moulsham Street 192 Moulsham Street
B.P. 59 Chelmsford, Essex Chelmsford, Essex
78231 Le Pecq CM2 0LG CM2 0LG
FRANCE United Kingdom United Kingdom
pinkas.denis@bull.net pope@secstan.com pope@secstan.com
Internet Draft Electronic Signature Formats
10. 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 others, This document and translations of it may be copied and furnished to
and derivative works that comment on or otherwise explain it or assist in others, and derivative works that comment on or otherwise explain it
its implementation may be prepared, copied, published and distributed, in or assist in its implementation may be prepared, copied, published and
whole or in part, without restriction of any kind, provided that the above distributed, in whole or in part, without restriction of any kind,
copyright notice and this paragraph are included on all such copies and provided that the above copyright notice and this paragraph are
derivative works. However, this document itself may not be modified in any included on all such copies and derivative works. However, this
way, such as by removing the copyright notice or references to the Internet document itself may not be modified in any way, such as by removing
Society or other Internet organizations, except as needed for the purpose of the copyright notice or references to the Internet Society or other
developing Internet standards in which case the procedures for copyrights Internet organizations, except as needed for the purpose of developing
defined in the Internet Standards process must be followed, or as required to Internet standards in which case the procedures for copyrights defined
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.
The limited permissions granted above are perpetual and will not be revoked Internet Draft Electronic Signature Formats
by the Internet Society or its successors or assigns.
The limited permissions granted above are perpetual and will not be
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 WILL NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
11.Temportary Issues
It might be interesting to split this document into two RFCs, one RFC
dealing only with ES formats, the other one only with Signature
Policies. In such a case, the basis of this split will be, sections 6
and annex C will be removed from this document and placed in the another
RFC dealing with Signature policies. The signature policy ASN.1 will be
removed the current ASN.1 modules in annex A and placed in a new ASN.1
module in the other RFC dealing with Signature Policies. Opinions are
requested on this issue.
Internet Draft Electronic Signature Formats Internet Draft Electronic Signature Formats
Note: If there is a request to split this document into two RFCs, one Annex A (normative): ASN.1 Definitions
RFC dealing with ES formats, the other with Signature policies, then the
signature policy ASN.1 will be removed the current ASN.1 modules in
annex A and placed in a new ASN.1 module in the other RFC dealing with
Signature policies.
Annex A (normative):
ASN.1 Definitions
This annex provides a summary of all the ASN.1 syntax definitions for This annex provides a summary of all the ASN.1 syntax definitions for
new syntax defined in this document. new syntax defined in this document.
A.1 Definitions Using X.208 (1988) ASN.1 Syntax A.1 Definitions Using X.208 (1988) ASN.1 Syntax
NOTE: The ASN.1 module defined in clause A.1 has precedence over that NOTE: The ASN.1 module defined in clause A.1 has precedence over that
defined in Annex A-2 in the case of any conflict. defined in Annex A-2 in the case of any conflict.
ETS-ElectronicSignature-88syntax { iso(1) member-body(2) ETS-ElectronicSignatureFormats-88syntax { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-mod(0) 5} us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-mod(0) 5}
DEFINITIONS EXPLICIT TAGS ::= DEFINITIONS EXPLICIT TAGS ::=
BEGIN BEGIN
-- EXPORTS All - -- EXPORTS All -
IMPORTS IMPORTS
-- Crypographic Message Syntax (CMS): RFC 2630 -- Crypographic Message Syntax (CMS): RFC 2630
ContentInfo, ContentType, id-data, id-signedData, SignedData, ContentInfo, ContentType, id-data, id-signedData, SignedData,
EncapsulatedContentInfo, EncapsulatedContentInfo, SignerInfo, id-contentType,
SignerInfo, id-contentType, id-messageDigest, MessageDigest, id-messageDigest, MessageDigest, id-signingTime, SigningTime,
id-signingTime, SigningTime,
id-countersignature, Countersignature id-countersignature, Countersignature
FROM CryptographicMessageSyntax FROM CryptographicMessageSyntax
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) cms(1) } smime(16) modules(0) cms(1) }
-- ESS Defined attributes: RFC 2634 -- ESS Defined attributes: RFC 2634
-- (Enhanced Security Services for S/MIME) -- (Enhanced Security Services for S/MIME)
id-aa-signingCertificate, SigningCertificate, IssuerSerial, id-aa-signingCertificate, SigningCertificate, IssuerSerial,
id-aa-contentReference, ContentReference, id-aa-contentReference, ContentReference,
id-aa-contentIdentifier, ContentIdentifier id-aa-contentIdentifier, ContentIdentifier
FROM ExtendedSecurityServices FROM ExtendedSecurityServices
{ iso(1) member-body(2) us(840) rsadsi(113549) { iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) ess(2) } pkcs(1) pkcs-9(9) smime(16) modules(0) ess(2) }
Internet Draft Electronic Signature Formats
-- Internet X.509 Public Key Infrastructure -- Internet X.509 Public Key Infrastructure
- - Certificate and CRL Profile: RFC 2459 - - Certificate and CRL Profile: RFC 2459
Certificate, AlgorithmIdentifier, CertificateList, Name, Certificate, AlgorithmIdentifier, CertificateList, Name,
GeneralNames, GeneralName, GeneralNames, GeneralName, DirectoryString,Attribute,
DirectoryString,Attribute, AttributeTypeAndValue, AttributeType, AttributeTypeAndValue, AttributeType, AttributeValue,
AttributeValue,
PolicyInformation, BMPString, UTF8String PolicyInformation, BMPString, UTF8String
Internet Draft Electronic Signature Formats
FROM PKIX1Explicit88 FROM PKIX1Explicit88
{iso(1) identified-organization(3) dod(6) internet(1) {iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit- security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit-
88(1)} 88(1)}
-- X.509 '97 Authentication Framework -- X.509 '97 Authentication Framework
AttributeCertificate AttributeCertificate
FROM AuthenticationFramework FROM AuthenticationFramework
{joint-iso-ccitt ds(5) module(1) authenticationFramework(7) 3} {joint-iso-ccitt ds(5) module(1) authenticationFramework(7) 3}
-- The imported AttributeCertificate is defined using the X.680 1997 -- The imported AttributeCertificate is defined using the X.680 1997
-- ASN.1 Syntax, -- ASN.1 Syntax,
-- an equivalent using the 88 ASN.1 syntax may be used. -- an equivalent using the 88 ASN.1 syntax may be used.
-- OCSP 2560 -- OCSP 2560
BasicOCSPResponse, ResponderID BasicOCSPResponse, ResponderID
FROM OCSP {-- OID not assigned -- } FROM OCSP {-- OID not assigned -- }
-- Time Stamp Protocol Internet Draft -- Time Stamp Protocol Internet Draft
FROM TSP {-- OID not assigned -- };
TimeStampToken
FROM PKIXTSP
{iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-tsp(13)}
-- S/MIME Object Identifier arcs used in this document -- S/MIME Object Identifier arcs used in this document
-- ===================================================
-- S/MIME OID arc used in this document -- S/MIME OID arc used in this document
-- id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) -- id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
-- us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 } -- us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 }
-- S/MIME Arcs -- S/MIME Arcs
-- id-mod OBJECT IDENTIFIER ::= { id-smime 0 } -- id-mod OBJECT IDENTIFIER ::= { id-smime 0 }
-- modules -- modules
-- id-ct OBJECT IDENTIFIER ::= { id-smime 1 } -- id-ct OBJECT IDENTIFIER ::= { id-smime 1 }
-- content types -- content types
-- id-aa OBJECT IDENTIFIER ::= { id-smime 2 } -- id-aa OBJECT IDENTIFIER ::= { id-smime 2 }
-- attributes -- attributes
-- id-spq OBJECT IDENTIFIER ::= { id-smime 5 } -- id-spq OBJECT IDENTIFIER ::= { id-smime 5 }
-- signature policy qualifier -- signature policy qualifier
-- id-cti OBJECT IDENTIFIER ::= { id-smime 6 } -- id-cti OBJECT IDENTIFIER ::= { id-smime 6 }
-- commitment type identifier -- commitment type identifier
Internet Draft Electronic Signature Formats Internet Draft Electronic Signature Formats
-- Definitions of Object Identifier arcs used in this document -- Definitions of Object Identifier arcs used in this document
-- ===========================================================
-- The allocation of OIDs to specific objects are given below with the -- The allocation of OIDs to specific objects are given below with the
-- associated ASN.1 syntax definition -- associated ASN.1 syntax definition
-- OID used referencing electronic signature mechanisms based on this -- OID used referencing electronic signature mechanisms based on this
-- standard for use with the IDUP API (see annex D) -- standard for use with the IDUP API (see annex D)
id-etsi-es-IDUP-Mechanism-v1 OBJECT IDENTIFIER ::= id-etsi-es-IDUP-Mechanism-v1 OBJECT IDENTIFIER ::=
{ itu-t(0) identified-organization(4) etsi(0) { itu-t(0) identified-organization(4) etsi(0)
electronic-signature-standard (1733) part1 (1) electronic-signature-standard (1733) part1 (1)
idupMechanism (4)etsiESv1(1) } idupMechanism (4)etsiESv1(1) }
-- CMS Attributes Defined in this document -- CMS Attributes Defined in this document
-- =======================================
-- Mandatory Electronic Signature Attributes -- Mandatory Electronic Signature Attributes
-- OtherSigningCertificate -- OtherSigningCertificate
id-aa-ets-otherSigCert OBJECT IDENTIFIER ::= { iso(1) id-aa-ets-otherSigCert 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) 19 } smime(16) id-aa(2) 19 }
OtherSigningCertificate ::= SEQUENCE { OtherSigningCertificate ::= SEQUENCE {
certs SEQUENCE OF OtherCertID, certs SEQUENCE OF OtherCertID,
policies SEQUENCE OF PolicyInformation OPTIONAL policies SEQUENCE OF PolicyInformation OPTIONAL
-- NOT USED IN THIS DOCUMENT -- NOT USED IN THIS DOCUMENT
} }
OtherCertID ::= SEQUENCE { OtherCertID ::= SEQUENCE {
otherCertHash OtherHash, otherCertHash OtherHash,
issuerSerial IssuerSerial OPTIONAL } issuerSerial IssuerSerial OPTIONAL
}
OtherHash ::= CHOICE { OtherHash ::= CHOICE {
sha1Hash OtherHashValue, -- This contains a SHA-1 hash sha1Hash OtherHashValue, -- This contains a SHA-1 hash
otherHash OtherHashAlgAndValue} otherHash OtherHashAlgAndValue
}
OtherHashValue ::= OCTET STRING OtherHashValue ::= OCTET STRING
OtherHashAlgAndValue ::= SEQUENCE { OtherHashAlgAndValue ::= SEQUENCE {
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 }
Internet Draft Electronic Signature Formats Internet Draft Electronic Signature Formats
SignaturePolicyIdentifier ::= SEQUENCE { SignaturePolicyIdentifier ::= 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 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 ::=
OBJECT IDENTIFIER 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
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 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
CommitmentTypeQualifier CommitmentTypeQualifier OPTIONAL
OPTIONAL} }
CommitmentTypeIdentifier ::= OBJECT IDENTIFIER CommitmentTypeIdentifier ::= OBJECT IDENTIFIER
CommitmentTypeQualifier ::= SEQUENCE { CommitmentTypeQualifier ::= SEQUENCE {
commitmentTypeIdentifier CommitmentTypeIdentifier, commitmentTypeIdentifier CommitmentTypeIdentifier,
qualifier ANY DEFINED BY commitmentTypeIdentifier } qualifier ANY DEFINED BY commitmentTypeIdentifier
}
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}
id-cti-ets-proofOfDelivery OBJECT IDENTIFIER ::= { iso(1) member- id-cti-ets-proofOfDelivery OBJECT IDENTIFIER ::= { iso(1) member-
skipping to change at page 60, line 9 skipping to change at page 48, line 9
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 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-
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 17} body(2) 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
countryName [0] DirectoryString OPTIONAL, countryName [0] DirectoryString OPTIONAL,
-- as used to name a Country in X.500
localityName [1] DirectoryString OPTIONAL, localityName [1] DirectoryString OPTIONAL,
postalAdddress [2] PostalAddress OPTIONAL } -- as used to name a locality in X.500
postalAdddress [2] PostalAddress OPTIONAL
}
PostalAddress ::= SEQUENCE SIZE(1..6) OF DirectoryString PostalAddress ::= SEQUENCE SIZE(1..6) OF DirectoryString
-- Signer Attributes -- Signer Attributes
id-aa-ets-signerAttr OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-aa-ets-signerAttr OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 18} us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 18}
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
-- 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) member- id-aa-signatureTimeStampToken OBJECT IDENTIFIER ::= { iso(1)
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 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 ETSICertID 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-
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 22} body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
id-aa(2) 22}
CompleteRevocationRefs ::= SEQUENCE OF CrlOcspRef CompleteRevocationRefs ::= SEQUENCE OF CrlOcspRef
CrlOcspRef ::= SEQUENCE { CrlOcspRef ::= SEQUENCE {
crlids [0] CRLListID OPTIONAL, crlids [0] CRLListID OPTIONAL,
ocspids [1] OcspListID OPTIONAL, ocspids [1] OcspListID OPTIONAL,
otherRev [2] OtherRevRefs OPTIONAL otherRev [2] OtherRevRefs OPTIONAL
} }
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
}
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 {
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 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
skipping to change at page 62, line 30 skipping to change at page 50, line 30
-- Certificate Revocation Values -- Certificate Revocation Values
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
}
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
skipping to change at page 63, line 15 skipping to change at page 51, line 15
Internet Draft Electronic Signature Formats 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 --
SignaturePolicy ::= SEQUENCE {
signPolicyHashAlg AlgorithmIdentifier,
signPolicyInfo SignPolicyInfo,
signPolicyHash SignPolicyHash OPTIONAL }
SignPolicyHash ::= OCTET STRING
SignPolicyInfo ::= SEQUENCE {
signPolicyIdentifier SignPolicyId,
dateOfIssue GeneralizedTime,
policyIssuerName PolicyIssuerName,
fieldOfApplication FieldOfApplication,
signatureValidationPolicy SignatureValidationPolicy,
signPolExtensions SignPolExtensions
OPTIONAL
}
SignPolicyId ::= OBJECT IDENTIFIER
PolicyIssuerName ::= GeneralNames
FieldOfApplication ::= DirectoryString
SignatureValidationPolicy ::= SEQUENCE {
signingPeriod SigningPeriod,
commonRules CommonRules,
commitmentRules CommitmentRules,
signPolExtensions SignPolExtensions
OPTIONAL
}
SigningPeriod ::= SEQUENCE {
notBefore GeneralizedTime,
notAfter GeneralizedTime OPTIONAL }
Internet Draft Electronic Signature Formats
CommonRules ::= SEQUENCE {
signerAndVeriferRules [0] SignerAndVerifierRules
OPTIONAL,
signingCertTrustCondition [1] SigningCertTrustCondition
OPTIONAL,
timeStampTrustCondition [2] TimestampTrustCondition
OPTIONAL,
attributeTrustCondition [3] AttributeTrustCondition
OPTIONAL,
algorithmConstraintSet [4] AlgorithmConstraintSet
OPTIONAL,
signPolExtensions [5] SignPolExtensions
OPTIONAL
}
CommitmentRules ::= SEQUENCE OF CommitmentRule
CommitmentRule ::= SEQUENCE {
selCommitmentTypes SelectedCommitmentTypes,
signerAndVeriferRules [0] SignerAndVerifierRules
OPTIONAL,
signingCertTrustCondition [1] SigningCertTrustCondition
OPTIONAL,
timeStampTrustCondition [2] TimestampTrustCondition
OPTIONAL,
attributeTrustCondition [3] AttributeTrustCondition
OPTIONAL,
algorithmConstraintSet [4] AlgorithmConstraintSet
OPTIONAL,
signPolExtensions [5] SignPolExtensions
OPTIONAL
}
SelectedCommitmentTypes ::= SEQUENCE OF CHOICE {
empty NULL,
recognizedCommitmentType CommitmentType }
CommitmentType ::= SEQUENCE {
identifier CommitmentTypeIdentifier,
fieldOfApplication [0] FieldOfApplication OPTIONAL,
semantics [1] DirectoryString OPTIONAL }
SignerAndVerifierRules ::= SEQUENCE {
signerRules SignerRules,
verifierRules VerifierRules }
Internet Draft Electronic Signature Formats
SignerRules ::= SEQUENCE {
externalSignedData BOOLEAN OPTIONAL,
-- True if signed data is external to CMS structure
-- False if signed data part of CMS structure
-- not present if either allowed
mandatedSignedAttr CMSAttrs,
-- Mandated CMS signed attributes
mandatedUnsignedAttr CMSAttrs,
-- Mandated CMS unsigned attributed
mandatedCertificateRef [0] CertRefReq DEFAULT signerOnly,
-- Mandated Certificate Reference
mandatedCertificateInfo [1] CertInfoReq DEFAULT none,
-- Mandated Certificate Info
signPolExtensions [2] SignPolExtensions
OPTIONAL}
CMSAttrs ::= SEQUENCE OF OBJECT IDENTIFIER
CertRefReq ::= ENUMERATED {
signerOnly (1),
fullPath (2)
}
CertInfoReq ::= ENUMERATED {
none (0),
signerOnly (1),
fullPath (2)
}
VerifierRules ::= SEQUENCE {
mandatedUnsignedAttr MandatedUnsignedAttr,
signPolExtensions SignPolExtensions OPTIONAL
}
MandatedUnsignedAttr ::= CMSAttrs
Internet Draft Electronic Signature Formats
CertificateTrustTrees ::= SEQUENCE OF CertificateTrustPoint
CertificateTrustPoint ::= SEQUENCE {
trustpoint Certificate,
-- self-signed certificate
pathLenConstraint [0] PathLenConstraint OPTIONAL,
acceptablePolicySet [1] AcceptablePolicySet OPTIONAL,
-- If not present "any policy"
nameConstraints [2] NameConstraints OPTIONAL,
policyConstraints [3] PolicyConstraints OPTIONAL }
PathLenConstraint ::= INTEGER (0..MAX)
AcceptablePolicySet ::= SEQUENCE OF CertPolicyId
CertPolicyId ::= OBJECT IDENTIFIER
NameConstraints ::= SEQUENCE {
permittedSubtrees [0] GeneralSubtrees OPTIONAL,
excludedSubtrees [1] GeneralSubtrees OPTIONAL }
GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree
GeneralSubtree ::= SEQUENCE {
base GeneralName,
minimum [0] BaseDistance DEFAULT 0,
maximum [1] BaseDistance OPTIONAL }
BaseDistance ::= INTEGER (0..MAX)
PolicyConstraints ::= SEQUENCE {
requireExplicitPolicy [0] SkipCerts OPTIONAL,
inhibitPolicyMapping [1] SkipCerts OPTIONAL }
SkipCerts ::= INTEGER (0..MAX)
CertRevReq ::= SEQUENCE {
endCertRevReq RevReq,
caCerts [0] RevReq
}
RevReq ::= SEQUENCE {
enuRevReq EnuRevReq,
exRevReq SignPolExtensions OPTIONAL}
Internet Draft Electronic Signature Formats
EnuRevReq ::= ENUMERATED {
clrCheck (0), --Checks must be made against current CRLs
-- (or authority revocation lists)
ocspCheck (1), -- The revocation status must be checked
-- using the Online Certificate Status Protocol (RFC 2450)
bothCheck (2),
-- Both CRL and OCSP checks must be carried out
eitherCheck (3),
-- At least one of CRL or OCSP checks must be carried out
noCheck (4),
-- no check is mandated
other (5)
-- Other mechanism as defined by signature policy extension
}
SigningCertTrustCondition ::= SEQUENCE {
signerTrustTrees CertificateTrustTrees,
signerRevReq CertRevReq
}
TimestampTrustCondition ::= SEQUENCE {
ttsCertificateTrustTrees [0] CertificateTrustTrees
OPTIONAL,
ttsRevReq [1] CertRevReq
OPTIONAL,
ttsNameConstraints [2] NameConstraints
OPTIONAL,
cautionPeriod [3] DeltaTime
OPTIONAL,
signatureTimestampDelay [4] DeltaTime
OPTIONAL }
DeltaTime ::= SEQUENCE {
deltaSeconds INTEGER,
deltaMinutes INTEGER,
deltaHours INTEGER,
deltaDays INTEGER }
AttributeTrustCondition ::= SEQUENCE {
attributeMandated BOOLEAN,
-- Attribute must be present
howCertAttribute HowCertAttribute,
attrCertificateTrustTrees [0] CertificateTrustTrees OPTIONAL,
attrRevReq [1] CertRevReq OPTIONAL,
attributeConstraints [2] AttributeConstraints OPTIONAL }
HowCertAttribute ::= ENUMERATED {
claimedAttribute (0),
certifiedAttribtes (1),
either (2) }
Internet Draft Electronic Signature Formats
AttributeConstraints ::= SEQUENCE {
attributeTypeConstarints [0] AttributeTypeConstraints
OPTIONAL,
attributeValueConstarints [1] AttributeValueConstraints
OPTIONAL }
AttributeTypeConstraints ::= SEQUENCE OF AttributeType
AttributeValueConstraints ::= SEQUENCE OF AttributeTypeAndValue
AlgorithmConstraintSet ::= SEQUENCE { -- Algorithm constrains on:
signerAlgorithmConstraints [0] AlgorithmConstraints OPTIONAL,
-- signer
eeCertAlgorithmConstraints [1] AlgorithmConstraints OPTIONAL,
-- issuer of end entity certs.
caCertAlgorithmConstraints [2] AlgorithmConstraints OPTIONAL,
-- issuer of CA certificates
aaCertAlgorithmConstraints [3] AlgorithmConstraints OPTIONAL,
-- Attribute Authority
tsaCertAlgorithmConstraints [4] AlgorithmConstraints OPTIONAL
-- TimeStamping Authority
}
AlgorithmConstraints ::= SEQUENCE OF AlgAndLength
AlgAndLength ::= SEQUENCE {
algID OBJECT IDENTIFIER,
minKeyLength INTEGER OPTIONAL,
-- Minimum key length in bits other
SignPolExtensions OPTIONAL
}
SignPolExtensions ::= SEQUENCE OF SignPolExtn
SignPolExtn ::= SEQUENCE {
extnID OBJECT IDENTIFIER,
extnValue OCTET STRING }
END -- ETS-ElectronicSignature-88syntax --
Internet Draft Electronic Signature Formats Internet Draft Electronic Signature Formats
A.2 Definitions Using X.680 1997 ASN.1 Syntax A.2 Definitions Using X.680 1997 ASN.1 Syntax
NOTE: The ASN.1 module defined in clause A.1 has precedence over that NOTE: The ASN.1 module defined in clause A.1 has precedence over that
defined in clause A.2 in the case of any conflict. defined in clause A.2 in the case of any conflict.
ETS-ElectronicSignature-97Syntax { iso(1) member-body(2) ETS-ElectronicSignatureFormats-97Syntax { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-mod(0) 6} us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-mod(0) 6}
DEFINITIONS EXPLICIT TAGS ::= DEFINITIONS EXPLICIT TAGS ::=
BEGIN BEGIN
-- EXPORTS All - -- EXPORTS All -
IMPORTS IMPORTS
-- Cryptographic Message Syntax (CMS): RFC 2630
ContentInfo, ContentType, id-data, id-signedData, SignedData, ContentInfo, ContentType, id-data, id-signedData, SignedData,
EncapsulatedContentInfo, SignerInfo, EncapsulatedContentInfo, SignerInfo, id-contentType,
id-contentType, id-messageDigest, MessageDigest, id-signingTime, id-messageDigest, MessageDigest, id-signingTime,
SigningTime, id-countersignature, Countersignature SigningTime, id-countersignature, Countersignature
FROM CryptographicMessageSyntax FROM CryptographicMessageSyntax
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) cms(1) } smime(16) modules(0) cms(1) }
-- ESS Defined attributes: RFC 2634 (Enhanced Security Services -- ESS Defined attributes: RFC 2634 (Enhanced Security Services
-- for S/MIME) -- for S/MIME)
id-aa-signingCertificate, SigningCertificate, IssuerSerial, id-aa-signingCertificate, SigningCertificate, IssuerSerial,
id-aa-contentReference, ContentReference, id-aa-contentReference, ContentReference,
id-aa-contentIdentifier, ContentIdentifier id-aa-contentIdentifier, ContentIdentifier
FROM ExtendedSecurityServices FROM ExtendedSecurityServices
{ iso(1) member-body(2) us(840) rsadsi(113549) { iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) ess(2) } pkcs(1) pkcs-9(9) smime(16) modules(0) ess(2) }
-- Internet X.509 Public Key Infrastructure -- Internet X.509 Public Key Infrastructure
- - Certificate and CRL Profile:RFC 2459 - - Certificate and CRL Profile:RFC 2459
Certificate, AlgorithmIdentifier, CertificateList, Name, Certificate, AlgorithmIdentifier, CertificateList, Name,
GeneralNames, GeneralName, DirectoryString, Attribute, GeneralNames, GeneralName, DirectoryString, Attribute,
AttributeTypeAndValue, AttributeType, AttributeValue, AttributeTypeAndValue, AttributeType, AttributeValue,
PolicyInformation. PolicyInformation.
FROM PKIX1Explicit93 FROM PKIX1Explicit93
{iso(1) identified-organization(3) dod(6) internet(1) {iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit-88(1)} id-pkix1-explicit-88(1)}
skipping to change at page 69, line 52 skipping to change at page 53, line 5
Certificate, AlgorithmIdentifier, CertificateList, Name, Certificate, AlgorithmIdentifier, CertificateList, Name,
GeneralNames, GeneralName, DirectoryString, Attribute, GeneralNames, GeneralName, DirectoryString, Attribute,
AttributeTypeAndValue, AttributeType, AttributeValue, AttributeTypeAndValue, AttributeType, AttributeValue,
PolicyInformation. PolicyInformation.
FROM PKIX1Explicit93 FROM PKIX1Explicit93
{iso(1) identified-organization(3) dod(6) internet(1) {iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit-88(1)} id-pkix1-explicit-88(1)}
Internet Draft Electronic Signature Formats
-- X.509 '97 Authentication Framework -- X.509 '97 Authentication Framework
AttributeCertificate AttributeCertificate
FROM AuthenticationFramework FROM AuthenticationFramework
{joint-iso-ccitt ds(5) module(1) authenticationFramework(7) 3} {joint-iso-ccitt ds(5) module(1) authenticationFramework(7) 3}
Internet Draft Electronic Signature Formats
-- OCSP 2560 -- OCSP 2560
BasicOCSPResponse, ResponderID BasicOCSPResponse, ResponderID
FROM OCSP FROM OCSP
-- { OID not assigned } -- { OID not assigned }
-- Time Stamp Protocol Internet Draft TimeStampToken -- Time Stamp Protocol Internet Draft TimeStampToken
FROM TSP
FROM PKIXTSP
{iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-tsp(13)}
-- S/MIME Object Identifier arcs used in this document -- S/MIME Object Identifier arcs used in this document
-- ===================================================
-- S/MIME OID arc used in this document -- S/MIME OID arc used in this document
-- id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) -- id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
-- us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 } -- us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 }
-- S/MIME Arcs -- S/MIME Arcs
-- id-mod OBJECT IDENTIFIER ::= { id-smime 0 } -- id-mod OBJECT IDENTIFIER ::= { id-smime 0 }
-- modules -- modules
-- id-ct OBJECT IDENTIFIER ::= { id-smime 1 } -- id-ct OBJECT IDENTIFIER ::= { id-smime 1 }
-- content types -- content types
-- id-aa OBJECT IDENTIFIER ::= { id-smime 2 } -- id-aa OBJECT IDENTIFIER ::= { id-smime 2 }
-- attributes -- attributes
-- id-spq OBJECT IDENTIFIER ::= { id-smime 5 } -- id-spq OBJECT IDENTIFIER ::= { id-smime 5 }
-- signature policy qualifier -- signature policy qualifier
-- id-cti OBJECT IDENTIFIER ::= { id-smime 6 } -- id-cti OBJECT IDENTIFIER ::= { id-smime 6 }
-- commitment type identifier -- commitment type identifier
-- Definitions of Object Identifier arcs used in this document -- Definitions of Object Identifier arcs used in this document
-- ===========================================================
-- The allocation of OIDs to specific objects are given below with the -- The allocation of OIDs to specific objects are given below with the
-- associated ASN.1 syntax definition -- associated ASN.1 syntax definition
-- OID used referencing electronic signature mechanisms based on this -- OID used referencing electronic signature mechanisms based on this
-- standard for use with the IDUP API (see annex D) -- standard for use with the IDUP API (see annex D)
Internet Draft Electronic Signature Formats
id-etsi-es-IDUP-Mechanism-v1 OBJECT IDENTIFIER ::= id-etsi-es-IDUP-Mechanism-v1 OBJECT IDENTIFIER ::=
{ itu-t(0) identified-organization(4) etsi(0) { itu-t(0) identified-organization(4) etsi(0)
electronic-signature-standard (1733) part1 (1) electronic-signature-standard (1733) part1 (1)
idupMechanism (4)etsiESv1(1) } idupMechanism (4)etsiESv1(1) }
Internet Draft Electronic Signature Formats
-- CMS Attributes Defined in this document -- CMS Attributes Defined in this document
-- =======================================
-- Mandatory Electronic Signature Attributes -- Mandatory Electronic Signature Attributes
-- OtherSigningCertificate -- OtherSigningCertificate
id-aa-ets-otherSigCert OBJECT IDENTIFIER ::= { iso(1) id-aa-ets-otherSigCert 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) 19 } smime(16) id-aa(2) 19 }
OtherSigningCertificate ::= SEQUENCE { OtherSigningCertificate ::= SEQUENCE {
certs SEQUENCE OF OtherCertID, certs SEQUENCE OF OtherCertID,
policies SEQUENCE OF PolicyInformation OPTIONAL policies SEQUENCE OF PolicyInformation OPTIONAL
-- NOT USED IN THIS DOCUMENT -- NOT USED IN THIS DOCUMENT
} }
OtherCertID ::= SEQUENCE { OtherCertID ::= SEQUENCE {
otherCertHash OtherHash, otherCertHash OtherHash,
issuerSerial IssuerSerial OPTIONAL } issuerSerial IssuerSerial OPTIONAL
}
OtherHash ::= CHOICE { OtherHash ::= CHOICE {
sha1Hash OtherHashValue, -- This contains a SHA-1 hash sha1Hash OtherHashValue, -- This contains a SHA-1 hash
otherHash OtherHashAlgAndValue} otherHash OtherHashAlgAndValue
}
OtherHashValue ::= OCTET STRING OtherHashValue ::= OCTET STRING
OtherHashAlgAndValue ::= SEQUENCE { OtherHashAlgAndValue ::= SEQUENCE {
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 { SignaturePolicyIdentifier ::= 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
}
Internet Draft Electronic Signature Formats
SigPolicyId ::= OBJECT IDENTIFIER SigPolicyId ::= OBJECT IDENTIFIER
Internet Draft Electronic Signature Formats
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 }
SupportedSigPolicyQualifiers SIG-POLICY-QUALIFIER ::= SupportedSigPolicyQualifiers SIG-POLICY-QUALIFIER ::=
skipping to change at page 72, line 49 skipping to change at page 55, line 47
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 }
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 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}
skipping to change at page 75, line 12 skipping to change at page 58, line 12
SignatureTimeStampToken ::= TimeStampToken SignatureTimeStampToken ::= TimeStampToken
Internet Draft Electronic Signature Formats 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 ETSICertID 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)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 22} us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 22}
CompleteRevocationRefs ::= SEQUENCE OF CrlOcspRef CompleteRevocationRefs ::= SEQUENCE OF CrlOcspRef
CrlOcspRef ::= SEQUENCE { CrlOcspRef ::= SEQUENCE {
crlids [0] CRLListID OPTIONAL, crlids [0] CRLListID OPTIONAL,
skipping to change at page 77, line 23 skipping to change at page 60, line 23
TimestampedCertsCRLs ::= TimeStampToken TimestampedCertsCRLs ::= TimeStampToken
-- Archive Timestamp -- Archive Timestamp
id-aa-ets-archiveTimestamp OBJECT IDENTIFIER ::= { iso(1) id-aa-ets-archiveTimestamp 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) 27} smime(16) id-aa(2) 27}
ArchiveTimeStampToken ::= TimeStampToken ArchiveTimeStampToken ::= TimeStampToken
END -- ETS-ElectronicSignatureFormats-97Syntax
SignaturePolicy ::= SEQUENCE {
signPolicyHashAlg AlgorithmIdentifier,
signPolicyInfo SignPolicyInfo,
signPolicyHash SignPolicyHash OPTIONAL }
SignPolicyHash ::= OCTET STRING
SignPolicyInfo ::= SEQUENCE {
signPolicyIdentifier SignPolicyId,
dateOfIssue GeneralizedTime,
policyIssuerName PolicyIssuerName,
fieldOfApplication FieldOfApplication,
signatureValidationPolicy SignatureValidationPolicy,
signPolExtensions SignPolExtensions
OPTIONAL
}
SignPolicyId ::= OBJECT IDENTIFIER
PolicyIssuerName ::= GeneralNames
FieldOfApplication ::= DirectoryString
SignatureValidationPolicy ::= SEQUENCE {
signingPeriod SigningPeriod,
commonRules CommonRules,
commitmentRules CommitmentRules,
signPolExtensions SignPolExtensions OPTIONAL
}
Internet Draft Electronic Signature Formats
SigningPeriod ::= SEQUENCE {
notBefore GeneralizedTime,
notAfter GeneralizedTime OPTIONAL }
CommonRules ::= SEQUENCE {
signerAndVeriferRules [0] SignerAndVerifierRules
OPTIONAL,
signingCertTrustCondition [1] SigningCertTrustCondition
OPTIONAL,
timeStampTrustCondition [2] TimestampTrustCondition
OPTIONAL,
attributeTrustCondition [3] AttributeTrustCondition
OPTIONAL,
algorithmConstraintSet [4] AlgorithmConstraintSet
OPTIONAL,
signPolExtensions [5] SignPolExtensions
OPTIONAL
}
CommitmentRules ::= SEQUENCE OF CommitmentRule
CommitmentRule ::= SEQUENCE {
selCommitmentTypes SelectedCommitmentTypes,
signerAndVeriferRules [0] SignerAndVerifierRules
OPTIONAL,
signingCertTrustCondition [1] SigningCertTrustCondition
OPTIONAL,
timeStampTrustCondition [2] TimestampTrustCondition
OPTIONAL,
attributeTrustCondition [3] AttributeTrustCondition
OPTIONAL,
algorithmConstraintSet [4] AlgorithmConstraintSet
OPTIONAL,
signPolExtensions [5] SignPolExtensions
OPTIONAL
}
SelectedCommitmentTypes ::= SEQUENCE OF CHOICE {
empty NULL,
recognizedCommitmentType CommitmentType }
CommitmentType ::= SEQUENCE {
identifier CommitmentTypeIdentifier,
fieldOfApplication [0] FieldOfApplication OPTIONAL,
semantics [1] DirectoryString OPTIONAL }
SignerAndVerifierRules ::= SEQUENCE {
signerRules SignerRules,
verifierRules VerifierRules }
Internet Draft Electronic Signature Formats
SignerRules ::= SEQUENCE {
externalSignedData BOOLEAN OPTIONAL,
-- True if signed data is external to CMS structure
-- False if signed data part of CMS structure
-- not present if either allowed
mandatedSignedAttr CMSAttrs,
-- Mandated CMS signed attributes
mandatedUnsignedAttr CMSAttrs,
-- Mandated CMS unsigned attributed
mandatedCertificateRef [0] CertRefReq DEFAULT signerOnly,
-- Mandated Certificate Reference
mandatedCertificateInfo [1] CertInfoReq DEFAULT none,
-- Mandated Certificate Info
signPolExtensions [2] SignPolExtensions OPTIONAL
}
CMSAttrs ::= SEQUENCE OF OBJECT IDENTIFIER
CertRefReq ::= ENUMERATED {
signerOnly (1),
-- Only reference to signer cert mandated
fullPath (2)
-- References for full cert path up to a trust
-- point required
}
CertInfoReq ::= ENUMERATED {
none (0) ,
-- No mandatory requirements
signerOnly (1) ,
-- Only reference to signer cert mandated
fullPath (2)
-- References for full cert path up to a
-- trust point mandated
}
VerifierRules ::= SEQUENCE {
mandatedUnsignedAttr MandatedUnsignedAttr,
signPolExtensions SignPolExtensions OPTIONAL
}
MandatedUnsignedAttr ::= CMSAttrs
-- Mandated CMS unsigned attributed
Internet Draft Electronic Signature Formats
CertificateTrustTrees ::= SEQUENCE OF CertificateTrustPoint
CertificateTrustPoint ::= SEQUENCE {
trustpoint Certificate,
-- self-signed certificate
pathLenConstraint [0] PathLenConstraint OPTIONAL,
acceptablePolicySet [1] AcceptablePolicySet OPTIONAL,
-- If not present "any policy"
nameConstraints [2] NameConstraints OPTIONAL,
policyConstraints [3] PolicyConstraints OPTIONAL }
PathLenConstraint ::= INTEGER (0..MAX)
AcceptablePolicySet ::= SEQUENCE OF CertPolicyId
CertPolicyId ::= OBJECT IDENTIFIER
NameConstraints ::= SEQUENCE {
permittedSubtrees [0] GeneralSubtrees OPTIONAL,
excludedSubtrees [1] GeneralSubtrees OPTIONAL }
GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree
GeneralSubtree ::= SEQUENCE {
base GeneralName,
minimum [0] BaseDistance DEFAULT 0,
maximum [1] BaseDistance OPTIONAL }
BaseDistance ::= INTEGER (0..MAX)
PolicyConstraints ::= SEQUENCE {
requireExplicitPolicy [0] SkipCerts OPTIONAL,
inhibitPolicyMapping [1] SkipCerts OPTIONAL }
SkipCerts ::= INTEGER (0..MAX)
CertRevReq ::= SEQUENCE {
endCertRevReq RevReq,
caCerts [0] RevReq
}
RevReq ::= SEQUENCE {
enuRevReq EnuRevReq,
exRevReq SignPolExtensions OPTIONAL}
Internet Draft Electronic Signature Formats
EnuRevReq ::= ENUMERATED {
clrCheck (0),
-- Checks must be made against current CRLs
-- (or authority revocation lists)
ocspCheck (1),
-- The revocation status must be checked using
-- the Online Certificate Status Protocol (RFC 2450)
bothCheck (2),
-- Both CRL and OCSP checks must be carried out
eitherCheck (3),
-- At least one of CRL or OCSP checks must be carried out
noCheck (4),
-- no check is mandated
other (5)
-- Other mechanism as defined by signature poilicy
-- extension
}
SigningCertTrustCondition ::= SEQUENCE {
signerTrustTrees CertificateTrustTrees,
signerRevReq CertRevReq
}
TimestampTrustCondition ::= SEQUENCE {
ttsCertificateTrustTrees [0] CertificateTrustTrees
OPTIONAL,
ttsRevReq [1] CertRevReq
OPTIONAL,
ttsNameConstraints [2] NameConstraints
OPTIONAL,
cautionPeriod [3] DeltaTime
OPTIONAL,
signatureTimestampDelay [4] DeltaTime
OPTIONAL }
DeltaTime ::= SEQUENCE {
deltaSeconds INTEGER,
deltaMinutes INTEGER,
deltaHours INTEGER,
deltaDays INTEGER }
AttributeTrustCondition ::= SEQUENCE {
attributeMandated BOOLEAN,
-- Attribute must be present
howCertAttribute HowCertAttribute,
attrCertificateTrustTrees [0] CertificateTrustTrees OPTIONAL,
attrRevReq [1] CertRevReq OPTIONAL,
attributeConstraints [2] AttributeConstraints OPTIONAL }
Internet Draft Electronic Signature Formats
HowCertAttribute ::= ENUMERATED {
claimedAttribute (0),
certifiedAttribtes (1),
either (2) }
AttributeConstraints ::= SEQUENCE {
attributeTypeConstarints [0] AttributeTypeConstraints
OPTIONAL,
attributeValueConstarints [1] AttributeValueConstraints
OPTIONAL }
AttributeTypeConstraints ::= SEQUENCE OF AttributeType
AttributeValueConstraints ::= SEQUENCE OF AttributeTypeAndValue
AlgorithmConstraintSet ::= SEQUENCE {
-- Algorithm constrains on:
signerAlgorithmConstraints [0] AlgorithmConstraints OPTIONAL,
-- signer
eeCertAlgorithmConstraints [1] AlgorithmConstraints OPTIONAL,
-- issuer of end entity certs.
caCertAlgorithmConstraints [2] AlgorithmConstraints OPTIONAL,
-- issuer of CA certificates
aaCertAlgorithmConstraints [3] AlgorithmConstraints OPTIONAL,
-- Attribute Authority
tsaCertAlgorithmConstraints [4] AlgorithmConstraints OPTIONAL
-- TimeStamping Authority
}
AlgorithmConstraints ::= SEQUENCE OF AlgAndLength
AlgAndLength ::= SEQUENCE {
algID OBJECT IDENTIFIER,
minKeyLength INTEGER OPTIONAL,
-- Minimum key length in bits
other SignPolExtensions OPTIONAL
}
SignPolExtensions ::= SEQUENCE OF SignPolExtn
SignPolExtn ::= SEQUENCE {
extnID OBJECT IDENTIFIER,
extnValue OCTET STRING }
END -- ETS-ElectronicSignature-97Syntax
Internet Draft Electronic Signature Formats Internet Draft Electronic Signature Formats
Annex B (informative): Annex B (informative): General Description
General Description
This annex captures the concepts that apply to this document and the This annex captures the concepts that apply to this document and the
rational for the elements of the specification defined using ASN.1 in rational for the elements of the specification defined using ASN.1 in
the main text of this document. the main text of this document.
The specification below includes a description why the component is The specification below includes a description why the component is
needed, with a brief description of the vulnerabilities and threats and needed, with a brief description of the vulnerabilities and threats
the manner by which they are countered. and the manner by which they are countered.
B.1 The Signature Policy B.1 The Signature Policy
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 determined of an electronic signature, under which the signature can be
to be valid. A given legal/contractual context may recognize a determined to be valid. A given legal/contractual context may
particular signature policy as meeting its requirements. A signature recognize a particular signature policy as meeting its requirements.
policy may be issued, for example, by a party relying on the electronic A signature policy may be issued, for example, by a party relying on
signatures and selected by the signer for use with that relying party. the electronic signatures and selected by the signer for use with that
Alternatively, a signature policy may be established through an relying party. Alternatively, a signature policy may be established
electronic trading association for use amongst its members. Both the through an electronic trading association for use amongst its members.
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 A signature policy has a globally unique reference, which is bound to
an electronic signature by the signer as part of the signature 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.
The signature policy thus includes the following: The signature policy thus includes the following:
* Information about the signature policy that can be displayed
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 The Signature Validation Policy may be structured so that it can be
computer processable. The current document includes, as an option, a computer processable. Any format of the signature validation policy
formal structure for the signature validation policy based on the used is allowed by this document. However, for a given signature policy
of Abstract Syntax Notation 1 (ASN.1). Other formats of the signature there must be one definitive form that has a unique binary encoded
validation policy are allowed by this document. However, for a given value.
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
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 rules (CA, Attribute Authorities, Time Stamping Authorities) as well as
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
to select the right display or application. It can be composed of to select the right display or application. It can be composed of
formatted text (e.g. EDIFACT), free text or of fields from an formatted text (e.g. EDIFACT), free text or of fields from an
electronic form (e-form). For example, the Adobe(tm) format "pdf" may electronic form (e-form). For example, the Adobe(tm) format "pdf" may
be used or the eXtensible Mark up Language (XML). be used or the eXtensible Mark up Language (XML).
B.3 Components of an Electronic Signature B.3 Components of an Electronic Signature
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 been The definition of electronic signature includes: "a commitment has
explicitly endorsed under a "Signature policy", at a given time, by a been explicitly endorsed under a "Signature policy", at a given time,
signer under an identifier, e.g. a name or a pseudonym, and optionally by a signer under an identifier, e.g. a name or a pseudonym, and
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 the technical components and technical aspects used in
creating the signature must be referenced, this is provided by a creating the signature must be referenced, this is provided by a
reference to the "Signature Validation Policy". The "Signature reference to the "Signature Validation Policy". The "Signature
Validation Policy" defines: Validation Policy" defines:
* the components of an electronic signature to be provided by the * the components of an electronic signature to be provided by the
signer; signer;
skipping to change at page 84, line 52 skipping to change at page 62, line 53
verifier and later by an arbitrator, auditor or other verifier and later by an arbitrator, auditor or other
independent parties. independent parties.
By signing over the signature policy identifier, the algorithm By signing over the signature policy identifier, the algorithm
identifier and the hash of the signature policy, 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 commitments implied by the
signature policy, any indication of commitment type included in the signature policy, any indication of commitment type included in the
electronic signature, and the user data that is signed. electronic signature, and the user data that is signed.
The hash algorithm identifier and value is included to ensure that both The hash algorithm identifier and value is included to ensure that
the signer and verifier use exactly the same signature policy. This both the signer and verifier use exactly the same signature policy.
unambiguously binds the signer and verifier to same definitive form of This unambiguously binds the signer and verifier to same definitive
the signature policy has a unique binary encoding. form of the signature policy has a unique binary encoding.
Internet Draft Electronic Signature Formats Internet Draft Electronic Signature Formats
In order to identify unambiguously the "Signature Validation Policy" to In order to identify unambiguously the "Signature Validation Policy"
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 been The definition of electronic signature includes: "a commitment has
explicitly endorsed under a signature policy, at a given time, by a been explicitly endorsed under a signature policy, at a given time,
signer under an identifier, e.g. a name or a pseudonym, and optionally a by a signer under an identifier, e.g. a name or a pseudonym, and
role". optionally a role".
The commitment type can be indicated in the electronic signature The commitment type can be indicated in the electronic signature
either: either:
* explicitly using a "commitment type indication" in the * explicitly using a "commitment type indication" in the
electronic signature; electronic signature;
* implicitly or explicitly from the semantics of the signed data. * implicitly or explicitly from the semantics of the signed data.
If the indicated commitment type is explicit using a "commitment type If the indicated commitment type is explicit using a "commitment type
skipping to change at page 85, line 47 skipping to change at page 63, line 47
treated as invalid. treated as invalid.
How commitment is indicated using the semantics of the data being How commitment is indicated using the semantics of the data being
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 the signed can have an explicit commitment within the context of
application (e.g. EDIFACT purchase order). the application (e.g. EDIFACT purchase order).
* 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, (meaning) which is only interpretable by humans, (i.e. free
(i.e. free text). text).
Internet Draft Electronic Signature Formats Internet Draft Electronic Signature Formats
B.3.4 Certificate Identifier from the Signer B.3.3 Certificate Identifier from the Signer
The definition of the ETSI electronic signature includes: "a commitment The definition of the ETSI electronic signature includes: "a
has been explicitly endorsed under a signature policy, at a given time, commitment has been explicitly endorsed under a signature policy,
by a signer under an identifier, e.g. a name or a pseudonym, and at a given time, by a signer under an identifier, e.g. a name or a
optionally a role." pseudonym, and optionally a role."
In many real life environments users will be able to get from different In many real life environments users will be able to get from
CAs or even from the same CA, different certificates containing the different CAs or even from the same CA, different certificates
same public key for different names. The prime advantage is that a user containing the same public key for different names. The prime
can use the same private key for different purposes. Multiple use of advantage is that a user can use the same private key for different
the private key is an advantage when a smart card is used to protect purposes. Multiple use of the private key is an advantage when a smart
the private key, since the storage of a smart card is always limited. card is used to protect the private key, since the storage of a smart
When several CAs are involved, each different certificate may contain a card is always limited. When several CAs are involved, each different
different identity, e.g. as a national or as an employee from a certificate may contain a different identity, e.g. as a national or as
company. Thus when a private key is used for various purposes, the an employee from a company. Thus when a private key is used for
certificate is needed to clarify the context in which the private key various purposes, the certificate is needed to clarify the context in
was used when generating the signature. Where there is the possibility which the private key was used when generating the signature. Where
of multiple use of private keys it is necessary for the there is the possibility of multiple use of private keys it is
signer to indicate to the verifier the precise certificate to be used. necessary for the signer to indicate to the verifier the precise
certificate to be used.
Many current schemes simply add the certificate after the signed data Many current schemes simply add the certificate after the signed data
and thus are subject to various substitution attacks. An example of a and thus are subject to various substitution attacks. An example of a
substitution attack is a "bad" CA that would issue a certificate to substitution attack is a "bad" CA that would issue a certificate to
someone with the public key of someone else. If the certificate from someone with the public key of someone else. If the certificate from
the signer was simply appended to the signature and thus not protected the signer was simply appended to the signature and thus not protected
by the signature, any one could substitute one certificate by another by the signature, any one could substitute one certificate by another
and the message would appear to be signed by some one else. and the message would appear to be signed by some one else.
In order to counter this kind of attack, the identifier of the signer In order to counter this kind of attack, the identifier of the signer
has to be protected by the digital signature from the signer. has to be protected by the digital signature from the signer.
Although it does not provide the same advantages as the previous Although it does not provide the same advantages as the previous
technique, another technique to counter that threat has been technique, another technique to counter that threat has been
identified. It requires all CAs to perform a Proof Of Possession of the identified. It requires all CAs to perform a Proof Of Possession of
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 the verification of the signature an identifier of the certificate from
signer must be part of the signed data. the signer must be part of the signed data.
B.3.5 Role Attributes B.3.4 Role Attributes
The definition of electronic signature includes: "a commitment has been The definition of electronic signature includes: "a commitment has
explicitly endorsed under a non repudiation security policy, at a given been explicitly endorsed under a non repudiation security policy,
time, by a signer under an identifier, e.g. a name or a pseudonym, and at a given time, by a signer under an identifier, e.g. a name or a
optionally a role. " pseudonym, and optionally a role. "
Internet Draft Electronic Signature Formats 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 is, e.g. a Sales Director. In many cases whom the sales Director really
is not that important but being sure that the signer is empowered by is, is not that important but being sure that the signer is empowered
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
attributes field; attributes field;
* by placing a attribute certificate containing a certified * by placing a attribute certificate containing a certified
role name in the CMS signed attributes field. role name in the CMS signed attributes field.
NOTE: Another possible approach would have been to use additional NOTE: Another possible approach would have been to use additional
attributes containing the roles name(s) in the signer's certificate. attributes containing the roles name(s) in the signer's certificate.
However, it was decided not to follow this approach as it breaks the However, it was decided not to follow this approach as it breaks the
basic philosophy of the certificate being issued for one primary basic philosophy of the certificate being issued for one primary
purpose. Also, by using separate certificates for management of the purpose. Also, by using separate certificates for management of the
signer's identity certificate and management of additional roles can signer's identity certificate and management of additional roles can
simplify the management, as new identity keys need not be issued if a simplify the management, as new identity keys need not be issued if a
skipping to change at page 87, line 32 skipping to change at page 65, line 33
attributes containing the roles name(s) in the signer's certificate. attributes containing the roles name(s) in the signer's certificate.
However, it was decided not to follow this approach as it breaks the However, it was decided not to follow this approach as it breaks the
basic philosophy of the certificate being issued for one primary basic philosophy of the certificate being issued for one primary
purpose. Also, by using separate certificates for management of the purpose. Also, by using separate certificates for management of the
signer's identity certificate and management of additional roles can signer's identity certificate and management of additional roles can
simplify the management, as new identity keys need not be issued if a simplify the management, as new identity keys need not be issued if a
use of role is to be changed. use of role is to be changed.
B.3.5.1 Claimed Role B.3.5.1 Claimed Role
The signer may be trusted to state his own role without any certificate The signer may be trusted to state his own role without any
to corroborate this claim. In which case the claimed role can be added certificate to corroborate this claim. In which case the claimed role
to the signature as a signed attribute. can be added to the signature as a signed attribute.
B.3.5.2 Certified Role B.3.5.2 Certified Role
Unlike public key certificates that bind an identifier to a public key, Unlike public key certificates that bind an identifier to a public
Attribute Certificates bind the identifier of a certificate to some key, Attribute Certificates bind the identifier of a certificate to
attributes, like a role. An Attribute Certificate is NOT issued by a CA some attributes, like a role. An Attribute Certificate is NOT issued
but by an Attribute Authority (AA). The Attribute Authority will be by a CA but by an Attribute Authority (AA). The Attribute Authority
most of the time under the control of an organization or a company that will be most of the time under the control of an organization or a
is best placed to know which attributes are relevant for which company that is best placed to know which attributes are relevant for
individual. The Attribute Authority may use or point to public key which individual.
certificates issued by any CA, provided that the appropriate trust may
be placed in that CA. Attribute Certificates may have various periods The Attribute Authority may use or point to public key certificates
of validity. That period may be quite short, e.g. one day. While this issued by any CA, provided that the appropriate trust may be placed
in that CA. Attribute Certificates may have various periods of
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, the Attribute Certificate will have to be included in the signed
data in order to be protected by the digital signature from the signer. data in order to be protected by the digital signature from the signer.
Internet Draft Electronic Signature Formats 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.6 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
reason an optional location indicator must be able to be included. reason an optional location indicator must be able to be included.
In order to provide indication of the location of the signer at the In order to provide indication of the location of the signer at the
time he or she applied his signature a location attribute may be time he or she applied his signature a location attribute may be
included in the signature. included in the signature.
B.3.7 Signing Time B.3.6 Signing Time
The definition of electronic signature includes: "a commitment has been The definition of electronic signature includes: "a commitment has
explicitly endorsed under a signature policy, at a given time, by a been explicitly endorsed under a signature policy, at a given time,
signer under an identifier, e.g. a name or a pseudonym, and optionally a by a signer under an identifier, e.g. a name or a pseudonym, and
optionally a
role. " role. "
There are several ways to address this problem. The solution adopted in There are several ways to address this problem. The solution adopted
this document is to sign over a time which the signer claims is the in this document is to sign over a time which the signer claims is the
signing time (i.e. claimed signing time) and to require a trusted time signing time (i.e. claimed signing time) and to require a trusted
stamp to be obtained when building a ES with Timestamp. When a verifier time stamp to be obtained when building a ES with Timestamp. When a
accepts a signature, the two times must be within acceptable limits. verifier accepts a signature, the two times must be within acceptable
limits.
The solution that is adopted in this document offers the major The solution that is adopted in this document offers the major
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 electronic the data signed by the signer (i.e. part of the basic
signature); electronic signature);
* 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 a indicated by the signer and the time of time stamping as indicated by
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.
"Close enough" means a few minutes, hours or even days according to the
"Signature Validation Policy".
Internet Draft Electronic Signature Formats Internet Draft Electronic Signature Formats
"Close enough" means a few minutes, hours or even days according to
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
4.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.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:
skipping to change at page 90, line 7 skipping to change at page 68, line 7
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 Internet Draft Electronic Signature Formats
It may happen that the certificate serial number appears in the CRL but It may happen that the certificate serial number appears in the CRL
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 know electronic signature is not yet valid, since it is not possible to
whether the certificate will or will not be revoked at the end of the know whether the certificate will or will not be revoked at the end
suspension period. If a decision has to be taken immediately then the of the suspension period. If a decision has to be taken immediately
signature has to be considered as invalid. If a decision can wait until then the signature has to be considered as invalid. If a decision can
the end of the suspension period, then two cases are possible: wait until the end of the suspension period, then two cases are
possible:
* the certificate serial number has disappeared from the list * the certificate serial number has disappeared from the list
and thus the certificate can be considered as valid and that CRL and thus the certificate can be considered as valid and that
must be captured and archived either by the verifier or CRL must be captured and archived either by the verifier or
elsewhere and be kept accessible for the purpose of arbitration. elsewhere and be kept accessible for the purpose of arbitration.
* 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.
B.4.3 OCSP Information B.4.3 OCSP Information
When using OCSP to get revocation information , a verifier will have to When using OCSP to get revocation information , a verifier will have
make sure that he or she gets at the time of the first verification an to make sure that he or she gets at the time of the first verification
OCSP response that contains the status "valid". This should be done as an OCSP response that contains the status "valid". This should be done
soon as possible after the generation of the signature. The signer, the as soon as possible after the generation of the signature. The signer,
verifier or any other third party may fetch this OCSP response. Since the verifier or any other third party may fetch this OCSP response.
OSCP responses are transient and thus are not archived by any TSP Since OSCP responses are transient and thus are not archived by any
including CA, it is the responsibility of every verifier to make sure TSP including CA, it is the responsibility of every verifier to make
that it is stored in a safe place. The simplest way is to store them sure that it is stored in a safe place. The simplest way is to store
associated with the electronic signature. An alternative would be to them associated with the electronic signature. An alternative would be
store them in some storage so that they can then be easily retrieved. to store them in some storage so that they can then be easily
retrieved.
In the same way as for the case of the CRL, it may happen that the In the same way as for the case of the CRL, it may happen that the
certificate is declared as invalid but with the secondary status certificate is declared as invalid but with the secondary status
"suspended". "suspended".
In such a case, the electronic signature is not yet valid, since it is In such a case, the electronic signature is not yet valid, since it is
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 as taken immediately then the electronic signature has to be considered
invalid. If a decision can wait until the end of the suspension period, as invalid. If a decision can wait until the end of the suspension
then two cases are possible: period, then two cases are possible:
* An OCSP response with a valid status is obtained at a later date
and thus the certificate can be considered as valid and that
OCSP response must be captured.
* An OCSP response with an invalid status is obtained with a * An OCSP response with a valid status is obtained at a later
secondary status indicating that the certificate is definitively date and thus the certificate can be considered as valid and
revoked and thus the electronic signature must be considered as that OCSP response must be captured.
invalid and discarded.
Internet Draft Electronic Signature Formats Internet Draft Electronic Signature Formats
* An OCSP response with an invalid status is obtained with a
secondary status indicating that the certificate is
definitively revoked and thus the electronic signature must be
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
A verifier will have to prove that the certification path was valid, at A verifier will have to prove that the certification path was valid,
the time of the signature, up to a trust point according to the naming at the time of the signature, up to a trust point according to the
constraints and the certificate policy constraints from the "Signature naming constraints and the certificate policy constraints from the
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 one signer and ending up with those of the self-signed certificate from
trusted root of the "Signature Validation Policy". In addition, it will one trusted root of the "Signature Validation Policy". In addition, it
be necessary to capture the Authority Revocation Lists (ARLs) to prove will be necessary to capture the Authority Revocation Lists (ARLs) to
than none of the CAs from the chain was revoked at the time of the prove than none of the CAs from the chain was revoked at the time of
signature. the signature.
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 signature, An important property for long standing signatures is that a
having been found once to be valid, must continue to be so months or signature, having been found once to be valid, must continue to be so
years later. months or years later.
A signer, verifier or both may be required to provide on request, proof A signer, verifier or both may be required to provide on request,
that a digital signature was created or verified during the validity proof that a digital signature was created or verified during the
period of the all the certificates that make up the certificate path. validity period of the all the certificates that make up the
In this case, the signer, verifier or both will also be required to certificate path. In this case, the signer, verifier or both will
provide proof that all the user and CA certificates used were not also be required to provide proof that all the user and CA
revoked when the signature was created or verified. certificates used were not revoked when the signature was created
or verified.
It would be quite unacceptable, to consider a signature as invalid even It would be quite unacceptable, to consider a signature as invalid
if the keys or certificates were later compromised. Thus there is a even if the keys or certificates were later compromised. Thus there
need to be able to demonstrate that the signature keys was valid around is a need to be able to demonstrate that the signature keys was valid
the time that the signature was created to provide long term evidence around the time that the signature was created to provide long term
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.
Internet Draft Electronic Signature Formats
If a recipient wants to hold a valid electronic signature he will have If a recipient wants to hold a valid electronic signature he will have
to ensure that he has obtained a valid time stamp for it, before that to ensure that he has obtained a valid time stamp for it, before that
key (and any key involved in the validation) is revoked. The sooner the key (and any key involved in the validation) is revoked. The sooner
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" and It is important to note that signatures may be generated "off-line"
time-stamped at a later time by anyone, for example by the signer or and time-stamped at a later time by anyone, for example by the signer
any recipient interested in the value of the signature. The time stamp or any recipient interested in the value of the signature. The time
can thus be provided by the signer together with the signed document, stamp can thus be provided by the signer together with the signed
or obtained by the recipient following receipt of the signed document. document, or obtained by the recipient following receipt of the signed
document.
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.
Should both the signer and verifier be required to timestamp the Should both the signer and verifier be required to timestamp the
signature value to meet the requirements of the signature policy, the signature value to meet the requirements of the signature policy, the
signature policy MAY specify a permitted time delay between the two signature policy MAY specify a permitted time delay between the two
time stamps. time stamps.
B.4.6 Timestamping for Long Life of Signature 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 to certificate chain ever being compromised. A verifier may be required
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 is be compromised. Since the information contained in the OCSP response
user specific and time specific, an individual time stamp is needed for is user specific and time specific, an individual time stamp is needed
every signature received. Instead of placing the time stamp only over for every signature received. Instead of placing the time stamp only
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
references are included in the ES with Complete validation data they references are included in the ES with Complete validation data they
are also protected. For the same cryptographic price, this provides an are also protected. For the same cryptographic price, this provides an
integrity mechanism over the ES with Complete validation data. Any integrity mechanism over the ES with Complete validation data. Any
modification can be immediately detected. It should be noticed that modification can be immediately detected. It should be noticed that
other means of protecting/detecting the integrity of the ES with other means of protecting/detecting the integrity of the ES with
Complete Validation Data exist and could be used. Complete Validation Data exist and could be used.
Although the technique requires a time stamp for every signature, it is Although the technique requires a time stamp for every signature, it
well suited for individual users wishing to have an integrity protected is well suited for individual users wishing to have an integrity
copy of all the validated signatures they have received. protected copy of all the validated signatures they have received.
By timestamping the complete electronic signature, including the By timestamping the complete electronic signature, including the
digital signature as well as the references to the certificates and digital signature as well as the references to the certificates and
revocation status information used to support validation of that revocation status information used to support validation of that
signature, the timestamp ensures that there is no ambiguity in the signature, the timestamp ensures that there is no ambiguity in the
means of validating that signature. means of validating that signature.
This technique is referred to as ES with eXtended validation data (ES- This technique is referred to as ES with eXtended validation data
X), type 1 Timestamped in this document. (ES-X), type 1 Timestamped in this document.
NOTE: Trust is achieved in the references by including a hash of the NOTE: Trust is achieved in the references by including a hash of the
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 electronic being referenced, the additional data may be attached to the
signature, in which case the electronic signature becomes a ES-X Long electronic signature, in which case the electronic signature becomes
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 was CA certificates that could be claimed to existing before the CA key
compromised. Any bogus timestamped CA certificates will show that the was compromised. Any bogus timestamped CA certificates will show that
certificate was created after the legitimate CA key was compromised. In the certificate was created after the legitimate CA key was
the same way, timestamping CA CRLs, will stop any attacker from issuing compromised. In the same way, timestamping CA CRLs, will stop any
bogus CA CRLs which could be claimed to existing before the CA key was attacker from issuing bogus CA CRLs which could be claimed to existing
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
reduces the amount of data the verifier has to timestamp, for example reduces the amount of data the verifier has to timestamp, for example
it could reduce to just one time stamp per day (i.e. in the case were it could reduce to just one time stamp per day (i.e. in the case were
all the signers use the same CA and the CRL applies for the whole day). all the signers use the same CA and the CRL applies for the whole day).
The information that needs to be time stamped is not the actual The information that needs to be time stamped is not the actual
certificates and CRLs but the unambiguous references to those certificates and CRLs but the unambiguous references to those
certificates and CRLs. certificates and CRLs.
skipping to change at page 94, line 40 skipping to change at page 72, line 48
Thus a ES-C with a timestamp signature value at time T1, can be proved Thus a ES-C with a timestamp signature value at time T1, can be proved
valid if all the CA and CRL references are timestamped at time T1+. valid if all the CA and CRL references are timestamped at time T1+.
B.4.7 Timestamping for Long Life of Signature B.4.7 Timestamping for Long Life of Signature
Advances in computing increase the probability of being able to break Advances in computing increase the probability of being able to break
algorithms and compromise keys. There is therefore a requirement to be algorithms and compromise keys. There is therefore a requirement to be
able to protect electronic signatures against this probability. able to protect electronic signatures against this probability.
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 time algorithms used to create an electronic signature (e.g. due to the
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 used necessary if the hash function and the crypto algorithms that were
to create the signature are no longer secure. Also, if it cannot be used to create the signature are no longer secure. Also, if it cannot
assumed that the hash function used by the Time Stamping Authority is be assumed that the hash function used by the Time Stamping Authority
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 95, line 31 skipping to change at page 73, line 40
The process will need to be performed and iterated before the The process will need to be performed and iterated before the
cryptographic algorithms used for generating the previous time stamp cryptographic algorithms used for generating the previous time stamp
are no longer secure. Archive validation data may thus bear multiple are no longer secure. Archive validation data may thus bear multiple
embedded time stamps. embedded time stamps.
B.4.8 Reference to Additional Data B.4.8 Reference to Additional Data
Using type 1 or 2 of Timestamped extended validation data verifiers Using type 1 or 2 of Timestamped extended validation data verifiers
still needs to keep track of all the components that were used to still needs to keep track of all the components that were used to
validate the signature, in order to be able to retrieve them again validate the signature, in order to be able to retrieve them again
later on. These components may be archived by an external source like a later on. These components may be archived by an external source like
trusted service provider, in which case referenced information that is a trusted service provider, in which case referenced information that
provided as part of the ES with Complete validation data (ES-C) is is provided as part of the ES with Complete validation data (ES-C) is
adequate. The actual certificates and CRL information reference in the adequate. The actual certificates and CRL information reference in the
ES-C can be gathered when needed for arbitration. ES-C can be gathered when needed for arbitration.
B.4.9 Timestamping for Mutual Recognition B.4.9 Timestamping for Mutual Recognition
In some business scenarios both the signer and the verifier need to In some business scenarios both the signer and the verifier need to
timestamp their own copy of the signature value. Ideally the two timestamp their own copy of the signature value. Ideally the two
timestamps should be as close as possible to each other. timestamps should be as close as possible to each other.
Example: A contract is signed by two parties A and B representing their Example: A contract is signed by two parties A and B representing
respective organizations, to timestamp the signer and verifier data two their respective organizations, to timestamp the signer and verifier
approaches are possible: data two approaches are possible:
* under the terms of the contract pre-defined common "trusted" * under the terms of the contract pre-defined common "trusted"
TSA may be used; TSA may be used;
Internet Draft Electronic Signature Formats
* if both organizations run their own timestamping services, A * if both organizations run their own timestamping services, A
and B can have the transaction timestamped by these two and B can have the transaction timestamped by these two