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

[Wayne Thayer]

This issue is titled “Make sure Forbidden practices are forbidden” - in
other words, make sure they are banned in our policy. The only forbidden
practice on our list [1] that’s not already covered by our policy is
“Distributing Generated Private Keys in PKCS#12 Files”. It reads:

CAs must never generate the key pairs for signer or SSL certificates. CAs
> may only generate the key pairs for SMIME certificates. Distribution or
> transfer of certificates in PKCS#12 form through unsecure electronic
> channels is not allowed. 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.
>

This practice was recently questioned [2] and generated lots of discussion
[3], with the conclusion being that our prohibition on this practice should
remain at least until a comprehensive plan for CA key generation is
presented and reviewed.

Given that background, please do not use this discussion thread to reopen
the debate on changing our policy on CA key generation. The scope here is
limited to the specifics of the existing requirements (e.g. the exception
for email encryption certificates), and moving them into policy.

I propose adding 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 encryption certificates meeting the following criteria:
> 1. The Extended Key Usage extension is present and set to
> id-kp-emailProtection; and,
> 2. The Key Usage extension is present and does not include either
> digitalSignature or nonRepudiation.
>

>
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.
>

I would appreciate everyone's input on this topic.

This is: https://github.com/mozilla/pkipolicy/issues/107

[1] https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices
[2]
https://groups.google.com/d/msg/mozilla.dev.security.policy/UnPOf5WIpXM/SbmSD5eCAgAJ
[3]
https://groups.google.com/d/msg/mozilla.dev.security.policy/MRd8gDwGGA4/AC4xgZ9CBgAJ

-------

This is a proposed update to Mozilla's root store policy for version
2.6. Please keep discussion in this group rather than on GitHub. Silence
is consent.

Policy 2.5 (current version):
https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md

[Ryan Hurst]

Some thoughts:

1 - Should additional text be included to mandate strong cipher suites (http://unmitigatedrisk.com/?p=543) be used; it is not uncommon for me to find PKCS#12s with very weak cryptographic algorithms in use. Such guidance would be limited by Windows which does not support modern cryptographic algorithms for key protection but having some standard would be better than none though it would potentially hurt interoperability for those use cases if the chosen suites were not uniform.

2 - Should additional text be included to mandate the that CA resellers cannot be used as an escape to this requirement; e.g. today A CA may simply rely on a third-party to implement this practice to stay in conformance with the policy.

3 - Should additional text be included to require that the user provide part or all of the secrete used as the "password" on the PKCS#12 file and that CA cannot store the user provided value?

[Wayne Thayer]

On Wed, Apr 4, 2018 at 3:15 PM, Ryan Hurst via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Some thoughts:
>
> 1 - Should additional text be included to mandate strong cipher suites (
> http://unmitigatedrisk.com/?p=543) be used; it is not uncommon for me to
> find PKCS#12s with very weak cryptographic algorithms in use. Such guidance
> would be limited by Windows which does not support modern cryptographic
> algorithms for key protection but having some standard would be better than
> none though it would potentially hurt interoperability for those use cases
> if the chosen suites were not uniform.
>

> Do we even need the section on PKCS12? It seems like an edge case to me.

2 - Should additional text be included to mandate the that CA resellers
> cannot be used as an escape to this requirement; e.g. today A CA may simply
> rely on a third-party to implement this practice to stay in conformance
> with the policy.
>

> I'm of the opinion, as expressed by others in the Trustico thread, that we
should not attempt to set policy for resellers. It would be quite difficult
to enforce, and as you pointed out in that thread, quite difficult to
distinguish a reseller that is also managing the certificate (e.g. a
hosting provider).

3 - Should additional text be included to require that the user provide
> part or all of the secrete used as the "password" on the PKCS#12 file and
> that CA cannot store the user provided value?

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Dimitris Zacharopoulos]

On 5/4/2018 12:26 πμ, Wayne Thayer via dev-security-policy wrote:
> 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.
>>
> I would appreciate everyone's input on this topic.
>
> This is:https://github.com/mozilla/pkipolicy/issues/107

I think the description for the PKCS#12 distribution via a physical data
storage device is overly prescriptive for a Policy document. I can think
of different ways to securely deliver such a file without needing the
first bullet. The intent of the policy is generally captured in the
first sentence "CAs MUST NOT distribute or transfer certificates in
PKCS#12 form through insecure electronic channels" and could include the
"physical" distribution by either removing the word "electronic" or by
adding the "physical" in the same sentence.

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.


Dimitris.

[Doug Beattie]

> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+doug.beattie=globals...@lists.mozilla.org] On Behalf Of Wayne
> Thayer via dev-security-policy
> Sent: Wednesday, April 4, 2018 5:26 PM
> To: mozilla-dev-security-policy <mozilla-dev-s...@lists.mozilla.org>
> Subject: Policy 2.6 Proposal: Add prohibition on CA key generation to policy
>
> I propose adding 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 encryption certificates meeting the following criteria:
> > 1. The Extended Key Usage extension is present and set to
> > id-kp-emailProtection; and, 2. The Key Usage extension is present and
> > does not include either digitalSignature or nonRepudiation.

I don’t think you should include #2 because it's a common practice to issue one certificate for Secure Mail that is used to both sign and encrypt, and this would preclude CA key generation for those types of certificates.

It's a fine line between what enterprises do and what they contract CAs to do. Based on this requirement, Enterprise customers can generate keys for any type of certificate but CAs are being specifically called out to be excluded from this. While CAs strive to provide a complete managed solution for their customers, this requirement prevents that from happening. Take for example a CA that has an appliance located in the enterprise. If that appliance generates keys, is that the "CA" generating the keys? It gets muddy.

I'd prefer that CAs be permitted to perform key generation for any certificate with an EKU of id-kp-emailProtection with key usage of keyEncipherment or dataEncipherment, but perhaps with an acknowledgement from the enterprise or end users that they acknowledge the fact the CA may have access to their private keys.

>
> >
> 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.
> >
>
> I would appreciate everyone's input on this topic.
>
> This is: https://github.com/mozilla/pkipolicy/issues/107
>

> [1] https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices
> [2]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/UnPOf5WIpXM/S
> bmSD5eCAgAJ
> [3]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/MRd8gDwGGA4/
> AC4xgZ9CBgAJ
>
> -------
>
> This is a proposed update to Mozilla's root store policy for version 2.6. Please
> keep discussion in this group rather than on GitHub. Silence is consent.
>
> Policy 2.5 (current version):
> https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md

[Wayne Thayer]

On Thu, Apr 5, 2018 at 3:15 AM, Dimitris Zacharopoulos <ji...@it.auth.gr>
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.

[Wayne Thayer]

On Thu, Apr 5, 2018 at 4:58 AM, Doug Beattie <doug.b...@globalsign.com>
wrote:

>
> I don’t think you should include #2 because it's a common practice to
> issue one certificate for Secure Mail that is used to both sign and
> encrypt, and this would preclude CA key generation for those types of
> certificates.
>

> I was attempting to match the existing "forbidden practice" requirement
that carves out an exception only for email encryption. I don't know why
that exception exists, but I do agree with you that it is uncommon for an
S/MIME certificate to support encryption but not signatures.

