XML Advanced Electronic Signatures (XAdES)

2.1.1 Contents of XAdES

As it has been stated, a XAdES signature will build on [XMLDSIG] by incorporation of one ds:Object that will be the bag for the whole set of qualifying properties. Some of them will be signed (signed qualifying information grouped within one new element, SignedProperties, see clause 4.2.1 SignedProperties) and others will not be signed (unsigned qualifying information, grouped within the UnsignedProperties element, see clause 4.2.2 UnsignedProperties).

In a XAdES the signature SHALL be applied in the usual way of [XMLDSIG] over the data object(s) to be signed and on the whole set of signed properties (SignedProperties element). The mandatory information in the SignedProperties element is:

• An unambiguous reference to the signer's certificate, e.g. the certificate itself or a reference to it together with a hash value of the certificate. This is particularly important when a signer holds a number of different certificates containing the same public key, to avoid claims by a verifier that the signature implies another certificate with different semantics. This is also important when the signer holds different certificates containing different public keys in order to provide the verifier with the correct signature verification data. Finally, it is also important in case the issuing key of the CA providing the certificate would be compromised (clause 5.2.2 The SigningCertificate element).

• An unambiguous way allowing the identification of the signature policy under which the electronic signature has been produced (clause 5.2.3 The SignaturePolicyIdentifier element). This will ensure that the verifier will be able to use the same signature policy during the verification process. A signature policy is needed to clarify the precise role and commitments that the signer intends to assume with respect to the signed data object, and to avoid claims by the verifier that a different signature policy was implied by the signer.

• The signing time, specifying the time at which the signer claims to have performed the signing process (clause 5.2.1 The SigningTime element).

In addition, the signature can also cover other signed propertiescontaining the following information:

• The data object(s) format(s) that identifies the format of a signed data object (when electronic signatures are not exchanged in a restricted context) to enable the verifier to be presented or use it (text, sound or video) in exactly the same way as intended by the signer (clause 5.2.5 The DataObjectFormat element).

• The commitment type(s) undertaken by the signer in signing (a) signed data object(s) in the context of the selected signature policy (when an explicit commitment is being used); This will be required where a Signature Policy specifies more than a single commitment type, each of which might have different legal interpretations of the intent of the signature (e.g. proof of origin, proof of receipt, proof of creation... ) (clause 5.2.6 The CommitmentTypeIndication element).

• The claimed or certified role assumed by the signer in creating the signature (clause 5.2.8 The SignerRole element).

• The purported place where the signer claims to have produced the signature (clause 5.2.7 The SignatureProductionPlace element).

2.1.2 Contents of XAdES-T

The signer or the verifier can build an XAdES-T by adding to the existentXAdES (as a child of UnsignedProperties element), an XML element (clause 5.1.3 The EncapsulatedPKIDataType data type) encapsulating a time-stamp on the [XMLDSIG] digital signature value, generated by a TSA to prove that the electronic signature was performed before that time (clause 5.3.1 The SignatureTimeStamp element).

2.1.3 Contents of XAdES-C

The signer or the verifier of an electronic signature can create theXAdES-C form by incorporating to the XAdES-T references to the complete set of data supporting its validity (certificate path, certificate revocation lists, OCSP responses [OCSP], etc). The signer or the verifier will create this form by incorporating to the XAdES-T these references, within an XML element whose definition will be given in the present document (clauses 5.4.1 The CompleteCertificateRefs element and 5.4.2 The CompleteRevocationRefs element). This element will be added as a child of the UnsignedProperties element.

4.2.1 SignedProperties

The SignedProperties element contains a number of propertiesthat are collectively signed by the [XMLDSIG] signature.

Alignment with the present document mandates that an element SignedSignatureProperties MUST appear.

Below follows the schema definition for SignedProperties element.

<xsd:element name="SignedProperties" type="SignedPropertiesType" />
<xsd:complexType name="SignedPropertiesType">
  <xsd:sequence>
    <xsd:element name="SignedSignatureProperties"
      type="SignedSignaturePropertiesType"/>
      <xsd:element name="SignedDataObjectProperties" 
        type="SignedDataObjectPropertiesType" minOccurs="0"/>
  </xsd:sequence>
  <xsd:attribute name="Id" type="xsd:ID" use="optional"/>
</xsd:complexType>
                                       

The SignedProperties element MUST contain properties thatqualify the [XMLDSIG] signature itself or the signer. They are included as content of the SignedSignatureProperties element.

The SignedProperties element MAY also contain properties that qualify some of the signed data objects. These properties appear as content of the SignedDataObjectProperties element.

The optional Id attribute can be used to make a reference to the SignedProperties element.

4.2.2 UnsignedProperties

The UnsignedProperties element contains a number ofproperties that are not signed by the [XMLDSIG] signature.

<xsd:element name="UnsignedProperties" type="UnsignedPropertiesType" />
  <xsd:complexType name="UnsignedPropertiesType">
    <xsd:sequence>
      <xsd:element name="UnsignedSignatureProperties" 
        type="UnsignedSignaturePropertiesType" minOccurs="0"/>
        <xsd:element name="UnsignedDataObjectProperties" 
          type="UnsignedDataObjectPropertiesType" minOccurs="0"/>
    </xsd:sequence>
    <xsd:attribute name="Id" type="xsd:ID" use="optional"/>
  </xsd:complexType>
                                       

The UnsignedProperties element MAY contain properties that qualify XML signature itself or the signer. They are included as content of the UnsignedSignatureProperties element.

The UnsignedProperties element MAY also contain properties that qualify some of the signed data objects. These properties appear as content of the UnsignedDataObjectProperties element.

The optional Id attribute can be used to make a reference to the UnsignedProperties element.

4.2.3 SignedSignatureProperties

This element contains properties that qualify the XML signature that hasbeen specified with the Target attribute of the QualifyingProperties container element.

<xsd:element name="SignedSignatureProperties"   type="SignedSignaturePropertiesType" />

<xsd:complexType name="SignedSignaturePropertiesType">
  <xsd:sequence>
    <xsd:element name="SigningTime" type="xsd:dateTime"/>
    <xsd:element name="SigningCertificate" type="CertIDListType"/>
    <xsd:element name="SignaturePolicyIdentifer" 
     type="SignaturePolicyIdentifierType"/>
    <xsd:element name="SignatureProductionPlace" type="SignatureProductionPlaceType" 
     minOccurs="0"/>
    <xsd:element name="SignerRole" type="SignerRoleType" minOccurs="0"/>
  </xsd:sequence>
</xsd:complexType>
                                       

The qualifying property SigningTime is described in detail in clause 5.2.1 The SigningTime element, SigningCertificate in clause 5.2.2 The SigningCertificate element, SignaturePolicyIdentifier in clause 5.2.3 The SignaturePolicyIdentifier element, SignatureProductionPlace in clause 5.2.7 The SignatureProductionPlace element, and SignerRole in clause 5.2.8 The SignerRole element.

4.2.4 SignedDataObjectProperties

This element contains properties that qualify some of the signed dataobjects.

<xsd:element name="SignedDataObjectProperties"   type="SignedDataObjectPropertiesType"/>

<xsd:complexType name="SignedDataObjectPropertiesType">
  <xsd:sequence>
    <xsd:element name="DataObjectFormat" type="DataObjectFormatType" 
      minOccurs="0" maxOccurs="unbounded"/>
    <xsd:element name="CommitmentTypeIndication" 
      type="CommitmentTypeIndicationType" minOccurs="0" 
      maxOccurs="unbounded"/>
    <xsd:element name="AllDataObjectsTimeStamp" type="TimeStampType" 
      minOccurs="0" maxOccurs="unbounded"/>
    <xsd:element name="IndividualDataObjectsTimeStamp" type="TimeStampType" 
      minOccurs="0" maxOccurs="unbounded"/>
  </xsd:sequence>
