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.
This Working Draft of XML Signature Requirements is a very
stable result of this Working Draft having been advanced through W3C Last
Call. Relatively small changes have been made to clarify the stated
requirements during that period. This document will now be advanced as an IETF
Informational RFC.
Please send comments to the editor <reagle@w3.org> and cc: the list <w3c-ietf-xmldsig@w3.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
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."
The specification must describe how to sign digital content, and XML
content in particular. The XML syntax used to represent a signature (over
any content) is described as an XML-signature. [Charter]
XML-signatures are generated from a hash over the canonical form of a
signature manifest. (In this document we use the term manifest to mean a
collection of references to the objects being signed. The specifications
may use the terms manifest, package or other terms differently from this
document while still meeting this requirement.) The manifest must support
references to Web resources, the hash of the resource content (or its
canonicalized form), and (optionally) the resource content type. [Brown,
List(Solo)]
Web resources are defined as any digital content that can be addressed
using the syntax of XLink
locator [XLink]).
The meaning of a signature is simple: The XML-signature syntax
associates the content of resources listed in a manifest with a key via a
strong one-way transformation.
The XML-signature syntax must be extensible such that it can support
arbitrary application/trust semantics and assertion capabilities --
that can also be signed. [Charter(Requirement1&4),
List(Bugbee,
Solo)]
The WG is not chartered to specify trust semantics, but syntax and
processing rules necessary for communicating signature validity
(authenticity, integrity and non-repudiation). [Charter(Requirement1)]
At the Chairs' discretion and in order to test the extensibility of
the syntax, the WG may produce non-critical-path proposals defining
common semantics (e.g., manifest, package, timestamps, endorsement,
etc.) relevant to signed assertions about Web resources in a schema
definition [XML, RDF] or link type definition [XLink].
Comment: A more formal definition of a signed resource
is below. The notation is "definition(inputs):constraints" where
definition evaluates as true for the given inputs and specified
constraints.
signed-resource(URI-of-resource, content, key, signature): (there was some
protocol message at a specific time such that "GET(URI-of-resource) =
content") AND (sign-doc(content, key, sig))
sign-doc(content, key, signature): signature is the value of a strong
one-way transformation over content and key that yields content
integrity/validity and/or key non-repudiability
The specification must not specify methods of confidentiality though the
Working Group may report on the feasibility of such work in a future or
rechartered activity. [List(Bugbee)]
The specification must only require the provision of key information
essential to checking the validity of the cryptographic signature. For
instance, identity and key recovery information might be of interest to
particular applications, but they are not within the class of required
information defined in this specification. [List(Reagle)]
The specification must define or reference at least one
method of canonicalizing and hashing the signature syntax (i.e., the
manifest and signature blocks). [Oslo] The specification must not specify
methods of canonicalizing resource content [Charter], though it may
specify security requirements over such methods. [Oslo] Such content is
normalized by specifying an appropriate content C14N (canonicalization)
algorithm [DOMHASH, XML-C14N]. Applications are expected to normalize
application specific semantics prior to handing data to a XML-signature
application or specify the necessary transformations for this process
within the signature. [Charter]
XML-signature applications must be conformant with the specifications as
follows:
XML-namespaces [XML-namespaces] within its own signature syntax.
Applications may choose C14N algorithms which do or do not process
namespaces within XML content. For instance, some C14N algorithms may
opt to remove all namespace declarations, others may rewrite namespace
declarations to provide for context independent declarations within
every element.
XLink [Xlink] within its own signature syntax. For any resource
identification beyond simple URIs (without fragment IDs) or
fragmentIDs, applications must use XLink locators to reference signed
resources. Signature applications must not embed or expand XLink
references in signed content, though applications may choose C14N
algorithms which provide this feature.
XML-Pointers [XPointer] within its own signature syntax. If
applications reference/select parts of XML documents, they must use
XML-Pointer within an XLink locator. [WS-list(1)]
The WG may specify security requirements that constrain the operation
of these dependencies to ensure consistent and secure signature generation
and operation. [Oslo]
XML-signatures must be developed as part of the broader Web design
philosophy of decentralization, URIs, Web data,
modularity/layering/extensibility, and assertions as statements about
statements. [Berners-Lee, WebData] In this context, existing cryptographic
provider (and infrastructure) primitives should be taken advantage of.
[List(Solo)]
XML-signature data structures must be based on the RDF data model [RDF]
but need not use the RDF serialization syntax. [Charter]
XML-signatures apply to any resource addressable by a locator
-- including non-XML content. XML-signature referents are identified with
XML locators (URIs or fragments) within the manifest that refer to
external or internal resources (i.e., network accessible or within the
same XML document/package). [Berners-Lee, Brown, List(Vincent),
WS, XFDL]
XML-signatures must be able to apply toa part or totality of a XML
document. [Charter, Brown]
Comment: A related requirement under consideration is
requiring the specification to support the ability to indicate those
portions of a document one signs via exclusion of those portions one does
not wish to sign. This feature allows one to create signatures that have
document closure [List(Boyer(1)],
retain ancestor information, and retain element order of non-continuous
regions that must be signed. We are considering implementing this
requirement via (1) a special <dsig:exclude> element,
(2) an exclude list accompanying the resource locator, or (3) the
XML-Fragment or XPointer specifications -- or a requested change to those
specifications if the functionality is not available. See List(Boyer(1,2))
for further discussion of this issue.
Multiple XML-signatures must be able to exist over the static content of
a Web resource given varied keys, content transormations, and algorithm
specifications (signature, hash, canonicalization, etc.). [Charter,
Brown]
XML-signatures are first class objects themselves and consequently must
be able to be referenced and signed. [Berners-Lee]
The specification must permit the use of varied digital
signature and message authentication codes, such as symmetric and
asymmetric authentication schemes as well as dynamic agreement of keying
material. [Brown] Resource or algorithm identifier are a first class
objects, and must be addressable by a URI. [Berners-Lee]
XML-signatures must be able to apply to the original version of an
included/encoded resource. [WS-list (Brown/Himes)]
An XML-signature must be an XML element (as defined by production 39 of the
XML1.0 specification. [XML])
When XML signatures are placed within a document the
operation must preserve(1) the document's root element tag as root and
(2) the root's descendancy tree except for the addition of signature
element(s) in places permitted by the document's content model. For
example, an XML form, when signed, should still be recognizable as a XML
form to its application after it has been signed. [WS-summary]
XML-signature must provide a mechanism that facilitates the production
of composite documents -- by addition or deletion -- while preserving the
signature characteristics (integrity, authentication, and
non-repudiatability) of the consituent parts. [Charter, Brown, List(Bugbee)]
An important use of XML-signatures will be detached Web signatures.
However, signatures may be embedded within or encapsulate XML or encoded
content. [Charter] This WG must specify a simple method of packaging and
encapsulation if no W3C Recommendation is available.
The specification must permit arbitrary cryptographic signature and
message authentication algorithms, symmetric and asymmetric authentication
schemes, and key agreement methods. [Brown]
The specification must specify at least one mandatory to implement
signature canonicalization, content canonicalization, hash, and signature
algorithm.
In the event of redundant attributes within the XML
Signature syntax andrelevant cryptographic blobs, XML Signature
applications prefer the XML Signature semantics.
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.
The signature design and specification text must not permit implementers
to erroneously build weak implementations susceptible to common security
weaknesses (such as as downgrade or algorithm substitution attacks).
The XML Signature specification should meet the requirements of the
following applications:
Internet Open Trading Protocol v1.0 [IOTP]
Financial Services Mark Up Language v2.0 [Charter]
At least one forms application [XFA, XFDL]
To ensure that all requirements within this document are adequately
addressed, the XML Signature specification must be reviewed by a
designated member of the following communities:
XML Syntax Working Group: canonicalization dependencies.
[Charter]
XML Linking Working Group: signature referants. [Charter]
XML Schema Working Group: signature schema design. [Charter]
Metadata Coordination Group: data model design. [Charter]
XML Package Working Group: signed content in/over
packages.
XML Fragment Working Group: signing portions of XML
content.
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.