It's a fine line between what enterprises do and what they contract CAs to
> do. Based on this requirement, Enterprise customers can generate keys for
> any type of certificate but CAs are being specifically called out to be
> excluded from this. While CAs strive to provide a complete managed
> solution for their customers, this requirement prevents that from
> happening. Take for example a CA that has an appliance located in the
> enterprise. If that appliance generates keys, is that the "CA" generating
> the keys? It gets muddy.
>

> Good question. I'd argue that it depends on whether or not the system is
designed to permit the CA to access the private key.

I'd prefer that CAs be permitted to perform key generation for any
> certificate with an EKU of id-kp-emailProtection with key usage of
> keyEncipherment or dataEncipherment, but perhaps with an acknowledgement
> from the enterprise or end users that they acknowledge the fact the CA may
> have access to their private keys.
>

> If we go down this route, I think we should just exempt all email
certificates.

[Buschart, Rufus]

>> I don’t think you should include #2 because it's a common practice to
>> issue one certificate for Secure Mail that is used to both sign and
>> encrypt, and this would preclude CA key generation for those types of
>> certificates.
>>
>> I was attempting to match the existing "forbidden practice"
>> requirement
>that carves out an exception only for email encryption.
>I don't know why that exception exists, but I do agree with you that it is uncommon for an S/MIME certificate to support encryption but not signatures.

Actually it is very common: our CA has a couple of hundred thousand S/MIME certificates in the field, that are either for mail encryption or for mail signature but not for both. And I believe there are a lot of other enterprise CAs that do the same. There is a good reason for doing so: the private keys for both types of certificates are safely stored on our employees corporate ID smart card. But only the signature keys are also generated on the smart card. The encryption keys are generated centrally in the CA and then securely injected into the smart card. The reason for this split is, that we want to be absolutely sure, that the email signature is non-repudiationable by the holder of the card (as required by the European Unions eIDAS regulation for 'advanced electronic signature') but on the other hand side, we need to be able to perform a key escrow for the encryption keys, in case the card is damaged or lost or if there is court requirement to decrypt corporate emails and the holder of the card is not willing to do so.

Don't hesitate to contact me, if you want to know more, how it works in our case.

With best regards,
Rufus Buschart

Siemens AG
GS IT HR 7 4
Hugo-Junkers-Str. 9
90411 Nuernberg, Germany
Tel.: +49 1522 2894134
mailto:rufus.b...@siemens.com

www.siemens.com/ingenuityforlife

[Ryan Hurst]

On Thursday, April 5, 2018 at 9:55:39 AM UTC-7, Wayne Thayer wrote:
> On Thu, Apr 5, 2018 at 3:15 AM, Dimitris Zacharopoulos <r>

> 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.

That seems an appropriate level of detail for policy. +1

[Jakob Bohm]

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).

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
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

[Wayne Thayer]

On Thu, Apr 5, 2018 at 12:29 PM, Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On 05/04/2018 18:55, Wayne Thayer wrote:
>

> 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.

[Wayne Thayer]

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 <wth...@mozilla.com> wrote:

> On Thu, Apr 5, 2018 at 12:29 PM, Jakob Bohm via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
>> On 05/04/2018 18:55, Wayne Thayer wrote:
>>

[Doug Beattie]

Wayne: I agree with your latest proposal.

> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+doug.beattie=globals...@lists.mozilla.org] On Behalf Of Wayne
> Thayer via dev-security-policy
> Sent: Monday, April 9, 2018 7:10 PM
> To: mozilla-dev-security-policy <mozilla-dev-s...@lists.mozilla.org>

> >> 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
> >>
> >>
> >

[Jürgen Brauckmann]

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

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.
=====

Thanks,
Jürgen

[Wayne Thayer]

On Tue, Apr 10, 2018 at 7:22 AM, Jürgen Brauckmann via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

>
>
> 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
>>> id-kp-emailProtection.
>>>
>>
>
> What about user certificates for logon/authentication? CN=John Doe,
> extendedKeyUsage=clientAuth? Is that different from email certificates?
>

> Yes, but certificates with only the clientAuth EKU are out of scope
according to section 1.1 of the Mozilla policy

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

> Yes, I think so.

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

> But this is too vague. I propose that we add the following paragraphs to
section 5.2:

CAs MUST NOT generate the key pairs for end-entity certificates that have
> EKU extension containing the KeyPurposeIds id-kp-serverAuth or
> anyExtendedKeyUsage.
>

>
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.

Here it is on GitHub:
https://github.com/mozilla/pkipolicy/commit/456f869a15b6b9ca9be1df1897852b0c508932c7

Are there any concerns with this approach?

- Wayne

Thanks,
> Jürgen
>
>

[Buschart, Rufus]

I believe the wording "insecure electronic channels" leaves a lot of space for interpretation. In corporate PKIs for email encryption it is quite common to transfer centrally generated email encryption p12-files to mobile device management systems, email encryption gateways or directly to mobile devices using a wide variety of 'electronic channels'. From the proposed wording it doesn't seem to be clear which of those channels are 'insecure' and which not. Even if not that common, the same applies for email signature p12-files for e.g. email signature on mail gateways or mobile devices. Most of the mobile devices out in the field neither support hardware token, key-pair-generation in the mailer software nor installation of downloaded p12-files (prohibited by app sandboxing).

Maybe it would be possible to restrict the new wording to the EKU kp-ServerAuth first and have a detailed discussion about email-encryption and user authentication with more interested parties in the next months?

With best regards,
Rufus Buschart

Siemens AG
GS IT HR 7 4
Hugo-Junkers-Str. 9
90411 Nuernberg, Germany
Tel.: +49 1522 2894134
mailto:rufus.b...@siemens.com

www.siemens.com/ingenuityforlife

-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+rufus.buschart=sieme...@lists.mozilla.org] On Behalf Of Wayne Thayer via dev-security-policy
Sent: Dienstag, 17. April 2018 02:24
To: mozilla-dev-security-policy
Subject: Re: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

[Wayne Thayer]

On Tue, Apr 17, 2018 at 6:10 AM, Buschart, Rufus via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> I believe the wording "insecure electronic channels" leaves a lot of space
> for interpretation. In corporate PKIs for email encryption it is quite
> common to transfer centrally generated email encryption p12-files to mobile
> device management systems, email encryption gateways or directly to mobile
> devices using a wide variety of 'electronic channels'. From the proposed
> wording it doesn't seem to be clear which of those channels are 'insecure'
> and which not. Even if not that common, the same applies for email
> signature p12-files for e.g. email signature on mail gateways or mobile
> devices. Most of the mobile devices out in the field neither support
> hardware token, key-pair-generation in the mailer software nor installation
> of downloaded p12-files (prohibited by app sandboxing).
>
> Maybe it would be possible to restrict the new wording to the EKU
> kp-ServerAuth first and have a detailed discussion about email-encryption
> and user authentication with more interested parties in the next months?
>

Again, this is not new wording. It's already a requirement:
https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Distributing_Generated_Private_Keys_in_PKCS.2312_Files

