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:
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.
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:
In addition, SignedProperties can contain the following optional contents.
See Figure 12-1.
Figure 12-1. XAdES,XAdES-T,and XAdES-C
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.
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.
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.
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.
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.