A mighty fortress is our PKI, Part II

[Ben Laurie]

On 28/07/2010 15:18, Peter Gutmann wrote:
> 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.

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