Having said that, could we instead be more specific by replacing "insecure
electronic channels" with "unencrypted email"? Limiting the scope of this
statement to id-kp-serverAuth is meaningless since we forbid CA key
generation for server certificates.

- Wayne

[Buschart, Rufus]

For us at Siemens PKI this wording would work, because we establish a first channel for email encryption to every employee when he receives his corporate smart card / ID card. But I still think the community should have a broad discussion what is acceptable behavior for transmitting S/MIME P12s and what not. For example if the CA sends not the P12-file directly to the subject but a link to download the P12 via HTTPS from a server of the CA, the level of security is practically the same as sending the P12-file directly (in both cases the operator of the mail server can intercept the P12 file easily) but it would be an allowed practice.

/Rufus



Von: Wayne Thayer [mailto:wth...@mozilla.com]
Gesendet: Freitag, 20. April 2018 22:00
An: Buschart, Rufus (GS IT HR 7 4)
Cc: mozilla-dev-security-policy; Wichmann, Markus Peter (GS IT ISEC TE DI IS); Grotz, Florian (GS IT HR 7 4)
Betreff: Re: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

[Jakob Bohm]

That would allow unencrypted HTTP, unencrypted FTP, unencrypted TFTP
etc. etc. It would also allow 40 bit encrypted connections (they are
insecure but unencrypted). The list of insecure electronic channels is
infinite.

[Wayne Thayer]

On Wed, Apr 25, 2018 at 8:01 AM, Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On 20/04/2018 21:59, Wayne Thayer wrote:
>

> That would allow unencrypted HTTP, unencrypted FTP, unencrypted TFTP
> etc. etc. It would also allow 40 bit encrypted connections (they are
> insecure but unencrypted). The list of insecure electronic channels is
> infinite.
>

> The original intent appears to have been to forbid using email to transmit
PKCS#12 files because it includes the following bullet [1]:
* The distribution channels used (e.g. unencrypted email) may not be
adequately secured.

The original phrase "insecure electronic channels" does encompass more but
is also vague enough to be easily misinterpreted.

Perhaps the phrase "unencrypted electronic channels" is a better solution?
I would welcome other suggestions.

[1] https://wiki.mozilla.org/CA/Forbidden_or_Problematic_
Practices#Distributing_Generated_Private_Keys_in_PKCS.2312_Files

[Enrico Entschew]

I suggest to make the requirement „* The PKCS#12 file must have a sufficiently secure password, and the password must be transferred via a separate channel than the PKCS#12 file.” binding for both transfer methods and not be limited to physical data storage.
Otherwise I agree with this proposal.

Enrico

[Wayne Thayer]

> That seems like a good and reasonable change, resulting in the following
policy:

CAs MUST NOT generate the key pairs for end-entity certificates that have
EKU extension containing the KeyPurposeIds id-kp-serverAuth or
anyExtendedKeyUsage.

CAs MUST NOT distribute or transfer certificates in PKCS#12 form through
insecure electronic channels. The PKCS#12 file must have a sufficiently

secure password, and the password must not be transferred together with the

file. 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)

Unless other comments are made, I'll consider this to be the conclusion of
discussion on this topic.

Wayne

[Buschart, Rufus]

---=== Intern ===---
Hello!

I would like to suggest to rephrase the central sentence a little bit:

Original:

CAs MUST NOT distribute or transfer certificates in PKCS#12 form through insecure electronic channels. The PKCS#12 file must have a sufficiently secure password, and the password must not be transferred together with the file.

Proposal:

CAs SHOULD NOT distribute or transfer certificates in PKCS#12 form through insecure electronic channels. If the CA chooses to do so, the PKCS#12 file SHALL have a password containing at least 32 bit of output from a CSPRNG, and the password SHALL be transferred using a different channel as the PKCS#12 file.


My proposal would allow a CA to centrally generate a P12 file, send it to the Subject by unencrypted email and send the P12 pin as a SMS or Threema message. This is an important use case if you want to have email encryption on a mobile device that is not managed by a mobile device management system. Additionally I made the wording a little bit more rfc2119-ish and made clear, what defines a 'sufficiently secure password' as the original wording lets a lot of room for 'interpretation'.

What do you think?

/Rufus


Siemens AG
Information Technology
Human Resources
PKI / Trustcenter

GS IT HR 7 4
Hugo-Junkers-Str. 9
90411 Nuernberg, Germany
Tel.: +49 1522 2894134
mailto:rufus.b...@siemens.com

www.twitter.com/siemens

www.siemens.com/ingenuityforlife

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike, Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322

> -----Ursprüngliche Nachricht-----
> Von: dev-security-policy
> [mailto:dev-security-policy-bounces+rufus.buschart=siemens.com@lists.m
> ozilla.org] Im Auftrag von Wayne Thayer via dev-security-policy
> Gesendet: Freitag, 27. April 2018 19:30
> An: Enrico Entschew
> Cc: mozilla-dev-security-policy

> Betreff: Re: Policy 2.6 Proposal: Add prohibition on CA key generation
> to policy
>

> On Fri, Apr 27, 2018 at 6:40 AM, Enrico Entschew via dev-security-policy < dev-secur...@lists.mozilla.org> wrote:
>
> > I suggest to make the requirement „* The PKCS#12 file must have a
> > sufficiently secure password, and the password must be transferred
> > via a separate channel than the PKCS#12 file.” binding for both
> > transfer methods and not be limited to physical data storage.
> > Otherwise I agree with this proposal.
> >
> > Enrico
> >
> > That seems like a good and reasonable change, resulting in the
> > following
> policy:
>
> CAs MUST NOT generate the key pairs for end-entity certificates that
> have EKU extension containing the KeyPurposeIds id-kp- serverAuth or anyExtendedKeyUsage.
>

> CAs MUST NOT distribute or transfer certificates in PKCS#12 form
> through insecure electronic channels. The PKCS#12 file must have a

> sufficiently secure password, and the password must not be transferred

> together with the file. 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)
>

> Unless other comments are made, I'll consider this to be the conclusion of discussion on this topic.
>
> Wayne

[Enrico Entschew]

Am Montag, 30. April 2018 08:25:39 UTC+2 schrieb Buschart, Rufus:
> ---=== Intern ===---
> Hello!
>
> I would like to suggest to rephrase the central sentence a little bit:
>
> Original:
>
> CAs MUST NOT distribute or transfer certificates in PKCS#12 form through insecure electronic channels. The PKCS#12 file must have a sufficiently secure password, and the password must not be transferred together with the file.
>
> Proposal:
>
> CAs SHOULD NOT distribute or transfer certificates in PKCS#12 form through insecure electronic channels. If the CA chooses to do so, the PKCS#12 file SHALL have a password containing at least 32 bit of output from a CSPRNG, and the password SHALL be transferred using a different channel as the PKCS#12 file.
>
>
> My proposal would allow a CA to centrally generate a P12 file, send it to the Subject by unencrypted email and send the P12 pin as a SMS or Threema message. This is an important use case if you want to have email encryption on a mobile device that is not managed by a mobile device management system. Additionally I made the wording a little bit more rfc2119-ish and made clear, what defines a 'sufficiently secure password' as the original wording lets a lot of room for 'interpretation'.
>
> What do you think?
>
> /Rufus
>
>

