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.
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
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
are also included in the signed information. The signature can not cover itself so the
element is outside
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
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
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
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.
SignedInfo element has the structure indicated below.
c14nAlg is the algorithm which is used to canonicalize the
element before it is digested as part of the signature operation.
SignatureAlg is the algorithm used to convert the canonicalized
SignatureValue. It is a combination of a digest algorithm and a key
dependent algorithm such as RSA-SHA1 or HMAC-SHA1. The
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.
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
that it is possible to change a
Signature from one where the data in enclosed
Object within the
Signature to one where the
appears elsewhere or to move a secure item between locations outside a
without invalidating the signature provided the secured data can still be located from the
ObjectReference element has the structure indicated below.
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
elements and indeed, in the XLink case need not point at XML.
optional for brevity in some simple applications that wish to provide their own default
Type element provides information about the content of the
Location. In particular, it can indicate that the thing consists of
signature attributes or is a
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
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
Transformations is applied results in
signing of the
DigestValue is what secures the thing pointed to.
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
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
in each signature's
The structure of
Manifest, which reuses the
Object elements described above, is as follows:
Package is syntactically identical to a
asserts the identity of the transformed data for all its
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.
Example with ftp and http URLs TBD.
Forms example with XPath TBD.
Example with multiple signatures over Manifests and substantial canonicalization TBD.