XML Signatures Scenarios FAQ
WG Proposal 18 February 2000
- This version:
- http://www.w3.org/Signature/Drafts/PROP-xmldsig-faq-20000218/
- Latest version:
-
- Previous version:
- http://www.w3.org/TR/1999/NOTE-xhtml-roadmap-19991118
- Editors:
- John Boyer, PureEdge, <jboyer@PureEdge.com>
- (tweaks) Joseph Reagle, W3C, <reagle@w3.org>
Copyright
©2000 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use
and software
licensing rules apply.
Abstract
This note describes common questions XML Signature application scenarios.
Status of this document
This a proposal for advancement as a IETF-draft/W3C-Note by the IETF/W3C XML Signature editors/authors. It is
presently a working document used to shed light on where thet specification can be
improved. At no point will this document be considered normative. This document is work in
progress and does not imply endorsement by the IESG or W3C membership.
Document Conventions
Whenever we speak of an element, we mean the content from the opening angle bracket of
its start tag to the closing angle bracket of its end tag, including all descendant
elements.
Questions
- How do I sign multiple data objects with the same signature?
- SignedInfo can have multiple references.
- How do I sign a single data object with multiple keys?
- Create a seperate Signature for every key that you want to apply to SignedInfo and its
data objects. To remove redundancy where SignedInfo includes many references, create a
single Manifest with each Signature referencing that single Manifest.
- I have some data in a non-XML format (could be any data such as a JPEG, word processor,
database or spreadsheet file). How do I sign it?
- If the data is addressable by a URI, you could create a detached signature.
The SignedInfo Reference would include a URI to the data.
- Alternately, if you have a copy of the data in some temporary file or
memory buffer, you can put the data in an enveloping signature.
The data must be base-64 encoded before putting it an Object element in Signature (because
it is not XML).
- I have a whole XML document. How do I sign it?
- If the XML document is addressable by a URL, then you could create a detached signature.
The SignedInfo Reference would include a URI to the XML document.
- If you have a copy of the XML document in some temporary file or memory
buffer, you can put the data in an enveloping signature.
It is likely that you will have to base-64 encode the XML document since an entire XML
document cannot appear as element content. Alternately, character sequences forbidden from
content by XML can be escaped using the XML escaping mechanism.
You could create an enveloped signature inside
the XML document. The SignedInfo Reference would refer to the documents root
element. The signature would have to use transforms to excluded itself from the message
digested in the References DigestValue.
- I have an XML document containing an XML element E that I would like to sign, where E is
not the root element. How do I add a signature to my document that signs E
- Create a signature S which identifies element E by its ID or by transform. For the sake
of simplicity, S can be placed as a sibling element of E, which would make S a detached signature.
- S could also be made an enveloping signature
by placing E within S, or an enveloped
signature by placing S within E.
- I have an XML document containing an XML element E that I would like to sign with
multiple keys, where E is not the root element. How do I add a signature to my
document that signs E.
- Create multiple detached signatures as sibling elements of E. Each signatures
SignedInfo Reference could identify E by its ID or by transform.
- Alternately, the signatures S1, S2,
could be enveloping signature.
Each successive signature would envelope E as well as the previously affixed signatures.
For example, The first signature S1 envelopes E in an Object, then has a SignedInfo
Reference that indicates the Object. The second signature S2 wraps signature S1 in an
Object, and uses a SignedInfo Reference to indicate the Object containing S1 (and E).
etc.
- I have an XML document. How do I combine that document with a signature such that, in
the resulting document, the signature signs the original document?
- Create an enveloping
signature around the root element of the document.
- Create an enveloped
signature. The signature is placed inside the document, and its SignedInfo Reference
contains transforms that omit the signature from the document.
- I want to sign an element, but some of its meaning is derived from attributes (e.g.
xmlns) and tag names of its ancestor elements. How do I preserve relevant information from
an elements ancestors?
- For namespace attributes in particular, one could canonicalize the content using
[Canonical XML].
- One can use Xpath transforms to include the start and end tags of relevant ancestors
while excluding the unwanted descendants of those ancestors.
- Suppose there are multiple elements in the same document. How do I sign the elements
plus the order in which the elements appeared in the document?
- Dont uses multiple references. Instead, use an Xpath transform, since the expected
result is that the elements included by the Xpath are given in document order.
- Suppose I have a document that must be signed with multiple keys, but the second signer
is allowed to make certain changes before signing. How do I allow the second signers
changes without breaking the first signers signature and without undermining the
security of the first signers signature?
- Xpath transform. The specific elements to be changed have their content omitted by the
transform. The transform is signed. Changing the transform breaks the
signature; changing anything not omitted by the transform breaks the signature.
- How do I sign everything related to what the user was looking at when s/he signed?
- This can be quite application-specific. If an applications document format
already maintains both the data and the information about how to render it, then the
signature need only be made to cover all of the relevant elements in the given document.
- If the application separates the data and rendering information into separate files,
such as XML markup for the data plus an XSL stylesheet, then there are two solutions.
- Two SignedInfo References, one to data and one to the rendering information.
- If the rendering information is specifically an XSL stylesheet, then the XSLT transform
could be used and the resulting document could be signed.
- How do I give the application more control over signed reference validation?
- Use a dsig:Manifest or element types from an external application namespace with their
own semantics.
- How do I create a signature over some content at a URL such that I can change the URL
without breaking the signature?
- Use Reference in a Manifest to indicate the content by URI. Reference in Signature
should indicate Manifest but should have transform that omits URI. Thus, URI can be
changed without breaking signature.
NOTE: Core validation does not validate digest values in Manifest (only in SignedInfo), so
the application must validate the Manifest after calling upon core validation.
- How do I sign combined XML documents where those documents have elements with the same
identifiers (i.e. the ID of each E must be changed to be unique)?
- Use omission Xpath transform to drop the ID and URI pieces. In order to use a
transform, the References to actual elements E must be in a Manifest. Again, this
means that the resulting signatures are application-specific.
- How do I change an enveloping signature to a detached signature without breaking the
signature?
- Manifest + transforms to omit URI and certain specific transforms.
- Does XML Signature provide for non-repudiation?
- The specification does not speak of non-repudation for the following reason. An XML
Signature associates a specific key with a specific message such that it is computational
infeasible for anyone without the key to alter either the message or the signature without
the signature under that key being broken. Consequently, the specification speaks of signer authentication.
Note that the use of assymetric keys does provide for technical non-repudation because
only one person need have access to the key. However, when symmetric key algorithms (like
HMAC) are used both the sender and receiver have access to the key. Furthermore,
non-repudation is frequently defined in the context of the trust model and concerns itself
with the trustworthiness of key distribution and revocation. Consequently, we avoid the
term non-repudiation.