[SSL Observatory] Number of CAs

[Andy Isaacson]

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