RE: SRVNames in name constraints

2017-08-15 Thread Jeremy Rowley via dev-security-policy
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

Re: SRVNames in name constraints

2017-08-15 Thread Peter Bowen via dev-security-policy
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

RE: SRVNames in name constraints

2017-08-15 Thread Jeremy Rowley via dev-security-policy
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

Re: SRVNames in name constraints

2017-08-15 Thread Peter Bowen via dev-security-policy
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"

Re: SRVNames in name constraints

2017-08-15 Thread Gervase Markham via dev-security-policy
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

Re: SRVNames in name constraints

2017-07-06 Thread Ryan Sleevi via dev-security-policy
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

Re: SRVNames in name constraints

2017-07-06 Thread Gervase Markham via dev-security-policy
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

Re: SRVNames in name constraints

2017-07-05 Thread Peter Bowen via dev-security-policy
> 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

Re: SRVNames in name constraints

2017-07-05 Thread Gervase Markham via dev-security-policy
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

Re: SRVNames in name constraints

2017-07-05 Thread Gervase Markham via dev-security-policy
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

Re: SRVNames in name constraints

2017-07-03 Thread Peter Bowen via dev-security-policy
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

RE: SRVNames in name constraints

2017-07-03 Thread Jeremy Rowley via dev-security-policy
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