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. The first observation is that it is more general than Tyler's approach, 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. (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. 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. Alternatively, use a wrapper convention such as: crypto:<https://www.acme.com>[x509_sha1=4ca4.b169.587f.7258.9f6b.f9ee.bd6e.d7cd.cd6a.d551] which would have more defined properties, and also be more aligned with crypto practice in general. > We sorta started an I-D, but it's not very far along[2]... > [2] (this is not a real Internet-Draft, despite boilerplate): > http://trevp.net/cryptoURL/draft-ietf-cryptoURL-01.html > http://trevp.net/cryptoURL/draft-ietf-cryptoURL-01.txt A great start! Turning to Zooko's recommendation: > > Tyler should probably reference SFS on his HTTPSY pages. Here's a good paper > focussed specifically on this issue. > > http://citeseer.nj.nec.com/mazieres99separating.html > ... > It is an excellent idea. FTR, here is an example I cribed from the paper (click on the top right of the above referenced page to get the actual paper): /sfs/sfs.lcs.mit.edu:vefvsv5wd4hz9isc3rb2x648ish742hy/pub/links/sfscvs >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. Looking at Adam Back's post on "eternal resource locators": > I'm not that familiar with SFS, but httpsy sounds quite related to > Anderson, Matyas and Peticolas' "eternal resource locator" [1], and > the WAX system they describe in that paper. This scheme allows a > referer to embody in a URL they refer to authentciation information > about the contents of the text in the body of the page referred to > (either by SHA1 document hash, or by reference to a signing key the > publisher of the referred page may use to sign and update that page's > contents). (WAX was also implemented in browsers if I remember from > earlier reading of that paper). Cribbing again from the paper: <A HREF="http://www.med.abc.ac.uk/examresults"; HASH-METHOD="TIGER" HASH-VALUE="987654321..." HASH-PARENT="http://www.cert.med.ac.uk";> here </A> which indicates an HTML only approach (the page pointed to also includes a duplication of the tiger hash value). Again, I suspect an approach that expanded the use of URIs in a compatible fashion would have more merit than the above, albeit an approach that is more structured. > [1] "The eternal resource locator: an alternative means of > establishing trust on the World Wide Web", Ross Anderson, Vaclav > Matyas, Fabien Petitcolas, 3rd USENIX workshop on electronic commerce > Augst 1998 > > http://www.cl.cam.ac.uk/~fapp2/papers/ec98-erl.pdf -- iang --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
