Re: Clarification request: ECC subCAs under RSA Root
On Thu, Mar 11, 2021 at 12:01 AM pfuen...--- via dev-security-policy 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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Clarification request: ECC subCAs under RSA Root
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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Clarification request: ECC subCAs under RSA Root
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 On > Behalf Of Ryan Sleevi via dev-security-policy > Sent: Wednesday, March 10, 2021 11:00 AM > To: pfuen...@gmail.com > Cc: Mozilla > 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
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-policy@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
Re: Clarification request: ECC subCAs under RSA Root
> 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
RE: Clarification request: ECC subCAs under RSA Root
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 -Original Message- From: dev-security-policy On Behalf Of pfuen...--- via dev-security-policy Sent: Wednesday, March 10, 2021 4:17 AM To: Mozilla Subject: Clarification request: ECC subCAs under RSA Root 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 ___ 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
