* 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 <http://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]
<mailto:[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]
<mailto:[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]
<mailto:[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] <mailto:[email protected]>
<[email protected] <mailto:[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] <mailto:[email protected]> "
group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected]
<mailto:[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] <mailto:[email protected]> "
group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected]
<mailto:[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] <mailto:[email protected]> "
group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected]
<mailto:[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/DM6PR14MB2186AF17B2A0D30DBC6C2B90920DA%40DM6PR14MB2186.namprd14.prod.outlook.com.
smime.p7s
Description: S/MIME cryptographic signature
