Re: secure URIs

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:

meta:<METADATA>:<URI>

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):

meta:sha1=oHn3H7i+rYwEnZulnHb09KO/6Ro=:http://josefsson.org/key.txt

Thoughts?