Re: Policy 2.6 Proposal: Require separate intermediates for different usages (e.g. server auth, S/MIME)

2018-05-02 Thread Wayne Thayer via dev-security-policy
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,

RE: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

2018-05-02 Thread Tim Hollebeek via dev-security-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