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
> Behalf Of Ryan Sleevi via dev-security-policy
> Sent: Wednesday, March 10, 2021 11:00 AM
> To: 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
> practice/good practice.
> I appreciate the goal in the abstract - which is to say, don't do more
> necessary (e.g. having an RSA-4096 signed by RSA-2048 is wasting cycles
> there's no other reason for it), but as Corey points out, there are times
> 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-
> > > 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
> > >
> > Thanks, Corey.
> > I also see it problematic, but I've been seeing other root programs
> > 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