[Servercert-wg] Subject name requirements for CA Certificates

[Ryan Sleevi]

On Wed, Oct 9, 2019 at 8:34 AM Rob Stradling <rob at sectigo.com> wrote:

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

I think you're highlighting exactly my point about why this is a systemic
issue. The underlying issue here, between this and organizationIdentifier,
is that some CAs view the Baseline Requirements as a "Everything not on
this list is permitted", which is entirely internally inconsistent with how
the BRs are written and historically inconsistent with the purpose of the
BRs.

We've seen other parties, interested in the PKI, correctly read the BRs and
EVGs as a list of "If it's not explicitly permitted, it's forbidden". I say
this because I don't believe it's that the underlying Guidelines are bad,
but if one approaches with a wrong mindset, they can lead to bad results.

I'm raising this in the Forum because this is fundamental to the
trustworthiness of CAs. If CAs view it as Default-Allow, a position that is
not internally nor historically consistent with the BRs or their purpose,
you end up with issues like this. The amount of badness is inumerable. This
particular issue is useful, because admittedly, it's low on the scale of
things to get overly excited about, but perfect to demonstrate the systemic
flaw in the reasoning and approach some use when reading the BRs.

This has been a systemic issue from some time; I'm sure some members here
recall when a former member of the Forum tried to argue that it was
perfectly acceptable to issue MITM certificates from publicly trusted
roots, because the BRs didn't explicitly forbid them, even though the BRs
required the CA validate the domain name. The CA, at that time, argued that
because they validated the network operator controlled DNS, the network
operator controlled all the domain names, ergo, MITM by a network operator
was perfectly fine. That approach, and conclusion, shakes faith in CAs to
the core, so we should try to prevent issues before they become that level.

Viewing things as implicitly permitted is an approach to security that
doesn't work. This is why blocklists don't work as security boundaries -
badness evolves and adapts to the thing that is blocked. It's why policies
start with Default-Deny, and then enumerate the goodness; it provides a
defensible security boundary and a common understanding about what can
happen. Yes, sometimes those things that are permitted are overly broad,
and badness seeps in, but as we saw with the exercises of 3.2.2.4, we work
to better specify (and more explicitly specify) what's permitted, to get
the desired result.

My point about raising SC16 is that we already went through this
exercise on whether it's permitted or denied. Multiple browsers shared
their view, that what isn't permitted is denied, which is why SC16 was
merely a clarification of existing root store policy, meant to remove
ambiguity that was not itself internally consistent with the guidelines,
but which some CAs nevertheless argued. It was perhaps less controversial,
save for the few CAs eager for PSD2 certificates, if only because it was
not a wide-spread case of misissuance. It's something where others
approaching the Guidelines recognized that it wasn't permitted, which is
why we went through the exercise of SC17, to permit it in the interim.

To Dimitris' point that he doesn't believe so many CAs violated the
requirements, I don't think the number is any indicator. We saw plenty of
CAs violating the iPAddress requirement, or the dNSName requirements, many
members of this Forum, even though those were long-standing requirements of
either the Baseline Requirements or RFC 5280. Mistakes happen, most
commonly when things change and CAs don't realize it. The same underlying
issue - things change, but practices not changing - is something root
stores struggle with still, even with ample communication; see
https://groups.google.com/d/msg/mozilla.dev.security.policy/3iuG8KGryC4/JMt2djuiBQAJ

No matter how explicit we make things, though, we need to make sure we have
a consistent reading: Do the BRs explicitly list everything that is
permitted, and anything not on this list forbidden? Or are they merely a
list of requirements for some things, with everything else being whatever
the CA wants? I'm firmly of the view that if there is a question about
permitted or not, the CA should assume the answer is "no" at first, and
then examine both the BRs and the relevant technical standards to see if
there is an argument that it is or should be. That analysis helps minimize
mistakes, because it forces a deeper evaluation each time something new is
going to be introduced. If there are questions, or concerns, they can or
should be shared.

I can understand that historically, CAs have taken the latter view, that
everything not restricted is left to their better judgement, because prior
to the BRs, that's exactly how they operated: making up and defining the
rules as they went. But that view is not consistent with the BRs' purpose,
nor is it internally consistent with the BRs as written. We have the BRs
because those arbitrary decisions on permissiveness lead to vast
inconsistency in the Web PKI and individual root stores; the only way to
bring consistency is to reset and align on expectations. Similarly, there
would be no point in enumerating the things that are good, and places where
CA discretion is allowed, if they're implicitly permitted, something that
the BRs do in a number of places that call out when things are allowed.

Again, going back to the BRs, as written, I'm hoping a CA could help
clarify what, in the view of a Default-Allow advocate, the rules are for
CA's Subject, such as Locality or State. It would seem that CAs arguing for
Default-Allow would have to also be arguing that there are no rules for
these fields, except which the CA decides, and suggesting that the purpose
of Ballot 199 was to make things more liberal for CAs, removing all other
rules. That similarly would not be consistent with the purpose and
discussion of Ballot 199, but perhaps there's a thread or discussion or
minutes from a meeting I missed while looking into this, that would show
that yes, it was intentional to allow anything goes.

If a CA wants to argue for added Subject fields in a Root; fields that are
largely unused and technically undesirable (for example, they add size
without adding information relevant to Relying Parties at the time of
processing), then the CAs need to make the case to add these fields. Maybe
there's a reason I've overlooked. The topic of cross-signs was heavily
discussed back during the Ballot 199 discussions, I would not be surprised
if it resurfaces, and I'm sure we can continue to identify solutions that
still ensure we move forward.

I'm hoping that this issue stirs a systemic change, which is:
1) If CAs are unhappy with a Default-Deny view, and believe it's ambiguous,
then what language would they feel makes it clearer about the expectations
placed on them when reading the BRs? It has to be document wide; there's no
way we will catch all potential badness by trying to do it piecemeal. I'm
more interested in making sure it's clear that it is, and has been,
Default-Deny; arguing against that approach simply means it would be
addressed at Root Store Policy. Profiles are about ensuring consistency,
regardless of the CA operating, and we only get that through limiting
flexibility to as few joints as possible.

2) What other elements, when reading through a lens of Default-Deny, which
for some CAs may be a new read to the BRs, might have areas where more
flexibility is desired or intended? That is, when viewing and voting on
SC16, and thinking through the implications, did CAs not notice this - or
when voting on Ballot 199? Having CAs examine their existing practices, and
re-reading the BRs through a lense of Default-Deny (which there are a
number of CAs who have already done this, so it's not "CAs as an industry"
that haven't, but merely "some CAs"), helps make sure we're not overlooking
anything else in the BRs that might be seen as a surprise to the CA?

These are ways we can systematically improve things. We can provide the
clarity of existing expectations, with is Dimitris' concern, and we can
make sure CAs existing practices are accounted for, much like we did with
Ballot 190, much like we've done with other clarification ballots.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191009/11a80755/attachment-0001.html>