[Cryptography] The EFF 650 CAs lie

[Florian Weimer]

* Phillip Hallam-Baker:

> Years ago, the EFF set up its infamous Certificate Observatory, looked at
> the network of public intermediate certificates that had been issued,
> called each intermediate a 'CA' and issued what has become the zombie lie
> of 650 CAs.
>
> It was not a deliberate lie at the time it was said but it has become a lie
> since with the obstinate refusal to correct the record. I am going to be
> taping a module on PKI for my course on cryptography and it would be much
> better for all concerned if I could say the EFF has finally retracted this
> claim.
>
> I have no idea who I could contact at EFF who could get this fixed but the
> lie continues to be repeated and it is high time it was retracted.
>
> As was explained at the time and on numerous occasions since, a CA is a
> body that has control of at least one Certificate signing key. The vast
> majority of the '650 CA's identified in the study control no signing keys.
> They are simply customers of a CA whose certificates are issued off a
> separate intermediate root.

I think the situation is much more complicated.  On the one end, the
number of distinct organizations having access to private key material
was likely lower than 650.  We don't really know because at the time,
there was a number of unconstrained, unaudited sub-CAs in operation.
This was long before certificate transparency, so a corporate MiTM
proxy with a valid sub-CA certificate and on-the-fly server
certificate generation could easily fly under the radar.

But for purposes of the browser PKI, we have seen that the RA part of
the CA business was equally important.  And the number of trusted RAs
was much larger than 650.  Lack of disclosure requirements for RAs
naturally made estimates difficult.  The public learned about these
trusted RAs (essentially resellers which could instruct the CA to
issue certificates based on fairly arbitrary CSRs) usually only after
some RA did something very wrong.

It's also funny that it's so hard to identify root CAs in the browser
PKI.  For organizations in the business of identifying others, they
put remarkable little effort into properly identifying themselves.  If
I recall correctly, for a long time, there was just Kathleen Wilson's
Google spreadsheet for that.

> That the EFF analysis was off should have been apparent from the fact that
> a very large number about a third of the total of the intermediate certs
> are all subordinate to one CA, the DFN root. The failure to check up with
> DFN to find out what was going on smacks of agenda pushing and frankly a
> willingness to fund raise off a lie
>
> Had the researchers contacted DFN, they would have discovered that DFN is
> the only party that acts as a CA, the only party that has the ability to
> sign certs, no cert signing keys have been passed to other parties etc.
> This was pointed out at the time and many times since.

For some sub-CAs, the published policy said that DFN (or any other
party) must not perform domain validation.  My understanding this is
not how things were implemented after the DFN PKI joined the browser
PKI.  We can debate whether it's preferable if a CA operators
according to its policy and does not perform domain validation, or if
validates and violates its policy.  And if they have different
policies with different validation procedures, wouldn't they qualify
as separate CAs?

In any case, it's a bit disingenuous to criticize someone for not
spending a week or two on unraveling the whole DFN PKI structure.  I
agree that it was probably much simpler than the published policies
suggested.  But then why publish these misleading policies?

> Ideally, an intermediate issuer would be constrained using PKIX
> constraints. Unfortunately, the PKIX specification and the Apple
> implementation make that impossible as some idiot thought it a good idea to
> require constraints be marked critical (i.e. use the break if the extension
> is not understood feature) and Apple's browser didn't understand them at
> the time.

PKIX also refused to require that the constraint applied to the
commonName field, making path constraints completely useless for the
browser PKI.

> One of the sad mistakes in PKIX was giving the criticality flag a
> name that caused people to mistake it for meaning 'this is very very
> important'. It means nothing of the sort it means 'break everything if this
> is not understood'. And it should never be used unless failing to
> understand an extension would cause an invalid cert to be considered valid.

Eh, if your security policy depends on certificate constraints being
applied by implementations, then you absolutely have to set the
critical bit, no?

> The article is still on the EFF site. It is high time it was retracted.

I think it's valuable because it draws attention to the phenomenon of
vanity CAs.  That is still