5.9.  CMS Imported Optional Attributes

   The following attributes may be present with the signed-data; the
   attributes are defined in CMS (RFC 3852 [4]) and are imported into
   the present document.  Where appropriate, the attributes are
   qualified and profiled by the present document.

5.9.1.  signing-time

   The signing-time attribute specifies the time at which the signer
   claims to have performed the signing process.

   Signing-time attribute values for ES have the ASN.1 type SigningTime
   as defined in CMS (RFC 3852 [4]).

      NOTE: RFC 3852 [4] states that dates between January 1, 1950 and
      December 31, 2049 (inclusive) must be encoded as UTCTime.  Any
      dates with year values before 1950 or after 2049 must be encoded
      as GeneralizedTime.

5.9.2.  countersignature

   The countersignature attribute values for ES have ASN.1 type
   CounterSignature, as defined in CMS (RFC 3852 [4]).  A
   countersignature attribute shall be an unsigned attribute.

5.10.  ESS-Imported Optional Attributes

   The following attributes may be present with the signed-data defined
   by the present document.  The attributes are defined in ESS and are
   imported into the present document and are appropriately qualified
   and profiled by the present document.

5.10.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 shall be a signed
   attribute.

   content-reference attribute values for ES have ASN.1 type
   ContentReference, as defined in ESS (RFC 2634 [5]).

   The content-reference attribute shall be used as defined in ESS (RFC
   2634 [5]).

5.10.2.  content-identifier Attribute

   The content-identifier attribute provides an identifier for the
   signed content, for use when a reference may be later required to
   that content; for example, in the content-reference attribute in
   other signed data sent later.  The content-identifier shall be a
   signed attribute.

   content-identifier attribute type values for the ES have an ASN.1
   type ContentIdentifier, as defined in ESS (RFC 2634 [5]).

   The minimal content-identifier attribute 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.

5.10.3.  content-hints Attribute

   The content-hints attribute provides information on the innermost
   signed content of a multi-layer message where one content is
   encapsulated in another.

   The syntax of the content-hints attribute type of the ES is as
   defined in ESS (RFC 2634 [5]).

   When used to indicate the precise format of the data to be presented
   to the user, the following rules apply:

      - the contentType 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; and

      - when the contentType is id-data, the contentDescription shall
        define the presentation format; the format may be defined by
        MIME types.

   When the format of the content is defined by MIME types, the
   following rules apply:

      - the contentType shall be id-data, as defined in CMS (RFC 3852
        [4]);

      - the contentDescription shall be used to indicate the encoding of
        the data, in accordance with the rules defined RFC 2045 [6]; see
        Annex F for an example of structured contents and MIME.

   NOTE 1: id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
   rsadsi(113549) pkcs(1) pkcs7(7) 1 }

   NOTE 2: contentDescription is optional in ESS (RFC 2634 [5]).  It may
   be used to complement contentTypes defined elsewhere; such
   definitions are outside the scope of the present document.

5.11.  Additional Optional Attributes Defined in the Present Document

   This section defines a number of attributes that may be used to
   indicate additional information to a verifier:

      a) the type of commitment from the signer, and/or

      b) the claimed location where the signature is performed, and/or

      c) claimed attributes or certified attributes of the signer,
         and/or

      d) a content time-stamp applied before the content was signed.

5.11.1.  commitment-type-indication Attribute

   There may be situations where 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 commitment-type-indication
   attribute conveys such information.

   The commitment-type-indication attribute shall 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 are defined as part
        of the signature policy; and

      - 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 the present document.

   The following generic commitment types are defined in the present
   document:

id-cti-ets-proofOfOrigin OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 1}

id-cti-ets-proofOfReceipt OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 2}

id-cti-ets-proofOfDelivery OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
cti(6) 3}

id-cti-ets-proofOfSender OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 4}

id-cti-ets-proofOfApproval OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
cti(6) 5}

id-cti-ets-proofOfCreation OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
cti(6) 6}

   These generic commitment types have the following meanings:

   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).

5.11.2.  signer-location Attribute

   The signer-location attribute 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 [11]).

   The signer-location attribute shall be a signed attribute.  The
   following object identifier identifies the signer-location attribute:

id-aa-ets-signerLocation OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 17}

   Signer-location attribute values have ASN.1 type SignerLocation:

