Re: PASWA, canonicalization, and signatures

I >think< there is a relatively obvious path to follow in the case of 
PASWA.  one that would be very much in the spirit of incremental evolution 
that's characterized SOAP itself.

In PASWA, the message is the Envelope infoset.  Any efforts to carry parts 
of the data in binary are merely optimizations and are not visible at the 
SOAP processing level.  The data we think of as attachments is at least 
conceptually present in the form of base64 character encodings.  As Rich 
has pointed out, there is some momentum toward using the already published 
exclusive canonicalization as the basis for WS-Security, a least in the 
short to medium term. 

We all agree that exclusive canonicalization will work with such an 
Infoset, and the only question is whether an alternative approach might 
leverage the efficient availability of a binary form to improve 
performance.  My suggest (speaking for the moment only for myself and not 
necessarily for my employer) is that we take the easy step first.  Let's 
start by relying on the standard exclusive canonicalization algorithm, 
applied to the character based infoset.  This builds largely on 
investments that will be made for other reasons anyway. 

If deployment experience shows that performance is indeed a problem, we 
always have the opportunity to consider later the possibility of a more 
elaborate c14n that would draw on the value space, at least for some 
elements.  Some of you may have noticed another thread I've started on the 
relationship between PASWA and the XQuery data model.  I haven't seen any 
specific requirements for doing signatures over instances of the XQuery 
model (I.e. signing the input and output of XML databases and queries), 
but it's not implausible that the need would eventually arise.  If so, I 
suspect that there might be synergy in considering together signatures 
over the XQuery model and optimizing PASWA signatures:  both involve 
combinations of value space and lexical space forms.

For now, speaking for myself, I think it makes sense to start by using the 
existing c14n recommendations in conjunction with the character form of 
the Infoset.  If individual implementations choose to optimize their 
computations of such signatures in the face of PASWA so be it, but such 
optimizations should not be visible externally.  The signature should be 
the same as that which would result from naively converting the value 
space to characters, and then signing that. 

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------







Marc Hadley <Marc.Hadley@Sun.COM>
Sent by: xml-dist-app-request@w3.org
06/11/03 10:20 AM

 
        To:     Rich Salz <rsalz@datapower.com>
        cc:     Tony Graham <Tony.Graham@Sun.COM>, "xml-dist-app@w3.org" 
<xml-dist-app@w3.org>, (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        Re: PASWA, canonicalization, and signatures



On Tuesday, Jun 10, 2003, at 14:05 US/Eastern, Rich Salz wrote:

>
>> 1. Who is expected to invent the c14n algorithm to be used when
>>    signing the "value space"?
>
> It's not clear that there needs to be one.  If it's binary data -- such
> as a JPEG or PDF -- then specify specify no transform.  If it's XML, 
> then
> (sigh) re-serialize the infoset according to one of the several c14n
> methods that are already out there.
>
In that case, the problem is identifying which chunks to process as XML 
and which as binary. Unless we prohibit intermediaries from inlining 
attachments then its possible that something that was signed as binary 
at the start of the message chain will be converted to base64 text 
somewhere along the message path. Without some clever C14N (and perhaps 
some indication in the infoset to trigger clever behaviour) its likely 
that such binary->infoset transform will break signatues.

If we want efficient signature processing then I think we either need a 
PASWA aware C14N or we need to prohibit intermediaries from messing 
with the message representation. The other answer is to do neither 
which means that sigs will need to be computed on the base64 encoded 
versions of attachments.

Marc.

>>    Note that the W3C XML Signature and XML Encryption activities
>>    closed in May 2003. [2]
>
> Irrelevent; since Transform/@Algorithm is a URI, anyone can develop
> a C14N spec.  UDDI has an XSD-based one, for example.
>
>>    SOAP message as binary content" and that it's only "inefficient
>>    implementations" that will add attachments as "base64 encoded
>>    content"?
>
> Or that that wish, e.g., to work over existing transports.
>         /r$
>
>
--
Marc Hadley <marc.hadley@sun.com>
Web Technologies and Standards, Sun Microsystems.

Received on Thursday, 12 June 2003 23:25:46 UTC