On XMLDSIG Canonicalization
Donald E. Eastlake 3rd
9 November 1999, 46th IETF Meeting
We're Talking About SignedInfo
- Other data that is signed and which happens to be XML may, depending on the application,
be treatable as binary or text
- SignedInfo is inside Signature and will usually be parsed and processed as XML
- For general interoperability, signatures must work when that parsing and processing is
done with DOM or SAX
The Signing/Verification Process
- Signer generates message/document including a Signature element.
- Verifier consumes message/document and attempts to verify Signature.
- Assume that for general interoperatiblity, verifier reads XML according to XML 1.0
specifciation and processes it using DOM or SAX.
- (Special applications that do not care about general interoperability can do whatever
- XML 1.0 specification requires certain modifications in the XML data read, some DTD
- Line ending normalization - DTD indepenent.
- Attribute value normalization - DTD dependent.
DOM / SAX Processing
- DOM is a standard. It yields a tree in memory.
- SAX yields a sequence of events corresponding to XML input.
- Both generally destroy attribute ordering, insignificant white space, insignificant
namespace aspects, ...
- Verification of a signature based on DOM/SAX requires serialization to a byte stream of
the DOM tree or the SAX event stream.
- The core verifier must be given EXACTLY the same byte stream as was signed despite
effects of XML reading and DOM/SAX processing. This implies availability of
- Syntax constraints to avoid damage during parsing
- pre-normalized attribute values, line endings, etc.
- Standard serialization, i.e., a canonicalization algorithm
- alphabetize attributes, etc.
- see W3C canonicalization drafts
Current XMLDSIG Status
- Absence of CanonicalizationMethod: implies no canonicalization
- Absence of Algorithm attribute: not specified
- Otherwise: any canonicalization algorithm can be specified
- Mandatory to implement: Minimal
- Recommended to implement: W3C XML