[Servercert-wg] Subject name requirements for CA Certificates
Dimitris Zacharopoulos (HARICA)
dzacharo at harica.gr
Wed Oct 9 03:58:52 MST 2019
I agree with Jeremy. For the same reason we added 9.2.8 in the EV
Guidelines to explicitly allow for /organizationalUnitName /in
Subscriber Certificates and *prohibit* any other subjectDN attribute, if
we wanted to explicitly prohibit any other subjectDN attributes in Root
or SubCA Certificates we should update the BRs accordingly.
We have seen several CA inclusion applications in public discussions (at
least in the Mozilla Root Store) that include Root CA Certificates with
ST and L attributes without any objections being raised
If we want to read the Baseline Requirements with such strict
interpretation, we must use "explicit" language for what is allowed and
what is not allowed. I don't think the existing guidelines and documents
were written from that perspective.
This was also identified as a concern during the presentation of the
European CAs at F2F 47
<https://cabforum.org/2019/08/16/minutes-for-ca-browser-forum-f2f-meeting-47-thessaloniki-12-13-june-2019/#Special-Challenges-and-concerns-for-Certification-Authorities-located-in-Europe>.
If we want to have such strict interpretations, then we need to re-read
the documents with that perspective in mind and ensure there are no
ambiguities for what is allowed and what is not. There should be no
"defaults" if we write explicit rules.
If the intent was to forbid L and ST in Root or SubCA Certificates, we
should have the rationale for this and update the BRs to explicitly
state that it is not allowed to have ANY additional subjectDN fields
except Country and Organization. If the intent was to allow L and ST in
order to align with subscriber Certificates (after all, we are trying to
identity an "Organization" in which L and ST can disambiguate possible
duplicates), then we should update the BRs to allow L and ST (and
possibly other attributes) along with the validation rules which should
be identical to the L and ST validation for subscriber certificates.
I can't accept the fact that so many CA CA/B Forum members mis-behaved
with this rule because of negligence. In my opinion there is obviously
something wrong with the requirements as written.
Dimitris.
On 2019-10-08 8:36 μ.μ., Jeremy Rowley via Servercert-wg wrote:
>
> 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
>
> o 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
>
> o 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
>
>
> _______________________________________________
> 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/20191009/0fdff283/attachment-0001.html>
More information about the Servercert-wg
mailing list