r...@sleevi.com>; Peter
Bowen <p...@amzn.com>; mozilla-dev-security-policy
<mozilla-dev-security-pol...@lists.mozilla.org>
Subject: Re: SRVNames in name constraints
On Tue, Aug 15, 2017 at 8:01 AM, Jeremy Rowley <jeremy.row...@digicert.com>
wrote:
> I realize use of
On Tue, Aug 15, 2017 at 8:01 AM, Jeremy Rowley
wrote:
> I realize use of underscore characters was been debated and explained at the
> CAB Forum, but I think it's pretty evident (based on the certs issued and
> responses to Ballot 202) that not all CAs believe certs
Of Peter Bowen via dev-security-policy
Sent: Tuesday, August 15, 2017 8:51 AM
To: Gervase Markham <g...@mozilla.org>
Cc: Ryan Sleevi <r...@sleevi.com>; Peter Bowen <p...@amzn.com>;
mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org>
Subject: Re: SRVN
On Tue, Aug 15, 2017 at 4:20 AM, Gervase Markham via
dev-security-policy wrote:
> On 06/07/17 16:56, Ryan Sleevi wrote:
>> Relevant to this group, id-kp-serverAuth (and perhaps id-kp-clientAuth)
>
> So what do we do? There are loads of "name-constrained"
On 06/07/17 16:56, Ryan Sleevi wrote:
> Relevant to this group, id-kp-serverAuth (and perhaps id-kp-clientAuth)
So what do we do? There are loads of "name-constrained" certs out there
with id-kp-serverAuth but no constraints on SRVName. Does that mean they
can issue for any SRVName they like? Is
On Thu, Jul 6, 2017 at 10:48 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> What EKU(s) get used with certs containing SRVName? I confess I don't
> understand this technology as well as I might.
>
Relevant to this group, id-kp-serverAuth (and
On 05/07/17 15:10, Peter Bowen wrote:
> The second bullet says “any”. As the rule for name constraints is that if
> they are not present for a type, then any name is allowed, you have to
> include name constraints for all four types. The issue comes down to the
> definition of “working
> On Jul 5, 2017, at 4:23 AM, Gervase Markham via dev-security-policy
> wrote:
>
> On 03/07/17 17:44, Peter Bowen wrote:
>> We still need to get the policy changed, even with the ballot. As
>> written right now, all name constrained certificates are no
On 03/07/17 17:44, Peter Bowen wrote:
> We still need to get the policy changed, even with the ballot. As
> written right now, all name constrained certificates are no longer
> considered constrained.
I'm not sure what you mean... What's the issue you are raising here?
Gerv
On 03/07/17 17:29, Peter Bowen wrote:
> "name constraints which do not allow Subject Alternative Names (SANs)
> of any of the following types: dNSName, iPAddress, SRVName,
> rfc822Name"
>
> SRVName is not yet allowed by the CA/Browser Forum Baseline
> Requirements (BRs), so I highly doubt any CA
We still need to get the policy changed, even with the ballot. As
written right now, all name constrained certificates are no longer
considered constrained.
On Mon, Jul 3, 2017 at 9:42 AM, Jeremy Rowley
wrote:
> Isn't this ballot ready to go? If we start the review
Isn't this ballot ready to go? If we start the review period now, it'll be
passed by the time the Mozilla policy is updated.
-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Peter Bowen via
12 matches
Mail list logo