W3C home > Mailing lists > Public > uri@w3.org > May 2003

Re: secure URIs

From: Simon Josefsson <jas@extundo.com>
Date: Sat, 03 May 2003 21:00:01 +0200
To: "Clive D.W. Feather" <clive@demon.net>
Cc: uri@w3.org
Message-ID: <ilusmrvdff2.fsf@latte.josefsson.org>

"Clive D.W. Feather" <clive@demon.net> writes:

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

I agree with you.

> 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?

The typical scenario for this is to wrap a URI, together with the hash
of the data the URI points at, and sign it.  Then a client receiving
this signed blob can retrieve the URI, verify the hash, and then be
sure that what she retrieved was what was intended.

This solution is used in some deployed systems.

>> 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.

It isn't.  It is only useful if the URI you received is signed data.

> 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?

In some cases size is the limiting factor.

You can transfer only a signed URI and a hash, and have the receiver
be able to download a 20GB file and be certain it is correct, without
forcing the 20GB file into the face of the client.  This makes sense
if you are sending many such signed URIs, and the client will
typically only select one of them.

E.g., sign the URI and hash of a realaudio, quicktime, mpeg3, etc
source, send it to a client, and she will be able to pick the one she
supports, download it and is able to verify its integrity.
Received on Saturday, 3 May 2003 15:00:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 13 January 2011 12:15:31 GMT