Policy 2.4 Proposal: Use language of capability throughout

[Gervase Markham]

We want to change the policy to make it clear that whether a cert is
covered by our policy or not is dependent on whether it is technically
capable of issuing server certs, not whether it is intended by the CA
for issuing server certs.

Until we change Firefox to require id-kp-serverAuth, the policy will
define "capable" as "id-kp-serverAuth or no EKU".

This involves a number of wording tweaks; the full set of changes are here:
https://github.com/mozilla/pkipolicy/compare/issue-27

This is: https://github.com/mozilla/pkipolicy/issues/27

-------

This is a proposed update to Mozilla's root store policy for version
2.4. Please keep discussion in this group rather than on Github. Silence
is consent.

Policy 2.3 (current version):
https://github.com/mozilla/pkipolicy/blob/2.3/rootstore/policy.md
Update process:
https://wiki.mozilla.org/CA:CertPolicyUpdates

[Brian Smith]

Gervase Markham <ge...@mozilla.org> wrote:
> We want to change the policy to make it clear that whether a cert is
> covered by our policy or not is dependent on whether it is technically
> capable of issuing server certs, not whether it is intended by the CA
> for issuing server certs.

NIT: The issue isn't whether it is technically capable of *issuing* a
cert, but what certificates it issues are trusted by Firefox (or, more
abstractly, TLS certificates trusted by a TLS client or email
certificates trusted by an S/MIME-capable email client).

In particular, I suggest replacing "unable to issue server or email
certificates" with "unable to issue *trusted* server or email
certificates" or similar.

Cheers,
Brian

> Until we change Firefox to require id-kp-serverAuth, the policy will
> define "capable" as "id-kp-serverAuth or no EKU".

This would allow anyExtendedKeyUsage in a way that isn't what you
intend, AFAICT. I suggest "without an EKU constraint that excludes
id-kp-serverAuth." This suggested new wording doesn't explicitly allow
anyExtendedKeyUsage to be used, not does it exclude a cert with
anyExtendedKeyUsage from being in scope, but otherwise accomplishes
the same thing.

More generally, I suggest you use the wording in my latest message in
the id-kp-serverAuth thread. In particular, id-kp-serverAuth doesn't
apply to email certificates; id-kp-emailProtection does. Thus, you
need to consider which EKU, which trust bit, and which types of names
are relevant separately for email and TLS.

Cheers,
Brian

[Gervase Markham]

On 08/12/16 13:06, Brian Smith wrote:
> In particular, I suggest replacing "unable to issue server or email
> certificates" with "unable to issue *trusted* server or email
> certificates" or similar.

I think I would prefer not to make that tie, because the obvious
question is "trusted in which version of Firefox"? I would prefer to
modify Firefox and the policy to match, but have the ability to skew
those two updates as necessary, rather than tie the policy to what
Firefox does directly.

Gerv

[Brian Smith]

Gervase Markham <ge...@mozilla.org> wrote:
> On 08/12/16 13:06, Brian Smith wrote:

>> In particular, I suggest replacing "unable to issue server or email
>> certificates" with "unable to issue *trusted* server or email
>> certificates" or similar.
>

> I think I would prefer not to make that tie, because the obvious
> question is "trusted in which version of Firefox"? I would prefer to
> modify Firefox and the policy to match, but have the ability to skew
> those two updates as necessary, rather than tie the policy to what
> Firefox does directly.

"Unable to issue" means "unable to sign with the private key" which
can only happen if they don't have the private key. But they do have
the private key so they're always able to issue certificates with any
contents they want. Thus "unable to issue" is a not a useful criteria
since no CA meets it and so you need a different criteria.

Cheers,
Brian
--
https://briansmith.org/

[Brian Smith]

On Thu, Dec 8, 2016 at 10:46 AM, Gervase Markham <ge...@mozilla.org> wrote:
> We want to change the policy to make it clear that whether a cert is
> covered by our policy or not is dependent on whether it is technically
> capable of issuing server certs, not whether it is intended by the CA
> for issuing server certs.

I'll quote part of the proposed change here:

> 2. Intermediate certificates which have at least one valid, unrevoked chain up
> to such a CA certificate and which are not technically constrained such
> that they are unable to issue server or email certificates. Such technical
> constraints could consist of either:
> * an Extended Key Usage (EKU) extension which does not contain either of the
> id-kp-serverAuth and id-kp-emailProtection EKUs; or:
> * name constraints which do not allow SANs of any of the following types:
> dNSName, iPAddress, SRVName, rfc822Name
>
> 3. End-entity certificates which have at least one valid, unrevoked chain up to
> such a CA certificate through intermediate certificates which are all in
> scope, such end-entity certificates having either:
> * an Extended Key Usage (EKU) extension which contains one or more of the
> id-kp-serverAuth and id-kp-emailProtection EKUs; or:
> * no EKU extension.

