X. Signature Syntax and Processing Overview

This section provides a general top down overview of XML digital signature syntax and processing with commentary. Many details are omitted. Information sufficiently detailed to implement the standard appears in later sections. General familiarity with digital signature concepts and XML syntax is assumed.

X.1 The Signature Element

XML digital signatures are very flexible. They can secure any type of data included within the signature, outside the signature in the same document, outside of the document, or even data which encloses the signature.

XML digital signatures are represented by the Signature element which has the following structure:

<Signature>
  (SignedInfo)
  (SignatureValue)
  (KeyInfo)?
  (Object)*
</Signature>

The required SignedInfo element, further described in the following subsection, is the information which is actually signed. However, the signed data within it includes one or more digests of data objects elsewhere so that those data objects are secured by signing their digest. In addition, the core signature verification includes the verification of these digests. The algorithms used in calculating the SignatureValue are also included in the signed information. The signature can not cover itself so the SignatureValue element is outside SignedInfo.

KeyInfo indicates what key was used to create the signature. It is optional because in some applications the key is implied by the circumstances. A wide variety of KeyInfo forms are available including certificates, key names, key agreement algorithms and information, etc. The keying information is outside of the signed information so that it need not be signed. KeyInfo might contain auxiliary information it is not desired to reveal to all signature verifiers. If KeyInfo were signed, it would be necessary to pass all of it to all verifiers. On the other hand, if it is desired to bind the keying information in to the signature, its digest and a pointer to it can easily be included in the signed information.

Object is ann optional element for representing data. The data can be optionally typed and/or encoded. While Object elements can appear inside a signature as show above, they can also appear outside of the Signature element in the same document or in other documents.

While there is no explicit provision for "attributes", they can be included as a type of Object and thus can easily be secured or not as appropriate.

X.2 The SignedInfo Element

The SignedInfo element has the structure indicated below.

<Signature>
  <SignedInfo>
    (c14nAlg)
    (SignatureAlg)
    (ObjectReference)+
  </SignedInfo>
  (SignatureValue)
  (KeyInfo)?
  (Object)*
</Signature>

The c14nAlg is the algorithm which is used to canonicalize the SignedInfo element before it is digested as part of the signature operation.

The SignatureAlg is the algorithm used to convert the canonicalized SignedInfo into the SignatureValue. It is a combination of a digest algorithm and a key dependent algorithm such as RSA-SHA1 or HMAC-SHA1. The c14nalg and SignatureAlg are signed to resist attacks based on substituting a weaker algorithm.

To promote interoperability, there are mandatory to implement canonicalization and signature algorithms. Additional standard algorithms are specified as Recommended or Optional and user defined algorithms are permitted.

The ObjectReference elements specify the things secured by the signature. As specified in more detail below, they point to the thing, specify any transformations, specify the digest algorithm, and include the digest value itself. It is the signing of this digest value and its verification as part of the signature verification that secures the thing pointed to.

The indirect reference to secured things via the ObjectReference means that it is possible to change a Signature from one where the data in enclosed as an Object within the Signature to one where the Object appears elsewhere or to move a secure item between locations outside a Signature without invalidating the signature provided the secured data can still be located from the same ObjectReference.

X.3 The ObjectReference Element

The ObjectReference element has the structure indicated below.

The Location says where the secured thing is. Because the core signature verification requires verification of digests and about the only thing you can be reasonably confident of is access to the signature structure and any surrounding XML, the only kind of location for which support is mandatory are IDREFs as fragment pointers to elements defined in this specification. For elements not so defined, no DTD may be available making it impossible, in general, to determine what XML attributes are IDs. Optionally, simple (URI) or extended XLink capability can also be supported. In either the fragment or XLink case, Location need not point at Object elements and indeed, in the XLink case need not point at XML. Location is optional for brevity in some simple applications that wish to provide their own default for it.

The optional Type element provides information about the content of the thing at Location. In particular, it can indicate that the thing consists of signature attributes or is a Manifest or Package (see below).

Transformations is an optional ordered list of processing steps that are applied to the thing at Location before it is digested. These transformations can include any number of canonicalizations, encoding and decoding including compression and inflation, and XPath based transforms. XPath transforms permit parts of an XML thing to be omitted. For example, if a thing being secured encloses the signature itself, such a transform must be used to exclude the signature from the data covered. If no Transformations element is present, the data pointed at by Location is digested directly.

To promote interoperability, there are mandatory to implement canonicalization and coding algorithms. Additional standard canonicalization, coding, and XPath based transform algorithms are specified as Recommended or Optional and user defined transformation algorithms are permitted.

DigestAlg is the algorithm which, when applied to the thing at Location after Transformations is applied results in DigestValue. The signing of the DigestValue is what secures the thing pointed to.

X.4 The Manifest and Package Elements

There are cases where it is efficient to have one signature covering many items but the core verification behavior of XML DSIG, where the content of everything secured must be digested and the signed digest verified, is not desireable. For example, it may be sufficient if the signature's validity for n out of m of the items can be verified. Or there may be a large number of items that it is desired to sign with multiple signature algorithms and / or keys where listing all of the item within the SignedInfo element of each Signature is too bulky. For example, there are multiple recipients that understand different algorithms or trust different keying material.

To answer these requirements, the Manifest element is provided which gives and asserts the correctness of the digests for multiple items, but leaves it entirely up to the application which digest or digests it will verify. Multiple signatures over the possibly large number of items in a Manifest need only point to the manifest from one ObjectReference in each signature's SignedInfo.

The structure of Manifest, which reuses the ObjectReference and Object elements described above, is as follows:

A Package is syntactically identical to a Manifest but asserts the identity of the transformed data for all its ObjectReference elements.

X.5 Examples

X.5.1 Simple Protocol

This example assumes a simple protocol where the key and signed data location are known to the application based on the communications channel over which it received the protocol data unit (PDU) and the protocol state or the like. As with other pseudo-XML in this section, details are omitted.

X.5.2 Remote Binary and Text Data

Example with ftp and http URLs TBD.

X.5.3 Form

Forms example with XPath TBD.

X.5.4 Complex Protocol

Example with multiple signatures over Manifests and substantial canonicalization TBD.