3 more good ideas: cryptoURLs, SFS, eternal resource locator/WAX

[Trevor Perrin]

At 11:53 AM 7/16/2003 -0400, Ian Grigg wrote:
>Content-Transfer-Encoding: 7bit
>
>Below follows a paragraph on each idea to distribute
>key hashes within existing web practice, with examples.
>
>Trevor Perrin wrote:
>
> > A similar idea was discussed on the W3C's URI list[1].  Simon Josefsson had
> > the clever idea of a URI scheme that binds an underlying URI to some
> > "crypto data" such as document hashes, key fingerprints, and key URLs:
> >
> > crypto:<underlying_URI>[<crypto_data>]
> >
> > 
> crypto:https://www.acme.com[x509_sha1=4ca4.b169.587f.7258.9f6b.f9ee.bd6e.d7cd.cd6a.d551]
>
>
>This is really good stuff.

Thanks!

>   The first observation
>is that it is more general than Tyler's approach,

Yeah, but also more complicated.

>in that it explicitly incorporates URIs and also
>the existing CA-cert regime.  In this way it will
>actually add to the current situation, rather than
>require the dismantling or ignoring of the CA-cert.

As Tyler pointed out, YURLs contain the hash of the CA's key, so they're 
similar in this respect.


>(Much as I think the CA-cert is 'mostly harmless'
>as far as security goes, there is little point in
>trying to remove it.  It really needs to be
>incorporated into any and all plans to add security
>to the browsing experience.)
>
>One observation immediatly springs to mind is that
>the above URLs simply don't work with existing
>conventions.  That is, when I click on them in my
>(admittedly not security conscious) email agent,
>the result fails.

That would be a great property, but I couldn't find a way to achieve it 
(see below).


>To rectify this, one could reverse the location of
>the hash:
>
> 
>crypto:[x509_sha1=4ca4.b169.587f.7258.9f6b.f9ee.bd6e.d7cd.cd6a.d551]:https://www.acme.com
>
>and similar with the mailto.

Do those work with your email client?  However you order it I'd expect 
clients to choke, so it seems more a question of readability.


>Alternatively, use a wrapper convention such as:
>
> 
>crypto:<https://www.acme.com>[x509_sha1=4ca4.b169.587f.7258.9f6b.f9ee.bd6e.d7cd.cd6a.d551]
>

Maybe.  Angle brackets are disallowed in RFC 2396; so are square brackets 
but RFC 2396bis currently admits them.. but yeah, these are the kind of 
miniscule but crucial details I'm not sure we've gotten right yet.

[...]

> >From what I can see across all these ideas, I'd
>suggest that if a URI form can be constructed
>that is compatible with existing URIs then this
>will have deployment advantages over the above.

That's a tough problem.  Tyler repurposes userinfo:

https://*<keyid>@<host>...

but that won't work well with ftp or telnet URLs that actually use 
userinfo.  And you're not supposed to have userinfo in http or https URLs, 
clients might choke on that.  You could try stuffing crypto data into the 
path or the query component:

http://<host>/path1/path2/<keyid>/
http://<host>?<keyid>

Then a naive client would pass it to the server and the server could ignore 
it, and an upgraded client would strip it off and not send it.  You'd have 
to upgrade servers to handle naive clients throwing crypto junk at 
them.  Still pretty ugly..

With a single "crypto" scheme, at least it would be easy to upgrade clients 
to recognize "crypto", discard the crypto data, and then process the URL 
normally.

Even in the best case, it would be years before you could expect most 
people to have browsers that did that.  But once that threshold was 
crossed, you could use "secure URLs" without inconveniencing people.

Trevor 


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com