[Servercert-wg] Subject name requirements for CA Certificates

Fri Oct 11 06:50:07 MST 2019

Getting back to Ryan’s initial post that subordinate CAs are being issued with more than the 3 field listed in Section 7.1.4.3.1.  Is it time to discuss the topic with the intent (at least from the CA perspective) that we propose a ballot that permits additional fields such as OU, S, and L to permit relying parties to have a better and more detailed understanding of the CA entity issuing the certificates?

By the way, Root program members weren’t listed in Ryan’s email and some of them are also at fault for not following the strict default DENY for CA subject DN:

*	Microsoft: 

*	https://crt.sh/?id=21606064 <https://crt.sh/?id=21606064&opt=cablint> &opt=cablint
*	https://crt.sh/?id=21606056 <https://crt.sh/?id=21606056&opt=cablint> &opt=cablint
*	https://crt.sh/?id=21606070 <https://crt.sh/?id=21606070&opt=cablint> &opt=cablint
*	https://crt.sh/?id=21606058 <https://crt.sh/?id=21606058&opt=cablint> &opt=cablint

*	Apple:

*	https://crt.sh/?id=1027088214 <https://crt.sh/?id=1027088214&opt=cablint> &opt=cablint
*	https://crt.sh/?id=5250464 <https://crt.sh/?id=5250464&opt=cablint> &opt=cablint
*	https://crt.sh/?id=1600419523 <https://crt.sh/?id=1600419523&opt=cablint> &opt=cablint

Lastly, I also wanted to point out that Let’s encrypt has a cross cert with an issuer that does not have Country. https://letsencrypt.org/certs/lets-encrypt-x4-cross-signed.pem.txt 

I think we need to formalize this in the BRs via ballot so that it’s clear to everyone:

a.	what can go into a Subordinate CA certificate and 
b.	what can/must go into a Cross Certificate as this is different and driven exclusively by the DN of the 2 roots being cross certified)

Doug

From: Servercert-wg <servercert-wg-bounces at cabforum.org> On Behalf Of Ryan Sleevi via Servercert-wg
Sent: Wednesday, October 9, 2019 4:43 PM
To: CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Subject: Re: [Servercert-wg] Subject name requirements for CA Certificates

On Wed, Oct 9, 2019 at 9:53 AM Ryan Sleevi <sleevi at google.com <mailto: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/20191011/1180dd8c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5701 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191011/1180dd8c/attachment-0001.p7s>