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 (RFC2634, 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 RFC2630 [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 (RFC2630 [8]).
The UTF8String can be used to indicate the encoding of the data, like
MIME type. RFC2045 [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 RFC2459 [RFC2459] and in ITU-T
Recommendation X.509 [X509]).
BasicOCSPResponse is defined in RFC2560 [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 RFC2630
(see clauses 4.1 and 4.2).
* CMS SignedData as defined in RFC2630 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 RFC2630:
- 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 RFC2634:
- 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 RFC2459 [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 RFC2459.
* Either of:
- Certificate Revocation Lists, as defined in ITU-T
Recommendation X.509 [1] and profiled in RFC2459 [7]; or
- On-line Certificate Status Protocol responses, as defined in
RFC2560.
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 RFC2459 [7] (see subclause 10.1).
* Either of:
- Certificate Revocation Lists, as defined in ITU-T
Recommendation X.509 [1] and profiled in RFC2459 [7] Or
- On-line Certificate Status Protocol, as defined in RFC2560
[8] (see subclause 10.3).
7. References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC2119, March 1997.
[ESS] Hoffman, P., "Enhanced Security Services for S/MIME", RFC
2634, June 1999.
[CMS] Housley, R., "Cryptographic Message Syntax", RFC2630,
June 1999.
[OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S. and C.
Adams, "On-line Status Certificate Protocol", RFC2560,
June 1999.
[TSP] Adams, C., Cain, P., Pinkas, D. and R. Zuccherato,
"Internet X.509 Public Key Infrastructure Time-Stamp
Protocol (TSP)", RFC3161, 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", RFC2459, 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 RFChas 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
Annex A (normative): ASN.1 Definitions
This annex provides a summary of all the ASN.1 syntax definitions for
new syntax defined in this document.
A.1 Definitions Using X.208 (1988) ASN.1 Syntax
NOTE: The ASN.1 module defined in clause A.1 has precedence over
that defined in Annex A-2 in the case of any conflict.
ETS-ElectronicSignatureFormats-88syntax { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-mod(0) 5}
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
-- EXPORTS All -
IMPORTS
-- Crypographic Message Syntax (CMS): RFC2630
ContentInfo, ContentType, id-data, id-signedData, SignedData,
EncapsulatedContentInfo, SignerInfo, id-contentType,
id-messageDigest, MessageDigest, id-signingTime, SigningTime,
id-countersignature, Countersignature
FROM CryptographicMessageSyntax
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) cms(1) }
-- ESS Defined attributes: RFC2634
-- (Enhanced Security Services for S/MIME)
id-aa-signingCertificate, SigningCertificate, IssuerSerial,
id-aa-contentReference, ContentReference,
id-aa-contentIdentifier, ContentIdentifier
FROM ExtendedSecurityServices
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) ess(2) }
-- Internet X.509 Public Key Infrastructure
-- Certificate and CRL Profile: RFC2459
Certificate, AlgorithmIdentifier, CertificateList, Name,
GeneralNames, GeneralName, DirectoryString,Attribute,
AttributeTypeAndValue, AttributeType, AttributeValue,
PolicyInformation, BMPString, UTF8String
FROM PKIX1Explicit88
{iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit-
88(1)}
-- X.509 '97 Authentication Framework
AttributeCertificate
FROM AuthenticationFramework
{joint-iso-ccitt ds(5) module(1) authenticationFramework(7) 3}
-- The imported AttributeCertificate is defined using the X.680 1997
-- ASN.1 Syntax,
-- an equivalent using the 88 ASN.1 syntax may be used.
-- OCSP 2560
BasicOCSPResponse, ResponderID
FROM OCSP {-- OID not assigned -- }
-- Time Stamp Protocol Work in Progress
TimeStampToken
FROM PKIXTSP
{iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-tsp(13)}
-- S/MIME Object Identifier arcs used in this document
-- ===================================================
-- S/MIME OID arc used in this document
-- id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
-- us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 }
-- S/MIME Arcs
-- id-mod OBJECT IDENTIFIER ::= { id-smime 0 }
-- modules
-- id-ct OBJECT IDENTIFIER ::= { id-smime 1 }
-- content types
-- id-aa OBJECT IDENTIFIER ::= { id-smime 2 }
-- attributes
-- id-spq OBJECT IDENTIFIER ::= { id-smime 5 }
-- signature policy qualifier
-- id-cti OBJECT IDENTIFIER ::= { id-smime 6 }
-- commitment type identifier
-- Definitions of Object Identifier arcs used in this document
-- ===========================================================
-- The allocation of OIDs to specific objects are given below with the
-- associated ASN.1 syntax definition
-- OID used referencing electronic signature mechanisms based on this
-- standard for use with the IDUP API (see annex D)
id-etsi-es-IDUP-Mechanism-v1 OBJECT IDENTIFIER ::=
{ itu-t(0) identified-organization(4) etsi(0)
electronic-signature-standard (1733) part1 (1)
idupMechanism (4)etsiESv1(1) }
-- CMS Attributes Defined in this document
-- =======================================
-- Mandatory Electronic Signature Attributes
-- OtherSigningCertificate
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 }
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
}
-- Signature Policy Identifier
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 }
"SignaturePolicy CHOICE {
SignaturePolicyId SignaturePolicyId,
SignaturePolicyImplied SignaturePolicyImplied
}
SignaturePolicyId ::= SEQUENCE {
sigPolicyIdentifier SigPolicyId,
sigPolicyHash SigPolicyHash,
sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF
SigPolicyQualifierInfo OPTIONAL
}
SignaturePolicyImplied ::= NULL
SigPolicyId ::= OBJECT IDENTIFIER
SigPolicyHash ::= OtherHashAlgAndValue
SigPolicyQualifierInfo ::= SEQUENCE {
sigPolicyQualifierId SigPolicyQualifierId,
sigQualifier ANY DEFINED BY sigPolicyQualifierId
}
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))
}
-- Optional Electronic Signature Attributes
-- Commitment Type
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}
CommitmentTypeIndication ::= SEQUENCE {
commitmentTypeId CommitmentTypeIdentifier,
commitmentTypeQualifier SEQUENCE SIZE (1..MAX) OF
CommitmentTypeQualifier OPTIONAL
}
CommitmentTypeIdentifier ::= OBJECT IDENTIFIER
CommitmentTypeQualifier ::= SEQUENCE {
commitmentTypeIdentifier CommitmentTypeIdentifier,
qualifier ANY DEFINED BY commitmentTypeIdentifier
}
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}
-- Signer Location
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}
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
-- Signer Attributes
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}
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
-- Content Time-Stamp
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}
ContentTimestamp::= TimeStampToken
-- Validation Data
-- Signature Time-Stamp
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}
SignatureTimeStampToken ::= TimeStampToken
-- Complete Certificate Refs.
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}
CompleteCertificateRefs ::= SEQUENCE OF OTHERCertID
-- Complete Revocation Refs
id-aa-ets-revocationRefs OBJECT IDENTIFIER ::= { iso(1) member-
body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)