Absolutely understandable and meaningful. I support this change.
Enrico

[Tim Hollebeek]

32 bits is rather ... low.

> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-

> bounces+tim.hollebeek=digice...@lists.mozilla.org] On Behalf Of Buschart,
> Rufus via dev-security-policy
> Sent: Monday, April 30, 2018 2:25 AM
> To: mozilla-dev-security-policy <mozilla-dev-s...@lists.mozilla.org>
> Cc: Wichmann, Markus Peter <markus....@siemens.com>; Enrico
> Entschew <enr...@entschew.com>; Grotz, Florian
> <floria...@siemens.com>; Heusler, Juergen
> <juergen...@siemens.com>; Wayne Thayer <wth...@mozilla.com>
> Subject: AW: Policy 2.6 Proposal: Add prohibition on CA key generation to
> policy
>

> ---=== Intern ===---
> Hello!
>
> I would like to suggest to rephrase the central sentence a little bit:
>
> Original:
>
> CAs MUST NOT distribute or transfer certificates in PKCS#12 form through
> insecure electronic channels. The PKCS#12 file must have a sufficiently secure
> password, and the password must not be transferred together with the file.
>
> Proposal:
>
> CAs SHOULD NOT distribute or transfer certificates in PKCS#12 form through
> insecure electronic channels. If the CA chooses to do so, the PKCS#12 file SHALL
> have a password containing at least 32 bit of output from a CSPRNG, and the
> password SHALL be transferred using a different channel as the PKCS#12 file.
>
>
> My proposal would allow a CA to centrally generate a P12 file, send it to the
> Subject by unencrypted email and send the P12 pin as a SMS or Threema
> message. This is an important use case if you want to have email encryption on
> a mobile device that is not managed by a mobile device management system.
> Additionally I made the wording a little bit more rfc2119-ish and made clear,
> what defines a 'sufficiently secure password' as the original wording lets a lot
> of room for 'interpretation'.
>
> What do you think?
>
> /Rufus
>
>

> > CAs MUST NOT distribute or transfer certificates in PKCS#12 form
> > through insecure electronic channels. The PKCS#12 file must have a

> > sufficiently secure password, and the password must not be transferred

> > together with the file. 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)
> >

> > Unless other comments are made, I'll consider this to be the conclusion of
> discussion on this topic.
> >
> > Wayne
> > _______________________________________________
> > dev-security-policy mailing list
> > dev-secur...@lists.mozilla.org
> >

> https://clicktime.symantec.com/a/1/HUkfAMaSNDzueZ8VpAI5fwA5As67iQ8caf
> D
> >
> WBr1uThY=?d=ckuHENZYbUJhkHaGquLNZOFaRZP9Zc8e3rxXzIneBrhS9PY6Y5iu
> qxaNSQ
> > CO7umlrvB6qtPvWhKg1hOt-
> 2VGAgBHkdp7nRO9u6gGSrCiQ5v77xypwOc0krIjNpHe3P_8
> > K4fNqBkxtFgHPPRsjnUrWo6Nfut4RREp2XdN4JmAN5a0_Cq-
> KD_3YVYUsmlED3KJBAPwUX
> >
> iunRGjvX_UO6wuk621g6OXR1oeHDV_bXTgF86SIyOLmLgkGFvIqEapcu7fJ586Bw
> XR1uCV
> > 8gq0HQREMlTc_HMD1E4L5sm7g1-GWjLMQdOIJJNK88wXlBK2yuCTd_0K-
> 7Qbvt8DWKSQME
> > NFnvkl5pb6pw6nhSUCEndZT2W45FaXBUVA4HO_-WtnzmCGQavYymFv-
> xnwBMawaicOyUGr
> > FGM3wkQ5QEkKG4HuCXwzqFi-
> 2XstRmiDm9CeSmhFrNoq1pFlsgL0sV8eqyVTAToo95agOr
> > viwOY0FWxUtqdwtZpEaa0-
> Npt_i4xVUnObY1uVKBclNwXtcDnDVHLC2A%3D%3D&u=https
> > %3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org

> https://clicktime.symantec.com/a/1/HUkfAMaSNDzueZ8VpAI5fwA5As67iQ8caf
> DWBr1uThY=?d=ckuHENZYbUJhkHaGquLNZOFaRZP9Zc8e3rxXzIneBrhS9PY6Y5i
> uqxaNSQCO7umlrvB6qtPvWhKg1hOt-
> 2VGAgBHkdp7nRO9u6gGSrCiQ5v77xypwOc0krIjNpHe3P_8K4fNqBkxtFgHPPRsj
> nUrWo6Nfut4RREp2XdN4JmAN5a0_Cq-
> KD_3YVYUsmlED3KJBAPwUXiunRGjvX_UO6wuk621g6OXR1oeHDV_bXTgF86SIy
> OLmLgkGFvIqEapcu7fJ586BwXR1uCV8gq0HQREMlTc_HMD1E4L5sm7g1-
> GWjLMQdOIJJNK88wXlBK2yuCTd_0K-
> 7Qbvt8DWKSQMENFnvkl5pb6pw6nhSUCEndZT2W45FaXBUVA4HO_-
> WtnzmCGQavYymFv-xnwBMawaicOyUGrFGM3wkQ5QEkKG4HuCXwzqFi-
> 2XstRmiDm9CeSmhFrNoq1pFlsgL0sV8eqyVTAToo95agOrviwOY0FWxUtqdwtZp
> Eaa0-
> Npt_i4xVUnObY1uVKBclNwXtcDnDVHLC2A%3D%3D&u=https%3A%2F%2Flists.
> mozilla.org%2Flistinfo%2Fdev-security-policy

[Doug Beattie]

I agree we need to tighten up Wayne's initial proposal a little.

-----
Initial proposal (Wayne):

CAs MUST NOT distribute or transfer certificates in PKCS#12 form through insecure electronic channels. The PKCS#12 file must have a sufficiently secure password, and the password must not be transferred together with the file. 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)

-----
Proposal #1 (Rufus):

CAs SHOULD NOT distribute or transfer certificates in PKCS#12 form through insecure electronic channels. If the CA chooses to do so, the PKCS#12 file SHALL have a password containing at least 32 bit of output from a CSPRNG, and the password SHALL be transferred using a different channel as the PKCS#12 file.

----
Proposal #2 (Doug)

If the PKCS#12 is distributed thought an insecure electronic channel then the PKCS#12 file SHALL have a password containing at least 32 bit of entropy and the PKCS#12 file and the password SHALL be transferred using a different channels.

If the PKCS#12 is distributed through a secure electronic channel, then... <If secure channels are used are there are any requirements on the strength of the password or the use of multiple distribution channels? Can you send both the P12 and password in a secure S/MIME email or a user can view/download both in the same session from a website? We should be clear.>

