Hmm, there seems to be some confusion
about the role C14N (or any other XML canonicalization algorithm, but I’ll
just talk about C14N here) plays in XMLDSIG. Let me try to clarify.
C14N is an algorithm for converting a to-be-signed XML node-set into an
octet stream suitable for hashing. While it’s possible that the serialized
input to the XMLDSIG signing process might just happen to be serialized in C14N-equivalent
form, in general this is pretty unlikely and in any case irrelevant once you
start signing subsets of the input node-set (i.e. by using one or more <Transform>
elements to identify the to-be-signed node set). XML canonicalization is
well-defined for any XML node-set (and thus for any parse-able piece of XML
that, once parsed, turns into an XML node-set). So there isn’t any
issue of XML “complying” with C14N – if it’s XML then
it has a node-set representation, and that node-set (or a subset) can be turned
into an octet stream via C14N, and the resulting octet stream can be hashed to
generate a DigestValue.
--bal
From: Anthony Nadalin
[mailto:drsecure@us.ibm.com]
Sent: Saturday, May 07, 2005 3:55
PM
To: Brian LaMacchia
Cc: Frederick.Hirsch@nokia.com;
wss@lists.oasis-open.org
Subject: RE: [wss] SwA profile
Issue 364 action for TC members
Are you saying that all XML simply complies to C14N or
exc-C14N (character
encoding, white space normalization, etc) rules ?
Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
"Brian
LaMacchia" <bal@exchange.microsoft.com>
"Brian
LaMacchia" <bal@exchange.microsoft.com>
05/07/2005 03:44 PM
|
To
|
Anthony
Nadalin/Austin/IBM@IBMUS, <Frederick.Hirsch@nokia.com>
|
cc
|
<wss@lists.oasis-open.org>
|
Subject
|
RE: [wss] SwA
profile Issue 364 action for TC members
|
|
I don’t understand this comment, specifically what you mean
by “if you don’t know what is all there and if canonicalization
makes sense.” The entire extent of an XML attachment is clearly present
at signature generation time -- it has to be or you couldn’t compute the
hash value to put in the Reference to it. XML canonicalization is only defined
for XML content, of course, but presumably you know that already from the MIME
type of the attachment in question (text/xml).
When
would the attachment be sufficiently present for hash computation but not for
canonicalization?
--bal
From: Anthony Nadalin [mailto:drsecure@us.ibm.com]
Sent: Wednesday, May 04, 2005 5:06 PM
To: Frederick.Hirsch@nokia.com
Cc: wss@lists.oasis-open.org
Subject: Re: [wss] SwA profile Issue 364 action for TC members
How can
you canonicalize if you don't know what is all there and if canonicalization
makes sense ? I would say that we should just treat these as opaque.
Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
<Frederick.Hirsch@nokia.com>
<Frederick.Hirsch@nokia.com>
05/04/2005 03:59 PM
|
To
|
<wss@lists.oasis-open.org>
|
cc
|
|
Subject
|
[wss] SwA profile Issue 364 action for TC members
|
|
There is one major open issue for the SwA profile, which is whether XML
attachments require XML canonicalization. This is issue 364 [1]
TC members
(a) argued against requiring canonicalization [2], [3] and treating XML
attachments as opaque. The Committee Draft reflected the TC viewpoint [4].
(b) Brian submitted a comment at the end of public review arguing that
canonicalization should be considered [5]. Draft 16 incorporated proposed text
to follow this recommendation, requiring canonicalization (see section 3) [6]
(c) Members of the TC argued against this. Their logic is reflected in the
latest draft, draft 18. [7] These arguments were not recorded on the mail list,
so please make them on the list now.
Brian has provided additional rationale [8] and some of these members have
revised their viewpoint [9]
As editor I'd like the TC to decide on the correct action before I make any
additional change to the profile. Should I change to require XML
canonicalization? Should I use the text provided in draft 16 on this topic?
Please send a message to the WSS list indicating support for requiring XML
canonicalization or for leaving draft 18 as it is on this issue. Better yet,
propose specific changes to draft 18.
It would help move this document forward for the TC to be able to make a
decision on the next call, scheduled for 17 May. We also need to consider
whether this change would require additional interop and/or public review.
Thanks
regards, Frederick
Frederick Hirsch
Nokia
[1] http://www.oasis-open.org/apps/org/workgroup/wss/download.php/12467/OASIS%20Web%20Services%20Security%20Issues%20List%2065.htm
[2] http://www.oasis-open.org/apps/org/workgroup/wss/email/archives/200408/msg00072.html
[3] http://www.oasis-open.org/apps/org/workgroup/wss/email/archives/200407/msg00034.html
[4] http://www.oasis-open.org/apps/org/workgroup/wss/download.php/10902/wss-swa-profile-1.0-cd-01.pdf
[5] http://lists.oasis-open.org/archives/wss-comment/200502/msg00004.html (item #4)
and
http://lists.oasis-open.org/archives/wss-comment/200502/msg00006.html
[6] http://www.oasis-open.org/apps/org/workgroup/wss/download.php/11700/wss-swa-profile-1.0-draft-16-diff.pdf
[7] http://www.oasis-open.org/apps/org/workgroup/wss/download.php/12407/wss-swa-profile-1.0-draft-18-diff.pdf
[8] http://www.oasis-open.org/apps/org/workgroup/wss/email/archives/200504/msg00017.html
[9] http://www.oasis-open.org/apps/org/workgroup/wss/email/archives/200505/msg00001.html