Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

On Fri, Jun 8, 2018 at 2:32 PM Buschart, Rufus wrote: > Did we somehow came to a conclusion / agreed wording here? I'm not sure if > I missed something, but the last email I've received in regards to this > issue is from mid of May and the last change in >

AW: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

y-bounces+rufus.buschart=siemens.com@lists.m > ozilla.org] Im Auftrag von Tim Hollebeek via dev-security-policy > Gesendet: Mittwoch, 16. Mai 2018 08:23 > An: Wayne Thayer; mozilla-dev-security-policy > Betreff: RE: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on > CA key generat

RE: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

-security-pol...@lists.mozilla.org> Subject: Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy) On Tue, May 15, 2018 at 9:17 PM Tim Hollebeek <tim.holleb...@digicert.com <mailto:tim.holleb...@digicert.com> > wrote: My only objection is

Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

c: mozilla-dev-security-policy >> <mozilla-dev-security-pol...@lists.mozilla.org> >> Subject: Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key >> generation to policy) >> >> I'm coming to the conclusion that this discussion is about "security >

Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

On Tue, May 15, 2018 at 9:17 PM Tim Hollebeek wrote: > My only objection is that this will cause key generation to shift to > partners and > affiliates, who will almost certainly do an even worse job. > > > This is already a Mozilla requirement [1] - we're just moving

RE: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

> This going to require 19 randomly generated Base64 characters and that does > not include removing common confused characters which will drive up the > length a bit more, but if this is what the Mozilla risk assessment came up > with, > then we’ll all have to comply. I hope there is a

RE: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

rity-policy > <mozilla-dev-security-pol...@lists.mozilla.org> > Subject: Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key > generation to policy) > > I'm coming to the conclusion that this discussion is about "security > theater"[1]. > As lon

Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

I'm coming to the conclusion that this discussion is about "security theater"[1]. As long as we allow CAs to generate S/MIME key pairs, there are gaping holes in the PKCS#12 requirements, the most obvious being that a CA can just transfer the private key to the user in pem format! Are there any

Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

On 15/5/2018 6:51 μμ, Wayne Thayer via dev-security-policy wrote: Did you consider any changes based on Jakob’s comments? If the PKCS#12 is distributed via secure channels, how strong does the password need to be? I think this depends on our threat model, which to be fair is not

Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

t:* Monday, May 14, 2018 4:54 PM > *To:* Doug Beattie <doug.beat...@globalsign.com>; > mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org > > > *Subject:* Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on > CA key generation to policy)

RE: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

need to be? Doug From: Wayne Thayer [mailto:wtha...@mozilla.com] Sent: Monday, May 14, 2018 4:54 PM To: Doug Beattie <doug.beat...@globalsign.com>; mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org> Subject: Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohi

Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

On 14/05/2018 22:53, Wayne Thayer wrote: On Mon, May 14, 2018 at 11:50 AM Doug Beattie via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: I hope some other CAs weigh in in this: Robin, Bruce, Jeremy, Daymion, Dean??? - We can’t permit user generated passwords (at least

Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

On Mon, May 14, 2018 at 11:50 AM Doug Beattie via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > I hope some other CAs weigh in in this: Robin, Bruce, Jeremy, Daymion, > Dean??? > - We can’t permit user generated passwords (at least that is Tim's > proposal, Wayne may not

Re: FW: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

On Mon, May 14, 2018 at 11:29 AM Bruce via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Wednesday, May 9, 2018 at 11:42:56 PM UTC-4, Wayne Thayer wrote: > > I think we have settled on the following resolution to this issue: > > > > Add the following to section 5.2

RE: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

> Sent: Monday, May 14, 2018 12:52 PM > To: Ryan Hurst <ryan.hu...@gmail.com>; mozilla-dev-security- > pol...@lists.mozilla.org > Subject: RE: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key > generation to policy) > > For the record, I posted s

Re: FW: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

On Wednesday, May 9, 2018 at 11:42:56 PM UTC-4, Wayne Thayer wrote: > I think we have settled on the following resolution to this issue: > > Add the following to section 5.2 (Forbidden and Required Practices): > > CAs MUST NOT generate the key pairs for end-entity certificates that have > > an

RE: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

n > Hurst via dev-security-policy > Sent: Friday, May 4, 2018 5:19 PM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key > generation to policy) > > > > True, but CAs can put technical constra

Re: FW: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

ev-security-pol...@lists.mozilla.org> > *Subject:* Re: FW: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition > on CA key generation to policy) > > > > > > I think we have settled on the following resolution to this issue: > > > > Add the following to secti

RE: FW: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

