draft-ietf-smime-cades-03.txt   draft-ietf-smime-cades-04.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 November 2007 J.Ross(Security and Standards) Expires March 2008 J.Ross (Security and Standards)
Obsoletes: RFC 3126 August 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-03.txt> <draft-ietf-smime-cades-04.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 1, line 51 skipping to change at page 1, line 51
This document defines the format of an electronic signature that can This document defines the format of an electronic signature that can
remain valid over long periods. This includes evidence as to its remain valid over long periods. This includes evidence as to its
validity even if the signer or verifying party later attempts to deny validity even if the signer or verifying party later attempts to deny
(i.e., repudiates the validity of the signature). (i.e., repudiates the validity of the signature).
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.6.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.
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
skipping to change at page 15, line 30 skipping to change at page 15, line 30
- Message-digest. It is defined in RFC 3852 [4] and specifies the - Message-digest. It is defined in RFC 3852 [4] and specifies the
message digest of the eContent OCTET STRING within message digest of the eContent OCTET STRING within
encapContentInfo being signed. Details are provided in section encapContentInfo being signed. Details are provided in section
5.7.2; 5.7.2;
- ESS signing-certificate OR ESS signing-certificate v2. The ESS - ESS signing-certificate OR ESS signing-certificate v2. The ESS
signing-certificate attribute is defined in Enhanced Security signing-certificate attribute is defined in Enhanced Security
Services (ESS), RFC 2634 [5] and only allows for the use of SHA-1 Services (ESS), RFC 2634 [5] and only allows for the use of SHA-1
as digest algorithm. The ESS signing-certificate attribute V2 as digest algorithm. The ESS signing-certificate attribute V2
is defined in “ESS Update: Adding CertID Algorithm Agility” [15], is defined in “ESS Update: Adding CertID Algorithm Agility”
and allows for the use of any digest algorithm. A CAdES-BES RFC 5035 [15], and allows for the use of any digest algorithm.
claiming compliance with the present document must include one of A CAdES-BES claiming compliance with the present document must
them. Section 5.7.3 provides the details of these attributes. include one of them. Section 5.7.3 provides the details of
Rationale for its inclusion is provided in section C.3.3. these attributes. Rationale for its inclusion is provided in
section C.3.3.
Optional signed attributes may be added to the CAdES-BES, including Optional signed attributes may be added to the CAdES-BES, including
optional signed attributes defined in CMS (RFC 3852 [4]), ESS (RFC 2634 optional signed attributes defined in CMS (RFC 3852 [4]), ESS (RFC 2634
[5]) and the present document. Listed below are optional attributes [5]) and the present document. Listed below are optional attributes
that are defined in section 5 and have a rational provided in annex C: that are defined in section 5 and have a rational provided in annex C:
- Signing-time: as defined in CMS (RFC 3852 [4]) indicates the time - Signing-time: as defined in CMS (RFC 3852 [4]) indicates the time
of the signature as claimed by the signer. Details and short of the signature as claimed by the signer. Details and short
rationale are provided in section 5.9.1. Section C.3.6 provides rationale are provided in section 5.9.1. Section C.3.6 provides
the rationale. the rationale.
skipping to change at page 22, line 40 skipping to change at page 22, line 40
4.4.3.1 EXtended Long Electronic Signature (CAdES-X Long) 4.4.3.1 EXtended Long Electronic Signature (CAdES-X Long)
Extended Long format (CAdES-X Long) in accordance with the present Extended Long format (CAdES-X Long) in accordance with the present
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 of specification details. Section B.1.1 gives details on the production
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.
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 | |
skipping to change at page 29, line 52 skipping to change at page 29, line 52
5.3 Signed-data content type 5.3 Signed-data content type
The signed-data content type of the ES is as defined in CMS (RFC 3852 The signed-data content type of the ES is as defined in CMS (RFC 3852
[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 (RFC The fields of type SignedData have the meanings as defined in CMS
3852 [4]). (RFC 3852 [4]).
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 21 skipping to change at page 31, line 21
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]).
5.6.3 Message signature verification process 5.6.3 Message signature verification process
The procedures for message signature verification are defined in CMS The procedures for message signature verification are defined in CMS
(RFC 3852 [4]) and enhanced in the present document: the input to the (RFC 3852 [4]) and enhanced in the present document: the input to the
signature verification process MUST be the signer's public key which signature verification process MUST be the signer's public key which
SHALL be verified as correct using the signing certificate reference SHALL be verified as correct using the signing certificate reference
attribute containing a reference to the signing certificate, e.g. when SigningCertificate from ESS [RFC 2634] is used, the public key from attribute containing a reference to the signing certificate, e.g. when
SigningCertificate from ESS [RFC 2634] is used, the public key from
the first certificate identified in the sequence of certificate the first certificate identified in the sequence of certificate
identifiers from SigningCertificate MUST be the key used to verify the identifiers from SigningCertificate MUST be the key used to verify the
digital signature. digital signature.
5.7 Basic ES mandatory present attributes 5.7 Basic ES mandatory present attributes
The following attributes shall be present with the signed-data defined The following attributes shall be present with the signed-data defined
by the present document. The attributes are defined in CMS (RFC 3852 by the present document. The attributes are defined in CMS (RFC 3852
[4]). [4]).
skipping to change at page 32, line 30 skipping to change at page 32, line 30
full certificate) that allows to a certificate to be unambiguously full certificate) that allows to a certificate to be unambiguously
identified. identified.
One, and only one, of the following alternative attributes shall be One, and only one, of the following alternative attributes shall be
present with the signedData defined by the present document. present with the signedData defined by the present document.
- The ESS signing-certificate attribute, defined in ESS [RFC 2634], - The ESS signing-certificate attribute, defined in ESS [RFC 2634],
MUST be used if the SHA-1 hashing algorithm is used. MUST be used if the SHA-1 hashing algorithm is used.
- The ESS signing-certificate attribute v2, defined in “ESS Update: - The ESS signing-certificate attribute v2, defined in “ESS Update:
Adding CertID Algorithm Agility”, shortly to be published as an Adding CertID Algorithm Agility”, RFC 5035 [15] which SHALL be
RFC [15] SHALL be used when other hashing algorithms are to be used. used when other hashing algorithms are to be used.
The certificate to be used to verify the signature shall be identified The certificate to be used to verify the signature shall be identified
in the sequence (i.e. the certificate from the signer) and the sequence in the sequence (i.e. the certificate from the signer) and the sequence
shall not be empty. The signature validation policy may mandate other shall not be empty. The signature validation policy may mandate other
certificates be present that may include all the certificates up to the certificates be present that may include all the certificates up to the
trust anchor. trust anchor.
5.7.3.1 ESS signing certificate attribute definition 5.7.3.1 ESS signing certificate attribute definition
The syntax of the signing-certificate attribute type of the ES is as The syntax of the signing-certificate attribute type of the ES is as
skipping to change at page 33, line 17 skipping to change at page 33, line 17
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.
The syntax of the signing-certificate v2 attribute type of the ES is as The syntax of the signing-certificate v2 attribute type of the ES is as
defined in “ESS Update: Adding CertID Algorithm Agility”, shortly to be published as an RFC [15], and further qualified in the present document. defined in “ESS Update: Adding CertID Algorithm Agility”, RFC 5035 [15]
and further qualified in the present document.
The sequence of policy information field is not used in the present The sequence of policy information field is not used in the present
document. document.
This attribute shall be used in the same manner as defined above for This attribute shall be used in the same manner as defined above for
the ESS signing-certificate attribute. the ESS signing-certificate attribute.
The object identifier for this attribute is: The object identifier for this attribute is:
id-aa-signingCertificateV2 OBJECT IDENTIFIER ::= id-aa-signingCertificateV2 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 36, line 45 skipping to change at page 36, line 45
The following attributes may be present with the signed-data, the The following attributes may be present with the signed-data, the
attributes are defined in CMS (RFC 3852 [4]) and are imported into the attributes are defined in CMS (RFC 3852 [4]) and are imported into the
present document. Were appropriated the attributes are qualified and present document. Were appropriated the attributes are qualified and
profiled by the present document. profiled by the present document.
5.9.1 Signing time 5.9.1 Signing time
The signing-time attribute specifies the time at which the signer The signing-time attribute specifies the time at which the signer
claims to have performed the signing process. claims to have performed the signing process.
Signing-time attribute values for ES have the ASN.1 type SigningTime as Signing-time attribute values for ES have the ASN.1 type SigningTime
defined in CMS (RFC 3852 [4]). as defined in CMS (RFC 3852 [4]).
NOTE: RFC 3852 [4] states that dates between 1 January 1950 and 31 NOTE: RFC 3852 [4] states that dates between 1 January 1950 and 31
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
skipping to change at page 44, line 29 skipping to change at page 44, line 29
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}
The signature-time-stamp attribute value has ASN.1 type The signature-time-stamp attribute value has ASN.1 type
SignatureTimeStampToken: SignatureTimeStampToken:
SignatureTimeStampToken ::= TimeStampToken SignatureTimeStampToken ::= TimeStampToken
The value of messageImprint field within TimeStampToken shall be a hash The value of messageImprint field within TimeStampToken shall be a
of the value of the signature field within SignerInfo for the hash of the value of the signature field within SignerInfo for the
signedData being time-stamped. signedData being time-stamped.
For further information and definition of TimeStampToken see For further information and definition of TimeStampToken see
section 7.4. section 7.4.
NOTE 1: In the case of multiple signatures it is possible to have a NOTE 1: In the case of multiple signatures it is possible to have a
TimeStampToken computed for each and all signers, or TimeStampToken computed for each and all signers, or
TimeStampToken computed on one signer's signature and no TimeStampToken computed on one signer's signature and no
TimeStampToken on another signer's signature. TimeStampToken on another signer's signature.
NOTE 2: In the case of multiple signatures, several TSTs, issued by NOTE 2: In the case of multiple signatures, several TSTs, issued by
different TSAs, may be present within the same signerInfo
different TSAs, may be present within the same signerInfo (see (see RFC 3852 [4]).
RFC 3852 [4]).
6.2 Complete validation reference data (CAdES-C) 6.2 Complete validation reference data (CAdES-C)
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:
skipping to change at page 50, line 10 skipping to change at page 50, line 10
attribute: attribute:
id-aa-ets-certValues OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-aa-ets-certValues OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 23} us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 23}
The certificate-values attribute value has the ASN.1 syntax The certificate-values attribute value has the ASN.1 syntax
CertificateValues. CertificateValues.
CertificateValues ::= SEQUENCE OF Certificate CertificateValues ::= SEQUENCE OF Certificate
Certificate is defined in section 7.1. (which is as defined in ITU-T Recommendation X.509 [1]. Certificate is defined in section 7.1. (which is as defined in ITU-T
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
already included in the TSTs as part of the TSUs signatures. In this already included in the TSTs as part of the TSUs signatures. In this
case the unsigned attribute shall be added to the signedData of the case the unsigned attribute shall be added to the signedData of the
relevant timestamp token. relevant timestamp token.
6.3.4 Revocation values attribute definition 6.3.4 Revocation values attribute definition
This attribute is used to contain the revocation information required This attribute is used to contain the revocation information required
skipping to change at page 53, line 57 skipping to change at page 53, line 57
- 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. The archiveTimestamp
attribute defined in versions of TS 101 733 prior to 1.5.1 is attribute defined in versions of TS 101 733 prior to 1.5.1 is
not compatible with the attribute defined in the current not compatible with the attribute defined in the current
document. The archiveTimestamp attribute defined in versions document. The archiveTimestamp attribute defined in versions
1.5.1 to 1.6.3 of TS 101 733 is compatible with current 1.5.1 to 1.7.3 of TS 101 733 is compatible with current
document if the content is internal to encapContentInfo. document if the content is internal to encapContentInfo.
Unless the version of TS 101 733 employed by the signing party Unless the version of TS 101 733 employed by the signing party
is known by all recipients, use of the archiveTimestamp is known by all recipients, use of the archiveTimestamp
attribute defined in prior versions of TS 101 733 is attribute defined in prior versions of TS 101 733 is
deprecated. 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.
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)".
[15] IETF RFC XXXX (2006). 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
of the Council of 13 December 1999 on a Community framework for of the Council of 13 December 1999 on a Community framework for
electronic signatures. electronic signatures.
[TS101733] ETSI Standard TS 101 733 V.1.6.3 (2005-06) Electronic [TS101733] ETSI Standard TS 101 733 V.1.7.3 (2005-06) Electronic
Signature Formats. Signature Formats.
[TS101861] ETSI TS 101 861: "Time stamping profile". [TS101861] ETSI TS 101 861: "Time stamping profile".
[TS101903] ETSI TS 101 903: "XML Advanced Electronic Signatures [TS101903] ETSI TS 101 903: "XML Advanced Electronic Signatures
(XAdES)". (XAdES)".
[TS102023] ETSI TS 102 023: "Electronic Signatures and [TS102023] ETSI TS 102 023: "Electronic Signatures and
Infrastructures (ESI); Policy requirements for time-stamping Infrastructures (ESI); Policy requirements for time-stamping
authorities". authorities".
skipping to change at page 64, line 39 skipping to change at page 64, line 39
ContentInfo, ContentType, id-data, id-signedData, SignedData, ContentInfo, ContentType, id-data, id-signedData, SignedData,
EncapsulatedContentInfo, SignerInfo, id-contentType, EncapsulatedContentInfo, SignerInfo, id-contentType,
id-messageDigest, MessageDigest, id-signingTime, SigningTime, id-messageDigest, MessageDigest, id-signingTime, SigningTime,
id-countersignature, Countersignature id-countersignature, Countersignature
FROM CryptographicMessageSyntax2004 FROM CryptographicMessageSyntax2004
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) cms-2004(24) } smime(16) modules(0) cms-2004(24) }
-- ESS Defined attributes: ESS Update -- ESS Defined attributes: ESS Update
-- RFC 5035 (Adding CertID Algorithm Agility)
id-aa-signingCertificate, SigningCertificate, IssuerSerial, id-aa-signingCertificate, SigningCertificate, IssuerSerial,
id-aa-contentReference, ContentReference, id-aa-contentIdentifier, id-aa-contentReference, ContentReference, id-aa-contentIdentifier,
ContentIdentifier, id-aa-signingCertificatev2 ContentIdentifier, id-aa-signingCertificatev2
FROM ExtendedSecurityServices-2006 FROM ExtendedSecurityServices-2006
{ iso(1) member-body(2) us(840) rsadsi(113549) { iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) 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
skipping to change at page 72, line 34 skipping to change at page 72, line 34
ContentInfo, ContentType, id-data, id-signedData, SignedData, ContentInfo, ContentType, id-data, id-signedData, SignedData,
EncapsulatedContentInfo, SignerInfo, EncapsulatedContentInfo, SignerInfo,
id-contentType, id-messageDigest, MessageDigest, id-signingTime, id-contentType, id-messageDigest, MessageDigest, id-signingTime,
SigningTime, id-countersignature, Countersignature SigningTime, id-countersignature, Countersignature
FROM CryptographicMessageSyntax2004 FROM CryptographicMessageSyntax2004
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) cms-2004(24) } smime(16) modules(0) cms-2004(24) }
-- ESS Defined attributes: ESS Update -- ESS Defined attributes: ESS Update
-- RFC 5035 (Adding CertID Algorithm Agility)
id-aa-signingCertificate, SigningCertificate, IssuerSerial, id-aa-signingCertificate, SigningCertificate, IssuerSerial,
id-aa-contentReference, ContentReference, id-aa-contentIdentifier, id-aa-contentReference, ContentReference, id-aa-contentIdentifier,
ContentIdentifier, id-aa-signingCertificatev2 ContentIdentifier, id-aa-signingCertificatev2
FROM ExtendedSecurityServices-2006 FROM ExtendedSecurityServices-2006
{ iso(1) member-body(2) us(840) rsadsi(113549) { iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) 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 -- Internet X.509 Public Key Infrastructure
-- Certificate and CRL Profile: RFC 3280 -- Certificate and CRL Profile: RFC 3280
skipping to change at page 98, line 55 skipping to change at page 98, line 55
In many real life environments users will be able to get from different In many real life environments users will be able to get from different
CAs or even from the same CA, different certificates containing the CAs or even from the same CA, different certificates containing the
same public key for different names. The prime advantage is that a same public key for different names. The prime advantage is that a
user can use the same private key for different purposes. Multiple use user can use the same private key for different purposes. Multiple use
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 was used when generating the signature. Where there is the possibility
possibility that multiple private keys are used, it is necessary for that multiple private keys are used, it is necessary for the signer to
the signer to indicate to the verifier the precise certificate to be indicate to the verifier the precise certificate to be used.
used.
Many current schemes simply add the certificate after the signed data Many current schemes simply add the certificate after the signed data
and thus are 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
skipping to change at page 100, line 48 skipping to change at page 100, line 49
C.3.6 Signing time C.3.6 Signing time
The present document provides the capability to include a claimed The present document provides the capability to include a claimed
signing time as an attribute of an electronic signature. signing time as an attribute of an electronic signature.
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. In all signature, the two times shall be within acceptable limits.
cases, the claimed signing time cannot be after the time identified by
the time-stamp or time-mark.
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.
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).
Also, the signing time, if present should be between the time indicated
by this time-stamp and time indicated by the CAdES-T time-stamp.
C.3.7 Content format C.3.7 Content format
When presenting signed data to a human user it may be important that When presenting signed data to a human user it may be important that
there is no ambiguity as to the presentation of the signed information there is no ambiguity as to the presentation of the signed information
to the relying party. In order for the appropriate representation to the relying party. In order for the appropriate representation
(text, sound or video) to be selected by the relying party when data (text, sound or video) to be selected by the relying party when data
(as opposed to data which has been further signed or encrypted) (as opposed to data which has been further signed or encrypted)
is encapsulated in the SignedData (indicated by the eContentType is encapsulated in the SignedData (indicated by the eContentType
within EncapsulatedContentInfo being set to id-data), further typing within EncapsulatedContentInfo being set to id-data), further typing
information should be used to identify the type of document being information should be used to identify the type of document being
skipping to change at page 118, line 41 skipping to change at page 118, line 41
|Content-Type= ||SignedData||Content-Type=||Dear MrSmith| |Content-Type= ||SignedData||Content-Type=||Dear MrSmith|
|multipart/ || ||application/ ||Received | |multipart/ || ||application/ ||Received |
|signed || ||pdf || 100 tins | |signed || ||pdf || 100 tins |
| /| || || || | | /| || || || |
| / -------------------+ /| || Mr.Jones | | / -------------------+ /| || Mr.Jones |
| \ -------------------+ / -----+ | | \ -------------------+ / -----+ |
| \| || || \ -----+ | | \| || || \ -----+ |
|Content-Type= || || \| |+------------+ |Content-Type= || || \| |+------------+
|application/ || |+-------------+ |application/ || |+-------------+
|pdf || | |pdf || |
| || | | || | |Content-Type= || |
|Content-Type= || |
|application/ || | |application/ || |
|pkcs7-signature|| | |pkcs7-signature|| |
| || | | || |
| /| || | | /| || |
| / -------+ | | / -------+ |
| \ -------+ | | \ -------+ |
| \| ||----------+ | \| ||----------+ | |
| |
+---------------+ +---------------+
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.
Annex G (informative): Relationship to the European Directive and EESSI Annex G (informative): Relationship to the European Directive and EESSI
skipping to change at page 130, line 29 skipping to change at page 130, line 30
included. included.
- since RFC 2459 and RFC 3852 has been obsoleted by RFC 3280 and - since RFC 2459 and RFC 3852 has been obsoleted by RFC 3280 and
RFC 3852 respectively, there was the need to refer to the OIDs RFC 3852 respectively, there was the need to refer to the OIDs
of the ASN.1 modules of RFC 3280 and RFC 3852, instead of the of the ASN.1 modules of RFC 3280 and RFC 3852, instead of the
OIDs of the ASN.1 modules of RFC 2459 and RFC 3852. OIDs of the ASN.1 modules of RFC 2459 and RFC 3852.
- other changes are related to the addition of the signing- - other changes are related to the addition of the signing-
certificate attribute, where the ESS signing-certificate certificate attribute, where the ESS signing-certificate
attribute defined in RFC 2634, shall be used if the SHA-1 attribute defined in RFC 2634, shall be used if the SHA-1
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 shall be used when other hashing algorithms are to be Agility RFC 5035 shall be used when other hashing algorithms
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.
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
 End of changes. 27 change blocks. 
46 lines changed or deleted 44 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/