Content-Integrity header

HTTP 1.0 specifies a header Content-MD5.

This is a bad header for all sorts of reasons, not least that the
header was added despite the fact that I told people that MD5 had just
been severely compromised. In particular there is only one digest
algorithm specified and no way to use others.

A better approach would be:

Content-Integrity: <base64-value> ;alg=<ID>


For many Web Services, what we would like to do is to specify a MAC
rather than a digest and to use a preshared key identified by some
form of kerberos-like ticket. We don't need to specify the internal
structure of the ticket, just accept that we will have some sort of
key exchange service interaction at the end of which the client ends
up with a shared secret, an algorithm and an identifier that can be
passed to the service where the interaction takes place:

Content-Integrity: <base64-value> ;ticket=<ticket-data>

Note that the method of establishing that ticket in the first place is
out of scope for HTTP. Just think of it as something akin to a cookie.
There are many ways that structure can be established but those are
for the Web Service to manage, not something we should bind into HTTP.


This approach is of course very similar to the www-authenticate header
but with the major distinction that WWW-Authenticate is really about
key establishment and this is a mechanism to apply the result of a key
establishment to a content payload. But I guess if people think it
better to re-use WWW-Authenticate than to introduce a new header, I
can go with that.

The way we authenticate Web Services transactions today is of course
through either TLS or by embedding the authentication data into the
content through something like JSON Signature or XML Signature or via
something like WS-*. I don't particularly like these approaches as the
content authentication is really meta-data for the content and that
means it belongs in the HTTP header and not in the transport layer or
in the content itself. That is what the HTTP headers are there for,
making meta-data statements about the content.

We seem to have got into a position where Web Services means 'just run
over HTTP as if it was TCP/IP with firewall bypass'. I think we could
make Web Services a lot simpler by using HTTP for the purpose it was
intended and not duplicating that functionality in SOAP or whatever.


I have discussed this with David Crocker and his DOSETA scheme. I
think this is a case where if HTTP has the right socket, we can both
plug into it.

-- 
Website: http://hallambaker.com/

Received on Friday, 6 July 2012 18:44:06 UTC