Andy, I like your suggested risk-based approach to narrow the focus on risky CAs. I'm interested in hearing similar suggestions along those lines. Also, I mentioned the collective good sincerely--not out of self interest--the point being that a holistic view is needed and a recognition that even though we might act out of self-interest, we're trying to provide a valuable security service and everyone's interests and technologies need to be considered. Some apparently don't accept this explanation from the CA industry, and I will never be able to convince them otherwise. I'll use this email to respond to other recent comments. I think the proposed alternatives aren't fully baked, so I'm hesitant to embrace them. Again, they need to be capable of practical integration into current systems. I don't know what atrocities are alleged, so I can't respond. On a final point, I could propose something improves the incentives for a CA to protect relying parties. That's a good idea that would require a more lengthy discussion--so those interested in that area are welcome to send their suggestions to me and/or to [email protected]. (I'm not speaking on behalf of CA/B Forum.) Ben
Sent from my iPhone On Dec 7, 2011, at 5:37 PM, Andy Isaacson <[email protected]> wrote: > On Wed, Dec 07, 2011 at 04:47:29PM -0700, Ben Wilson wrote: >> Thanks, Peter. This dialogue is healthy. My point and the point that you >> and others have made is that whatever that number is we need to take it and >> boil it down to something manageable. If you cast your net in a way to >> identify a group of 650 (odds are there will be under-inclusion and >> over-inclusion), then we should take that sample and apply some additional >> criteria to the group. What problem are we trying to solve? > > I'm trying to find out how many distinct security policies and HSMs need > to be audited for a user, using the default trust root in browsers, to have > confidence that false certificates have not been issued. > > To do that, first we (the entire SSL community) will need to enumerate > the private keys that have a valid certificate chain to the trust root. > The thousand-plus CA certificates discovered by the EFF SSL Observatory > are a strict subset of that set of private keys. > > Once we have enumerated the set of private keys (note that I'm not > assuming a single entity will have knowledge of the entire set!), we > need to enumerate where they are stored. Hopefully they are all in HSMs > with undisturbed audit logs and can be shown to not have exposed key > material outside of their audited systems. > > I'd advocate that CAs take a proactive audit stance towards this private > key material. I believe that CAs should at the very least, provide > browser vendors with an independently audited census of all private keys > chained from their in-browser certificates. The audit should have a > publicly disclosed summary containing population counts for categories > like "keys maintained in HSM at CA", "keys maintained in HSM at customer > premises", "audit logs maintained by CA", "audit logs maintained by > customer", et cetera. > > Keys which are discovered to be potentially compromised in the process > of this audit MUST be publicly disclosed and blacklisted. I would claim > that this must include keys which were protected during their validity > period but which lost integrity after certificate expiration. > > To manage the CA pushback from the bad publicity potential in this area, > perhaps an independent or community group (CA-B-F, EFF, IETF, Mozilla) > could manage a blacklist of such exposed keys without necessarily > disclosing what CA signed the certificate. > > > I'm sure there is more information that the Relying Community would > benefit from. > > > What would we learn from this collection of audited censuses? > - how many HSMs are critical to the security of my SSL certs? > - how many audit-log-creating organizations? > >> forces are driving CA proliferation without quality control, then someone >> needs to identify what standards should exist and identify the bad apples >> based on some objective criteria. (From a positive perspective, what >> security measures can be implemented that will provide the greatest benefit >> and least collective harm?) > > Note that when a CA says "minimize collective harm", it sounds to us > Relying Parties like "avoid any damage to CA bottom line or business > model no matter the potential cost to other parties". I have very > little sympathy for the existing CA business model and I think the > record is clear that CA secrecy and intransigence has done great harm to > practical Internet security. Hopefully the better CAs such as yourself > can distinguish yourselves from some of your less savory competitors by > helping this process along. > > Thanks for contributing to the conversation > -andy
