Allow multiple instances of the OU attribute in CA Certificates #394
Conversation
The current BRs are silent on the prohibition of the OU attribute in CA Certificates, thus the profiles ballot must allow multiple instances of OU in CA Certificates, despite being "NOT RECOMMENDED".
|
@dzacharo: "silent" in what sense? Didn't the root program representatives make it clear that they expect CAs to read the BRs with a "Default Deny" mindset? See the https://lists.cabforum.org/pipermail/servercert-wg/2019-October/001154.html thread, which @sleevi started with...
|
|
There was never conclusion on this topic and Sleevi's interpretation was never reflected in the BRs. In fact, in upcoming meetings, he acknowledged conflicts that would cause significant impact if the BRs were read as a "default deny". IMHO the BRs are neither "default deny" nor "default allow". They have clauses that explicitly allow or explicitly deny things. If we identify areas that need more strict rules, we update them accordingly, like we did with the OU in subscriber certificates. If we want to disallow OUs in CA Certificates, we can certainly introduce that and check the impact of this change. Check the minutes of the recent validation subcommittee. One such example of significant impact is the |
|
I'm not sure why we're reintroducing OUs here when they've effectively been sunset. My initial thought was that it sounds like, if anything, the thing that was overlooked was ensuring they're explicitly disallowed in the same timeframe as for subscriber certificates. |
|
Hi Clint, |
|
Hi Dimitris, |
|
I thought it was clear from the minutes, apologies if it wasn't captured with more details. The currently proposed profiles ballot clearly forbids multiple instances of a subject attribute except for Ryan took an action to check CCADB and report for recent issuance of CA Certificates that contain OU fields after the prohibition in end-entity certificates. Hope this makes things a bit clearer. |
|
Hi all,
I ran a query on Censys to present the list of valid CA certificate subject
DNs known to CT, where certificates were issued after 6/8/2017 (when the
language we now see in Section 7.1.4.3 of the BRs became effective).
SELECT parsed.subject_dn
FROM `censys-io.certificates_public.certificates`
WHERE parsed.extensions.basic_constraints.is_ca IS TRUE
AND parsed.validity.start >= TIMESTAMP("2017-06-08")
AND parsed.validity.end >= TIMESTAMP("2022-10-12")
AND validation.google_ct_primary.valid = TRUE
When evaluated, this returned 2,281 unique CA subject DNs. These subject
DNs were then parsed to identify the number of occurrences of the following
subject distinguished name fields:
Name Fields Count=0 Count=1 Count>1
CN= 2 2278 1
C= 7 2274 0
DC= 2278 0 3
emailAddress= 2276 0 5
L= 1743 538 0
organizationIdentifier= 2128 1 152
O= 4 2277 0
OU= 1778 461 42
postalCode= 2278 3 0
serialNumber= 2163 118 0
street= 2278 3 0
ST= 1932 349 0
Total Certificates Examined: 2281
* Credit to Censys for this data
To help interpret the above data, using the "OU" row as an example:
- 1778 certificate subject DNs contained *no* instance of "OU="
- 461 certificate subject DNs contained *1* instance of "OU="
- 42 certificate subject DNs contained *more than 1* instance of "OU="
I'm still checking to see if licensing agreements would allow me to share
the raw data, and if so, will follow-up with it.
Thanks,
Ryan
…On Wed, Oct 12, 2022 at 3:54 PM Dimitris Zacharopoulos < ***@***.***> wrote:
I thought it was clear from the minutes, apologies if it wasn't captured
with more details.
The currently proposed profiles ballot clearly forbids multiple instances
of a subject attribute except for streetAddress and domainComponent (for
CA and end-entity certificates). A concern was raised that the current BRs
do not prohibit OUs in CA Certificate subjectDN which means that the
profiles ballot should allow multiple instances of the OU attribute as well.
If we want to prohibit the OU attribute from CA Certificates, this could
be introduced in a future ballot but should probably not delay or cause
risks to the passing of the profiles ballot.
Ryan took an action to check CCADB and report for recent issuance of CA
Certificates that contain OU fields after the prohibition in end-entity
certificates.
Hope this makes things a bit clearer.
—
Reply to this email directly, view it on GitHub
<#394 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABAR37NCYLKQDVBZN2OXDH3WC4JNPANCNFSM6AAAAAARATLWQY>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
Thanks Ryan. I guess it would be important to see if OUs have been included on or after 2022-09-01 which was the cutoff date for forbidding OU in subscriber certificates. If none have been created, then we might close this PR and create another one to explicitly disallow the OU in CA Certificate profile just like we do with the Subscriber Certificate profile, because there would be no impact. However, we should add a note in the ballot introduction about that normative change to make sure all CAs are aware of this. |
I'm not the expert on the crt.sh DB, but I ran the following query against it just now: That should capture any CA certificate that has a known Server Auth (plus EV Server Auth) trust purpose in any of the crt.sh known root stores. 0 results are found. Removing the match against trust purposes, reveals a few results, but those are not publicly trusted. |
|
After adjusting my original query, 24 CA certificates are known to CT that
were issued after 9/1/22. Each has 1 instance of CN, O, and C.
My findings are consistent with Martijn's (Thanks, Martijn!).
- Ryan
…On Thu, Oct 13, 2022 at 4:30 AM Martijn Katerbarg ***@***.***> wrote:
Thanks Ryan. I guess it would be important to see if OUs have been
included on or after 2022-09-01 which was the cutoff date for forbidding OU
in subscriber certificates.
I'm not the expert on the crt.sh DB, but I ran the following query against
it just now:
SELECT cc.ca_id, x509_nameattributes(certificate, '2.5.4.11', true) from ccadb_certificate
INNER JOIN ca_certificate cc on ccadb_certificate.certificate_id = cc.certificate_id
INNER JOIN ca c on cc.ca_id = c.id
INNER JOIN certificate cert on cc.certificate_id = cert.id
WHERE x509_notbefore(certificate) >= '2022-09-01' AND cc.ca_id IN (SELECT ca_id FROM ca_trust_purpose WHERE trust_purpose_id IN (SELECT id as trust_purpose_id FROM trust_purpose WHERE purpose ILIKE '%Server Auth%'))
That should capture any CA certificate that has a known Server Auth (plus
EV Server Auth) trust purpose in any of the crt.sh known root stores.
0 results are found. Removing the match against trust purposes, reveals a
few results, but those are not publicly trusted.
—
Reply to this email directly, view it on GitHub
<#394 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABAR37M7KL7HHVJYTLZU7NLWC7CAVANCNFSM6AAAAAARATLWQY>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Just adding that a clear position on this (codifying default-deny in the BRs or just saying "No OUs anywhere") would be useful as we had some back and forth about an OU lint and if it should or shouldn't apply to CA certs over in the zlint project. Mainly just adding this comment here to try and add weight to this discussion topic being a useful one as teams working in this space have felt a lack of clarity on if OUs are allowed in CA certs or not and in the case of zlint our no-OUs lint doesn't currently apply to CA certs. Relevant zlint issue that references or is referenced where this came up: zmap/zlint#690 |
|
Thanks Rob. Indeed a clarification would help which is what I intend to propose in today's SCWG teleconference (https://lists.cabforum.org/pipermail/servercert-wg/2022-October/003339.html) |
|
As mentioned in #394 (comment) and agreed in today's SCWG call, I will close this PR and create another one to prohibit OUs in CA Certificates, after we double check that the requirements would allow the issuance of a non-TLS subCA that may include OUs. |
The current BRs are silent on the prohibition of the OU attribute in CA Certificates, thus the profiles ballot must allow multiple instances of OU in CA Certificates, despite being "NOT RECOMMENDED".