It seems that both new certificates don't contain the Extended Key Usage Extension.
So that these two intermediate certificates inherited the Purposes of DST Root CA X3
I know that the leaf certificates would contain Extended Key Usage Extension and limit the usage to ClientAuth and ServerAuth
But I'm still confused about why don't you include ExtKeyUsage into the cross-signed intermediate?
Intermediate certificates created after January 1, 2019, with the exception of cross-certificates that share a private key with a corresponding root certificate:
MUST contain an EKU extension; and,
...
I don't think that the new R3 qualifies under that cross-certificate rule, because its key is not the same as any root certificate. So I wonder, why is the EKU-less cross-certificate valid under that rule?
I'm not affiliated with LE and I'm not an X.509v4 expert, but it seems the Extended Key Usage has been introduced to the intermediate certs in the most recent key signing ceremony: all previous intermediate certificates (X1 to X4, both signed by ISRG Root X1 and cross-signed by IdenTrust) didn't have this extension.
Following up the recent threads about this latest key ceremony[1, 2], I came across a link to the related GitHub page: Let's Encrypt 2020 Hierarchy. Here you can find a link to the Boulder's ceremony tooling used to generate the intermediates. In this README, we can see the following text currently:
Note: Intermediate certificates always include the extended key usages id-kp-serverAuth as required by 7.1.2.2.g of the CABF Baseline Requirements. Since we also include id-kp-clientAuth in end-entity certificates in boulder we also include it in intermediates, if this changes we may remove this inclusion.
7.1.2.2.g of the CA/B Forum BR 1.7.2 (current version) reads:
extkeyUsage (optional/required)
For Cross Certificates that share a Subject Distinguished Name and Subject Public Key with a Root Certificate operated in accordance with these Requirements, this extension MAY be present. If present, this extension SHOULD NOT be marked critical. This extension MUST only contain usages for which the issuing CA has verified the Cross Certificate is authorized to assert. This extension MAY contain the anyExtendedKeyUsage [RFC5280] usage, if the Root Certificate(s) associated with this Cross Certificate are operated by the same organization as the issuing Root Certificate.
For all other Subordinate CA Certificates, including Technically Constrained Subordinate CA Certificates:
This extension MUST be present and SHOULD NOT be marked critical2.
For Subordinate CA Certificates that will be used to issue TLS certificates, the value id-kp-serverAuth [RFC5280] MUST be present. The value id-kp-clientAuth [RFC5280] MAY be present. The values id-kp-emailProtection [RFC5280], id-kpcodeSigning [RFC5280], id-kp-timeStamping [RFC5280], and anyExtendedKeyUsage [RFC5280] MUST NOT be present. Other values SHOULD NOT be present.
For Subordinate CA Certificates that are not used to issue TLS certificates, then the value id-kp-serverAuth [RFC5280] MUST NOT be present. Other values MAY be present, but SHOULD NOT combine multiple independent usages (e.g. including idkp-timeStamping [RFC5280] with id-kp-codeSigning [RFC5280]).
2 While RFC 5280, Section 4.2.1.12, notes that this extension will generally only appear within end-entity certificates, these Requirements make use of this extension to further protect relying parties by limiting the scope of subordinate certificates, as implemented by a number of Application Software Suppliers.
Personally, I think the BR isn't very clear about the definition for "Subordinate CA" and related definitions:
Subordinate CA: A Certification Authority whose Certificate is signed by the Root CA, or another Subordinate CA.
Root CA: The top level Certification Authority whose Root Certificate is distributed by Application Software Suppliers and that issues Subordinate CA Certificates.
Certification Authority: An organization that is responsible for the creation, issuance, revocation, and management of Certificates. The term applies equally to both Roots CAs and Subordinate CAs.
Personally, I think the distinct use of "Root CA" and "Subordinate CA" is that a subordinate CA is an organization without a root certificate present in Application Software Suppliers (i.e., browsers et c.). ISRG/Let's Encrypt wouldn't be such an organization, as the ISRG Root is present in Application Software Suppliers. Thus, ISRG/LE would qualify as a root CA, not a subordinate CA.
This is exact the opposite as what Mozilla describes in the link from @_az's post:
The term "subordinate CA" in this section refers to any organization or legal entity that is in possession or control of a certificate that is capable of being used to issue new certificates.
Skimming the BR it seems their definition of subordinate CA is as Mozilla writes: not as such a separate organization, but it's also possible to to read "Subordinate CA" loosly as "intermediate certificate issuing CA", even if it's the same organization. For example, section 6.1.1.1 writes:
For Root CA Key Pairs that are either (i) used as Root CA Key Pairs or (ii) Key Pairs generated for a subordinate CA that is not the operator of the Root CA or an Affiliate of the Root CA, the CA SHALL: (…)
There it apparently needs to describe exactly my definition of "Subordinate CA" by adding all those constraints..
Personally, I think that ballot is close to a disaster. As far as I know, the idea behind the CA/Browser Forum is to make a default set of rules for everybody. If browsers start doing some weird stuff, you can't just incorporate those things in the BR and force them to everybody. In any case it doesn't make things more clearly IMHO.. This particular apparently was added due to the Microsoft Root Program.
I concur. The addition of "(…) with a Root Certificate (…)" makes this cross-signed intermediate certificate invalid. However, I don't know if this was wat sleevi intended? The previous 7.1.2.2.g didn't mention this at all. Also, the explanation about this modification to 7.1.2.2.g about the Microsoft Root Program (see link to PR above) doesn't mention this also. If we look closer to the Microsoft Root Program Requirements, currently we read the following applicable section:
Issuing CA certificates that chain to a participating Root CA must be constrained to a single EKU (e.g., separate Server Authentication, S/MIME, Code Signing, and Time Stamping uses. This means that a single Issuing CA must not combine server authentication with S/MIME, code signing or time stamping EKU. A separate intermediate must be used for each use case.
I'm unable to link to the github page with history of that section, as the link to the github page (see the four grey dots at the top of the Program Requirements page @ MS) is dead unfortunately.
In any case, the MS Program Requirements don't make any difference between cross-signed intermediates or normal intermediates. So that makes the discussion about what sleevi intended and where he/she got it from about the Root Certificate exclusion of the cross-sign rule a little bit mute
zlint does flag the new cross-signature under that rule, though only at the info level because apparenty the linter doesn't know whether it's a cross-signature or not.
Hmm, perhaps LE wants to play by the rules for 200…%. Personally, I think that whole SC31 stuff isn't correct. The reasons stated for adding this specific rule isn't stated in Microsofts own rules.. I think this might be a perfect opportunity to start a discussion about this on a CA/Browser level.
Very good, looking forward to the formal incident report. And hopefully a discussion about 7.1.2.2.g: "How did these requirements end up there anyway?!?"
I don't understand why 7.1.2.2.g, as in the linked bugzilla, is relevant. The intermediates are not Technically Constrained, right? They are Unconstrained, in the language of the BRs.
So under 7.1.2.2.g, aren't the EKU's optional?
These certs are perhaps in violation of the Mozilla Root Program, but why of the BRs?
Only "For Cross Certificates that share a Subject Distinguished Name and Subject Public Key with a Root Certificate (…) For all other Subordinate Certificates" it's mandatory.
However, I don't really understand the "For all other Subordinate Certificates" part. The "all other" part would suggest that the first part also is about Subordinate Certificates. But have you ever seen a Subordinate Certificate (i.e., intermediate?) which has the same public key as a root certificate?
I think that whole 7.1.2.2.g section is just... Wrong.
Going by the glossary definitions in the BRs ... I think it's for sure a Subordinate CA and not a Root CA.
If Let's Encrypt had chosen to cross-sign their roots instead of their intermediates, they would have gotten away with no EKUs. But we'd all be worse off because we'd need have fullchains with 3 certificates in them.
You're right. The public key contained in the certificate doesn't matter for the definition indeed, it's the signing certificate which makes the difference (according to the "Subordinate CA" definition) and the fact a cross-signed "root" certificate (i.e., Subordinate CA Certificate containing a root public key ) will never be stored in a root certificate store too (according to the "Root CA" definition).
.
