HTTP Response Signing Abstract Model

I've argued that there's a need for an HTTP-specific mechanism for
signing HTTP responses. So let's try and design one. Usually at this
point, I would start coding, but with security-related stuff, I think
it's better to have more discussion up front... Let's suppose that the
mechanism will take the form of a new Signature header. Here is my
current thinking as to the steps involved in constructing a Signature
header: [eleven steps in the abstract design]... (1) What kinds of
security token can be used? At least X.509 certificates should be
supported. But there should be the potential to support other kinds
of token. (2) How are security tokens identified? It depends on the
type. For X.509, it would make sense to have a URI that allowed the
client to fetch the certificate. It would also be desirable to have
an identifier that uniquely identifies the certificate, so that the
client can tell whether it already has the certificate without having
to go fetch it. As far as I can tell, in the X.509 case, people mostly
use the SHA-1 hash of the DER encoding of the certificate for this.
(3) How does the server know what kind of signature (if any) the
client wants? The client can provide a Want-Signature header in the
request... (4) Can there be multiple signatures? Yes. In the normal
HTTP style, the Signature header should support a comma-separated
list of signatures. The order of this list would be significant.
There should be a way for each signature in the list to specify which
of the previous signatures in the list are included in what it signs.
There's a semantic difference between two independent signatures, and
a later signature endorsing an earlier signature... (5) How about
streaming? Tricky. The fundamental problem is that HTTP 1.1 isn't
very good at enabling the interleaved delivery of data and metadata... More Information See also the followup: Click Here