[Servercert-wg] Subject name requirements for CA Certificates

Tue Oct 8 11:07:26 MST 2019

Ryan,

There are at least 3 different topics in this email so I think we need to dissect them.

1) Root subject DN information

Section 7.1.4.3.1 lists the rules for what needs to be included in the Roots, but, imo, it does not preclude other fields.  Other CAs have OU for example, is that a misissuance?  If this is THE list of fields, then we should amend that section to say the Root must have exactly these 3 fields (C, O, CN), no more and no fewer.

2) Cross certificates not complying to current BR requirements

A Cross Certificate is a certificate that is used to establish a trust relationship between two Root CAs, per the definition in the BRs.  The Issuer DN needs be the value of the signing root and the subject DN needs to be the DN of the CA that is being signed.  These are “special” certificates and I don’t think the rules for subordinate CAs apply.  RFC 5280 says:

   CAs MUST encode the distinguished name in the subject field of a CA

   certificate identically to the distinguished name in the issuer field

   in certificates issued by that CA.  If CAs use different encodings,

   implementations might fail to recognize name chains for paths that

   include this certificate.  As a consequence, valid paths could be

   rejected.

I don’t think that Cross Certificates can  follow the rules for Subordinate CAs and we should more clearly specify the requirements for these in the BRs as a separate category vs. lumping them in with subordinate CAs.

3) GlobalSign Root created in 12/2014 not compliant in that it does not contain C

I’m still looking, but so far I haven’t found a spec that mandates C for Root created at that time.  Could one of you point me to that?

From: Servercert-wg <servercert-wg-bounces at cabforum.org> On Behalf Of Ryan Sleevi via Servercert-wg
Sent: Tuesday, October 8, 2019 1:25 PM
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/319aade0/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/20191008/319aade0/attachment-0001.p7s>