[Servercert-wg] Subject name requirements for CA Certificates

[Ryan Sleevi]

On Wed, Oct 9, 2019 at 9:53 AM Ryan Sleevi <sleevi at google.com> wrote:

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

I received a question off-list about this, and so I wanted to resurface
this, especially in light of
https://cabforum.org/pipermail/servercert-wg/2019-October/001171.html

Our goal is to make sure that the expectations are clearly and
unambiguously communicated, and that CAs are approaching the BRs in a way
that's aligned with the needs of Browsers that use BRs and BR audits as
part of their Root Program.

As we saw with SC16, and we see now, different CAs read the BRs
differently, and this can lead to very inconsistent results. While I don't
think that one can read the BRs internally consistent with Default-Allow,
the extent of the interpretation on this particular section is so
widespread, and certainly on the lower urgency issues, that we should try
to fix it. As much as I know it's painful to bring up, we saw the same
issue with underscores: where CAs didn't apply the relevant RFCs, which
lead to incorrect results.

My objectives are two-fold:
1) How do we make sure it's consistently clear that the BRs should be read
as Default-Deny? Regardless of your views on how they should be read, let's
fix it, so that it aligns with expectations?
2) What are the things that CAs are doing that would be impacted by that?
Are there things other than Subject names that would be impacted? Let's
identify and discuss those.

I think that we'd be willing to overlook matters of non-compliance, if they
credibly and specifically were related to this underlying problem of
reading things as Default-Allow versus Default-Deny, are of limited impact
to our users (to be evaluated on a case-by-case basis), and we can make
sure that there's consensus on the expression of Default-Deny in the BRs
that everyone agrees means Default-Deny. If CAs come forward with examples
of things that would be prohibited by Default-Deny, but which they did or
do, let's discuss them and figure out how to address it.

Provided that we're making forward progress in the Forum on this, and CAs
are identifying areas that are impacted, and proposing solutions, and if
CAs adopt a default position of "Default-Deny" for new-issuance and raise
matters of concern or impact that it might have, we're more than happy to
continue discussing here and clarifying. But I think it's important to make
sure it's clear the expectation, so we can figure out how to move from
"where we are" to "where we should move towards".

A different way of framing this: Let's make sure we consistently take an
approach of "Why" rather than "Why not", as Wayne summarized previously in
https://cabforum.org/pipermail/validation/2019-September/001332.html . That
requires setting the default expectation for how to read the BRs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191009/54dffcda/attachment-0001.html>