Re: Origin vs Authority; use of HTTPS (draft-nottingham-site-meta-01)

On 2/11/09 12:38 PM, "Adam Barth" <w3c@adambarth.com> wrote:

> On Wed, Feb 11, 2009 at 11:55 AM, Eran Hammer-Lahav <eran@hueniverse.com>
> wrote:
>> There is nothing incorrect about: GET mailto:joe@example.com HTTP/1.1
>
> I don't know how to get a Web browser to generate such a request, so I
> am unable to assess its security implications.

It really does not matter what a browser will do with such URI. This example
is not really of interest to a browser because that would imply that the
mailto URI has some visual representation the user wants to see. No such
representation exists today for the user to ask for and the brower to show.

But an application with full access to the HTTP protocol can use it to
obtain some representation of the URI that will mean something to it.

>> It might look funny to most people but it is perfectly valid. The protocol
>> is HTTP, the scheme is mailto. HTTP can talk about any URI, not just http
>> URIs. Since this is about *how* /host-meta is obtained, it should talk about
>> protocol, not scheme.
>
> Here's my understanding of how this should work (ignoring redirects
> for the moment).  Please correct me if my understanding is incorrect
> or incomplete:
>
> 1) The user agent retrieves the host-meta file by requesting a certain
> URL from the network layer.
>
> 2) The network layer does some magic involving protocols and
> electrical signals on wires and returns a sequence of bytes.
>
> 3) The user agent now must compute a scope for the retrieved host-meta file.
>
> I recommend that the scope for the host-meta file be determined from
> the URL irrespective of whatever magic goes on in step 2. because this
> is the way all other security scopes are computed in Web browsers.
> For example, if I view an HTML document location at
> http://example.com/index.html, its security origin is (http,
> example.com, 80) regardless of whether the HTML document was actually
> retrieved by carrier pigeon or SMTP.

You got this backwards. You decide what the scope is, you get the document
for that scope, you use it.

1. You want to find out more about example.com on port 80 speaking HTTP.
2. You want to find out more about http://example.com/resource/1 (and care
about the HTTP representation).

In both cases, you will do:

GET /host-meta HTTP/1.1
Host: example.com:80

While this document can be identified with http://example.com/host-meta,
that URI alone is not enough to declare its scope. The fact you used HTTP to
obtain a representation of this URI is also needed. Again, protocol and
scheme are not the same thing.

Now, how do you know that what you got is authorized/trusted/unspoofed/etc?
You don't based on what the host-meta spec is offering. If you need that,
specify it in your application. If a bunch of people agree on how to add
security to this, we can address it separately.

Your argument is that without such security, this whole thing is useless. We
obviously disagree.

EHL

Received on Wednesday, 11 February 2009 22:45:09 UTC