W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > July to September 2000

Re: Proposed processing model for Reference and Transforms

From: Joseph M. Reagle Jr. <reagle@w3.org>
Date: Tue, 22 Aug 2000 18:06:08 -0400
Message-Id: <>
To: "John Boyer" <jboyer@PureEdge.com>
Cc: "XML DSig" <w3c-ietf-xmldsig@w3.org>, <jboyer@csr.csc.UVic.CA>
At 13:25 8/22/2000 -0700, John Boyer wrote:
 >Attached is a copy of the latest editors' copy of the XML DSig
specification, except that I have added and deleted the text necessary to
implement the new Reference/Transform processing model discussed in the most
recent teleconference.  


 >The sections of HTML surrounded by <u></u> and <strike></strike>

Other readers might find this useful to see your additions: (css is
1. s/john="john"/class="john"/
2.  u.john {color:green;}

 >4) Rewrote text of all Transforms such that they indicate whether they
input and output an octet stream or a node-set.  Rewrote text surrounding
DigestMethod so that it is clear that if the input is not an octet stream,
then the node-set gets canonicalized.

Meaning that we are not requiring an explicit C14N? (It's implied?)
Regarding Don's comments from the call, do we need a "parse me" transform
that explicitly represents the conversion of octects to node-sets prior to
xml processing, or will this be implicit to the subsequent XML transform?

>8) I now distinguish between Canonical XML and Canonical XML with Comments.
 This was really quite necessary to get everything to work and keep all of
the features we used to have.  Canonical XML with Comments is recommended,
not required.  As well, it seemed like it wouldn't hurt anything because
Minimal canonicalization would be quite difficult if comments had to be

I'm not sure about this (or calling it 'parameterization'). If someone wants
to include comments, they have the option, but I don't think it needs to be
spoken of in the Signature spec even, just makes things seem more complex.

 >9) The C14N Draft needs to be changed. Rather than taking an octet stream
representing the document plus taking an optional XPath expression to filter
the document, it will now take an octet stream or node-set as input, along
with an optional flag that tells whether or not comments should be omitted
from the output.  For the octet stream case (which is the one everyone's
really focused on right now), the stream will be converted to a node-set AS
CURRENTLY DEFINED as long as the comment flag is FALSE.  The identifier (URL
for C14N)#WithComments will be created within the C14N document.
Again, I fear this comment issue will cause confusion, and people will
wonder whether to include them. If an application wants to keep them, it can
simply specify its own XPath, but providing this option will just re-invite
people to discuss the nature of comments because they will worry which they
should use.

Joseph Reagle Jr.   
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/People/Reagle/
Received on Tuesday, 22 August 2000 18:11:13 UTC

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