draft-ietf-smime-cades-04.txt   draft-ietf-smime-cades-05.txt 
S/MIME Working Group D.Pinkas (Bull SAS) S/MIME Working Group D.Pinkas (Bull SAS)
INTERNET-DRAFT N.Pope (Thales eSecurity) INTERNET-DRAFT N.Pope (Thales eSecurity)
Expires March 2008 J.Ross (Security and Standards) Expires March 2008 J.Ross (Security and Standards)
Obsoletes: RFC 3126 September 2007 Obsoletes: RFC 3126 September 2007
Target Category: Informational Target Category: Informational
CMS Advanced Electronic Signatures (CAdES) CMS Advanced Electronic Signatures (CAdES)
<draft-ietf-smime-cades-04.txt> <draft-ietf-smime-cades-05.txt>
Status of this memo Status of this memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 2, line 5 skipping to change at page 2, line 5
The format can be considered as an extension to RFC 3852 [4] and The format can be considered as an extension to RFC 3852 [4] and
RFC 2634 [5], where, when appropriate additional signed and RFC 2634 [5], where, when appropriate additional signed and
unsigned attributes have been defined. unsigned attributes have been defined.
The contents of this Informational RFC amounts to a The contents of this Informational RFC amounts to a
transposition of the ETSI TS 101 733 V.1.7.3 (CMS Advanced transposition of the ETSI TS 101 733 V.1.7.3 (CMS Advanced
Electronic Signatures - CAdES) [TS101733] and is technically Electronic Signatures - CAdES) [TS101733] and is technically
equivalent to it. equivalent to it.
Internet-draft CMS Advanced Electronic Signatures September 2007
Table of Contents Table of Contents
1. Introduction 6 1. Introduction 6
2. Scope 6 2. Scope 6
3. Definitions and abbreviations 8 3. Definitions and abbreviations 8
3.1 Definitions 8 3.1 Definitions 8
3.2 Abbreviations 11 3.2 Abbreviations 11
skipping to change at page 3, line 5 skipping to change at page 3, line 5
Electronic Signatures 34 Electronic Signatures 34
5.8.1 Signature policy identifier 34 5.8.1 Signature policy identifier 34
5.9 CMS imported optional attributes 36 5.9 CMS imported optional attributes 36
5.9.1 Signing time 36 5.9.1 Signing time 36
5.9.2 Countersignature 36 5.9.2 Countersignature 36
5.10 ESS imported optional attributes 37 5.10 ESS imported optional attributes 37
5.10.1 Content reference attribute 37 5.10.1 Content reference attribute 37
5.10.2 Content identifier attribute 37 5.10.2 Content identifier attribute 37
5.10.3 Content hints attribute 37 5.10.3 Content hints attribute 37
Internet-draft CMS Advanced Electronic Signatures September 2007
5.11 Additional optional attributes defined in the present document 38 5.11 Additional optional attributes defined in the present document 38
5.11.1 Commitment type indication attribute 38 5.11.1 Commitment type indication attribute 38
5.11.2 Signer location attribute 40 5.11.2 Signer location attribute 40
5.11.3 Signer attributes attribute 40 5.11.3 Signer attributes attribute 40
5.11.4 Content time-stamp 41 5.11.4 Content time-stamp 41
5.12 Support for multiple signatures 41 5.12 Support for multiple signatures 41
5.12.1 Independent signatures 41 5.12.1 Independent signatures 41
5.12.2 Embedded signatures 42 5.12.2 Embedded signatures 42
6. Additional Electronic Signature validation attributes 42 6. Additional Electronic Signature validation attributes 42
skipping to change at page 4, line 5 skipping to change at page 4, line 5
9.2 Choice of algorithms 58 9.2 Choice of algorithms 58
10. IANA Considerations 59 10. IANA Considerations 59
11. References 59 11. References 59
11.1 Normative references 58 11.1 Normative references 58
11.2 Informative references 60 11.2 Informative references 60
12. Authors' addresses 62 12. Authors' addresses 62
Internet-draft CMS Advanced Electronic Signatures September 2007
13. Acknowledgments 63 13. Acknowledgments 63
Annex A (normative): ASN.1 definitions 64 Annex A (normative): ASN.1 definitions 64
A.1 Signature format definitions using X.208 ASN.1 syntax 64 A.1 Signature format definitions using X.208 ASN.1 syntax 64
A.2 Signature format definitions using X.680 ASN.1 syntax 72 A.2 Signature format definitions using X.680 ASN.1 syntax 72
Annex B (informative): Extended forms of Electronic Signatures 81 Annex B (informative): Extended forms of Electronic Signatures 81
B.1 Extended forms of validation data 81 B.1 Extended forms of validation data 81
B.1.1 CAdES-X Long 82 B.1.1 CAdES-X Long 82
B.1.2 CAdES-X Type 1 83 B.1.2 CAdES-X Type 1 83
skipping to change at page 5, line 5 skipping to change at page 5, line 5
C.4.6 Reference to additional data 108 C.4.6 Reference to additional data 108
C.4.7 Time-stamping for mutual recognition 108 C.4.7 Time-stamping for mutual recognition 108
C.4.8 TSA key compromise 109 C.4.8 TSA key compromise 109
C.5 Multiple signatures 109 C.5 Multiple signatures 109
Annex D (informative):Data protocols to interoperate with TSPs 110 Annex D (informative):Data protocols to interoperate with TSPs 110
D.1 Operational protocols 110 D.1 Operational protocols 110
D.1.1 Certificate retrieval 110 D.1.1 Certificate retrieval 110
D.1.2 CRL retrieval 110 D.1.2 CRL retrieval 110
Internet-draft CMS Advanced Electronic Signatures September 2007
D.1.3 OnLine certificate status 110 D.1.3 OnLine certificate status 110
D.1.4 Time-stamping 110 D.1.4 Time-stamping 110
D.2 Management protocols 110 D.2 Management protocols 110
D.2.1 Request for certificate revocation 110 D.2.1 Request for certificate revocation 110
Annex E (informative): Guidance on naming 111 Annex E (informative): Guidance on naming 111
E.1 Allocation of names 111 E.1 Allocation of names 111
E.2 Providing access to registration information 111 E.2 Providing access to registration information 111
E.3 Naming schemes 112 E.3 Naming schemes 112
E.3.1 Naming schemes for individual citizens 112 E.3.1 Naming schemes for individual citizens 112
skipping to change at page 6, line 5 skipping to change at page 6, line 5
I.2.3 General 128 I.2.3 General 128
Annex J (informative): Changes from the previous version 130 Annex J (informative): Changes from the previous version 130
Full Copyright Statement 131 Full Copyright Statement 131
Disclaimer 131 Disclaimer 131
Intellectual Property 131 Intellectual Property 131
Internet-draft CMS Advanced Electronic Signatures September 2007
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. This includes evidence as validity of such signatures is important. This includes evidence as
to its validity even if the signer or verifying party later attempts to its validity even if the signer or verifying party later attempts
to deny (i.e., repudiates, see ISO/IEC 10181-5 [ISO10181-5]) the to deny (i.e., repudiates, see ISO/IEC 10181-5 [ISO10181-5]) the
validity of the signature). validity of the signature).
skipping to change at page 7, line 5 skipping to change at page 7, line 5
of long term electronic signatures. of long term electronic signatures.
An electronic signature defined by the present document can be used for An electronic signature defined by the present document can be used for
arbitration in case of a dispute between the signer and verifier, which arbitration in case of a dispute between the signer and verifier, which
may occur at some later time, even years later. may occur at some later time, even years later.
The present document includes the concept of signature policies that The present document includes the concept of signature policies that
can be used to establish technical consistency when validating can be used to establish technical consistency when validating
electronic signatures but does not mandate their use. electronic signatures but does not mandate their use.
Internet-draft CMS Advanced Electronic Signatures September 2007
The present document is based on the use of public key cryptography to The present document is based on the use of public key cryptography to
produce digital signatures, supported by public key certificates. produce digital signatures, supported by public key certificates.
The present document also specifies the use of time-stamping and time- The present document also specifies the use of time-stamping and time-
marking services to prove the validity of a signature long after the marking services to prove the validity of a signature long after the
normal lifetime of critical elements of an electronic signature. It normal lifetime of critical elements of an electronic signature. It
also, as an option, defines ways to provide very long-term protection also, as an option, defines ways to provide very long-term protection
against key compromise or weakened algorithms. against key compromise or weakened algorithms.
The present document builds on existing standards that are widely The present document builds on existing standards that are widely
adopted. This includes: adopted. This includes:
skipping to change at page 8, line 5 skipping to change at page 8, line 5
Another document, TS 101 903 [TS101903], describes formats for XML Another document, TS 101 903 [TS101903], describes formats for XML
advanced electronic signatures (XAdES) built on XMLDSIG [XMLDSIG]. advanced electronic signatures (XAdES) built on XMLDSIG [XMLDSIG].
In addition, the present document identifies other documents that In addition, the present document identifies other documents that
define formats for Public Key Certificates, Attribute Certificates, define formats for Public Key Certificates, Attribute Certificates,
Certificate Revocation Lists and supporting protocols, including, Certificate Revocation Lists and supporting protocols, including,
protocols for use of trusted third parties to support the operation of protocols for use of trusted third parties to support the operation of
electronic signature creation and validation. electronic signature creation and validation.
Internet-draft CMS Advanced Electronic Signatures September 2007
Informative annexes include: Informative annexes include:
- illustrations of extended forms of extended Electronic Signatures - illustrations of extended forms of extended Electronic Signatures
formats that protect against various vulnerabilities and examples formats that protect against various vulnerabilities and examples
of validation processes (Annex B); of validation processes (Annex B);
- descriptions and explanations of some of the concepts used in the - descriptions and explanations of some of the concepts used in the
present document, giving a rationale for normative parts of the present document, giving a rationale for normative parts of the
present document (Annex C); present document (Annex C);
skipping to change at page 9, line 5 skipping to change at page 9, line 5
Attribute Authority (AA): authority which assigns privileges by issuing Attribute Authority (AA): authority which assigns privileges by issuing
attribute certificates. attribute certificates.
Authority certificate: certificate issued to an authority (e.g. either Authority certificate: certificate issued to an authority (e.g. either
to a certification authority or to an attribute authority). to a certification authority or to an attribute authority).
Attribute Authority Revocation List (AARL): revocation list containing Attribute Authority Revocation List (AARL): revocation list containing
a list of references to certificates issued to AAs, that are no longer a list of references to certificates issued to AAs, that are no longer
considered valid by the issuing authority. considered valid by the issuing authority.
Internet-draft CMS Advanced Electronic Signatures September 2007
Attribute Certificate Revocation List (ACRL): revocation list Attribute Certificate Revocation List (ACRL): revocation list
containing a list of references to attribute certificates that are no containing a list of references to attribute certificates that are no
longer considered valid by the issuing authority. longer considered valid by the issuing authority.
Certification Authority Revocation List (CARL): revocation list Certification Authority Revocation List (CARL): revocation list
containing a list of public-key certificates issued to certification containing a list of public-key certificates issued to certification
authorities, that are no longer considered valid by the certificate authorities, that are no longer considered valid by the certificate
issuer. issuer.
Certification Authority (CA): authority trusted by one or more users to Certification Authority (CA): authority trusted by one or more users to
create and assign public key certificates, optionally the certification create and assign public key certificates, optionally the certification
skipping to change at page 10, line 5 skipping to change at page 10, line 5
be used to validate it. be used to validate it.
Grace period: time period which permits the certificate revocation Grace period: time period which permits the certificate revocation
information to propagate through the revocation process to relying information to propagate through the revocation process to relying
parties. parties.
Initial verification: a process performed by a verifier done after an Initial verification: a process performed by a verifier done after an
electronic signature is generated in order to capture additional electronic signature is generated in order to capture additional
information that could make it valid for long term verification. information that could make it valid for long term verification.
Internet-draft CMS Advanced Electronic Signatures September 2007
Public Key Certificate (PKC): public keys of a user, together with some Public Key Certificate (PKC): 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 which issued it. private key of the certification authority which issued it.
NOTE: See ITU-T Recommendation X.509 [1]. NOTE: See ITU-T Recommendation X.509 [1].
Rivest-Shamir-Adleman (RSA): asymmetric cryptography algorithm based on Rivest-Shamir-Adleman (RSA): asymmetric cryptography algorithm based on
the difficulty to factor very large numbers, using a key pair: a the difficulty to factor very large numbers, using a key pair: a
private key and a public key. private key and a public key.
skipping to change at page 11, line 5 skipping to change at page 11, line 5
thus establishing evidence that the datum existed before that time. thus establishing evidence that the datum existed before that time.
Time-Marking Authority: trusted third party that creates records in an Time-Marking Authority: trusted third party that creates records in an
audit trail in order to indicate that a datum existed before a audit trail in order to indicate that a datum existed before a
particular point in time. particular point in time.
Time-Stamping Authority (TSA): trusted third party that creates time- Time-Stamping Authority (TSA): trusted third party that creates time-
stamp tokens in order to indicate that a datum existed at a particular stamp tokens in order to indicate that a datum existed at a particular
point in time. point in time.
Internet-draft CMS Advanced Electronic Signatures September 2007
Time-Stamping Unit (TSU): set of hardware and software which is managed Time-Stamping Unit (TSU): set of hardware and software which is managed
as a unit and has a single time-stamp token signing key active at a as a unit and has a single time-stamp token signing key active at a
time. time.
Trusted Service Provider (TSP): entity that helps to build trust Trusted Service Provider (TSP): entity that helps to build trust
relationships by making available or providing some information upon relationships by making available or providing some information upon
request. request.
Validation data: additional data that may be used by a verifier of Validation data: additional data that may be used by a verifier of
electronic signatures to determine the signature is valid. electronic signatures to determine the signature is valid.
skipping to change at page 12, line 5 skipping to change at page 12, line 5
CAdES-X CAdES with eXtended validation data CAdES-X CAdES with eXtended validation data
CARL Certification Authority Revocation List CARL Certification Authority Revocation List
CMS Cryptographic Message Syntax CMS Cryptographic Message Syntax
CRL Certificate Revocation List CRL Certificate Revocation List
CWA CEN Workshop Agreement CWA CEN Workshop Agreement
DER Distinguished Encoding Rules (for ASN.1) DER Distinguished Encoding Rules (for ASN.1)
DSA Digital Signature Algorithm DSA Digital Signature Algorithm
EDIFACT Electronic Data Interchange For Administration, Commerce EDIFACT Electronic Data Interchange For Administration, Commerce
and Transport and Transport
Internet-draft CMS Advanced Electronic Signatures September 2007
EESSI European Electronic Signature Standardization Initiative EESSI European Electronic Signature Standardization Initiative
EPES Explicit Policy-based Electronic Signature EPES Explicit Policy-based Electronic Signature
ES Electronic Signature ES Electronic Signature
ESS Enhanced Security Services (enhances CMS) ESS Enhanced Security Services (enhances CMS)
IDL Interface Definition Language IDL Interface Definition Language
MIME Multipurpose Internet Mail Extensions MIME Multipurpose Internet Mail Extensions
OCSP Online Certificate Status Provider OCSP Online Certificate Status Provider
OID Object IDentifier OID Object IDentifier
PKC Public Key Certificate PKC Public Key Certificate
PKIX Public Key Infrastructure using X.509 (IETF Working Group) PKIX Public Key Infrastructure using X.509 (IETF Working Group)
skipping to change at page 13, line 5 skipping to change at page 13, line 5
4.1 Major parties 4.1 Major parties
The major parties involved in a business transaction supported by The major parties involved in a business transaction supported by
electronic signatures as defined in the present document are: electronic signatures as defined in the present document are:
- the Signer; - the Signer;
- the Verifier; - the Verifier;
- Trusted Service Providers (TSP); and - Trusted Service Providers (TSP); and
- the Arbitrator. - the Arbitrator.
Internet-draft CMS Advanced Electronic Signatures September 2007
The signer is the entity that creates the electronic signature. When The signer is the 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 The verifier is the entity that validates the electronic signature, it
may be a single entity or multiple entities. may be a single entity or multiple entities.
The Trusted Service Providers (TSPs) are one or more entities that help The 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. They
skipping to change at page 14, line 5 skipping to change at page 14, line 5
In some cases the following additional TSPs are needed: In some cases the following additional TSPs are needed:
- Attribute Authorities. - Attribute Authorities.
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 in disputes between a signer An Arbitrator is an entity that arbitrates in disputes between a signer
and a verifier. and a verifier.
Internet-draft CMS Advanced Electronic Signatures September 2007
4.2 Signatures policies 4.2 Signatures policies
The present document includes the concept of signature policies that The present document includes the concept of signature policies that
can be used to establish technical consistency when validating can be used to establish technical consistency when validating
electronic signatures. electronic signatures.
When a comprehensive signature policy used by the verifier is either When a comprehensive signature policy used by the verifier is either
explicitly indicated by the signer or implied by the data being signed, explicitly indicated by the signer or implied by the data being signed,
then a consistent result can be obtained when validating an electronic then a consistent result can be obtained when validating an electronic
signature. signature.
skipping to change at page 15, line 4 skipping to change at page 15, line 4
present contains: present contains:
- The signed user data (e.g. the signer's document) as defined in - The signed user data (e.g. the signer's document) as defined in
CMS (RFC 3852 [4]); CMS (RFC 3852 [4]);
- A collection of mandatory signed attributes as defined in CMS - A collection of mandatory signed attributes as defined in CMS
(RFC 3852 [4]) and in ESS (RFC 2634 [5]); (RFC 3852 [4]) and in ESS (RFC 2634 [5]);
- Additional mandatory signed attributes defined in the present - Additional mandatory signed attributes defined in the present
document; and document; and
Internet-draft CMS Advanced Electronic Signatures September 2007
- The digital signature value computed on the user data and, when - The digital signature value computed on the user data and, when
present, on the signed attributes, as defined in CMS (RFC 3852 present, on the signed attributes, as defined in CMS (RFC 3852
[4]). [4]).
A CAdES Basic Electronic Signature (CAdES-BES) in accordance with the A CAdES Basic Electronic Signature (CAdES-BES) in accordance with the
present document may contain: present document may contain:
- a collection of additional signed attributes; and - a collection of additional signed attributes; and
- a collection of optional unsigned attributes. - a collection of optional unsigned attributes.
skipping to change at page 16, line 5 skipping to change at page 16, line 5
information that describes the innermost signed content of a information that describes the innermost signed content of a
multi-layer message where one content is encapsulated in another. multi-layer message where one content is encapsulated in another.
Section 5.10.1 provides the specification details. Section C.3.8 Section 5.10.1 provides the specification details. Section C.3.8
provides the rationale. provides the rationale.
- Content-reference. as defined in ESS (RFC 2634 [5]) can be - Content-reference. as defined in ESS (RFC 2634 [5]) can be
incorporated as a way to link request and reply messages in an incorporated as a way to link request and reply messages in an
exchange between two parties. Section 5.10.1 provides the exchange between two parties. Section 5.10.1 provides the
specification details. Section C.3.9 provides the rationale. specification details. Section C.3.9 provides the rationale.
Internet-draft CMS Advanced Electronic Signatures September 2007
- Content-identifier. as defined in ESS (RFC 2634 [5]) contains an - Content-identifier. as defined in ESS (RFC 2634 [5]) contains an
identifier that may be used later on in the previous content- identifier that may be used later on in the previous content-
reference attribute. Section 5.10.2 provides the specification reference attribute. Section 5.10.2 provides the specification
details. Section C.3.8 provides the rationale. details. Section C.3.8 provides the rationale.
- Commitment-type-indication. This attribute is defined by the - Commitment-type-indication. This attribute is defined by the
present document as a way to indicate the commitment endorsed by present document as a way to indicate the commitment endorsed by
the signer when producing the signature. Section 5.11.1 provides the signer when producing the signature. Section 5.11.1 provides
the specification details. Section C.3.2 provides the the specification details. Section C.3.2 provides the
rationale. rationale.
skipping to change at page 17, line 5 skipping to change at page 17, line 5
||+---------+ +----------+ | | ||+---------+ +----------+ | |
|||Signer's | | Signed | Digital | | |||Signer's | | Signed | Digital | |
|||Document | |Attributes| Signature | | |||Document | |Attributes| Signature | |
||| | | | | | ||| | | | | |
||+---------+ +----------+ | | ||+---------+ +----------+ | |
|+------------------------------------+ | |+------------------------------------+ |
+---------------------------------------+ +---------------------------------------+
Figure 1: Illustration of a CAdES-BES Figure 1: Illustration of a CAdES-BES
Internet-draft CMS Advanced Electronic Signatures September 2007
The signer's conformance requirements of a CAdES-BES are defined in The signer's conformance requirements of a CAdES-BES are defined in
section 8.1. section 8.1.
NOTE: The CAdES-BES is the minimum format for an electronic signature NOTE: The CAdES-BES is the minimum format for an electronic signature
to be generated by the signer. On its own, it does not to be generated by the signer. On its own, it does not
provide enough information for it to be verified in the longer provide enough information for it to be verified in the longer
term. For example, revocation information issued by the term. For example, revocation information issued by the
relevant certificate status information issuer needs to be relevant certificate status information issuer needs to be
available for long term validation (see section 4.4.2). available for long term validation (see section 4.4.2).
skipping to change at page 18, line 5 skipping to change at page 18, line 5
the mandated signature policy. the mandated signature policy.
Section 5.7.3 provides the details on the specification of signature- Section 5.7.3 provides the details on the specification of signature-
policy-identifier attribute. Section C.1 provides a short rationale. policy-identifier attribute. Section C.1 provides a short rationale.
Specification of the contents of signature policies is outside the Specification of the contents of signature policies is outside the
scope of the present document. scope of the present document.
Further information on signature policies is provided in TR 102 038 Further information on signature policies is provided in TR 102 038
[TR102038] and sections 5.8.1, C.1 and C.3.1 of the present document. [TR102038] and sections 5.8.1, C.1 and C.3.1 of the present document.
Internet-draft CMS Advanced Electronic Signatures September 2007
The structure of the CAdES-EPES is illustrated in figure 2. The structure of the CAdES-EPES is illustrated in figure 2.
+------------- Elect.Signature (CAdES-EPES) ---------------+ +------------- Elect.Signature (CAdES-EPES) ---------------+
| | | |
|+-------------------------------------------------------+ | |+-------------------------------------------------------+ |
|| +-----------+ | | || +-----------+ | |
|| | | +---------------------------+ | | || | | +---------------------------+ | |
|| | | | +----------+ | | | || | | | +----------+ | | |
|| | Signer's | | |Signature | Signed | Digital | | || | Signer's | | |Signature | Signed | Digital | |
|| | Document | | |Policy ID | Attributes |Signature| | || | Document | | |Policy ID | Attributes |Signature| |
skipping to change at page 19, line 5 skipping to change at page 19, line 5
When the signature-policy-identifier signed attribute is present, it When the signature-policy-identifier signed attribute is present, it
shall meet the requirements of the signature policy. shall meet the requirements of the signature policy.
Validation data includes CA certificates as well as revocation status Validation data includes CA certificates as well as revocation status
information in the form of Certificate Revocation Lists (CRLs) or information in the form of Certificate Revocation Lists (CRLs) or
certificate status information (OCSP) provided by an on-line service. certificate status information (OCSP) provided by an on-line service.
Validation data also includes evidence that the signature was created Validation data also includes evidence that the signature was created
before a particular point in time this may be either a time-stamp before a particular point in time this may be either a time-stamp
token or time-mark. token or time-mark.
Internet-draft CMS Advanced Electronic Signatures September 2007
The present document defines unsigned attributes able to contain The present document defines unsigned attributes able to contain
validation data that can be added to CAdES-BES and CAdES-EPES leading validation data that can be added to CAdES-BES and CAdES-EPES leading
to electronic signature formats that include validation data. Sections to electronic signature formats that include validation data. Sections
below summarize these formats and their most relevant characteristics. below summarize these formats and their most relevant characteristics.
4.4.1 Electronic Signature with Time (CAdES-T) 4.4.1 Electronic Signature with Time (CAdES-T)
Electronic Signature with Time (CAdES-T) in accordance with the present Electronic Signature with Time (CAdES-T) in accordance with the present
document is when there exits trusted time associated with the ES. document is when there exits trusted time associated with the ES.
skipping to change at page 20, line 4 skipping to change at page 20, line 4
| | | | | | | |
| | Management and | | | | Management and | |
| | provision of time | | | | provision of time | |
| | mark is the | | | | mark is the | |
| | responsibility of | | | | responsibility of | |
| | the TSP. | | | | the TSP. | |
| +----------------------+ | | +----------------------+ |
+------------------------------------------------------------------+ +------------------------------------------------------------------+
Figure 3: Illustration of CAdES-T formats Figure 3: Illustration of CAdES-T formats
Internet-draft CMS Advanced Electronic Signatures September 2007
NOTE 1 : A time stamp token is added to the CAdES-BES or CAdES-EPES NOTE 1 : A time stamp token is added to the CAdES-BES or CAdES-EPES
as an unsigned attribute. as an unsigned attribute.
NOTE 2 : Timestamp tokens that may themselves include unsigned NOTE 2 : Timestamp tokens that may themselves include unsigned
attributes required to validate the timestamp token, such attributes required to validate the timestamp token, such
as the complete-certificate-references and complete- as the complete-certificate-references and complete-
revocation-references attributes as defined by the present revocation-references attributes as defined by the present
document. document.
4.4.2 ES with Complete validation data references (CAdES-C) 4.4.2 ES with Complete validation data references (CAdES-C)
skipping to change at page 21, line 5 skipping to change at page 21, line 5
|||+---------++----------+ ||timemarked| | | | | |||+---------++----------+ ||timemarked| | | | |
||+--------------------------------++----------+ | | | | ||+--------------------------------++----------+ | | | |
|+-----------------------------------------------+ +-------------+ | |+-----------------------------------------------+ +-------------+ |
+------------------------------------------------------------------+ +------------------------------------------------------------------+
Figure 4: Illustration of CAdES-C format Figure 4: Illustration of CAdES-C format
NOTE 1: The complete certificate and revocation references are added NOTE 1: The complete certificate and revocation references are added
to the CAdES-T as an unsigned attribute. to the CAdES-T as an unsigned attribute.
Internet-draft CMS Advanced Electronic Signatures September 2007
NOTE 2: As a minimum, the signer will provide the CAdES-BES or when NOTE 2: As a minimum, the signer will provide the CAdES-BES or when
indicating that the signature conforms to an explicit signing indicating that the signature conforms to an explicit signing
policy the CAdES-EPES. policy the CAdES-EPES.
NOTE 3: To reduce the risk of repudiating signature creation, the NOTE 3: To reduce the risk of repudiating signature creation, the
trusted time indication needs to be as close as possible to trusted time indication needs to be as close as possible to
the time the signature was created. The signer or a TSP could the time the signature was created. The signer or a TSP could
provide the CAdES-T, if not the verifier should create the provide the CAdES-T, if not the verifier should create the
CAdES-T on first receipt of an electronic signature because CAdES-T on first receipt of an electronic signature because
the CAdES-T provides independent evidence of the existence of the CAdES-T provides independent evidence of the existence of
the signature prior to the trusted time indication. the signature prior to the trusted time indication.
skipping to change at page 22, line 4 skipping to change at page 22, line 4
time | status | status | time | status | status |
| checking | checking | | checking | checking |
| | | | | |
Time-stamp Certification Build Time-stamp Certification Build
or path CAdES-C or path CAdES-C
time-mark construction time-mark construction
over & verification over & verification
signature signature
Figure 5: Illustration of a grace period Figure 5: Illustration of a grace period
Internet-draft CMS Advanced Electronic Signatures September 2007
NOTE 7: CWA 14171 [CWA 14171] specifies a signature validation NOTE 7: CWA 14171 [CWA 14171] specifies a signature validation
process using CAdES-T, CAdES-C and a grace period. process using CAdES-T, CAdES-C and a grace period.
Annex B provides example validation processes. Section C.4 Annex B provides example validation processes. Section C.4
provides additional information about applying grace periods provides additional information about applying grace periods
during the validation process. during the validation process.
The verifier's conformance requirements are defined in section 8.3 for The verifier's conformance requirements are defined in section 8.3 for
time stamped CAdES-C and section 8.4 for time marked CAdES-C. The time stamped CAdES-C and section 8.4 for time marked CAdES-C. The
present document only defines conformance requirements for the verifier present document only defines conformance requirements for the verifier
up to an ES with complete validation data (CAdES-C). This means that up to an ES with complete validation data (CAdES-C). This means that
skipping to change at page 23, line 5 skipping to change at page 23, line 5
document adds to the CAdES-C format the certificate-values and document adds to the CAdES-C format the certificate-values and
revocation-values attributes. The first one contains the whole revocation-values attributes. The first one contains the whole
certificate path required for verifying the signature; the second one certificate path required for verifying the signature; the second one
the CRLs and/OCSP responses required for the validation of the the CRLs and/OCSP responses required for the validation of the
signature. This provides a known repository of certificate and signature. This provides a known repository of certificate and
revocation information required to validate an CAdES-C and prevents revocation information required to validate an CAdES-C and prevents
such information getting lost. Sections 6.3.3 and 6.3.4 give such information getting lost. Sections 6.3.3 and 6.3.4 give
specification details. Section B.1.1 gives details on the production specification details. Section B.1.1 gives details on the production
of the format. Sections C4.1 to C.4.2 provide the rationale. of the format. Sections C4.1 to C.4.2 provide the rationale.
Internet-draft CMS Advanced Electronic Signatures September 2007
The structure of the CAdES-X Long format is illustrated in figure 6. The structure of the CAdES-X Long format is illustrated in figure 6.
+----------------------- CAdES-X-Long -----------------------------+ +----------------------- CAdES-X-Long -----------------------------+
|+------------------------------------ CadES-C --+ | |+------------------------------------ CadES-C --+ |
|| +----------+ | +-------------+ | || +----------+ | +-------------+ |
||+------ CAdES -------------------+|Timestamp | | | | | ||+------ CAdES -------------------+|Timestamp | | | | |
||| || over | | | Complete | | ||| || over | | | Complete | |
|||+---------++----------+ ||digital | | | certificate | | |||+---------++----------+ ||digital | | | certificate | |
||||Signer's || Signed | Digital ||signature | | | and | | ||||Signer's || Signed | Digital ||signature | | | and | |
||||Document ||Attributes|Signature|| | | | revocation | | ||||Document ||Attributes|Signature|| | | | revocation | |
skipping to change at page 24, line 5 skipping to change at page 24, line 5
attribute, whose content is a time-stamp token on the CAdES-C itself. attribute, whose content is a time-stamp token on the CAdES-C itself.
This provides an integrity and trusted time protection over all the This provides an integrity and trusted time protection over all the
elements and references. It may protect the certificates, CRLs and elements and references. It may protect the certificates, CRLs and
OCSP responses in case of a later compromise of a CA key, CRL key or OCSP responses in case of a later compromise of a CA key, CRL key or
OCSP issuer key. Section 6.3.5 provides the specification details. OCSP issuer key. Section 6.3.5 provides the specification details.
Section B.1.2 gives details on the production of the time-stamping Section B.1.2 gives details on the production of the time-stamping
process. Sections C.4.4.1 provides the rationale. process. Sections C.4.4.1 provides the rationale.
Internet-draft CMS Advanced Electronic Signatures September 2007
The structure of the CAdES-X Type 1 format is illustrated in figure 7. The structure of the CAdES-X Type 1 format is illustrated in figure 7.
+----------------------- CAdES-X-Type 1 ------------------------------+ +----------------------- CAdES-X-Type 1 ------------------------------+
|+-------------------------------------- CAdES-C -----+ | |+-------------------------------------- CAdES-C -----+ |
|| +-------------+ | +-----------+ | || +-------------+ | +-----------+ |
||+--------- CAdES ------------------+| Timestamp | | | | | ||+--------- CAdES ------------------+| Timestamp | | | | |
||| || over | | | | | ||| || over | | | | |
|||+---------++----------+ || digital | | | | | |||+---------++----------+ || digital | | | | |
||||Signer's || Signed | Digital || signature | | | Timestamp | | ||||Signer's || Signed | Digital || signature | | | Timestamp | |
||||Document ||Attributes| Signature || | | | over | | ||||Document ||Attributes| Signature || | | | over | |
skipping to change at page 25, line 5 skipping to change at page 25, line 5
It may protect the certificates, CRLs and OCSP responses in case of a It may protect the certificates, CRLs and OCSP responses in case of a
later compromise of a CA key, CRL key or OCSP issuer key. later compromise of a CA key, CRL key or OCSP issuer key.
Both CAdES-X Type 1 and CAdES-X Type 2 counter the same threats and the Both CAdES-X Type 1 and CAdES-X Type 2 counter the same threats and the
usage of one or the other depends on the environment. Section 6.3.5 usage of one or the other depends on the environment. Section 6.3.5
provides the specification details. Section B.1.3 gives details on the provides the specification details. Section B.1.3 gives details on the
production of the time-stamping process. Section C.4.4.2 provides the production of the time-stamping process. Section C.4.4.2 provides the
rationale. rationale.
Internet-draft CMS Advanced Electronic Signatures September 2007
The structure of the CAdES-X Type 2 format is illustrated in figure 8. The structure of the CAdES-X Type 2 format is illustrated in figure 8.
+------------------------- CAdES-X-Type 2 ----------------------------+ +------------------------- CAdES-X-Type 2 ----------------------------+
|+----------------------------------------CAdES-C ---+ | |+----------------------------------------CAdES-C ---+ |
|| +------------+| | || +------------+| |
||+----- CAdES -----------------------+| Timmestamp || | ||+----- CAdES -----------------------+| Timmestamp || |
||| || over || | ||| || over || |
|||+---------+ +----------+ || digital || +-------------+| |||+---------+ +----------+ || digital || +-------------+|
||||Signer's | | Signed | Digital || signature || | Time-stamp || ||||Signer's | | Signed | Digital || signature || | Time-stamp ||
||||Document | |Attributes| signature || || | only over || ||||Document | |Attributes| signature || || | only over ||
skipping to change at page 26, line 5 skipping to change at page 26, line 5
4.4.3.4 EXtended Long Electronic Signature with Time (CAdES-X Long Type 4.4.3.4 EXtended Long Electronic Signature with Time (CAdES-X Long Type
1 or 2) 1 or 2)
Extended Long with Time (CAdES-X Long Type 1 or 2) in accordance with Extended Long with Time (CAdES-X Long Type 1 or 2) in accordance with
the present document is a combination of CAdES-X Long and one of the the present document is a combination of CAdES-X Long and one of the
two former types (CAdES-X Type 1 and CAdES-X Type 2). Section B.1.4 two former types (CAdES-X Type 1 and CAdES-X Type 2). Section B.1.4
gives details on the production of the time-stamping process. Section gives details on the production of the time-stamping process. Section
C4.8 in annex C provides the rationale. C4.8 in annex C provides the rationale.
Internet-draft CMS Advanced Electronic Signatures September 2007
The structure of the CAdES-X Long Type 1 and CAdES-X Long Type 2. The structure of the CAdES-X Long Type 1 and CAdES-X Long Type 2.
format is illustrated in figure 9. format is illustrated in figure 9.
+------------------ CAdES-X Long Type 1 or 2 -----------------------+ +------------------ CAdES-X Long Type 1 or 2 -----------------------+
| +--------------+| | +--------------+|
|+-------------------------------------- CAdES-C --+|+------------+|| |+-------------------------------------- CAdES-C --+|+------------+||
|| ||| Timestamp ||| || ||| Timestamp |||
||+------- CAdES --------------------++----------+ ||| over ||| ||+------- CAdES --------------------++----------+ ||| over |||
||| ||Timestamp | ||| CAdES-C ||| ||| ||Timestamp | ||| CAdES-C |||
||| ||over | ||+------------+|| ||| ||over | ||+------------+||
skipping to change at page 27, line 5 skipping to change at page 27, line 5
Archival Form (CAdES-A) in accordance with the present document builds Archival Form (CAdES-A) in accordance with the present document builds
on a CAdES-X Long or a CAdES-X Long Type 1 or 2 by adding one or more on a CAdES-X Long or a CAdES-X Long Type 1 or 2 by adding one or more
archive-time-stamp attributes. This form is used for archival of long- archive-time-stamp attributes. This form is used for archival of long-
term signatures. Successive time-stamps protect the whole material term signatures. Successive time-stamps protect the whole material
against vulnerable hashing algorithms or the breaking of the against vulnerable hashing algorithms or the breaking of the
cryptographic material or algorithms. Section 6.4 contains the cryptographic material or algorithms. Section 6.4 contains the
specification details. Sections C.4.5 and C.4.8 provide the rationale. specification details. Sections C.4.5 and C.4.8 provide the rationale.
The structure of the CAdES-A form is illustrated in figure 10. The structure of the CAdES-A form is illustrated in figure 10.
Internet-draft CMS Advanced Electronic Signatures September 2007
+---------------------------CAdES-A ---------------------------------+ +---------------------------CAdES-A ---------------------------------+
|+----------------------------------------------------+ | |+----------------------------------------------------+ |
|| +--------------+| +----------+ | || +--------------+| +----------+ |
||+----------------------CAdES-C ----+|+------------+|| | | | ||+----------------------CAdES-C ----+|+------------+|| | | |
||| +----------+ ||| Timestamp ||| | | | ||| +----------+ ||| Timestamp ||| | | |
|||+---- CAdES-BES ----+|Timestamp | ||| over ||| | | | |||+---- CAdES-BES ----+|Timestamp | ||| over ||| | | |
|||| or CAdeS-EPES || over | ||| CAdES-C ||| | Archive | | |||| or CAdeS-EPES || over | ||| CAdES-C ||| | Archive | |
|||| ||digital | ||+------------+|| | | | |||| ||digital | ||+------------+|| | | |
|||| ||signature | || or || |Timestamp | | |||| ||signature | || or || |Timestamp | |
|||| || | ||+------------+|| | | | |||| || | ||+------------+|| | | |
skipping to change at page 28, line 4 skipping to change at page 28, line 4
The CAdES-C may be used for arbitration should there be a dispute The CAdES-C may be used for arbitration should there be a dispute
between the signer and verifier, provided that: between the signer and verifier, provided that:
- 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, ACRLs or OCSP responses referenced in the CAdES-C; required CRLs, ACRLs or OCSP responses referenced in the CAdES-C;
- when time-stamping in the CAdES-T is being used, the certificate - when time-stamping in the CAdES-T is being used, the certificate
from the TSU that has issued the time-stamp token in the CAdES-T from the TSU that has issued the time-stamp token in the CAdES-T
format is still within its validity period; format is still within its validity period;
Internet-draft CMS Advanced Electronic Signatures September 2007
- when time-stamping in the CAdES-T is being used, the certificate - when time-stamping in the CAdES-T is being used, the certificate
from the TSU that has issued the time-stamp token in the CAdES-T from the TSU that has issued the time-stamp token in the CAdES-T
format is not revoked at the time of arbitration; format is not revoked at the time of arbitration;
- when time-marking in the CAdES-T is being used, a reliable audit - when time-marking in the CAdES-T is being used, a reliable audit
trail from the Time-Marking Authority is available for trail from the Time-Marking Authority is available for
examination regarding the time; examination regarding the time;
- none of the private keys corresponding to the certificates used - none of the private keys corresponding to the certificates used
to verify the signature chain have ever been compromised; to verify the signature chain have ever been compromised;
skipping to change at page 29, line 5 skipping to change at page 29, line 5
electronic signature may be checked again at some later time when electronic signature may be checked again at some later time when
additional information becomes available. additional information becomes available.
NOTE: For example; an incomplete validation may be because all the NOTE: For example; an incomplete validation may be because all the
required certificates are not available or the grace period is required certificates are not available or the grace period is
not completed. not completed.
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.
Internet-draft CMS Advanced Electronic Signatures September 2007
Example validation sequences are illustrated in annex B. Example validation sequences are illustrated in annex B.
5 Electronic signature attributes 5 Electronic signature attributes
This section builds upon the existing Cryptographic Message Syntax This section builds upon the existing Cryptographic Message Syntax
(CMS), as defined in RFC 3852 [4], and Enhanced Security Services (CMS), as defined in RFC 3852 [4], and Enhanced Security Services
(ESS), as defined in RFC 2634 [5]. The overall structure of Electronic (ESS), as defined in RFC 2634 [5]. The overall structure of Electronic
Signature is as defined in CMS. The Electronic Signature (ES) uses Signature is as defined in CMS. The Electronic Signature (ES) uses
attributes defined in CMS, ESS and the present document. The present attributes defined in CMS, ESS and the present document. The present
document defines ES attributes which it uses and are not defined document defines ES attributes which it uses and are not defined
skipping to change at page 30, line 5 skipping to change at page 30, line 5
[4]). [4]).
5.4 SignedData type 5.4 SignedData type
The syntax of the SignedData of the ES is as defined in CMS (RFC 3852 The syntax of the SignedData of the ES is as defined in CMS (RFC 3852
[4]). [4]).
The fields of type SignedData have the meanings as defined in CMS The fields of type SignedData have the meanings as defined in CMS
(RFC 3852 [4]). (RFC 3852 [4]).
Internet-draft CMS Advanced Electronic Signatures September 2007
The identification of signer's certificate used to create the signature The identification of signer's certificate used to create the signature
is always signed (see section 5.7.3). The validation policy may specify is always signed (see section 5.7.3). The validation policy may specify
requirements for the presence of certain certificates. The degenerate case requirements for the presence of certain certificates. The degenerate case
where there are no signers is not valid in the present document. where there are no signers is not valid in the present document.
5.5 EncapsulatedContentInfo type 5.5 EncapsulatedContentInfo type
The syntax of the EncapsulatedContentInfo type ES is as defined in CMS The syntax of the EncapsulatedContentInfo type ES is as defined in CMS
(RFC 3852 [4]). (RFC 3852 [4]).
skipping to change at page 31, line 5 skipping to change at page 31, line 5
The fields of type SignerInfo have the meanings defined in CMS (RFC The fields of type SignerInfo have the meanings defined in CMS (RFC
3852 [4]) but the signedAttrs field shall contain the following 3852 [4]) but the signedAttrs field shall contain the following
attributes: attributes:
- content-type as defined in section 5.7.1; and - content-type as defined in section 5.7.1; and
- message-digest as defined in section 5.7.2; - message-digest as defined in section 5.7.2;
- signing-certificate as defined in section 5.7.3. - signing-certificate as defined in section 5.7.3.
Internet-draft CMS Advanced Electronic Signatures September 2007
5.6.1 Message digest calculation process 5.6.1 Message digest calculation process
The message digest calculation process is as defined in CMS (RFC 3852 The message digest calculation process is as defined in CMS (RFC 3852
[4]). [4]).
5.6.2 Message signature generation process 5.6.2 Message signature generation process
The input to the message signature generation process is as defined in The input to the message signature generation process is as defined in
CMS (RFC 3852 [4]). CMS (RFC 3852 [4]).
skipping to change at page 32, line 5 skipping to change at page 32, line 5
Note 2 : For implementations supporting signature generation, if Note 2 : For implementations supporting signature generation, if
the content-type attribute is id-data, then it is the content-type attribute is id-data, then it is
recommended that the eContent be encoded using MIME. recommended that the eContent be encoded using MIME.
For implementations supporting signature verification, if For implementations supporting signature verification, if
the signed data (i.e. eContent) is MIME-encoded, then the the signed data (i.e. eContent) is MIME-encoded, then the
OID of the content-type attribute must be id-data. OID of the content-type attribute must be id-data.
In both cases, the MIME content-type(s) must be used to In both cases, the MIME content-type(s) must be used to
identify the presentation format of the data. See Annex F identify the presentation format of the data. See Annex F
for further details about the use of MIME. for further details about the use of MIME.
Internet-draft CMS Advanced Electronic Signatures September 2007
5.7.2 Message digest 5.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 (RFC 3852 [4]). in CMS (RFC 3852 [4]).
5.7.3 Signing certificate reference attributes 5.7.3 Signing certificate reference attributes
The Signing certificate reference attributes are supported by using The Signing certificate reference attributes are supported by using
either the ESS signing-certificate attribute or the ESS-signing- either the ESS signing-certificate attribute or the ESS-signing-
certificate-v2 attribute. certificate-v2 attribute.
skipping to change at page 33, line 5 skipping to change at page 33, line 5
issuerSerial field. issuerSerial field.
If present, the issuerAndSerialNumber in SignerIdentifier field of the If present, the issuerAndSerialNumber in SignerIdentifier field of the
SignerInfo shall match the issuerSerial field present in ESSCertID. SignerInfo shall match the issuerSerial field present in ESSCertID.
In addition the certHash from ESSCertID shall match the SHA-1 hash of In addition the certHash from ESSCertID shall match the SHA-1 hash of
the certificate. The certificate identified shall be used during the the certificate. The certificate identified shall be used during the
signature verification process. If the hash of the certificate does signature verification process. If the hash of the certificate does
not match the certificate used to verify the signature, the signature not match the certificate used to verify the signature, the signature
shall be considered invalid. shall be considered invalid.
Internet-draft CMS Advanced Electronic Signatures September 2007
NOTE: Where an attribute certificate is used by the signer to NOTE: Where an attribute certificate is used by the signer to
associate a role, or other attributes of the signer, with the associate a role, or other attributes of the signer, with the
electronic signature, this is placed in the signer-attributes electronic signature, this is placed in the signer-attributes
attribute as defined in section 5.8.3. attribute as defined in section 5.8.3.
5.7.3.2 ESS signing certificate v2 attribute definition 5.7.3.2 ESS signing certificate v2 attribute definition
The ESS signing-certificate v2 attribute is similar to the ESS The ESS signing-certificate v2 attribute is similar to the ESS
signing-certificate defined above, except that this attribute can be signing-certificate defined above, except that this attribute can be
used with hashing algorithms other than SHA-1. used with hashing algorithms other than SHA-1.
skipping to change at page 34, line 5 skipping to change at page 34, line 5
5.7.3.3 Other signing certificate attribute definition 5.7.3.3 Other signing certificate attribute definition
RFC 3126 was using the other signing certificate attribute as RFC 3126 was using the other signing certificate attribute as
an alternative to the ESS signing-certificate when hashing algorithms an alternative to the ESS signing-certificate when hashing algorithms
other than SHA-1 were being used. Its use is now deprecated, since other than SHA-1 were being used. Its use is now deprecated, since
the structure of the general-signing-certificate-v2 attribute is the structure of the general-signing-certificate-v2 attribute is
simpler. Its description is however still present in this version for simpler. Its description is however still present in this version for
backwards compatibility. backwards compatibility.
Internet-draft CMS Advanced Electronic Signatures September 2007
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 }
The other-signing-certificate attribute value has the ASN.1 syntax The other-signing-certificate attribute value has the ASN.1 syntax
OtherSigningCertificate: OtherSigningCertificate:
OtherSigningCertificate ::= SEQUENCE { OtherSigningCertificate ::= SEQUENCE {
certs SEQUENCE OF OtherCertID, certs SEQUENCE OF OtherCertID,
policies SEQUENCE OF PolicyInformation OPTIONAL policies SEQUENCE OF PolicyInformation OPTIONAL
skipping to change at page 35, line 4 skipping to change at page 35, line 4
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 ::= CHOICE { SignaturePolicyIdentifier ::= CHOICE {
signaturePolicyId SignaturePolicyId, signaturePolicyId SignaturePolicyId,
signaturePolicyImplied SignaturePolicyImplied signaturePolicyImplied SignaturePolicyImplied
-- not used in this version -- not used in this version
} }
Internet-draft CMS Advanced Electronic Signatures September 2007
SignaturePolicyId ::= SEQUENCE { SignaturePolicyId ::= SEQUENCE {
sigPolicyId SigPolicyId, sigPolicyId SigPolicyId,
sigPolicyHash SigPolicyHash, sigPolicyHash SigPolicyHash,
sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF
SigPolicyQualifierInfo OPTIONAL} SigPolicyQualifierInfo OPTIONAL}
SignaturePolicyImplied ::= NULL SignaturePolicyImplied ::= NULL
The sigPolicyId field contains an object-identifier which uniquely The sigPolicyId field contains an object-identifier which uniquely
identifies a specific version of the signature policy. The syntax of identifies a specific version of the signature policy. The syntax of
skipping to change at page 36, line 4 skipping to change at page 36, line 4
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 }
The present document specifies the following qualifiers: The present 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, and signature policy, and
Internet-draft CMS Advanced Electronic Signatures September 2007
- sp-user-notice: this contains a user notice which should be - sp-user-notice: this contains a user notice which should be
displayed whenever the signature is validated. displayed whenever the signature is validated.
sigpolicyQualifierIds defined in the present document: sigpolicyQualifierIds defined in the present document:
SigPolicyQualifierId ::= OBJECT IDENTIFIER SigPolicyQualifierId ::= OBJECT IDENTIFIER
id-spq-ets-uri OBJECT IDENTIFIER ::= { iso(1) id-spq-ets-uri OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-spq(5) 1 } smime(16) id-spq(5) 1 }
skipping to change at page 37, line 5 skipping to change at page 37, line 5
December 2049 (inclusive) MUST be encoded as UTCTime. Any dates December 2049 (inclusive) MUST be encoded as UTCTime. Any dates
with year values before 1950 or after 2049 MUST be encoded as with year values before 1950 or after 2049 MUST be encoded as
GeneralizedTime. GeneralizedTime.
5.9.2 Countersignature 5.9.2 Countersignature
The counterSignature attribute values for ES have ASN.1 type The counterSignature attribute values for ES have ASN.1 type
CounterSignature as defined in CMS (RFC 3852 [4]). A counterSignature CounterSignature as defined in CMS (RFC 3852 [4]). A counterSignature
attribute shall be an unsigned attribute. attribute shall be an unsigned attribute.
Internet-draft CMS Advanced Electronic Signatures September 2007
5.10 ESS imported optional attributes 5.10 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
the present document. The attributes are defined in ESS and are the present document. The attributes are defined in ESS and are
imported into the present document and were appropriate qualified and imported into the present document and were appropriate qualified and
profiled by the present document. profiled by the present document.
5.10.1 Content reference attribute 5.10.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
skipping to change at page 38, line 5 skipping to change at page 38, line 5
the user the following rules apply: the user the following rules apply:
- the contentType indicates the type of the associated content. It - the contentType indicates the type of the associated content. It
is an object identifier (i.e. a unique string of integers) is an object identifier (i.e. a unique string of integers)
assigned by an authority that defines the content type; and assigned by an authority that defines the content type; and
- when the contentType is id-data the contentDescription shall - when the contentType is id-data the contentDescription shall
define the presentation format, the format may be defined by MIME define the presentation format, the format may be defined by MIME
types. types.
Internet-draft CMS Advanced Electronic Signatures September 2007
When the format of the content is defined by MIME types the following When the format of the content is defined by MIME types the following
rules apply: rules apply:
- the contentType shall be id-data as defined in CMS (RFC 3852 - the contentType shall be id-data as defined in CMS (RFC 3852
[4]); [4]);
- the contentDescription shall be used to indicate the encoding of - the contentDescription shall be used to indicate the encoding of
the data in accordance with the rules defined RFC 2045 [6], see the data in accordance with the rules defined RFC 2045 [6], see
annex F for an example structured contents and MIME. annex F for an example structured contents and MIME.
skipping to change at page 39, line 5 skipping to change at page 39, line 5
precise semantics defined by registration, under the rules of the precise semantics defined by registration, under the rules of the
registration authority. Such a registration authority may be a registration authority. Such a registration authority may be a
trading association or a legislative authority. trading association or a legislative authority.
The signature policy specifies a set of attributes that it The signature policy specifies a set of attributes that it
"recognizes". This "recognized" set includes all those commitment "recognizes". This "recognized" set includes all those commitment
types defined as part of the signature policy as well as any externally types defined as part of the signature policy as well as any externally
defined commitment types that the policy may choose to recognize. Only defined commitment types that the policy may choose to recognize. Only
recognized commitment types are allowed in this field. recognized commitment types are allowed in this field.
Internet-draft CMS Advanced Electronic Signatures September 2007
The following object identifier identifies the commitment-type- The following object identifier identifies the commitment-type-
indication attribute: indication attribute:
id-aa-ets-commitmentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-aa-ets-commitmentType OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 16} us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 16}
commitment-type-indication attribute values have ASN.1 type commitment-type-indication attribute values have ASN.1 type
CommitmentTypeIndication. CommitmentTypeIndication.
CommitmentTypeIndication ::= SEQUENCE { CommitmentTypeIndication ::= SEQUENCE {
skipping to change at page 40, line 5 skipping to change at page 40, line 5
cti(6) 6} cti(6) 6}
These generic commitment types have the following meaning: These generic commitment types have the following meaning:
Proof of origin indicates that the signer recognizes to have created, Proof of origin indicates that the signer recognizes to have created,
approved and sent the message. approved and sent the message.
Proof of receipt indicates that signer recognizes to have received the Proof of receipt indicates that signer recognizes to have received the
content of the message. content of the message.
Internet-draft CMS Advanced Electronic Signatures September 2007
Proof of delivery indicates that the TSP providing that indication has Proof of delivery indicates that the TSP providing that indication has
delivered a message in a local store accessible to the recipient of the delivered a message in a local store accessible to the recipient of the
message. message.
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.
skipping to change at page 41, line 5 skipping to change at page 41, line 5
It may be either: It may be either:
- claimed attributes of the signer; or - claimed attributes of the signer; or
- certified attributes of the signer. - certified attributes of the signer.
The signer-attributes attribute shall be a signed attribute. The signer-attributes attribute shall be a signed attribute.
The following object identifier identifies the signer-attribute The following object identifier identifies the signer-attribute
attribute: attribute:
Internet-draft CMS Advanced Electronic Signatures September 2007
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-attributes values have ASN.1 type SignerAttribute: signer-attributes 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 }
ClaimedAttributes ::= SEQUENCE OF Attribute ClaimedAttributes ::= SEQUENCE OF Attribute
skipping to change at page 42, line 5 skipping to change at page 42, line 5
5.12 Support for multiple signatures 5.12 Support for multiple signatures
5.12.1 Independent signatures 5.12.1 Independent signatures
Multiple independent signatures (see section B.5) are supported by Multiple independent signatures (see section B.5) are supported by
independent SignerInfo from each signer. independent SignerInfo from each signer.
Each SignerInfo shall include all the attributes required under the Each SignerInfo shall include all the attributes required under the
present document and shall be processed independently by the verifier. present document and shall be processed independently by the verifier.
Internet-draft CMS Advanced Electronic Signatures September 2007
Note: Independent signatures may be used to provide independent Note: Independent signatures may be used to provide independent
signatures from different parties with different signed attributes, or signatures from different parties with different signed attributes, or
to provide multiple signatures from the same party using alternative to provide multiple signatures from the same party using alternative
signature algorithms in which case the other attributes, excluding signature algorithms in which case the other attributes, excluding
time values and signature policy information, will generally be the time values and signature policy information, will generally be the
same. same.
5.12.2 Embedded signatures 5.12.2 Embedded signatures
Multiple embedded signatures (see section C.5) are supported using the Multiple embedded signatures (see section C.5) are supported using the
skipping to change at page 43, line 4 skipping to change at page 43, line 4
In addition the following optional eXtended forms of validation data In addition the following optional eXtended forms of validation data
are also defined, see annex B for an overview the eXtended forms of are also defined, see annex B for an overview the eXtended forms of
validation data: validation data:
- CAdES-X with time stamp: there are two types of time-stamp used - CAdES-X with time stamp: there are two types of time-stamp used
in extended validation data defined by the present document: in extended validation data defined by the present document:
- Type 1(CAdES-X Type 1): comprises a time-stamp over the ES - Type 1(CAdES-X Type 1): comprises a time-stamp over the ES
with complete validation data (CAdES-C); and with complete validation data (CAdES-C); and
Internet-draft CMS Advanced Electronic Signatures September 2007
- Type 2 (CAdES-X Type2): comprises a time-stamp over the - Type 2 (CAdES-X Type2): comprises a time-stamp over the
certification path references and the revocation information certification path references and the revocation information
references used to support the CAdES-C. references used to support the CAdES-C.
NOTE 3: Formats for CAdES-X Type 1 and CAdES-X Type 2 are illustrated NOTE 3: Formats for CAdES-X Type 1 and CAdES-X Type 2 are illustrated
in sections B.1.2 and B.1.3, respectively. in sections B.1.2 and B.1.3, respectively.
- CAdES-X Long :comprises the complete validation data references - CAdES-X Long :comprises the complete validation data references
(CAdES-C) plus the actual values of all the certificates and (CAdES-C) plus the actual values of all the certificates and
revocation information used in the CAdES-C. revocation information used in the CAdES-C.
skipping to change at page 44, line 5 skipping to change at page 44, line 5
NOTE 6: the optional attributes of the extended validation data are NOTE 6: the optional attributes of the extended validation data are
defined in sections 6.3 and 6.4. defined in sections 6.3 and 6.4.
6.1 Electronic Signature Time-stamped (CAdES-T) 6.1 Electronic Signature Time-stamped (CAdES-T)
An Electronic Signature with time-stamp is an electronic signature for An Electronic Signature with time-stamp 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 are is available (i.e. some certificates and revocation information are
available but not all). available but not all).
Internet-draft CMS Advanced Electronic Signatures September 2007
The minimum structure time-stamp validation data is: The minimum structure time-stamp validation data is:
- the Signature Time-stamp Attribute as defined in section 6.1.1 - the Signature Time-stamp Attribute as defined in section 6.1.1
over the ES signature value. over the ES signature value.
6.1.1 Signature time- stamp attribute definition 6.1.1 Signature time- stamp attribute definition
The signature-time-stamp attribute is a TimeStampToken computed on the The signature-time-stamp attribute is a TimeStampToken computed on the
signature value for a specific signer. It is an unsigned attribute. signature value for a specific signer. It is an unsigned attribute.
Several instances of this attribute may occur with an electronic Several instances of this attribute may occur with an electronic
skipping to change at page 45, line 4 skipping to change at page 45, line 4
An electronic signature with complete validation data references An electronic signature with complete validation data references
(CAdES-C) is an Electronic Signature for which all the additional data (CAdES-C) is an Electronic Signature for which all the additional data
required for validation (i.e. all certificates and revocation required for validation (i.e. all certificates and revocation
information) is available. This form is built on the CAdES-T form information) is available. This form is built on the CAdES-T form
defined above. defined above.
As a minimum, the complete validation data shall include the following: As a minimum, the complete validation data shall include the following:
- a time, which shall either be a signature-timestamp attribute, as - a time, which shall either be a signature-timestamp attribute, as
defined in section 6.1.1, or a time mark operated by a Time- defined in section 6.1.1, or a time mark operated by a Time-
Marking Authority; Marking Authority;
Internet-draft CMS Advanced Electronic Signatures September 2007
- complete-certificate-references, as defined in section 6.2.1; - complete-certificate-references, as defined in section 6.2.1;
- complete-revocation-references , as defined in section 6.2.2. - complete-revocation-references , as defined in section 6.2.2.
6.2.1 Complete certificate references attribute definition 6.2.1 Complete certificate references attribute definition
The complete-certificate-references attribute is an unsigned attribute. The complete-certificate-references attribute is an unsigned attribute.
It references the full set of CA certificates that have been used to It references the full set of CA certificates that have been used to
validate an ES with Complete validation data up to (but not including) validate an ES with Complete validation data up to (but not including)
the signer's certificate. Only a single instance of this attribute the signer's certificate. Only a single instance of this attribute
skipping to change at page 46, line 5 skipping to change at page 46, line 5
This attribute can be used to illustrate that the verifier has taken This attribute can be used to illustrate that the verifier has taken
due diligence of the available revocation information and then to be due diligence of the available revocation information and then to be
able to retrieve that information when stored elsewhere. able to retrieve that information when stored elsewhere.
The following object identifier identifies the complete-revocation- The following object identifier identifies the complete-revocation-
references attribute: references 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 CMS Advanced Electronic Signatures September 2007
The complete-revocation-references attribute value has the ASN.1 syntax The complete-revocation-references 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
} }
skipping to change at page 47, line 5 skipping to change at page 47, line 5
When creating a crlValidatedID, the crlHash is computed over the entire When creating a crlValidatedID, the crlHash is computed over the entire
DER encoded CRL including the signature. The crlIdentifier would 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.
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 shall correspond to the time thisUpdate CRL issued time, which shall correspond to the time thisUpdate
contained in the issued CRL, and if present, the crlNumber. The contained in the issued CRL, and if present, the crlNumber. The
Internet-draft CMS Advanced Electronic Signatures September 2007
crlListID attribute is an unsigned attribute. In the case that the crlListID attribute is an unsigned attribute. In the case that the
identified CRL is a Delta CRL then references to the set of CRLs to identified CRL is a Delta CRL then references to the set of CRLs to
provide a complete revocation list shall be included. provide a complete revocation list shall be included.
The OcspIdentifier is to identify the OCSP response using the issuer The OcspIdentifier is to identify the OCSP response using the issuer
name and the time of issue of the OCSP response which shall correspond name and the time of issue of the OCSP response which shall correspond
to the time producedAt contained in the issued OCSP response. Since it to the time producedAt contained in the issued OCSP response. Since it
may be needed to make the difference between two OCSP responses may be needed to make the difference between two OCSP responses
received within the same second, then the hash of the response received within the same second, then the hash of the response
contained in the OcspResponsesID may be needed to solve the ambiguity. contained in the OcspResponsesID may be needed to solve the ambiguity.
skipping to change at page 48, line 5 skipping to change at page 48, line 5
The attribute-certificate-references attribute value has the ASN.1 The attribute-certificate-references attribute value has the ASN.1
syntax AttributeCertificateRefs: syntax AttributeCertificateRefs:
AttributeCertificateRefs ::= SEQUENCE OF OtherCertID AttributeCertificateRefs ::= SEQUENCE OF OtherCertID
OtherCertID is defined in section 5.8.2. OtherCertID is defined in section 5.8.2.
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 section 6.3.3. certificate-values attribute defined in section 6.3.3.
Internet-draft CMS Advanced Electronic Signatures September 2007
6.2.4 Attribute revocation references attribute definition 6.2.4 Attribute revocation references attribute definition
This attribute is only used when a user attribute certificate is This attribute is only used when a user attribute certificate is
present in the electronic signature and when that attribute certificate present in the electronic signature and when that attribute certificate
can be revoked. can be revoked.
The attribute-revocation-references attribute is an unsigned attribute. The attribute-revocation-references attribute is an unsigned attribute.
Only a single instance of this attribute shall occur with an Only a single instance of this attribute shall occur with an
electronic signature. It references the full set of the ACRL or OCSP electronic signature. It references the full set of the ACRL or OCSP
responses that have been used in the validation of the attribute responses that have been used in the validation of the attribute
skipping to change at page 49, line 5 skipping to change at page 49, line 5
- Time-Stamped Certificates and CRLs references, as defined in - Time-Stamped Certificates and CRLs references, as defined in
section 6.3.6 (CAdES-X Type 2). section 6.3.6 (CAdES-X Type 2).
6.3.2 Long validation data (CAdES-X Long, CAdES-X Long Type 1 or 2) 6.3.2 Long validation data (CAdES-X Long, CAdES-X Long Type 1 or 2)
The extended validation data may also include the following additional The extended validation data may also include the following additional
information, forming a CAdES-X Long, for use if later validation information, forming a CAdES-X Long, for use if later validation
processes may not have access to this information: processes may not have access to this information:
Internet-draft CMS Advanced Electronic Signatures September 2007
- certificate-values as defined in section 6.3.3; and - certificate-values as defined in section 6.3.3; and
- revocation-values as defined in section 6.3.4. - revocation-values as defined in section 6.3.4.
The extended validation data may in addition to certificate-values and The extended validation data may in addition to certificate-values and
revocation-values as defined in sections 6.3.3 and 6.3.4 include one of revocation-values as defined in sections 6.3.3 and 6.3.4 include one of
the following additional attributes, forming an CAdES-X Long Type 1 or the following additional attributes, forming an CAdES-X Long Type 1 or
CAdES-X Long Type 2. CAdES-X Long Type 2.
- CAdES-C Time-stamp, as defined in section 6.3.3 (CAdES-X long - CAdES-C Time-stamp, as defined in section 6.3.3 (CAdES-X long
Type 1); or Type 1); or
skipping to change at page 50, line 5 skipping to change at page 50, line 5
NOTE: If an attribute certificate is used, it is not provided in this NOTE: If an attribute certificate is used, it is not provided in this
structure but shall be provided by the signer as a signer- structure but shall be provided by the signer as a signer-
attributes attribute (see section 5.11.3). attributes attribute (see section 5.11.3).
The following object identifier identifies the certificate-values The following object identifier identifies the certificate-values
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}
Internet-draft CMS Advanced Electronic Signatures September 2007
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 section 7.1. (which is as defined in ITU-T Certificate is defined in section 7.1. (which is as defined in ITU-T
Recommendation X.509 [1]. Recommendation X.509 [1].
This attribute may include the certification information for any TSUs This attribute may include the certification information for any TSUs
that have provided the time-stamp tokens if these certificates are not that have provided the time-stamp tokens if these certificates are not
skipping to change at page 51, line 5 skipping to change at page 51, line 5
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 (OtherRevVals) The syntax and semantics of the other revocation values (OtherRevVals)
is outside the scope of the present document. is outside the scope of the present document.
Internet-draft CMS Advanced Electronic Signatures September 2007
The definition of the syntax of the other form of revocation The definition of the syntax of the other form of revocation
information is as identified by OtherRevRefType. information is as identified by OtherRevRefType.
CertificateList is defined in section 7.2. (which as defined in ITU-T CertificateList is defined in section 7.2. (which as defined in ITU-T
Recommendation X.509 [1]). Recommendation X.509 [1]).
BasicOCSPResponse is defined in section 7.3. (which as defined in BasicOCSPResponse is defined in section 7.3. (which as defined in
RFC 2560 [3]). RFC 2560 [3]).
This attribute may include the values of revocation data including CRLs This attribute may include the values of revocation data including CRLs
skipping to change at page 52, line 5 skipping to change at page 52, line 5
The CAdES-C-timestamp attribute value has the ASN.1 syntax The CAdES-C-timestamp attribute value has the ASN.1 syntax
ESCTimeStampToken : ESCTimeStampToken :
ESCTimeStampToken ::= TimeStampToken ESCTimeStampToken ::= TimeStampToken
The value of messageImprint field within TimeStampToken shall be a hash The value of messageImprint field within TimeStampToken shall 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: that value) of the following data objects:
Internet-draft CMS Advanced Electronic Signatures September 2007
- OCTETSTRING of the SignatureValue field within SignerInfo; - OCTETSTRING of the SignatureValue field within SignerInfo;
- signature-time-stamp, or a time mark operated by a Time-Marking - signature-time-stamp, or a time mark operated by a Time-Marking
Authority; Authority;
- complete-certificate-references s attribute; and - complete-certificate-references s attribute; and
- complete-revocation-references attribute. - complete-revocation-references attribute.
For further information and definition of the TimeStampToken, see For further information and definition of the TimeStampToken, see
skipping to change at page 53, line 5 skipping to change at page 53, line 5
The value of messageImprint field within TimeStampToken shall be a hash The value of messageImprint field within TimeStampToken shall 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 (CAdES-C): Complete validation data (CAdES-C):
- complete-certificate-references attribute; and - complete-certificate-references attribute; and
- complete-revocation-references attribute. - complete-revocation-references attribute.
Internet-draft CMS Advanced Electronic Signatures September 2007
6.4 Archive validation data 6.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 time-stamp token on an electronic signature is in danger of and a the time-stamp token on an electronic signature is in danger of
being invalidated due to algorithm weakness or limits in the validity being invalidated due to algorithm weakness or limits in the validity
period of the TSA certificate, then it may be required to time-stamp period of the TSA certificate, then it may be required to time-stamp
the electronic signature several times. When this is required an the electronic signature several times. When this is required an
archive time-stamp attribute may be required for the archive form of archive time-stamp attribute may be required for the archive form of
electronic signature (CAdES-A). This archive time-stamp attribute may electronic signature (CAdES-A). This archive time-stamp attribute may
be repeatedly applied over a period of time. be repeatedly applied over a period of time.
skipping to change at page 53, line 31 skipping to change at page 53, line 33
the CAdES-BES or CAdES-EPES, then they shall be added to the electronic the CAdES-BES or CAdES-EPES, then they shall be added to the electronic
signature prior to computing the archive time-stamp token. signature prior to computing the archive time-stamp token.
The archive-time-stamp attribute is an unsigned attribute. Several The archive-time-stamp attribute is an unsigned attribute. Several
instances of this attribute may occur with an electronic signature instances of this attribute may occur with an electronic signature
both over time and from different TSUs. both over time and from different TSUs.
The following object identifier identifies the nested The following object identifier identifies the nested
archive-time-stamp attribute: archive-time-stamp attribute:
id-aa-ets-archiveTimestamp OBJECT IDENTIFIER ::= id-aa-ets-archiveTimestampV2 OBJECT IDENTIFIER ::=
{ 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) id-aa(2) 48} smime(16) id-aa(2) 48}
Archive-time-stamp attribute values have the ASN.1 syntax Archive-time-stamp attribute values have the ASN.1 syntax
ArchiveTimeStampToken ArchiveTimeStampToken
ArchiveTimeStampToken ::= TimeStampToken ArchiveTimeStampToken ::= TimeStampToken
The value of messageImprint field within TimeStampToken shall be a hash The value of messageImprint field within TimeStampToken shall be a hash
of the concatenation of: of the concatenation of:
skipping to change at page 53, line 57 skipping to change at page 53, line 59
- When present, the Certificates and crls elements of the - When present, the Certificates and crls elements of the
SignedData sequence; and SignedData sequence; and
- Together with all data elements in the SignerInfo sequence - Together with all data elements in the SignerInfo sequence
including all signed and unsigned attributes. including all signed and unsigned attributes.
NOTE 1: An alternative archiveTimestamp attribute, identified by NOTE 1: An alternative archiveTimestamp attribute, identified by
object identifier { iso(1) member-body(2) us(840) object identifier { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 27, is rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 27, is
defined in prior versions of TS 101 733. The archiveTimestamp defined in prior versions of TS 101 733 and in RFC 3126.
attribute defined in versions of TS 101 733 prior to 1.5.1 is
not compatible with the attribute defined in the current Internet-draft CMS Advanced Electronic Signatures September 2007
document. The archiveTimestamp attribute defined in versions
1.5.1 to 1.7.3 of TS 101 733 is compatible with current The archiveTimestamp attribute defined in versions of
document if the content is internal to encapContentInfo. TS 101 733 prior to 1.5.1 and in RFC 3126 is not compatible
Unless the version of TS 101 733 employed by the signing party with the attribute defined in the current document. The
is known by all recipients, use of the archiveTimestamp archiveTimestamp attribute defined in versions 1.5.1 to 1.7.3
attribute defined in prior versions of TS 101 733 is of TS 101 733 is compatible with the current document if the
deprecated. content is internal to encapContentInfo. Unless the version
of TS 101 733 employed by the signing party is known by all
recipients, use of the archiveTimestamp attribute defined in
prior versions of TS 101 733 is deprecated.
NOTE 2: Counter signatures held as countersignature attributes do not NOTE 2: Counter signatures held as countersignature attributes do not
require independent archive time-stamps as they are protected require independent archive time-stamps as they are protected
by the archive time-stamp against the containing signedData by the archive time-stamp against the containing signedData
structure. structure.
NOTE 3: Unless DER is used throughout, it is recommended that the NOTE 3: Unless DER is used throughout, it is recommended that the
binary encoding of the ASN.1 structures being time-stamped are binary encoding of the ASN.1 structures being time-stamped are
preserved when being archived to ensure that the recalculation preserved when being archived to ensure that the recalculation
of the data hash is consistent. of the data hash is consistent.
skipping to change at page 55, line 5 skipping to change at page 55, line 5
- Adding the complete-certificate-references attribute and the - Adding the complete-certificate-references attribute and the
complete-revocation-references attribute of the TSP as an complete-revocation-references attribute of the TSP as an
unsigned attribute within TimeStampToken, when the required unsigned attribute within TimeStampToken, when the required
information is store elsewhere; or information is store elsewhere; or
- Adding the certificate-values attribute and the revocation-values - Adding the certificate-values attribute and the revocation-values
attribute of the TSP as an unsigned attribute within attribute of the TSP as an unsigned attribute within
TimeStampToken, when the required information is store elsewhere. TimeStampToken, when the required information is store elsewhere.
Internet-draft CMS Advanced Electronic Signatures September 2007
7 Other standard data structures 7 Other standard data structures
7.1 Public-key certificate format 7.1 Public-key certificate format
The X.509 v3 certificate basis syntax is defined in ITU-T The X.509 v3 certificate basis syntax is defined in ITU-T
Recommendation X.509 [1]. A profile of the X.509 v3 certificate is Recommendation X.509 [1]. A profile of the X.509 v3 certificate is
defined in RFC 3280 [2]. defined in RFC 3280 [2].
7.2 Certificate revocation list format 7.2 Certificate revocation list format
skipping to change at page 56, line 5 skipping to change at page 56, line 5
The distinguished name shall include identifiers for the organization The distinguished name shall include identifiers for the organization
providing the service and the legal jurisdiction (e.g. country) under providing the service and the legal jurisdiction (e.g. country) under
which it operates. which it operates.
Where a signer signs as an individual but wishes to also identify Where a signer signs as an individual but wishes to also identify
him/herself as acting on behalf of an organization, it may be necessary him/herself as acting on behalf of an organization, it may be necessary
to provide two independent forms of identification. The first to provide two independent forms of identification. The first
identity, with is directly associated with the signing key identifies identity, with is directly associated with the signing key identifies
Internet-draft CMS Advanced Electronic Signatures September 2007
him/her as an individual. The second, which is managed independently, him/her as an individual. The second, which is managed independently,
identifies that person acting as part of the organization, possibly identifies that person acting as part of the organization, possibly
with a given role. In this case one of the two identities is carried with a given role. In this case one of the two identities is carried
in the subject/subjectAltName field of the signer's certificate as in the subject/subjectAltName field of the signer's certificate as
described above. described above.
The present document does not specify the format of signer's attribute The present document does not specify the format of signer's attribute
that may be included in public key certificates. that may be included in public key certificates.
NOTE : Signer's attribute may be supported by using a claimed role in NOTE : Signer's attribute may be supported by using a claimed role in
skipping to change at page 57, line 4 skipping to change at page 57, line 4
A system supporting CAdES-BES signers according to the present A system supporting CAdES-BES signers according to the present
document shall, at a minimum, support generation of an electronic document shall, at a minimum, support generation of an electronic
signature consisting of the following components: signature consisting of the following components:
- The general CMS syntax and content type as defined in RFC 3852 - The general CMS syntax and content type as defined in RFC 3852
[4] (see sections 5.1 and 5.2); [4] (see sections 5.1 and 5.2);
- CMS SignedData as defined in RFC 3852 [4] with version set to 3 - CMS SignedData as defined in RFC 3852 [4] with version set to 3
and at least one SignerInfo shall be present (see sections 5.3 to and at least one SignerInfo shall be present (see sections 5.3 to
5.6); 5.6);
Internet-draft CMS Advanced Electronic Signatures September 2007
- The following CMS attributes as defined in RFC 3852 [4]: - The following CMS attributes as defined in RFC 3852 [4]:
- content-type; this shall always be present - content-type; this shall always be present
(see section 5.7.1); and (see section 5.7.1); and
- message-digest; this shall always be present (see section - message-digest; this shall always be present (see section
5.7.2). 5.7.2).
- One of following attributes as defined in the present document: - One of following attributes as defined in the present document:
skipping to change at page 58, line 4 skipping to change at page 58, line 4
- complete-revocation-references attribute, as defined in - complete-revocation-references attribute, as defined in
section 6.2.2; section 6.2.2;
- Public Key Certificates, as defined in ITU-T Recommendation X.509 - Public Key Certificates, as defined in ITU-T Recommendation X.509
[1] (see section 8.1); and [1] (see section 8.1); and
- either of: - either of:
- Certificate Revocation Lists. as defined in ITU-T - Certificate Revocation Lists. as defined in ITU-T
Recommendation X.509 [1] (see section 8.2); or Recommendation X.509 [1] (see section 8.2); or
Internet-draft CMS Advanced Electronic Signatures September 2007
- on-line Certificate Status Protocol, as defined in RFC 2560 - on-line Certificate Status Protocol, as defined in RFC 2560
[3] (see section 8.3). [3] (see section 8.3).
8.4 Verification using secure records 8.4 Verification using secure records
A system supporting verifiers according to the present document shall, A system supporting verifiers according to the present document shall,
at a minimum, support: at a minimum, support:
- verification of the mandated components of an electronic - verification of the mandated components of an electronic
signature, as defined in section 8.1; signature, as defined in section 8.1;
skipping to change at page 59, line 5 skipping to change at page 59, line 5
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 cryptographic algorithm will reduce. Therefore, cryptographic
algorithm implementations should be modular allowing new algorithms to algorithm implementations should be modular allowing new algorithms to
be readily inserted. That is, implementers should be prepared for the be readily inserted. That is, implementers should be prepared for the
set of mandatory to implement algorithms to change over time. set of mandatory to implement algorithms to change over time.
Internet-draft CMS Advanced Electronic Signatures September 2007
10. IANA Considerations 10. IANA Considerations
No IANA actions required. No IANA actions required.
11. References 11. References
11.1 Normative references 11.1 Normative references
[1] ITU-T Recommendation X.509 (2000)/ISO/IEC 9594-8 (2001): [1] ITU-T Recommendation X.509 (2000)/ISO/IEC 9594-8 (2001):
"Information technology - Open Systems Interconnection - "Information technology - Open Systems Interconnection -
skipping to change at page 60, line 5 skipping to change at page 60, line 5
[12] ITU-T Recommendation X.500: "Information technology - Open [12] ITU-T Recommendation X.500: "Information technology - Open
Systems Interconnection - The Directory: Overview of Systems Interconnection - The Directory: Overview of
concepts, models and services". concepts, models and services".
[13] IETF RFC 3281 (2002): "An Internet Attribute Certificate [13] IETF RFC 3281 (2002): "An Internet Attribute Certificate
Profile for Authorization". Profile for Authorization".
[14] ITU-T Recommendation X.208 (1988): "Specification of Abstract [14] ITU-T Recommendation X.208 (1988): "Specification of Abstract
Syntax Notation One (ASN.1)". Syntax Notation One (ASN.1)".
Internet-draft CMS Advanced Electronic Signatures September 2007
[15] IETF RFC 5035 (2007). ESS Update: Adding CertID Algorithm [15] IETF RFC 5035 (2007). ESS Update: Adding CertID Algorithm
Agility. Agility.
11.2 Informative references 11.2 Informative references
ETSI technical specifications can be downloaded free of charge ETSI technical specifications can be downloaded free of charge
via the Services and Products Download Area at: via the Services and Products Download Area at:
http://www.etsi.org/services_products/freestandard/home.htm http://www.etsi.org/services_products/freestandard/home.htm
[EU Directive] Directive 1999/93/EC of the European Parliament and [EU Directive] Directive 1999/93/EC of the European Parliament and
skipping to change at page 61, line 5 skipping to change at page 61, line 5
Infrastructure Operational Protocols - LDAPv2". Infrastructure Operational Protocols - LDAPv2".
[RFC2587] IETF RFC 2587 (1999): "Internet X.509 Public Key [RFC2587] IETF RFC 2587 (1999): "Internet X.509 Public Key
Infrastructure LDAPv2 Schema". Infrastructure LDAPv2 Schema".
[RFC3125] IETF RFC 3125 (2000): "Electronic Signature Policies". [RFC3125] IETF RFC 3125 (2000): "Electronic Signature Policies".
[RFC3851] IETF RFC 3851 (2004): “SMIME Version 3.1 Message [RFC3851] IETF RFC 3851 (2004): “SMIME Version 3.1 Message
Specification”. Specification”.
Internet-draft CMS Advanced Electronic Signatures September 2007
[ISO7498-2] ISO 7498-2 (1989): "Information processing systems – [ISO7498-2] ISO 7498-2 (1989): "Information processing systems –
Open Systems Interconnection - Basic Reference Model - Part 2: Open Systems Interconnection - Basic Reference Model - Part 2:
Security Architecture". Security Architecture".
[ISO9796-2] ISO/IEC 9796-2 (2002): "Information technology – [ISO9796-2] ISO/IEC 9796-2 (2002): "Information technology –
Security techniques - Digital signature schemes giving message Security techniques - Digital signature schemes giving message
recovery - Part 2: Integer factorization based mechanisms". recovery - Part 2: Integer factorization based mechanisms".
[ISO9796-4] ISO/IEC 9796-4 (1998): "Digital signature schemes [ISO9796-4] ISO/IEC 9796-4 (1998): "Digital signature schemes
giving message recovery - Part 4: Discrete logarithm based giving message recovery - Part 4: Discrete logarithm based
skipping to change at page 62, line 5 skipping to change at page 62, line 5
Certificate-based mechanisms". Certificate-based mechanisms".
[ISO15946-2] ISO/IEC 15946-2 (2002): "Information technology – [ISO15946-2] ISO/IEC 15946-2 (2002): "Information technology –
Security techniques - Cryptographic techniques based on elliptic Security techniques - Cryptographic techniques based on elliptic
curves - Part 2: Digital signatures". curves - Part 2: Digital signatures".
[ISO15946-3] ISO/IEC 15946-3 (2002): "Information technology – [ISO15946-3] ISO/IEC 15946-3 (2002): "Information technology –
Security techniques - Cryptographic techniques based on elliptic Security techniques - Cryptographic techniques based on elliptic
curves - Part 3: Key establishment". curves - Part 3: Key establishment".
Internet-draft CMS Advanced Electronic Signatures September 2007
[X690] ITU-T Recommendation X.690 (2002): "Specification of basic [X690] ITU-T Recommendation X.690 (2002): "Specification of basic
encoding rules for Abstract Syntax Notation One (ASN.1)". encoding rules for Abstract Syntax Notation One (ASN.1)".
[CWA14171] CWA 14171 CEN Workshop Agreements: "General Guidelines [CWA14171] CWA 14171 CEN Workshop Agreements: "General Guidelines
for Electronic Signature Verification". for Electronic Signature Verification".
[XMLDSIG] XMLDSIG: W3C/IETF Recommendation (February 2002): [XMLDSIG] XMLDSIG: W3C/IETF Recommendation (February 2002):
"XML-Signature Syntax and Processing". "XML-Signature Syntax and Processing".
[X9.30-1] ANSI X9.30-1 (1997): "Public Key Cryptography for the [X9.30-1] ANSI X9.30-1 (1997): "Public Key Cryptography for the
skipping to change at page 63, line 4 skipping to change at page 63, line 4
Nick Pope Nick Pope
Thales eSecurity Thales eSecurity
Meadow View House Meadow View House
Long Crendon Long Crendon
Aylesbury Aylesbury
Buck Buck
HP18 9EQ HP18 9EQ
United Kingdom United Kingdom
EMail: nick.pope@thales-esecurity.com EMail: nick.pope@thales-esecurity.com
Internet-draft CMS Advanced Electronic Signatures September 2007
John Ross John Ross
Security & Standards Consultancy Ltd Security & Standards Consultancy Ltd
The Waterhouse Business Centre The Waterhouse Business Centre
2 Cromer Way 2 Cromer Way
Chelmsford Chelmsford
Essex Essex
CM1 2QE CM1 2QE
United Kingdom United Kingdom
EMail: ross@secstan.com EMail: ross@secstan.com
13. Acknowledgments 13. Acknowledgments
Special thanks to Russ Housley for reviewing the document. Special thanks to Russ Housley for reviewing the document.
Internet-draft CMS Advanced Electronic Signatures September 2007
Annex A (normative): ASN.1 definitions 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 the present document. new syntax defined in the present document.
A.1 Signature format definitions using X.208 ASN.1 syntax A.1 Signature format definitions using X.208 ASN.1 syntax
NOTE: The ASN.1 module defined in section A.1 using syntax defined in NOTE: The ASN.1 module defined in section A.1 using syntax defined in
ITU-T Recommendation X.208 [14] has precedence over that ITU-T Recommendation X.208 [14] has precedence over that
defined in section A.2 in the case of any conflict. defined in section A.2 in the case of any conflict.
skipping to change at page 65, line 4 skipping to change at page 65, line 4
pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-ess-2006(30) } pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-ess-2006(30) }
-- Internet X.509 Public Key Infrastructure - Certificate and CRL -- Internet X.509 Public Key Infrastructure - Certificate and CRL
-- Profile: RFC 3280 -- Profile: RFC 3280
Certificate, AlgorithmIdentifier, CertificateList, Name, Certificate, AlgorithmIdentifier, CertificateList, Name,
DirectoryString, Attribute, BMPString, UTF8String DirectoryString, Attribute, BMPString, UTF8String
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(18)} security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18)}
Internet-draft CMS Advanced Electronic Signatures September 2007
GeneralNames, GeneralName, PolicyInformation GeneralNames, GeneralName, PolicyInformation
FROM PKIX1Implicit88 FROM PKIX1Implicit88
{iso(1) identified-organization(3) dod(6) internet(1) security(5) {iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit (19)} mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit (19)}
-- Internet Attribute Certificate Profile for Authorization - RFC 3281 -- Internet Attribute Certificate Profile for Authorization - RFC 3281
AttributeCertificate AttributeCertificate
FROM PKIXAttributeCertificate {iso(1) identified-organization(3) FROM PKIXAttributeCertificate {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) dod(6) internet(1) security(5) mechanisms(5) pkix(7)
skipping to change at page 66, line 4 skipping to change at page 66, line 4
etsiESv1(1) } etsiESv1(1) }
-- Basic ES CMS Attributes Defined in the present document -- Basic ES CMS Attributes Defined in the present document
-- ======================================================= -- =======================================================
-- OtherSigningCertificate - deprecated -- OtherSigningCertificate - deprecated
id-aa-ets-otherSigCert OBJECT IDENTIFIER ::= id-aa-ets-otherSigCert OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-aa(2) 19 } smime(16) id-aa(2) 19 }
Internet-draft CMS Advanced Electronic Signatures September 2007
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 THE PRESENT DOCUMENT -- NOT USED IN THE PRESENT DOCUMENT
} }
OtherCertID ::= SEQUENCE { OtherCertID ::= SEQUENCE {
otherCertHash OtherHash, otherCertHash OtherHash,
issuerSerial IssuerSerial OPTIONAL } issuerSerial IssuerSerial OPTIONAL }
skipping to change at page 67, line 4 skipping to change at page 67, line 4
SignaturePolicyImplied ::= NULL SignaturePolicyImplied ::= NULL
SigPolicyId ::= OBJECT IDENTIFIER SigPolicyId ::= OBJECT IDENTIFIER
SigPolicyHash ::= OtherHashAlgAndValue SigPolicyHash ::= OtherHashAlgAndValue
OtherHashAlgAndValue ::= SEQUENCE { OtherHashAlgAndValue ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier, hashAlgorithm AlgorithmIdentifier,
hashValue OtherHashValue } hashValue OtherHashValue }
Internet-draft CMS Advanced Electronic Signatures September 2007
OtherHashValue ::= OCTET STRING OtherHashValue ::= OCTET STRING
SigPolicyQualifierInfo ::= SEQUENCE { SigPolicyQualifierInfo ::= SEQUENCE {
sigPolicyQualifierId SigPolicyQualifierId, sigPolicyQualifierId SigPolicyQualifierId,
sigQualifier ANY DEFINED BY sigPolicyQualifierId } sigQualifier ANY DEFINED BY sigPolicyQualifierId }
SigPolicyQualifierId ::= OBJECT IDENTIFIER SigPolicyQualifierId ::= OBJECT IDENTIFIER
id-spq-ets-uri OBJECT IDENTIFIER ::= id-spq-ets-uri OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
skipping to change at page 68, line 5 skipping to change at page 68, line 5
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-body(2) id-cti-ets-proofOfOrigin OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 1} us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 1}
Internet-draft CMS Advanced Electronic Signatures September 2007
id-cti-ets-proofOfReceipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-cti-ets-proofOfReceipt OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 2} us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 2}
id-cti-ets-proofOfDelivery OBJECT IDENTIFIER ::= id-cti-ets-proofOfDelivery OBJECT IDENTIFIER ::=
{ 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) cti(6) 3} smime(16) cti(6) 3}
id-cti-ets-proofOfSender OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-cti-ets-proofOfSender OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 4} us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 4}
skipping to change at page 69, line 5 skipping to change at page 69, line 5
-- as defined in RFC 3281 : see section 4.1 -- as defined in RFC 3281 : see section 4.1
-- Content Timestamp -- Content Timestamp
id-aa-ets-contentTimestamp OBJECT IDENTIFIER ::= id-aa-ets-contentTimestamp OBJECT IDENTIFIER ::=
{ 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) id-aa(2) 20} smime(16) id-aa(2) 20}
ContentTimestamp ::= TimeStampToken ContentTimestamp ::= TimeStampToken
Internet-draft CMS Advanced Electronic Signatures September 2007
-- Signature Timestamp -- Signature Timestamp
id-aa-signatureTimeStampToken OBJECT IDENTIFIER ::= id-aa-signatureTimeStampToken OBJECT IDENTIFIER ::=
{ 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) id-aa(2) 14} smime(16) id-aa(2) 14}
SignatureTimeStampToken ::= TimeStampToken SignatureTimeStampToken ::= TimeStampToken
-- Complete Certificate Refs. -- Complete Certificate Refs.
skipping to change at page 70, line 4 skipping to change at page 70, line 4
ocspIdentifier OcspIdentifier, ocspIdentifier OcspIdentifier,
ocspRepHash OtherHash OPTIONAL ocspRepHash OtherHash 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 CMS Advanced Electronic Signatures September 2007
OtherRevRefs ::= SEQUENCE { OtherRevRefs ::= SEQUENCE {
otherRevRefType OtherRevRefType, otherRevRefType OtherRevRefType,
otherRevRefs ANY DEFINED BY otherRevRefType otherRevRefs ANY DEFINED BY otherRevRefType
} }
OtherRevRefType ::= OBJECT IDENTIFIER OtherRevRefType ::= OBJECT IDENTIFIER
-- Certificate Values -- Certificate Values
id-aa-ets-certValues OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-aa-ets-certValues OBJECT IDENTIFIER ::= { iso(1) member-body(2)
skipping to change at page 70, line 53 skipping to change at page 70, line 56
-- Time-Stamped Certificates and CRLs -- Time-Stamped Certificates and CRLs
id-aa-ets-certCRLTimestamp OBJECT IDENTIFIER ::= { iso(1) id-aa-ets-certCRLTimestamp OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) id-aa(2) 26} smime(16) id-aa(2) 26}
TimestampedCertsCRLs ::= TimeStampToken TimestampedCertsCRLs ::= TimeStampToken
-- Archive Timestamp -- Archive Timestamp
id-aa-ets-archiveTimestamp OBJECT IDENTIFIER ::= { iso(1) id-aa-ets-archiveTimestampV2 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) 48} smime(16) id-aa(2) 48}
Internet-draft CMS Advanced Electronic Signatures September 2007
ArchiveTimeStampToken ::= TimeStampToken ArchiveTimeStampToken ::= TimeStampToken
-- Attribute certificate references -- Attribute certificate references
id-aa-ets-attrCertificateRefs OBJECT IDENTIFIER ::= { iso(1) id-aa-ets-attrCertificateRefs 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) 44} smime(16) id-aa(2) 44}
AttributeCertificateRefs ::= SEQUENCE OF OtherCertID AttributeCertificateRefs ::= SEQUENCE OF OtherCertID
-- Attribute revocation references -- Attribute revocation references
id-aa-ets-attrRevocationRefs OBJECT IDENTIFIER ::= { iso(1) id-aa-ets-attrRevocationRefs 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) 45} smime(16) id-aa(2) 45}
AttributeRevocationRefs ::= SEQUENCE OF CrlOcspRef AttributeRevocationRefs ::= SEQUENCE OF CrlOcspRef
END END
Internet-draft CMS Advanced Electronic Signatures September 2007
A.2 Signature format definitions using X.680 ASN.1 syntax A.2 Signature format definitions using X.680 ASN.1 syntax
NOTE: The ASN.1 module defined in section A.1 has precedence over that NOTE: The ASN.1 module defined in section A.1 has precedence over that
defined in section A.2 using syntax defined in ITU-T defined in section A.2 using syntax defined in ITU-T
Recommendation X.680 (1997) [8] in the case of any conflict. Recommendation X.680 (1997) [8] in the case of any conflict.
ETS-ElectronicSignatureFormats-ExplicitSyntax97 { iso(1) member-body(2) ETS-ElectronicSignatureFormats-ExplicitSyntax97 { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-mod(0) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-mod(0)
eSignature-explicit97(29)} eSignature-explicit97(29)}
skipping to change at page 73, line 4 skipping to change at page 73, line 4
-- Internet X.509 Public Key Infrastructure -- Internet X.509 Public Key Infrastructure
-- Certificate and CRL Profile: RFC 3280 -- Certificate and CRL Profile: RFC 3280
Certificate, AlgorithmIdentifier, CertificateList, Name, Certificate, AlgorithmIdentifier, CertificateList, Name,
Attribute Attribute
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) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit(18)} id-pkix1-explicit(18)}
Internet-draft CMS Advanced Electronic Signatures September 2007
GeneralNames, GeneralName, PolicyInformation GeneralNames, GeneralName, PolicyInformation
FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-implicit(19)} id-pkix1-implicit(19)}
-- Internet Attribute Certificate Profile for Authorization - RFC 3281 -- Internet Attribute Certificate Profile for Authorization - RFC 3281
AttributeCertificate AttributeCertificate
FROM PKIXAttributeCertificate {iso(1) identified-organization(3) FROM PKIXAttributeCertificate {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
skipping to change at page 74, line 5 skipping to change at page 74, line 5
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) idupMechanism (4) electronic-signature-standard (1733) part1 (1) idupMechanism (4)
etsiESv1(1) } etsiESv1(1) }
-- Basic ES Attributes Defined in the present document -- Basic ES Attributes Defined in the present document
-- =================================================== -- ===================================================
-- CMS Attributes defined in the present document -- CMS Attributes defined in the present document
Internet-draft CMS Advanced Electronic Signatures September 2007
-- OtherSigningCertificate - deprecated -- OtherSigningCertificate - deprecated
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 THE PRESENT DOCUMENT -- NOT USED IN THE PRESENT DOCUMENT
skipping to change at page 75, line 4 skipping to change at page 75, line 4
SignaturePolicyImplied ::= NULL SignaturePolicyImplied ::= NULL
SigPolicyId ::= OBJECT IDENTIFIER SigPolicyId ::= OBJECT IDENTIFIER
SigPolicyHash ::= OtherHashAlgAndValue SigPolicyHash ::= OtherHashAlgAndValue
OtherHashAlgAndValue ::= SEQUENCE { OtherHashAlgAndValue ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier, hashAlgorithm AlgorithmIdentifier,
hashValue OtherHashValue hashValue OtherHashValue
} }
Internet-draft CMS Advanced Electronic Signatures September 2007
OtherHashValue ::= OCTET STRING OtherHashValue ::= OCTET STRING
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 76, line 5 skipping to change at page 76, line 5
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)) }
-- Optional Electronic Signature Attributes -- Optional Electronic Signature Attributes
Internet-draft CMS Advanced Electronic Signatures September 2007
-- 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 OPTIONAL} CommitmentTypeQualifier OPTIONAL}
skipping to change at page 77, line 4 skipping to change at page 77, line 4
smime(16) cti(6) 5} smime(16) cti(6) 5}
id-cti-ets-proofOfCreation OBJECT IDENTIFIER ::= id-cti-ets-proofOfCreation OBJECT IDENTIFIER ::=
{ 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) cti(6) 6} smime(16) cti(6) 6}
-- Signer Location -- Signer Location
id-aa-ets-signerLocation OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-aa-ets-signerLocation OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 17} us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 17}
Internet-draft CMS Advanced Electronic Signatures September 2007
SignerLocation ::= SEQUENCE { SignerLocation ::= SEQUENCE {
-- at least one of the following shall be present -- at least one of the following shall be present
countryName [0] DirectoryString{maxSize} OPTIONAL, countryName [0] DirectoryString{maxSize} OPTIONAL,
-- as used to name a Country in X.520 -- as used to name a Country in X.520
localityName [1] DirectoryString{maxSize} OPTIONAL, localityName [1] DirectoryString{maxSize} OPTIONAL,
-- as used to name a locality in X.520 -- as used to name a locality in X.520
postalAdddress [2] PostalAddress OPTIONAL } postalAdddress [2] PostalAddress OPTIONAL }
PostalAddress ::= SEQUENCE SIZE(1..6) OF DirectoryString{maxSize} PostalAddress ::= SEQUENCE SIZE(1..6) OF DirectoryString{maxSize}
-- maxSize parametrization as specified in X.683 -- maxSize parametrization as specified in X.683
skipping to change at page 78, line 4 skipping to change at page 78, line 4
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 21} us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 21}
CompleteCertificateRefs ::= SEQUENCE OF OtherCertID CompleteCertificateRefs ::= SEQUENCE OF OtherCertID
-- Complete Revocation Refs -- Complete Revocation Refs
id-aa-ets-revocationRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-aa-ets-revocationRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2)
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
Internet-draft CMS Advanced Electronic Signatures September 2007
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
} }
skipping to change at page 79, line 5 skipping to change at page 79, line 5
WITH SYNTAX { WITH SYNTAX {
WITH SYNTAX &Type ID &id } WITH SYNTAX &Type ID &id }
-- Certificate Values -- Certificate Values
id-aa-ets-certValues OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-aa-ets-certValues OBJECT IDENTIFIER ::= { iso(1) member-body(2)
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}
CertificateValues ::= SEQUENCE OF Certificate CertificateValues ::= SEQUENCE OF Certificate
Internet-draft CMS Advanced Electronic Signatures September 2007
-- Certificate Revocation Values -- Certificate Revocation Values
id-aa-ets-revocationValues OBJECT IDENTIFIER ::= id-aa-ets-revocationValues OBJECT IDENTIFIER ::=
{ 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) id-aa(2) 24} smime(16) 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 OPTIONAL otherRevVals [2] OtherRevVals OPTIONAL
skipping to change at page 79, line 44 skipping to change at page 79, line 46
-- Time-Stamped Certificates and CRLs -- Time-Stamped Certificates and CRLs
id-aa-ets-certCRLTimestamp OBJECT IDENTIFIER ::= id-aa-ets-certCRLTimestamp OBJECT IDENTIFIER ::=
{ 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) id-aa(2) 26} smime(16) id-aa(2) 26}
TimestampedCertsCRLs ::= TimeStampToken TimestampedCertsCRLs ::= TimeStampToken
-- Archive Timestamp -- Archive Timestamp
id-aa-ets-archiveTimestamp OBJECT IDENTIFIER ::= id-aa-ets-archiveTimestampV2 OBJECT IDENTIFIER ::=
{ 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) id-aa(2) 48} smime(16) id-aa(2) 48}
ArchiveTimeStampToken ::= TimeStampToken ArchiveTimeStampToken ::= TimeStampToken
-- Attribute certificate references -- Attribute certificate references
id-aa-ets-attrCertificateRefs OBJECT IDENTIFIER ::= id-aa-ets-attrCertificateRefs OBJECT IDENTIFIER ::=
{ 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) id-aa(2) 44} smime(16) id-aa(2) 44}
AttributeCertificateRefs ::= SEQUENCE OF OtherCertID AttributeCertificateRefs ::= SEQUENCE OF OtherCertID
Internet-draft CMS Advanced Electronic Signatures September 2007
-- Attribute revocation references -- Attribute revocation references
id-aa-ets-attrRevocationRefs OBJECT IDENTIFIER ::= id-aa-ets-attrRevocationRefs OBJECT IDENTIFIER ::=
{ 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) id-aa(2) 45} smime(16) id-aa(2) 45}
AttributeRevocationRefs ::= SEQUENCE OF CrlOcspRef AttributeRevocationRefs ::= SEQUENCE OF CrlOcspRef
END END
Internet-draft CMS Advanced Electronic Signatures September 2007
Annex B (informative): Extended forms of Electronic Signatures Annex B (informative): Extended forms of Electronic Signatures
Section 4 provides on overview of the various formats of electronic Section 4 provides on overview of the various formats of electronic
signatures included in the present document. This annex lists the signatures included in the present document. This annex lists the
attributes that need to be present in the various extended electronic attributes that need to be present in the various extended electronic
signature formats and provide example validation sequences using the signature formats and provide example validation sequences using the
extended formats. extended formats.
B.1 Extended forms of validation data B.1 Extended forms of validation data
skipping to change at page 82, line 5 skipping to change at page 82, line 5
The above time-stamp forms can be useful when it is required to counter The above time-stamp forms can be useful when it is required to counter
the risk that any CA keys used in the certificate chain may be the risk that any CA keys used in the certificate chain may be
compromised. compromised.
A combination of the two formats above may be used. This form of A combination of the two formats above may be used. This form of
eXtended validation data is called an ES X-Long Type 1 or CAdES-X Long eXtended validation data is called an ES X-Long Type 1 or CAdES-X Long
Type 2. This form of Electronic Signature can be useful when the Type 2. This form of Electronic Signature can be useful when the
verifier needs both the values and proof of when the validation data verifier needs both the values and proof of when the validation data
existed. existed.
Internet-draft CMS Advanced Electronic Signatures September 2007
NOTE 2: The advantages/drawbacks for CAdES-X long Type 1 and CAdES-X NOTE 2: The advantages/drawbacks for CAdES-X long Type 1 and CAdES-X
long Type 2 are discussed in section C.4.6. long Type 2 are discussed in section C.4.6.
B.1.1 CAdES-X Long B.1.1 CAdES-X Long
An Electronic Signature with the additional validation data forming the An Electronic Signature with the additional validation data forming the
CAdES-X Long form (CAdES-X-Long)) is illustrated in figure B.1 and CAdES-X Long form (CAdES-X-Long)) is illustrated in figure B.1 and
comprises the following: comprises the following:
- CAdES-BES or CAdES-EPES as defined in sections 4.3 , 5.7 or 5.8; - CAdES-BES or CAdES-EPES as defined in sections 4.3 , 5.7 or 5.8;
skipping to change at page 83, line 5 skipping to change at page 83, line 5
- attribute-revocation-references attribute as defined in section - attribute-revocation-references attribute as defined in section
6.2.4. 6.2.4.
Other unsigned attributes may be present, but are not required. Other unsigned attributes may be present, but are not required.
NOTE: Attribute certificate and revocation references are only NOTE: Attribute certificate and revocation references are only
present if a user attribute certificate is present in the present if a user attribute certificate is present in the
electronic signature, see sections 6.2.2 and 6.2.3. electronic signature, see sections 6.2.2 and 6.2.3.
Internet-draft CMS Advanced Electronic Signatures September 2007
+---------------------- CAdES-X-Long --------------------------------+ +---------------------- CAdES-X-Long --------------------------------+
|+-------------------------------------- CAdES-C ---+ | |+-------------------------------------- CAdES-C ---+ |
|| +----------+ | +-------------+| || +----------+ | +-------------+|
||+----- CAdES-BES or CAdES-EPES ----+ |Timestamp | | | || ||+----- CAdES-BES or CAdES-EPES ----+ |Timestamp | | | ||
||| | |over | | | Complete || ||| | |over | | | Complete ||
|||+---------++----------++---------+| |digital | | | certificate || |||+---------++----------++---------+| |digital | | | certificate ||
|||| || || || |signature | | | and || |||| || || || |signature | | | and ||
||||Signer's || Signed ||Digital || | | | | revocation || ||||Signer's || Signed ||Digital || | | | | revocation ||
||||Document ||Attributes||signature|| |Optional | | | data || ||||Document ||Attributes||signature|| |Optional | | | data ||
|||| || || || |when | | | || |||| || || || |when | | | ||
skipping to change at page 84, line 5 skipping to change at page 84, line 5
- complete-revocation-references attribute as defined in section - complete-revocation-references attribute as defined in section
6.2.2; 6.2.2;
- CAdES-C-Timestamp attribute, as defined in section 6.3.5. - CAdES-C-Timestamp attribute, as defined in section 6.3.5.
The following attributes are required if a TSP is not providing a time- The following attributes are required if a TSP is not providing a time-
mark of the ES: mark of the ES:
- signature-time-stamp attribute as defined in section 6.1.1. - signature-time-stamp attribute as defined in section 6.1.1.
Internet-draft CMS Advanced Electronic Signatures September 2007
If attributes certificates are used then the following attributes may If attributes certificates are used then the following attributes may
be present: be present:
- attribute-certificate-references attribute defined in section - attribute-certificate-references attribute defined in section
6.2.3; 6.2.3;
- attribute-revocation-references attribute as defined in section - attribute-revocation-references attribute as defined in section
6.2.4. 6.2.4.
Other unsigned attributes may be present, but are not required. Other unsigned attributes may be present, but are not required.
skipping to change at page 85, line 4 skipping to change at page 85, line 4
eXtended Validation Data - Type 2 X is illustrated in figure B.3. and eXtended Validation Data - Type 2 X is illustrated in figure B.3. and
comprises the following: comprises the following:
- CAdES-BES or CAdES-EPES as defined in sections 4.2, 5.7 or 5.8; - CAdES-BES or CAdES-EPES as defined in sections 4.2, 5.7 or 5.8;
- complete-certificate-references attribute as defined in section - complete-certificate-references attribute as defined in section
6.2.1; 6.2.1;
- complete-revocation-references attribute as defined in section - complete-revocation-references attribute as defined in section
6.2.2; 6.2.2;
Internet-draft CMS Advanced Electronic Signatures September 2007
- time-stamped-certs-crls-references attribute as defined in section - time-stamped-certs-crls-references attribute as defined in section
6.3.6. 6.3.6.
The following attributes are required if a TSP is not providing a time- The following attributes are required if a TSP is not providing a time-
mark of the ES: mark of the ES:
- signature-time-stamp attribute as defined in section 6.1.1. - signature-time-stamp attribute as defined in section 6.1.1.
If attributes certificates are used then the following attributes may If attributes certificates are used then the following attributes may
be present: be present:
skipping to change at page 86, line 5 skipping to change at page 86, line 5
+--------------------------------------------------------------------+ +--------------------------------------------------------------------+
Figure B.3 : Illustration of CAdES-X Type 2 Figure B.3 : Illustration of CAdES-X Type 2
B.1.4 CAdES-X Long Type 1 and CAdES-X Long Type 2 B.1.4 CAdES-X Long Type 1 and CAdES-X Long Type 2
An Electronic Signature with the additional validation data forming the An Electronic Signature with the additional validation data forming the
CAdES-X Long Type 1 and CAdES-X Long Type 2 is illustrated in CAdES-X Long Type 1 and CAdES-X Long Type 2 is illustrated in
figure B.4 and comprises the following: figure B.4 and comprises the following:
Internet-draft CMS Advanced Electronic Signatures September 2007
- CAdES-BES or CAdES-EPES as defined in sections 4.3, 5.7 or 5.8; - CAdES-BES or CAdES-EPES as defined in sections 4.3, 5.7 or 5.8;
- complete-certificate-references attribute as defined in section - complete-certificate-references attribute as defined in section
6.2.1; 6.2.1;
- complete-revocation-references attribute as defined in section - complete-revocation-references attribute as defined in section
6.2.2; 6.2.2;
The following attributes are required if a TSP is not providing a time- The following attributes are required if a TSP is not providing a time-
mark of the ES: mark of the ES:
skipping to change at page 87, line 5 skipping to change at page 87, line 5
6.2.4. 6.2.4.
Plus one of the following attributes is required: Plus one of the following attributes is required:
- CAdES-C-Timestamp attribute, as defined in section 6.3.5; - CAdES-C-Timestamp attribute, as defined in section 6.3.5;
- time-stamped-certs-crls-references attribute as defined in section - time-stamped-certs-crls-references attribute as defined in section
6.3.6. 6.3.6.
Other unsigned attributes may be present, but are not required. Other unsigned attributes may be present, but are not required.
Internet-draft CMS Advanced Electronic Signatures September 2007
+---------------------- CAdES-X-Type 1 or 2 ------------------------+ +---------------------- CAdES-X-Type 1 or 2 ------------------------+
| +--------------+| | +--------------+|
|+-------------------------------------- CAdES-C --+|+------------+|| |+-------------------------------------- CAdES-C --+|+------------+||
|| +----------+ ||| Timestamp ||| || +----------+ ||| Timestamp |||
||+-- CAdES-BES or CAdES-EPES -------+|Timestamp | ||| over ||| ||+-- CAdES-BES or CAdES-EPES -------+|Timestamp | ||| over |||
||| ||over | ||| CAdES-C ||| ||| ||over | ||| CAdES-C |||
|||+---------++----------++---------+||digital | | +------------+ | |||+---------++----------++---------+||digital | | +------------+ |
|||| || || |||signature | || or || |||| || || |||signature | || or ||
||||Signer's || Signed || Digital ||| | ||+------------+|| ||||Signer's || Signed || Digital ||| | ||+------------+||
||||Document ||Attributes||Signature|||Optional | ||| Timestamp ||| ||||Document ||Attributes||Signature|||Optional | ||| Timestamp |||
skipping to change at page 88, line 5 skipping to change at page 88, line 5
section 6.2.2; section 6.2.2;
- certificate-values attribute; of the TSU as defined in section - certificate-values attribute; of the TSU as defined in section
6.3.3; 6.3.3;
- revocation-values attribute, of the TSU as defined in section - revocation-values attribute, of the TSU as defined in section
6.3.4. 6.3.4.
Other unsigned attributes may be present, but are not required. Other unsigned attributes may be present, but are not required.
Internet-draft CMS Advanced Electronic Signatures September 2007
B.3 Archive validation data (CAdES-A) B.3 Archive validation data (CAdES-A)
Before the algorithms, keys and other cryptographic data used at the Before the algorithms, keys and other cryptographic data used at the
time the CAdES-C was built become weak and the cryptographic functions time the CAdES-C was built become weak and the cryptographic functions
become vulnerable, or the certificates supporting previous time-stamps become vulnerable, or the certificates supporting previous time-stamps
expires, the signed data, the CAdES-C and any additional information expires, the signed data, the CAdES-C and any additional information
(i.e. any CAdES-X) should be time-stamped. If possible this should use (i.e. any CAdES-X) should be time-stamped. If possible this should use
stronger algorithms (or longer key lengths) than in the original time- stronger algorithms (or longer key lengths) than in the original time-
stamp. This additional data and time-stamp is called Archive stamp. This additional data and time-stamp is called Archive
Validation Data required for the ES Archive format (CAdES-A). The Validation Data required for the ES Archive format (CAdES-A). The
skipping to change at page 89, line 5 skipping to change at page 89, line 5
||| +-------------+| |certificate | | | ||| +-------------+| |certificate | | |
||+----------------------------------+ | and | | | ||+----------------------------------+ | and | | |
|| |revocation | | | || |revocation | | |
|| | values | | | || | values | | |
|| +------------+ | | || +------------+ | |
|+----------------------------------------------------+ | |+----------------------------------------------------+ |
+--------------------------------------------------------------------+ +--------------------------------------------------------------------+
Figure B.5 : Illustration of CAdES-A Figure B.5 : Illustration of CAdES-A
Internet-draft CMS Advanced Electronic Signatures September 2007
The CAdES-A comprises the following elements: The CAdES-A comprises the following elements:
- the CAdES-BES or CAdES-EPES including their signed and unsigned - the CAdES-BES or CAdES-EPES including their signed and unsigned
attributes; attributes;
- complete-certificate-references attribute as defined in section - complete-certificate-references attribute as defined in section
6.2.1; 6.2.1;
- complete-revocation-references attribute as defined in section - complete-revocation-references attribute as defined in section
6.2.2. 6.2.2.
skipping to change at page 90, line 5 skipping to change at page 90, line 5
- archive-time-stamp attributes defined in section 6.4.1. - archive-time-stamp attributes defined in section 6.4.1.
Several instances of archive-time-stamp attribute may occur with an Several instances of archive-time-stamp attribute may occur with an
electronic signature both over time and from different TSUs. The time- electronic signature both over time and from different TSUs. The time-
stamp should be created using stronger algorithms (or longer key stamp should be created using stronger algorithms (or longer key
lengths) than in the original electronic signatures or time-stamps. lengths) than in the original electronic signatures or time-stamps.
Other unsigned attributes of the ES may be present, but are not Other unsigned attributes of the ES may be present, but are not
required. required.
Internet-draft CMS Advanced Electronic Signatures September 2007
The archive timestamp will itself contain the certificate and The archive timestamp will itself contain the certificate and
revocation information required to validate the archive timestamp, this revocation information required to validate the archive timestamp, this
may include the following unsigned attributes: may include the following unsigned attributes:
- complete-certificate-references attribute of the TSU as defined - complete-certificate-references attribute of the TSU as defined
in section 6.2.1; in section 6.2.1;
- complete-revocation-references attribute of the TSU as defined in - complete-revocation-references attribute of the TSU as defined in
section 6.2.2; section 6.2.2;
skipping to change at page 91, line 5 skipping to change at page 91, line 5
Other unsigned attributes may be present, but are not required. Other unsigned attributes may be present, but are not required.
B.4 Example validation sequence B.4 Example validation sequence
As described earlier the signer or initial verifier may collect all the As described earlier the signer or initial verifier may collect all the
additional data that forms the electronic signature. Figure B.6, and additional data that forms the electronic signature. Figure B.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.
Internet-draft CMS Advanced Electronic Signatures September 2007
+------------------------------------------ CAdES-C -------------+ +------------------------------------------ CAdES-C -------------+
|+------------------------------- CAdES-T ------+ | |+------------------------------- CAdES-T ------+ |
||+-------------- CAdES ------------+ | | ||+-------------- CAdES ------------+ | |
|||+--------------------++---------+|+---------+| +-----------+ | |||+--------------------++---------+|+---------+| +-----------+ |
|||| ________ || |||Timestamp|| |Complete | | |||| ________ || |||Timestamp|| |Complete | |
|||||Sign.Pol| ||Digital |||over || |certificate| | |||||Sign.Pol| ||Digital |||over || |certificate| |
||||| Id. | Signed ||signature|||digital || | and | | ||||| Id. | Signed ||signature|||digital || | and | |
||||| option.|attributes|| |||signature|| |revocation | | ||||| option.|attributes|| |||signature|| |revocation | |
|||||________| |+---------+|+---------+| |references | | |||||________| |+---------+|+---------+| |references | |
|||+--------------------+ | ^ | +-----------+ | |||+--------------------+ | ^ | +-----------+ |
skipping to change at page 92, line 4 skipping to change at page 92, line 4
To ascertain the validity status as Valid or Invalid and communicate To ascertain the validity status as Valid or Invalid and communicate
that to the user (4) all the additional data required to validate the that to the user (4) all the additional data required to validate the
CAdES-C, must be available (e.g. the complete certificate and CAdES-C, must be available (e.g. the complete certificate and
revocation information). revocation information).
Once the data needed to complete validation data references (CAdES-C) Once the data needed to complete validation data references (CAdES-C)
is available then the validation process should: is available then the validation process should:
- obtain all the necessary additional certificate and revocation - obtain all the necessary additional certificate and revocation
status information; status information;
Internet-draft CMS Advanced Electronic Signatures September 2007
- complete all the validation checks on the ES, using the complete - complete all the validation checks on the ES, using the complete
certificate and revocation information (if a time-stamp is not certificate and revocation information (if a time-stamp is not
already present, this may be added at the same stage combining already present, this may be added at the same stage combining
CAdES-T and CAdES-C process); CAdES-T and CAdES-C process);
- record the complete certificate and revocation references (3); - record the complete certificate and revocation references (3);
- indicate the validity status to the user (4). - indicate the validity status to the user (4).
At the same time as the validation process creates the CAdES-C, the At the same time as the validation process creates the CAdES-C, the
skipping to change at page 93, line 5 skipping to change at page 93, line 5
v | v | v | v |
+---------+ +--------+ +---------+ +--------+
|Signature| |Trusted | |Signature| |Trusted |
| Policy | |Service | | Policy | |Service |
| Issuer | |Provider| | Issuer | |Provider|
+---------+ +--------+ +---------+ +--------+
Figure B.7 : Illustration of a CAdES validation sequence Figure B.7 : Illustration of a CAdES validation sequence
with CAdES-X Long with CAdES-X Long
Internet-draft CMS Advanced Electronic Signatures September 2007
When the validation process creates the CAdES-C it may also create When the validation process creates the CAdES-C it may also create
extended forms of validation data. extended forms of validation data.
A first alternative is to time-stamp all data forming the CAdES-X Type A first alternative is to time-stamp all data forming the CAdES-X Type
1 (6). 1 (6).
This is illustrated in figure B.8. This is illustrated in figure B.8.
+------------------------------------------------ CAdES-X Type 1 -----+ +------------------------------------------------ CAdES-X Type 1 -----+
|+------------------------------- CAdES-C ------------------+ | |+------------------------------- CAdES-C ------------------+ |
skipping to change at page 94, line 5 skipping to change at page 94, line 5
Figure B.8 : Illustration of CAdES with eXtended Validation Data Figure B.8 : Illustration of CAdES with eXtended Validation Data
CAdES-X Type 1 CAdES-X Type 1
Another alternative is to time-stamp the certificate and revocation Another alternative is to time-stamp the certificate and revocation
information references used to validate the electronic signature (but information references used to validate the electronic signature (but
not the signature) (6'); this is called CAdES-X Type 2. not the signature) (6'); this is called CAdES-X Type 2.
This is illustrated in figure B.9. This is illustrated in figure B.9.
Internet-draft CMS Advanced Electronic Signatures September 2007
+-------------------------------------------- CAdES-X Type 2 --------+ +-------------------------------------------- CAdES-X Type 2 --------+
|+------------------------------- CAdES-C -------------+ | |+------------------------------- CAdES-C -------------+ |
||+-------------- CAdES ------------+ | | ||+-------------- CAdES ------------+ | |
|||+--------------------++---------+|+---------+ |+-----------+| |||+--------------------++---------+|+---------+ |+-----------+|
|||| ________ || |||Timestamp| ||Timestamp || |||| ________ || |||Timestamp| ||Timestamp ||
|||||Sign.Pol| || |||over | || over || |||||Sign.Pol| || |||over | || over ||
||||| Id. | Signed ||Digital |||digital | ||complete || ||||| Id. | Signed ||Digital |||digital | ||complete ||
||||| option.|attributes||signature|||signature| ||certificate|| ||||| option.|attributes||signature|||signature| ||certificate||
|||||________| || ||| | || || |||||________| || ||| | || ||
|||+--------------------++---------+|+---------+ || and || |||+--------------------++---------+|+---------+ || and ||
skipping to change at page 95, line 5 skipping to change at page 95, line 5
Figure B.9: Illustration of CAdES with eXtended Validation Data Figure B.9: Illustration of CAdES with eXtended Validation Data
CAdES-X Type 2 CAdES-X Type 2
Before the algorithms used in any of electronic signatures become or Before the algorithms used in any of electronic signatures become or
are likely, to be compromised or rendered vulnerable in the future, it are likely, to be compromised or rendered vulnerable in the future, it
may be necessary to time-stamp the entire electronic signature, may be necessary to time-stamp the entire electronic signature,
including all the values of the validation and user data as an ES with including all the values of the validation and user data as an ES with
Archive Validation Data (CAdES-A) (7). Archive Validation Data (CAdES-A) (7).
Internet-draft CMS Advanced Electronic Signatures September 2007
An CAdES-A is illustrated in figure B.10. An CAdES-A is illustrated in figure B.10.
+----------------------------- CAdES-A ---------------------------+ +----------------------------- CAdES-A ---------------------------+
| | | |
| +-- CAdES-X Long Type 1 or 2 ----------+ | | +-- CAdES-X Long Type 1 or 2 ----------+ |
| | | +------------+ | | | | +------------+ |
| | | | | | | | | | | |
| | | | Archive | | | | | | Archive | |
| | | | Time-stamp | | | | | | Time-stamp | |
| | | | | | | | | | | |
skipping to change at page 96, line 5 skipping to change at page 96, line 5
- indicate the claimed location of the signer; - indicate the claimed location of the signer;
- indicate the claimed or certified role under which a signature - indicate the claimed or certified role under which a signature
was created; was created;
- support counter signatures; - support counter signatures;
- support multiple signatures. - support multiple signatures.
Internet-draft CMS Advanced Electronic Signatures September 2007
Annex C (informative):General description Annex C (informative):General description
This annex explains some of the concepts and provides the rational for This annex explains some of the concepts and provides the rational for
normative parts of the present document. normative parts of the present document.
The specification below includes a description why and when the each The specification below includes a description why and when the each
component of an electronic signature is useful, with a brief component of an electronic signature is useful, with a brief
description of the vulnerabilities and threats and the manner by which description of the vulnerabilities and threats and the manner by which
they are countered. they are countered.
skipping to change at page 97, line 5 skipping to change at page 97, line 5
signature; signature;
- 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, e.g. - rules, which relate to the environment used by the signer, e.g.
the use of an agreed CAD (Card Accepting Device) used in the use of an agreed CAD (Card Accepting Device) used in
conjunction with a smart card. conjunction with a smart card.
Internet-draft CMS Advanced Electronic Signatures September 2007
For example, the major rules required for technical validation can For example, the major rules required for technical validation can
include: recognized root keys or "top-level certification authorities", include: recognized root keys or "top-level certification authorities",
acceptable certificate policies (if any), necessary certificate acceptable certificate policies (if any), necessary certificate
extensions and values (if any), the need for the revocation status for extensions and values (if any), the need for the revocation status for
each component of the certification tree, acceptable TSAs (if time- each component of the certification tree, acceptable TSAs (if time-
stamp tokens are being used), acceptable organizations for keeping the stamp tokens are being used), acceptable organizations for keeping the
audit trails with time-marks (if time-marking is being used), audit trails with time-marks (if time-marking is being used),
acceptable AAs (if any are being used).as well as rules defining the acceptable AAs (if any are being used).as well as rules defining the
components of the electronic signature that shall be provided by the components of the electronic signature that shall be provided by the
signer with data required by the verifier when required to provide long signer with data required by the verifier when required to provide long
skipping to change at page 98, line 5 skipping to change at page 98, line 5
policy that is to be used to verify a CAdES-EPES the signature an policy that is to be used to verify a CAdES-EPES the signature an
identifier and hash of the "Signature policy" shall be part of the identifier and hash of the "Signature policy" shall be part of the
signed data. Additional information about the explicit policy (e.g. signed data. Additional information about the explicit policy (e.g.
web reference to the document) may be carried as "qualifiers" to the web reference to the document) may be carried as "qualifiers" to the
signature policy identifier. signature policy identifier.
In order to unambiguously identify the authority responsible for In order to unambiguously identify the authority responsible for
defining an explicit signature policy the "Signature policy" can be defining an explicit signature policy the "Signature policy" can be
signed. signed.
Internet-draft CMS Advanced Electronic Signatures September 2007
C.3.2 Commitment type indication C.3.2 Commitment type indication
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 electronic - explicitly using a "commitment type indication" in the electronic
signature; signature;
- implicitly or explicitly from the semantics of the signed data. - implicitly or explicitly from the semantics of the signed data.
skipping to change at page 99, line 5 skipping to change at page 99, line 5
of the private key is an advantage when a smart card is used to protect of the private key is an advantage when a smart card is used to protect
the private key, since the storage of a smart card is always limited. the private key, since the storage of a smart card is always limited.
When several CAs are involved, each different certificate may contain a When several CAs are involved, each different certificate may contain a
different identity, e.g. as a national or as an employee from a different identity, e.g. as a national or as an employee from a
company. Thus when a private key is used for various purposes, the company. Thus when a private key is used for various purposes, the
certificate is needed to clarify the context in which the private key certificate is needed to clarify the context in which the private key
was used when generating the signature. Where there is the possibility was used when generating the signature. Where there is the possibility
that multiple private keys are used, it is necessary for the signer to that multiple private keys are used, it is necessary for the signer to
indicate to the verifier the precise certificate to be used. indicate to the verifier the precise certificate to be used.
Internet-draft CMS Advanced Electronic Signatures September 2007
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 vulnerable to substitution attacks. If the certificate and thus are vulnerable to substitution attacks. If the certificate
from the signer was simply appended to the signature and thus not from the signer was simply appended to the signature and thus not
protected by the signature, any one could substitute one certificate by protected by the signature, any one could substitute one certificate by
another and the message would appear to be signed by some one else. In another 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 has order to counter this kind of attack, the identifier of the signer has
to be protected by the digital signature from the signer. to be protected by the digital signature from the signer.
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 the
skipping to change at page 100, line 5 skipping to change at page 100, line 5
of certificates. For example by using separate certificates of certificates. For example by using separate certificates
for signer's identity and roles means new identity keys need for signer's identity and roles means new identity keys need
not be issued if a user's role changes. not be issued if a user's role changes.
C.3.4.1 Claimed role C.3.4.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 certificate
to corroborate this claim. In which case the claimed role can be added to corroborate this claim. In which case the claimed role can be added
to the signature as a signed attribute. to the signature as a signed attribute.
Internet-draft CMS Advanced Electronic Signatures September 2007
C.3.4.2 Certified role C.3.4.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 key,
Attribute Certificates bind the identifier of a certificate to some Attribute Certificates bind the identifier of a certificate to some
attributes, like a role. An Attribute Certificate is NOT issued by a attributes, like a role. An Attribute Certificate is NOT issued by a
CA but by an Attribute Authority (AA). The Attribute Authority in most CA but by an Attribute Authority (AA). The Attribute Authority in most
cases might be under the control of an organization or a company that cases might be under the control of an organization or a company that
is best placed to know which attributes are relevant for which is best placed to know which attributes are relevant for which
individual. The Attribute Authority may use or point to public key individual. The Attribute Authority may use or point to public key
certificates issued by any CA, provided that the appropriate trust may certificates issued by any CA, provided that the appropriate trust may
skipping to change at page 101, line 5 skipping to change at page 101, line 5
Using this attribute a signer may sign over a time which is the claimed Using this attribute a signer may sign over a time which is the claimed
signing time. When an ES with Time-stamp is created (CAdES-T) then signing time. When an ES with Time-stamp is created (CAdES-T) then
either a trusted time stamp is obtained and added to the ES or a either a trusted time stamp is obtained and added to the ES or a
trusted time mark exists in an audit trail. When a verifier accepts a trusted time mark exists in an audit trail. When a verifier accepts a
signature, the two times shall be within acceptable limits. signature, the two times shall be within acceptable limits.
A further optional attribute is defined in the present document to A further optional attribute is defined in the present document to
timestamp the content, to provide proof of the existence of the timestamp the content, to provide proof of the existence of the
content, at the time indicated by the time-stamp token. content, at the time indicated by the time-stamp token.
Internet-draft CMS Advanced Electronic Signatures September 2007
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 time-stamping This solution requires an on-line connection to a trusted time-stamping
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 time-stamp (see signed object existed before the date included in the time-stamp (see
section 5.11.4). section 5.11.4).
C.3.7 Content format C.3.7 Content format
skipping to change at page 102, line 5 skipping to change at page 102, line 5
C.4.1 Revocation status information C.4.1 Revocation status information
A verifier will have to ascertain that the certificate of the signer A verifier will have to ascertain that the certificate of the signer
was valid at the time of the signature. This can be done by either: was valid at the time of the signature. This can be done by either:
- using Certificate Revocation Lists (CRLs); - using Certificate Revocation Lists (CRLs);
- using responses from an on-line certificate status server (for - using responses from an on-line certificate status server (for
example; obtained through the OCSP protocol). example; obtained through the OCSP protocol).
Internet-draft CMS Advanced Electronic Signatures September 2007
NOTE 1: The time of the signature may not be know, so time-stamping NOTE 1: The time of the signature may not be know, so time-stamping
or time-marking may be used to provide the time indication of or time-marking may be used to provide the time indication of
when it was known the signature existed. when it was known the signature existed.
NOTE 2: When validating an electronic signature and checking NOTE 2: When validating an electronic signature and checking
revocation status information a "grace period" is required revocation status information a "grace period" is required
which needs to be suitably long enough to allow the involved which needs to be suitably long enough to allow the involved
authority to process a "last minute" revocation request and authority to process a "last minute" revocation request and
for the request to propagate through the revocation system. for the request to propagate through the revocation system.
This grace period is to be added to the time included with the This grace period is to be added to the time included with the
skipping to change at page 103, line 5 skipping to change at page 103, line 5
When using OCSP to get revocation information, a verifier will have to When using OCSP to get revocation information, a verifier will have to
make sure that he or she gets at the time of the first verification an make sure that he or she gets at the time of the first verification an
OCSP response that contains the status "valid". This should be done as OCSP response that contains the status "valid". This should be done as
soon as possible after the generation of the signature, still providing soon as possible after the generation of the signature, still providing
a "grace period" suitable enough to allow the involved authority to a "grace period" suitable enough to allow the involved authority to
process a "last minute" revocation request The signer, the verifier or process a "last minute" revocation request The signer, the verifier or
any other third party may fetch this OCSP response. Since OCSP any other third party may fetch this OCSP response. Since OCSP
responses are transient and thus are not archived by any TSP including responses are transient and thus are not archived by any TSP including
CA, it is the responsibility of every verifier to make sure that it is CA, it is the responsibility of every verifier to make sure that it is
Internet-draft CMS Advanced Electronic Signatures September 2007
stored in a safe place. The simplest way is to store them associated stored in a safe place. The simplest way is to store them associated
with the electronic signature. An alternative would be to store them with the electronic signature. An alternative would be to store them
in some storage so that they can then be easily retrieved, and in some storage so that they can then be easily retrieved, and
incorporate references to them in the electronic signature itself as an incorporate references to them in the electronic signature itself as an
CAdES-C form. CAdES-C form.
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". In such a case, same comment as for CRL applies. "suspended". In such a case, same comment as for CRL applies.
skipping to change at page 104, line 5 skipping to change at page 104, line 5
provide proof that the signer's certificate and all the CA certificates provide proof that the signer's certificate and all the CA certificates
used to form a valid certification path were not revoked when the used to form a valid certification path were not revoked when the
signature was created or verified. 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 even
if the keys or certificates were later compromised. Thus there is a if the keys or certificates were later compromised. Thus there is a
need to be able to demonstrate that the signature keys was valid at the need to be able to demonstrate that the signature keys was valid at the
time that the signature was created to provide long term evidence of time that the signature was created to provide long term evidence of
the validity of a signature. the validity of a signature.
Internet-draft CMS Advanced Electronic Signatures September 2007
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 shall signature but revoked some time later. In this event, evidence shall
be provided that the document was signed before the signing key was be provided that the document was signed before the signing key was
revoked. Time-stamping by a Time-Stamping Authority (TSA) can provide revoked. Time-stamping by a Time-Stamping Authority (TSA) can provide
such evidence. A time stamp is obtained by sending the hash value of such evidence. A time stamp is obtained by sending the hash value of
the given data to the TSA. The returned "time-stamp" is a signed the given data to the TSA. The returned "time-stamp" is a signed
document that contains the hash value, the identity of the TSA, and the document 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. Time-stamping a digital signature (by sending a hash time of stamping. Time-stamping a digital signature (by sending a hash
of the signature to the TSA) before the revocation of the signer's of the signature to the TSA) before the revocation of the signer's
skipping to change at page 105, line 5 skipping to change at page 105, line 5
C.4.4 Time-stamping for long life of signature before CA key C.4.4 Time-stamping for long life of signature before CA key
compromises compromises
Time-stamped extended electronic signatures are needed when there is a Time-stamped extended electronic signatures are needed when there is a
requirement to safeguard against the possibility of a CA key in the requirement to safeguard against the possibility of a CA key in the
certificate chain ever being compromised. A verifier may be required certificate chain ever being compromised. A verifier may be required
to provide on request, proof that the certification path and the to provide on request, proof that the certification path and the
revocation information used a the time of the signature were valid, revocation information used a the time of the signature were valid,
Internet-draft CMS Advanced Electronic Signatures September 2007
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.
The present document defines two ways of using time-stamps to protect The present document defines two ways of using time-stamps to protect
against this compromise: against this compromise:
- time-stamp the ES with Complete validation data, when an OCSP - time-stamp 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 (CAdES-X Type 1). This format is suitable to be used with signer (CAdES-X Type 1). This format is suitable to be used with
an OCSP response and offers the additional advantage to provide an OCSP response and offers the additional advantage to provide
skipping to change at page 106, line 5 skipping to change at page 106, line 5
revocation status information used to support validation of that revocation status information used to support validation of that
signature, the time-stamp ensures that there is no ambiguity in the signature, the time-stamp ensures that there is no ambiguity in the
means of validating that signature. means of validating that signature.
This technique is referred to as CAdES-X Type 1 in the present This technique is referred to as CAdES-X Type 1 in the present
document. 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.
Internet-draft CMS Advanced Electronic Signatures September 2007
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 electronic
signature, in which case the electronic signature becomes an CAdES-X signature, in which case the electronic signature becomes an CAdES-X
Long Type 1 as defined by the present document. Long Type 1 as defined by the present document.
An CAdES-X Long Type 1 is simply the concatenation of an CAdES-X Type 1 An CAdES-X Long Type 1 is simply the concatenation of an CAdES-X Type 1
with a copy of the additional data being referenced. with a copy of the additional data being referenced.
C.4.4.2 Time-stamping certificates and revocation information C.4.4.2 Time-stamping certificates and revocation information
references (CAdES-X Type 2) references (CAdES-X Type 2)
skipping to change at page 107, line 5 skipping to change at page 107, line 5
and requires the following: and requires the following:
- all the CA certificates references and revocation information - all the CA certificates references and revocation information
references (i.e. CRLs) used in validating the CAdES-C are covered references (i.e. CRLs) used in validating the CAdES-C are covered
by one or more time-stamp. by one or more time-stamp.
Thus an CAdES-C with a time-stamp signature value at time T1, can be Thus an CAdES-C with a time-stamp signature value at time T1, can be
proved valid if all the CA and CRL references are time-stamped at time proved valid if all the CA and CRL references are time-stamped at time
T1+. T1+.
Internet-draft CMS Advanced Electronic Signatures September 2007
C.4.5 Time-stamping for archive of signature C.4.5 Time-stamping for archive 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 possibility. able to protect electronic signatures against this possibility.
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 time
available for crypto analysis, or improvements in crypto analytical available for crypto analysis, or improvements in crypto analytical
techniques). Before such weaknesses become likely, a verifier should techniques). Before such weaknesses become likely, a verifier should
skipping to change at page 108, line 5 skipping to change at page 108, line 5
Nested time-stamps will also protect the verifier against key Nested time-stamps will also protect the verifier against key
compromise or cracking the algorithm on the old electronic signatures. compromise or cracking the algorithm on the old electronic signatures.
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.
This technique is referred to as CAdES-A in the present document. This technique is referred to as CAdES-A in the present document.
Internet-draft CMS Advanced Electronic Signatures September 2007
C.4.6 Reference to additional data C.4.6 Reference to additional data
Using CAdES-X Type 1 or CAdES-X Type 2 extended validation data Using CAdES-X Type 1 or CAdES-X Type 2 extended validation data
verifiers still needs to keep track of all the components that were verifiers still needs to keep track of all the components that were
used to validate the signature, in order to be able to retrieve them used to validate the signature, in order to be able to retrieve them
again later on. These components may be archived by an external source again later on. These components may be archived by an external source
like a trusted service provider, in which case referenced information like a trusted service provider, in which case referenced information
that is provided as part of the ES with Complete validation data that is provided as part of the ES with Complete validation data
(CAdES-C) is adequate. The actual certificates and CRL information (CAdES-C) is adequate. The actual certificates and CRL information
reference in the CAdES-C can be gathered when needed for arbitration. reference in the CAdES-C can be gathered when needed for arbitration.
skipping to change at page 109, line 5 skipping to change at page 109, line 5
the signature from the signer can thus be provided by the signer the signature from the signer can thus be provided by the signer
together with the signed document, and/or obtained by the verifier together with the signed document, and/or obtained by the verifier
following receipt of the signed document. following receipt of the signed document.
The business scenarios may thus dictate that one or more of the long- The business scenarios may thus dictate that one or more of the long-
term signature time-stamping methods describe above be used. This may term signature time-stamping methods describe above be used. This may
be part of a mutually agreed Signature Validation Policy which is part be part of a mutually agreed Signature Validation Policy which is part
of an agreed signature policy under which digital signature may be used of an agreed signature policy under which digital signature may be used
to support the business relationship between the two parties. to support the business relationship between the two parties.
Internet-draft CMS Advanced Electronic Signatures September 2007
C.4.8 TSA key compromise C.4.8 TSA key compromise
TSA servers should be built in such a way that once the private TSA servers should be built in such a way that once the private
signature key is installed, there is minimal likelihood of compromise signature key is installed, there is minimal likelihood of compromise
over as long as possible period. Thus the validity period for the over as long as possible period. Thus the validity period for the
TSA's keys should be as long as possible. TSA's keys should be as long as possible.
Both the CAdES-T and the CAdES-C contain at least one time stamp over Both the CAdES-T and the CAdES-C contain at least one time stamp over
the signer's signature. In order to protect against the compromise of the signer's signature. In order to protect against the compromise of
the private signature key used to produce that time-stamp, the Archive the private signature key used to produce that time-stamp, the Archive
skipping to change at page 110, line 5 skipping to change at page 110, line 5
Embedded signatures are applied one after the other and are used where Embedded signatures are applied one after the other and are used where
the order the signatures are applied is important. The capability to the order the signatures are applied is important. The capability to
sign over signed data shall be provided. sign over signed data shall be provided.
These forms are described in section 5.13. All other multiple signature These forms are described in section 5.13. All other multiple signature
schemes, e.g. a signed document with a countersignature, double schemes, e.g. a signed document with a countersignature, double
countersignatures or multiple signatures, can be reduced to one or more countersignatures or multiple signatures, can be reduced to one or more
occurrence of the above two cases. occurrence of the above two cases.
Internet-draft CMS Advanced Electronic Signatures September 2007
Annex D (informative):Data protocols to interoperate with TSPs Annex D (informative):Data protocols to interoperate with TSPs
D.1 Operational protocols D.1 Operational protocols
The following protocols can be used by signers and verifiers to The following protocols can be used by signers and verifiers to
interoperate with Trusted Service Providers during the electronic interoperate with Trusted Service Providers during the electronic
signature creation and validation. signature creation and validation.
D.1.1 Certificate retrieval D.1.1 Certificate retrieval
skipping to change at page 111, line 5 skipping to change at page 111, line 5
Signers and verifiers can use the following management protocols to Signers and verifiers can use the following management protocols to
manage the use of certificates. manage the use of certificates.
D.2.1 Request for certificate revocation D.2.1 Request for certificate revocation
Request for a certificate to be revoked can be made using the Request for a certificate to be revoked can be made using the
revocation request and response messages defined in revocation request and response messages defined in
RFC 2510 [RFC2510]. RFC 2510 [RFC2510].
Internet-draft CMS Advanced Electronic Signatures September 2007
Annex E (informative): Guidance on naming Annex E (informative): Guidance on naming
E.1 Allocation of names E.1 Allocation of names
The subject name shall be allocated through a registration scheme The subject name shall be allocated through a registration scheme
administered through a Registration Authority (RA) to ensure administered through a Registration Authority (RA) to ensure
uniqueness. This RA may be an independent body or a function carried uniqueness. This RA may be an independent body or a function carried
out by the Certification Authority. out by the Certification Authority.
In addition to ensuring uniqueness, the RA shall verify that the name In addition to ensuring uniqueness, the RA shall verify that the name
skipping to change at page 112, line 5 skipping to change at page 112, line 5
- whether the registration information should be disclosed; - whether the registration information should be disclosed;
- to whom such information should be disclosed; - to whom such information should be disclosed;
- under what circumstances such information should be disclosed. - under what circumstances such information should be disclosed.
This policy may be different whether the RA is being used only within a This policy may be different whether the RA is being used only within a
company or for public use. The policy will have to take into account company or for public use. The policy will have to take into account
national legislation and in particular any data protection and privacy national legislation and in particular any data protection and privacy
legislation. legislation.
Internet-draft CMS Advanced Electronic Signatures September 2007
Currently, the provision of access to registration is a local matter Currently, the provision of access to registration is a local matter
for the RA. However, if open access is required, standard protocols for the RA. However, if open access is required, standard protocols
such as HTTP - RFC 2068 (Internet Web Access Protocol) may be employed such as HTTP - RFC 2068 (Internet Web Access Protocol) may be employed
with the addition of security mechanisms necessary to meet the data with the addition of security mechanisms necessary to meet the data
protection requirements (e.g. Transport Layer Security - RFC 2246 protection requirements (e.g. Transport Layer Security - RFC 2246
[RFC2246] with client authentication). [RFC2246] with client authentication).
E.3 Naming schemes E.3 Naming schemes
E.3.1 Naming schemes for individual citizens E.3.1 Naming schemes for individual citizens
skipping to change at page 113, line 5 skipping to change at page 113, line 5
verifier to verify that it is the right person. At the next exchange verifier to verify that it is the right person. At the next exchange
the picture does not need to be sent again. the picture does not need to be sent again.
A manual signature may be used if a signed document has been received A manual signature may be used if a signed document has been received
beforehand. In such a case, at the first exchange the drawing of the beforehand. In such a case, at the first exchange the drawing of the
manual signature is sent and the hash contained in the certificate may manual signature is sent and the hash contained in the certificate may
be used by the verifier to verify that it is the right manual be used by the verifier to verify that it is the right manual
signature. At the next exchange the manual signature does not need to signature. At the next exchange the manual signature does not need to
be sent again. be sent again.
Internet-draft CMS Advanced Electronic Signatures September 2007
E.3.2 Naming schemes for employees of an organization E.3.2 Naming schemes for employees of an organization
The name of an employee within an organization is likely to be some The name of an employee within an organization is likely to be some
combination of the name of the organization and the identifier of the combination of the name of the organization and the identifier of the
employee within that organization. employee within that organization.
An organization name is usually a registered name, i.e. business or An organization name is usually a registered name, i.e. business or
trading name used in day to day business. This name is registered by a trading name used in day to day business. This name is registered by a
Naming Authority, which guarantees that the organization's registered Naming Authority, which guarantees that the organization's registered
name is unambiguous and cannot be confused with another organization. name is unambiguous and cannot be confused with another organization.
skipping to change at page 114, line 5 skipping to change at page 114, line 5
city where the office is located. However the more information is city where the office is located. However the more information is
placed in the certificate the more problems arise if there is a change placed in the certificate the more problems arise if there is a change
in the organization structure or the place of work. So this may not be in the organization structure or the place of work. So this may not be
the best solution. An alternative is to provide more attributes (like the best solution. An alternative is to provide more attributes (like
the organization unit and the place of work) through access to a the organization unit and the place of work) through access to a
directory maintained by the company. It is likely that at the time of directory maintained by the company. It is likely that at the time of
registration the Registration Authority got more information than what registration the Registration Authority got more information than what
was placed in the certificate, if such additional information is placed was placed in the certificate, if such additional information is placed
in a repository accessible only to the organization. in a repository accessible only to the organization.
Internet-draft CMS Advanced Electronic Signatures September 2007
Annex F (informative): Example structured contents and MIME Annex F (informative): Example structured contents and MIME
F.1 Use of MIME to encode data F.1 Use of MIME to encode data
The signed content may be structured as using MIME (Multipurpose The signed content may be structured as using MIME (Multipurpose
Internet Mail Extensions - RFC 2045 [6]. Whilst the MIME structure was Internet Mail Extensions - RFC 2045 [6]. Whilst the MIME structure was
initially developed for Internet e-mail, it has a number of features initially developed for Internet e-mail, it has a number of features
which make it useful to provide a common structure for encoding a range which make it useful to provide a common structure for encoding a range
of electronic documents and other multi-media data (e.g. photographs, of electronic documents and other multi-media data (e.g. photographs,
video). These features include: video). These features include:
skipping to change at page 115, line 5 skipping to change at page 115, line 5
Other information about the content such as a description, or an Other information about the content such as a description, or an
associated file name. associated file name.
An example MIME header for text object is: An example MIME header for text object is:
Mime-Version: 1.0 Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1 Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable
Internet-draft CMS Advanced Electronic Signatures September 2007
An example MIME header for a binary file containing a pdf document is: An example MIME header for a binary file containing a pdf document is:
Content-Type: application/pdf Content-Type: application/pdf
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Description: JCFV201.pdf Content-Description: JCFV201.pdf
Content-Disposition: filename="JCFV201.pdf" Content-Disposition: filename="JCFV201.pdf"
F.1.2 Content encoding F.1.2 Content encoding
MIME supports a range of mechanisms for encoding the both text and MIME supports a range of mechanisms for encoding the both text and
skipping to change at page 116, line 5 skipping to change at page 116, line 5
=_NextPart_000_01BC4599.98004A80" =_NextPart_000_01BC4599.98004A80"
Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit
------=_NextPart_000_01BC4599.98004A80 ------=_NextPart_000_01BC4599.98004A80
Content-Type: text/plain; charset=ISO-8859-1 Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit
Per your request, I've attached our proposal for the Java Card Version Per your request, I've attached our proposal for the Java Card Version
2.0 API and the Java Card FAQ. 2.0 API and the Java Card FAQ.
Internet-draft CMS Advanced Electronic Signatures September 2007
------=_NextPart_000_01BC4599.98004A80 ------=_NextPart_000_01BC4599.98004A80
Content-Type: application/pdf; name="JCFV201.pdf" Content-Type: application/pdf; name="JCFV201.pdf"
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Description: JCFV201.pdf Content-Description: JCFV201.pdf
Content-Disposition: attachment; filename="JCFV201.pdf" Content-Disposition: attachment; filename="JCFV201.pdf"
0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAAAgAAAAA 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAAAgAAAAA
AAAAAEAAAtAAAAAEAAAD+////AAAAAAMAAAAGAAAA////////////////////////////// AAAAAEAAAtAAAAAEAAAD+////AAAAAAMAAAAGAAAA//////////////////////////////
//////////AANhAAQAYg== //////////AANhAAQAYg==
skipping to change at page 117, line 5 skipping to change at page 117, line 5
or or
- a "multipart/signed" object with the signed data and the - a "multipart/signed" object with the signed data and the
signature encoded as separate MIME objects. signature encoded as separate MIME objects.
The signed data is not included in the SignedData, and the CMS The signed data is not included in the SignedData, and the CMS
structure only includes the signature. See [RFC3851], structure only includes the signature. See [RFC3851],
section 3.4.3 “Signing Using the multipart/signed Format” and section 3.4.3 “Signing Using the multipart/signed Format” and
figure F.2 hereafter. figure F.2 hereafter.
Internet-draft CMS Advanced Electronic Signatures September 2007
+-------------++----------++-------------++------------+ +-------------++----------++-------------++------------+
| || || || | | || || || |
| S/MIME || CAdES || MIME || pdf file | | S/MIME || CAdES || MIME || pdf file |
| || || || | | || || || |
|Content-Type=||SignedData||Content-Type=||Dear MrSmith| |Content-Type=||SignedData||Content-Type=||Dear MrSmith|
|application/ || eContent ||application/ ||Received | |application/ || eContent ||application/ ||Received |
|pkcs7-mime || ||pdf || 100 tins | |pkcs7-mime || ||pdf || 100 tins |
| || || || | | || || || |
|smime-type= || /| || /| || Mr.Jones | |smime-type= || /| || /| || Mr.Jones |
|signed-data || / -----+ / ------+ | |signed-data || / -----+ / ------+ |
skipping to change at page 118, line 4 skipping to change at page 118, line 4
message. In this case the signed data is not included in the message. In this case the signed data is not included in the
SignedData, and the CMS structure only includes the signature. See SignedData, and the CMS structure only includes the signature. See
[RFC3851], section 3.4.3 “Signing Using the multipart/signed Format” [RFC3851], section 3.4.3 “Signing Using the multipart/signed Format”
and figure F.2 herafter. and figure F.2 herafter.
An example of signed data encoded this approach is: An example of signed data encoded this approach is:
Content-Type: multipart/signed; Content-Type: multipart/signed;
protocol="application/pkcs7-signature"; protocol="application/pkcs7-signature";
micalg=sha1; boundary=boundary42 micalg=sha1; boundary=boundary42
Internet-draft CMS Advanced Electronic Signatures September 2007
--boundary42 --boundary42
Content-Type: text/plain Content-Type: text/plain
This is a clear-signed message. This is a clear-signed message.
--boundary42 --boundary42
Content-Type: application/pkcs7-signature; name=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s Content-Disposition: attachment; filename=smime.p7s
skipping to change at page 119, line 5 skipping to change at page 119, line 5
| \ -------+ | | \ -------+ |
| \| ||----------+ | | | \| ||----------+ | |
+---------------+ +---------------+
Figure F.2. Signing Using application/pkcs7-signature Figure F.2. Signing Using application/pkcs7-signature
This second approach (multipart/signed) has the advantage that the This second approach (multipart/signed) has the advantage that the
signed data can be decoded by any MIME compatible system even if signed data can be decoded by any MIME compatible system even if
it does not recognize CMS encoded electronic signatures. it does not recognize CMS encoded electronic signatures.
Internet-draft CMS Advanced Electronic Signatures September 2007
Annex G (informative): Relationship to the European Directive and EESSI Annex G (informative): Relationship to the European Directive and EESSI
G.1 Introduction G.1 Introduction
This annex provides an indication of the relationship between This annex provides an indication of the relationship between
electronic signatures created under the present document and electronic signatures created under the present document and
requirements under the European Parliament and Council Directive on a requirements under the European Parliament and Council Directive on a
Community framework for electronic signatures. Community framework for electronic signatures.
NOTE: Legal advice should be sought on the specific national NOTE: Legal advice should be sought on the specific national
skipping to change at page 120, line 4 skipping to change at page 120, line 4
under his sole control; and under his sole control; and
d) it is linked to the data to which it relates in such a d) it is linked to the data to which it relates in such a
manner that any subsequent change of the data is detectable. manner that any subsequent change of the data is detectable.
- it is based on a certificate which meets detailed criteria given - it is based on a certificate which meets detailed criteria given
in annex I to the directive and is issued by a "certification- in annex I to the directive and is issued by a "certification-
service-provider" which meets requirements given in annex II to service-provider" which meets requirements given in annex II to
the directive. Such a certificate is referred to as a "qualified the directive. Such a certificate is referred to as a "qualified
certificate"; certificate";
Internet-draft CMS Advanced Electronic Signatures September 2007
- it is created by a "device" which detailed criteria given in - it is created by a "device" which detailed criteria given in
annex III to the directive. Such a device is referred to a annex III to the directive. Such a device is referred to a
"secure-signature-creation device"; "secure-signature-creation device";
This form of electronic signature is referred to as a "qualified This form of electronic signature is referred to as a "qualified
electronic signature" in EESSI (see below). electronic signature" in EESSI (see below).
G.3 ETSI electronic signature formats and the directive G.3 ETSI electronic signature formats and the directive
An electronic signature created in accordance with the present document An electronic signature created in accordance with the present document
skipping to change at page 121, line 5 skipping to change at page 121, line 5
- procedures for Electronic Signature Verification; - procedures for Electronic Signature Verification;
- electronic signature syntax and encoding formats; - electronic signature syntax and encoding formats;
- protocol to interoperate with a Time Stamping Authority; - protocol to interoperate with a Time Stamping Authority;
- Policy requirements for Time-Stamping Authorities; - Policy requirements for Time-Stamping Authorities;
- XML electronic signature formats. - XML electronic signature formats.
Internet-draft CMS Advanced Electronic Signatures September 2007
Each of these standards addresses a range of requirements including Each of these standards addresses a range of requirements including
the requirements of Qualified Electronic Signatures as specified in the requirements of Qualified Electronic Signatures as specified in
article 5.1 of the Directive. However, some of them also address article 5.1 of the Directive. However, some of them also address
general requirements of electronic signatures for business and general requirements of electronic signatures for business and
electronic commerce which all fall into the category of article 5.2 of electronic commerce which all fall into the category of article 5.2 of
the Directive. Such variation in the requirements may be identified the Directive. Such variation in the requirements may be identified
either as different levels or different options. either as different levels or different options.
G.4.2 Classes of electronic signatures G.4.2 Classes of electronic signatures
skipping to change at page 122, line 5 skipping to change at page 122, line 5
Annex H (informative):APIs for the generation and verification of Annex H (informative):APIs for the generation and verification of
electronic signatures tokens electronic signatures tokens
While the present document describes the data format of an electronic While the present document describes the data format of an electronic
signature, the question is whether there exists APIs (Application signature, the question is whether there exists APIs (Application
Programming Interfaces) able to manipulate these structures. At least Programming Interfaces) able to manipulate these structures. At least
two such APIs have been defined. One set by the IETF and another set two such APIs have been defined. One set by the IETF and another set
by the OMG (Object Management Group). by the OMG (Object Management Group).
Internet-draft CMS Advanced Electronic Signatures September 2007
H.1 Data framing H.1 Data framing
In order to be able to use either of these APIs, it will be necessary In order to be able to use either of these APIs, it will be necessary
to frame the previously defined electronic signature data structures to frame the previously defined electronic signature data structures
using a mechanism-independent token format. Section 3.1 of RFC 2743 using a mechanism-independent token format. Section 3.1 of RFC 2743
[RFC2743] describes that framing incorporating an identifier of the [RFC2743] describes that framing incorporating an identifier of the
mechanism type to be used and enabling tokens to be interpreted mechanism type to be used and enabling tokens to be interpreted
unambiguously. unambiguously.
In order to be processable by these APIs, all electronic signature data In order to be processable by these APIs, all electronic signature data
skipping to change at page 123, line 5 skipping to change at page 123, line 5
3) 0x06 -- Tag for OBJECT IDENTIFIER. 3) 0x06 -- Tag for OBJECT IDENTIFIER.
4) Object identifier length -- length (number of octets) of the 4) Object identifier length -- length (number of octets) of the
encoded object identifier contained in element 5, encoded per encoded object identifier contained in element 5, encoded per
rules as described in 2a) and 2b) above. rules as described in 2a) and 2b) above.
5) object identifier octets -- variable number of octets, encoded 5) object identifier octets -- variable number of octets, encoded
per ASN.1 BER rules: per ASN.1 BER rules:
Internet-draft CMS Advanced Electronic Signatures September 2007
- The first octet contains the sum of two values: - The first octet contains the sum of two values:
(1) the top-level object identifier component, multiplied by (1) the top-level object identifier component, multiplied by
40 (decimal); and 40 (decimal); and
(2) the second-level object identifier component. (2) the second-level object identifier component.
This special case is the only point within an object This special case is the only point within an object
identifier encoding where a single octet represents contents identifier encoding where a single octet represents contents
of more than one component. of more than one component.
skipping to change at page 124, line 5 skipping to change at page 124, line 5
Protection) able to handle the electronic signature data format Protection) able to handle the electronic signature data format
defined in the present document. defined in the present document.
The IDUP-GSS-API includes support for non-repudiation services. The IDUP-GSS-API includes support for non-repudiation services.
It supports evidence generation, where "evidence" is information that It supports evidence generation, where "evidence" is information that
either by itself, or when used in conjunction with other information, either by itself, or when used in conjunction with other information,
is used to establish proof about an event or action, as well a evidence is used to establish proof about an event or action, as well a evidence
verification. verification.
Internet-draft CMS Advanced Electronic Signatures September 2007
IDUP supports various types of evidences. All the types defined in IDUP supports various types of evidences. All the types defined in
IDUP are supported in the present document through the commitment type IDUP are supported in the present document through the commitment type
parameter. parameter.
Section 2.3.3 of IDUP describes the specific calls needed to handle Section 2.3.3 of IDUP describes the specific calls needed to handle
evidences ("EV" calls). The "EV" group of calls provides a simple, evidences ("EV" calls). The "EV" group of calls provides a simple,
high-level interface to underlying IDUP mechanisms when application high-level interface to underlying IDUP mechanisms when application
developers need to deal only with evidences but not with encryption or developers need to deal only with evidences but not with encryption or
integrity services. integrity services.
skipping to change at page 125, line 5 skipping to change at page 125, line 5
includes it in the token so that verification can be guaranteed to be includes it in the token so that verification can be guaranteed to be
possible at any future time. possible at any future time.
H.3 CORBA security interfaces defined by the OMG H.3 CORBA security interfaces defined by the OMG
Non-repudiation interfaces have been defined in "CORBA Security", a Non-repudiation interfaces have been defined in "CORBA Security", a
document produced by the OMG (Object Management Group). These document produced by the OMG (Object Management Group). These
interfaces are described in IDL (Interface Definition Language) and are interfaces are described in IDL (Interface Definition Language) and are
optional. optional.
Internet-draft CMS Advanced Electronic Signatures September 2007
The handling of "tokens" supporting non-repudiation is done through the The handling of "tokens" supporting non-repudiation is done through the
following interfaces: following interfaces:
- set_NR_features specifies the features to apply to future - set_NR_features specifies the features to apply to future
evidence generation and verification operations; evidence generation and verification operations;
- get_NR_features returns the features which will be applied to - get_NR_features returns the features which will be applied to
future evidence generation and verification operations; future evidence generation and verification operations;
- generate_token generates a Non-repudiation token using the - generate_token generates a Non-repudiation token using the
skipping to change at page 126, line 5 skipping to change at page 126, line 5
does not contain all the data required for its verification, and does not contain all the data required for its verification, and
it is anticipated that some of the data not stored in the token it is anticipated that some of the data not stored in the token
may become unavailable during the interval between generation of may become unavailable during the interval between generation of
the evidence token and verification unless it is stored in the the evidence token and verification unless it is stored in the
token. The form_complete_evidence operation gathers the missing token. The form_complete_evidence operation gathers the missing
information and includes it in the token so that verification can information and includes it in the token so that verification can
be guaranteed to be possible at any future time. be guaranteed to be possible at any future time.
NOTE: The similarity between the two sets of APIs is noticeable. NOTE: The similarity between the two sets of APIs is noticeable.
Internet-draft CMS Advanced Electronic Signatures September 2007
Annex I (informative):Cryptographic algorithms Annex I (informative):Cryptographic algorithms
RFC 3370 [10] describes the conventions for using several cryptographic RFC 3370 [10] describes the conventions for using several cryptographic
algorithms with the Crytographic Message Syntax (CMS). Only the algorithms with the Crytographic Message Syntax (CMS). Only the
hashing and signing algorithms are appropriate for use with the present hashing and signing algorithms are appropriate for use with the present
document. document.
Since the publication of RFC 3370 [10], MD5 has been broken. This Since the publication of RFC 3370 [10], MD5 has been broken. This
algorithm is no more considered as appropriate and has been deleted algorithm is no more considered as appropriate and has been deleted
from the list of algorithms. from the list of algorithms.
skipping to change at page 127, line 5 skipping to change at page 127, line 5
- ISO/IEC 10118-3 (1997) [ISO10118-3]: "Information technology - - ISO/IEC 10118-3 (1997) [ISO10118-3]: "Information technology -
Security techniques - Hash-functions - Part 3: Dedicated Security techniques - Hash-functions - Part 3: Dedicated
hash-functions". ISO/IEC 10118-3 specifies the following hash-functions". ISO/IEC 10118-3 specifies the following
dedicated hash-functions: dedicated hash-functions:
- SHA-1 (FIPS 180-1); - SHA-1 (FIPS 180-1);
- RIPEMD-128; - RIPEMD-128;
- RIPEMD-160. - RIPEMD-160.
Internet-draft CMS Advanced Electronic Signatures September 2007
- ISO/IEC 10118-4 (1998) [ISO10118-4]: "Information technology - - ISO/IEC 10118-4 (1998) [ISO10118-4]: "Information technology -
Security techniques - Hash-functions - Part 4: Hash-functions Security techniques - Hash-functions - Part 4: Hash-functions
using modular arithmetic". using modular arithmetic".
- RFC 1320 (PS 1992): "The MD4 Message-Digest Algorithm". RFC 1320 - RFC 1320 (PS 1992): "The MD4 Message-Digest Algorithm". RFC 1320
specifies the hash-function MD4. Today, MD4 is considered out- specifies the hash-function MD4. Today, MD4 is considered out-
dated. dated.
- RFC 1321 (I 1992): "The MD5 Message-Digest Algorithm". RFC 1321 - RFC 1321 (I 1992): "The MD5 Message-Digest Algorithm". RFC 1321
(informational) specifies the hash-unction MD5. Today, MD5 is (informational) specifies the hash-unction MD5. Today, MD5 is
skipping to change at page 128, line 5 skipping to change at page 128, line 5
The RSA signature algorithm is defined in RFC 2437 [RFC2437]. The RSA signature algorithm is defined in RFC 2437 [RFC2437].
RFC 3370 [10] specifies the use of the RSA signature algorithm with RFC 3370 [10] specifies the use of the RSA signature algorithm with
the SHA-1 algorithm. The algorithm identifier for RSA with SHA-1 is: the SHA-1 algorithm. The algorithm identifier for RSA with SHA-1 is:
Sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) Sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 } us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 }
NOTE: RFC 3370 [10] recommends that MD5 is not used for new NOTE: RFC 3370 [10] recommends that MD5 is not used for new
implementations. implementations.
Internet-draft CMS Advanced Electronic Signatures September 2007
I.2.3 General I.2.3 General
The following is a selection of work that has been done in the area of The following is a selection of work that has been done in the area of
digital signature mechanisms: digital signature mechanisms:
- FIPS Publication 186 (1994): "Digital Signature Standard". - FIPS Publication 186 (1994): "Digital Signature Standard".
NIST's Digital Signature Algorithm (DSA) is a variant of NIST's Digital Signature Algorithm (DSA) is a variant of
ElGamal's Discrete Logarithm based digital signature mechanism. ElGamal's Discrete Logarithm based digital signature mechanism.
The DSA requires a 160-bit hash-function and mandates SHA-1. The DSA requires a 160-bit hash-function and mandates SHA-1.
skipping to change at page 129, line 5 skipping to change at page 129, line 5
giving message recovery - Part 4: Discrete logarithm based giving message recovery - Part 4: Discrete logarithm based
mechanisms". ISO/IEC 9796-4 specifies digital signature mechanisms". ISO/IEC 9796-4 specifies digital signature
mechanisms with partial message recovery that are based on mechanisms with partial message recovery that are based on
Discrete Logarithm techniques. The document includes the Discrete Logarithm techniques. The document includes the
Nyberg-Rueppel scheme. Nyberg-Rueppel scheme.
- ISO/IEC 14888-1 [ISO14888-1]: "Digital signatures with appendix - - ISO/IEC 14888-1 [ISO14888-1]: "Digital signatures with appendix -
Part 1: General". ISO/IEC 14888-1 contains definitions and Part 1: General". ISO/IEC 14888-1 contains definitions and
describes the basic concepts of digital signatures with appendix. describes the basic concepts of digital signatures with appendix.
Internet-draft CMS Advanced Electronic Signatures September 2007
- ISO/IEC 14888-2 [ISO14888-2]: "Digital signatures with appendix - - ISO/IEC 14888-2 [ISO14888-2]: "Digital signatures with appendix -
Part 2: Identity-based mechanisms". ISO/IEC 14888-2 specifies Part 2: Identity-based mechanisms". ISO/IEC 14888-2 specifies
digital signature schemes with appendix that make use of digital signature schemes with appendix that make use of
identity-based keying material. The document includes the identity-based keying material. The document includes the
zero-knowledge techniques of Fiat-Shamir and Guillou-Quisquater. zero-knowledge techniques of Fiat-Shamir and Guillou-Quisquater.
- ISO/IEC 14888-3 [ISO14888-3]: "Digital signatures with appendix - - ISO/IEC 14888-3 [ISO14888-3]: "Digital signatures with appendix -
Part 3: Certificate-based mechanisms". ISO/IEC 14888-3 specifies Part 3: Certificate-based mechanisms". ISO/IEC 14888-3 specifies
digital signature schemes with appendix that make use of digital signature schemes with appendix that make use of
certificate-based keying material. The document includes five certificate-based keying material. The document includes five
skipping to change at page 130, line 5 skipping to change at page 130, line 5
specifies the DSA, NIST's Digital Signature Algorithm. specifies the DSA, NIST's Digital Signature Algorithm.
- ANSI X9.62 (1998) [X9.62]: "Public Key Cryptography for the - ANSI X9.62 (1998) [X9.62]: "Public Key Cryptography for the
Financial Services Industry - The Elliptic Curve Digital Financial Services Industry - The Elliptic Curve Digital
Signature Algorithm (ECDSA)". ANSI X9.62 specifies the Elliptic Signature Algorithm (ECDSA)". ANSI X9.62 specifies the Elliptic
Curve Digital Signature Algorithm, an analog of NIST's Digital Curve Digital Signature Algorithm, an analog of NIST's Digital
Signature Algorithm (DSA) using elliptic curves. The appendices Signature Algorithm (DSA) using elliptic curves. The appendices
provide tutorial information on the underlying mathematics for provide tutorial information on the underlying mathematics for
elliptic curve cryptography and many examples. elliptic curve cryptography and many examples.
Internet-draft CMS Advanced Electronic Signatures September 2007
Annex J (informative): Changes from the previous version Annex J (informative): Changes from the previous version
The title of the document has changed to be aligned with the title The title of the document has changed to be aligned with the title
of XAdES (XML Advanced Electronic Signatures), the vocabulary used of XAdES (XML Advanced Electronic Signatures), the vocabulary used
within the present document has been aligned with the vocabulary within the present document has been aligned with the vocabulary
used in XAdES, used in XAdES,
If the hash of the signature policy is unknown, then, by If the hash of the signature policy is unknown, then, by
convention, the sigPolicyHash shall be set to all zeros. convention, the sigPolicyHash shall be set to all zeros.
skipping to change at page 131, line 5 skipping to change at page 131, line 5
hashing algorithm is used, while the ESS signing-certificate hashing algorithm is used, while the ESS signing-certificate
attribute v2, defined in “ESS Update: Adding CertID Algorithm attribute v2, defined in “ESS Update: Adding CertID Algorithm
Agility RFC 5035 shall be used when other hashing algorithms Agility RFC 5035 shall be used when other hashing algorithms
are to be used. are to be used.
- the definition of the Archive time-stamp attribute has been - the definition of the Archive time-stamp attribute has been
changed in section 6.4.1. to protect all signed and unsined changed in section 6.4.1. to protect all signed and unsined
attributes. A new object identifier has been assigned to this attributes. A new object identifier has been assigned to this
attribute. attribute.
Internet-draft CMS Advanced Electronic Signatures September 2007
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on This document and the information contained herein are provided on
An "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE An "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
skipping to change at page 132, line 5 skipping to change at page 132, line 5
to pertain to the implementation or use of the technology described to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights. it has made any independent effort to identify any such rights.
Information on the ETSI Intellectual Property Rights Policy may be Information on the ETSI Intellectual Property Rights Policy may be
obtained from <http://www.etsi.org/legal/home.htm>. The document is obtained from <http://www.etsi.org/legal/home.htm>. The document is
an extract from Annex 6 of the ETSI Rules of Procedure that are an extract from Annex 6 of the ETSI Rules of Procedure that are
available at : <http://portal.etsi.org/directives/home.asp>. available at : <http://portal.etsi.org/directives/home.asp>.
Internet-draft CMS Advanced Electronic Signatures September 2007
The ETSI IPR database http://webapp.etsi.org/IPR/home.asp contains The ETSI IPR database http://webapp.etsi.org/IPR/home.asp contains
IPRs, particularly patents and patent applications, which have been IPRs, particularly patents and patent applications, which have been
notified to ETSI as being essential, or potentially essential, to notified to ETSI as being essential, or potentially essential, to
ETSI standards. Unless otherwise specified, all IPRs contained ETSI standards. Unless otherwise specified, all IPRs contained
herein have been notified to ETSI, with an undertaking from the herein have been notified to ETSI, with an undertaking from the
owner to grant licenses according to the terms and conditions of owner to grant licenses according to the terms and conditions of
Article 6.1 of Annex 6 of the ETSI Rules of the ETSI IPR Policy. Article 6.1 of Annex 6 of the ETSI Rules of the ETSI IPR Policy.
The ETSI IPR database provides data that is based on the information The ETSI IPR database provides data that is based on the information
received. ETSI has not checked the validity of the information, nor received. ETSI has not checked the validity of the information, nor
 End of changes. 135 change blocks. 
14 lines changed or deleted 300 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/