- From: Joseph Reagle <reagle@w3.org>
- Date: Thu, 20 Dec 2001 17:33:59 -0500
- To: "Cherian, Sanjay" <Sanjay_Cherian@stercomm.com>, "'w3c-ietf-xmldsig@w3.org'" <w3c-ietf-xmldsig@w3.org>
- Cc: "'galvin@eListX.com'" <galvin@eListX.com>, "'david@drummondgroup.com'" <david@drummondgroup.com>, "Damodaran, Suresh" <Suresh_Damodaran@stercomm.com>
On Thursday 20 December 2001 11:32, Cherian, Sanjay wrote: > This could likely be a problem that has been debated a lot in the past > but I would appreciate if someone explained > (or pointed to a previous explanation on the mailing list or elsewhere) > what the current thinking is regarding this. Hi Sanjay, The "meta" question of allowing transforms over SignedInfo certainly has been a topic of discussion in the past with some advocating for this functionality. However, the option we proceeded with was to avoid such complexity in the core xmldsig processing and to limit processing to a handful of well specified and vetted canonicalizations instead of arbitrary transforms. I expect proposals for infoset and schema augmented/typed canonicalizations to be made eventually. I've not considered handling white-space text nodes as you suggest, though I think it would be simple to specify and implement. (I wouldn't consider it "smarter", just different. And what is considered "trivial" to some is consider important to others. So I'd call it a alternative canonicalization that removes text nodes consisting solely of whitespace characters.) > Rather > than use the schema-unaware canonicalization > algorithm ( http://www.w3.org/TR/2001/REC-xml-c14n-20010315 ), it would > seem that a different canonicalization algorithm > could be written which, being aware of the XMLDSIG schema, could do a > better job of eliminating trivial whitespace. Note, I think the behaviour of schema "collapsing" (all whitespace replaced by a single '#x20' ) is different than that specified by xsl:strip-space (actually removes the text node). Also, schema collapsing applies to type string (and its derived types) and consequently (I don't think) would collapse the white-space between elements (or mixed content) -- unless I'm missing something else in schema that you are referring to. > In other words, a 'smarter' XMLDSIG schema-aware CanonicalizationMethod > algorithm could be published with the caveat that > changes in whitespace in descendants of ds:SignedInfo would become > irrelevant. In situations where this might be a problem, > the earlier schema-unaware canonicalization algorithm could be used > instead. Under what circumstances are you loosing the white space? Regardless, why not generate your XML and use xml:space="preserve" at the root? That's what it is for! <smile/> -- Joseph Reagle Jr. http://www.w3.org/People/Reagle/ W3C Policy Analyst mailto:reagle@w3.org IETF/W3C XML-Signature Co-Chair http://www.w3.org/Signature/ W3C XML Encryption Chair http://www.w3.org/Encryption/2001/
Received on Thursday, 20 December 2001 17:34:08 UTC