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-policy-boun...@lists.mozilla.org> On > Behalf Of Ryan Sleevi via dev-security-policy > Sent: Wednesday, March 10, 2021 11:00 AM > To: pfuen...@gmail.com <pfuente...@gmail.com> > Cc: Mozilla <mozilla-dev-security-pol...@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- > security-pol...@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 > > _______________________________________________ > > dev-security-policy mailing list > > dev-security-policy@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-security-policy > > > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
