[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 [email protected]
<[email protected]>:
* 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]> 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/DM6PR14MB2186AF17B2A0D30DBC6C2B90920DA%40DM6PR14MB2186.namprd14.prod.outlook.com
<https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/DM6PR14MB2186AF17B2A0D30DBC6C2B90920DA%40DM6PR14MB2186.namprd14.prod.outlook.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/ae469baf-4c58-e8c2-4961-80d1b2f9405b%40it.auth.gr.