If a PKCS#12 file is distributed via a non-secure physical data storage device <need definition>, then
a) the storage must be packaged in a way that the opening of the package causes irrecoverable physical damage. (e.g. a security seal), or
b) the PKCS#12 must have a password of at least 32 bits of entropy and the password must be sent via separate channel.

----
Comments:

1) The discussions to date have not addressed the use of secure channels on the quality of the password, nor on the use of multiple channels. What is the intent? We should specify that so it's clear.

2) I think the use of CSPRNG is overkill for this application. Can we leave this at a certain entropy level?

3) The tamper requirement would only seem applicable if the P12 wasn't protected well (via strong P12 password on USB storage or via "good" PIN on a suitably secure crypto token).

> > CAs MUST NOT distribute or transfer certificates in PKCS#12 form
> > through insecure electronic channels. The PKCS#12 file must have a

> > sufficiently secure password, and the password must not be transferred

> > together with the file. 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)
> >

> > Unless other comments are made, I'll consider this to be the conclusion of
> discussion on this topic.
> >
> > Wayne
> > _______________________________________________
> > dev-security-policy mailing list
> > dev-secur...@lists.mozilla.org

> > https://lists.mozilla.org/listinfo/dev-security-policy

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org

> https://lists.mozilla.org/listinfo/dev-security-policy

[Tim Hollebeek]

Once again, CSPRNGs are not overkill. They are widely available in virtually every
programming language in existence these days. I have never understood why
there is so much pushback against something that often appears near the top of
many top ten lists about basic principles for secure coding.

Also, while I'm responding, and since it got copied into your proposal, 32 bits is
still way too small.

"irrecoverable physical damage" ? You want to go beyond tamper evident,
and even tamper responsive, and require self-destruction on tamper??
I personally think we probably want to get out of the area of writing
requirements about physical distribution. They're VERY hard to get right.

-Tim

> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+tim.hollebeek=digice...@lists.mozilla.org] On Behalf Of Doug
> Beattie via dev-security-policy
> Sent: Monday, April 30, 2018 1:06 PM
> To: Buschart, Rufus <rufus.b...@siemens.com>; mozilla-dev-security-
> policy <mozilla-dev-s...@lists.mozilla.org>
> Cc: Wichmann, Markus Peter <markus....@siemens.com>; Enrico
> Entschew <enr...@entschew.com>; Grotz, Florian
> <floria...@siemens.com>; Heusler, Juergen
> <juergen...@siemens.com>; Wayne Thayer <wth...@mozilla.com>

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

>
>
> I agree we need to tighten up Wayne's initial proposal a little.
>
> -----
> Initial proposal (Wayne):
>

> CAs MUST NOT distribute or transfer certificates in PKCS#12 form through
> insecure electronic channels. The PKCS#12 file must have a sufficiently secure
> password, and the password must not be transferred together with the file. 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)
>

> > CAs MUST NOT distribute or transfer certificates in PKCS#12 form
> > through insecure electronic channels. The PKCS#12 file must have a

> > sufficiently secure password, and the password must not be transferred

> > > CAs MUST NOT distribute or transfer certificates in PKCS#12 form
> > > through insecure electronic channels. The PKCS#12 file must have a

> > > sufficiently secure password, and the password must not be

> > > transferred together with the file. 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)
> > >

[Wayne Thayer]

The current policy seems inconsistent on the trust placed in passwords to
protect PKCS#12 files. On one hand, it forbids transmission via insecure
electronic channels regardless of password protection. But it goes on to
permit transmission of PKCS#12 files on a storage device as long as a
"sufficiently strong" password is delivered via a different means. If we
trust PKCS#12 encryption with a strong password (it's not clear that we
should [1]), then the policy could be:

PKCS#12 files SHALL have a password containing at least 64 bits of output

from a CSPRNG, and the password SHALL be transferred using a different

channel than the PKCS#12 file.

This eliminates the need for separate rules pertaining to physical storage
devices.

Is there a good reason to allow transmission of PKCS#12 files with weak/no
passwords over "secure" channels?

[1] http://unmitigatedrisk.com/?p=543

On Mon, Apr 30, 2018 at 10:46 AM, Tim Hollebeek <tim.ho...@digicert.com>
wrote:

> Once again, CSPRNGs are not overkill. They are widely available in
> virtually every
> programming language in existence these days. I have never understood why
> there is so much pushback against something that often appears near the
> top of
> many top ten lists about basic principles for secure coding.
>
> Also, while I'm responding, and since it got copied into your proposal, 32
> bits is
> still way too small.
>
> "irrecoverable physical damage" ? You want to go beyond tamper evident,
> and even tamper responsive, and require self-destruction on tamper??
> I personally think we probably want to get out of the area of writing
> requirements about physical distribution. They're VERY hard to get right.
>

> That is copied from the current policy, and while it's confusing I believe
it just means 'tamper evident'.

-Tim
>
> > -----Original Message-----
> > From: dev-security-policy [mailto:dev-security-policy-
> > bounces+tim.hollebeek=digice...@lists.mozilla.org] On Behalf Of Doug
> > Beattie via dev-security-policy
> > Sent: Monday, April 30, 2018 1:06 PM
> > To: Buschart, Rufus <rufus.b...@siemens.com>; mozilla-dev-security-
> > policy <mozilla-dev-s...@lists.mozilla.org>
> > Cc: Wichmann, Markus Peter <markus....@siemens.com>; Enrico
> > Entschew <enr...@entschew.com>; Grotz, Florian
> > <floria...@siemens.com>; Heusler, Juergen
> > <juergen...@siemens.com>; Wayne Thayer <wth...@mozilla.com>
> > Subject: RE: Policy 2.6 Proposal: Add prohibition on CA key generation
> to policy
> >
> >
> > I agree we need to tighten up Wayne's initial proposal a little.
> >
> > -----
> > Initial proposal (Wayne):
> >

> > CAs MUST NOT distribute or transfer certificates in PKCS#12 form through
> > insecure electronic channels. The PKCS#12 file must have a sufficiently

> secure
> > password, and the password must not be transferred together with the

> file. 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)
> >

> > -----
> > Proposal #1 (Rufus):
> >
> > CAs SHOULD NOT distribute or transfer certificates in PKCS#12 form
> through

> > > CAs MUST NOT distribute or transfer certificates in PKCS#12 form
> > > through insecure electronic channels. The PKCS#12 file must have a

> > > sufficiently secure password, and the password must not be transferred

> > > > CAs MUST NOT distribute or transfer certificates in PKCS#12 form
> > > > through insecure electronic channels. The PKCS#12 file must have a

> > > > sufficiently secure password, and the password must not be

> > > > transferred together with the file. 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)
> > > >

[Tim Hollebeek]

OOB passwords are generally tough to integrate into automation, and if the channel really is “secure” then they might not be buying you anything, depending where the “secure” channel starts and ends and how it is authenticated.



That might not be a GOOD reason to allow it, but it is the one reason that comes to mind. Taking the other side, I’d argue that it’s unlikely that the “secure” channel stretches unbroken from the site of key generation to the key loading/usage site. And it’s possible that “secure” is being used incorrectly, and the channel is encrypted but not authenticated. In that case, having a strong password does help for at least a portion of the transmission.



