Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5126

CMS Advanced Electronic Signatures (CAdES)

Pages: 141
Informational
Obsoletes:  3126
Part 3 of 7 – Pages 38 to 60
First   Prev   Next

Top   ToC   RFC5126 - Page 38   prevText

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.
Top   ToC   RFC5126 - Page 39
   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
Top   ToC   RFC5126 - Page 40
   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
Top   ToC   RFC5126 - Page 41
      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
Top   ToC   RFC5126 - Page 42
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.
Top   ToC   RFC5126 - Page 43
   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}
Top   ToC   RFC5126 - Page 44
   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.
Top   ToC   RFC5126 - Page 45
   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.
Top   ToC   RFC5126 - Page 46
      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.
Top   ToC   RFC5126 - Page 47
        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
Top   ToC   RFC5126 - Page 48
   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.
Top   ToC   RFC5126 - Page 49
      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}
Top   ToC   RFC5126 - Page 50
   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
}
Top   ToC   RFC5126 - Page 51
   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
Top   ToC   RFC5126 - Page 52
   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).
Top   ToC   RFC5126 - Page 53

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
Top   ToC   RFC5126 - Page 54
      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
Top   ToC   RFC5126 - Page 55
   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.
Top   ToC   RFC5126 - Page 56

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
Top   ToC   RFC5126 - Page 57
      - 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.
Top   ToC   RFC5126 - Page 58

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.
Top   ToC   RFC5126 - Page 59
      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:
Top   ToC   RFC5126 - Page 60
      - 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.



(page 60 continued on part 4)

Next Section