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).
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]
crypto:ftp://ftp.acme.com/file.dat[content_md5=6bb2.83af.35c9.2ec4.9deb.4654.5f31.f175]
crypto:mailto:[EMAIL PROTECTED],pgp_url=http://www.acme.com/alice.asc]
The first example is like an httpsy URL. The second gives a file and its md5 hash. The third gives Alice's email address and PGP key. These "cryptoURLs" could be used wherever URLs are, not just on the web. For example, a signed XML document that uses cryptoURLs to reference external content would extend the signature over that content. A protocol like LDAP that returns a URL referral to another server could return a cryptoURL so the client can securely access that server.
We sorta started an I-D, but it's not very far along[2]...
Trevor
[1] http://lists.w3.org/Archives/Public/uri/2003Apr/0095.html
[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
--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