</xsd:complexType>
                                       

The qualifying property AllDataObjectsTimeStamp is describedin detail in clause 5.2.9 The AllDataObjectsTimeStamp element, IndividualDataObjectsTimeStamp in clause 5.2.10 The AllDataObjectsTimeStamp element, DataObjectFormat in clause 5.2.5 The DataObjectFormatelement, and CommitmentTypeIndication in clause 5.2.6 The CommitmentTypeIndication element.

All these properties qualify the signed data object after all the required transforms have been made.

4.2.5 UnsignedSignatureProperties

This element contains properties that qualify the XML signature that hasbeen specified with the Target attribute of the QualifyingProperties container element. The content of this element is not covered by the XML signature.

<xsd:element name="UnsignedSignatureProperties"   type="UnsignedSignaturePropertiesType"/>

<xsd:complexType name="UnsignedSignaturePropertiesType">
  <xsd:sequence>
    <xsd:element name="CounterSignature" type="CounterSignatureType" 
      minOccurs="0" maxOccurs="unbounded"/>
    <xsd:element name="SignatureTimeStamp" type="TimeStampType" 
      minOccurs="0" maxOccurs="unbounded"/>
    <xsd:element name="CompleteCertificateRefs" 
      type="CompleteCertificateRefsType" minOccurs="0"/>
    <xsd:element name="CompleteRevocationRefs" 
      type="CompleteRevocationRefsType" minOccurs="0"/>
    <xsd:choice>
      <xsd:element name="SigAndRefsTimeStamp" type="TimeStampType" 
        minOccurs="0" maxOccurs="unbounded"/>
      <xsd:element name="RefsOnlyTimeStamp" type="TimeStampType" 
        minOccurs="0" maxOccurs="unbounded"/>
    </xsd:choice>
    <xsd:element name="CertificateValues" type="CertificateValuesType" 
      minOccurs="0"/>
    <xsd:element name="RevocationValues" type="RevocationValuesType" 
      minOccurs="0"/>
    <xsd:element name="ArchiveTimeStamp" type="TimeStampType" 
      minOccurs="0" maxOccurs="unbounded"/>
  </xsd:sequence>
  </xsd:complexType>
                                       

The qualifying property CounterSignature is described indetail in clause 5.2.4 The CounterSignature element, SignatureTimeStamp in clause 5.3.1 The SignatureTimeStamp element, CompleteCertificateRefs in clause 5.4.1 The CompleteCertificateRefs element, CompleteRevocationRefs in clause 5.4.2 The CompleteRevocationRefs element, SigAndRefsTimeStamp in clause 5.5.1 The SigAndRefsTimeStamp element, RefsOnlyTimeStamp in clause 5.5.2 The RefsOnlyTimeStamp element, CertificateValues in clause 5.6.1 The CertificateValues element, RevocationValues in clause 5.6.2 The RevocationValues element, and ArchiveTimeStamp in clause 5.7.1 The ArchiveTimeStamp element.

4.2.6 UnsignedDataObjectProperties

This element contains properties that qualify some of the signed data objects. The signature generated by the signer does not cover the content of this element.

<xsd:element name="UnsignedDataObjectProperties" type="UnsignedDataObjectPropertiesType" />

<xsd:complexType name="UnsignedDataObjectPropertiesType">
  <xsd:sequence>
    <xsd:element name="UnsignedDataObjectProperty" type="AnyType" 
      minOccurs="0" maxOccurs="unbounded"/>
  </xsd:sequence>
</xsd:complexType>
                                       

TS 101733 [ESI] does not specify the usage of any unsigned propertyqualifying the signed data object. The present document, however, incorporates this element for the shake of completeness and to cope with potential future needs for inclusion of such kind of properties. The schema definition leaves open the definition of the contents of this type. The type AnyType is defined in clause 5.1.1 The AnyType data type.

4.3.1 SigningProperties

As has already been stated, all the properties that should be protected bythe signature have to be collected in a single instance of the QualifyingProperties element. Actually these properties are children of the SignedProperties child of this element.

In order to protect the properties with the signature, a ds:Reference element must be added to the [XMLDSIG] signature. This ds:Reference element MUST be composed in such a way that it uses the SignedProperties element mentioned above as the input for computing its corresponding digest.

Additionally, the present document MANDATES the use of the Type attribute of this particular ds:Reference element, with its value set to

http://uri.etsi.org/01903/v1.1.1#SignedProperties

This value indicates that the data used for hash computation is aSignedProperties element and therefore helps a verifying application to detect the signed properties of a signature conforming with the present document.

If the QualifyingProperties element containing the SignedProperties element is stored in a place different from the signature (indirect incorporation), the result of processing the URI and transforms in this ds:Reference element must be the same as the result of processing the URI and transforms in the QualifyingPropertiesReference element pointing to the aforementioned QualifyingProperties element.

4.3.2 QualifyingPropertiesReference

This element contains information about aQualifyingProperties element that is stored in place different from the signature, for instance in another XML document.

<xsd:element name="QualifyingPropertiesReference"   type="QualifyingPropertiesReferenceType"/>

<xsd:complexType name="QualifyingPropertiesReferenceType">
  <xsd:sequence>
    <xsd:element name="Transforms" type="ds:TransformsType" minOccurs="0"/>
  </xsd:sequence>
  <xsd:attribute name="URI" type="xsd:anyURI" use="required"/>
  <xsd:attribute name="Id" type="xsd:ID" use="optional"/>
</xsd:complexType>
                                       

The mandatory URI attribute provides an identifier for the location of theQualifyingProperties element. This could be for instance a URL to a web site where the information can be retrieved, or a name that the participating applications can use to identify a particular QualifyingProperties element.

The optional ds:Transforms element can be used to specify a chain of tranformations that has to be applied to the data referenced by the URI attribute in order to get the actual representation of the QualifyingProperties element. The processing model for the chain of transformations is as defined in clause http://www.w3.org/TR/xmldsig-core/#sec-ReferenceProcessingModel of [XMLDSIG].

The optional Id attribute can be used to make a reference to the QualifyingPropertiesReference element.

5.1.1 The AnyType data type

The AnyType schema data type has a content model that allowsa sequence of arbitrary XML elements that is of unrestricted length. Additionally, an element of this data type can bear an unrestricted number of arbitrary attributes. It is used throughout the remaining parts of this clause wherever the content of an XML element has been left open.

<xsd:complexType name="AnyType" mixed="true">  
  <xsd:sequence>
    <xsd:any namespace="##any"/>
  </xsd:sequence>
  <xsd:anyAttribute namespace="##any"/>
</xsd:complexType>
                               

5.1.2 The ObjectIdentifierType data type

The ObjectIdentifierType data type can be used to identify aparticular data object.

It allows the specification of an unique and permanent identifier of an object. In addition, a textual description of the nature of the data object, and a number of references to documents where additional information about the nature of the data object can be found.

<xsd:complexType name="ObjectIdentifierType">
  <xsd:sequence>
    <xsd:element name="Identifier" type="xsd:anyURI"/>
    <xsd:element name="Description" type="xsd:string" minOccurs="0"/>
    <xsd:element name="DocumentationReferences"
      type="DocumentationReferencesType" minOccurs="0"/>
  </xsd:sequence>
</xsd:complexType>

The Identifier element contains a permanent identifier. Once assigned the identifier can never be re-assigned again. It supports both the mechanism that is used to identify objects in ASN.1 and the mechanism that is usually used to identify objects in an XML environment:

• In ASN.1 an Object IDentifier (OID) is used to identify an object. To encode an OID using the ObjectIdentifierType, the element Identifier MUST contain the OID as a Uniform Resource Name [URN-OID] conforming to the way specified in RFC3061. A textual representation enabling humans to easily understand the meaning of the OID MAY be given using the element Description. The present document does not suggest a particular format for such a textual representation.