SignerLocation ::= SEQUENCE {
   -- at least one of the following shall 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

5.11.3.  signer-attributes Attribute

   The signer-attributes attribute 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 shall 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-attributes 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 RFC 3281: see Section 4.1.

      NOTE 1: Only a single signer-attributes can be used.

      NOTE 2: Attribute and AttributeCertificate are as defined
      respectively in ITU-T Recommendations X.501 [9] and X.509 [1].

5.11.4.  content-time-stamp Attribute

   The content-time-stamp attribute is an attribute that is the
   time-stamp token of the signed data content before it is signed.  The
   content-time-stamp attribute shall be a signed attribute.

   The following object identifier identifies the content-time-stamp
   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 of TimeStampToken (as described in RFC
   3161 [7]) shall be a hash of the value of the eContent field within
   encapContentInfo in the signedData.

   For further information and definition of TimeStampToken, see Section
   7.4.

      NOTE: content-time-stamp indicates that the signed information was
      formed before the date included in the content-time-stamp.

5.12.  Support for Multiple Signatures

5.12.1.  Independent Signatures

   Multiple independent signatures (see Annex B.5) are supported by
   independent SignerInfo from each signer.

   Each SignerInfo shall include all the attributes required under the
   present document and shall be processed independently by the
   verifier.

      NOTE: Independent signatures may be used to provide independent
      signatures from different parties with different signed
      attributes, or to provide multiple signatures from the same party
      using alternative signature algorithms, in which case the other
      attributes, excluding time values and signature policy
      information, will generally be the same.

5.12.2.  Embedded Signatures

   Multiple embedded signatures (see Annex C.5) are supported using the
   countersignature unsigned attribute (see Section 5.9.2).  Each
   counter signature is carried in countersignature held as an unsigned
   attribute to the SignerInfo to which the counter-signature is
   applied.

      NOTE: Counter signatures may be used to provide signatures from
      different parties with different signed attributes, or to provide
      multiple signatures from the same party using alternative
      signature algorithms, in which case the other attributes,
      excluding time values and signature policy information, will
      generally be the same.

6.  Additional Electronic Signature Validation Attributes

   This section specifies attributes that contain different types of
   validation data.  These attributes build on the electronic signature
   specified in Section 5.  This includes:

      - Signature-time-stamp applied to the electronic signature value
        or a Time-Mark in an audit trail.  This is defined as the
        Electronic Signature with Time (CAdES-T); and

      - Complete validation data references that comprise the time-stamp
        of the signature value, plus references to all the certificates
        (complete-certificate-references) and revocation (complete-
        revocation-references) information used for full validation of
        the electronic signature.  This is defined as the Electronic
        Signature with Complete data references (CAdES-C).

      NOTE 1: Formats for CAdES-T are illustrated in Section 4.4, and
      the attributes are defined in Section 6.1.1.

      NOTE 2: Formats for CAdES-C are illustrated in Section 4.4.  The
      required attributes for the CAdES-C signature format are defined
      in Sections 6.2.1 to 6.2.2; optional attributes are defined in
      Sections 6.2.3 and 6.2.4.

   In addition, the following optional extended forms of validation data
   are also defined; see Annex B for an overview of the extended forms
   of validation data:

      - CAdES-X with time-stamp: there are two types of time-stamps used
        in extended validation data defined by the present document;

         - Type 1(CAdES-X Type 1): comprises a time-stamp over the ES
           with Complete validation data (CAdES-C); and

         - Type 2 (CAdES-X Type2): comprises a time-stamp over the
           certification path references and the revocation information
           references used to support the CAdES-C.

      NOTE 3: Formats for CAdES-X Type 1 and CAdES-X Type 2 are
      illustrated in Sections B.1.2 and B.1.3, respectively.

         - CAdES-X Long: comprises the Complete validation data
           references (CAdES-C), plus the actual values of all the
           certificates and revocation information used in the CAdES-C.

      NOTE 4: Formats for CAdES-X Long are illustrated in Annex B.1.1.

         - CAdES-X Long Type 1 or CAdES-X Long Type 2: comprises an
           X-Time-Stamp (Type 1 or Type 2), plus the actual values of
           all the certificates and revocation information used in the
           CAdES-C as per CAdES-X Long.

   This section also specifies the data structures used in Archive
   validation data format (CAdES-A)of extended forms:

      - Archive form of electronic signature (CAdES-A) comprises:

        - the Complete validation data references (CAdES-C),

        - the certificate and revocation values (as in a CAdES-X Long ),

        - any existing extended electronic signature time-stamps
          (CAdES-X Type 1 or CAdES-X Type 2), if present, and

        - the signed user data and an additional archive time-stamp
          applied over all that data.

        An archive time-stamp may be repeatedly applied after long
        periods to maintain validity when electronic signature and
        time-stamping algorithms weaken.

   The additional data required to create the forms of electronic
   signature identified above is carried as unsigned attributes
   associated with an individual signature by being placed in the
   unsignedAttrs field of SignerInfo.  Thus, all the attributes defined
   in Section 6 are unsigned attributes.

      NOTE 5: Where multiple signatures are to be supported, as
      described in Section 5.12, each signature has a separate
      SignerInfo.  Thus, each signature requires its own unsigned
      attribute values to create CAdES-T, CAdES-C, etc.

      NOTE 6: The optional attributes of the extended validation data
      are defined in Sections 6.3 and 6.4.

6.1.  signature time-stamp Attribute (CAdES-T)

   An electronic signature with time-stamp is an electronic signature
   for which part, but not all, of the additional data required for
   validation is available (i.e., some certificates and revocation
   information are available, but not all).

   The minimum structure time-stamp validation data is:

      - the signature time-stamp attribute, as defined in Section 6.1.1,
        over the ES signature value.

6.1.1.  signature-time-stamp Attribute Definition

   The signature-time-stamp attribute is a TimeStampToken computed on
   the signature value for a specific signer; it is an unsigned
   attribute.  Several instances of this attribute may occur with an
   electronic signature, from different TSAs.

   The following object identifier identifies the signature-time-stamp
   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-time-stamp attribute value has ASN.1 type
   SignatureTimeStampToken:

   SignatureTimeStampToken ::= TimeStampToken

   The value of the messageImprint field within TimeStampToken shall be
   a hash of the value of the signature field within SignerInfo for the
   signedData being time-stamped.

   For further information and definition of TimeStampToken, see Section
   7.4.

      NOTE 1: In the case of multiple signatures, it is possible to have
      a:

      - TimeStampToken computed for each and all signers; or

      - TimeStampToken computed on one signer's signature; and no

      - TimeStampToken on another signer's signature.

      NOTE 2: In the case of multiple signatures, several TSTs, issued
      by different TSAs, may be present within the same signerInfo (see
      RFC 3852 [4]).

6.2.  Complete Validation Data References (CAdES-C)

   An electronic signature with Complete validation data references
   (CAdES-C) is an electronic signature for which all the additional
   data required for validation (i.e., all certificates and revocation
   information) is available.  This form is built on the CAdES-T form
   defined above.

   As a minimum, the Complete validation data shall include the
   following:

      - a time, which shall either be a signature-timestamp attribute,
        as defined in Section 6.1.1, or a time-mark operated by a
        Time-Marking Authority;

      - complete-certificate-references, as defined in Section 6.2.1;

      - complete-revocation-references, as defined in Section 6.2.2.

6.2.1.  complete-certificate-references Attribute Definition

   The complete-certificate-references attribute is an unsigned
   attribute.  It references the full set of CA certificates that have
   been used to validate an ES with Complete validation data up to (but
   not including) the signer's certificate.  Only a single instance of
   this attribute shall occur with an electronic signature.

      NOTE 1: The signer's certificate is referenced in the signing
      certificate attribute (see Section 5.7.3).

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-references attribute value has the ASN.1
   syntax CompleteCertificateRefs.

   CompleteCertificateRefs ::=  SEQUENCE OF OtherCertID

   OtherCertID is defined in Section 5.7.3.3.

   The IssuerSerial that shall be present in OtherCertID.  The certHash
   shall match the hash of the certificate referenced.

      NOTE 2: Copies of the certificate values may be held using the
      certificate-values attribute, defined in Section 6.3.3.

      This attribute may include references to the certification chain
      for any TSUs that provides time-stamp tokens.  In this case, the
      unsigned attribute shall be added to the signedData of the
      relevant time-stamp token as an unsignedAttrs in the signerInfos
      field.

6.2.2.  complete-revocation-references Attribute Definition

   The complete-revocation-references attribute is an unsigned
   attribute.  Only a single instance of this attribute shall occur with
   an electronic signature.  It references the full set of the CRL,
   ACRL, or OCSP responses that have been used in the validation of the
   signer, and CA certificates used in ES with Complete validation data.

   This attribute indicates that the verifier has taken due diligence to
   gather the available revocation information.  The references stored
   in this attribute can be used to retrieve the referenced information,
   if not stored in the CMS structure, but somewhere else.

   The following object identifier identifies the
   complete-revocation-references 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-references attribute value has the ASN.1
   syntax CompleteRevocationRefs:

   CompleteRevocationRefs ::=  SEQUENCE OF CrlOcspRef

   CrlOcspRef ::= SEQUENCE {
      crlids      [0]   CRLListID    OPTIONAL,
      ocspids     [1]   OcspListID   OPTIONAL,
      otherRev    [2]   OtherRevRefs OPTIONAL
   }

   CompleteRevocationRefs shall contain one CrlOcspRef for the
   signing-certificate, followed by one for each OtherCertID in the
   CompleteCertificateRefs attribute.  The second and subsequent
   CrlOcspRef fields shall 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 a crlValidatedID, the crlHash is computed over the
   entire DER encoded CRL including the signature.  The crlIdentifier
   would normally be present unless the CRL can be inferred from other
   information.

   The crlIdentifier is to identify the CRL using the issuer name and
   the CRL issued time, which shall correspond to the time thisUpdate
   contained in the issued CRL, and if present, the crlNumber.  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 shall be included.

   The OcspIdentifier is to identify the OCSP response using the issuer
   name and the time of issue of the OCSP response, which shall
   correspond to the time produced as contained in the issued OCSP
   response.  Since it may be needed to make the difference between two
   OCSP responses received within the same second, the hash of the
   response contained in the OcspResponsesID may be needed to solve the
   ambiguity.

      NOTE 1: Copies of the CRL and OCSP responses values may be held
      using the revocation-values attribute defined in Section 6.3.4.

      NOTE 2: It is recommended that this attribute be used in
      preference to the OtherRevocationInfoFormat specified in RFC 3852
      to maintain backwards compatibility with the earlier version of
      this specification.

   The syntax and semantics of other revocation references are outside
   the scope of the present document.  The definition of the syntax of
   the other form of revocation information is as identified by
   OtherRevRefType.

   This attribute may include the references to the full set of the CRL,
   ACRL, or OCSP responses that have been used to verify the
   certification chain for any TSUs that provide time-stamp tokens.  In
   this case, the unsigned attribute shall be added to the signedData of
   the relevant time-stamp token as an unsignedAttrs in the signerInfos
   field.

6.2.3.  attribute-certificate-references Attribute Definition

   This attribute is only used when a user attribute certificate is
   present in the electronic signature.

   The attribute-certificate-references attribute is an unsigned
   attribute.  It references the full set of AA certificates that have

   been used to validate the attribute certificate.  Only a single
   instance of this attribute shall occur with an electronic signature.

   id-aa-ets-attrCertificateRefs OBJECT IDENTIFIER ::=
   { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
   smime(16) id-aa(2) 44}

   The attribute-certificate-references attribute value has the ASN.1
   syntax AttributeCertificateRefs:

   AttributeCertificateRefs ::=  SEQUENCE OF OtherCertID

   OtherCertID is defined in Section 5.7.3.3.

      NOTE: Copies of the certificate values may be held using the
      certificate-values attribute defined in Section 6.3.3.

6.2.4.  attribute-revocation-references Attribute Definition

   This attribute is only used when a user attribute certificate is
   present in the electronic signature and when that attribute
   certificate can be revoked.

   The attribute-revocation-references attribute is an unsigned
   attribute.  Only a single instance of this attribute shall occur with
   an electronic signature.  It references the full set of the ACRL or
   OCSP responses that have been used in the validation of the attribute
   certificate.  This attribute can be used to illustrate that the
   verifier has taken due diligence of the available revocation
   information.

   The following object identifier identifies the
   attribute-revocation-references attribute:

   id-aa-ets-attrRevocationRefs OBJECT IDENTIFIER ::= { iso(1)
   member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
   id-aa(2) 45}

   The attribute-revocation-references attribute value has the ASN.1
   syntax AttributeRevocationRefs:

   AttributeRevocationRefs ::=  SEQUENCE OF CrlOcspRef

6.3.  Extended Validation Data (CAdES-X)

   This section specifies a number of optional attributes that are used
   by extended forms of electronic signatures (see Annex B for an
   overview of these forms of validation data).

6.3.1.  Time-Stamped Validation Data (CAdES-X Type 1 or Type 2)

   The extended validation data may include one of the following
   additional attributes, forming a CAdES-X Time-Stamp validation data
   (CAdES-X Type 1 or CAdES-X Type 2), to provide additional protection
   against later CA compromise and provide integrity of the validation
   data used:

      - CAdES-C Time-stamp, as defined in Section 6.3.5 (CAdES-X Type
        1); or

      - Time-Stamped Certificates and CRLs references, as defined in
        Section 6.3.6 (CAdES-X Type 2).

6.3.2.  Long Validation Data (CAdES-X Long, CAdES-X Long Type 1 or 2)

   The extended validation data may also include the following
   additional information, forming a CAdES-X Long, for use if later
   validation processes may not have access to this information:

      - certificate-values, as defined in Section 6.3.3; and

      - revocation-values, as defined in Section 6.3.4.

   The extended validation data may, in addition to certificate-values
   and revocation-values as defined in Sections 6.3.3 and 6.3.4, include
   one of the following additional attributes, forming a CAdES-X Long
   Type 1 or CAdES-X Long Type 2.

      - CAdES-C Time-stamp, as defined in Section 6.3.3 (CAdES-X long
        Type 1); or

      - Time-Stamped Certificates and CRLs references, as defined in
        Section 6.3.4 (CAdES-X Long Type 2).

   The CAdES-X Long Type 1 or CAdES-X Long Type 2 provides additional
   protection against later CA compromise and provides integrity of the
   validation data used.

      NOTE 1: The CAdES-X-Long signature provides long-term proof of the
      validity of the signature for as long as the CA keys, CRL Issuers
      keys, and OCSP responder keys are not compromised and are
      resistant to cryptographic attacks.

      NOTE 2: As long as the time-stamp data remains valid, the CAdES-X
      Long Type 1 and the CAdES-X Long Type 2 provide the following
      important property for long-standing signatures; that having been
      found once to be valid, it shall continue to be so months or years

      later, long after the validity period of the certificates has
      expired, or after the user key has been compromised.

6.3.3.  certificate-values Attribute Definition

   This attribute may be used to contain the certificate information
   required for the following forms of extended electronic signature:
   CAdES-X Long, ES X-Long Type 1, and CAdES-X Long Type 2; see Annex
   B.1.1 for an illustration of this form of electronic signature.

   The certificate-values attribute is an unsigned attribute.  Only a
   single instance of this attribute shall occur with an electronic
   signature.  It holds the values of certificates referenced in the
   complete-certificate-references attribute.

      NOTE: If an attribute certificate is used, it is not provided in
      this structure but shall be provided by the signer as a
      signer-attributes attribute (see Section 5.11.3).

   The following object identifier identifies the certificate-values
   attribute:

   id-aa-ets-certValues OBJECT IDENTIFIER ::= { iso(1) member-body(2)
   us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 23}

   The certificate-values attribute value has the ASN.1 syntax
   CertificateValues.

   CertificateValues ::=  SEQUENCE OF Certificate

   Certificate is defined in Section 7.1. (which is as defined in ITU-T
   Recommendation X.509 [1]).

   This attribute may include the certification information for any TSUs
   that have provided the time-stamp tokens, if these certificates are
   not already included in the TSTs as part of the TSUs signatures.  In
   this case, the unsigned attribute shall be added to the signedData of
   the relevant time-stamp token.

6.3.4.  revocation-values Attribute Definition

   This attribute is used to contain the revocation information required
   for the following forms of extended electronic signature: CAdES-X
   Long, ES X-Long Type 1, and CAdES-X Long Type 2; see Annex B.1.1 for
   an illustration of this form of electronic signature.

   The revocation-values attribute is an unsigned attribute.  Only a
   single instance of this attribute shall occur with an electronic

   signature.  It holds the values of CRLs and OCSP referenced in the
   complete-revocation-references attribute.

      NOTE: It is recommended that this attribute be used in preference
      to the OtherRevocationInfoFormat specified in RFC 3852 to maintain
      backwards compatibility with the earlier version of this
      specification.

   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 OPTIONAL }

   OtherRevVals ::= SEQUENCE {
      OtherRevValType   OtherRevValType,
      OtherRevVals      ANY DEFINED BY OtherRevValType }

   OtherRevValType ::= OBJECT IDENTIFIER

   The syntax and semantics of the other revocation values
   (OtherRevVals) are outside the scope of the present document.

   The definition of the syntax of the other form of revocation
   information is as identified by OtherRevRefType.

   CertificateList is defined in Section 7.2. (which is as defined in
   ITU-T Recommendation X.509 [1]).

   BasicOCSPResponse is defined in Section 7.3. (which is as defined in
   RFC 2560 [3]).

   This attribute may include the values of revocation data including
   CRLs and OCSPs for any TSUs that have provided the time-stamp tokens,
   if these certificates are not already included in the TSTs as part of
   the TSUs signatures.  In this case, the unsigned attribute shall be
   added to the signedData of the relevant time-stamp token.

