[Servercert-wg] Subject name requirements for CA Certificates

Tue Oct 8 10:36:57 MST 2019

There’s nothing in the language of the BRs that prohibits other fields in issuing certs, and I don’t read the history that way.  The purpose of ballot 199 was stated as:

“Section 7.1.4.3 of the BRs, which deals with Subject Information for Subordinate CA Certificates, currently requires only that all information in a Subordinate CA Certificate is accurate; it does not say what information is required. Some of the necessary information is required elsewhere in the BRs, but it is not complete - commonName is missing. If commonName is omitted, DN clashes can more easily occur. So this motion centralises that information in the obvious place, and adds a commonName requirement.“

Nothing is specified about restricting additional fields – it’s all about consolidating information and adding a commonName. If the intent was to exclude other information, the language would have said these are the only fields permitted.  If I’m going with the plain language, the ballot made commonName required and consolidated the language without further restricting contents.  If the intent was to restrict the contents to just those fields, that was a pretty bad miss on the stated purpose and in the language.

From: Servercert-wg <servercert-wg-bounces at cabforum.org> On Behalf Of Ryan Sleevi via Servercert-wg
Sent: Tuesday, October 8, 2019 11:25 AM
To: CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Subject: [Servercert-wg] Subject name requirements for CA Certificates

The Baseline Requirements, v1.6.6, Section 7.1.4, sets out the rules for certificate names.

Subscriber Certificates are described in 7.1.4.2, with the Distinguished Name profile set forward in 7.1.4.2.2

The following fields are permitted (in some form) in Subscriber certificates:

  *   7.1.4.2.2.a - commonName (OID 2.5.4.3)
  *   7.1.4.2.2.b - organizationName (OID 2.5.4.10)
  *   7.1.4.2.2.c - givenName (OID 2.5.4.42)
  *   7.1.4.2.2.c - surname (OID 2.5.4.4)
  *   7.1.4.2.2.d - streetAddress (OID 2.5.4.9)
  *   7.1.4.2.2.e - localityName (OID 2.5.4.7)
  *   7.1.4.2.2.f - stateOrProvinceName (OID 2.5.4.8)
  *   7.1.4.2.2.g - postalCode (OID 2.5.4.17)
  *   7.1.4.2.2.h - countryName (OID 2.5.4.6)
  *   7.1.4.2.2.i - organizationalUnitName (OID 2.5.4.11)
  *   And any other attribute permitted under 7.1.4.2.2.j
For EV certificates, only the following fields are permitted in Subscriber certificates, as defined in Section 9.2 of the EV Guidelines, v1.7.0

  *   9.2.1 - organizationName (OID 2.5.4.10)
  *   9.2.2 - commonName (OID 2.5.4.3)
  *   9.2.3 - businessCategory (OID 2.5.4.15)
  *   9.2.4 - jurisdictionLocalityName (OID 1.3.6.1.4.1.311.60.2.1.1)
  *   9.2.4 - jurisdictionStateOrProvinceName (OID 1.3.6.1.4.1.311.60.2.1.2)
  *   9.2.4 - jurisdictionCountryName (OID 1.3.6.1.4.1.311.60.2.1.3)
  *   9.2.5 - serialNumber (OID 2.5.4.5)
  *   9.2.6 - streetAddress (OID 2.5.4.9)
  *   9.2.6 - localityName (OID 2.5.4.7)
  *   9.2.6 - stateOrProvinceName (OID 2.5.4.8)
  *   9.2.6 - countryName (OID 2.5.4.6)
  *   9.2.6 - postalCode (OID 2.5.4.17)
  *   9.2.7 - organizationalUnitName (OID 2.5.4.11)
  *   9.2.8 - organizationIdentifier (OID 2.5.4.97)
However, for CA certificates, both Root and Intermediate, the Baseline Requirements only permit the following, as defined in Section 7.1.4.3.1

  *   7.1.4.3.1.a - commonName (OID 2.5.4.3)
  *   7.1.4.3.1.b - organizationName (OID 2.5.4.10)
  *   7.1.4.3.1.c - countryName (OID 2.5.4.6)
No other fields are listed in 7.1.4.3.1. Nor is there permission to include any other attributes, comparable to 7.1.4.2.2.j

These changes were introduced in Ballot 199, https://cabforum.org/2017/05/09/ballot-199-require-commonname-root-intermediate-certificates/, which introduced these normative changes, adopted May 2017, with the end of the IP review period on 2017-06-08.

