[Servercert-wg] Ballot SC31 - Browser Alignment

[Ryan Sleevi]

On Thu, Jul 2, 2020 at 3:48 PM Dimitris Zacharopoulos (HARICA) <
dzacharo at harica.gr> wrote:

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

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.

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.

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.

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.


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

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

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.

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20200702/6568b71d/attachment.html>