Clarification request: ECC subCAs under RSA Root

[pfuen...@gmail.com]

Hello all,

I'd have an open question about the possibility (from a compliance standpoint) of having an ECC 256 subordinate under an RSA 2048 Root.

If I look at the WebTrust criteria, I can see this:
****
4.1.3 CA key generation generates keys that:
a) use a key generation algorithm as disclosed within the CA’s CP and/or CPS;
b) have a key length that is appropriate for the algorithm and for the validity period of the CA certificate as disclosed in the CA’s CP and/or CPS. The public key length to be certified by a CA is less than or equal to that of the CA’s private signing key; and
c) take into account requirements on parent and subordinate CA key sizes and have a key size in accordance with the CA’s CP and/or CPS.
****

My reading of this criteria is that it's not possible to have a subordinate with a stronger key than the issuer, but this is unclear when mixing algorithms.

In theory, an ECC 256 subordinate has a stronger crypto than an RSA 2048 Root, so if I read the above criteria in terms of crypto strength, I get the impression that this is nor allowed. But I don't know if this is an appropriate interpretation of the rules.

Can anyone help me to see the light?

Thanks!
Pedro

[Corey Bonnell]

My understanding is that neither the BRs or any Root Program require that that subordinate CA key be weaker or equal in strength to the issuing CA's key.

Additionally, such a requirement would prohibit cross-signs where a "legacy" root with a smaller key size would certify a new root CA with a stronger key. For that reason, this illustrative control seems problematic.

Thanks,
Corey

_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

[pfuen...@gmail.com]

> My understanding is that neither the BRs or any Root Program require that that subordinate CA key be weaker or equal in strength to the issuing CA's key.
>
> Additionally, such a requirement would prohibit cross-signs where a "legacy" root with a smaller key size would certify a new root CA with a stronger key. For that reason, this illustrative control seems problematic.
>

Thanks, Corey.
I also see it problematic, but I've been seeing other root programs (i.e. Spanish Government) enforcing this rule, so I'd like to understand if it's a "best practice" or a rule, and, in particular, if it's rule to be respected for TLS-oriented hierarchies.
P

[Ryan Sleevi]

I agree with Corey that this is problematic, and wouldn't even call it a
best practice/good practice.

I appreciate the goal in the abstract - which is to say, don't do more work
than necessary (e.g. having an RSA-4096 signed by RSA-2048 is wasting
cycles *if* there's no other reason for it), but as Corey points out, there
are times where it's both necessary and good to have such chains.

On Wed, Mar 10, 2021 at 9:46 AM pfuen...--- via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> > My understanding is that neither the BRs or any Root Program require
> that that subordinate CA key be weaker or equal in strength to the issuing
> CA's key.
> >
> > Additionally, such a requirement would prohibit cross-signs where a
> "legacy" root with a smaller key size would certify a new root CA with a
> stronger key. For that reason, this illustrative control seems problematic.
> >
>

> Thanks, Corey.
> I also see it problematic, but I've been seeing other root programs (i.e.
> Spanish Government) enforcing this rule, so I'd like to understand if it's
> a "best practice" or a rule, and, in particular, if it's rule to be
> respected for TLS-oriented hierarchies.
> P

[Tim Hollebeek]

I know where this kind of requirement is coming from ... it's a common
requirement in key management systems, but they generally operate in worlds
that are completely different from the Web PKI. Even there, it often causes
more problems than it solves. I've spent more of my life dealing with the
fallout from rules like this than I care to admit.

It makes more sense when you have a complex asymmetric or symmetric system
with different strength keys protecting the distribution of symmetric keys
with different strengths, and you want to make sure the keys being
distributed actually have the intended strength, instead of being somewhat
weaker due to potential attacks on weak links in the distribution system.
One of the ways of simplifying that complexity is to enforce various
uniformity requirements on the chains. This helps prevent accidentally
using an encryption key that was distributed with a weaker key, and thinking
that it has full strength.

It's important to remember that TLS keys are real-time online authentication
keys, generally with relatively short lifetimes (relative to many typical
KMSs!), and the goal is to meet the minimum authentication strength goal at
the time the connection is being built. Whether one or more keys is a bit
stronger than necessary doesn't hurt anything in the same way that it can
for encryption keys. And as the two previous people have noted, mixed
chains can be extremely useful in various interoperability and
transition/upgrade scenarios. So rules like these can actually reduce
cryptoagility by unnecessarily eliminating perfectly viable options, and
reducing cryptoagility is the exact opposite of what we should be trying to
accomplish.

-Tim

> -----Original Message-----
> From: dev-security-policy <dev-security-...@lists.mozilla.org>
On

> Behalf Of Ryan Sleevi via dev-security-policy
> Sent: Wednesday, March 10, 2021 11:00 AM
> To: pfuen...@gmail.com <pfuen...@gmail.com>
> Cc: Mozilla <mozilla-dev-s...@lists.mozilla.org>
> Subject: Re: Clarification request: ECC subCAs under RSA Root
>
> I agree with Corey that this is problematic, and wouldn't even call it a
best
> practice/good practice.
>
> I appreciate the goal in the abstract - which is to say, don't do more
work than
> necessary (e.g. having an RSA-4096 signed by RSA-2048 is wasting cycles
*if*
> there's no other reason for it), but as Corey points out, there are times
where
> it's both necessary and good to have such chains.
>
> On Wed, Mar 10, 2021 at 9:46 AM pfuen...--- via dev-security-policy < dev-

> securit...@lists.mozilla.org> wrote:
>
> > > My understanding is that neither the BRs or any Root Program require
> > that that subordinate CA key be weaker or equal in strength to the
> > issuing CA's key.
> > >
> > > Additionally, such a requirement would prohibit cross-signs where a
> > "legacy" root with a smaller key size would certify a new root CA with
> > a stronger key. For that reason, this illustrative control seems
problematic.
> > >
> >

> > Thanks, Corey.
> > I also see it problematic, but I've been seeing other root programs
(i.e.
> > Spanish Government) enforcing this rule, so I'd like to understand if
> > it's a "best practice" or a rule, and, in particular, if it's rule to
> > be respected for TLS-oriented hierarchies.
> > P

[pfuen...@gmail.com]

OK. Thanks for your answers.

In summary, my understanding is that we can ignore that illustrative control of the Webtrust Criteria and that the community is cool with these subordinations of CAs with stronger keys (same or different algorithm).

Best,
Pedro

[Peter Bowen]

On Thu, Mar 11, 2021 at 12:01 AM pfuen...--- via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:
>
> In summary, my understanding is that we can ignore that illustrative control of the Webtrust Criteria and that the community is cool with these subordinations of CAs with stronger keys (same or different algorithm).

Illustrative controls in WebTrust are not the principles and criteria,
which are the requirements. Illustrative controls are just examples
of things that CAs _might_ choose to do. They might also choose to do
different things, which is fine as long as the things they do meet the
criteria.

As you read through the WebTrust Principles and Criteria for
Certification Authorities, you should also note that some principles
and some criteria are notated with "if supported" or "if applicable".
Not having controls that cover these is also usually fine, as long as
you disclose that you do not do them. For example, many CAs in the
Mozilla program do not issue Integrated Circuit Cards (also called
"smart cards"), so WebTrust for CAs criteria 5.3 is not applicable;
instead the management assertion can simply state that the CA does not
issue ICCs.

Thanks,
Peter