Re: secure URIs

[For some reason this didn't go to the list. Trevor, do you want to post
your reply to it, or do you want me to do so?]

Trevor Perrin said:
>> Bitter experience says that it's always better to make the scheme as wide
>> and extensible as possible. In particular, "why would you want that?" is
>> almost a guaranteed recipe for later regrets.
> 
> If "secure" is restricted to crypto metadata, you could always define other 
> schemes for different metadata types:
> 
> language:http://whatever.com:french

You could, but why bother? That's gross special-casing when there's a much
more general approach.

> But I can't think of a type of metadata (besides crypto) where this would 
> be a good idea.

But should your imagination (or mine, for that matter) be the limit on what
can be done?

Actually, here's an example: to provide alternative versions of documents
according to the age of the user:

    http://images.films.com
    meta:http://images.films.com:rating=u
    meta:http://images.films.com:rating=pg
    meta:http://images.films.com:rating=15
    meta:http://images.films.com:rating=18

[I'd use something like the ICRA system in reality, but you get the idea.]

> I guess I perceive crypto data as not really "metadata" 
> about the resource, but rather part of the resource's identity.  If you 
> want to reliably retrieve a document, than knowing how to cryptographically 
> authenticate the document (or document owner) is just as important as 
> knowing its URL (at least in a sufficiently paranoid threat model).
> 
> In other words, this isn't just metadata to be used after resolving the 
> URL, but is integral to the process of resolving it, and I can't think of 
> other data that's similarly deserving of being bound to the URL.

Version number?

In fact, now that I think about it I'm having trouble understanding how
putting a hash in the URL helps with anything. What's your threat model?
Any change to the document happens either at the source or in transit. The
latter is handled by https. The former is much more likely to be deliberate
- that is, the author finds a mistake and wants to correct it. Now what
happens to the hash?

> I think that every secure URL would provide authentication of some sort (of 
> the document itself, in the form of a hash value, or of the party serving 
> the document, in the form of a key fingerprint).

A key fingerprint for the server is perhaps a useful thing, much more than
a hash of the document. But doesn't https give you that via another path
already? I'm not convinced that putting the key into every URL is the right
approach.

Both hashes and key fingerprints, however, merely move the problem one step
back - how do you know the URL contains the right hash/key? However you
solve that problem, why not apply it directly to the content?

-- 
Clive D.W. Feather  | Work:  <clive@demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive@davros.org>  | *** NOTE CHANGE ***
Demon Internet      | WWW: http://www.davros.org | Fax:    +44 870 051 9937
Thus plc            |                            | Mobile: +44 7973 377646

Received on Friday, 2 May 2003 06:01:09 UTC