On Sun, 1 Aug 2010 15:07:46 +0200 Guus Sliepen <g...@sliepen.org> wrote: > On Sun, Aug 01, 2010 at 11:20:51PM +1200, Peter Gutmann wrote: > > > >But, if you query an online database, how do you authenticate > > >its answer? If you use a key for that or SSL certificate, I see > > >a chicken-and-egg problem. > > > > What's your threat model? > > My threat model is practice. > > I assume Perry assumed that you have some pre-established trust > relationship with the online database. However, I do not see myself > having much of those. Yes, my browser comes preloaded with a set of > root certificates, but Verisign is as much a third party to me as > any SSL protected website I want to visit.
Security is not magic. If you have no pre-existing trust relationship with some source of information, you cannot get additional trusted information from that source. You have to have some sort of existing pre-shared information -- a public or private key and a decision to believe the information from that source -- to get anywhere. > Anyway, suppose we do all trust Verisign. Then everybody needs its > public key on their computers to safely communicate with it. How is > this public key distributed? Just like those preloaded root certs > in the browser? What if their key gets compromised? How do we > revoke that key and get a new one? I think the "we all trust Verisign" model is a bad one (no particular slam on Verisign here, I think any "we all trust some third party" model is bad.) However, you are asking an important question, which is, how do we replace compromised keys in our configuration files? This depends a lot on the application. If we're talking about a single administrative domain (say a few thousand machines inside a company that are all managed by the same small group), you push out a new config file. If we're talking about, say, a banking application where lots of people have the bank's key in the config for their software, the protocol either has a way of rolling over to the "next key" or you are forced to send all the users new smartcards or USB keys or what have you, which is a good incentive to have a means in your protocol for moving to the next key. As for the case of "everyone on earth trusts third party X", except for something like the DNS, I see no reason or benefit in such a system at all. > We still have all the same problems with the public key of our root > of trust as we have with long-lived certificates. Perry says we > should do online checks in such a case. So which online database can > tell us if Verisign's public key is still good? Do we need multiple > trusted online databases who can vouch for each other, and hope not > all of them fail simultaneously? No. I think you're not focusing on real applications here. You're instead thinking far too abstractly. Say, for example, we're talking about some credit card processor's public key that is used by all their validation terminals. Presumably they need some sort of update protocol. However, that protocol does not need to involve certificates and is not a matter of global concern. There should be very few cases where a key is a matter of global concern -- I think having keys be a matter of global concern is something of an architectural error. > Another issue with online verification is the increase in traffic. > Would Verisign like it if they get queried for a significant > fraction of all the SSL connections that are made by all users in > the world? I think the "Verisign is the standard of all truth" model is broken, but lets consider what you're saying for a minute. If Verisign is indeed the "standard of truth", then how could we do anything else? If we don't check a key with Verisign at least every few hours, then how can we ever have meaningful revocation? Whether you think that Verisign wouldn't "like" this or not, there is no other choice given the model you are presenting. Either revocation is impossible or people make online checks. Perry -- Perry E. Metzger pe...@piermont.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com