- From: Marc Hadley <Marc.Hadley@Sun.COM>
- Date: Wed, 14 May 2003 14:48:33 -0400
- To: Martin Gudgin <mgudgin@microsoft.com>
- Cc: xml-dist-app@w3.org
On Wednesday, May 14, 2003, at 11:10 US/Eastern, Martin Gudgin 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. >> > > It seems to me that, per xmldsig, the xmldsig:SignedInfo element would > contain the URI of the C14N algorithm used. This would indicate whether > chars or bytes were used as input to signature calculation. This would > give C and D (or anyone else) enough info to perform the correct > calculation. > That would be the case if the type of the elements is known (thus you can work out which element content to sign as bytes and which as chars. If type information is not available then how would you tell the difference between base64 data or text that looks like base64 data. I think an explicit mark would be more robust. Marc. -- Marc Hadley <marc.hadley@sun.com> Web Technologies and Standards, Sun Microsystems.
Received on Wednesday, 14 May 2003 14:49:56 UTC