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

> 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

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

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

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

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-security-policy@lists.mozilla.org> wrote: > A few problems I see

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

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.

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

: Tuesday, May 1, 2018 3:49 PM To: Tim Hollebeek <tim.holleb...@digicert.com> Cc: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Policy 2.6 Proposal: Add prohibition on CA key generation to policy > I'm not sure I agree with this as a recommendation; if you want both parties >

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

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

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

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

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

Entschew <enr...@entschew.com>; Grotz, Florian <florian.gr...@siemens.com>; Heusler, Juergen <juergen.heus...@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

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

s.com>; Heusler, Juergen <juergen.heus...@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 elect

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

om>; Enrico > > Entschew <enr...@entschew.com>; Grotz, Florian > > <florian.gr...@siemens.com>; Heusler, Juergen > > <juergen.heus...@siemens.com>; Wayne Thayer <wtha...@mozilla.com> > > Subject: RE: Policy 2.6 Proposal: Add prohibition on CA

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

ico > Entschew <enr...@entschew.com>; Grotz, Florian > <florian.gr...@siemens.com>; Heusler, Juergen > <juergen.heus...@siemens.com>; Wayne Thayer <wtha...@mozilla.com> > Subject: RE: Policy 2.6 Proposal: Add prohibition on CA key generation to > policy > > > I

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

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

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

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

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

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

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-security-policy@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

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

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

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

On Wed, Apr 25, 2018 at 8:01 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> 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 < >> dev-security-policy@lists.mozilla.org> wrote: >> >> I

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

On 20/04/2018 21:59, Wayne Thayer wrote: On Tue, Apr 17, 2018 at 6:10 AM, Buschart, Rufus via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: I believe the wording "insecure electronic channels" leaves a lot of space for interpretation. In corporate PKIs for email

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 < dev-security-policy@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

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

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

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

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

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

t; To: mozilla-dev-security-policy > <mozilla-dev-security-pol...@lists.mozilla.org> > Subject: Re: Policy 2.6 Proposal: Add prohibition on CA key generation to > policy > > Getting back to the earlier question about email certificates, I am now of the > opinion that we sh

Re: Policy 2.6 Proposal: Add prohibition on CA key generation to 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

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

On Thu, Apr 5, 2018 at 12:29 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> 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

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

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

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

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 > wrote: > > > My proposal is "CAs MUST NOT distribute or transfer private keys and > > associated certificates in PKCS#12 form through insecure physical or > > electronic

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

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

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

On Thu, Apr 5, 2018 at 4:58 AM, Doug Beattie 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

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

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

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

On Wed, Apr 4, 2018 at 3:15 PM, Ryan Hurst via dev-security-policy < dev-security-policy@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

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

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