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

[Ian Grigg]

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 majordomo at metzdowd.com