RE: SRVNames in name constraints

[Jeremy Rowley via dev-security-policy]

Ah.  Sorry about that.  I agree that no CA can issue those yet.

-Original Message-
From: Peter Bowen [mailto:pzbo...@gmail.com]
Sent: Tuesday, August 15, 2017 9:04 AM
To: Jeremy Rowley <jeremy.row...@digicert.com>
Cc: Gervase Markham <g...@mozilla.org>; Ryan Sleevi <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 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 for
> SRVNames are prohibited. I realize the rationale against underscores
> is that 5280 requires a valid host name for DNS and X.509 does not
> necessarily permit underscores, but it's not explicitly stated. Ballot
> 202 went a long way towards clarification on when underscores are
> permitted, but that failed, creating all new confusion on the issue.
> Any CA not paying careful attention to the discussion and looking at
> only the results, would probably believe SRVNames are permitted as
> long as the entry is in SAN:dNSName instead of otherName.

Jeremy,

I was assuming the definition of "SRVname" meant an otherName type entry. 
Obviously a dNSName of _xmpp.example.com would have name constraints applied, 
so I don't think that there is an issue there.

Thanks,
Peter


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SRVNames in name constraints

[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 for SRVNames are
> prohibited. I realize the rationale against underscores is that 5280
> requires a valid host name for DNS and X.509 does not necessarily permit
> underscores, but it's not explicitly stated. Ballot 202 went a long way
> towards clarification on when underscores are permitted, but that failed,
> creating all new confusion on the issue.  Any CA not paying careful
> attention to the discussion and looking at only the results, would probably
> believe SRVNames are permitted as long as the entry is in SAN:dNSName
> instead of otherName.

Jeremy,

I was assuming the definition of "SRVname" meant an otherName type
entry.  Obviously a dNSName of _xmpp.example.com would have name
constraints applied, so I don't think that there is an issue there.

Thanks,
Peter
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: SRVNames in name constraints

[Jeremy Rowley via dev-security-policy]

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 for SRVNames are
prohibited. I realize the rationale against underscores is that 5280
requires a valid host name for DNS and X.509 does not necessarily permit
underscores, but it's not explicitly stated. Ballot 202 went a long way
towards clarification on when underscores are permitted, but that failed,
creating all new confusion on the issue.  Any CA not paying careful
attention to the discussion and looking at only the results, would probably
believe SRVNames are permitted as long as the entry is in SAN:dNSName
instead of otherName.   

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf 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: SRVNames in name constraints

On Tue, Aug 15, 2017 at 4:20 AM, Gervase Markham via dev-security-policy
<dev-security-policy@lists.mozilla.org> 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" certs out 
> there with id-kp-serverAuth but no constraints on SRVName. Does that 
> mean they can issue for any SRVName they like? Is that a problem once 
> we start allowing it?
>
> I've filed:
> https://github.com/mozilla/pkipolicy/issues/96
> on this issue in general.

Right now no CA is allowed to issue for SRVName.  Part of the CA/Browser
Forum ballot I had drafted a while ago had language that said something like
"If a CA certificate contains at least one DNSName entry in NameConstraints
and does not have any SRVName entries in NameConstraints, then the CA MUST
NOT issue any certificates containing SRVname names."

However this is a morass, as it is defining what a CA can do based on
something outside the CA's scope.  I'm not sure how to deal with this, to be
honest.

Thanks,
Peter
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SRVNames in name constraints

[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" certs out there
> with id-kp-serverAuth but no constraints on SRVName. Does that mean they
> can issue for any SRVName they like? Is that a problem once we start
> allowing it?
>
> I've filed:
> https://github.com/mozilla/pkipolicy/issues/96
> on this issue in general.

Right now no CA is allowed to issue for SRVName.  Part of the
CA/Browser Forum ballot I had drafted a while ago had language that
said something like "If a CA certificate contains at least one DNSName
entry in NameConstraints and does not have any SRVName entries in
NameConstraints, then the CA MUST NOT issue any certificates
containing SRVname names."

However this is a morass, as it is defining what a CA can do based on
something outside the CA's scope.  I'm not sure how to deal with this,
to be honest.

Thanks,
Peter
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SRVNames in name constraints

[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 that a problem once we start
allowing it?

I've filed:
https://github.com/mozilla/pkipolicy/issues/96
on this issue in general.

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SRVNames in name constraints

[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 perhaps id-kp-clientAuth)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SRVNames in name constraints

[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 server” certificates.  Mozilla does not use either 
> rfc822names or SRVName for name validation for server authentication, but you 
> could have a valid server certificate that has only these names.  Is 
> NSS/Firefox code considered a “technical constraint”?  If not, then all 
> technically constrained CA certificates need to have constraints on SRVName 
> and rfc822Name type General Names in addition to what they have now.

You are right; this is a bug. Server certs need to have constraints on
dNSName and ipAddress (v4 and v6), and email certs need to have
constraints on rfc822Name. It is not intended to require that e.g.
server certs have rfc822Name constraints in order to be considered
technically constrained.

What EKU(s) get used with certs containing SRVName? I confess I don't
understand this technology as well as I might.

Note that I'm going on holiday for 3 weeks; further engagement may have
to wait until I return.

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SRVNames in name constraints

[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 longer
>> considered constrained.
> 
> I'm not sure what you mean... What's the issue you are raising here?

Right now (Policy v2.5) says:

Intermediate certificates which have at least one valid, unrevoked chain up to 
such a CA certificate and which are not technically constrained to prevent 
issuance of working server or email certificates. Such technical constraints 
could consist of either:

an Extended Key Usage (EKU) extension which does not contain any of these 
KeyPurposeIds: anyExtendedKeyUsage, id-kp-serverAuth, id-kp-emailProtection; or:
name constraints which do not allow Subject Alternative Names (SANs) of any of 
the following types: dNSName, iPAddress, SRVName, rfc822Name
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 server” certificates.  Mozilla does not use either rfc822names or 
SRVName for name validation for server authentication, but you could have a 
valid server certificate that has only these names.  Is NSS/Firefox code 
considered a “technical constraint”?  If not, then all technically constrained 
CA certificates need to have constraints on SRVName and rfc822Name type General 
Names in addition to what they have now.

Thanks,
Peter
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SRVNames in name constraints

[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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SRVNames in name constraints

[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 has issued a
> cross-certificate containing constraints on SRVName-type names.  Until
> the Forum allows such issuance, I think this requirement should be
> changed to remove SRVName from the list.  If the Forum does allow such
> in the future, adding this back can be revisited at such time.

Clearly, the set of things CAs must abide by is the restrictive union of
the BRs and all the browser policies. So this is in the nature of an
"unusable permission". So I don't think it's doing any harm.

Are there any plans for a ballot to enable this? I thought that perhaps
there might be. If so, it seems easiest to just leave it.

Gerv

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SRVNames in name constraints

[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
<jeremy.row...@digicert.com> wrote:
> 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 dev-security-policy
> Sent: Monday, July 3, 2017 10:30 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: SRVNames in name constraints
>
> In reviewing the Mozilla CA policy, I noticed one bug that is probably my
> fault.  It says:
>
> "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 has issued a cross-certificate containing
> constraints on SRVName-type names.  Until the Forum allows such issuance, I
> think this requirement should be changed to remove SRVName from the list.
> If the Forum does allow such in the future, adding this back can be
> revisited at such time.
>
> Thanks,
> Peter
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: SRVNames in name constraints

[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 dev-security-policy
Sent: Monday, July 3, 2017 10:30 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: SRVNames in name constraints

In reviewing the Mozilla CA policy, I noticed one bug that is probably my
fault.  It says:

"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 has issued a cross-certificate containing
constraints on SRVName-type names.  Until the Forum allows such issuance, I
think this requirement should be changed to remove SRVName from the list.
If the Forum does allow such in the future, adding this back can be
revisited at such time.

Thanks,
Peter
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

SRVNames in name constraints

[Peter Bowen via dev-security-policy]

In reviewing the Mozilla CA policy, I noticed one bug that is probably
my fault.  It says:

"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 has issued a
cross-certificate containing constraints on SRVName-type names.  Until
the Forum allows such issuance, I think this requirement should be
changed to remove SRVName from the list.  If the Forum does allow such
in the future, adding this back can be revisited at such time.

Thanks,
Peter
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy