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

Re: secure URIs

From: Simon Josefsson <jas@extundo.com>
Date: Wed, 30 Apr 2003 00:59:44 +0200
To: Trevor Perrin <trevp@trevp.net>
Cc: "Roy T. Fielding" <fielding@apache.org>, uri@w3.org
Message-ID: <ilur87kq59b.fsf@latte.josefsson.org>

Trevor Perrin <trevp@trevp.net> writes:

> Roy T. Fielding wrote:
>>Additional metadata about the result of a GET request on a URI does
>>not belong in the URI itself, nor is there any reason to squeeze it
>>into that protocol element.
> I'm proposing a syntax that could attach general crypto metadata to
> URIs - 
> the interpretation of this metadata would depend on the scheme.  So
> this wouldn't be limited to just HTTP GET requests.  For example:
> ftp-://somesite.com/somefile.data[sha256=mY3Shx9...]
> ldap-://ldap.somedirectory.com/c=US[x509_sha1=hb6C4t...]
> mailto-:alice@acme.com[x509_sha1=vL2Nz7K...,x509_url=http://acme.com/keys/alice.cer]
> The crypto data in the first URI is the hash of the file.  The crypto
> data in the second URI is the fingerprint of an SSL server
> certificate.  The crypto data in the third URI is the fingerprint of
> an S/MIME certificate, and a URL where this certificate can be found.
> I would expect all or most crypto data to be one of these three types
> (hash of some document, fingerprint of some cert or key, or URL of
> some cert or key).

There are merits to the idea that security metadata should not be part
of URIs.  Here is one idea that implement the fundamental idea (which
I still believe is useful) without modifying URIs, like the above
approach does.

The syntax would be:


So to embed that a HTTP resource should have a certain SHA-1 hash (for
integrity, or even authentication, purposes) would be (this happens to
be a working example):


Received on Tuesday, 29 April 2003 18:59:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:05 UTC