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