<doug.beat...@globalsign.com> Cc: mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org> Subject: Re: FW: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy) I think we have settled on the following resolution to this issue: Add t

Re: FW: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

I think we have settled on the following resolution to this issue: Add the following to section 5.2 (Forbidden and Required Practices): CAs MUST NOT generate the key pairs for end-entity certificates that have > an EKU extension containing the KeyPurposeIds id-kp-serverAuth or >

FW: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

urity-policy [mailto:mailto:dev-security-policy- >> bounces+doug.beattie=mailto:globalsign@lists.mozilla.org] On Behalf Of >> Ryan >> Hurst via dev-security-policy >> Sent: Friday, May 4, 2018 4:35 PM >> To: mailto:mozilla-dev-security-pol...@lists.mozilla.org &g

Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

a.org] On Behalf Of Ryan > > Hurst via dev-security-policy > > Sent: Friday, May 4, 2018 4:35 PM > > To: mozilla-dev-security-pol...@lists.mozilla.org > > Subject: Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on > CA key > > generation to policy) > > >

Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

On 04/05/2018 20:58, Wayne Thayer wrote: The optimist in me thinks we might be getting close to resolving this issue (the last one remaining for the 2.6 policy update). Here is another proposal that attempts to account for most of the input we've received: Add the following to section 5.2

Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

> True, but CAs can put technical constraints on that to limit the acceptable > passwords to a certain strength. (hopefully with a better strength-testing > algorithm than the example Tim gave earlier) Tim is the best of us -- this is hard to do well :)

Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

On Friday, May 4, 2018 at 3:37:10 PM UTC-5, Ryan Hurst wrote: > > > > What about "or a user supplied password"? > > -carl > > user supplied passwords will (in real world scenarios) not be as good as a > one generated for them; this is in part why I suggested earlier if a user > password to be

Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

On Fri, May 4, 2018 at 1:25 PM Carl Mehner via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hey Doug, > > On Friday, May 4, 2018 at 3:00:03 PM UTC-5, Doug Beattie wrote: > > Hey Wayne, > > > > This should be a really easy thing, but it's not. > > > > First comments on

Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

> > What about "or a user supplied password"? > -carl user supplied passwords will (in real world scenarios) not be as good as a one generated for them; this is in part why I suggested earlier if a user password to be used that it be mixed with a server provided value.

Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

On Friday, May 4, 2018 at 1:00:03 PM UTC-7, Doug Beattie wrote: > First comments on this: "MUST be encrypted and signed; or, MUST have a > password that..." > - Isn't the password the key used for encryption? I'm not sure if the "or" > makes sense since in both cases the password is the key for

Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

Hey Doug, On Friday, May 4, 2018 at 3:00:03 PM UTC-5, Doug Beattie wrote: > Hey Wayne, > > This should be a really easy thing, but it's not. > > First comments on this: "MUST be encrypted and signed; or, MUST have a > password that..." > - Isn't the password the key used for encryption? I'm

RE: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

dev-security-policy > Sent: Friday, May 4, 2018 2:58 PM > To: mozilla-dev-security-policy > <mozilla-dev-security-pol...@lists.mozilla.org> > Subject: Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key > generation to policy) > > The optimist in me thinks

Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

The optimist in me thinks we might be getting close to resolving this issue (the last one remaining for the 2.6 policy update). Here is another proposal that attempts to account for most of the input we've received: Add the following to section 5.2 (Forbidden and Required Practices): CAs MUST

RE: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

> Maybe you want n = 112 / 8 = 14 bytes. Doh! Yes. -Tim smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy

Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

On 2018-05-04 12:10, Tim Hollebeek wrote: It has generally been understood that a string still "contains at least 112 bits of output from a CSPRNG" if that string has been fed through an encoding mechanism like Base64 or Base32. Furthermore, explicit requirements about including mixed case or

RE: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

ev-security-policy- > bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of Buschart, > Rufus via dev-security-policy > Sent: Thursday, May 3, 2018 6:01 PM > To: Carl Mehner <c...@cem.me>; mozilla-dev-security-pol...@lists.mozilla.org > Subject: Bit encoding (AW: Policy 2.

Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

As I was reading this very interesting thread, I kept asking myself "what are we trying to protect". Are we trying to protect a "Private Key" or a "PKCS#12" file? I suppose the consensus of the community, based mainly on compatibility issues, is that we can't avoid the solution of a PKCS#12

Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

Basically I like the new wording: > PKCS#12 files [...] SHALL have a password containing at least 112 bits > of output from a CSPRNG, [...] But I think there is a practical problem here: Directly using the output of any random number generator ("C" or not) to generate a password will lead to