- From: HAYASHI, Tatsuya <lef.mutualauth@gmail.com>
- Date: Tue, 10 Jul 2012 04:08:48 +0900
- To: ietf-http-wg@w3.org
- Cc: Phillip Hallam-Baker <hallam@gmail.com>, James M Snell <jasnell@gmail.com>
+1 I know that this is demanded. When I discussion about http-authentication and phishing, it is requested by many people. It is a difficult problem. ex) proxy... I think that it is good to do this discussion now. --- Tatsuya On Sat, Jul 7, 2012 at 8:23 AM, James M Snell <jasnell@gmail.com> wrote: > 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/ >> > -- HAYASHI, Tatsuya Lepidum Co. Ltd.
Received on Monday, 9 July 2012 19:09:16 UTC