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.busch...@siemens.com www.siemens.com/ingenuityforlife -----Original Message----- From: dev-security-policy [mailto:dev-security-policy-bounces+rufus.buschart=siemens....@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 On Tue, Apr 10, 2018 at 7:22 AM, Jürgen Brauckmann via dev-security-policy < dev-security-policy@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 > > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
