Unrestricted cross-signed Subordinate CA profile questions

[Phil Porada]

Suppose there are three key-pairs identified by the following names:

• Root CA Alpha
• Root CA Beta
• Intermediate CA Gamma

Suppose a fairly traditional hierarchy utilizing those key-pairs:

• Root CA Alpha has issued a certificate over its own public key. This self-signed cert must comply with BRs 7.1.2.1 Root CA Certificate Profile.
• Root CA Beta has issued a certificate over its own public key. Same as above.
• Root CA Beta has issued a basicConstraints CA=true cert over Intermediate CA Gamma's public key. Intermediate CA Gamma must comply with BRs 7.1.2.6 TLS Subordinate CA Certificate Profile.

Suppose that Root CA Alpha also cross-signs Root CA Beta. This cross-sign would normally be a TLS Subordinate CA Certificate Profile, subject to BRs 7.1.2.6, except that it also matches the definition of BRs 7.1.2.2 Cross-Certified Subordinate CA. Specifically it is "a CA Certificate using the same Subject Name and Subject Public Key Information as one or more existing CA Certificate(s), whether a Root CA Certificate or Subordinate CA Certificate." Therefore it has slightly looser requirements, namely in terms of extKeyUsages. This makes sense, as the whole point of the Cross-Certified Subordinate CA profile is to allow cross-certs to more closely match the original cert they're cross-signing.Suppose that Root CA Alpha also cross-signs Intermediate CA Gamma. Now we arrive at a problem. This certificate also meets the qualifications of a 7.1.2.2 Cross-Certified Subordinate CA: it has the same Subject Name and Public Key as an existing CA Certificate. This means that the EKU extension can be omitted entirely because it is "unrestricted". But this is very surprising! The TLS Subordinate CA Certificate it is cross-signing is clearly required to have EKUs. Why does this cross-sign get to omit them? It feels like this certificate should be required to abide by the 7.1.2.6 TLS Subordinate CA Certificate Profile, even though it meets the qualifications of 7.1.2.2.

If I have confused something, I apologize. Thank you for any guidance here.

[Thomas Zermeno]

Phil,

Presuming that CA Alpha and CA Beta are different organizations, which are not affiliated, then the cross-signed Intermediate CA Gamma certificate does not meet the requirements of 7.1.2.2.3, namely:

The extKeyUsage extension MAY be “unrestricted” as described in the following table if: ‐ the
organizationName represented in the Issuer and Subject names of the corresponding certificate
are either: ‐ the same, or ‐ the organizationName represented in the Subject name is an affiliate of
the organizationName represented in the Issuer name ....


In this hypothetical scenario, the issuer of the cross-signed intermediate certificate would be "organizationName=CA Alpha", but the subject would be "organizationName=CA Beta".  While this subject correlation matches the cross-signed "Root CA Beta", that is not considered when determining the extKeyUsage requirements. 

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/dcb791eb-4754-4389-a0ca-2551c9d55a7an%40mozilla.org.

--

-TZ

"When I am working on a problem I never think about beauty. I only think about how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong."
    - Buckminster Fuller (1895-1983)

[Aaron Gable]

Thomas,

Apologies, you're totally correct -- but the prompt was not fully specified. Suppose further that CA Alpha and CA Beta are operated by the same organization.

Thanks,

Aaron

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAAbOY9JW0iMxdKBQZsBTKprZ40_p1pi5grsiLgbEjV1VrbCikw%40mail.gmail.com.

[Thomas Zermeno]

Aaron,

I knew that question seemed too easy. 🙃 In this situation the Intermediate CA Gamma would have to be issued under a previous version of the BRs that allowed unrestricted EKU (if such a version does exist) in order to have the unrestricted EKU after cross-signing.  As a "modern" TLS intermediate, Gamma would have to comply with the current §7.1.2.6, before being cross-signed, and therefore extKeyUsage must be present and must not have the value of anyExtendedKeyUsage (i.e., unrestricted).  This is different from the situation where Root Beta is cross-signed by the affiliate Root Alpha, which then transforms "Root Beta" into a subordinate CA, as per §7.1.2.2.4., while maintaining its unrestricted EKU setting (either by the lack of the extKeyUsage field or the existence thereof with the value of anyExtendedKeyUsage). 

In my interpretation, §7.1.2.2.3 was not written to give additional powers to existing subCAs when cross-signed, but to clarify that it is permitted to maintain the unrestricted EKU when cross-signing root CAs. 

Regards,

Tom

[Aaron Gable]

Yes, I completely agree that that should be the interpretation; I think it's clear that this is the intended interpretation. And to be clear, yes, we're imagining that Intermediate CA Gamma was issued in compliance with the current profiles, and therefore is a 7.1.2.6 Subordinate CA Certificate and has EKUs as required by that profile.

But the current text of the BRs only seems to say:

- Section 7.1.2: "all certificates that [a CA] issues MUST comply with one of the following certificate profiles"

- Section 7.1.2.2: "This Certificate Profile MAY be used when issuing a CA Certificate using the same Subject Name and Subject Public Key Information as one or more existing CA Certificate(s), whether a Root CA Certificate or Subordinate CA Certificate."

- Section 7.1.2.2.3: "The extKeyUsage extension MAY be 'unrestricted'... if the organizationName represented in the Issuer and Subject names of the corresponding certificate are...

the same".

So it sure sounds like, by the letter, it would be acceptable for Root CA Alpha to issue a cross-sign of Intermediate CA Gamma which complies with the 7.1.2.2 Cross-Certified Subordinate CA Certificate Profile and does not have any EKUs. This feels like a bug in the BRs.

