Am 10.04.2018 um 01:10 schrieb Wayne Thayer via dev-security-policy:
Getting back to the earlier question about email certificates, I am now of
the opinion that we should limit the scope of this policy update to TLS
certificates. The current language for email certificates isn't clear and
any attempt to fix it requires us to answer the bigger question of "under
what circumstances is CA key generation acceptable?"

My updated proposal is to add the following paragraphs to section 5.3
“Forbidden and Required Practices”:

CAs MUST not generate the key pairs for end-entity certificates, except for
email certificates with the Extended Key Usage extension present and set to

What about user certificates for logon/authentication? CN=John Doe, extendedKeyUsage=clientAuth? Is that different from email certificates?

Wouldn't it be better to make that a positive list to really limit the scope of the change?

CAs MUST NOT generate the key pairs for end-entity certificates the scope of the Baseline Requirements.


CAs MUST not distribute or transfer certificates in PKCS#12 form through
insecure electronic channels. If a PKCS#12 file is distributed via a
physical data storage device, then:
* The storage must be packaged in a way that the opening of the package
causes irrecoverable physical damage. (e.g. a security seal)
* The PKCS#12 file must have a sufficiently secure password, and the
password must not be transferred together with the storage.

Once again, I would appreciate your comments on this proposal.

- Wayne
dev-security-policy mailing list

Reply via email to