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
>
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
-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
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
>
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
> 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
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
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
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
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)
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
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
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
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
> 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
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
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
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
<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
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
>
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
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)
> >
>
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
> 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 :)
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
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
>
> 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.
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
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
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
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
> 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
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
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.
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
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
36 matches
Mail list logo