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

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. -Tim From: Ryan Hurst [mailto:ryan.hu...@gmail.com] Sent:

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

OISTE WISeKey Global Root GC CA Root Inclusion Request

This request is for inclusion of the OISTE WISeKey Global Root GC CA as documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1403591 * BR Self Assessment is here: https://bugzilla.mozilla.org/attachment.cgi?id=8912732 * Summary of Information Gathered and Verified:

Re: Policy 2.6 Proposal: Require separate intermediates for different usages (e.g. server auth, S/MIME)

Jakob, On Tue, May 1, 2018 at 1:14 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote > > However maybe an additional (clarifying or new) requirement set: > > I think the existing language in section 5.3.1 covers all of this. If not, can you point out the gaps

Re: Policy 2.6 Proposal: Require separate intermediates for different usages (e.g. server auth, S/MIME)

On 30/04/2018 18:47, Wayne Thayer wrote: On Mon, Apr 30, 2018 at 8:27 AM, Ryan Sleevi wrote: On Wed, Apr 25, 2018 at 1:03 PM, Wayne Thayer wrote: On Tue, Apr 24, 2018 at 9:24 AM, Ryan Sleevi wrote: I'm not sure I underestand the