roadmap for separation of 2.0 material from 1.1 material in XML Signature 2.0

During our last call we discussed the fact that the XML Signature 2.0 combines existing 1.1 material with new 2.0 content, making it hard to understand what is new. On the other hand we also noted the benefit of a single document to refer to, rather than multiple documents. I took an action to outline an approach we could take if we were to decide to  separate out the  1.1 material. This message is to outline that approach and completes ACTION-738.

If we look at the recently revised XML Signature 2.0 table of contents, we see the following:

• 1. Introduction
• 1.1 Editorial and Conformance Conventions
• 1.2 Design Philosophy
• 1.3 Versions Namespaces and Identifiers
• 1.4 Acknowledgements
• 2. Signature Overview and Examples
• 2.1 Simple Examples (Signature, SignedInfo, Methods, and References)
• 2.1.1 Simple Example in "Compatibility Mode"
• 2.1.2 More on Reference
• 2.1.3 Simple Example in "2.0 Mode"
• 2.2 Extended Example (Object and SignatureProperty)
• 2.3 Extended Example (Object and Manifest)
• 3. Processing Rules
• 3.1 Signature Generation
• 3.2 Core Validation
• 3.3 2.0 Mode Processing
• 3.3.1 Reference Generation in "2.0 Mode"
• 3.3.2 Reference check in "2.0 Mode"
• 3.3.3 Signature Validation in "2.0 Mode"
• 3.3.4 Reference Validation in "2.0 Mode"
• 3.4 Compatibility Mode Processing
• 3.4.1 Reference Generation in "Compatibility Mode"
• 3.4.2 Reference check in "Compatibility Mode"
• 3.4.3 Signature Validation in "Compatibility Mode"
• 3.4.4 Reference Validation in "Compatibility Mode"
• 4. Core Signature Syntax
• 4.1 The ds:CryptoBinary Simple Type
• 4.2 The Signature element
• 4.3 The SignatureValue Element
• 4.4 The SignedInfo Element
• 4.4.1 The CanonicalizationMethod Element
• 4.4.1.1 Use of CanonicalizationMethod in "2.0 Mode"
• 4.4.1.2 Use of CanonicalizationMethod in "Compatibility Mode"
• 4.4.2 The SignatureMethod Element
• 4.4.3 The Reference Element
• 4.4.3.1 Signature Modes
• 4.4.3.2 The URI Attribute
• 4.4.3.2.1 The "Compatibility Mode" Reference Processing Model
• 4.4.3.2.2 "Compatibility Mode" Same-Document URI-References
• 4.4.3.3 The Transforms Element
• 4.4.3.3.1 The "Compatibility Mode" Transforms Processing Model
• 4.4.3.3.2 The "2.0 Mode" Transforms Processing Model
• 4.4.3.4 The DigestMethod Element
• 4.4.3.5 The DigestValue Element
• 4.5 The KeyInfo Element
• 4.5.1 The KeyName Element
• 4.5.2 The KeyValue Element
• 4.5.2.1 The DSAKeyValue Element
• 4.5.2.2 The RSAKeyValue Element
• 4.5.2.3 The dsig11:ECKeyValue Element
• 4.5.2.3.1 Explicit Curve Parameters
• 4.5.2.3.2 Compatibility with RFC 4050
• 4.5.3 The RetrievalMethod Element
• 4.5.4 The X509Data Element
• 4.5.4.1 Distinguished Name Encoding Rules
• 4.5.5 The PGPData Element
• 4.5.6 The SPKIData Element
• 4.5.7 The MgmtData Element
• 4.5.8 XML Encryption EncryptedKey and DerivedKey Elements
• 4.5.9 The dsig11:DEREncodedKeyValue Element
• 4.5.10 The dsig11:KeyInfoReference Element
• 4.6 The Object Element
• 5. Additional Signature Syntax
• 5.1 The Manifest Element
• 5.2 The SignatureProperties Element
• 5.3 Processing Instructions in Signature Elements
• 5.4 Comments in Signature Elements
• 6. Algorithms
• 6.1 Algorithm Identifiers and Implementation Requirements
• 6.2 Message Digests
• 6.2.1 SHA-1
• 6.2.2 SHA-256
• 6.2.3 SHA-384
• 6.2.4 SHA-512
• 6.3 Message Authentication Codes
• 6.3.1 HMAC
• 6.4 Signature Algorithms
• 6.4.1 DSA
• 6.4.2 RSA (PKCS#1 v1.5)
• 6.4.3 ECDSA
• 6.5 "2.0 Mode" Canonicalization Algorithms
• 6.5.1 Canonical XML 2.0
• 6.6 "Compatibility Mode" Canonicalization Algorithms
• 6.6.1 Canonical XML 1.0
• 6.6.2 Canonical XML 1.1
• 6.6.3 Exclusive XML Canonicalization 1.0
• 6.7 "2.0 Mode" Transform Algorithm
• 6.7.1 The dsig2:Selection Element
• 6.7.1.1 Subtrees with Optional Exclusions
• 6.7.1.2 Selection of XML Documents or Fragments
• 6.7.1.3 Selection of External Binary Data
• 6.7.1.4 Selection of Binary Data within XML
• 6.7.1.5 The dsig2:IncludedXPath Element
• 6.7.1.6 The dsig2:ExcludedXPath Element
• 6.7.1.7 The dsig2:ByteRange Element
• 6.8 The dsig2:Verification Element
• 6.8.1 The dsig2:DigestDataLength Element
• 6.8.2 The dsig2:PositionAssertion Element
• 6.8.3 The dsig2:IDAttributes Element
• 6.9 "Compatibility Mode" Transform Algorithms
• 6.9.1 Canonicalization
• 6.9.2 Base64
• 6.9.3 XPath Filtering
• 6.9.4 Signature Transform
• 6.9.5 XSLT Transform
• 7. XML Canonicalization and Syntax Constraint Considerations
• 7.1 XML 1.0 Syntax Constraints, and Canonicalization
• 7.2 DOM/SAX Processing and Canonicalization
• 7.3 Namespace Context and Portable Signatures
• 8. Security Considerations
• 8.1 Transforms
• 8.1.1 Only What is Signed is Secure
• 8.1.2 Only What is "Seen" Should be Signed
• 8.1.3 "See" What is Signed
• 8.2 Check the Security Model
• 8.3 Algorithms, Key Lengths, Certificates, Etc.
• 9. Schema
• 9.1 XSD Schema
• 10. Definitions
• A. References
• A.1 Normative references
• A.2 Informative references


The following remain the same and are duplicated in 1.1 and 2.0:

* Most of the general description, and  syntax sections
* The KeyInfo section
* Algorithms (apart from 2.0 additions and re-labelling items for compatibility mode)
* C14N and Security considerations
* Schema (apart from new schema additions)
* Definitions and References (apart from new references)

What has changed:
* Added (or will add)  examples for 2.0 mode
* Added new language for Reference processing of URIs, transforms, and how the two modes relate
* new Algorithm sections  for C14N and 2.0 transforms
* new references

Tradeoffs are

* One document might be easier to follow for those unfamiliar with 1.1; allows changes to 1.1 material
* Referencing 1.1 avoids possibility of inadvertent branching, simpler for those already familiar with 1.1
* Referencing 1.1 enables focus on 2.0 which might make for simpler and clearer document

We have also discussed for a long time the benefits of separating the Algorithms section from 1.1 and 2.0 so it can be maintained separately. Magnus noted concern on the list that doing so might slow reaching standardization. I won't deal with that here, since it is fairly simple to take that section out and make it a new document if we choose to do so.

If we were to separate 1.1 from 2.0 and reference the 1.1 draft, the following steps might be required:

1. Rewrite introduction to

* describe benefits of 2.0 mode, and how it requires a change to Reference syntax and processing but shares other aspects of 1.1 (including most syntax and processing)
* clarify compatibility mode and that 1.1 mechanism should work without new benefits
* Enumerate the material in 1.1 that is applicable but should be referenced from 1.1

2. Limit examples section to 2.0 examples, indicating compatibility examples are in the 1.1 document

3. Remove processing material for compatibility mode but keep general processing and 2.0 processing material.

4. Eliminate most of the material in the Syntax section, explicitly referencing 1.1 for everything apart from a discussion of use of Reference in 2.0, 2.0 canonical xml and transforms in 2.0

5.  Remove the additional signature syntax section

6. Remove all the algorithms section content apart from  the additions to the 1.1 algorithms document: 2.0 C14N, 2.0 mode transform algorithm, selection element, and Verification element,

7. remove "XML Canonicalization and Syntax Constraint Considerations<http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-20/#sec-XML-Canonicalization>"

8. Limit security considerations to new considerations specific to 2.0, rename to "2.0 security considerations" and clarify that these are in addition to 1.1 considerations.

9. Limit schema section to describing new and changed schema, clarify that intent in the text

10. Remove definitions section

11. Only provide references needed for 2.0 that are not in 1.1 document. Add reference to XML Signature 1.1


regards, Frederick

Frederick Hirsch
Nokia

[1] http://lists.w3.org/Archives/Public/public-xmlsec/2010Dec/att-0043/minutes-2010-12-07.html#item05

Received on Monday, 13 December 2010 22:19:52 UTC