<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jul 2, 2020 at 3:48 PM Dimitris Zacharopoulos (HARICA) <<a href="mailto:dzacharo@harica.gr">dzacharo@harica.gr</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
As we have discussed several times in the past, mixed hierarchies
are already in existence. Apple and Mozilla uses Roots for both
id-kp-emailProtection and id-kp-serverAuth. Microsoft uses Roots for
id-kp-codeSigning too. If there is a goal to separate these
hierarchies per EKU, then let's all agree on such a goal and proceed
accordingly. <br></div></blockquote><div><br></div><div>We've repeatedly made such statements, from SHA-1 on. We've seen, for example, ASC X9 start up for a PKI. We've seen browsers share their feedback, half a year ago, regarding separate PKIs for eIDAS Qualified Website Authentication Certificates.</div><div><br></div><div>I agree on the substance that a given manufacturer may enable for multiple EKUs right now. But I mentioned this distinction to highlight the "other users"; for example, the countless CAs that use the same hierarchy for issuing clientAuth certs to smart cards as they do for publicly trusted certificates. You need only read Microsoft's Root Store Updates to see them fairly aggressively phasing those trust-bits off CAs, or transitioning to split hierarchies.</div><div><br></div><div>This is why it's ludicrously irresponsible to suggest a CA going out of business as somehow being a result of the Browser imposing rules. The browser is their customer. If they're not providing a service that's useful to that customer, of course that customer will go elsewhere. It's not at all the customer's fault for not frequenting that store, especially if it provided nothing of value, no different than a factory that's known for making shoddy products with lead paint and selling counterfeit versions on the side quickly finds that they don't have many customers left. That's not the customer's fault.</div><div><br></div><div>All of this is to emphasize: The notion of a "Root" for browsers should really be viewed through the lens of "Managed CA for a particular Browser vendor". It may be that you can use the same CA to provide the service to multiple vendors. Doug certainly knows Google's view and recommendations, which is that our interest is very explicitly in a "TLS only" hierarchy. A CA like GlobalSign can, and we can see through the notifications to browser vendors, is working to accomplish this, because the same root they use for other Programs may not be acceptable to Google for much longer.</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"><div><blockquote type="cite"><div dir="ltr"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>HARICA supports the ballot including the 398-day limit,
but I fully understand and respect the position of other
CAs which "in principle" don't support this to be included
in the BRs. In practice, Browsers shouldn't need this to
be included in the BRs or rely on audits. </div>
</blockquote>
<div><br>
</div>
<div>This sort of "absolute" language is entirely dismissive,
and highlights the failing comity of the Forum. I can
understand if you don't understand the reasons, but to state
it as an absolute is to dismiss the countless good-faith
efforts made over the past 5 years to explain these
concerns.</div>
<div><br>
</div>
<div>I also fail to see how it *isn't* still understood,
especially as we look at approximately 270-290 misissued
intermediate certificates needing revocation within the next
7 days. Any pain caused by that is a direct consequence of
those intermediates being used for longer than needed, which
is directly proportional to the sum of certificates they
have issued and the maximum lifetimes of those certificates.</div>
<div><br>
</div>
<div>Put differently: If certificates were only valid for 7
days, then the full and prompt replacement of every one of
those intermediates posing security risk would be completed,
on time, and without any issues. Every day longer that a
certificate is valid for only serves to increase the impact
of that revocation, thus incentivizing the CA to fail to
meet their contractual obligations, and thus worsening or
exacerbating the security impact to browsers and end users.
This should be trivial to scratch out on paper and see how
it works out.</div>
</div>
</div>
</blockquote>
<br>
For the 270-290 Intermediates, some of them chain to a Root with
such a common hierarchy (for TLS, emailProtection, codeSigning,
timeStamping, docSigning, etc) and the end-entity certificates
cannot last for 7 days (consider for example EV Code Signing
Certificates where the keys must be generated in FIPS devices). Your
request to revoke such non-TLS Issuing CAs is because they "touch"
the common Root (which is capable for TLS), thus becoming in Scope
of the Baseline Requirements. Issuing 7-day Certificates for these
non-TLS Certificates wouldn't solve this problem.<br></div></blockquote><div><br></div><div>"Yes and". That is, you've demonstrated why the problem requires multiple approaches, which we're clearly proceeding with. Look at the requirements from both Microsoft and Mozilla within SC31 that clearly prohibit multi-use intermediates, as the first step towards tamping down on this problem. Yet even independent of the specific example I referenced, we can see the value of lifetime is still there: it covers if *anything* goes wrong, by setting a upper-bound on pain.</div><div><br></div><div>However, you've also helped highlight precisely why CT alone isn't sufficient. If the intermediate is not capable of TLS, but has an id-kp-OCSPSigning EKU, there's no guarantee it can be logged to CT. This is especially true as CT logs move to restrict disclosures to *only* TLS certificates, to better scale and protect privacy for non-TLS certificates. We only know about these certificates incidentally.</div><div><br></div><div>And this similarly matches the "non-browser use of TLS", which may not be logged to CT at all, because by design and intention, CT is not a policy that is "imposed" on 100% of a CA's issuance, even for TLS. If a CA is issuing 1y certs from an intermediate for browsers, they could still be issuing 2y TLS certs for non-browsers from that same intermediate. Yet when it comes time to revoke that intermediate, even looking at CT and seeing "all TLS certs are expired", the CA may argue they can't revoke, because of their "non-browser" use cases. This isn't hypothetical: we see CAs regularly doing this, requesting OneCRL/CRLSet because actually adhering to the BRs would be too costly for them. As such, it makes the provisions of 4.9.1.2 a joke - they aren't requirements, or even guidelines, more like suggestions really. And that rot infests everything else, because now the BRs are subject to "how costly it would be for the CA to actually do", despite their assurances to browsers that they will do. It enables the race to the bottom that we've been ardently fighting against.</div><div><br></div><div>So yes, the audit matters, and CT alone isn't sufficient. And this is true for every requirement: we have to check and verify, robustly. Yes that involves CT, but that also requires independent assurance, and that such assurance is meaningfully robust (e.g. detailed control), and not simply checklists.</div><div><br></div></div></div>