Re: Policy 2.6 Proposal: Require separate intermediates for different usages (e.g. server auth, S/MIME)
Unless there is further discussion, I will consider this issue closed with the following change to section 5.3, meaning that it applies to both unconstrained and technically constrained intermediates: Subordinate CA certificates created after January 1, 2019: * MUST contain an EKU extension; and, * MUST NOT include the anyExtendedKeyUsage KeyPurposeId; and, * MUST NOT include both the id-kp-serverAuth and id-kp-emailProtection KeyPurposeIds in the same certificate. - Wayne On Mon, Apr 30, 2018 at 5:58 PM, pfuentes69--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > Maybe I'm too pragmatic, but from a risk management perspective, I don't > see a constrained CA issuing a poor certificate harming the whole > CA/Browser community, so I would even accept that risk. > > Anyway, as a conclusion, I see your point about this maybe being difficult > to manage in the real world, so I guess my request to consider the > exception for name constrained CAs is not as straightforward as it's in my > head. > > Cheers! > > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Policy 2.6 Proposal: Add prohibition on CA key generation to policy
> I'd recommend making a requirement that it be "protected" by at least as many > bits of strength as the key it protects. Not doing so could cause compliance > issues: things like PCI [1] and the NIST [2] recommendations require this type of > protection. You don't have compliance problems because my proposal is weaker than PCI and NIST (ANSI and ISO also have the same requirement). It focuses on RSA-2048 keys because those are what are prevalent in the industry. If your key is larger than 2048 bits, you can and should use more entropy in your password, and you have to if you need to comply with PCI/ANSI/ISO [1]. But that's ok because the requirement is >= 112, not exactly 112. > However, like Wayne said, this still leaves room for interpretation, if > mentioning bits is necessary, can we just bump it up to 256 rather than 112? 256 is overkill. People do have to type these passwords sometimes. 112 is the NIST-blessed strength of RSA-2048 [2]. That's why I think it's the right number. -Tim [1] I left out NIST because it isn't actually a standards body, it just provides guidance. [2] Yes, comparing symmetric and asymmetric strengths gets all applesy and orangey sometimes, but it's in the right ballpark, and it's a useful number since it's widely used and you can point to something to justify it. 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
