On Oct 31, 2011, at 3:53 AM, Mikko Rantalainen wrote: > 2011-10-27 14:29 EEST: Henri Sivonen: >> On Thu, Oct 20, 2011 at 9:57 PM, Martin Boßlet >> <[email protected]> wrote: >>> Are there plans in this direction? Would functionality like this have a >>> chance to be considered for the standard? >> >> The chances are extremely slim. >> >> XML signatures depend on XML canonicalization which is notoriously >> difficult to implement correctly and suffers from interop problems >> because unmatched sets of bugs in the canonicalization phase make >> signature verification fail. I think browser vendors would be >> reasonable if they resisted making XML signatures of canonicalization >> part of the platform. >> >> Moreover, most of the Web is HTML, so enthusiasm for XHTML-only >> features is likely very low these days. > > I agree. If a method for signature would be introduced, it should be on > HTTP-level instead. For example, the server (or client) could pass an > extra header (e.g. Content-Signature) where value would be the signature > of the content with some extra info about the key&algorithm used for > signature.
And, for the record, S/MIME already defines the application/pkcs7-signature MIME type for signed message-bodies (see RFC 5751 for the latest). Support for S/MIME response processing in browsers is thin-to-nonexistent, but business-to-business exchange of S/MIME signed bodies over HTTP has been around for many years. It at least has the benefit of not requiring canonicalization, since the signature algortithm is defined to run over the serialized bytes of the message. The main reason to push for signatures in the body of a message would be because there was desire to sign a sub-region of the document, or to support multiple or partially-trusted signers; the use cases for that are quite rarified at this point. -mh
