[Servercert-wg] Subject name requirements for CA Certificates

[Rob Stradling]

To learn that SC16 was intended to be a "clarify" ballot, you have to read the "Purpose of Ballot".  Are all CAs (including CAs that are not members of CABForum, and including new CAs that don't even exist yet) expected/required to familiarize themselves with the intent behind each and every previous CABForum ballot before they attempt to interpret the BRs or EVGs?  If so, this surprises me.  I would have thought that the BRs and EVGs should stand on their own.

________________________________
From: Servercert-wg <servercert-wg-bounces at cabforum.org> on behalf of Ryan Sleevi via Servercert-wg <servercert-wg at cabforum.org>
Sent: 08 October 2019 19:29
To: Jeremy Rowley <jeremy.rowley at digicert.com>
Cc: CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Subject: Re: [Servercert-wg] Subject name requirements for CA Certificates


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.


On Tue, Oct 8, 2019 at 1:44 PM Jeremy Rowley <jeremy.rowley at digicert.com<mailto:jeremy.rowley at digicert.com>> wrote:

I guess I’m saying we fall into category #2? I don’t think the language reads as prohibiting other fields, nor does the ballot purpose.

I guess I set myself up for disappointment here :)

This is the classic split between "Everything not explicitly forbidden is permitted" and "Everything not explicitly permitted is forbidden".
- CAs are inclined to argue the former; it provides them the most flexibility, at the cost of the least predictability.
- Browsers are inclined to argue for the latter; what's the point of a certificate profile if it doesn't actually restrict the profile?

When the Ballot took care to reframe the language, and explicitly included a provision for allowing other fields, but only in limited cases, I don't think we can reasonably conclude "default allow" was intended in that ballot.

However, more generally, I don't think an argument that "default allow" should be the method of reading the Baseline Requirements, especially enumerated lists. The fact that this continues to be an issue of divergence is why I raised this: because we're seeing systemic, repeated misissuance through tortured interpretations like this. Rob Stradling raised the EVGs having a default-deny being indicative of a default-allow, but that ignores the fact that the Default-Deny was introduced in SC16, which did not /change/ the requirements but merely /clarified/ them, by explicitly emphasizing that it was, and always has been, a Default-Deny.

The problem with reading enumerated lists as Default-Allow is that it implies a degree of "lawlessness". For example, if we assume Default-Allow, then when we compare to 7.1.4.2.2.j, the logical conclusion is that unlike Subscriber certificates, the issuing CA does not need to verify any of the information in the CA certificates, except for the enumerated field, because there's no requirement like 7.1.4.2.2.j. I hope CAs would recognize how logically inconsistent such a conclusion would be, and that logical inconsistency is why reading with a Default-Allow is not good. Or, consider the BRs at the time of Ballot 199 - which, despite the numbering, was adopted prior to Ballot 190 (which didn't pass until September 2017). Section 3.2.2.4 had the cursed "any other method" of validation. In a Default-Allow world, why would such a statement be necessary? If it was omitted, then enumerated lists are permitted. Or look at the contemporaneous discussion around our Bylaws, with Ballot 180-et-al? The discussion there centered heavily on enumerated lists, and that if something was not enumerated, it was not permitted, thus creating the concerns for IP.

It's easy to offer favorable interpretations in isolation, even when they're not consistent.

However, I'm more concerned with the systemic issue at play here: which is Default-Deny versus Default-Allow. I'm concerned that none of the CAs issuing these certificates noticed the discrepancy and thought to raise it as an issue. Presumably, all thought it was permitted, even though such a conclusion was internally inconsistent with the BRs. That worries me for other conclusions that are internally inconsistent, and it worries me that SC16, which explicitly tried to clarify that it was not a change in the requirements, but a clarification of existing requirements (i.e. "What isn't listed is not permitted") did not prompt an evaluation of other such assumptions. Those systemic issues are worrying.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191009/5d72a129/attachment.html>