On Wed, Sep 14, 2011 at 9:15 AM, Daniel Kahn Gillmor <[email protected]>wrote:
> On 09/13/2011 05:55 PM, Chris Palmer wrote: > > On Tue, Sep 13, 2011 at 5:45 AM, Daniel Kahn Gillmor > > <[email protected]> wrote: > > > >> From my perspective, i see no advantage to pinning any of the CAs -- if > >> your EE is compromised, you're sunk. And since the mechanism provides a > >> mechanism (and nice instructions, thanks) for transition to an emergency > >> offline backup EE key+cert, that is all handled well. > > > > In the case of normal EE certificate expiration — as opposed to > > compromise — if you are pinned to (say) an intermediary signer, you > > can just get a fresh certificate from the same signer, deploy it, and > > change nothing else. > > > > Conversely, if you had pinned to an EE, you'd need to follow a > > procedure something like this near expiration time: > > > > 0. Generate the new cert. > > 1. Change your pins directive to include the new and the old public > > key fingerprints. > > 2. Wait long enough for "most, surely?" of your users to have received > > the new pins, or for their pins to expire by the normal maxAge means. > > 3. Decommission the old EE cert and deploy the new. > > Actually, if your certificate policy requires key rotation at > certificate expiry, you can generate key N+1 at any time (preferably > early in the life of the cert corresponding to key N), and introduce the > secondary pin at that point, without having gotten certificate N+1 yet. > Yep. > It still looks to me like pinning a CA does nothing more than give them > the chance to hold you hostage at certificate renewal time, and to > expose you to vulnerability should the CA itself be compromised. It gives you scaling and administrative convenience. If you have 10,000 hosts in your enterprise network you really do not want to have to be managing trust on a per host level. Now consider the case where you are renting your compute power in the cloud and so the machine instances are existing for a few hours at a time. Any scheme that insists on only tying to the EE cert or key is going to create a major operational headache for those sites. It is really easy to design a scheme that is easy to administer. It is also going to cause huge amounts of state that the client has to manage. If you have 10,000 front end web servers you are going to need 10,000 different client keys to do the job right. So what most of the large enterprises would likely do if they introduced any form of security policy would be to have a private CA run up that is an intermediate in a larger hierarchy. This is why the bogus EFF study came up with the absurd number of 600 CAs. What they have never come clean on is the fact that 150 of those 'CAs' are in fact merely intermediate roots tied to a single customer that are managed in the same infrastructure as the root CA operations. What pinning to a CA does raise is the absolute need to have the ability to pin more than one CA at a time. > Again, that's fine and one size does not fit all. > > Sure, one size does not fit all, but it looks like the document is > (reasonably) trying to outline some common patterns of reasonable > behavior to encourage best practices. I still don't see any best > practice that involves pinning to a CA unless that CA is itself under > the control of your own organization. > > I recommend that the draft make this explicit, to avoid encouraging > system operators binding themselves even more tightly to a CA by > misapplication of this mechanism. > There is certainly a difference in the risk factor here between pinning in the browser and CAA as currently specd (i.e. without the client enforcement capability). [I originally wrote big, but thinking it through, maybe not so much] CA issue of certs is never a 100% automated process. There are some cases where automated issue is possible but there are inevitably exceptions. CAA does not prevent a CA issuing a cert, it merely triggers an exception. So the CA that received the failed application is going to circle back to the customer and ask what is up. If the CAA record was inserted maliciously or without informed consent then the customer is going to be mighty peeved with their old CA and likely contact slashdot with a nasty story. If there is client enforcement of the records then there is a potential to use them maliciously. But even so, I can't see this being much of a practical concern. The main value add CAs bring in practice is teaching people how to configure crypto and install certs properly without making a mess of it. Every customer call center I have been in the conversations you hear are salespeople walking a customer through install for Apache or ISS. So provided there is an escape hole from the pinning mechanism, the CAs are going to be more than capable of talking the customer through how to untie themselves from the attempted customer capture. -- Website: http://hallambaker.com/
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
