On 28/07/2010 15:18, Peter Gutmann wrote: > Ben Laurie <b...@links.org> writes: > >> However, using private keys to prove that you are (probably) dealing with >> the >> same entity as yesterday seems like a useful thing to do. And still needs >> revocation. > > It depends on what you mean by revocation, traditional revocation in the PKI > sense isn't needed because (well apart from the fact that it doesn't work, > you > can't un-say something after you've already said it) if you look at what a PK > or a cert is, it's just a capability, and the way to revoke (in the > capability > sense) a capability is to do something like rename the object that the > capability refers to or use a level of indirection and break the link when > you > want to revoke (in the capability sense) the access. This means that no > matter how many copies of the capability are floating around out there and > whether the relying party checks CRLs or not, they're not going to be able to > get in.
Now you are talking my language! Have I mentioned that my new project at Google is all about finding good UI for exposing capabilities to users? >> Is there a good replacement for pk for this purpose? > > Which purpose? If you mean securing the distribution channel for binaries, > here's a very simple one that doesn't need PK at all, it's called a > self-authenticating URL. To use it you go to your software site, and here's > a > real-world example that uses it, the Python Package Index, and click on a > download link, something like > http://pypi.python.org/packages/package.gz#md5=.... (yeah, I know, it uses > MD5...). This link can point anywhere, because the trusted source of the > link > includes a hash of the binary (and in this case it's a non-HTTPS source, you > can salt and pepper it as required, for exammple make it an HTTPS link and > use > key continuity to manage the cert). In this form the concept is called link > fingerprints, it was actually implemented for Firefox as a Google Summer of > Code project, but then removed again over concerns that if it was present > people might actually use it (!!). It's still available in DL managers like > DownThemAll. The problem here is that it doesn't directly give me an upgrade path. Of course, I agree that this is sufficient to give me a link to the "right" binary, but what about its successors? > Another option is to cryptographically bind the key to the URL, so you again > have a trusted link source for your download and the link is to > https://<base64>.downloadsite.com, where <base64> is a fingerprint of the > cert > you get when you connect to the site. This does away with the need for a CA, > because the link itself authenticates the cert that's used. Yes, this is of course the YURL scheme. > Then there are other variations, cryptographically generated addresses, ... > all sorts of things have been proposed. > > The killer, again, is the refusal of any browser vendor to adopt any of it. > In the case of FF someone actually wrote the code for them, and it was > rejected. Without support from browser vendors, it doesn't matter what cool > ideas people come up with, it's never going to get any better. > > Peter. > > -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com