On Wed, Apr 25, 2018 at 8:01 AM, Jakob Bohm via dev-security-policy < [email protected]> wrote:
> On 20/04/2018 21:59, Wayne Thayer wrote: > >> On Tue, Apr 17, 2018 at 6:10 AM, Buschart, Rufus via dev-security-policy < >> [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_Practic >> es#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. >> >> > 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 _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
