IETF LogoW3C Logo

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>

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

  1. How do I sign multiple data objects with the same signature?
    1. SignedInfo can have multiple references.
  2. How do I sign a single data object with multiple keys?
    1. 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.
  3. 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?
    1. If the data is addressable by a URI, you could create a detached signature. The SignedInfo Reference would include a URI to the data.
    2. 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).
  4. I have a whole XML document. How do I sign it?
    1. 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.
    2. 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.
    3. You could create an enveloped signature inside the XML document. The SignedInfo Reference would refer to the document’s root element. The signature would have to use transforms to excluded itself from the message digested in the Reference’s DigestValue.

  5. 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
    1. 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.
    2. S could also be made an enveloping signature by placing E within S, or an enveloped signature by placing S within E.
  6. 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.
    1. Create multiple detached signatures as sibling elements of E. Each signature’s SignedInfo Reference could identify E by its ID or by transform.
    2. 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.
  7. 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?
    1. Create an enveloping signature around the root element of the document.
    2. Create an enveloped signature. The signature is placed inside the document, and its SignedInfo Reference contains transforms that omit the signature from the document.
  8. 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 element’s ancestors?
    1. For namespace attributes in particular, one could canonicalize the content using [Canonical XML].
    2. One can use Xpath transforms to include the start and end tags of relevant ancestors while excluding the unwanted descendants of those ancestors.
  9. 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?
    1. Don’t 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.
  10. 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 signer’s changes without breaking the first signer’s signature and without undermining the security of the first signer’s signature?
    1. 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.
  11. How do I sign everything related to what the user was looking at when s/he signed?
    1. This can be quite application-specific.  If an application’s 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.
    2. 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.
      1. Two SignedInfo References, one to data and one to the rendering information.
      2. If the rendering information is specifically an XSL stylesheet, then the XSLT transform could be used and the resulting document could be signed.
  12. How do I give the application more control over signed reference validation?
    1. Use a dsig:Manifest or element types from an external application namespace with their own semantics.
  13. How do I create a signature over some content at a URL such that I can change the URL without breaking the signature?
    1. 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.
  14. 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)?
    1. 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.
  15. How do I change an enveloping signature to a detached signature without breaking the signature?
    1. Manifest + transforms to omit URI and certain specific transforms.
  16. Does XML Signature provide for non-repudiation?
    1. 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.