6.3.5.  CAdES-C-time-stamp Attribute Definition

   This attribute is used to protect against CA key compromise.

   This attribute is used for the time-stamping of the complete
   electronic signature (CAdES-C).  It is used in the following forms of
   extended electronic signature; CAdES-X Type 1 and CAdES-X Long Type
   1; see Annex B.1.2 for an illustration of this form of electronic
   signature.

   The CAdES-C-time-stamp attribute is an unsigned attribute.  It is a
   time-stamp token of the hash of the electronic signature and the
   complete validation data (CAdES-C).  It is a special-purpose
   TimeStampToken Attribute that time-stamps the CAdES-C.  Several
   instances of this attribute may occur with an electronic signature
   from different TSAs.

      NOTE 1: It is recommended that the attributes being time-stamped
      be encoded in DER.  If DER is not employed, then the binary
      encoding of the ASN.1 structures being time-stamped should be
      preserved to ensure that the recalculation of the data hash is
      consistent.

      NOTE 2: Each attribute is included in the hash with the attrType
      and attrValues (including type and length) but without the type
      and length of the outer SEQUENCE.

   The following object identifier identifies the CAdES-C-Timestamp
   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 CAdES-C-timestamp attribute value has the ASN.1 syntax
   ESCTimeStampToken :

   ESCTimeStampToken ::= TimeStampToken

   The value of the messageImprint field within TimeStampToken shall be
   a hash of the concatenated values (without the type or length
   encoding for that value) of the following data objects:

      - OCTETSTRING of the SignatureValue field within SignerInfo;

      - signature-time-stamp, or a time-mark operated by a Time-Marking
        Authority;

      - complete-certificate-references attribute; and

      - complete-revocation-references attribute.

   For further information and definition of the TimeStampToken, see
   Section 7.4.

