It’s just data
James Clark: Overall I think we can do much better than S/MIME by designing something specifically for HTTP.
James' third reason looks like a killer one to me. One minor caution: There are scenarios where it is convenient for servers to be able to stream responses, and most signing algorithms are designed to accommodate such requirements. This would tend to indicate that a design that tacks signatures on the end would be preferred. YMMV.
If HTTP trailers were not defined to be hop-by-hop, I would suggest that they would be perfect for this kind of thing. A trailer could easily contain a signature for the content.
Posted by James Snell atwell, and the content negototiation wrench is large and flying directly into your machinery. What’s signed in a gzip’ed response, and how does that work with caching?
Posted by dbt atThere would need to be a distinction made between a Content-Signature and a Transfer-Signature. The Content-Signature would be calculated on the base content, prior to application of the Transfer-Encoding. If Content-Encoding indicates gzip, then the Content-Signature would be calculated after compression
Posted by James Snell atIt might be possible to support signing and huge data transfer (>1TB) over HTTP without streaming... if you broke it up into chunks before signing, and calculated the Content-Length for each.
Sort of like a half-way point to the BitTorrent protocol, but without the requirement of a tracker. That could make new bit-torrent-ish protocols even easier to create...
I always liked streaming, but is it now time for an Accepts-Chunking HTTP header?
Posted by bex atI too agree with mr. Clark. I think he makes eight very strong points which shows that S/MIME doesn’t solve the problem and that we need something else for HTTP.
Posted by Asbjørn Ulsberg at