tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 3126

 
 
 

Electronic Signature Formats for long term electronic signatures

Part 2 of 3, p. 22 to 48
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 22 
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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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 RFC Part