tag:blogger.com,1999:blog-3944976411672994427.post8187656743858025486..comments2009-01-10T15:51:29.635+07:00James Clarkhttp://www.blogger.com/profile/10624718204308567662jjc@public.jclark.comBlogger2125tag:blogger.com,1999:blog-3944976411672994427.post-11609174688327772572007-10-10T23:38:00.000+07:002007-10-10T23:38:00.000+07:00Excellent points. Regarding the Accept-Signature idea, by way of example, take a look at http://svn.apache.org/repos/asf/incubator/abdera/java/trunk/security/src/main/java/org/apache/abdera/security/util/servlet/, specifically the DHEncryptedResponseFilter.java class where we use an Accept-Encryption header to negotiate whether or not the response should be encrypted. A similar model for signatures would work well.James Snellhttp://www.snellspace.comnoreply@blogger.comtag:blogger.com,1999:blog-3944976411672994427.post-62325506978223723512007-10-10T20:10:00.000+07:002007-10-10T20:10:00.000+07:00Just as a counter example I've actually used S/MIME over HTTP in real-live production systems with success. Actually it was a multipart/encrypted which contained a message/http payload. Granted, we wrote the software which lives on both sides of the network (web server module, and browser plugin). Both the HTTP request and HTTP response were wrapped this way, so that messages in both directions were protected and could be authenticated.<BR/><BR/>By using the message/http payload we solved the problem of how to sign headers. In fact the outermost headers were very minimal; just enough to get the inner body routed to the decryption routines and control any proxies, caching, etc. The method, URL, Etag, etc. that were actually used came from inside the message/http.<BR/><BR/>You don't have to use PKCS methods either. We took advantage of already having a way to distribute secure secret keys so that we could use much lighter-weight algorithms like AES and HMAC/SHA without having to mess with the X.509 ugliness.<BR/><BR/>The main disadvantage we found were that some vendors of proxies or load balancing equipment don't correctly follow the HTTP specs and can stumble on multipart/encrypted payloads. Usually the bigger-named and more expensive "enterprise-level" devices were the worst offenders at misinterpreting the specs correctly.<BR/><BR/>And of course since nobody supports it now, you have to have you own software on each side. So I'm not sure S/MIME is the solution either, but it is certainly possible.Deron Merandahttp://deron.meranda.us/noreply@blogger.com