6.3.6.  time-stamped-certs-crls-references Attribute Definition

   This attribute is used to protect against CA key compromise.  This
   attribute is used for the time-stamping certificate and revocation
   references.  It is used in the following forms of extended electronic
   signature: CAdES-X Type 2 and CAdES-X Long Type 2; see Annex B.1.3
   for an illustration of this form of electronic signature.

   A time-stamped-certs-crls-references attribute is an unsigned
   attribute.  It is a time-stamp token issued for a list of referenced
   certificates and OCSP responses and/or CRLs to protect against
   certain CA compromises.  Its syntax is as follows:

      NOTE 1: It is recommended that the attributes being time-stamped
      be encoded in DER.  If DER is not employed, then the binary
      encoding of the ASN.1 structures being time-stamped should be
      preserved to ensure that the recalculation of the data hash is
      consistent.

      NOTE 2: Each attribute is included in the hash with the attrType
      and attrValues (including type and length) but without the type
      and length of the outer SEQUENCE.

   The following object identifier identifies the
   time-stamped-certs-crls-references attribute:

   id-aa-ets-certCRLTimestamp OBJECT IDENTIFIER ::=
   { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
   smime(16) id-aa(2) 26}

   The attribute value has the ASN.1 syntax TimestampedCertsCRLs:

   TimestampedCertsCRLs ::= TimeStampToken

   The value of the messageImprint field within the TimeStampToken shall
   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 (CAdES-C):

      - complete-certificate-references attribute; and

      - complete-revocation-references attribute.