I highlight this because we're seeing CAs violate the requirements in 7.1.4.3.1 by issuing Intermediate CA certificates with attributes other than those enumerated. It is unclear to me how a CA can view this as permitted.

The only interpretation I can offer is that CAs are taking one of several views:
1) "We did not realize the BRs changed"

This accepts it's a mistake, and the CA failed to review the BRs for the changes and the normative requirement impact. This raises concerns about other changes to the BRs that the CA may not have followed or adopted, a continued source of concern for the ecosystem.

2) "Those only list the required fields; anything else is permitted."

This view assumes that the intent was to allow pre-Ballot 199 behaviour (of allowing CAs to issue whatever they want for Sub-CAs/Roots), and that the only change in 199 was to require those three fields. However, this reading is not consistent with 199, which restructured 7.1.4.2.2.j., which both explicitly stated additional fields were permitted, and explicitly restricted that permission to Subscriber certificates.

I'm not sure if there are other interpretations here, but I thought it important to highlight what the BRs currently require, and have required for more than two years now. I've noticed many CAs that are members of the Forum ignoring this requirement, and it's not clear to me why, or under what interpretation they believe they're compliant.

Examples from CA/B Forum Members include:

  *   Actalis S.p.A.:  https://crt.sh/?q=6018f0dffaa4d48f6b363dbd895b43d720691f9658e3d940727fb1499d525005
  *   Amazon:  https://crt.sh/?q=ecc295b6ddcd084ba7179fb53bdd1d422cb6c0a8d94f154d4a5b17780b7279ed
  *   ANF Autoridad de Certificacion:  https://crt.sh/?q=a757bd00fcfb5e438757b692770d751d01c060bff71fe6d5e6b8eaf4fc30a7e7
  *   Certinomis:  https://crt.sh/?q=03b5ffe7db4d85717cb2ed07119dd63a8d592c2fd04f2988d1c074f0fffaaa2e

     *   This also includes the organizationIdentifier OID, 2.5.4.97, in a CA certificate, which is not permitted

  *   CertSign:  https://crt.sh/?q=7826de1be414e454cfcae0d17b17ff0cad12ee68cf487f357b38499e274b0171
  *   ComSign:  https://crt.sh/?q=7c50eaaf7e06d11499907cdcb47e8e256c81d388cd0e1d93b92b558e0b971e50
  *   DigiCert:  https://crt.sh/?q=191e0b48b78b7efa4822a465ad69b34405b878d10bd853d8e57cb8b9d9e50b8b
  *   eMudhra:  https://crt.sh/?q=fad2e98649f1c606150f55269ebc035aea22ffac131de64ba6900c75d8447b7e
  *   Entrust:  https://crt.sh/?q=b700ba49af4d19e72fb15a2dac3c213ba44c319fa7da92772b3682e12b781093

     *   Incidentally, even if arguing that this was issued under 7.1.4.2, this violates the requirement that CAs SHALL NOT include a Domain Name in a Subject attribute

  *   E-Tugra:  https://crt.sh/?q=89e80a3ed72df73e58db23744e2ca3ecbc225f750a61d6be268124f7c95e465b
  *   GlobalSign:  https://crt.sh/?q=d439f88e8f2f80a306f910dcde548d71bbfd99a85fc7034efb610e3749550932
  *   HARICA:  https://crt.sh/?q=cdff27afa3daf9f706aa7ac530298337e520c8b10a22f6514e00e21fd2873b79
  *   Logius PKIoverheid:  https://crt.sh/?q=c7422de21cebc92ecae6be9dcd7e711ee650d30aed711fbb0df6b2c784b6c4fb
  *   QuoVadis:  https://crt.sh/?q=425202d4bbfda9b799d0f7aa927d944f42cca4237c2fc19875b9075deb35a621
  *   SECOM:  https://crt.sh/?q=7a4fcba079f5bddcf0a76c3b03a377e155a53009474a1b3eb8f34961a53bda9c
  *
  *   Sectigo:  https://crt.sh/?q=3989a31702e9e6a9485f3c92a77d21b1852c7f6722f23d44b8cbe72a926ec854
  *   SecureTrust:  https://crt.sh/?q=11d9330d1a2398508dd50d3094eb28b1b44900d9928f8c22b25ef7a781bdb403
  *   SSL.com:  https://crt.sh/?q=36c7e329750a403db0baf069c9a9f33963e5c98a66a8ab57016db6f88cc5614d
  *   SwissSign:  https://crt.sh/?q=78b08b7d449a53dea551dbe9bea5dd60fc7939c775535c018dfa24a3d9e9ffd7
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191008/caf9a6fc/attachment-0001.html>