[Cryptography] The EFF 650 CAs lie

[Phillip Hallam-Baker]

On Wed, Apr 29, 2020 at 4:39 PM Florian Weimer <fw at deneb.enyo.de> wrote:

> * Phillip Hallam-Baker:
>
> > 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?
>

That is not what I am criticizing them for. Anyone can get the analysis
wrong.

The problem is the refusal to correct the mistake after it was made.

It took me less than an hour to find out what was going on at DFN. I sent
them an email and they replied. I forwarded the response to the EFF.

EFF has known that the claims made about DFN were bogus all along. They
were told within days of publishing the original claim. They have repeated
the claim multiple times since without modification.


Oh yes and that business of me working for a 'for profit' CA. That has not
been true for well over a year. At this point it is now the EFF that is in
a position to profit greatly from the situation they helped create. Lets
Encrypt is probably worth in the region of half a billion dollars.

Oh! Oh! people shout. But Lets Encrypt is 'not for profit'.

Well so was the PIR registry behind .ORG, guess what happened to that.
TrustE began as a not for profit as well.




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

I knew the reason for that. We had a two day conference at NIST and finally
worked out why the spec was broken and unfixable. Can't remember the
details.

PKIX is a very old and complex spec. I spent 25 years wrestling new
features into it. And most of the time found it wasn't possible.



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

Not if it is an additional control rather than a critical control.

Setting the critical bit meant the certificates would be rejected by a
significant proportion of the installed base. So no CA was going to issue
certs with it set. Contrawise, Apple had no intention of implementing a
feature 'nobody used'.

The requirement to set the critical bit sets up a deployment deadlock.

The minute CAs start issuing certs with soft constraints, browsers that
didn't implement them have an immediate incentive to change because if they
accept a cert that should have been recognized as invalid, they are now at
fault for not implementing that feature.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20200430/23544eea/attachment.htm>