I think what we're looking for is either:

a) Some line in the current BRs which we've missed which disallows this configuration; or

b) Suggestions for some change that could be made to the BRs which would disallow this configuration.

Thanks,

Aaron

[Corey Bonnell]

• So it sure sounds like, by the letter, it would be acceptable for Root CA Alpha to issue a cross-sign of Intermediate CA Gamma which complies with the 7.1.2.2 Cross-Certified Subordinate CA Certificate Profile and does not have any EKUs. This feels like a bug in the BRs.

 

Agreed that this is allowed by the BRs. However, MRSP section 5.3 says:

 

“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;

    MUST NOT include the anyExtendedKeyUsage KeyPurposeId; and

    MUST NOT include both the id-kp-serverAuth and id-kp-emailProtection KeyPurposeIds in the same certificate.”

 

So, although this EKU-less cross-certificate issued to CA Gamma is perfectly compliant with the BRs, it would run afoul of MRSP as CA Gamma’s key is not certified by a root certificate in the Mozilla root store.

 

Thanks,

Corey

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAEmnErcdThaHFDVYem3Sa6GXGJH5peP0sH9XfBO7aa3av2CqyA%40mail.gmail.com.

[Aaron Gable]

Corey,

Aha, thank you! We had not yet started perusing individual root program requirements. This suggests that perhaps the simplest fix for the BRs is to amend Section 7.1.2.2 from:

> This Certificate Profile MAY be used when issuing a CA Certificate using the same Subject Name and Subject Public Key Information as one or more existing CA Certificate(s), whether a Root CA Certificate or Subordinate CA Certificate.

to:

> This Certificate Profile MAY be used when issuing a CA Certificate using the same Subject Name and Subject Public Key Information as one or more existing Root CA Certificate(s).

I assume there was reasoning behind the decision to explicitly state "whether a Root CA Certificate or Subordinate CA Certificate" in 7.1.2.2, but I haven't been able to find it, neither in the meeting minutes sent to CA/BF lists nor in the history of or comments on the Profiles PR. This language was present in the very first draft of that PR, in a commit by Ryan Sleevi named "Profiles WIP".

I'd love to know more if people recall the reasoning behind this carveout, and if folks see a reason not to close it.

Aaron

[Dimitris Zacharopoulos]

[Re-sending because my mail client accidentally dropped the list address]

Corey,

The "corresponding root certificate" does not need to be included in the Mozilla Root Program which allows cross signing of CAs that are in the inclusion process.


Thanks,

Dimitris.

Aug 8, 2023 23:27:13 'Corey Bonnell' via dev-secur...@mozilla.org <dev-secur...@mozilla.org>:

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/DM6PR14MB2186AF17B2A0D30DBC6C2B90920DA%40DM6PR14MB2186.namprd14.prod.outlook.com.

[Aaron Gable]

(Apologies if you're seeing this twice, the thread got accidentally forked.)

Hi all,

Thanks to some off-list / backchannel conversations, I think I have a better understanding of what's going on here.

Structurally, there is zero difference between:
A) A keypair which is intended to be a Root, and has both a self-signed and a cross-signed (for compatibility) certificate generated at the same time; and
B) A keypair which is intended to be an Intermediate, and has both a cross-signed (from a Root) and a self-signed (for... some internal purpose?) certificate generated at the same time.

So technically the current Mozilla requirement appears to have a loophole. Suppose that a CA really wants to cross-sign Intermediate Epsilon, but they want the resulting cert to have no EKUs. They can first have Epsilon's private key issue a self-signed certificate, and then the cross-certificate will "share a private key with a corresponding root certificate" and is no longer subject to the EKU requirement.

The existence of this end-run around the system is why the current version of the BRs says "whether a Root CA Certificate or Subordinate CA Certificate". It's functionally impossible to truly distinguish between Roots and Intermediates (many or most CA keypairs are represented by both), so don't even bother trying.

However, I don't think it is true that we as a community want CAs to issue Cross-Certified Subordinate CA Certificates with no EKUs just because they can. I think the current BRs language goes beyond just permitting this behavior and, by virtue of its "or a Subordinate CA Certificate" call-out, implicitly encourages this behavior. Yes, this is nit-picking and splitting hairs, but I think it would be better for the BRs to permit EKU-less cross-signs only of Root certificates, and if a CA really wants to do an end-run around that requirement, then they can go generate that root.

Aaron

[Corey Bonnell]

• The existence of this end-run around the system is why the current version of the BRs says "whether a Root CA Certificate or Subordinate CA Certificate". It's functionally impossible to truly distinguish between Roots and Intermediates (many or most CA keypairs are represented by both), so don't even bother trying.
  
  

BR 6.1.7 has the following set of restrictions of Root CA Private Keys:

 

“Private Keys corresponding to Root Certificates MUST NOT be used to sign Certificates except in

the following cases:

1. Self‐signed Certificates to represent the Root CA itself;

2. Certificates for Subordinate CAs and Cross‐Certified Subordinate CA Certificates;

3. Certificates for infrastructure purposes (administrative role certificates, internal CA

operational device certificates); and

4. Certificates for OCSP Response verification”

 

The CA issuing such a self-signed Root Certificate is a statement that the keypair in question will be used in accordance with BR 6.1.7. Notably, 6.1.7 does not allow the issuance of end-entity TLS certificates, so I doubt this loophole in the BRs would ever be (ab)used by a CA in practice.

 

Thanks,

Corey