• In an XML environment objects are typically identified by means of an Uniform Resource Identifier [URI]. To encode such a URI using the ObjectIdentifierType, the element Identifier MUST be used.

  Please note: Since such a URI represenent a PERMANENT identifier, the URI (scheme, domain name) should be carefully chosen. For example, if a domain ceases to exist, this will also invalidiate all the identifiers specified under the domain, since it could happen that the do- main is reassigned to a different owner who could then change the meaning of the identifiers. .

Should an OID and an URI exist identifying the same object, the present document encourages the use of the URI as explained in the first bullet above.

<xsd:complexType name="IdentifierType"> 
  <xsd:complexContent>
    <xsd:extension base="xsd:anyURI">
      <xsd:attribute name="Qualifier" type="QualifierType" use="optional"/>
    </xsd:extension>
  </xsd:complexContent>
</xsd:complexType>

<xsd:simpleType name="QualifierType">
  <xsd:restriction base="xsd:string">
    <xsd:enumeration value="OIDAsURI"/>
    <xsd:enumeration value="OIDAsURN"/>
  </xsd:restriction>
</xsd:simpleType>
                                       

The optional Description element contains an informal textdescribing the object identifier.

The optional DocumentationReferences element consists of an arbitrary number of references pointing to further explanatory documentation of the object identifier.

<xsd:complexType name="DocumentationReferencesType">  
  <xsd:sequence maxOccurs="unbounded">
    <xsd:element name="DocumentationReference" type="xsd:anyURI"/>
  </xsd:sequence>
</xsd:complexType>
                                       

5.1.3 The EncapsulatedPKIDataType data type

The EncapsulatedPKIDataType is used to incorporate a piece ofPKI data into an XML structure whereas the PKI data is encoded using an ASN.1 encoding mechanism. Examples of such PKI data that are widely used at the time being include X509 certificates and revocation lists, OCSP responses, attribute certificates and time-stamps.

<xsd:complexType name="EncapsulatedPKIDataType">  
  <xsd:complexContent>
    <xsd:extension base="xsd:base64Binary">
      <xsd:attribute name="Id" type="xsd:ID" use="optional"/>
    </xsd:extension>
  </xsd:complexContent>
</xsd:complexType>
                                       

The content of this data type is the piece of PKI data, base64 encoded asdefined in [XMLDSIG]. The optional ID attribute can be used to make a reference to an element of this data type.

5.1.4 The TimeStampType data type

Time-Stamps shall be used with XML Advanced Electronic Signatures in anumber of use cases:

• A XML Advanced Electronic Signature with Time-Stamp (XAdES-T) includes a time-stamp over the XML Advanced Electronic Signature (XAdES) to protect against repudiation in case of a key compromise.

• Two mechanisms are provided for protection against fraudulence in case of a CA key compromise, obtaining the XAdES-X form:

  • A time-stamp only over all certificate and revocation information references of an XML Advanced Electronic Signature with Complete Validation Data (XAdES-C).

  • A time-stamp computed over the signature value, the signature time-stamp and the certificate and revocation information references present in the XML Advanced Electronic Signature with Complete Validation Data (XAdES-C).

• To provide for long term validity of an XML signature, a time-stamp can be applied over an XML Advanced Electronic Signature with Extended Validation Data (XAdES-X-L) to obtain a XAdES-A form. In this case the time-stamp is called an Archive Time-Stamp. Additional time-stamps can be added to this XAdES-A as time goes on.

• Additionally, time-stamps proving that some or all the data objects to be signed have been created before some time can also be added as signed properties to the XAdES.

A time-stamp is obtained by sending the digest value of the given data tothe Time-Stamp Authority (TSA). The returned time-stamp is a signed data that contains the digest value, the identity of the TSA, and the time of stamping. This proves that the given data existed before the time of stamping.

Time-Stamps specified in the present document will be generated on selected parts of the XAdES signature element.

Below follows the schema definition for the data type used for all the time-stamps mentioned above.

<xsd:complexType name="TimeStampType">
  <xsd:sequence>
    <xsd:element name="HashDataInfo" type="HashDataInfoType" 
     maxOccurs="unbounded"/>
    <xsd:choice>
      <xsd:element name="EncapsulatedTimeStamp" 
       type="EncapsulatedPKIDataType"/>
      <xsd:element name="XMLTimeStamp" type="AnyType"/>
    </xsd:choice>
  </xsd:sequence>
</xsd:complexType>

<xsd:complexType name="HashDataInfoType">
  <xsd:sequence>
    <xsd:element name="Transforms" type="ds:TransformsType" minOccurs="0"/>
  </xsd:sequence>
  <xsd:attribute name="uri" type="xsd:anyURI" use="required"/>
</xsd:complexType>
                                       

Each HashDataInfo element contains an uriattribute referencing a data object and one ds:Transforms element indicating the transformations to make to this data object as described in [XMLDSIG].

The sequence of HashDataInfo elements will be used to produce the input of the hash computation process whose result will be included in the time-stamp request to be sent to the TSA.

The actual input to the hash computation is obtained as follows. Each data object referenced in the sequence of elements HashDataInfo is transformed according the indications of the corresponding Transforms element. Once all the referenced data objects have been transformed, the resulting octets are concatenated in the order in which the data objects are referenced.

The time-stamp generated by the TSA can be either an ASN.1 data object (as defined in [TSP], use EncapsulatedTimeStamp), or it can be encoded as XML (use XMLTimeStamp). Since at the time being there is no standard for an XML time-stamp, we provide a placeholder for future use.

5.2.1 The SigningTime element

The SigningTime property specifies the time at which the signer (purportedly) performed the signing process.

The XML Schema recommendation [XML-schema-part-2] defines an XML type xsd:dateTime that allows for the inclusion of the required information. This is the type selected for the SigningTime element.>

This is a signed property that qualifies the whole signature.

An XML electronic signature aligned with the present document MUST contain exactly one SigningTime element .

Below follows the schema definition for this element:

<xsd:element name="SigningTime" type="xsd:dateTime"/>

5.2.2 The SigningCertificate element

According to what has been stated in the Introduction clause, anelectronic signature produced in accordance with the present document incorporates: "a commitment that has been explicitly endorsed under a signature policy, at a given time, by a signer under an identifier, e.g. a name or a pseudonym, and optionally a role".

In many real life environments users will be able to get from different CAs or even from the same CA, different certificates containing the same public key for different names. The prime advantage is that a user can use the same private key for different purposes. Multiple use of the private key is an advantage when a smart card is used to protect the private key, since the storage of a smart card is always limited. When several CAs are involved, each different certificate may contain a different identity, e.g. as a national or as an employee from a company. Thus when a private key is used for various purposes, the certificate is needed to clarify the context in which the private key was used when generating the signature. Where there is the possibility of multiple use of private keys it is necessary for the signer to indicate to the verifier the precise certificate to be used.

Many current schemes simply add the certificate after the signed data and thus are subject to various substitution attacks. An example of a substitution attack is a "bad" CA that would issue a certificate to someone with the public key of someone else. If the certificate from the signer was simply appended to the signature and thus not protected by the signature, any one could substitute one certificate by another and the message would appear to be signed by some one else.

In order to counter this kind of attack, the identifier of the certificate has to be protected by the digital signature from the signer.

The SigningCertificate property is designed to prevent thesimple substitution of the certificate. This property contains references to certificates and digest values computed on them.

The certificate used to verify the signature shall be identified in the sequence; the signature policy may mandate other certificates be present, that may include all the certificates up to the point of trust.

This is a signed property that qualifies the signature.

An XML electronic signature aligned with the present document MUST contain exactly one SigningCertificate element .