Again, it doesn't make sense to say that the forms of names matter for
name constraints, but don't matter for end-entity certificates. If an
end-entity certificate doesn't contain any names of the forms dNSName,
iPAddress, SRVName, rfc822Name, then it shouldn't be in scope.

Also, the way that the text is worded the above means that an
intermediate certificate that contains anyExtendedKeyUsage in its EKU
would be considered out of scope of Mozilla's policy. However, you
need to have such certificates be in scope so that you can forbid them
from using anyExtendedKeyUsage.

[Gervase Markham]

On 10/12/16 21:14, Brian Smith wrote:
> "Unable to issue" means "unable to sign with the private key" which
> can only happen if they don't have the private key. But they do have
> the private key so they're always able to issue certificates with any
> contents they want. Thus "unable to issue" is a not a useful criteria
> since no CA meets it and so you need a different criteria.

This seems like a linguistic nit but, nevertheless, I have replaced

"unable to issue server or email certificates" with "unable to issue

working server or email certificates". A certificate issued which does
not meet the name constraints of its issuing CA could fairly be called
"non-working" in WebPKI terms.

This makes it more clear while avoiding complicating matters by
referencing what Firefox does or does not trust.

Gerv

[Gervase Markham]

On 10/12/16 21:25, Brian Smith wrote:
> Again, it doesn't make sense to say that the forms of names matter for
> name constraints, but don't matter for end-entity certificates. If an
> end-entity certificate doesn't contain any names of the forms dNSName,
> iPAddress, SRVName, rfc822Name, then it shouldn't be in scope.

Why would it have id-kp-serverAuth or id-kp-emailProtection and not have
any names of those forms?

> Also, the way that the text is worded the above means that an
> intermediate certificate that contains anyExtendedKeyUsage in its EKU
> would be considered out of scope of Mozilla's policy. However, you
> need to have such certificates be in scope so that you can forbid them
> from using anyExtendedKeyUsage.

Well, there are two responses to that.

Firstly, no. The certs in scope are: "Intermediate certificates ...

which are not technically constrained such that they are unable to issue

working server or email certificates." If an intermediate certificate
has an EKU with anyEKU, it is able to issue working server or email
certificates. So it's in scope. (This utilises my use of "working"
rather than "trusted", as noted in my previous email.)

But secondly, I'm not banning the use of anyEKU, because Firefox doesn't
trust cert chains that rely on it, so there's no need to ban it. Is there?

Gerv

[Kurt Roeckx]

On 2016-12-16 15:45, Gervase Markham wrote:
> But secondly, I'm not banning the use of anyEKU, because Firefox doesn't
> trust cert chains that rely on it, so there's no need to ban it. Is there?

Can I point out again that Firefox (or NSS) is not the only user of the
root store?


Kurt

[Ryan Sleevi]

On Fri, Dec 16, 2016 at 7:24 AM, Kurt Roeckx <ku...@roeckx.be> wrote:
> On 2016-12-16 15:45, Gervase Markham wrote:
>>

>> But secondly, I'm not banning the use of anyEKU, because Firefox doesn't
>> trust cert chains that rely on it, so there's no need to ban it. Is there?
>
>

> Can I point out again that Firefox (or NSS) is not the only user of the root
> store?

Can I point out again

https://wiki.mozilla.org/CA:FAQ#Can_I_use_Mozilla.27s_set_of_CA_certificates.3F

Not trying to be snarky - just that if we're going to act upon your
comment, actionable data and concerns are needed.

Put more concretely:
- Hypotheticals ("What about software foo?") should not be considered
unless they're demonstrated
- If they are demonstrated, the author/maintainers of those packages
should be engaging with the Mozilla community to represent those
concerns

So let's say, for example, that Curl was using the Mozilla set, but
using it with a GnuTLS validator, and was concerned about a direction
that Mozilla would take - wanting additional time or to push back on
that. It seems eminently reasonable to expect that both the
maintainers of Curl and GnuTLS's validator would step up and
participate, representing those concerns, and be open/amenable to
changes or to explaining why changes may not work.

Absent that, as an upstream project, it seems entirely reasonable that
a decision is made, on list, and unless someone comes up with specific
and concrete objections (with a plan for remediating or exploring the
problem more), then it goes forward. For example, "This would break
Curl, and we'd need a new version of GnuTLS to support [X]. Could you
wait on making this change for 3 months so that we can get a new
release out?" is a concrete and actionable plan :)

[Kurt Roeckx]