-Tim

From: Wayne Thayer [mailto:wth...@mozilla.com]
Sent: Monday, April 30, 2018 2:25 PM
To: Tim Hollebeek <tim.ho...@digicert.com>
Cc: Doug Beattie <doug.b...@globalsign.com>; Buschart, Rufus <rufus.b...@siemens.com>; mozilla-dev-security-policy <mozilla-dev-s...@lists.mozilla.org>; Wichmann, Markus Peter <markus....@siemens.com>; Enrico Entschew <enr...@entschew.com>; Grotz, Florian <floria...@siemens.com>; Heusler, Juergen <juergen...@siemens.com>
Subject: Re: Policy 2.6 Proposal: Add prohibition on CA key generation to policy



The current policy seems inconsistent on the trust placed in passwords to protect PKCS#12 files. On one hand, it forbids transmission via insecure electronic channels regardless of password protection. But it goes on to permit transmission of PKCS#12 files on a storage device as long as a "sufficiently strong" password is delivered via a different means. If we trust PKCS#12 encryption with a strong password (it's not clear that we should [1]), then the policy could be:



PKCS#12 files SHALL have a password containing at least 64 bits of output from a CSPRNG, and the password SHALL be transferred using a different channel than the PKCS#12 file.



This eliminates the need for separate rules pertaining to physical storage devices.



Is there a good reason to allow transmission of PKCS#12 files with weak/no passwords over "secure" channels?



[1] http://unmitigatedrisk.com/?p=543

On Mon, Apr 30, 2018 at 10:46 AM, Tim Hollebeek <tim.ho...@digicert.com <mailto:tim.ho...@digicert.com> > wrote:

Once again, CSPRNGs are not overkill. They are widely available in virtually every
programming language in existence these days. I have never understood why
there is so much pushback against something that often appears near the top of
many top ten lists about basic principles for secure coding.

Also, while I'm responding, and since it got copied into your proposal, 32 bits is
still way too small.

"irrecoverable physical damage" ? You want to go beyond tamper evident,
and even tamper responsive, and require self-destruction on tamper??
I personally think we probably want to get out of the area of writing
requirements about physical distribution. They're VERY hard to get right.

That is copied from the current policy, and while it's confusing I believe it just means 'tamper evident'.



-Tim

> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy- <mailto:dev-security-policy->
> bounces+tim.hollebeek=digice...@lists.mozilla.org <mailto:digice...@lists.mozilla.org> ] On Behalf Of Doug
> Beattie via dev-security-policy
> Sent: Monday, April 30, 2018 1:06 PM

> To: Buschart, Rufus <rufus.b...@siemens.com <mailto:rufus.b...@siemens.com> >; mozilla-dev-security-
> policy <mozilla-dev-s...@lists.mozilla.org <mailto:mozilla-dev-s...@lists.mozilla.org> >
> Cc: Wichmann, Markus Peter <markus....@siemens.com <mailto:markus....@siemens.com> >; Enrico
> Entschew <enr...@entschew.com <mailto:enr...@entschew.com> >; Grotz, Florian
> <floria...@siemens.com <mailto:floria...@siemens.com> >; Heusler, Juergen
> <juergen...@siemens.com <mailto:juergen...@siemens.com> >; Wayne Thayer <wth...@mozilla.com <mailto:wth...@mozilla.com> >

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

>
>
> I agree we need to tighten up Wayne's initial proposal a little.
>
> -----
> Initial proposal (Wayne):
>

> CAs MUST NOT distribute or transfer certificates in PKCS#12 form through
> insecure electronic channels. The PKCS#12 file must have a sufficiently secure
> password, and the password must not be transferred together with the file. 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)
>

> > CAs MUST NOT distribute or transfer certificates in PKCS#12 form
> > through insecure electronic channels. The PKCS#12 file must have a

> > sufficiently secure password, and the password must not be transferred

> > mailto:rufus.b...@siemens.com <mailto:rufus.b...@siemens.com>
> > www.twitter.com/siemens <http://www.twitter.com/siemens>
> >
> > www.siemens.com/ingenuityforlife <http://www.siemens.com/ingenuityforlife>

> >
> > Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim
> > Hagemann Snabe; Managing Board: Joe Kaeser, Chairman, President and
> > Chief Executive Officer; Roland Busch, Lisa Davis, Klaus Helmrich,
> > Janina Kugel, Cedrik Neike, Michael Sen, Ralf P. Thomas; Registered
> > offices: Berlin and Munich, Germany; Commercial registries: Berlin
> > Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322
> >
> > > -----Ursprüngliche Nachricht-----
> > > Von: dev-security-policy

> > > [mailto:dev-security-policy-bounces+rufus.buschart <mailto:dev-security-policy-bounces%2Brufus.buschart> =siemens.com@lists

> > > .m ozilla.org <http://ozilla.org> ] Im Auftrag von Wayne Thayer via dev-security-policy

> > > Gesendet: Freitag, 27. April 2018 19:30
> > > An: Enrico Entschew
> > > Cc: mozilla-dev-security-policy
> > > Betreff: Re: Policy 2.6 Proposal: Add prohibition on CA key
> > > generation to policy
> > >
> > > On Fri, Apr 27, 2018 at 6:40 AM, Enrico Entschew via
> > > dev-security-policy <

> > dev-secur...@lists.mozilla.org <mailto:dev-secur...@lists.mozilla.org> > wrote:
> > >
> > > > I suggest to make the requirement „* The PKCS#12 file must have a
> > > > sufficiently secure password, and the password must be transferred
> > > > via a separate channel than the PKCS#12 file.” binding for both
> > > > transfer methods and not be limited to physical data storage.
> > > > Otherwise I agree with this proposal.
> > > >
> > > > Enrico
> > > >
> > > > That seems like a good and reasonable change, resulting in the
> > > > following
> > > policy:
> > >
> > > CAs MUST NOT generate the key pairs for end-entity certificates that
> > > have EKU extension containing the KeyPurposeIds id-kp- serverAuth or
> > anyExtendedKeyUsage.
> > >

> > > CAs MUST NOT distribute or transfer certificates in PKCS#12 form
> > > through insecure electronic channels. The PKCS#12 file must have a

> > > sufficiently secure password, and the password must not be

> > > transferred together with the file. 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)
> > >

[Doug Beattie]

We should allow someone to obtain/view the P12 password and to download the P12 over an authenticated web site (managed portal), and that seems to be precluded by the definition below.

Doug

From: Tim Hollebeek [mailto:tim.ho...@digicert.com]
Sent: Monday, April 30, 2018 3:05 PM
To: Wayne Thayer <wth...@mozilla.com>
Cc: Doug Beattie <doug.b...@globalsign.com>; Buschart, Rufus <rufus.b...@siemens.com>; mozilla-dev-security-policy <mozilla-dev-s...@lists.mozilla.org>; Wichmann, Markus Peter <markus....@siemens.com>; Enrico Entschew <enr...@entschew.com>; Grotz, Florian <floria...@siemens.com>; Heusler, Juergen <juergen...@siemens.com>
Subject: RE: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

