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

Unless there is further discussion, I will consider this issue closed with the following change to section 5.3, meaning that it applies to both unconstrained and technically constrained intermediates: Subordinate CA certificates created after January 1, 2019: * MUST contain an EKU extension; and,

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

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

Hi Ryan, thanks for your enlightening feedback to my poor comments... let me try to add some more here. El lunes, 30 de abril de 2018, 17:22:38 (UTC+2), Ryan Sleevi escribió: > On Sun, Apr 29, 2018 at 10:12 AM, pfuentes69--- via dev-security-policy < > dev-security-policy@lists.mozilla.org>

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

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 use case. I'm hoping that they

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

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 use case. I'm hoping that they can clarify >> more. >> >> Pedro - can you explain more about why this is

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

On Sun, Apr 29, 2018 at 10:12 AM, pfuentes69--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > With all my respects to the experts involved in this discussion, my > statement is based in risk management, and I just think there's maybe no > need to over-regulate

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

With all my respects to the experts involved in this discussion, my statement is based in risk management, and I just think there's maybe no need to over-regulate name-constrained CAs, as this technique is already reducing the risks that those new rules intend to control. Name Constraints, as

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

On Tue, Apr 24, 2018 at 9:24 AM, Ryan Sleevi wrote: > I'm not sure I underestand the use case. I'm hoping that they can clarify > more. > > Pedro - can you explain more about why this is important? That is, it would seem valuable as part of the technical constraint > exercise

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

I'm not sure I underestand the use case. I'm hoping that they can clarify more. That is, it would seem valuable as part of the technical constraint exercise to ensure the EKUs are restsricted. This is particularly true due to how nameConstraints work - they are blacklists (effectively), rather

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

On Sun, Apr 22, 2018 at 2:56 PM, pfuentes69--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I think you should consider an an exception Issuing CAs including Name > Constraints. This would keep allowing root signing services for corporate > CAs without forcing

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

I think you should consider an an exception Issuing CAs including Name Constraints. This would keep allowing root signing services for corporate CAs without forcing multiple CAs. El viernes, 20 de abril de 2018, 23:03:17 (UTC+2), Wayne Thayer escribió: > On Thu, Apr 19, 2018 at 8:40 PM, Jakob

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

On Thu, Apr 19, 2018 at 8:40 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 17/04/2018 20:24, Wayne Thayer wrote: > >> This proposal is to require intermediate certificates to be dedicated to >> specific purposes by EKU. Beginning at some future date,

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

On 17/04/2018 20:24, Wayne Thayer wrote: This proposal is to require intermediate certificates to be dedicated to specific purposes by EKU. Beginning at some future date, all newly created intermediate certificates containing either the id-kp-serverAuth or id-kp-emailProtection EKUs would be

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

sts.mozilla.org> Subject: RE: Policy 2.6 Proposal: Require separate intermediates for different usages (e.g. server auth, S/MIME) > -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+doug.beattie=globalsign@lists.mozilla.org] On Behal

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

@lists.mozilla.org> > Subject: Policy 2.6 Proposal: Require separate intermediates for different > usages (e.g. server auth, S/MIME) > > This proposal is to require intermediate certificates to be dedicated to > specific purposes by EKU. Beginning at some future date, all newly

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

On 17/4/2018 9:24 μμ, Wayne Thayer via dev-security-policy wrote: This proposal is to require intermediate certificates to be dedicated to specific purposes by EKU. Beginning at some future date, all newly created intermediate certificates containing either the id-kp-serverAuth or

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

This proposal is to require intermediate certificates to be dedicated to specific purposes by EKU. Beginning at some future date, all newly created intermediate certificates containing either the id-kp-serverAuth or id-kp-emailProtection EKUs would be required to contain only a single EKU.