Copyright © 1999 The Internet Society & W3C (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
This is a Last Call XML Signature Requirements public Working Draft. This report is not expected to be advanced to Recommendation. Instead, this Last Call designation is (1) a representation of WG consensus, (2) an invitation for comments that will affect the future course of the technical specification, and (3) an opportunity to identify and obtain commitments regarding WG dependencies. This document will be referred to at least the W3C XML Plenary Interest Group and W3C Chairs Working Group. Last Call period ends when dependencies between WGs have been acknowledged and the Signature Chairs have procured commitments of review. This is expected to take six weeks from the date of publication.
This document attempts to capture the Working Group's consensus though it
contains points which are still uncertain or not well specified. Issues
which are still being actively discussed during the publication of this document
class="discuss" and rendered in navy by style sheet compliant
Please send comments to the editor <email@example.com> and cc: the list <firstname.lastname@example.org>. Publication as a Working Draft does not imply endorsement by the W3C membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite W3C Drafts as other than "work in progress". A list of current W3C working drafts can be found at http://www.w3.org/TR
This document lists the design principles, scope, and requirements for the XML Digital Signature specification. It includes requirements as they relate to the signature syntax, data model, format, cryptographic processing, and external requirements and coordination.
The XML 1.0 Recommendation [XML] describes the syntax of a class of data objects called XML documents. The mission of this working group is to develop a XML syntax used for representing signatures on digital content and procedures for computing and verifying such signatures. Signatures will provide data integrity, authentication, and/or non-repudiatability.
This document lists the design principles, scope, and requirements over three things: (1) the scope of work available to the WG, (2) the XML signature specification, and (3) applications that implement the specification. It includes requirements as they relate to the signature syntax, data model, format, cryptographic processing, and external requirements and coordination. Those things that are required are designated as "must," those things that are optional are designated by "may," those things that are optional but recommended are designated as "should."
Comment: Scenarios are being explored which examine the ability to sign without
requiring a manifest whereas the scope of the signed content is designated
by the relative placement of signature elements in the XML stream/tree. For
<html> .....</body><dsig xmlns="http://..."
xmlns="http://..."> ... </dsig></html>
Comment: A more formal definition of a signed resource is the following evaluates
as true "definition(inputs):constraints" where R is a resource., I is a resource
identifier (URI), and C is content (sequence-of-octects).
signed-resource(I, C, key, sig): there was some request R such that GET(R) = C and address(R) = I and sign-doc(C, key, sig)
sign-doc(C, key, sig): sig is the value of a strong one-way
function over content and key that yields C integrity/validity and K non-repudiability
The WG may specify security requirements that constrain the operation of these dependencies to ensure consistent and secure signature generation and operation. [Oslo]
Comment: A related requirement under consideration is that of being able
to indicate those portions of a document one signs via exclusion of those
portions one does not wish to sign. This allows one to create signatures
that have document closure, retain ancestor information when necessary, and
retain element order of non-continuous regions that must be signed. We are
considering meething this requirement by including a special
<c14n:exclude> element, or by creating an exclude
list accompanying the resource locator, a by asking for a change in the fragment
or XPointer specifications to yield this functionality. See
for further discussion of this issue.
Comment: Another possibility is that an error should be generated, however it isn't where a conflict will be flagged between the various function and application layers regardless.
Comment: Members of the WG are very interested in signing and processing XML fragments and packaged components. Boyer asserts that [XML-fragment] does not "identify non-contiguous portions of a document in such a way that the relative positions of the connected components is preserved." Packaging is a capability critical to XML-Signature applications, but it is clearly dependent on clear trust/semantic definitions, package application requirements, and even cache-like application requirements. It is not clear how this work will be addressed.