OOB passwords are generally tough to integrate into automation, and if the channel really is “secure” then they might not be buying you anything, depending where the “secure” channel starts and ends and how it is authenticated.

That might not be a GOOD reason to allow it, but it is the one reason that comes to mind. Taking the other side, I’d argue that it’s unlikely that the “secure” channel stretches unbroken from the site of key generation to the key loading/usage site. And it’s possible that “secure” is being used incorrectly, and the channel is encrypted but not authenticated. In that case, having a strong password does help for at least a portion of the transmission.

-Tim

From: Wayne Thayer [mailto:wth...@mozilla.com]
Sent: Monday, April 30, 2018 2:25 PM
To: Tim Hollebeek <tim.ho...@digicert.com>
Cc: Doug Beattie <doug.b...@globalsign.com>; Buschart, Rufus <rufus.b...@siemens.com>; mozilla-dev-security-policy <mozilla-dev-s...@lists.mozilla.org>; Wichmann, Markus Peter <markus....@siemens.com>; Enrico Entschew <enr...@entschew.com>; Grotz, Florian <floria...@siemens.com>; Heusler, Juergen <juergen...@siemens.com>
Subject: Re: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

The current policy seems inconsistent on the trust placed in passwords to protect PKCS#12 files. On one hand, it forbids transmission via insecure electronic channels regardless of password protection. But it goes on to permit transmission of PKCS#12 files on a storage device as long as a "sufficiently strong" password is delivered via a different means. If we trust PKCS#12 encryption with a strong password (it's not clear that we should [1]), then the policy could be:

PKCS#12 files SHALL have a password containing at least 64 bits of output from a CSPRNG, and the password SHALL be transferred using a different channel than the PKCS#12 file.

This eliminates the need for separate rules pertaining to physical storage devices.

Is there a good reason to allow transmission of PKCS#12 files with weak/no passwords over "secure" channels?

[1] http://unmitigatedrisk.com/?p=543

On Mon, Apr 30, 2018 at 10:46 AM, Tim Hollebeek <mailto:tim.ho...@digicert.com> wrote:
Once again, CSPRNGs are not overkill. They are widely available in virtually every
programming language in existence these days. I have never understood why
there is so much pushback against something that often appears near the top of
many top ten lists about basic principles for secure coding.

Also, while I'm responding, and since it got copied into your proposal, 32 bits is
still way too small.

"irrecoverable physical damage" ? You want to go beyond tamper evident,
and even tamper responsive, and require self-destruction on tamper??
I personally think we probably want to get out of the area of writing
requirements about physical distribution. They're VERY hard to get right.
That is copied from the current policy, and while it's confusing I believe it just means 'tamper evident'.

-Tim

> -----Original Message-----
> From: dev-security-policy [mailto:mailto:dev-security-policy-
> bounces+tim.hollebeek=mailto:digice...@lists.mozilla.org] On Behalf Of Doug
> Beattie via dev-security-policy
> Sent: Monday, April 30, 2018 1:06 PM

> To: Buschart, Rufus <mailto:rufus.b...@siemens.com>; mozilla-dev-security-
> policy <mailto:mozilla-dev-s...@lists.mozilla.org>
> Cc: Wichmann, Markus Peter <mailto:markus....@siemens.com>; Enrico
> Entschew <mailto:enr...@entschew.com>; Grotz, Florian
> <mailto:floria...@siemens.com>; Heusler, Juergen
> <mailto:juergen...@siemens.com>; Wayne Thayer <mailto:wth...@mozilla.com>

> Subject: RE: Policy 2.6 Proposal: Add prohibition on CA key generation to policy
>
>
> I agree we need to tighten up Wayne's initial proposal a little.
>
> -----
> Initial proposal (Wayne):
>

> CAs MUST NOT distribute or transfer certificates in PKCS#12 form through
> insecure electronic channels. The PKCS#12 file must have a sufficiently secure
> password, and the password must not be transferred together with the file. 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)
>

> > CAs MUST NOT distribute or transfer certificates in PKCS#12 form
> > through insecure electronic channels. The PKCS#12 file must have a

> > sufficiently secure password, and the password must not be transferred

> > mailto:mailto:rufus.b...@siemens.com
> > http://www.twitter.com/siemens

> >
> > http://www.siemens.com/ingenuityforlife
> >
> > Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim
> > Hagemann Snabe; Managing Board: Joe Kaeser, Chairman, President and
> > Chief Executive Officer; Roland Busch, Lisa Davis, Klaus Helmrich,
> > Janina Kugel, Cedrik Neike, Michael Sen, Ralf P. Thomas; Registered
> > offices: Berlin and Munich, Germany; Commercial registries: Berlin
> > Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322
> >
> > > -----Ursprüngliche Nachricht-----
> > > Von: dev-security-policy

> > > [mailto:mailto:dev-security-policy-bounces%2Brufus.buschart=siemens.com@lists
> > > .m http://ozilla.org] Im Auftrag von Wayne Thayer via dev-security-policy

> > > Gesendet: Freitag, 27. April 2018 19:30
> > > An: Enrico Entschew
> > > Cc: mozilla-dev-security-policy
> > > Betreff: Re: Policy 2.6 Proposal: Add prohibition on CA key
> > > generation to policy
> > >
> > > On Fri, Apr 27, 2018 at 6:40 AM, Enrico Entschew via
> > > dev-security-policy <

> > mailto:dev-secur...@lists.mozilla.org> wrote:
> > >
> > > > I suggest to make the requirement „* The PKCS#12 file must have a
> > > > sufficiently secure password, and the password must be transferred
> > > > via a separate channel than the PKCS#12 file.” binding for both
> > > > transfer methods and not be limited to physical data storage.
> > > > Otherwise I agree with this proposal.
> > > >
> > > > Enrico
> > > >
> > > > That seems like a good and reasonable change, resulting in the
> > > > following
> > > policy:
> > >
> > > CAs MUST NOT generate the key pairs for end-entity certificates that
> > > have EKU extension containing the KeyPurposeIds id-kp- serverAuth or
> > anyExtendedKeyUsage.
> > >

> > > CAs MUST NOT distribute or transfer certificates in PKCS#12 form
> > > through insecure electronic channels. The PKCS#12 file must have a

> > > sufficiently secure password, and the password must not be

> > > transferred together with the file. 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)
> > >

[Ryan Hurst]

A few problems I see with the proposed text:

- What is sufficient? I would go with a definition tied to the effective strength of the keys it protects; in other words, you should protect a 2048bit RSA key with something that offers similar properties or that 2048bit key does not live up to its 2048 bit properties. This is basically the same CSPRNG conversation but it's worth looking at https://www.keylength.com/
- The language should recommend that the "password" be a value that is a mix of a user-supplied value and the CSPRNG output and that the CA can not store the user-supplied value for longer than necessary to create the PKCS#12.
- The strength of the password is discussed but PKCS#12 supports a bunch of weak cipher suites and it is common to find them in use in PKCS#12s. The minimum should be specified to be what Microsoft supports which is pbeWithSHAAnd3-KeyTripleDES-CBC for “privacy” of keys and for the privacy of certificates it uses pbeWithSHAAnd40BitRC2-CBC.
- The language requires the use of a password when using PKCS#12s but PKCS#12 supports both symmetric and asymmetric key based protection also. While these are not broadly supported the text should not probit the use of stronger mechanisms than 3DES and a password.