Below follows the schema definition:

<xsd:element name="SigningCertificate" type="CertIDListType"/>
<xsd:complexType name="CertIDListType">
  <xsd:sequence>
    <xsd:element name="Cert" type="CertIDType" maxOccurs="unbounded"/>
  </xsd:sequence>
</xsd:complexType>

<xsd:complexType name="CertIDType">
  <xsd:sequence>
    <xsd:element name="CertDigest" type="DigestAlgAndValueType"/>
    <xsd:element name="IssuerSerial" type="ds:X509IssuerSerialType"/>
  </xsd:sequence>
</xsd:complexType>

<xsd:complexType name="DigestAlgAndValueType">
  <xsd:sequence>
    <xsd:element name="DigestMethod" type="ds:DigestMethodType"/>
    <xsd:element name="DigestValue" type="ds:DigestValueType"/>
  </xsd:sequence>
</xsd:complexType>
                                       

The SigningCertificate element contains the aforementionedsequence of certificate identifiers and digests computed on the certificates (Cert elements).

The element IssuerSerial contains the identifier of one of the certificates referenced in the sequence. Should the ds:X509IssuerSerial element appear in the signature to denote the same certificate, its value MUST be consistent with the corresponding IssuerSerial element.

If the signer uses an attribute certificate to associate a role with the electronic signature, such a certificate MUST be present in the SignerRole property.

The element CertDigest contains the digest of one of the certificates referenced in the sequence. It contains two elements: DigestMethod indicates the digest algorithm and DigestValue contains the value of the digest.

5.2.3 The SignaturePolicyIdentifier element

The signature policy is a set of rules for the creation and validation ofan electronic signature, under which the signature can be determined to be valid. A given legal/contractual context may recognize a particular signature policy as meeting its requirements.

The signature policy needs to be available in human readable form so that it can be assessed to meet the requirements of the legal and contractual context in which it is being applied.

To facilitate the automatic processing of an electronic signature the parts of the signature policy which specify the electronic rules for the creation and validation of the electronic signature also need to be in a computer processable form.

If no signature policy is identified then the signature may be assumed to have been generated/verified without any policy constraints, and hence may be given no specific legal or contractual significance through the context of a signature policy.

As it has been stated before, any electronic signature claiming alignment with the present document must contain an unambiguous way allowing the identification of the Signature. The present document specifies two alternatives:

• The electronic signature can contain an explicit and unambiguous identifier of a Signature Policy together with a hash value of the signature policy, so it can be verified that the policy selected by the signer is the one being used by the verifier. An explicit signature policy has a globally unique reference, which, in this way, is bound to an electronic signature by the signer as part of the signature calculation. In these cases, for a given explicit signature policy there shall be one definitive form that has a unique binary encoded value. Finally, a signature policy identified in this way may be qualified by additional information.

• Alternatively, the electronic signature can avoid the inclusion of the aforementioned identifier and hash value. This will be possible when the signature policy can be unambiguously derived from the semantics of the type of data object(s) being signed, and some other information, e.g. national laws or private contractual agreements, that mention that a given signature policy must be used for this type of data content. In such cases, the signature will contain a specific empty element indicating that this implied way to identify the signature policy is used instead the identifier and hash value.

The signature policy identifier is a signed property qualifying thesignature.

An XML electronic signature aligned with the present document MUST contain exactly one SignaturePolicyIdentifier element.

Below follows the schema definition for this type:

<xsd:element name="SignaturePolicyIdentifier" type="SignaturePolicyIdentifierType"/>
<xsd:complexType name="SignaturePolicyIdentifierType">
  <xsd:choice>
    <xsd:element name="SignaturePolicyId" type="SignaturePolicyIdType"/>
    <xsd:element name="SignaturePolicyImplied"/>
  </xsd:choice>
</xsd:complexType>

<xsd:complexType name="SignaturePolicyIdType">
  <xsd:sequence>
    <xsd:element name="SigPolicyId" type="ObjectIdentifierType"/>
    <xsd:element ref="ds:Transforms" minOccurs="0"/>
    <xsd:element name="SigPolicyHash" type="DigestAlgAndValueType"/>
    <xsd:element name="SigPolicyQualifiers" 
      type="SigPolicyQualifiersListType" minOccurs="0"/>
  </xsd:sequence>
</xsd:complexType>

<xsd:complexType name="SigPolicyQualifiersListType">
  <xsd:sequence>
    <xsd:element name="SigPolicyQualifier" type="AnyType" 
      maxOccurs="unbounded"/>
  </xsd:sequence>
</xsd:complexType>
                                       

The SignaturePolicyId element will appear when the signaturepolicy is identified using the first alternative. The SigPolicyId element contains an identifier that uniquely identifies a specific version of the signature policy. The SigPolicyHash element contains the identifier of the hash algorithm and the hash value of the signature policy. The SigPolicyQualifier element can contain additional information qualifying the signature policy identifier. The optional ds:Transforms element can contain the transformations performed on the signature policy document before computing its hash. The processing model for these transformations is described in [XMLDSIG].

Alternatively, the SignaturePolicyImplied element will appear when the second alternative is used. This empty element indicates that the data object(s) being signed and other external data imply the signature policy.

<xsd:element name="SPURI" type="xsd:anyURI"/>
<xsd:element name="SPUserNotice" type="SPUserNoticeType"/>

<xsd:complexType name="SPUserNoticeType">
  <xsd:sequence>
    <xsd:element name="NoticeRef" type="NoticeReferenceType" minOccurs="0"/>
    <xsd:element name="ExplicitText" type="xsd:string" minOccurs="0"/>
  </xsd:sequence>
</xsd:complexType>

<xsd:complexType name="NoticeReferenceType">
  <xsd:sequence>
    <xsd:element name="Organization" type="xsd:string"/>
    <xsd:element name="NoticeNumbers" type="IntegerListType"/>
  </xsd:sequence>
</xsd:complexType>

<xsd:complexType name="IntegerListType">
  <xsd:sequence>
    <xsd:element name="int" type="xsd:integer" minOccurs="0"
      maxOccurs="unbounded"/>
  </xsd:sequence>
</xsd:complexType>
                                               

5.2.4 The CounterSignature element

Some electronic signatures may only be valid if they bear more than onesignature. This is the case generally when a contract is signed between two parties. The ordering of the signatures may or may not be important, i.e. one may or may not need to be applied before the other.

Several forms of multiple and counter signatures need to be supported, which fall into two basic categories:

• Independent signatures.

• Embedded signatures.

Independent signatures are parallel signatures where the ordering of thesignatures is not important. Therefore an independent signature will not appear as a CounterSignature property of another independent one.

Embedded signatures are applied one after the other and are used where the order the signatures are applied is important. Multiple embedded signatures are supported using the CounterSignature unsigned property. Each CounterSignature is carried in one CounterSignature element added to the Signature element to which the CounterSignature is applied.

In a qualified Signature the contents of the CounterSignature element are one or more signatures (i.e. ds:Signature elements) of the SignatureValue in the qualified Signature.

A CounterSignature can itself be qualified by a CounterSignature property. Thus it is possible to construct arbitrarily long series of countersignatures.

This is a unsigned property that qualifies the signature.

Below follows the schema definition for this element.

<xsd:element name="CounterSignature" type="CounterSignatureType" />
<xsd:complexType name="CounterSignatureType">
  <xsd:sequence>
    <xsd:element ref="ds:Signature"/>
  </xsd:sequence>
</xsd:complexType>
                                       

The next figure shows a countersigned Signature.

Figure 5. Use of CounterSignature element

5.2.5 The DataObjectFormat element

