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