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 <https://github.com/cabforum/servercert/pull/373>. This language was present in the very first draft of that PR <https://github.com/cabforum/servercert/commit/d513d20973493f1c17663d67500621ca59098c45#diff-e0ac1bd190515a4f2ec09139d395ef6a8c7e9e5b612957c1f5a2dea80c6a6cfeR1837>, 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 On Tue, Aug 8, 2023 at 1:27 PM Corey Bonnell <[email protected]> wrote: > > - 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 > > > > *From:* 'Aaron Gable' via [email protected] < > [email protected]> > *Sent:* Tuesday, August 8, 2023 4:14 PM > *To:* Thomas Zermeno <[email protected]> > *Cc:* Phil Porada <[email protected]>; > [email protected] > *Subject:* Re: Unrestricted cross-signed Subordinate CA profile questions > > > > 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 > > > > On Tue, Aug 8, 2023 at 12:17 PM Thomas Zermeno <[email protected]> > wrote: > > 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 > > > > On Tue, Aug 8, 2023 at 12:10 PM Aaron Gable <[email protected]> wrote: > > 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 > > > > On Tue, Aug 8, 2023 at 10:03 AM Thomas Zermeno <[email protected]> > wrote: > > 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. > > > > On Tue, Aug 8, 2023 at 11:00 AM 'Phil Porada' via > [email protected] <[email protected]> wrote: > > 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. > > -- > You received this message because you are subscribed to the Google Groups " > [email protected]" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > 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 > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/dcb791eb-4754-4389-a0ca-2551c9d55a7an%40mozilla.org?utm_medium=email&utm_source=footer> > . > > > > > -- > > -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) > > -- > You received this message because you are subscribed to the Google Groups " > [email protected]" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > 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 > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAAbOY9JW0iMxdKBQZsBTKprZ40_p1pi5grsiLgbEjV1VrbCikw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > > > > -- > > -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) > > -- > You received this message because you are subscribed to the Google Groups " > [email protected]" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAEmnErcdThaHFDVYem3Sa6GXGJH5peP0sH9XfBO7aa3av2CqyA%40mail.gmail.com > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAEmnErcdThaHFDVYem3Sa6GXGJH5peP0sH9XfBO7aa3av2CqyA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAEmnEre0YnTjeOsqBjybcT8RMXh15ZbXnj0xDY%3DX487aBKaw%3DQ%40mail.gmail.com.
