[SSL Observatory] Number of CAs

[Benjamin T. Wilson]

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 questions at cabforum.org.  (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 <adi at hexapodia.org> 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