RE: [ebxml-msg] Whitespace problem with XMLDSIG usage in ebMSS

[Dale Moberg <dmoberg@cyclonecommerce.com>]

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>