Ryan

[Ryan Hurst]

> I'm not sure I agree with this as a recommendation; if you want both
parties
> to provide inputs to the generation of the password, use a
well-established
> and vetted key agreement scheme instead of ad hoc mixing.

> Of course, at that point you have a shared transport key, and you should
> probably
> just use a stronger, more modern authenticated key block than PKCS#12,
> but that's a conversation for another day.

I say this because it is desirable that the CA plausibly not be able to
decrypt the key even if it holds the encrypted key blob.



On Tue, May 1, 2018 at 12:40 PM, Tim Hollebeek <tim.ho...@digicert.com>
wrote:

>
> > - What is sufficient? I would go with a definition tied to the effective
> > strength of
> > the keys it protects; in other words, you should protect a 2048bit RSA
> key
> > with
> > something that offers similar properties or that 2048bit key does not
> live
> > up to
> > its 2048 bit properties.
>

> Yup, this is the typical position of standards bodies for crypto stuff. I
> noticed that
> the 32 got fixed to 64, but it really should be 112.

>
> > - The language should recommend that the "password" be a value that is a
> mix
> > of a user-supplied value and the CSPRNG output and that the CA can not
> store
> > the user-supplied value for longer than necessary to create the PKCS#12.
>

> I'm not sure I agree with this as a recommendation; if you want both
> parties
> to provide inputs to the generation of the password, use a well-established
> and vetted key agreement scheme instead of ad hoc mixing.
>
> Of course, at that point you have a shared transport key, and you should
> probably
> just use a stronger, more modern authenticated key block than PKCS#12,
> but that's a conversation for another day.

>
> > - The language requires the use of a password when using PKCS#12s but
> > PKCS#12 supports both symmetric and asymmetric key based protection also.
> > While these are not broadly supported the text should not probit the use
> of
> > stronger mechanisms than 3DES and a password.
>

> Strongly agree.
>
> -Tim
>

[Tim Hollebeek]

I get that, but any CA that can securely erase and forget the user’s contribution to the password and certainly do the same thing to the entire password, so I’m not seeing the value of the extra complexity and interaction.



-Tim

From: Ryan Hurst [mailto:ryan....@gmail.com]
Sent: Tuesday, May 1, 2018 3:49 PM
To: Tim Hollebeek <tim.ho...@digicert.com>
Cc: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

[Ryan Hurst]

On Tuesday, May 1, 2018 at 1:00:20 PM UTC-7, Tim Hollebeek wrote:
> I get that, but any CA that can securely erase and forget the user’s contribution to the password and certainly do the same thing to the entire password, so I’m not seeing the value of the extra complexity and interaction.

It forces a conscious decision to violate a core premise.

[Wayne Thayer]

Ryan - thanks for raising these issues again. I still have concerns about
getting this specific in the policy, but since we're now headed down that
road...

On Tue, May 1, 2018 at 7:13 PM, Ryan Hurst via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> A few problems I see with the proposed text:
>

> - What is sufficient? I would go with a definition tied to the effective
> strength of the keys it protects; in other words, you should protect a
> 2048bit RSA key with something that offers similar properties or that

> 2048bit key does not live up to its 2048 bit properties. This is basically
> the same CSPRNG conversation but it's worth looking at
> https://www.keylength.com/

The latest proposal replaces "sufficient" with "at least 64 bits of output
from a CSPRNG". We could go back to "sufficient strength for the keys it
protects", but that also leaves quite a bit of room for misinterpretation.

Are there objections to "at least 112 bits of output from a CSPRNG" as Tim
proposed?

>
> - The language should recommend that the "password" be a value that is a
> mix of a user-supplied value and the CSPRNG output and that the CA can not
> store the user-supplied value for longer than necessary to create the
> PKCS#12.
>

I'm with Tim on this - it's added complexity for no real added security.

- The strength of the password is discussed but PKCS#12 supports a bunch of
> weak cipher suites and it is common to find them in use in PKCS#12s. The
> minimum should be specified to be what Microsoft supports which is
> pbeWithSHAAnd3-KeyTripleDES-CBC for “privacy” of keys and for the privacy
> of certificates it uses pbeWithSHAAnd40BitRC2-CBC.
>

After reading your (Ryan's) blog, I was left with the impression that
Windows only supports the weakest algorithms, so adding this requirement
doesn't mean anything. If that's not correct, can you suggest some language?

- The language requires the use of a password when using PKCS#12s but
> PKCS#12 supports both symmetric and asymmetric key based protection also.

> While these are not broadly supported the text should not prohibit the use

> of stronger mechanisms than 3DES and a password.
>

> Does the following language work? If not, could you suggest something
better?

PKCS#12 files SHALL be encrypted and signed; or, SHALL have a password

containing at least 64 bits of output from a CSPRNG, and the password SHALL
be transferred using a different channel than the PKCS#12 file.

> Ryan
>
>

[Carl Mehner]

On Tuesday, May 1, 2018 at 6:40:53 PM UTC-5, Wayne Thayer wrote:
> Ryan - thanks for raising these issues again. I still have concerns about
> getting this specific in the policy, but since we're now headed down that
> road...
>
> On Tue, May 1, 2018 at 7:13 PM, Ryan Hurst via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
> > A few problems I see with the proposed text:
> >
> > - What is sufficient? I would go with a definition tied to the effective
> > strength of the keys it protects; in other words, you should protect a
> > 2048bit RSA key with something that offers similar properties or that
> > 2048bit key does not live up to its 2048 bit properties. This is basically
> > the same CSPRNG conversation but it's worth looking at
> > https://www.keylength.com/
>
>
> The latest proposal replaces "sufficient" with "at least 64 bits of output
> from a CSPRNG". We could go back to "sufficient strength for the keys it
> protects", but that also leaves quite a bit of room for misinterpretation.
>
> Are there objections to "at least 112 bits of output from a CSPRNG" as Tim
> proposed?

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.
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?

I went back to the word "protect" to rule out the use of 3DES because bumping up the password past 112 bits doesn't really do much good if the underlying algorithm maxes out its protective strength at 112.
I realize this will decrease the utility of the p12/pfx files since none of the adequately protected files would be openable on any version of Windows. However, the team at Microsoft is well aware of this and they can prioritize their own backlog (they just don't appear to have been given the right incentive to do so as of yet). Perhaps we can add a date-gate..

How about:

PKCS#12 files SHALL be encrypted and signed; or, SHALL have a password

containing at least 112 bits of output from a CSPRNG, and the password SHALL
be transferred using a different channel than the PKCS#12 file. Beginning January 1, 2020 PKCS#12 files must be protected by at least 256 bits of output from a CSPRNG.

This would give people like Microsoft some extra time to update their implementations to support AES.


-Carl

[1] PCI - DSS v3.2, Section 3.5
[2] 800-57 Part 1, Section 6.2.1.3 - https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf

[Tim Hollebeek]

> 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.