[Servercert-wg] Subject name requirements for CA Certificates

[Tim Hollebeek]

Doug is right.

 

This is how standards work.  The requirements are the requirements.

 

If any aspect of certificate issuance needs to be constrained, those requirements need to be explicitly stated in the Baseline Requirements so that everyone is clear what they are.  This is how things have always worked, both in the Baseline Requirements, and every other standards document.

 

-Tim

 

From: Servercert-wg <servercert-wg-bounces at cabforum.org> On Behalf Of Doug Beattie via Servercert-wg
Sent: Wednesday, October 9, 2019 12:28 PM
To: Ryan Sleevi <sleevi at google.com>; CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>; Rob Stradling <rob at sectigo.com>
Subject: Re: [Servercert-wg] Subject name requirements for CA Certificates

 

Ryan,

 

I agree with Rob.  It’s clear that your view is not shared by everyone and evangelizing your view on the mail lists won’t help those that read the BRs as their source of truth.  We need to go through a BR update and explicitly state what’s permitted and what isn’t so that EVERYONE is on same page with interpretation and have the correct historical interpretation.  These specs need to stand on their own. Even those that read most of the emails on these lists are not all sharing the same interpretation so it’s important we get the rules explicitly stated in the BRs.

 

Take the EVGL, section 9.2.9 that says: CAs SHALL NOT include any Subject attributes except as specified in Section 9.2.  This implies that other sections which list sets of fields without this statement may include other items not explicitly listed, else why make this statement there and nowhere else?   

 

Take for example the BRs, 7.1.2.1 Root CA Certificate.  It lists basicConstraints, keyUsage, certificatePolicies and extendedKeyUsage.  Are these the ONLY extensions permitted? No, 

 

Section 7.1.2.3 lists 6 extensions.  Is this the only set of extensions permitted in subscriber certificates?  No, certainly subjectAltName is permitted (mandated).  If this is permitted and not on the list, why not others like Netscape Certificate Type, Logo Type extension (https://www.ietf.org/rfc/rfc3709.txt), and more?  If the list of extensions needs to be limited to a set, then that NEEDS to be in the BRs.

 

Need I continue?

 

 

 

From: Servercert-wg <servercert-wg-bounces at cabforum.org <mailto:servercert-wg-bounces at cabforum.org> > On Behalf Of Ryan Sleevi via Servercert-wg
Sent: Wednesday, October 9, 2019 9:54 AM
To: Rob Stradling <rob at sectigo.com <mailto:rob at sectigo.com> >
Cc: CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org <mailto:servercert-wg at cabforum.org> >
Subject: Re: [Servercert-wg] Subject name requirements for CA Certificates

 

 

 

On Wed, Oct 9, 2019 at 8:34 AM Rob Stradling <rob at sectigo.com <mailto: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/fa4aaa81/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4940 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191009/fa4aaa81/attachment-0001.p7s>