OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [wss] SwA profile Issue 364 action for TC members


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
Inactive hide details for "Brian LaMacchia" <bal@exchange.microsoft.com>"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
Inactive hide details for <Frederick.Hirsch@nokia.com><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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]