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 Wednesday, 11 June 2003 10:20:36 UTC