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
> id-kp-emailProtection.

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

On Mon, Apr 9, 2018 at 3:54 PM, Wayne Thayer <> wrote:

> On Thu, Apr 5, 2018 at 12:29 PM, Jakob Bohm via dev-security-policy <
>> wrote:
>> On 05/04/2018 18:55, Wayne Thayer wrote:
>>> On Thu, Apr 5, 2018 at 3:15 AM, Dimitris Zacharopoulos <
>>> >
>>> wrote:
>>> My proposal is "CAs MUST NOT distribute or transfer private keys and
>>>> associated certificates in PKCS#12 form through insecure physical or
>>>> electronic channels " and remove the rest.
>>>> +1 - I support this proposal.
>> But that removes the explicit exception for methods such as the
>> following *example* protocol (securing such a protocol is the job and
>> expertise of the affected CAs).
>> This is a valid point, so perhaps we should stick with the original
> language regarding distribution of PKCS12 files on physical storage devices.
> 1. Set the notBefore data in the new certificate several days or weeks
>>   into the future.
>> 2. Securely store the PKCS#12 or other private key format on a USB
>>   stick, USB token or smartcard.
>> 3. Place that device in a physically sealed envelope or package.
>> 4. Send it through regular postal mail (an insecure physical channel).
>> 5. Upon receiving the envelope/package, the subscriber must verify that
>>   the seal is unbroken and acknowledge that, through a secure electronic
>>   channel.  The procedure may/should include additional steps to verify
>>   that the sealed envelope/package is the same one sent.
>> 6. If this is not done before the certificate's notBefore date, the
>>   certificate is preemptively revoked due to private key compromise and
>>   issuance is retried with a new key.
>> Enjoy
>> Jakob
dev-security-policy mailing list

Reply via email to