Re: [http-auth] First draft of HTTP Signatures published

[Phillip Hallam-Baker <[e-mail]>]

HTTP Session Continuation is a separate spec but I would like to share as
much as possible between them.

http://www.ietf.org/id/draft-hallambaker-httpsession-01.txt

Early versions of the session continuation mechanism included header
signing. That is a real headache. The only way that I think it can be made
to work reliably is to duplicate the information that you want to sign into
the signing header which is the approach in DKIM.

For HTTP transactions, the only headers that I think should ever be signed
are content meta-data. The reason signing is hard in SMTP and HTTP is that
there is a huge confusion between headers used for routing and headers that
are properly part of the content. This is perhaps a change that could be
made in HTTP/2.

You will find a lot of objections being made of the form 'this will break
when intermediaries change content'. And they will continue to be made no
matter how many times you point out that detecting changes to the content
and rejecting that transaction is the whole objective. So there will need
to be some statement to the effect that the intended behavior is to prevent
all types of content modification.

We don't yet know what the effect of intermediaries is on the request line
and I suspect that as we get into tests we are going to discover that we
have to do some form of canonicalization. For example, I strongly suspect
that we are going to want to combine the Host-Name header and http method
into the request line to make it a canonical url.