On Fri, Dec 16, 2016 at 09:41:08AM -0800, Ryan Sleevi wrote:
> On Fri, Dec 16, 2016 at 7:24 AM, Kurt Roeckx <ku...@roeckx.be> wrote:
> > On 2016-12-16 15:45, Gervase Markham wrote:
> >>

> >> But secondly, I'm not banning the use of anyEKU, because Firefox doesn't
> >> trust cert chains that rely on it, so there's no need to ban it. Is there?
> >
> >

> > Can I point out again that Firefox (or NSS) is not the only user of the root
> > store?
>
> Can I point out again
> https://wiki.mozilla.org/CA:FAQ#Can_I_use_Mozilla.27s_set_of_CA_certificates.3F

It's actually the first time I read that.

Anyway, my comment is maily that it's not because FireFox doesn't
support anyEKU or clientAuth that other software doesn't. And that
having a policy that only focuses on serverAuth (or email) might have
an effect on those other users.

It's my understanding that NSS (or FireFox) doesn't allow the
anyEKU anywhere in the chain. The BR seem to perfectly allow the
anyEKU for CAs, but requires the serverAuth or clientAuth for the
subscriber.

My understanding from what would change is that if it has an
anyEKU or clientAuth anywhere in the chain it would no longer be in
scope of the Mozilla requirements and so that it would not need to
follow the BRs, be audited, follow their CP/CPS, and that Mozilla
wouldn't care because it doesn't affect Firefox. But clearly
others could be affected.


Kurt

[Kurt Roeckx]

On Fri, Dec 16, 2016 at 09:41:08AM -0800, Ryan Sleevi wrote:
>

> Not trying to be snarky - just that if we're going to act upon your
> comment, actionable data and concerns are needed.
>
> Put more concretely:
> - Hypotheticals ("What about software foo?") should not be considered
> unless they're demonstrated
> - If they are demonstrated, the author/maintainers of those packages
> should be engaging with the Mozilla community to represent those
> concerns
>
> So let's say, for example, that Curl was using the Mozilla set, but
> using it with a GnuTLS validator, and was concerned about a direction
> that Mozilla would take - wanting additional time or to push back on
> that. It seems eminently reasonable to expect that both the
> maintainers of Curl and GnuTLS's validator would step up and
> participate, representing those concerns, and be open/amenable to
> changes or to explaining why changes may not work.
>
> Absent that, as an upstream project, it seems entirely reasonable that
> a decision is made, on list, and unless someone comes up with specific
> and concrete objections (with a plan for remediating or exploring the
> problem more), then it goes forward. For example, "This would break
> Curl, and we'd need a new version of GnuTLS to support [X]. Could you
> wait on making this change for 3 months so that we can get a new
> release out?" is a concrete and actionable plan :)

So I guess I should also reply to the rest here.

I am a Debian Developer and an OpenSSL developer, but I'm not
speaking in anybody's name. But I do want to represent concerns
that the general open source community might have that just isn't
active on this list. Maybe more of them should be active here, but
probably they just don't know about it.

In Debian we actually ship libcurl linked against gnutls, nss and
openssl. Just like we ship a whole lot of other software. Almost
all of the software that supports X509 makes use of the Mozilla root
store. There are clearly problems with the way it uses it, but we
should at least avoiding making it worse.

If there are such changes needed in other software, having that
software fixed in 3 month shouldn't acutally be a problem. But
unless someone is going to assign a CVE to it, it's probably not
going to get deployed.


Kurt

[Ryan Sleevi]

On Fri, Dec 16, 2016 at 11:56 AM, Kurt Roeckx <ku...@roeckx.be> wrote:
> So I guess I should also reply to the rest here.
>
> I am a Debian Developer and an OpenSSL developer, but I'm not
> speaking in anybody's name. But I do want to represent concerns
> that the general open source community might have that just isn't
> active on this list. Maybe more of them should be active here, but
> probably they just don't know about it.
>
> In Debian we actually ship libcurl linked against gnutls, nss and
> openssl. Just like we ship a whole lot of other software. Almost
> all of the software that supports X509 makes use of the Mozilla root
> store. There are clearly problems with the way it uses it, but we
> should at least avoiding making it worse.

Right, but if you're going to take a dependency on upstream (which
'Almost all of the software that supports X509 makes use of the
Mozilla root store' effectively is), you either need to accept
upstream's decisions and deal with it (just like any upstream project
can change an API) or participate with upstream.

So far, the answer has been "You make use at your own peril" -
although that's not because of apathy or active hostility towards
those projects, more to the side of "You should be participating with
and tracking upstream if you're going to depend on it"

