- From: Phillip Hallam-Baker <hallam@gmail.com>
- Date: Fri, 6 Jul 2012 18:12:59 -0400
- To: ietf-http-wg@w3.org
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 22:13:26 UTC