[SSL Observatory] Number of CAs

[Patrick Patterson]

Hello Andy:

On 2011-12-07, at 7:37 PM, Andy Isaacson 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.
> 

Ok - what is your definition of "false certificates" - is it certificates that you feel were not issued correctly? Is it certificates that the CA admits to being issued in violation of it's policies? The two are not the same. 

> 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.
> 

One does not need to "expose key material" for "illegitimate" certificates to be issued. All that is required is for some human to not fulfill their role correctly, and this often results in the CA's keys being used quite correctly (i.e. the CA software responding to a request from someone it considers legitimate), but the end result may be that a certificate was issued contrary to policy.

And when you say "HSM" - do you mean a smartcard, or a module that if you look at it wrong, it wipes the keys - depending on your attack surface and your opponent, there are times when even the latter is not sufficient. Also, what standard would you like the HSM to follow to ensure protection of the private key? I know of at least one HSM manufacturer (which is rated to EAL4+) that "backs up" the private key by exporting it to a PKCS#12 (albeit with a very long passphrase). Would you consider that acceptable? 

And what about an offline key that was not in an HSM, but was only accessible under guard, by 2 or more people, inside of a highly secure facility? Making a blanket statement of "must be in an HSM" misses the point - how about "kept so that it is only accessible under a known set of conditions, by a known set of actors". 

> 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.
> 

I know of CAs that would be able to provide such details, but where you could still find certificates that were issued on the whim of some administrator (it is 100% within the policy of that CA to allow this). Focussing once again on the integrity of the keys sort of misses the point of the PKI. It's the entire infrastructure that you need to look at (including the people), and not just the technology. We tend to say to clients that PKI is 90% people and process, 5% technology, and 5% crypto - without the 90%, you have some very nice technology and crypto, but you don't have very much security.

> 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.
> 

Again - what do you mean by "compromised" - do you mean "got out of their HSM", or "may have signed a certificate or three that was requested by a rogue Registration Authority". Should you revoke the entire CA for that, or should you just revoke those certificates and punish the Registration Authority?

Not to mention that, in the case of the Malaysian government cert that was used to sign some malware, it was the USER/Subscriber who didn't report their key stolen, and so the CA had no way of putting it on the blacklist / CRL. How do you propose to solve the "Users are the weakest part of the security chain" problem (which is NOT PKI specific).

> 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.
> 

How, pray tell, could you do that? A certificate contains the Issuer. So unless you have this body only publish a list of hashes of certs, then you would certainly be exposing who signed the certs.

> 
> I'm sure there is more information that the Relying Community would
> benefit from.
> 


We're not a CA, so we don't have an iron in this fire, but I would like to see a constructive dialog on how to educate organisations (at the user level, it's probably a lost cause) to perform their own trust audits, and take an active participation in who they and their users trust. Simply educating folks that PKI isn't about HSMs or keys, and is about binding identities and operationing according to a policy is probably a start. Once that sinks in, then people will start thinking of checking the audits of organisations, and only trusting them if they both agree with their policy (Hey, a CA can have a policy that says that it sells certs only to "the bad guys" and as long as that's what it does, it'll pass the audit :), and a valid audit from some accredited firm.

Now, the audit regime, and what it means to be accredited is a topic for yet another day :)

Have fun.

---
Patrick Patterson
Chief PKI Architect
Carillon Information Security Inc.
http://www.carillon.ca