Or, to use more Mozilla/Firefox terms:
- NSS (and Mozilla projects) are a Tier 1 platform for the Mozilla Root Store
- Distros that depend on the Mozilla Root Store, but actively
participate in development (e.g.: I'm looking at you, all you
wonderful Red Hat folks :P) are sort-of Tier 2 - it depends on the
breakage, but generally it's somewhere between 1&2
- Other software depending on the Mozilla Root Store is more akin to
Tier 3 or (worse) Tier 4.
- If you're participating and active in discussions, you're likely
between Tier 3 and Tier 2
- If you're just tracking upstream (*cough* Debian :P), and not
participating, you're really in that Tier 3 form (if you're paying
attention and maintaining it) or Tier 4 (if you're not even paying
attention and just taking it blindly)

> If there are such changes needed in other software, having that
> software fixed in 3 month shouldn't acutally be a problem. But
> unless someone is going to assign a CVE to it, it's probably not
> going to get deployed.

Sure, but that's kinda incumbent on downstream, much like a downstream
that 'abused' internal APIs is a perfectly justifiable target to break
/ not be concerned about.

[Brian Smith]

Gervase Markham <ge...@mozilla.org> wrote:
> On 10/12/16 21:25, Brian Smith wrote:

>> Again, it doesn't make sense to say that the forms of names matter for
>> name constraints, but don't matter for end-entity certificates. If an
>> end-entity certificate doesn't contain any names of the forms dNSName,
>> iPAddress, SRVName, rfc822Name, then it shouldn't be in scope.
>

> Why would it have id-kp-serverAuth or id-kp-emailProtection and not have
> any names of those forms?

I'm more thinking of certificates that don't have an EKU extension but
do have names of those forms. Such certificates should be in scope.

Otherwise, A CA can easily issue just a certificate that is trusted
for every browser except Firefox, which is out of scope for Mozilla's
CA program. A CA might do this, for example, if Mozilla were being
more difficult than other root stores and/or the customer in question
doesn't care if the site works in Firefox or not.

>> Also, the way that the text is worded the above means that an
>> intermediate certificate that contains anyExtendedKeyUsage in its EKU
>> would be considered out of scope of Mozilla's policy. However, you
>> need to have such certificates be in scope so that you can forbid them
>> from using anyExtendedKeyUsage.
>

> Well, there are two responses to that.
>
> Firstly, no. The certs in scope are: "Intermediate certificates ...

> which are not technically constrained such that they are unable to issue

> working server or email certificates." If an intermediate certificate
> has an EKU with anyEKU, it is able to issue working server or email
> certificates. So it's in scope. (This utilises my use of "working"
> rather than "trusted", as noted in my previous email.)

What does "working" mean? If I were a CA I would interpret "working"
to mean "works in Firefox" which would then allow me to issue
certificates that violate Mozilla's CA policies by issuing them from
an intermediate that has (only) anyExtendedKeyUsage, so that they work
in every browser except Firefox and are out of scope of your policy.

> But secondly, I'm not banning the use of anyEKU, because Firefox doesn't
> trust cert chains that rely on it, so there's no need to ban it. Is there?

Again, the reason for banning anyEKU is to prevent, through policy,
CAs from using/issuing intermediate certificates that work in every
browser except Firefox, for whatever reason (most likely, to work
around a CA policy disagreement).

[Gervase Markham]

On 16/12/16 21:56, Brian Smith wrote:
> What does "working" mean? If I were a CA I would interpret "working"
> to mean "works in Firefox"

Working means, I guess, "RFC 5280 etc. expect it to work". Conflicting
name constraints, no-one expects to work. AnyEKU, some people do.

> which would then allow me to issue
> certificates that violate Mozilla's CA policies by issuing them from
> an intermediate that has (only) anyExtendedKeyUsage, so that they work
> in every browser except Firefox and are out of scope of your policy.

If they are out of scope of our policy, and not trusted by Firefox, why
do we care if they violate it?

> Again, the reason for banning anyEKU is to prevent, through policy,
> CAs from using/issuing intermediate certificates that work in every
> browser except Firefox, for whatever reason (most likely, to work
> around a CA policy disagreement).

It would help greatly if you proposed concrete alternative text instead
of making (difficult to fuly comprehend) assertions about the inadequacy
of the current draft.

Gerv

[Gervase Markham]

On 08/12/16 20:46, Gervase Markham wrote:
> We want to change the policy to make it clear that whether a cert is
> covered by our policy or not is dependent on whether it is technically
> capable of issuing server certs, not whether it is intended by the CA
> for issuing server certs.
>
> Until we change Firefox to require id-kp-serverAuth, the policy will
> define "capable" as "id-kp-serverAuth or no EKU".
>
> This involves a number of wording tweaks; the full set of changes are here:
> https://github.com/mozilla/pkipolicy/compare/issue-27

Resolution: latest version of this branch merged. Thanks to everyone for
helping improve the wording; I think what we have now will suffice.

Gerv