When presenting signed data to a human user it may be important that there is no ambiguity as to the presentation of the signed data object to the relying party. In order for the appropriate representation (text, sound or video) to be selected by the relying party a content hint may be indicated by the signer. If a relying party system does not use the format specified to present the data object to the relying party, the electronic signature may not be valid. Such a behaviour may have been established by the signature policy, for instance.

The DataObjectFormat element provides information that describes the format of the signed data object. This element MUST be present when it is mandatory to present the signed data object to human users on verification. This is a signed property that qualifies one specific signed data object. In consequence, an XML electronic signature aligned with the present document MAY contain more than one DataObjectFormat elements, each one qualifying one signed data object.

Below follows the schema definition for this element.

<xsd:element name="DataObjectFormat" type="DataObjectFormatType"/>
<xsd:complexType name="DataObjectFormatType">
  <xsd:sequence>
    <xsd:element name="Description" type="xsd:string" minOccurs="0"/>
    <xsd:element name="ObjectIdentifier" type="ObjectIdentifierType" 
      minOccurs="0"/>
    <xsd:element name="MimeType" type="xsd:string" minOccurs="0"/>
    <xsd:element name="Encoding" type="xsd:anyURI" minOccurs="0"/>
  </xsd:sequence>
  <xsd:attribute name="ObjectReference" type="xsd:anyURI" 
   use="required"/>
</xsd:complexType>
                                       

This element can convey:

• Textual information related to the signed data object(s) in element Description.

• An identifier indicating the type of the signed data object(s) in element ObjectIdentifier.

• An indication of the MIME type of the signed data object(s), in element MimeType.

• An indication of the encoding format of the signed data object(s), in element Encoding.

At least one element of Description, ObjectIdentifier and MimeType must be present within the property.

5.2.6 The CommitmentTypeIndication element

According to what has been stated in the Introduction clause, anelectronic signature produced in accordance with the present document incorporates: "a commitment that has been explicitly endorsed under a signature policy, at a given time, by a signer under an identifier, e.g. a name or a pseudonym, and optionally a role".

The commitment type can be indicated in the electronic signature either:

• Explicitly using a commitment type indication in the electronic signature.

• implicitly or explicitly from the semantics of the signed data object.

If the indicated commitment type is explicit by means of a commitment typeindication in the electronic signature, acceptance of a verified signature implies acceptance of the semantics of that commitment type. The semantics of explicit commitment types indications shall be specified either as part of the signature policy or may be registered for generic use across multiple policies.

If a signature includes a commitment type indication other than one of those recognized under the signature policy the signature shall be treated as invalid.

How commitment is indicated using the semantics of the data object being signed is outside the scope of the present document.

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.

• 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 definition of a commitment type includes:

• The object identifier for the commitment.

• A sequence of qualifiers.

The qualifiers can provide more information about the commitment, it couldprovide, for example, information about the context be it contractual/legal/application specific.

If an electronic signature does not contain a recognized commitment type then the semantics of the electronic signature is dependent on the data object being signed and the context in which it is being used.

This is a signed property that qualifies signed data object(s). In consequence, an XML electronic signature aligned with the present document MAY contain more than one CommitmentTypeIndication elements.

Below follows the schema definition for this element.

<xsd:element name="CommitmentTypeIndication" type="CommitmentTypeIndicationType"/>
<xsd:complexType name="CommitmentTypeIndicationType">
  <xsd:sequence>
    <xsd:element name="CommitmentTypeId" type="ObjectIdentifierType"/>
    <xsd:choice>
      <xsd:element name="ObjectReference" type="xsd:anyURI" 
         minOccurs="0" maxOccurs="unbounded"/>
      <xsd:element name="AllSignedDataObjects"/>
    </xsd:choice>
    <xsd:element name="CommitmentTypeQualifiers"
      type="CommitmentTypeQualifiersListType" minOccurs="0"/>
  </xsd:sequence>
</xsd:complexType>

<xsd:complexType name="CommitmentTypeQualifiersListType">
  <xsd:sequence>
    <xsd:element name="CommitmentTypeQualifier" 
      type="AnyType" minOccurs="0" maxOccurs="unbounded"/>
  </xsd:sequence>
</xsd:complexType>
                                       

The CommitmentTypeId element univocally identifies the type of commitment made by the signer. A number of commitments have been already identified in TS 101 733 [ESI] (and consequently assigned a corresponding OIDs), namely:

• Proof of origin indicates that the signer recognizes to have created, approved and sent the signed data object.

• Proof of receipt indicates that signer recognizes to have received the content of the signed data object.

• Proof of delivery indicates that the TSP providing that indication has delivered a signed data object in a local store accessible to the recipient of the signed data object.

• Proof of sender indicates that the entity providing that indication has sent the signed data object (but not necessarily created it).

• Proof of approval indicates that the signer has approved the content of the signed data object.

• Proof of creation indicates that the signer has created the signed data object (but not necessarily approved, nor sent it).

One ObjectReference element refers to oneds:Reference element of the ds:SignedInfo corresponding with one data object qualified by this property. If some but not all the signed data objects share the same commitment, one ObjectReference element MUST appear for each one of them. However, if all the signed data objects share the same commitment, the AllSignedDataObjects empty element MUST be present.

The CommitmentTypeQualifiers element provides means to include additional qualifying information on the commitment made by the signer.

5.2.7 The SignatureProductionPlace element

In some transactions the purported place where the signer was at the timeof signature creation may need to be indicated. In order to provide this information a new property may be included in the signature.

This property specifies an address associated with the signer at a particular geographical (e.g. city) location.

This is a signed property that qualifies the signer.

An XML electronic signature aligned with the present document MAY contain at most one SignatureProductionPlace element.

Below follows the schema definition for this element.

<xsd:element name="SignatureProductionPlace" type="SignatureProductionPlaceType"/>
<xsd:complexType name="SignatureProductionPlaceType">
  <xsd:sequence>
    <xsd:element name="City" type="xsd:string" minOccurs="0"/>
    <xsd:element name="StateOrProvince" type="xsd:string" minOccurs="0"/>
    <xsd:element name="PostalCode" type="xsd:string" minOccurs="0"/>
    <xsd:element name="CountryName" type="xsd:string" minOccurs="0"/>
  </xsd:sequence>
</xsd:complexType>
                                       

5.2.8 The SignerRole element

According to what has been stated in the Introduction clause, anelectronic signature produced in accordance with the present document incorporates: "a commitment that has been explicitly endorsed under a signature policy, at a given time, by a signer under an identifier, e.g. a name or a pseudonym, and optionally a role".

While the name of the signer is important, the position of the signer within a company or an organization can be even more important. Some contracts may only be valid if signed by a user in a particular role, e.g. a Sales Director. In many cases who the sales Director really is, is not that important but being sure that the signer is empowered by his company to be the Sales Director is fundamental.

The present document defines two different ways for providing this feature:

• Using a claimed role name.

• Using an attribute certificate containing a certified role.

Unlike public key certificates that bind an identifier to a public key,Attribute Certificates bind the identifier of a certificate to some attributes of its owner, like a role. The Attribute Authority will be most of the time under the control of an organization or a company that is best placed to know which attributes are relevant for which individual. The Attribute Authority may use or point to public key certificates issued by any CA, provided that the appropriate trust may be placed in that CA. Attribute Certificates may have various periods of validity. That period may be quite short, e.g. one day. While this requires that a new Attribute Certificate is obtained every day, valid for that day, this can be advantageous since revocation of such certificates may not be needed. When signing, the signer will have to specify which Attribute Certificate it selects.

This is a signed property that qualifies the signer.

An XML electronic signature aligned with the present document MAY contain at most one SignerRole element.

Below follows the schema definition for this element.

