Radical proposal for Vnext of XML Signature

Henry S. Thompson
26 Sep 2007

1. Introduction

Using XML Canonicalization as the preprocessor for signature generation and verification has proved less than satisfactory. I think it's worth considering replacing C14N with something designed specifically for this role, with the benefit of hindsight wrt the problems that have been uncovered with the existing architecture.

2. What are we signing?

In order to play the role of guaranteeing the integrity of a document, what must be signed? I think the right way to address this is to look at infoset items and properties. Here's a suggested set of things which must be covered:

Document Information Item
children, base URI, all declarations processed, version
Element Information Item
namespace name, local name, children, attributes, base URI
Attribute Information Item
namespace name, local name, normalized value, attribute type
Processing Model Information Item
target, content, base URI
Character Information Item
character code
Comment Information Item

Note in particular that no information about namespace bindings is required/involved here -- no prefixes, no namespace attributes, no in-scope namespaces.

3. What should we really be signing

The previous section doesn't really answer the question -- we need a byte sequence to digest, not a tree of abstract information items and properties. You could imagine as trivial an answer as "Treat the infoitem/property story as a simple object model, and serialize per e.g. JSON". That might be too easy an answer for some, and in particular it would be horribly inefficient wrt namespace names.

The alternative I think would be worth exploring would be a variant of XMill. This would massively reduce the redundancy, as well as possibly improving the quality of the digest produced.

4. Can we stand to lose consistency of prefixes?

I think Ed Simon's attitude is correct here -- if fidelity of prefixes in content is an issue, type-aware processing would be required to convert e.g. QNames and XPaths in content into an expanded-name form.

5. Summary

I think a new XML Signature WG should include in its charter exploring the possibility of replacing C14N completely in the signature architecture.