[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ebxml-msg] Whitespace problem with XMLDSIG usage in ebMSS
I am just catching up on this discussion, and it might have been resolved in some message I have not yet gotten to, but... here is what I thought the major contentions were: 1. Intermediaries may for unknown reasons decide to do some format change that invalidate the signature, using any of the existing w3c defined transforms. 2. Also even when excisable-by-xpath elements are added by intermediaries, there are format changes possible that may fail to provide suitable canonicalization by any existing w3c transform. (suitable canonicalization means to allow signature validity to be preserved under the identified changes.) My question is whether Sanjay and others take this whitespace problem to be resolvable by defining a new canonicalizing transform? If so, should we submit this issue somehow or other to the XMLDsig group/activity in W3C and have them see if they are interested in developed a transform suitable for whitespace under the reformatting changes you have identified? I guess in general I see ebXML messaging as a consumer of security protocols, weaving them into an approach suitable for business requirements. So I do not see this as within our scope/charter to actually fix this, except perhaps by presenting it to w3c for consideration. Maybe SBC can let Sanjay join the w3c committee to represent us! Dale Moberg -----Original Message----- From: Rich Salz [mailto:rsalz@zolera.com] Sent: Wednesday, December 19, 2001 1:15 PM To: David Fischer Cc: Cherian, Sanjay; ebxml-msg@lists.oasis-open.org; Damodaran, Suresh Subject: Re: [ebxml-msg] Whitespace problem with XMLDSIG usage in ebMSS Impressive analysis Sanjay. I disagree with one part: >The solution to this latter problem is to require MSHs to apply the XSL >transform to ds:SignedInfo elements BEFORE signing and BEFORE verifying > (that is, before the XMLDSIG implementation gets the envelope). This is often not possible. In many DSIG toolkits, the ds:SignedInfo is generated by the signing code, and the application has no capability to generate or modify it. I think the only practical thing is to include a warning that intermediate MSH's must treat at least ds:Signature elements as if the xml:space="preserve" attribute is set. /r$ -- Zolera Systems, Your Key to Online Integrity Securing Web services: XML, SOAP, Dig-sig, Encryption http://www.zolera.com ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC