W3C Working Draft 1999-July-21
- This Working Group version:
- Latest Public WD version:
- Previous version:
- Joseph Reagle Jr. <firstname.lastname@example.org>
Copyright © 1999
The Internet Society & W3C
(MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing
W3C Status of this Document
This is a WG XML Signature
Requirements consensus candidate draft. This version is based on the first public WD which was
formed from the Charter
[Charter], XML-signature Workshop [WS], and Brown's IETF draft [Brown]. This version is
restructured and includes many changes based on W3C review [AC], mailing
and the July '99 WG discussion [Oslo].
This document attempts to capture the Working Group's consensus though it contains
points which are still in dispute or not well specified. Issues which are still being
actively discussed during the publication of this document are of
and rendered in red by style sheet compliant applications.
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.
Publication as a Working Draft does not imply endorsement by the W3C membership.
This document lists the design principles, scope and requirements for the XML Digital
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,
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 a sign digital content in general, and XML
documents in particular. [Charter]
XML-signatures are generated from a hash over the canonical form of a
signature manifest. The manifest includes references to Web resources, the hash of the
resource content (or its canonicalized form), and (optionally) the resource content type.
Web resources are defined as any digital content content that can be addressed using the
syntax of XLink locator
- The meaning of a signature is simple: The XML-signature syntax associates a
cryptographic signature with Web resources listed in the manifest using XML markup.
- The XML-signature syntax must be extensible such that it can support arbitrary
application/trust semantics and assertion capabilities -- that can also be signed.
- 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-standard-track proposals defining common semantics (e.g., timestamps,
endorsement, etc.) relevant to signed assertions about Web resources in a schema
definition [XML, RDF] or link type
- 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. Identity and key recovery
information are permissible but they are not within the class of required information.
- 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. [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 remove all namespace declarations, others may rewrite
namespace declarations to provide for context independent declarations within every
- XLink [Xlink] within its own signature syntax. Applications must use XLink locators
within the signature manifest to reference 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. [Reagle, 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, Reagle, WebData] In this context, existing
cryptographic provider (and infrastructure) primitives should be taken advantage of.
1. Signature Data Model and Syntax
- XML-signature data structures must be predicated 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, Reagle, Brown, List(Vincent)]
- XML-signatures must be able to apply to a part or totality of a XML document.
- 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, Reagle]
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 negotiation of keying material. [Brown] Resource or algorithm identifier
are a first class objects, and must be addressable by a URI. [Beners-Lee, Reagle]
- 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 a well-formed XML document. [Charter] [What
if it's imported into another document, does this make sene?]
An XML document of a certain type must still be recognizable as its
original type when signed. 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)]
- A key 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
negotiation methods. [Brown]
- The specification must specify at least one required signature canonicalization, content
canonicalization, hash, and signature algorithm.
In the event of redundant attributes within the XML Signature syntax
and relevant cryptographic blobs, XML Signature applications prefer the XML Signature
semantics. [awaiting clarification - Reagle.]
- The XML Signature specification should meet the requirements of the following
- Internet Open Trading Protocol v2.0 [Charter]
- Financial Services Mark Up Language v2.0 [Charter]
- 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
- XML Syntax Working Group [Charter]
- XML Linking Working Group [Charter]
- XML Schema Working Group [Charter]
- Metadata Coordination Group [Charter]
- W3C Internationalization Interest Group [AC Review]