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

Re: secure URIs

From: Trevor Perrin <trevp@trevp.net>
Date: Tue, 29 Apr 2003 15:38:21 -0700
To: "Roy T. Fielding" <fielding@apache.org>
Cc: uri@w3.org
Message-id: <5.2.0.9.0.20030429141119.02fbbc20@pop.comcast.net>


Hi Roy,

Let me presents some arguments in favor of squeezing crypto metadata into 
URIs.  I'm not sure they're compelling, but just to explore this a bit 
further..


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


>The same can and often is accomplished
>by way of related attributes (such as an additional attribute on the
>link) or by third-party link verifiers (such as the signature files
>often distributed separately from software packages, that provide
>the signature for that package).

Yup.  But I'll claim there's advantages to treating crypto data as part of 
the URI:

Most protocols that transport URIs (HTML, XML protocols, the address line 
of the browser) don't associate any crypto data with them.  Adding an 
additional element for this to every such protocol is infeasible.  If the 
crypto data could be stuffed in the URI, then these protocols could 
transport crypto data without even knowing it, as long as the party who 
eventually resolves the URI can handle the crypto data (at minimum "handle" 
would just mean "discard", so it would be easy to upgrade URI-handling code 
to treat a secure URI like a normal URI).

Also, URIs are often transported across different protocols (you 
copy-and-paste a URL from an email to your browser, or from one XML 
document to another, or an XML document is transformed into a different 
format, and so on).  If each protocol had its own way of calculating and 
storing crypto data, then there would have to be a translation at every 
such interface to turn one type of crypto data into another.  It would be 
much preferable to standardize the notion of "URI-associated crypto data" 
at the URI level, so everyone using URIs deals with crypto data 
consistently, and so the crypto data is bound into the URI and travels 
wherever it goes, instead of needing to be explicitly juggled and passed 
around separately.


Trevor
Received on Tuesday, 29 April 2003 18:39:05 GMT

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