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
> 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
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
Re: Mozilla's Response to Camerfirma's Compliance Issues
In my personal opinion, given that most of the actions for the remediation plan are expected to be completed during the first quarter of 2021, if the community considers that the plan adequately prevents further issues, it would be reasonable to establish a deadline to take such a decision based on the effective execution of the plan by the date of that deadline, demonstrated by means of an independent audit report. On the other hand, I'd like to understand if the option being in consideration is a partial distrust (i.e. eliminate the trust bits for serverAuth) or a total distrust. BR Pedro ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Mandatory reasonCode analysis
Hello, as we are in the "list of shame" and as a way to ensure we are following these discussions, I'd like to say that the OISTE CA that is referenced here (it's an old intermediate CA expiring in December 2020, and its CRL contains some unspecified revocations for Issuing CAs from 2015 and older) is under a root for which we already requested to remove the TLS trust bit to the different CA programs (e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=1653092), so now is out of the scope of BR. Best, Pedro ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
