Tech-invite  3GPPspecsRELsGlossariesSIPRFCs
8887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100

in Index   Prev   Next

RFC 3126

Electronic Signature Formats for long term electronic signatures

Pages: 84
Obsoleted by:  5126
Part 2 of 3 – Pages 22 to 48
First   Prev   Next

ToP   noToC   RFC3126 - Page 22   prevText

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].
ToP   noToC   RFC3126 - Page 23
   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].
ToP   noToC   RFC3126 - Page 24

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.
ToP   noToC   RFC3126 - Page 25
   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 }
ToP   noToC   RFC3126 - Page 26
   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.
ToP   noToC   RFC3126 - Page 27
   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
   }
ToP   noToC   RFC3126 - Page 28
   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.
ToP   noToC   RFC3126 - Page 29

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
ToP   noToC   RFC3126 - Page 30
   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.
ToP   noToC   RFC3126 - Page 31
      *  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}
ToP   noToC   RFC3126 - Page 32
      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.
ToP   noToC   RFC3126 - Page 33
   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
ToP   noToC   RFC3126 - Page 34
   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.
ToP   noToC   RFC3126 - Page 35

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
ToP   noToC   RFC3126 - Page 36
   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.
ToP   noToC   RFC3126 - Page 37
   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.
ToP   noToC   RFC3126 - Page 38

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
ToP   noToC   RFC3126 - Page 39
   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.
ToP   noToC   RFC3126 - Page 40
   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}
ToP   noToC   RFC3126 - Page 41
   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].
ToP   noToC   RFC3126 - Page 42

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:
ToP   noToC   RFC3126 - Page 43
      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
ToP   noToC   RFC3126 - Page 44
   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.
ToP   noToC   RFC3126 - Page 45

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).
ToP   noToC   RFC3126 - Page 46

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).
ToP   noToC   RFC3126 - Page 47
      *  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.
ToP   noToC   RFC3126 - Page 48

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)

Next Section