<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 29, 2020 at 4:39 PM Florian Weimer <<a href="mailto:fw@deneb.enyo.de">fw@deneb.enyo.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">* Phillip Hallam-Baker:<br><br>
> That the EFF analysis was off should have been apparent from the fact that<br>
> a very large number about a third of the total of the intermediate certs<br>
> are all subordinate to one CA, the DFN root. The failure to check up with<br>
> DFN to find out what was going on smacks of agenda pushing and frankly a<br>
> willingness to fund raise off a lie<br>
><br>
> Had the researchers contacted DFN, they would have discovered that DFN is<br>
> the only party that acts as a CA, the only party that has the ability to<br>
> sign certs, no cert signing keys have been passed to other parties etc.<br>
> This was pointed out at the time and many times since.<br>
<br>
For some sub-CAs, the published policy said that DFN (or any other<br>
party) must not perform domain validation.  My understanding this is<br>
not how things were implemented after the DFN PKI joined the browser<br>
PKI.  We can debate whether it's preferable if a CA operators<br>
according to its policy and does not perform domain validation, or if<br>
validates and violates its policy.  And if they have different<br>
policies with different validation procedures, wouldn't they qualify<br>
as separate CAs?<br>
<br>
In any case, it's a bit disingenuous to criticize someone for not<br>
spending a week or two on unraveling the whole DFN PKI structure.  I<br>
agree that it was probably much simpler than the published policies<br>
suggested.  But then why publish these misleading policies?<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">That is not what I am criticizing them for. Anyone can get the analysis wrong.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The problem is the refusal to correct the mistake after it was made.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Oh! Oh! people shout. But Lets Encrypt is 'not for profit'.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Well so was the PIR registry behind .ORG, guess what happened to that. TrustE began as a not for profit as well.</div><div class="gmail_default" style="font-size:small"><br></div></div><div class="gmail_default" style="font-size:small"><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> Ideally, an intermediate issuer would be constrained using PKIX<br>
> constraints. Unfortunately, the PKIX specification and the Apple<br>
> implementation make that impossible as some idiot thought it a good idea to<br>
> require constraints be marked critical (i.e. use the break if the extension<br>
> is not understood feature) and Apple's browser didn't understand them at<br>
> the time.<br>
<br>
PKIX also refused to require that the constraint applied to the<br>
commonName field, making path constraints completely useless for the<br>
browser PKI.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">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.</div></div><div><br></div><div><div class="gmail_default" style="font-size:small">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.</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> One of the sad mistakes in PKIX was giving the criticality flag a<br>
> name that caused people to mistake it for meaning 'this is very very<br>
> important'. It means nothing of the sort it means 'break everything if this<br>
> is not understood'. And it should never be used unless failing to<br>
> understand an extension would cause an invalid cert to be considered valid.<br>
<br>
Eh, if your security policy depends on certificate constraints being<br>
applied by implementations, then you absolutely have to set the<br>
critical bit, no?<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Not if it is an additional control rather than a critical control.</div></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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'.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The requirement to set the critical bit sets up a deployment deadlock.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div></div></div>