[Servercert-wg] Ballot SC31 - Browser Alignment

[Dimitris Zacharopoulos (HARICA)]

On 2020-07-03 12:05 π.μ., Ryan Sleevi wrote:
>
>
> On Thu, Jul 2, 2020 at 3:48 PM Dimitris Zacharopoulos (HARICA) 
> <dzacharo at harica.gr <mailto: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.
>

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.

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 
(https://github.com/cabforum/documents/issues/196) about the clientAuth 
EKU, but the separate TLS hierarchy discussion should take place 
separately from the SC31 ballot thread.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20200703/030d8b4b/attachment-0001.html>