XML-Signature Requirements

1. Introduction

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 an XML compliant syntax used for representing signatures on Web resources and portions of protocol messages (anything referencable by a URI) and procedures for computing and verifying such signatures. Such signatures will be able to provide data integrity, authentication, and/or non-repudiatability

2. Design Principles and Scope

1. The specification for XML-Signature shall describe how to a digitally sign a Web resource in general, and an XML document in particular. [Charter]
2. The meaning of the signature is very simple:  The XML signature syntax associates the cryptographic signature value with Web resources using XML markup.
   1. This is not an exercise in specifying trust semantics, but syntax and processing rules necessary for communicating signature validity (authenticity, integrity and non-repudiation). [Charter(Requirement1)]
   2. XML Signature is a basis by which trust decisions are enabled. The simple signature XML syntax must be highly extensible such that it can support external application/trust semantics and arbitrarily sophisticated assertion capabilities -- that can also be signed. [Charter(Requirement1&4)]
   3. Validity and Identity
      1. Only enough information necessary to check the validity of the cryptographic signature need be provided. [Reagle]
      2. Each signature shall be associated with information to identify the signer and/or the cryptographic information required to validate the signature.   [List(Solo)]
3. An XML-Signature can apply to a part or totality of an XML document.  [Charter, Brown]
4. More than one signature may exist over any resource.[Charter] The solution shall provide for extended signature functionality such as co-signature, endorsement, plurality of recipients, etc.  [Brown]
5. A key use of XML Signatures will be detached Web signatures. Additionally and in conjunction with XML facilities (including packaging) signatures may be embedded within or encapsulate XML or encoded content. [Charter]
6. The signature syntax specification will not specify methods of serialization or canonicalization. XML content is normalized by specifying an appropriate content C14N (canonicalization) algorithm [DOMHASH, C14N]; applications are expected to normalize application specific semantics prior to handing data to a XML-Signature application. [Charter]
7. XML-Signature applications must
   1. understand XML-Pointers [XPointer]. Applications will reference/select parts of XML documents using XML-Pointer. [Reagle, WS-list(1)]
   2. understand XML-namespaces [XML-namespaces] in the creation of its own signature syntax. Applications may optionally choose C14N algorithms which do or do not process namespaces within XML content.
   3. understand XLink. Applications will use XLink to reference signed resources within the manifest. Signature applications will not embed or expand XLink references in the signed content, though applications may optionally choose C14N algorithms which provide this feature.
8. Implementation/Deployment Philosophy
   1. XML Signatures will be an integral part of the broader Web design philosophy, including decentralization, URIs, Web data, modularity/layering/extensibility, and metadata as statements about statements. [Reagle]
   2. The ability to leverage existing cryptographic provider (and infrastructure) primitives is desirable.  [List(Solo)]

3. Requirements

Signature Data Model and Syntax

1. XML-Signature will use the RDF data model [RDF] but need not use the RDF serialization syntax. [Charter]
2. XML-Signatures can be applied to any Web resource -- 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)]
   1. Entries should include explicit content type information. [List(Solo)]
3. XML-Signatures are first class objects themselves, and consequently referenceable and signable. [Berners-Lee, Reagle]
4. Algorithm Identification
   1. Whenever possible, any resource or algorithm identifier is a first class object, and identified by a URI in a decentralized manner. [Beners-Lee, Reagle]
   2. Ability to specify algorithms independently and to reference the algorithms linked to standard algorithm specifications (e.g. OIDs) [List(Solo)]
5. XML-Signatures must be able to apply to the original unencoded version of an included/encoded resource. [WS-list (Brown/Himes)]

Format

1. An XML-Signature is XML. [Charter]
2. A document of a certain type must still be recognizable as its original type when signed. [WS-summary]
3. The solution shall provide a mechanism that eases the production of composite documents that consist of the combination by addition or deletion of authenticated blocks of information, while preserving verifiability of the origin and authenticity of these blocks of information. [Brown]
4. ?Packaging?

Cryptography

1. The solution shall provide indifferently for digital signature and message authentication codes, considering symmetric and asymmetric authentication schemes as well as dynamic negotiation of keying material. [Brown]

Processing

1. In the event of redundant attributes within the XML Signature syntax and relevant cryptographic blobs, XML Signature applications prefer the XML Signature semantics. [Reagle]

Coordination

The XML Signature specification should meet the requirements of the following applications:

1. Internet Open Trading Protocol v2.0 [Charter]
2. ?Legal XML [List]
3. Financial Services Mark Up Language v2.0 [Charter]

The XML Signature specification must be reviewed by the following W3C communities:

1. XML Syntax Working Group [Charter]
2. XML Linking Working Group [Charter]
3. XML Schema Working Group [Charter]
4. Metadata Coordination Group [Charter]

4. References

Berners-Lee

Axioms of Web Architecture: URIs.
http://www.w3.org/DesignIssues/Axioms.html

Brown-XML-DSig

Internet Draft. Digital Signatures for XML http://search.ietf.org/internet-drafts/draft-brown-xml-dsig-00.txt

C14N

XML Canonicalization Requirements. http://www.w3.org/TR/NOTE-xml-canonical-req

Charter

XML-DSig Charter.
http://www.w3.org/1999/05/XML-DSig-charter-990521.html

DOMHASH

Internet Draft. Digest Values for DOM (DOMHASH) http://search.ietf.org/internet-drafts/draft-hiroshi-dom-hash-01.txt

Infoset-Req

XML Information Set Requirements Note. http://www.w3.org/TR/NOTE-xml-infoset-req

IOTP-DSig

Internet Draft. Digital Signatures for the Internet Open Trading Protocol http://www.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0-dsig-00.txt

Namespaces

Namespaces in XML Recommendation. http://www.w3.org/TR/REC-xml-names

Signature List

http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/

WS (list, summary)

XML-DSig '99: The W3C Signed XML Workshop
http://www.w3.org/DSig/signed-XML99/
http://www.w3.org/DSig/signed-XML99/summary.html

XLink

XML Linking Language
http://www.w3.org/TR/WD-xlink

XML

Extensible Markup Language (XML) Recommendation. http://www.w3.org/TR/REC-xml

XML-namespaces

Namespaces in XML
http://www.w3.org/TR/REC-xml-names/

XPointer

XML Pointer Language (XPointer)
http://www.w3.org/TR/WD-xptr