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:[email protected]] 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 On Tue, Apr 17, 2018 at 6:10 AM, Buschart, Rufus via dev-security-policy <[email protected]<mailto:[email protected]>> 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 _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
