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,
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 s
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 use case. I'm hoping that they can
clarify more.
Pedro -
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> wrot
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 can
>>> clarify more.
>>>
>>> Pedro - can you explain more
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 important?
>
> That is, it would seem valuable a
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 name-cons
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 u
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 to ensure the EKUs
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
tha
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 multiple
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 B
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, a
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 requ
eattie via dev-security-policy
> Sent: Tuesday, April 17, 2018 1:37 PM
> To: Wayne Thayer ; mozilla-dev-security-policy
>
> Subject: RE: Policy 2.6 Proposal: Require separate intermediates for
> different usages (e.g. server auth, S/MIME)
>
>
>
> > -Original Mes
From: dev-security-policy
On Behalf Of Doug Beattie via dev-security-policy
Sent: Tuesday, April 17, 2018 1:37 PM
To: Wayne Thayer ; mozilla-dev-security-policy
Subject: RE: Policy 2.6 Proposal: Require separate intermediates for
different usages (e.g. server auth, S/MIME)
> -Original
@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
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
id-kp-emailPr
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.
Argumen
19 matches
Mail list logo