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.
---
Von: dev-security-policy
[mailto:dev-security-policy-bounces+rufus.buschart=siemens.com@lists.m
ozilla.org] Im Auftrag von Carl Mehner via dev-security-policy
Gesendet: Mittwoch, 2. Mai 2018 07:45
An: mozilla-dev-security-pol...@lists.mozilla.org
Betreff: Re: Policy 2.6 Proposal: Add prohibition o
er via dev-security-policy
> Gesendet: Mittwoch, 2. Mai 2018 07:45
> An: mozilla-dev-security-pol...@lists.mozilla.org
> Betreff: 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:
> &g
> 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
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
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
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.
: 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
>
> 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
>
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
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
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
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
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
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
> >
emens.com>; Wayne Thayer <wtha...@mozilla.com>
> Subject: AW: Policy 2.6 Proposal: Add prohibition on CA key generation to
> policy
>
> ---=== Intern ===---
> Hello!
>
> I would like to suggest to rephrase the central sentence a little bit:
>
> Original:
>
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
pril 2018 19:30
> An: Enrico Entschew
> Cc: mozilla-dev-security-policy
> Betreff: 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.mozil
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
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
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
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
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
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
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
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
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
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
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
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
>> 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
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
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
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
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
This issue is titled “Make sure Forbidden practices are forbidden” - in
other words, make sure they are banned in our policy. The only forbidden
practice on our list [1] that’s not already covered by our policy is
“Distributing Generated Private Keys in PKCS#12 Files”. It reads:
CAs must never
69 matches
Mail list logo