Gervase Markham wrote: > On 09/04/11 18:05, Adam Barth wrote: > > In addition to thinking about orderly transitions to new > > certificates (as you mention), there's also the case of disorderly > > transitions. For example, what happens if the site's private key > > gets compromised and it wishes to move to a new certificate before > > it planned. > > This is why it seems to me that certificate attribute locking, as > opposed to particular certificate locking, has to be the way to go.
If you need to switch CAs immediately, then you had better have already purchased a backup EV cert, because it is unlikely that you will be able to get a new EV cert from a different CA in a reasonable time frame. In that case, you already know which CA you are using as a backup, so the website could lock its domain to both CAs' EV intermediate certs in advance. If you have merely a "EV lock," then you are still trusting every CA with an EV root, and you will still have the choice of getting the backup cert in advance or dealing with downtime or operating the website in a comprised state. > The aim of "locking" is to segment the trust landscape > so that a site can say "do not trust all X hundred CAs for my site, > trust only this one, or these two". They can then insulate themselves > from the possibility of a compromise elsewhere. > > Pinning a particular certificate seems to meet this goal only > imperfectly. I mostly agree. But, a website may want to trade this flexibility for a greater protection against misbehavior of the one or two CAs they have chosen to do business with. Such a mechanism shouldn't require a website administrator to trust *any* CA more than necessary. Cheers, Brian _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
