W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

Re: Content-Integrity header

From: Phillip Hallam-Baker <hallam@gmail.com>
Date: Fri, 6 Jul 2012 18:12:59 -0400
Message-ID: <CAMm+LwjDVDJW9Pus+hOZTxeFdcBm=cnso_fbvoR-heTazs8L=Q@mail.gmail.com>
To: ietf-http-wg@w3.org
Someone pointed me to this in a private message:

This is a Proposed Standard and defines a Digest header that covers
the digest only functionality.

The digest header is not really suited to extension so that suggests
that a MAC only header such as Content-MAC or MAC would be more

On Fri, Jul 6, 2012 at 2:43 PM, Phillip Hallam-Baker <hallam@gmail.com> wrote:
> 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/

Website: http://hallambaker.com/
Received on Friday, 6 July 2012 22:13:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:02 UTC