W3C home > Mailing lists > Public > public-xmlsec@w3.org > September 2008

ISSUE-51 (scantor): Effects of schema normalization on signature verification [Rqmts (XML Signature and Canonicalization V Next Requirements)]

From: XML Security Working Group Issue Tracker <sysbot+tracker@w3.org>
Date: Tue, 2 Sep 2008 14:40:45 +0000 (GMT)
To: public-xmlsec@w3.org
Message-Id: <20080902144045.C194BBF4F@nelson.w3.org>

ISSUE-51 (scantor): Effects of schema normalization on signature verification [Rqmts (XML Signature and Canonicalization V Next Requirements)]

http://www.w3.org/2008/xmlsec/track/issues/51

Raised by: Scott Cantor
On product: Rqmts (XML Signature and Canonicalization V Next Requirements)

Part of schema validation typically involves enforcing data type "correctness" for element content when elements are declared with a simple type. The rules for this check involve the use of the "schema normalized value", which allows things like whitespace to be modified in order to produce a value suitable to check for type correctness.

At least one reference in the XML Schema 1.1 specification is here:
http://www.w3.org/TR/xmlschema-1/#e-schema_normalized_value

The XSD data type documentation describes the rules for canonicalizing lexical values to produce the "schema normalized value". For example, leading and trailing whitespace is often removed.

These DOM changes are usually destructive to signature verification. Implementations have worked around this problem by simply ignoring normalization, allowing it to be selectively disabled, or even storing both the original and the normalized values in the DOM.

The most "correct" way of dealing with this is via an XML Signature Transform that forces the signer and verifier to apply these normalization rules consistently. IBM proposed such a transform several years ago, but it hasn't seen much uptake, partly because achema validation in general has mostly seen limited use in signature applications because of these problems.
Received on Tuesday, 2 September 2008 14:42:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:43:54 GMT