[Servercert-wg] Subject name requirements for CA Certificates

[Ryan Sleevi]

On Tue, Oct 8, 2019 at 1:44 PM Jeremy Rowley <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/20191008/bdbe0c5c/attachment.html>