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