This section provides a general top down overview of XML digital signature syntax with commentary. Information sufficiently detailed to implement the standard appears in later sections. General familiarity with digital signature concepts and XML syntax is assumed.
Signature ElementXML 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 itself.
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 availabe
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 a third party even though that party needs
to be able to verify the signature in which case an extract from
the KeyInfo can be passed to the third party.
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 a 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.
SignedInfo ElementThe SignedInfo element has the following structure:
<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 hashed as part of the
signature verification. This is optional because, being a known XML structure,
this canonicalization can usually be defaulted.
The SignatureAlg is mandatory. Including it in the signed
information resists attacks based on substituting a weaker algorithm for
the one used in signing which is also the reason that c14nAlg
is included.
The ObjectReference elements specify the things secured by
the signature. As specified in more detail below, they point to the thing,
specify any canonicalizations, transformations, or decoding or encoding
applied, 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, under some circumstances, it is possible to change a signature
from one where the data in enclosed as an Object to one where
the Object appears elsewhere without breaking the signature.
ObjectReference ElementThe ObjectReference element has the following structure:
...
<SignedInfo>(c14nAlg)?
(SignatureAlg)
<ObjectReference>(Location)?
(Type)?
(Transformations)?
(DigestAlg)
(DigestValue)
</ObjectReference>+</SignedInfo>
...
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 its surrounding XML document, the only kind of
location for which support is mandatory are are IDREFs as fragment pointers.
Optionally, full Xlink capability can be supported and need not point at
Object elements.
Location is optional for brevity in some simple applications
where it defaults to TBD.
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.
Transformations is an optional ordered list of processing steps
that are applied to the thing at Location before it is digested.
These transformation can include canonicalizations, encoding, decoding, and
XSLT transforms. XSLT 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
value or the entire signature from the data covered.
DigestAlg is the algorithm which, when applied to the thing
at Location after Transformations is applied results
in DigestValue. The signing of the digest values is what secures
the things pointed to.
Manifest and Package ElementsThere are many cases where it is efficient to have one signature covering
many items but the core behavior of XML DSIG, where content of everything
secured must be digested and the signed digest verified, is not desireable.
The Manifest structure asserts the correctness of the digests
given but leaves it entirely up to the application which it will verify.
(more to be written)
(to be written)