RFC 3126
Electronic Signature Formats for long term electronic signatures
3. Data structure of an Electronic Signature
This clause uses and builds upon the Cryptographic Message Syntax (CMS), as defined in RFC 2630 [CMS], and Enhanced Security Services (ESS), as defined in RFC 2634 [ESS]. The overall structure of Electronic Signature is as defined in [CMS]. The Electronic Signature (ES) uses attributes defined in [CMS], [ESS] and this document. This document defines in full the ES attributes which it uses and are not defined elsewhere. The mandated set of attributes and the digital signature value is defined as the minimum Electronic Signature (ES) required by this document. A signature policy MAY mandate other signed attributes to be present.3.1 General Syntax
The general syntax of the ES is as defined in [CMS].3.2 Data Content Type
The data content type of the ES is as defined in [CMS]. The data content type is intended to refer to arbitrary octet strings, such as ASCII text files; the interpretation is left to the application. Such strings need not have any internal structure (although they could have their own ASN.1 definition or other structure).3.3 Signed-data Content Type
The Signed-data content type of the ES is as defined in [CMS]. The signed-data content type consists of a content of any type and zero or more signature values. Any number of signers in parallel can sign any type of content. The typical application of the signed-data content type represents one signer's digital signature on content of the data content type. To make sure that the verifier uses the right certificate, this document mandates that the hash of the signers certificate is always included in the Signing Certificate signed attribute.3.4 SignedData Type
The syntax of the SignedData type of the ES is as defined in [CMS].
The fields of type SignedData have the meanings defined [CMS] except that: * version is the syntax version number. The value of version must be 3. * The identification of signer's certificate used to create the signature is always present as a signed attribute. * The degenerate case where there are no signers is not valid in this document.3.5 EncapsulatedContentInfo Type
The syntax of the EncapsulatedContentInfo a type of the ES is as defined in [CMS]. For the purpose of long term validation as defined by this document, it is advisable that either the eContent is present, or the data which is signed is archived in such as way as to preserve the any data encoding. It is important that the OCTET STRING used to generate the signature remains the same every time either the verifier or an arbitrator validates the signature. The degenerate case where there are no signers is not valid in this document.3.6 SignerInfo Type
The syntax of the SignerInfo a type of the ES is as defined in [CMS]. Per-signer information is represented in the type SignerInfo. In the case of multiple independent signatures, there is an instance of this field for each signer. The fields of type SignerInfo have the meanings defined in [CMS] except that signedAttributes must, as a minimum, contain the following attributes: * ContentType as defined in clause 3.7.1. * MessageDigest as defined in clause 3.7.2. * SigningTime as defined in clause 3.7.3. * SigningCertificate as defined in clause 3.8.1. * SignaturePolicyId as defined in clause 3.9.1.3.6.1 Message Digest Calculation Process
The message digest calculation process is as defined in [CMS].
3.6.2 Message Signature Generation Process
The input to the digital signature generation process is as defined in [CMS].3.6.3 Message Signature Verification Process
The procedures for CMS signed data validation are as defined in [CMS] and enhanced in this document. The input to the signature verification process includes the signer's public key verified as correct using either the ESS Signing Certificate attribute or the Other Signing Certificate attribute.3.7 CMS Imported Mandatory Present Attributes
The following attributes MUST be present with the signed-data defined by this document. The attributes are defined in [CMS].3.7.1 Content Type
The syntax of the content-type attribute type of the ES is as defined in [CMS].3.7.2 Message Digest
The syntax of the message-digest attribute type of the ES is as defined in [CMS].3.7.3 Signing Time
The syntax of the message-digest attribute type of the ES is as defined in [CMS] and further qualified by this document. The signing-time attribute type specifies the time at which the signer claims to have performed the signing process. This present document recommends the use of GeneralizedTime.3.8 Alternative Signing Certificate Attributes
One, and only one, of the following two alternative attributes MUST be present with the signed-data defined by this document to identify the signing certificate. Both attributes include an identifier and a hash of the signing certificate. The first, which is adopted in existing standards, may be only used with the SHA-1 hashing algorithm. The other shall be used when other hashing algorithms are to be supported.
The signing certificate attribute is designed to prevent the simple substitution and re-issue attacks, and to allow for a restricted set of authorization certificates to be used in verifying a signature.3.8.1 ESS Signing Certificate Attribute Definition
The syntax of the signing certificate attribute type of the ES is as defined in [ESS], and further qualified and profile in this document. The ESS signing certificate attribute must be a signed attribute. This document mandates the presence of this attribute as a signed CMS attribute, and the sequence must not be empty. The certificate used to verify the signature must be identified in the sequence, the Signature Validation Policy may mandate other certificate references to be present, that may include all the certificates up to the point of trust. The encoding of the ESSCertID for this certificate must include the issuerSerial field. The issuerAndSerialNumber present in the SignerInfo must be consistent with issuerSerial field. The certificate identified must be used during the signature verification process. If the hash of the certificate does not match the certificate used to verify the signature, the signature must be considered invalid. The sequence of policy information field is not used in this document. NOTE: Where an attribute certificate is used by the signer to associate a role, or other attributes of the signer, with the electronic signature this is placed in the Signer Attribute attribute as defined in clause 3.12.3.3.8.2 Other Signing Certificate Attribute Definition
The following attribute is identical to the ESS SigningCertificate defined above except that this attribute can be used with hashing algorithms other than SHA-1. This attribute must be used in the same manner as defined above for the ESS SigningCertificate attribute. The following object identifier identifies the signing certificate attribute: id-aa-ets-otherSigCert OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) id-aa(2) 19 }
The signing certificate attribute value has the ASN.1 syntax
OtherSigningCertificate
OtherSigningCertificate ::= SEQUENCE {
certs SEQUENCE OF OtherCertID,
policies SEQUENCE OF PolicyInformation OPTIONAL
-- NOT USED IN THIS DOCUMENT
}
OtherCertID ::= SEQUENCE {
otherCertHash OtherHash,
issuerSerial IssuerSerial OPTIONAL
}
OtherHash ::= CHOICE {
sha1Hash OtherHashValue, -- This contains a SHA-1 hash
otherHash OtherHashAlgAndValue
}
OtherHashValue ::= OCTET STRING
OtherHashAlgAndValue ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
hashValue OtherHashValue
}
3.9 Additional Mandatory Attributes
3.9.1 Signature policy Identifier
This document mandates that a reference to the signature policy, is
included in the signedData, this reference is either explicitly
identified or implied by the semantics of the signed content and
other external data. A signature policy defines the rules for
creation and validation of an electronic signature, is included as a
signed attribute with every signature. The signature policy
identifier must be a signed attribute.
The following object identifier identifies the signature policy
identifier attribute:
id-aa-ets-sigPolicyId OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-aa(2) 15 }
Signature-policy-identifier attribute values have ASN.1 type
SignaturePolicyIdentifier.
SignaturePolicyIdentifier ::= CHOICE{
SignaturePolicyId SignaturePolicyId,
SignaturePolicyImplied SignaturePolicyImplied }
SignaturePolicyId ::= SEQUENCE {
sigPolicyIdentifier SigPolicyId,
sigPolicyHash SigPolicyHash,
sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF
SigPolicyQualifierInfo OPTIONAL
}
SignaturePolicyImplied ::= NULL
The presence of the NULL type indicates that the signature policy is
implied by the semantics of the signed data and other external data.
The sigPolicyId field contains an object-identifier which uniquely
identifies a specific version of the signature policy. The syntax of
this field is as follows:
SigPolicyId ::= OBJECT IDENTIFIER
The sigPolicyHash field contains the identifier of the hash algorithm
and the hash of the value of the signature policy.
If the signature policy is defined using a computer processable
notation like ASN.1, then the hash is calculated on the value without
the outer type and length fields and the hashing algorithm must be as
specified in the field signPolicyHshAlg.
If the signature policy is defined using another structure, the type
of structure and the hashing algorithm must be either specified as
part of the signature policy, or indicated using a signature policy
qualifier.
SigPolicyHash ::= OtherHashAlgAndValue
A signature policy identifier may be qualified with other information
about the qualifier. The semantics and syntax of the qualifier is as
associated with the object-identifier in the sigPolicyQualifierId
field. The general syntax of this qualifier is as follows:
SigPolicyQualifierInfo ::= SEQUENCE {
sigPolicyQualifierId SigPolicyQualifierId,
sigQualifier ANY DEFINED BY sigPolicyQualifierId
}
This document specifies the following qualifiers:
* spuri: This contains the web URI or URL reference to the
signature policy
* spUserNotice: This contains a user notice which should be
displayed whenever the signature is validated.
-- sigpolicyQualifierIds defined in this document
SigPolicyQualifierId ::= OBJECT IDENTIFIER
id-spq-ets-uri OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-spq(5) 1 }
SPuri ::= IA5String
id-spq-ets-unotice OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-spq(5) 2 }
SPUserNotice ::= SEQUENCE {
noticeRef NoticeReference OPTIONAL,
explicitText DisplayText OPTIONAL
}
NoticeReference ::= SEQUENCE {
organization DisplayText,
noticeNumbers SEQUENCE OF INTEGER
}
DisplayText ::= CHOICE {
visibleString VisibleString (SIZE (1..200)),
bmpString BMPString (SIZE (1..200)),
utf8String UTF8String (SIZE (1..200))
}
3.10 CMS Imported Optional Attributes
The following attributes MAY be present with the signed-data defined
by this document. The attributes are defined in ref [CMS] and are
imported into this specification and were appropriate qualified and
profiling by this document.
3.10.1 Countersignature
The syntax of the countersignature attribute type of the ES is as defined in [CMS]. The countersignature attribute must be an unsigned attribute.3.11 ESS Imported Optional Attributes
The following attributes MAY be present with the signed-data defined by this document. The attributes are defined in ref [ESS] and are imported into this specification and were appropriate qualified and profiling by this document.3.11.1 Content Reference Attribute
The content reference attribute is a link from one SignedData to another. It may be used to link a reply to the original message to which it refers, or to incorporate by reference one SignedData into another. The content reference attribute MUST be used as defined in [ESS]. The content reference MUST be a signed attribute. The syntax of the content reference attribute type of the ES is as defined in [ESS].3.11.2 Content Identifier Attribute
The content identifier attribute provides an identifier for the signed content for use when reference may be later required to that content, for example in the content reference attribute in other signed data sent later. The content identifier must be a signed attribute. The syntax of the content identifier attribute type of the ES is as defined in [ESS]. The minimal signedContentIdentifier should contain a concatenation of user-specific identification information (such as a user name or public keying material identification information), a GeneralizedTime string, and a random number.3.11.3 Content Hints Attribute
The content hints attribute provides information that describes the format of the signed content. It may be used by the signer to indicate to a verifier the precise format that MUST be used to
present the data (e.g., text, voice, video) to a verifier. This attribute MUST be present when it is mandatory to present the signed data to human users on verification. The syntax of the content hints attribute type of the ES is as defined in ESS (RFC 2634, section 2.9 [9]). When used to indicate the precise format of the data to be presented to the user the following rules apply: The contentType (defined in RFC 2630 [8]) indicates the type of the associated content. It is an object identifier (i.e., a unique string of integers) assigned by an authority that defines the content type. The UTF8String shall define the presentation format. The format may be defined by MIME types as indicated below. Note 1: The contentType can be id-data defined in CMS (RFC 2630 [8]). The UTF8String can be used to indicate the encoding of the data, like MIME type. RFC 2045 [25] provides a common structure for encoding a range of electronic documents and other multi-media types, see annex B for further information, a system supporting verification of electronic signature may present information to users in the form identified by the MIME type. id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 }3.12 Additional Optional Attributes
3.12.1 Commitment Type Indication Attribute
There may be situation were a signer wants to explicitly indicate to a verifier that by signing the data, it illustrates a type of commitment on behalf of the signer. The commitmentTypeIndication attribute conveys such information. The commitmentTypeIndication attribute must be a signed attribute. The commitment type may be: * defined as part of the signature policy, in which case the commitment type has precise semantics that is defined as part of the signature policy.
* be a registered type, in which case the commitment type has
precise semantics defined by registration, under the rules of
the registration authority. Such a registration authority may
be a trading association or a legislative authority.
The signature policy specifies a set of attributes that it
"recognizes". This "recognized" set includes all those commitment
types defined as part of the signature policy as well as any
externally defined commitment types that the policy may choose to
recognize. Only recognized commitment types are allowed in this
field.
The following object identifier identifies the commitment type
indication attribute:
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}
Commitment-Type-Indication attribute values have ASN.1 type
CommitmentTypeIndication.
CommitmentTypeIndication ::= SEQUENCE {
commitmentTypeId CommitmentTypeIdentifier,
commitmentTypeQualifier SEQUENCE SIZE (1..MAX) OF
CommitmentTypeQualifier OPTIONAL
}
CommitmentTypeIdentifier ::= OBJECT IDENTIFIER
CommitmentTypeQualifier ::= SEQUENCE {
commitmentTypeIdentifier CommitmentTypeIdentifier,
qualifier ANY DEFINED BY
commitmentTypeIdentifier
}
The use of any qualifiers to the commitment type is outside the scope
of this document.
The following generic commitment types are defined in this document:
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}
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}
id-cti-ets-proofOfDelivery OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) cti(6) 3}
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}
id-cti-ets-proofOfApproval OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) cti(6) 5}
id-cti-ets-proofOfCreation OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) cti(6) 6}
These generic commitment types have the following meaning:
Proof of origin indicates that the signer recognizes to have created,
approved and sent the message.
Proof of receipt indicates that signer recognizes to have received
the content of the message.
Proof of delivery indicates that the TSP providing that indication
has delivered a message in a local store accessible to the recipient
of the message.
Proof of sender indicates that the entity providing that indication
has sent the message (but not necessarily created it).
Proof of approval indicates that the signer has approved the content
of the message.
Proof of creation indicates that the signer has created the message
(but not necessarily approved, nor sent it).
3.12.2 Signer Location attribute
The signer-location attribute is an attribute which specifies a
mnemonic for an address associated with the signer at a particular
geographical (e.g., city) location. The mnemonic is registered in
the country in which the signer is located and is used in the
provision of the Public Telegram Service (according to ITU-T
Recommendation F.1 [PTS]).
The signer-location attribute must be a signed attribute.
The following object identifier identifies the signer-location
attribute:
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}
Signer-location attribute values have ASN.1 type SignerLocation.
SignerLocation ::= SEQUENCE {
-- at least one of the following must be present
countryName [0] DirectoryString OPTIONAL,
-- as used to name a Country in X.500
localityName [1] DirectoryString OPTIONAL,
-- as used to name a locality in X.500
postalAdddress [2] PostalAddress OPTIONAL
}
PostalAddress ::= SEQUENCE SIZE(1..6) OF DirectoryString
3.12.3 Signer Attributes attribute
The signer-attributes attribute is an attribute which specifies
additional attributes of the signer (e.g., role).
It may be either:
* claimed attributes of the signer; or
* certified attributes of the signer;
The signer-attributes attribute must be a signed attribute.
The following object identifier identifies the signer-attribute
attribute:
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}
signer-attribute attribute values have ASN.1 type SignerAttribute.
SignerAttribute ::= SEQUENCE OF CHOICE {
claimedAttributes [0] ClaimedAttributes,
certifiedAttributes [1] CertifiedAttributes
}
ClaimedAttributes ::= SEQUENCE OF Attribute
CertifiedAttributes ::= AttributeCertificate
-- as defined in X.509 : see section 10.3
NOTE: The claimed and certified attribute are imported from ITU-T Recommendations X.501 [16] and ITU-T Recommendation X.509:Draft Amendment on Certificate Extensions, October 1999.3.12.4 Content Time-Stamp attribute
The content time-stamp attribute is an attribute which is the time- stamp of the signed data content before it is signed. The content time-stamp attribute must be a signed attribute. The following object identifier identifies the signer-attribute attribute: id-aa-ets-contentTimestamp OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 20} Content time-stamp attribute values have ASN.1 type ContentTimestamp: ContentTimestamp::= TimeStampToken The value of messageImprint field within TimeStampToken must be a hash of the value of eContent field within encapContentInfo within the signedData. For further information and definition of TimeStampToken see [TSP].3.13 Support for Multiple Signatures
3.13.1 Independent Signatures
Multiple independent signatures are supported by independent SignerInfo from each signer. Each SignerInfo must include all the attributes required under this document and must be processed independently by the verifier.3.13.2 Embedded Signatures
Multiple embedded signatures are supported using the counter- signature unsigned attribute (see clause 3.10.1). Each counter signature is carried in Countersignature held as an unsigned attribute to the SignerInfo to which the counter-signature is applied.
4. Validation Data
This clause specifies the validation data structures which builds on the electronic signature specified in clause 3. This includes: * Time-Stamp applied to the electronic signature value. * Complete validation data which comprises the time-stamp of the signature value, plus references to all the certificates and revocation information used for full validation of the electronic signature. The following optional eXtended forms of validation data are also defined: * X-timestamp: There are two types of time-stamp used in extended validation data defined by this document. - Type 1 -Time-Stamp which comprises a time-stamp over the ES with Complete validation data (ES-C). - Type 2 X-Time-Stamp which comprises of a time-stamp over the certification path references and the revocation information references used to support the ES-C. * X-Long: This comprises a Complete validation data plus the actual values of all the certificates and revocation information used in the ES-C. * X-Long-Time-Stamp: This comprises a Type 1 or Type 2 X- Timestamp plus the actual values of all the certificates and revocation information used in the ES-C. This clause also specifies the data structures used in Archive validation data: * Archive validation data comprises a Complete validation data, the certificate and revocation values (as in a X-Long validation data), any other existing X-timestamps, plus the Signed User data and an additional archive time-stamp over all that data. An archive time-stamp may be repeatedly applied after long periods to maintain validity when electronic signature and timestamping algorithms weaken. The additional data required to create the forms of electronic signature identified above is carried as unsigned attributes associated with an individual signature by being placed in the
unsignedAttrs field of SignerInfo. Thus all the attributes defined in clause 4 are unsigned attributes. NOTE: Where multiple signatures are to be supported, as described in clause 3.13, each signature has a separate SignerInfo. Thus, each signature requires its own unsigned attribute values to create ES-T, ES-C etc.4.1 Electronic Signature Timestamp
An Electronic Signature with Timestamp is an Electronic Signature for which part, but not all, of the additional data required for validation is available (e.g., some certificates and revocation information is available but not all). The minimum structure Timestamp validation data is the Signature Timestamp Attribute as defined in clause 4.1.1 over the ES signature value.4.1.1 Signature Timestamp Attribute Definition
The Signature Timestamp attribute is timestamp of the signature value. It is an unsigned attribute. Several instances of this attribute from different TSAs may occur with an electronic signature. The Signature Validation Policy specifies, in the signatureTimestampDelay field of TimestampTrustConditions, a maximum acceptable time difference which is allowed between the time indicated in the signing time attribute and the time indicated by the Signature Timestamp attribute. If this delay is exceeded then the electronic signature must be considered as invalid. The following object identifier identifies the Signature Timestamp attribute: id-aa-signatureTimeStampToken OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 14} The Signature timestamp attribute value has ASN.1 type SignatureTimeStampToken. SignatureTimeStampToken ::= TimeStampToken The value of messageImprint field within TimeStampToken must be a hash of the value of signature field within SignerInfo for the signedData being timestamped.
For further information and definition of TimeStampToken see [TSP].4.2 Complete Validation Data
An electronic signature with complete validation data is an Electronic Signature for which all the additional data required for validation (i.e., all certificates and revocation information) is available. Complete validation data (ES-C) build on the electronic signature Time-Stamp as defined above. The minimum structure of a Complete validation data is: * the Signature Time-Stamp Attribute, as defined in clause 4.1.1; * Complete Certificate Refs, as defined in clause 4.2.1; * Complete Revocation Refs, as defined in clause 4.2.2. The Complete validation data MAY also include the following additional information, forming a X-Long validation data, for use if later validation processes may not have access to this information: * Complete Certificate Values, as defined in clause 4.2.3; * Complete Revocation Values, as defined in clause 4.2.4. The Complete validation data MAY also include one of the following additional attributes, forming a X-Time-Stamp validation data, to provide additional protection against later CA compromise and provide integrity of the validation data used: * ES-C Time-Stamp, as defined in clause 4.2.5; or * Time-Stamped Certificates and CRLs references, as defined in clause 4.2.6. NOTE 1: As long as the CA's are trusted such that these keys cannot be compromised or the cryptography used broken, the ES-C provides long term proof of a valid electronic signature. A valid electronic signature is an electronic signature which passes validation according to a signature validation policy. NOTE 2: The ES-C provides the following important property for long standing signatures; that is having been found once to be valid, must continue to be so months or years later. Long after the validity period of the certificates have expired, or after the user key has been compromised.
4.2.1 Complete Certificate Refs Attribute Definition
The Complete Certificate Refs attribute is an unsigned attribute. It references the full set of CA certificates that have been used to validate a ES with Complete validation data (ES-C) up to (but not including) the signer's certificate. Only a single instance of this attribute must occur with an electronic signature. Note: The signer's certified is referenced in the signing certificate attribute (see clause 3.1). id-aa-ets-certificateRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 21} The complete certificate refs attribute value has the ASN.1 syntax CompleteCertificateRefs. CompleteCertificateRefs ::= SEQUENCE OF OTHERCertID OTHERCertID is defined in clause 3.8.2. The IssuerSerial that must be present in OTHERCertID. The certHash must match the hash of the certificate referenced. NOTE: Copies of the certificate values may be held using the Certificate Values attribute defined in clause 4.3.1.4.2.2 Complete Revocation Refs Attribute Definition
The Complete Revocation Refs attribute is an unsigned attribute. Only a single instance of this attribute must occur with an electronic signature. It references the full set of the CRL or OCSP responses that have been used in the validation of the signer and CA certificates used in ES with Complete validation data. The following object identifier identifies the CompleteRevocationRefs attribute: 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} The complete revocation refs attribute value has the ASN.1 syntax CompleteRevocationRefs. CompleteRevocationRefs ::= SEQUENCE OF CrlOcspRef
CrlOcspRef ::= SEQUENCE {
crlids [0] CRLListID OPTIONAL,
ocspids [1] OcspListID OPTIONAL,
otherRev [2] OtherRevRefs OPTIONAL
}
CompleteRevocationRefs must contain one CrlOcspRef for the signing
certificate, followed by one for each OTHERCertID in the
CompleteCertificateRefs attribute. The second and subsequent
CrlOcspRef fields must be in the same order as the OTHERCertID to
which they relate. At least one of CRLListID or OcspListID or
OtherRevRefs should be present for all but the "trusted" CA of the
certificate path.
CRLListID ::= SEQUENCE {
crls SEQUENCE OF CrlValidatedID}
CrlValidatedID ::= SEQUENCE {
crlHash OtherHash,
crlIdentifier CrlIdentifier OPTIONAL}
CrlIdentifier ::= SEQUENCE {
crlissuer Name,
crlIssuedTime UTCTime,
crlNumber INTEGER OPTIONAL
}
OcspListID ::= SEQUENCE {
ocspResponses SEQUENCE OF OcspResponsesID}
OcspResponsesID ::= SEQUENCE {
ocspIdentifier OcspIdentifier,
ocspRepHash OtherHash OPTIONAL
}
OcspIdentifier ::= SEQUENCE {
ocspResponderID ResponderID,
-- As in OCSP response data
producedAt GeneralizedTime
-- As in OCSP response data
}
When creating an crlValidatedID, the crlHash is computed over the
entire DER encoded CRL including the signature. The crlIdentifier
would normally be present unless the CRL can be inferred from other
information.
The crlIdentifier is to identify the CRL using the issuer name and
the CRL issued time which must correspond to the time "thisUpdate"
contained in the issued CRL. 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 provide a complete revocation list
must be included.
The OcspIdentifier is to identify the OSCP response using the issuer
name and the time of issue of the OCSP response which must correspond
to the time "producedAt" contained in the issued OCSP response.
Since it may be needed to make the difference between two OCSP
responses received within the same second, then the hash of the
response contained in the OcspResponsesID may be needed to solve the
ambiguity.
NOTE: Copies of the CRL and OCSP responses values may be held using
the Revocation Values attribute defined in clause 4.3.2.
OtherRevRefs ::= SEQUENCE {
otherRevRefType OtherRevRefType,
otherRevRefs ANY DEFINED BY otherRevRefType
}
OtherRevRefType ::= OBJECT IDENTIFIER
The syntax and semantics of other revocation references is outside
the scope of this document. The definition of the syntax of the
other form of revocation information is as identified by
OtherRevRefType.
4.3 Extended Validation Data
4.3.1 Certificate Values Attribute Definition
The Certificate Values attribute is an unsigned attribute. Only a
single instance of this attribute must occur with an electronic
signature. It holds the values of certificates referenced in the
CompleteCertificateRefs attribute.
Note: If an Attribute Certificate is used, it is not provided in this
structure but must be provided by the signer as a signer-attributes
attribute (see clause 12.3).
The following object identifier identifies the CertificateValues
attribute:
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}
The certificate values attribute value has the ASN.1 syntax CertificateValues. CertificateValues ::= SEQUENCE OF Certificate Certificate is defined in RFC2459 and ITU-T Recommendation X.509 [1])4.3.2 Revocation Values Attribute Definition
The Revocation Values attribute is an unsigned attribute. Only a single instance of this attribute must occur with an electronic signature. It holds the values of CRLs and OCSP referenced in the CompleteRevocationRefs attribute. The following object identifier identifies the Revocation Values attribute: id-aa-ets-revocationValues OBJECT IDENTIFIER ::= { iso(1) member- body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 24} The revocation values attribute value has the ASN.1 syntax RevocationValues. RevocationValues ::= SEQUENCE { crlVals [0] SEQUENCE OF CertificateList OPTIONAL, ocspVals [1] SEQUENCE OF BasicOCSPResponse OPTIONAL, otherRevVals [2] OtherRevVals } OtherRevVals ::= SEQUENCE { otherRevValType OtherRevValType, otherRevVals ANY DEFINED BY otherRevValType } OtherRevValType ::= OBJECT IDENTIFIER The syntax and semantics of the other revocation values is outside the scope of this document. The definition of the syntax of the other form of revocation information is as identified by OtherRevRefType. CertificateList is defined in RFC 2459 [RFC2459] and in ITU-T Recommendation X.509 [X509]). BasicOCSPResponse is defined in RFC 2560 [OCSP].
4.3.3 ES-C Time-Stamp Attribute Definition
This attribute is used for the Type 1 X-Time-Stamped validation data. The ES-C Time-Stamp attribute is an unsigned attribute. It is time- stamp of a hash of the electronic signature and the complete validation data (ES-C). It is a special purpose TimeStampToken Attribute which time-stamps the ES-C. Several instances instance of this attribute may occur with an electronic signature from different TSAs. The following object identifier identifies the ES-C Time-Stamp attribute: id-aa-ets-escTimeStamp OBJECT IDENTIFIER ::= { iso(1) member- body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 25} The ES-C time-stamp attribute value has the ASN.1 syntax ESCTimeStampToken. ESCTimeStampToken ::= TimeStampToken The value of messageImprint field within TimeStampToken must be a hash of the concatenated values (without the type or length encoding for that value) of the following data objects as present in the ES with Complete validation data (ES-C): * signature field within SignerInfo; * SignatureTimeStampToken attribute; * CompleteCertificateRefs attribute; * CompleteRevocationRefs attribute. For further information and definition of the Time Stamp Token see [TSP].4.3.4 Time-Stamped Certificates and CRLs Attribute Definition
This attribute is used for the Type 2 X-Time-Stamp validation data. A TimestampedCertsCRLsRef attribute is an unsigned attribute. It is a list of referenced certificates and OCSP responses/CRLs which are been time-stamped to protect against certain CA compromises. Its syntax is as follows: The following object identifier identifies the TimestampedCertsCRLsRef attribute:
id-aa-ets-certCRLTimestamp OBJECT IDENTIFIER ::= { iso(1) member-
body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
id-aa(2) 26}
The attribute value has the ASN.1 syntax TimestampedCertsCRLs.
TimestampedCertsCRLs ::= TimeStampToken
The value of messageImprint field within TimeStampToken must be a
hash of the concatenated values (without the type or length encoding
for that value) of the following data objects as present in the ES
with Complete validation data (ES-C):
* CompleteCertificateRefs attribute;
* CompleteRevocationRefs attribute.
4.4 Archive Validation Data
Where an electronic signature is required to last for a very long
time, and a the time-stamp on an electronic signature is in danger of
being invalidated due to algorithm weakness or limits in the validity
period of the TSA certificate, then it may be required to time-stamp
the electronic signature several times. When this is required an
archive time-stamp attribute may be required. This time-stamp may be
repeatedly applied over a period of time.
4.4.1 Archive Time-Stamp Attribute Definition
The Archive Time-Stamp attribute is time-stamp of the user data and
the entire electronic signature. If the Certificate values and
Revocation Values attributes are not present these attributes must be
added to the electronic signature prior to the time-stamp. The
Archive Time-Stamp attribute is an unsigned attribute. Several
instances of this attribute may occur with on electronic signature
both over time and from different TSAs.
The following object identifier identifies the Nested Archive Time-
Stamp attribute:
id-aa-ets-archiveTimestamp OBJECT IDENTIFIER ::= { iso(1) member-
body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
id-aa(2) 27}
Archive time-stamp attribute values have the ASN.1 syntax
ArchiveTimeStampToken
ArchiveTimeStampToken ::= TimeStampToken
The value of messageImprint field within Time-StampToken must be a
hash of the concatenated values (without the type or length encoding
for that value) of the following data objects as present in the
electronic signature:
* encapContentInfo eContent OCTET STRING;
* signedAttributes;
* signature field within SignerInfo;
* SignatureTimeStampToken attribute;
* CompleteCertificateRefs attribute;
* CompleteRevocationData attribute;
* CertificateValues attribute
(If not already present this information must be included in
the ES-A);
* RevocationValues attribute
(If not already present this information must be included in
the ES-A);
* ESCTimeStampToken attribute if present;
* TimestampedCertsCRLs attribute if present;
* any previous ArchiveTimeStampToken attributes.
For further information and definition of TimeStampToken see [TSP]
The time-stamp should be created using stronger algorithms (or longer
key lengths) than in the original electronic signatures.
5. Security Considerations
5.1 Protection of Private Key
The security of the electronic signature mechanism defined in this
document depends on the privacy of the signer's private key.
Implementations must take steps to ensure that private keys cannot be
compromised.
5.2 Choice of Algorithms
Implementers should be aware that cryptographic algorithms become
weaker with time. As new cryptoanalysis techniques are developed and
computing performance improves, the work factor to break a particular
cryptographic algorithm will reduce. Therefore, cryptographic
algorithm implementations should be modular allowing new algorithms
to be readily inserted. That is, implementers should be prepared for
the set of mandatory to implement algorithms to change over time.
6. Conformance Requirements
This document only defines conformance requirements up to a ES with Complete validation data (ES-C). This means that none of the extended and archive forms of Electronic Signature (ES-X, ES-A) need to be implemented to get conformance to this standard. This document mandates support for elements of the signature policy.6.1 Signer
A system supporting signers according to this document must, at a minimum, support generation of an electronic signature consisting of the following components: * The general CMS syntax and content type as defined in RFC 2630 (see clauses 4.1 and 4.2). * CMS SignedData as defined in RFC 2630 with version set to 3 and at least one SignerInfo must be present (see clauses 4.3, 4.4, 4.5, 4.6). * The following CMS Attributes as defined in RFC 2630: - ContentType; This must always be present (see clause 3.7.1); - MessageDigest; This must always be present (see clause 3.7.2); - SigningTime; This must always be present (see clause 3.7.3). * The following ESS Attributes as defined in RFC 2634: - SigningCertificate: This must be set as defined in clauses 3.8.1 and 3.8.2. * The following Attributes as defined in clause 3.9: - SignaturePolicyIdentifier; This must always be present. * Public Key Certificates as defined in ITU-T Recommendation X.509 [1] and profiled in RFC 2459 [7] (see clause 9.1).
6.2 Verifier using time-stamping
A system supporting verifiers according to this document with time- stamping facilities must, at a minimum, support: * Verification of the mandated components of an electronic signature, as defined in clause 5.1. * Signature Time-Stamp attribute, as defined in clause 4.1.1. * Complete Certificate Refs attribute, as defined in clause 4.2.1. * Complete Revocation Refs Attribute, as defined in clause 4.2.2. * Public Key Certificates, as defined in ITU-T Recommendation X.509 and profiled in RFC 2459. * Either of: - Certificate Revocation Lists, as defined in ITU-T Recommendation X.509 [1] and profiled in RFC 2459 [7]; or - On-line Certificate Status Protocol responses, as defined in RFC 2560.6.3 Verifier using secure records
A system supporting verifiers according to the present document shall, at a minimum, support: * Verification of the mandated components of an electronic signature, as defined in subclause 5.1. * Complete Certificate Refs attribute, as defined in subclause 4.2.1. * Complete Revocation Refs Attribute, as defined in subclause 9.2.2. * A record shall be maintained, which cannot be undetectably modified, of the electronic signature and the time when the signature was first validated using the referenced certificates and revocation information. * Public Key Certificates, as defined in ITU-T Recommendation X.509 [1] and profiled in RFC 2459 [7] (see subclause 10.1).
* Either of:
- Certificate Revocation Lists, as defined in ITU-T
Recommendation X.509 [1] and profiled in RFC 2459 [7] Or
- On-line Certificate Status Protocol, as defined in RFC 2560
[8] (see subclause 10.3).
7. References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[ESS] Hoffman, P., "Enhanced Security Services for S/MIME", RFC
2634, June 1999.
[CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630,
June 1999.
[OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S. and C.
Adams, "On-line Status Certificate Protocol", RFC 2560,
June 1999.
[TSP] Adams, C., Cain, P., Pinkas, D. and R. Zuccherato,
"Internet X.509 Public Key Infrastructure Time-Stamp
Protocol (TSP)", RFC 3161, August 2001.
[PTS] Public Telegram Service. ITU-T Recommendation F1.
[RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
X.509 Public Key Infrastructure, Certificate and CRL
Profile", RFC 2459, January 1999.
[PKCS9] RSA Laboratories, "The Public-Key Cryptography Standards
(PKCS)", RSA Data Security Inc., Redwood City, California,
November 1993 Release.
[ISONR] ISO/IEC 10181-5: Security Frameworks in Open Systems.
Non-Repudiation Framework. April 1997.
[TS101733] ETSI Standard TS 101 733 V.1.2.2 (2000-12) Electronic
Signature Formats. Note: copies of ETSI TS 101 733 can be
freely downloaded from the ETSI web site www.etsi.org.
8. Authors' Addresses
This Informational RFC has been produced in ETSI TC-SEC. ETSI F-06921 Sophia Antipolis, Cedex - FRANCE 650 Route des Lucioles - Sophia Antipolis Valbonne - France Tel: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 secretariat@etsi.fr http://www.etsi.org Contact Point Harri Rasilainen ETSI 650 Route des Lucioles F-06921 Sophia Antipolis, Cedex FRANCE EMail: harri.rasilainen@etsi.fr Denis Pinkas Integris 68, Route de Versailles 78434 Louveciennes CEDEX FRANCE EMail: Denis.Pinkas@bull.net John Ross Security & Standards 192 Moulsham Street Chelmsford, Essex CM2 0LG United Kingdom EMail: ross@secstan.com Nick Pope Security & Standards 192 Moulsham Street Chelmsford, Essex CM2 0LG United Kingdom EMail: pope@secstan.com
(next page on part 3)
