A mighty fortress is our PKI, Part II

Peter Gutmann pgut001 at cs.auckland.ac.nz
Wed Jul 28 10:18:19 EDT 2010


Ben Laurie <ben at 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.

>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.

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.

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.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list