[Servercert-wg] Subject name requirements for CA Certificates

Ryan Sleevi sleevi at google.com
Tue Oct 8 10:25:07 MST 2019

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

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

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

   - - commonName (OID
   - - organizationName (OID
   - - givenName (OID
   - - surname (OID
   - - streetAddress (OID
   - - localityName (OID
   - - stateOrProvinceName (OID
   - - postalCode (OID
   - - countryName (OID
   - - organizationalUnitName (OID
   - And any other attribute permitted under

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
   - 9.2.2 - commonName (OID
   - 9.2.3 - businessCategory (OID
   - 9.2.4 - jurisdictionLocalityName (OID
   - 9.2.4 - jurisdictionStateOrProvinceName (OID
   - 9.2.4 - jurisdictionCountryName (OID
   - 9.2.5 - serialNumber (OID
   - 9.2.6 - streetAddress (OID
   - 9.2.6 - localityName (OID
   - 9.2.6 - stateOrProvinceName (OID
   - 9.2.6 - countryName (OID
   - 9.2.6 - postalCode (OID
   - 9.2.7 - organizationalUnitName (OID
   - 9.2.8 - organizationIdentifier (OID

However, for CA certificates, both Root and Intermediate, the Baseline
Requirements only permit the following, as defined in Section

   - - commonName (OID
   - - organizationName (OID
   - - countryName (OID

No other fields are listed in Nor is there permission to include
any other attributes, comparable to

These changes were introduced in Ballot 199,
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 by issuing Intermediate CA certificates with attributes other
than those enumerated. It is unclear to me how a CA can view this as

The only interpretation I can offer is that CAs are taking one of several
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, 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.:
   - Amazon:
   - ANF Autoridad de Certificacion:
   - Certinomis:
      - This also includes the organizationIdentifier OID,, in a
      CA certificate, which is not permitted
   - CertSign:
   - ComSign:
   - DigiCert:
   - eMudhra:
   - Entrust:
      - Incidentally, even if arguing that this was issued under,
      this violates the requirement that CAs SHALL NOT include a
Domain Name in a
      Subject attribute
   - E-Tugra:
   - GlobalSign:
   - HARICA:
   - Logius PKIoverheid:
   - QuoVadis:
   - SECOM:
   - Sectigo:
   - SecureTrust:
   - SSL.com:
   - SwissSign:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191008/6b08b46f/attachment.html>

More information about the Servercert-wg mailing list