<xsd:element name="SignerRole" type="SignerRoleType"/>
<xsd:complexType name="SignerRoleType">
  <xsd:sequence>
    <xsd:element name="ClaimedRoles" type="ClaimedRolesListType"
      minOccurs="0"/>
    <xsd:element name="CertifiedRoles" type="CertifiedRolesListType"
      minOccurs="0"/>
  </xsd:sequence>
</xsd:complexType>

<xsd:complexType name="ClaimedRolesListType">
  <xsd:sequence>
    <xsd:element name="ClaimedRole" type="AnyType" maxOccurs="unbounded"/>
  </xsd:sequence>
</xsd:complexType>

<xsd:complexType name="CertifiedRolesListType">
  <xsd:sequence>
    <xsd:element name="CertifiedRole" type="EncapsulatedPKIDataType"
      maxOccurs="unbounded"/>
  </xsd:sequence>
</xsd:complexType>
                                       

This property contains a sequence of roles that the signer can play(element SignerRole). At least one of the two elements ClaimedRoles or CertifiedRoles must be present.

The ClaimedRoles element contains a sequence of roles claimed by the signer but not certified. Additional contents types may be defined on a domain application basis and be part of this element. The namespaces given to the corresponding XML schemas will allow their unambiguous identification in the case these roles use XML.

The CertifiedRoles element contains one or more wrapped attribute certificates for the signer.

5.2.9 The AllDataObjectsTimeStamp element

The AllDataObjectsTimeStamp element contains the time-stampcomputed ds:Reference elements within the ds:SignedInfo referencing whatever the signer wants to sign except the SignedProperties element.

The application must compose the HashDataInfo element(s) in a way that the data referenced by all HashDataInfo together results in the sequence of ds:Reference elements described above.

The AllDataObjectsTimeStamp element is a signed property.

Several instances of this property from different TSAs can occur within the same XAdES.

Below follows the schema definition for this element.

<xsd:element name="AllDataObjectsTimeStamp" type="TimeStampType"/>
                                       

5.2.10 The AllDataObjectsTimeStamp element

The IndividualDataObjectsTimeStamp element contains the time-stamp computed before the signature production, over a sequence formed by SOME ds:Reference elements within the ds:SignedInfo. Note that this sequence cannot contain a ds:Reference computed on the SignedProperties element.

The application must compose the HashDataInfo element(s) in a way that the data referenced by all HashDataInfo together results in the sequence of ds:Reference elements mentioned above.

The IndividualDataObjectsTimeStamp element is a signed property that qualifies the signed data object(s).

Several instances of this property can occur within the same XAdES.

Below follows the schema definition for this element.

<xsd:element name="IndividualDataObjectsTimeStamp" type="TimeStampType"/>

5.3.1 The SignatureTimeStamp element

An important property for long standing signatures is that a signature, having been found once to be valid, shall continue to be so months or years later.

A signer, verifier or both may be required to provide on request, proof that a digital signature was created or verified during the validity period of the all the certificates that make up the certificate path. In this case, the signer, verifier or both will also be required to provide proof that all the user and CA certificates used were not revoked when the signature was created or verified.

It would be quite unacceptable, to consider a signature as invalid even if the keys or certificates were later compromised. Thus there is a need to be able to demonstrate that the signature key was valid around the time that the signature was created to provide long term evidence of the validity of a signature.

Time-stamping by a Time-Stamping Authority (TSA) can provide such evidence. A time-stamp is obtained by sending the hash value of the given data to the TSA. The returned time-stamp is a signed data object that contains the hash value, the identity of the TSA, and the time of stamping. This proves that the given data existed before the time of stamping.

Time-stamping an electronic signature (XAdES) before the revocation of the signer's private key and before the end of the validity of the certificate, provides evidence that the signature has been created while the certificate was valid and before it was revoked.

If a recipient wants to hold a valid electronic signature he will have to ensure that he has obtained a valid time-stamp for it, before that key (and any key involved in the validation) is revoked. The sooner the time-stamp is obtained after the signing time, the better.

It is important to note that signatures may be generated "off-line" and time-stamped at a later time by anyone, for example by the signer or any recipient interested in the value of the signature. The time-stamp can thus be provided by the signer together with the signed data object, or obtained by the recipient following receipt of the signed data object.

The Signature Validation Policy can specify a maximum acceptable time difference which is allowed between the time indicated in the SigningTime element and the time indicated by the SignatureTimeStamp element. If this delay is exceeded then the electronic signature shall be considered as invalid.

The SignatureTimeStamp encapsulates the time-stamp over the ds:SignatureValue element.

The SignatureTimeStamp element is an unsigned property qualifying the signature. A XAdES-T form MAY contain several SignatureTimeSamp elements, obtained from different TSAs.

Below follows the schema definition for this element:

<xsd:element name="SignatureTimeStamp" type="TimeStampType"/>

The SignatureTimeStamp element contains a single HashDataInfo element that refers to the ds:SignatureValue element of the [XMLDSIG] signature. That is, the input for the timestamp hash computation is the ds:SignatureValue XML element.

5.4.1 The CompleteCertificateRefs element

This clause defines the XML element able to carry the aforementioned references to the certificates: the CompleteCertificateRefs element.

This is an unsigned property that qualifies the signature.

An XML electronic signature aligned with the present document MAY contain at most one CompleteCertificateRefs element.

Below follows the schema definition for this element.

<xsd:element name="CompleteCertificateRefs" type="CompleteCertificateRefsType"/>

<xsd:complexType name="CompleteCertificateRefsType">
  <xsd:sequence>
    <xsd:element name="CertRefs" type="CertIDListType" />
  </xsd:sequence>
  <xsd:attribute name="Id" type="xsd:ID" use="optional"/>
</xsd:complexType>

The CertRefs element contains a sequence of Cert elements already defined in clause 5.2.2 The SigningCertificate element, incorporating the digest of each certificate and optionally the issuer and serial number identifier.

5.4.2 The CompleteRevocationRefs element

As it was stated in the previous clause, the XAdES-C signatures add to the XAdES-T the full set of references to the revocation data that have been used in the validation of the signer and CAs certificates. They provide means to retrieve the actual revocation data archived elsewhere in case of dispute and, in this way, to illustrate that the verifier has taken due diligence of the available revocation information.

Currently two major types of revocation data are managed in most of the systems, namely CRLs and responses of on-line certificate status servers, obtained through protocols designed for these purposes, like OCSP protocol [OCSP].

This clause defines the CompleteRevocationRefs element that will carry the full set of revocation information used for the verification of the electronic signature.

This is an unsigned property that qualifies the signature.

An XML electronic signature aligned with the present document MAY contain at most one CompleteRevocationRefs element.

Below follows the schema definition for this element.

<xsd:element name="CompleteRevocationRefs"
  type="CompleteRevocationRefsType"/>

<xsd:complexType name="CompleteRevocationRefsType">
  <xsd:sequence>
    <xsd:element name="CRLRefs" type="CRLRefsType" minOccurs="0"/>
    <xsd:element name="OCSPRefs" type="OCSPRefsType" minOccurs="0"/>
    <xsd:element name="OtherRefs" type="OtherCertStatusRefsType" minOccurs="0"/> 
  </xsd:sequence>
  <xsd:attribute name="Id" type="xsd:ID" use="optional"/>
</xsd:complexType>

<xsd:complexType name="CRLRefsType">
  <xsd:sequence>
    <xsd:element name="CRLRef" type="CRLRefType" maxOccurs="unbounded"/>
  </xsd:sequence>
</xsd:complexType>

<xsd:complexType name="CRLRefType">
  <xsd:sequence>
    <xsd:element name="DigestAlgAndValue" type="DigestAlgAndValueType"/>
    <xsd:element name="CRLIdentifier" type="CRLIdentifierType" minOccurs="0"/>
  </xsd:sequence>
</xsd:complexType>

