W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > October to December 2001

Re: About whitespace in ds:SignedInfo

From: Joseph Reagle <reagle@w3.org>
Date: Thu, 20 Dec 2001 17:33:59 -0500
Message-Id: <200112202234.RAA23851@tux.w3.org>
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 

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:36 UTC