12.1 Levels of XAdES Signature

The ETSI draft defines a series of augmented XML signatures, each of which builds on and requires all information required by the previous type of augmented XML signature. The levels are as follows:

  • XAdES (XML Advanced Electronic Signature)

  • XAdES-T (XAdES with additional time stamp)

  • XAdES-C (XAdES-T with complete validation data references)

  • XAdES-X (XAdES-C with extended validation data)

  • XAdES-XL (XAdES-X with complete validation data information)

  • XAdES-A (XAdES-XL with one or more embedded archival time stamps)

The validation of an electronic signature according to the ETSI draft criterion requires not only the signature, but also a signed signature policy, various signature properties, and validation data such as certificates, revocation status information, and time stamps. The signer or the verifier may collect this validation data. Higher-level ETSI advanced signatures include the data in the extended signature object.

The signature policy specifies the requirements for a signature to meet a particular business need, including both technical and procedural requirements. It also covers signature creation and validation.

12.1.1 XAdES

The first level of advanced signature is built on an XMLDSIG structure by adding one enveloped Object element that has either a QualifyingProperties or a QualifyingPropertiesReference child. QualifyingProperties is used to directly include properties in the signature and can occur zero or one time. QualifyingPropertiesReference indirectly includes properties stated elsewhere and can occur zero or more times. All QualifiedProperties and Qualified PropertiesReferences in a signature must occur within the same Object element. QualifyingProperties in turn has two children, SignedProperties and Unsigned Properties.

SignedProperties, whether directly present in a QualifyingProperties element or indirectly present though a QualifyingPropertiesReference element, must be the target of a Reference element in the Signature being enhanced. Furthermore, the Reference must use the Type attribute with a value of


Mandatory contents of the SignedProperties element of an XAdES are as follows:

  • A reference to the certificate with the signer's public key that the signer selected for this XAdES. While XMLDSIG is concerned primarily with cryptographic security, XAdES focuses on trust. As a consequence, it must know the exact certificate used because policy constraints apply to that certificate and because revocations are done at a certificate level. (See Section 12.3.2.)

  • A reference to the signature policy to be used, so a verifier can use the same policy as the signer. (See Section 12.3.3.)

  • The time at which the signer claims to have created the signature. (See Section 12.3.1.)

In addition, SignedProperties can contain the following optional contents.

  • An indication of the content format so that the verifier will interpret the signed data properly. (See Section 12.3.5.)

  • A commitment type. It is required only if the signature policy indicates that more than one commitment type is possible, which alters the intention of the signature (e.g., proof of origin, proof of receipt). (See Section 12.3.6.)

  • Any additional information that the application requires the signature policy to sign.

  • The claimed or certified role assumed by the signer in creating the signature. (See Section 12.3.8.)

  • Contact information for the signer as claimed by the signer. (See Section 12.3.7.)

  • A content time stamp to prove the signature was created after that time. (See Section 12.3.9.)

See Figure 12-1.

Figure 12-1. XAdES,XAdES-T,and XAdES-C


12.1.2 XAdES-T

To build an XAdES-T (time stamped) from an XAdES, you need to obtain a time stamp across the signature (see Section 12.4.1) and add it as a child of the UnsignedProperties element of the XAdES. See Figure 12-1.

12.1.3 XAdES-C

To build an XAdES-C (complete) from an XAdES-T, you must add references to the full set of data supporting the validity of the signature. (Refer to Sections 12.4.2 and 12.4.3.) That is, you must add references to all certificates in the certification path to be used by the verifier with certificate revocation lists or OCSP tokens for each issuer, showing that the certificates have not been revoked. You add this information as a child of the UnsignedProperties element of the XAdES-T. See Figure 12-1.

12.1.4 XAdES-X

When an XAdES-C is "complete," you can add extended validation information to it to produce an XAdES-X (extended) or XAdES-XL signature. See Figure 12-2.

Figure 12-2. XAdES-A,XAdES-XL,and XAdES-X


To build an XAdES-X, you add a time stamp over the entire XAdES-C structure or over the references to the complete set of validating data that the XAdES-C requires, as Sections 12.4.4 and 12.4.5 describe.

12.1.5 XAdES-XL

An XAdES-XL (extended long-term) is a long-term version of XAdES-X. In the long run, you may not be able to dereference the references to validation data that XAdES-C requires. The XAdES-XL, therefore, requires that you include the actual validation data, not just references to it (as Sections 12.4.6 and 12.4.7 specify) as a child element of the UnsignedSignatureProperties element. See Figure 12-2.

12.1.6 XAdES-A

An XAdES-A (archival) is built from an XAdES-XL or an earlier XAdES-A by time stamping the XAdES-XL or earlier XAdES-A as Section 12.4.8 specifies. This time stamping should be done with stronger keys and stronger/newer algorithms than are used in the signature being stamped. This approach proves that the signature was created before that time and ensures that it will remain valid against later key compromise or later algorithm weakness as long as the last time stamp itself is still strong. See Figure 12-2.

Secure XML(c) The New Syntax for Signatures and Encryption
Secure XML: The New Syntax for Signatures and Encryption
ISBN: 0201756056
EAN: 2147483647
Year: 2005
Pages: 186

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net