<xsd:complexType name="CRLIdentifierType">
  <xsd:sequence>
    <xsd:element name="Issuer" type="xsd:string"/>
    <xsd:element name="IssueTime" type="xsd:dateTime" />
    <xsd:element name="Number" type="xsd:integer"  minOccurs="0"/>
  </xsd:sequence>
  <xsd:attribute name="URI" type="xsd:anyURI" use="optional"/>
</xsd:complexType>

<xsd:complexType name="OCSPRefsType">
  <xsd:sequence>
    <xsd:element name="OCSPRef" type="OCSPRefType" maxOccurs="unbounded"/>
  </xsd:sequence>
</xsd:complexType>

<xsd:complexType name="OCSPRefType">
  <xsd:sequence>
    <xsd:element name="OCSPIdentifier" type="OCSPIdentifierType"/>
    <xsd:element name="DigestAlgAndValue" type="DigestAlgAndValueType" 
      minOccurs="0"/>
  </xsd:sequence>
</xsd:complexType>

<xsd:complexType name="OCSPIdentifierType">
  <xsd:sequence>
    <xsd:element name="ResponderID" type="xsd:string"/>
    <xsd:element name="ProducedAt" type="xsd:dateTime"/>
  </xsd:sequence>
  <xsd:attribute name="URI" type="xsd:anyURI" use="optional"/>
</xsd:complexType>

<xsd:complexType name="OtherCertStatusRefsType">
  <xsd:sequence>
    <xsd:element name="OtherRef" type="AnyType" maxOccurs="unbounded"/>
  </xsd:sequence>
</xsd:complexType>

The CompleteRevocationRefs element can contain:

• Sequences of references to CRLs (CRLRefs element).

• Sequences of references to OCSP responses (OCSPRefs element).

• Other references to alternative forms of revocation data (OtherRefs element).

Each element in a CRLRefs sequence (CrlRef element) identifies one CRL. This identification is made by means of:

• The digest of the entire DER encoded (DigestAlgAndValue element).

• A set of data (CRLIdentifier element) including the issuer (Issuer element), the time when the CRL was issued (IssueTime element) and optionally the number of the CRL (Number element). The Identifier element can be dropped if the CRL could be inferred from other information. Its URI attribute could serve to indicate where the identified CRL is archived.

Each element in a OCSPRefs sequence (OcspRef element) identifies one OCSP response. This identification is made by means of:

• A set of data (OCSPIdentifier element) including the name of the server that has produced the referenced response (ResponderID element) and the time indication in the "ProducedAt" field of the referenced response (ProducedAt element). The optional URI attribute could serve to indicate where the OCSP response identified is archived.

• The digest computed on the DER encoded OCSP (DigestAlgAndValue element) response, since it may be needed to differentiate between two OCSP responses by the same server with their "ProducedAt" fields within the same second.

Alternative forms of validation data can be included in this property making use of the OtherRefs element, a sequence whose items (OtherRef elements) can contain any kind of information.

5.5.1 The SigAndRefsTimeStamp element

When an OCSP response is used, it is necessary to time-stamp in particular that response in the case the key from the responder would be compromised. Since the information contained in the OCSP response is user specific and time specific, an individual time-stamp is needed for every signature received. Instead of placing the time-stamp only over the certification path references and the revocation information references, which include the OCSP response, the time-stamp is placed on the the digital signature (ds:Signature element), the time-stamp(s) present in the XAdES-T form, the certification path references and the revocation status references. For the same cryptographic price, this provides an integrity mechanism over the XAdES-C. Any modification can be immediately detected. It should be noticed that other means of protecting/detecting the integrity of the XAdES-C exist and could be used.

The form obtained by the concatenation of successive time-stamps of this type is an XAdES-X (XML Advanced Electronic Signature with extended validation data).

The SigAndRefsTimeStamp element is an unsigned property qualifying the signature. A XAdES-X form MAY contain several SigAndRefsTimeStamp elements, obtained from different TSAs.

Below follows the schema definition for this element.

<xsd:element name="SigAndRefsTimeStamp" type="TimeStampType"/>

The SigAndRefsTimeStamp element contains the folliowing HashDataInfo elements:

• One referring to the ds:SignatureValue element of the qualified [XMLDSIG] signature.

• One per each SignatureTimeStamp property element present in XAdES-T.

• One referring to the CompleteCertificateRefs property element.

• One referring to the CompleteRevocationRefs property element.

That is, the input for the timestamp hash computation is a sequence of the following XML elements:

(ds:SignatureValue, SignatureTimeStamp+, CompleteCertificateRefs, CompleteRevocationRefs).

5.5.2 The RefsOnlyTimeStamp element

Time-Stamping each ES with Complete Validation Data as defined above may not be efficient, particularly when the same set of CA certificates and CRL information is used to validate many signatures.

Time-Stamping CA certificates will stop any attacker from issuing bogus CA certificates that could be claimed to exist before the CA key was compromised. Any bogus time-stamped CA certificates will show that the certificate was created after the legitimate CA key was compromised. In the same way, time-stamping CA CRLs, will stop any attacker from issuing bogus CA CRLs which could be claimed to exist before the CA key was compromised.

Time-Stamping of commonly used certificates and CRLs can be done centrally, e.g. inside a company or by a service provider. This method reduces the amount of data the verifier has to time-stamp, for example it could reduce to just one time-stamp per day (i.e. in the case were all the signers use the same CA and the CRL applies for the whole day). The information that needs to be time-stamped is not the actual certificates and CRLs but the unambiguous references to those certificates and CRLs.

The form obtained by the concatenation of successive time-stamps of this type is an XAdES-X (XML Advanced Electronic Signature with extended validation data).

The hash sent to the TSA will be computed then over the concatenation of CompleteCertificateRefs and CompleteRevocationRefs elements.

The RefsOnlyTimeStamp element is an unsigned property qualifying the signature. A XAdES-X form MAY contain several RefsOnlyTimeStamp elements, obtained from different TSAs.

Below follows the schema definition for this element.

"><xsd:element name="RefsOnlyTimeStamp" type="TimeStampType"/>

The SigAndRefsTimeStamp element contains two HashDataInfo elements:

• The first one refers to the CompleteCertificateRefs property element.

• The second one refers to the CompleteRevocationRefs property element.

That is, the input for the timestamp hash computation is a sequence of the following XML elements:

(CompleteCertificateRefs,CompleteRevocationRefs)

5.6.1 The CertificateValues element

A verifier will have to prove that the certification path was valid, at the time of the validation of the signature, up to a trust point according to the naming constraints and the certificate policy constraints from the "Signature Validation Policy". "Signature Validation Policy" is the term used for the set of rules specifically devoted to the validation process in the Signature Policy. It will be necessary to capture all the certificates from the certification path, starting with those from the signer and ending up with those of the certificate from one trusted root of the "Signature validation policy".

When dealing with long term electronic signatures, all the data used in the verification (including the certificate path) must be conveniently archived. The archiving of all this material with the electronic signature gives place to the XAdES-X-L form.

In principle, the CertificateValues element contains the full set of certificates that have been used to validate the electronic signature, including the signer's certificate. However, it is not necessary to include one of those certificates into this property, if the certificate is already present in the ds:KeyInfo element of the signature.

In fact, both the signer certificate (referenced in the mandatory SigningCertificate property element) and all certificates referenced in the CompleteCertificateRefs property element must be present either in the ds:KeyInfo element of the signature or in the CertificateValues property element.

The CertificateValues is an unsigned property and qualifies the XML signature.

An XML electronic signature aligned with the present document MAY contain at most one CertificateValues element.

<xsd:element name="CertificateValues" type="CertificateValuesType"/>

<xsd:complexType name="CertificateValuesType">
    <xsd:choice minOccurs="0" maxOccurs="unbounded">
        <xsd:element name="EncapsulatedX509Certificate"
          type="EncapsulatedPKIDataType"/>
        <xsd:element name="OtherCertificate" type="AnyType"/>
    </xsd:choice>
    <xsd:attribute name="Id" type="xsd:ID" use="optional"/>
</xsd:complexType>

The EncapsulatedX509Certificate element is able to contain the base64 encoding of a DER-encoded X.509 certificate. The OtherCertificate element is a placeholder for potential future new formats of certificates.

5.6.2 The RevocationValues element

When dealing with long term electronic signatures, all the revocation data used in the verification of such signatures must be stored and conveniently time-stamped as has been stated in clause 4 Syntax overview for arbitration purposes.

Currently two major types of revocation data are managed in most of the systems, namely CRLs and responses of on-line certificate status servers, obtained through protocols designed for these purposes, like [OCSP] protocol.

When using CRLs to get revocation information, a verifier will have to make sure that he or she gets at the time of the first verification the appropriate certificate revocation information from the signer's CA. This should be done as soon as possible to minimize the time delay between the generation and verification of the signature. This involves checking that the signer certificate serial number is not included in the CRL. The signer, the verifier or any other third party may obtain either this CRL. If obtained by the signer, then it shall be conveyed to the verifier. Additional CRLs for the CA certificates in the certificate path must also be checked by the verifier. It may be convenient to archive these CRLs within an XAdES-A for ease of subsequent verification or arbitration.

When using [OCSP] to get revocation information, a verifier will have to make sure that she or he gets at the time of the first verification an OCSP response that contains the status "valid". This should be done as soon as possible after the generation of the signature. The signer, the verifier or any other third party may fetch this OCSP response. Since OCSP responses are transient and thus are not archived by any TSP including CA, it is the responsibility of every verifier to make sure that it is stored in a safe place. The simplest way is to store them associated with the electronic signature in its XAdES-X-L form.

The RevocationValues property element is used to hold the values of the revocation information which are to be shipped with the XML signature in case of an XML Advanced Electronic Signature with Extended Validation Data (XAdES-X-Long).

This is a unsigned property that qualifies the signature.

An XML electronic signature aligned with the present document MAY contain at most one RevocationValues element.

Below follows the schema definition for this element.

<xsd:element name="RevocationValues" type="RevocationValuesType"/>

<xsd:complexType name="RevocationValuesType">
  <xsd:sequence>
    <xsd:element name="CRLValues" type="CRLValuesType" minOccurs="0"/>
    <xsd:element name="OCSPValues" type="OCSPValuesType" minOccurs="0"/>
    <xsd:element name="OtherValues" type="OtherCertStatusValuesType" minOccurs="0"/>
  </xsd:sequence>
  <xsd:attribute name="Id" type="xsd:ID"  use="optional"/>
</xsd:complexType>

Revocation information can include Certificate Revocation Lists (CRLValues) or responses from an online certificate status server (OCSPValues). Additionally a placeholder for other revocation information (OtherValues) is provided for future use.

<xsd:complexType name="CRLValuesType">
  <xsd:sequence>
     <xsd:element name="EncapsulatedCRLValue" type="EncapsulatedPKIDataType" 
       maxOccurs="unbounded"/>
  </xsd:sequence>
</xsd:complexType>

Certificate Revocation Lists (CRLValues) consist of a sequence of at least one Certificate Revocation List. Each EncapsulatedCRLValue will contain the base64 encoding of a DER-encoded X509 CRL.

"><xsd:complexType name="OCSPValuesType">
  <xsd:sequence>
      <xsd:element name="EncapsulatedOCSPValue" 
        type="EncapsulatedPKIDataType" maxOccurs="unbounded"/>
  </xsd:sequence>
</xsd:complexType>

OCSP Responses (OCSPValues) consist of a sequence of at least one OCSP Response. The EncapsulatedOCSPValue element contains the base64 encoding of a DER-encoded OCSP Response.

"><xsd:complexType name="OtherCertStatusValuesType">
  <xsd:sequence>
    <xsd:element name="OtherValue" type="AnyType" maxOccurs="unbounded"/>
  </xsd:sequence>
</xsd:complexType>

The OtherValues element provides a placeholder for other revocation information that can be used in the future. The ObjectIdentifier element is used to specify the type of revocation information that is contained by the subsequent Value element.

5.7.1 The ArchiveTimeStamp element

Advances in computing increase the probability of being able to break algorithms and compromise keys. There is therefore a requirement to be able to protect electronic signatures against this possibility.

Over a period of time weaknesses may occur in the cryptographic algorithms used to create an electronic signature (e.g. due to the time available for cryptoanalysis, or improvements in cryptoanalytical techniques). Before such weaknesses become likely, a verifier should take extra measures to maintain the validity of the electronic signature. Several techniques could be used to achieve this goal depending on the nature of the weakened cryptography. In order to simplify matters, a single technique, called Archive validation data (XAdES-A form), covering all the cases is being used in the present document.

Archive validation data consists of the complete validation data and the complete certificate and revocation data, time-stamped together with the electronic signature. The Archive validation data is necessary if the hash function and the crypto algorithms that were used to create the signature are no longer secure. Also, if it cannot be assumed that the hash function used by the Time-Stamping Authority is secure, then nested time-stamps of Archived Electronic Signature are required.

The potential for Trusted Service Provider (TSP) key compromise should be significantly lower than for user keys, because TSP(s) are expected to use stronger cryptography and better key protection. It can be expected that new algorithms (or old ones with greater key lengths) will be used. In such a case, a sequence of time-stamps will protect against forgery. Each time-stamp needs to be affixed before either the compromise of the signing key or of the cracking of the algorithms used by the TSA. TSAs (Time-Stamping Authorities) should have long keys (e.g. which at the time of drafting the present document was 2048 bits for the signing RSA algorithm) and/or a "good" or different algorithm.

Nested time-stamps will also protect the verifier against key compromise or cracking the algorithm on the old electronic signatures.

The process will need to be performed and iterated before the cryptographic algorithms used for generating the previous time-stamp are no longer secure. Archive validation data may thus bear multiple embedded time-stamps.

The hash sent to the TSA (messageImprint) will be computed on the XAdES-X-L form of the electronic signature and the signed data objects, ie on the sequence formed as explained below.

The ArchiveTimeStamp element is an unsigned property qualifying the signature. A XAdES-A form MAY contain several ArchiveTimeStamp elements.

Below follows the schema definition for this element.

<xsd:element name="ArchiveTimeStamp" type="TimeStampType"/>

The XAdESArchiveTimeStamp element contains the following sequence of HashDataInfo elements:

• One HashDataInfo element for each data object signed by the [XMLDSIG] signature. The result of application of the transforms specified each HashDataInfo must be exactly the same as the octet stream that was originally used for computing the digest value of the corresponding ds:Reference.

• One HashDataInfo element for the ds:SignedInfo element. The result of application of the transforms specified in this HashDataInfo must be exactly the same as the octet stream that was originally used for computing the signature value of the [XMLDSIG] signature.

• One HashDataInfo element for the SignedSignatureProperties element.

• One HashDataInfo element for the SignedDataObjectProperties element.

• One HashDataInfo element for the ds:SignatureValue element.

• One HashDataInfo element per each SignatureTimeStamp property.

• One HashDataInfo element for the CompleteCertificateRefs property.

• One HashDataInfo element for the CompleteRevocationRefs property.

• One HashDataInfo element for the CertificatesValues property (add this property previously if not already present).

• One HashDataInfo element for the RevocationValues property (add this property previously if not already present).

• One HashDataInfo element per each SigAndRefsTimeStamp property (if present).

• One HashDataInfo element per each property RefsOnlyTimeStamp (if present).

• One HashDataInfo element per each any previous XAdESArchiveTimestamp property (if present).