W3C home > Mailing lists > Public > xml-dist-app@w3.org > May 2003

Re: PASWA, Include and Protocol Bindings

From: Marc Hadley <Marc.Hadley@Sun.COM>
Date: Thu, 08 May 2003 14:20:06 -0400
To: Mark Nottingham <mark.nottingham@bea.com>
Cc: Martin Gudgin <mgudgin@microsoft.com>, noah_mendelsohn@us.ibm.com, xml-dist-app@w3.org
Message-id: <B1BB977A-8181-11D7-9596-0003937568DC@sun.com>

On Thursday, May 8, 2003, at 13:53 US/Eastern, Mark Nottingham wrote:
>
>> 2) If A wants to incorporate message security including the 
>> attachments
>> then it has a couple of obvious options:
>>
>> - Generate signatures based on the base64 encoded version of the data
>> (requires base64 encoding step)
>> - Use an attachment/xninc:Include aware C14N algorithm that allows
>> signing of the raw attachment octets (base64 encoding not required).
>>
>> If A uses the latter case, how do C or D determine which instances of
>> base64 encoded data to decode prior to signature verification ? This 
>> is
>> related to the problem described in 1) above.
>>
>> If A uses the former case then D better be careful about which parts 
>> of
>> the message it turns into attachments otherwise it could make
>> additional work for E base64 encoding attachments prior to signature
>> verification.
>
> An alternative is to use a signature algorithm that (perhaps 
> selectively)
> operates on the value space of the content, rather than the lexical 
> space.

That's what I meant by "an attachment/xbinc:Include aware C14N 
algorithm". Unless I'm mistaken I think your alternative is the second 
case I described.

> This sidesteps the problem by making the attachment mechanism 
> transparent,
> as intended.
>
How does it sidestep the problem? Please explain.

Marc.

--
Marc Hadley <marc.hadley@sun.com>
Web Technologies and Standards, Sun Microsystems.
Received on Thursday, 8 May 2003 14:22:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:14 GMT