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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[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


Yes Dale, good summary.  We have already discussed this with the XMLDsig folks
and they informed us they identified this problem and decided to let the
applications deal with it!  Maybe something more can be done.

I don't see our list of transforms to be an exhaustive list.  If someone wanted
to add another transform in their implementation, I don't think that would break
our spec.  If the Dsig group fixes this problem, implementations could use the
new canonicalization method they define.

Rather than try to resolve this at this eleventh hour, I have inserted a warning
in the Multi-Hop section.

Regards,

David.


-----Original Message-----
From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com]
Sent: Saturday, January 05, 2002 8:48 AM
To: Rich Salz; Damodaran, Suresh; Cherian, Sanjay
Cc: ebxml-msg@lists.oasis-open.org
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>

----------------------------------------------------------------
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