[Servercert-wg] Subject name requirements for CA Certificates

[Dimitris Zacharopoulos (HARICA)]

This is a very long thread and haven't had a chance to go through it all 
the way, so apologies if what I say here has already been discussed.

It appears that when the guidelines were written, they were not so 
carefully considered in terms of consequences of mis-interpretation and 
expectations as far as DENY or ALLOW rules. To put it simple with an 
example, when the Forum enumerated the subjectDN attributes in the EV 
Guidelines (section 9.2), the /organizationalUnitName /field was not 
included. Especially when it was clarified that no other fields are 
allowed to be present, this created an unintended DENY rule that no one 
thought of or explained. There was no rationale why the 
/organizationalUnitName /was LEFT OUT of the EV Guidelines. That 
unintentional gap was fixed by ballot SC16 with 100% of voting in favor 
by both Issuers and Consumers 
https://cabforum.org/2019/03/16/ballot-sc16-other-subject-attributes/

Similarly, for CA Certificates (Root or Subordinate CA Certificates), I 
couldn't find a discussion to support that no other identity subjectDN 
fields should be allowed and why. If the rules wanted to forbid 
additional subjectDN fields for such certificates, they should include 
language as explicit as section 9.2 of the EV Guidelines which says "CAs 
SHALL NOT include any Subject attributes except as specified in Section 
9.2."

In the absence of any rationale to limit only a c/ountryName, 
organizationName/ and /commonName /field in subjectDNs of CA 
Certificates, I propose we create a ballot that clarifies the 
expectation to include /stateOrProvinceName/, /localityName/, 
/organizationalUnitName/ and perhaps /organizationIdentifier/, along 
with their validation rules (we already have good rules for those 
fields), and add a clause that other fields SHALL NOT be present.

I hope this will be an uncontroversial issue just like it happened with 
ballot SC16. At least we will take care of this issue. Then, we can look 
at the rest of the documents for similar issues. I'm afraid that even if 
we adopt a policy for "Default-DENY" we will still have problems in 
understanding what to do. English language (and practically ANY 
language) can describe a requirement and explicitly leave some leeway 
allowing options to the CA. Then a possible reader won't know if that 
leeway was left on purpose (intentional) or not. That's why in most 
cases of updates in the Guidelines, there was rationale for ALLOW and/or 
DENY as necessary.

The default-allow default-deny is a very interesting discussion but we 
have spotted a real practical problem in the guidelines that causes 
confusion and possible compliance risks that needs to be taken care of 
sooner than later.


Dimitris.


On 2019-10-09 8:53 μ.μ., Tim Hollebeek via Servercert-wg wrote:
>
> 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.
>
>
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> http://cabforum.org/mailman/listinfo/servercert-wg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191023/e99f2042/attachment-0001.html>