Re: Content-Integrity header

In general, I'm +1 on the general idea albeit with a few caveats...

1. To minimize complexity, only a single Content-Integrity header
should be used. I don't want, as Roy points out, to have to iterated
through a bunch of unsupported header values looking for the one I
want. Just as it makes very little sense for an implementor to provide
multiple Last-Modified, Etag and Content-Type headers in a single
message; there should be only a single Content-Integrity statement and
I either understand it or I don't.

2. The performance impact of calculating the digest needs to be
carefully considered. I'd rather not be required to buffer a full
representation in memory all the time just to calculate a header
value. I know it's largely unavoidable, but perhaps there's some
currently elusive solution that can be considered. For instance..
allowing Content-Integrity to appear as a trailer at the end of a
chunked response.

3. Something needs to be said about what happens if the
Content-Integrity check fails. For instance, if a request containing
Content-Integrity is sent to the server and the server detects that
the signature is invalid, what should happen? what must happen?
Likewise, how are intermediaries expected to treat the
Content-Integrity header given that any intermediary is able to modify
the payload at any time?

- James

On Fri, Jul 6, 2012 at 3:12 PM, Phillip Hallam-Baker <hallam@gmail.com> wrote:
> Someone pointed me to this in a private message:
> http://tools.ietf.org/html/rfc3230#section-4.3.2
>
> 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
> appropriate.
>
>
>
> 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 23:24:20 UTC