SRVNames in name constraints

[Peter Bowen]

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

[Jeremy Rowley]

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.

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

[Peter Bowen]

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.

[Gervase Markham]

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

[Gervase Markham]

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

[Peter Bowen]

> On Jul 5, 2017, at 4:23 AM, Gervase Markham via dev-security-policy <dev-secur...@lists.mozilla.org> 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

[Gervase Markham]

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

[Ryan Sleevi]

On Thu, Jul 6, 2017 at 10:48 AM, Gervase Markham via dev-security-policy <
dev-secur...@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)

[Gervase Markham]

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

[Gervase Markham]

On 06/07/17 16:56, Ryan Sleevi wrote:

> Relevant to this group, id-kp-serverAuth (and perhaps id-kp-clientAuth)

[Peter Bowen]

On Tue, Aug 15, 2017 at 4:20 AM, Gervase Markham via
dev-security-policy <dev-secur...@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

[Jeremy Rowley]

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=digice...@lists.mozilla
.org] On Behalf Of Peter Bowen via dev-security-policy

Sent: Tuesday, August 15, 2017 8:51 AM
To: Gervase Markham <ge...@mozilla.org>
Cc: Ryan Sleevi <ry...@sleevi.com>; Peter Bowen <p...@amzn.com>;
mozilla-dev-security-policy <mozilla-dev-s...@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-secur...@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.

[Peter Bowen]

On Tue, Aug 15, 2017 at 8:01 AM, Jeremy Rowley
<jeremy...@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

[Jeremy Rowley]

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

-----Original Message-----
From: Peter Bowen [mailto:pzb...@gmail.com]
Sent: Tuesday, August 15, 2017 9:04 AM
To: Jeremy Rowley <jeremy...@digicert.com>
Cc: Gervase Markham <ge...@mozilla.org>; Ryan Sleevi <ry...@sleevi.com>; Peter
Bowen <p...@amzn.com>; mozilla-dev-security-policy
<mozilla-dev-s...@lists.mozilla.org>
Subject: Re: SRVNames in name constraints

On Tue, Aug 15, 2017 at 8:01 AM, Jeremy Rowley <jeremy...@digicert.com>
wrote: