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 [EMAIL PROTECTED]
