<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<br>
<div class="moz-cite-prefix">On 2020-07-03 12:05 π.μ., Ryan Sleevi
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CACvaWvbDyLuxeMC4HkYxVTd9XfmFYGXdNqz69w8+hxD=yR9jcA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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" moz-do-not-send="true">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>
</blockquote>
<br>
Thank you for the very clear statement of intent about the
separation of hierarchies. From my perspective, I think it's the
first time that this is made so unambiguously clear as a
recommendation by Google Chrome and it would be great if there were
equally clear and unambiguous statements from other Browsers
operating "mixed EKU" programs. If there is agreement, we may be
able to find solutions for the ecosystem to reach this goal sooner
than later.<br>
<br>
I will start a separate thread about this and hopefully get some
clarify by all of our Browser Members. There are several challenges,
some of which were already discussed on GitHub
(<a class="moz-txt-link-freetext" href="https://github.com/cabforum/documents/issues/196">https://github.com/cabforum/documents/issues/196</a>) about the
clientAuth EKU, but the separate TLS hierarchy discussion should
take place separately from the SC31 ballot thread.<br>
<br>
<br>
</body>
</html>