6.4.  Archive Validation Data

   Where an electronic signature is required to last for a very long
   time, and the time-stamp token on an electronic signature is in
   danger of being invalidated due to algorithm weakness or limits in
   the validity period of the TSA certificate, it may be required to
   time-stamp the electronic signature several times.  When this is
   required, an archive time-stamp attribute may be required for the
   archive form of the electronic signature (CAdES-A).  This archive
   time-stamp attribute may be repeatedly applied over a period of time.

6.4.1.  archive-time-stamp Attribute Definition

   The archive-time-stamp attribute is a time-stamp token of many of the
   elements of the signedData in the electronic signature.  If the
   certificate-values and revocation-values attributes are not present
   in the CAdES-BES or CAdES-EPES, then they shall be added to the
   electronic signature prior to computing the archive time-stamp token.

   The archive-time-stamp attribute is an unsigned attribute.  Several
   instances of this attribute may occur with an electronic signature
   both over time and from different TSUs.

   The following object identifier identifies the nested
   archive-time-stamp attribute:

   id-aa-ets-archiveTimestampV2  OBJECT IDENTIFIER ::=
   { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
   smime(16) id-aa(2) 48}

   Archive-time-stamp attribute values have the ASN.1 syntax
   ArchiveTimeStampToken

   ArchiveTimeStampToken ::= TimeStampToken

   The value of the messageImprint field within TimeStampToken shall be
   a hash of the concatenation of:

      - the encapContentInfo element of the SignedData sequence;

      - any external content being protected by the signature, if the
        eContent element of the encapContentInfo is omitted;

      - the Certificates and crls elements of the SignedData sequence,
        when present, and;

      - all data elements in the SignerInfo sequence including all
        signed and unsigned attributes.

      NOTE 1: An alternative archiveTimestamp attribute, identified by
      an object identifier { iso(1) member-body(2) us(840)
      rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 27, is defined
      in prior versions of TS 101 733 [TS101733] and in RFC 3126.

      The archiveTimestamp attribute, defined in versions of TS 101 733
      prior to 1.5.1 and in RFC 3126, is not compatible with the
      attribute defined in the current document.  The archiveTimestamp
      attribute, defined in versions 1.5.1 to 1.6.3 of TS 101 733, is
      compatible with the current document if the content is internal to
      encapContentInfo.  Unless the version of TS 101 733 employed by
      the signing party is known by all recipients, use of the
      archiveTimestamp attribute defined in prior versions of TS 101 733
      is deprecated.

      NOTE 2: Counter signatures held as countersignature attributes do
      not require independent archive time-stamps, as they are protected
      by the archive time-stamp against the containing SignedData
      structure.

      NOTE 3: Unless DER is used throughout, it is recommended that the
      binary encoding of the ASN.1 structures being time-stamped be
      preserved when being archived to ensure that the recalculation of
      the data hash is consistent.

      NOTE 4: The hash is calculated over the concatenated data elements
      as received/stored, including the Type and Length encoding.

      NOTE 5: Whilst it is recommended that unsigned attributes be DER
      encoded, it cannot generally be so guaranteed except by prior
      arrangement.  For further information and definition of
      TimeStampToken, see Section 7.4.  The timestamp should be created
      using stronger algorithms (or longer key lengths) than in the
      original electronic signatures and weak algorithm (key length)
      timestamps.

      NOTE 6: This form of ES also provides protection against a TSP key
      compromise.

   The ArchiveTimeStamp will be added as an unsigned attribute in the
   SignerInfo sequence.  For the validation of one ArchiveTimeStamp, the
   data elements of the SignerInfo must be concatenated, excluding all
   later ArchivTimeStampToken attributes.

   Certificates and revocation information required to validate the
   ArchiveTimeStamp shall be provided by one of the following methods:

      - The TSU provides the information in the SignedData of the
        timestamp token;

      - Adding the complete-certificate-references attribute and the
        complete-revocation-references attribute of the TSP as an
        unsigned attribute within TimeStampToken, when the required
        information is stored elsewhere; or

      - Adding the certificate-values attribute and the
        revocation-values attribute of the TSP as an unsigned attribute
        within TimeStampToken, when the required information is stored
        elsewhere.