XML-Signature Requirements:
Abstract:
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.
Status of this document:
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.
Requirements:
1. Signature Data Model and Syntax:
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 to a part or totality of a XML document. [Charter, Brown]
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)]
2. Format:
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.
3. Cryptography and Processing:
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 and relevant 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).
4.Coordination:
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]
W3C Internationalization Interest Group: [AC Review]
XML Package Working Group: signed content in/over packages.
XML Fragment Working Group: signing portions of XML content.
RSS/XML