- From: James M Snell <jasnell@gmail.com>
- Date: Fri, 6 Jul 2012 16:23:32 -0700
- To: Phillip Hallam-Baker <hallam@gmail.com>
- Cc: ietf-http-wg@w3.org
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