Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Can we require id-kp-serverAuth now?

656 views
Skip to first unread message

Gervase Markham

unread,
Nov 9, 2016, 4:59:10 AM11/9/16
to mozilla-dev-s...@lists.mozilla.org
At the moment, Firefox recognises an EE cert as a server cert if it has
an EKU extension with id-kp-serverAuth, or if it has no EKU at all.

On 17th of Feb 2013, Mozilla published CA policy 2.1, which required
adherence to the BRs (version 1.1.5).[0]

Since the very first version of the BRs[1], EKU and id-kp-serverAuth has
been mandatory for EE server certificates.

The current maximum lifetime of a BR cert is 39 months. 17th Feb 2013 is
more than 39 months ago. (Even if it were previously possible to issue
longer certs and some may still be around, those will all be SHA-1, and
so no longer work from January. There may also have been an intro period
for BR compliance, but even with that, we must be pretty much hitting 39
months now.)

So, it is now possible to change Firefox to mandate the presence of
id-kp-serverAuth for EE server certs from Mozilla-trusted roots? Or is
there some reason I've missed we can't do that?

The advantage of doing this is that it makes it much easier to scope our
root program to avoid capturing certs it's not meant to capture.

Gerv


[0]
http://web.archive.org/web/20130217001843/http://www.mozilla.org/projects/security/certs/policy/
[1] https://cabforum.org/wp-content/uploads/Baseline_Requirements_V1.pdf
, Appendix B

Kurt Roeckx

unread,
Nov 9, 2016, 5:44:13 AM11/9/16
to mozilla-dev-s...@lists.mozilla.org
On 2016-11-09 10:58, Gervase Markham wrote:
> At the moment, Firefox recognises an EE cert as a server cert if it has
> an EKU extension with id-kp-serverAuth, or if it has no EKU at all.

So not when the anyExtendedKeyUsage is present?

> On 17th of Feb 2013, Mozilla published CA policy 2.1, which required
> adherence to the BRs (version 1.1.5).[0]
>
> Since the very first version of the BRs[1], EKU and id-kp-serverAuth
> has been mandatory for EE server certificates.

I can't actually find this anymore in the current BRs.

> So, it is now possible to change Firefox to mandate the presence of
> id-kp-serverAuth for EE server certs from Mozilla-trusted roots? Or is
> there some reason I've missed we can't do that?
>
> The advantage of doing this is that it makes it much easier to scope our
> root program to avoid capturing certs it's not meant to capture.

I wanted to look up stats to see how common this still is. But I sort of
have a problem with this, since the EKU is the best indicator I have to
know if something needs to comply with the BRs or not.

But I guess I can at least let it give a message when no EKU is present.


Kurt

Nick Lamb

unread,
Nov 9, 2016, 7:17:49 AM11/9/16
to mozilla-dev-s...@lists.mozilla.org
On Wednesday, 9 November 2016 09:59:10 UTC, Gervase Markham wrote:
> The current maximum lifetime of a BR cert is 39 months. 17th Feb 2013 is
> more than 39 months ago. (Even if it were previously possible to issue
> longer certs and some may still be around, those will all be SHA-1, and
> so no longer work from January. There may also have been an intro period
> for BR compliance, but even with that, we must be pretty much hitting 39
> months now.)

I am not always very clear on how Censys queries work, but I believe this query is a useful starting point (within the limited context of Censys)

current_valid_nss: true AND (NOT parsed.extensions.extended_key_usage:1)

A couple of examples that look to me as though they might be able to be installed in a web server yet lack the EKU:

https://censys.io/certificates/127f386498e3cfd330e40699b92efb68b72bfaa08af68f9a0fe959b1fea3ae9c

https://censys.io/certificates/c52d1aa01fbc3e7095d8c6336423590fdad7b003304f6b73ed835e36f8f802b3


> So, it is now possible to change Firefox to mandate the presence of
> id-kp-serverAuth for EE server certs from Mozilla-trusted roots? Or is
> there some reason I've missed we can't do that?

I would be astonished if there were literally no certificates in use on web servers which will get rejected as a result of this change. So the question is how much pain it's worth and whether it helps to wait another year or so.

Gervase Markham

unread,
Nov 9, 2016, 7:54:04 AM11/9/16
to Kurt Roeckx
On 09/11/16 10:43, Kurt Roeckx wrote:
> On 2016-11-09 10:58, Gervase Markham wrote:
>> At the moment, Firefox recognises an EE cert as a server cert if it has
>> an EKU extension with id-kp-serverAuth, or if it has no EKU at all.
>
> So not when the anyExtendedKeyUsage is present?

No. I believe we discovered we don't support that.

>> Since the very first version of the BRs[1], EKU and id-kp-serverAuth
>> has been mandatory for EE server certificates.
>
> I can't actually find this anymore in the current BRs.

Section 7.1.2.3.

Gerv

Gervase Markham

unread,
Nov 9, 2016, 8:03:37 AM11/9/16
to Nick Lamb
On 09/11/16 12:17, Nick Lamb wrote:

> I am not always very clear on how Censys queries work, but I believe this query is a useful starting point (within the limited context of Censys)
>
> current_valid_nss: true AND (NOT parsed.extensions.extended_key_usage:1)

That query produces 8,090 results over 324 pages. Does censys.io have a
CSV export or similar?

> A couple of examples that look to me as though they might be able to be installed in a web server yet lack the EKU:
>
> https://censys.io/certificates/127f386498e3cfd330e40699b92efb68b72bfaa08af68f9a0fe959b1fea3ae9c

This one's in the Federal Bridge maze. Not in crt.sh. I can't seem to
use censys.io to work out why it thinks we trust it, because I thought
that we didn't trust all of that stuff.

> https://censys.io/certificates/c52d1aa01fbc3e7095d8c6336423590fdad7b003304f6b73ed835e36f8f802b3

Chains up to Globalsign's root. Revoked by the CA:
https://crt.sh/?sha256=c52d1aa01fbc3e7095d8c6336423590fdad7b003304f6b73ed835e36f8f802b3

> I would be astonished if there were literally no certificates in use
> on web servers which will get rejected as a result of this change. So
> the question is how much pain it's worth and whether it helps to wait
> another year or so.

Am I right, though, that all such certs would be BR violations? Or is
there something I've missed?

Gerv


Rob Stradling

unread,
Nov 9, 2016, 8:27:35 AM11/9/16
to Gervase Markham, Nick Lamb, mozilla-dev-s...@lists.mozilla.org
On 09/11/16 13:02, Gervase Markham wrote:
<snip>
>> A couple of examples that look to me as though they might be able to be installed in a web server yet lack the EKU:
>>
>> https://censys.io/certificates/127f386498e3cfd330e40699b92efb68b72bfaa08af68f9a0fe959b1fea3ae9c
>
> This one's in the Federal Bridge maze. Not in crt.sh.

I just submitted it to the (really quick to include submitted certs)
WoSign log, so this URL should work soon:
https://crt.sh/?sha256=127f386498e3cfd330e40699b92efb68b72bfaa08af68f9a0fe959b1fea3ae9c

> I can't seem to
> use censys.io to work out why it thinks we trust it, because I thought
> that we didn't trust all of that stuff.

Paths from this cert up to an NSS built-in root do exist, but they all
contain at least one expired or revoked intermediate.

I'm guessing that Censys isn't considering the revocation status of
intermediates in the manner that crt.sh does.

See here: https://crt.sh/?caid=373&opt=mozilladisclosure

<snip>

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

Jakob Bohm

unread,
Nov 9, 2016, 9:07:01 AM11/9/16
to mozilla-dev-s...@lists.mozilla.org
On 09/11/2016 14:26, Rob Stradling wrote:
> ...
> On 09/11/16 13:02, Gervase Markham wrote:
>> ...
>> I can't seem to
>> use censys.io to work out why it thinks we trust it, because I thought
>> that we didn't trust all of that stuff.
>
> Paths from this cert up to an NSS built-in root do exist, but they all
> contain at least one expired or revoked intermediate.
>
> I'm guessing that Censys isn't considering the revocation status of
> intermediates in the manner that crt.sh does.
>
> See here: https://crt.sh/?caid=373&opt=mozilladisclosure
>

Did I hear rumors that some browsers don't check this either?


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

Jeremy Rowley

unread,
Nov 9, 2016, 11:11:00 AM11/9/16
to Gervase Markham, Kurt Roeckx, mozilla-dev-s...@lists.mozilla.org
7.1.2.3 requires an EKU but does not require serverAuth. clientAuth is
permissible. Omitting other values is only a "SHOULD"

This is back to the same problem we keep going round and round again. Only
certificates intended for web servers are considered in scope of the BRs.
Therefore, the BRs only require an EKU if the certs are intended for
webservers.

Regardless of the BRs, I whole heartedly support excluding a lack of EKU or
inclusion of the anyEKU from operating as a server cert.

Jeremy


-----Original Message-----
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla
.org] On Behalf Of Gervase Markham
Sent: Wednesday, November 9, 2016 5:53 AM
To: Kurt Roeckx <ku...@roeckx.be>;
mozilla-dev-s...@lists.mozilla.org
Subject: Re: Can we require id-kp-serverAuth now?

On 09/11/16 10:43, Kurt Roeckx wrote:
> On 2016-11-09 10:58, Gervase Markham wrote:
>> At the moment, Firefox recognises an EE cert as a server cert if it
>> has an EKU extension with id-kp-serverAuth, or if it has no EKU at all.
>
> So not when the anyExtendedKeyUsage is present?

No. I believe we discovered we don't support that.

>> Since the very first version of the BRs[1], EKU and id-kp-serverAuth
>> has been mandatory for EE server certificates.
>
> I can't actually find this anymore in the current BRs.

Section 7.1.2.3.

Gerv

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

Rob Stradling

unread,
Nov 9, 2016, 11:56:54 AM11/9/16
to Jakob Bohm, mozilla-dev-s...@lists.mozilla.org
On 09/11/16 14:06, Jakob Bohm wrote:
> On 09/11/2016 14:26, Rob Stradling wrote:
>> ...
>> On 09/11/16 13:02, Gervase Markham wrote:
>>> ...
>>> I can't seem to
>>> use censys.io to work out why it thinks we trust it, because I thought
>>> that we didn't trust all of that stuff.
>>
>> Paths from this cert up to an NSS built-in root do exist, but they all
>> contain at least one expired or revoked intermediate.
>>
>> I'm guessing that Censys isn't considering the revocation status of
>> intermediates in the manner that crt.sh does.
>>
>> See here: https://crt.sh/?caid=373&opt=mozilladisclosure
>
> Did I hear rumors that some browsers don't check this either?

It's true that not all browsers support all revocation methods.
However, the context of Gerv's comment and my response was Mozilla
browsers and the revocation methods that are supported by Mozilla browsers.

Specifically, Gerv was wondering why Censys was declaring the FPKI to be
trusted by Mozilla when we know that the FPKI has in fact been
distrusted by Mozilla via OneCRL.

Gervase Markham

unread,
Nov 9, 2016, 12:33:19 PM11/9/16
to Jeremy Rowley, Kurt Roeckx
On 09/11/16 16:10, Jeremy Rowley wrote:
> 7.1.2.3 requires an EKU but does not require serverAuth. clientAuth is
> permissible.

Yes, that is true, but I'm not sure it's relevant to the point. There
are two types of BR-compatible cert:

EKU-serverAuth
EKU-clientAuth

Either may have other EKUs too, but all will have at least one of those.
No EKU is not permitted. And the EKU-clientAuth ones won't be trusted by
Firefox for server auth, clearly.

> This is back to the same problem we keep going round and round again. Only
> certificates intended for web servers are considered in scope of the BRs.
> Therefore, the BRs only require an EKU if the certs are intended for
> webservers.

I intend to fix Mozilla policy to rescope the BRs more clearly.
https://github.com/mozilla/pkipolicy/issues/27

Gerv

Nick Lamb

unread,
Nov 9, 2016, 1:08:23 PM11/9/16
to mozilla-dev-s...@lists.mozilla.org
On Wednesday, 9 November 2016 13:03:37 UTC, Gervase Markham wrote:
> On 09/11/16 12:17, Nick Lamb wrote:
>
> > I am not always very clear on how Censys queries work, but I believe this query is a useful starting point (within the limited context of Censys)
> >
> > current_valid_nss: true AND (NOT parsed.extensions.extended_key_usage:1)
>
> That query produces 8,090 results over 324 pages. Does censys.io have a
> CSV export or similar?

Censys.io has a RESTful API. They recommend using a Python library to access it. My Python is... crude and unidiomatic but functional - if it seems to me in this or some future thread that the group would benefit from a text dump of relevant certificates I will certainly make one.

So far in this case I think it isn't so useful so I won't do it yet.

> Am I right, though, that all such certs would be BR violations? Or is
> there something I've missed?

Yes, I think a public CA issuing a certificate for a web server or similar was obliged all the way from version 1 of the Baseline Requirements to add this EKU to the certificate. Since Firefox soon won't trust very old (SHA-1) certificates anyway, and has never intended to trust non-BR compliant Certificate Authorities such as the Federal Bridge, that seems to cover everything.

Isn't there still some value in estimating the impact?

Peter Bowen

unread,
Nov 9, 2016, 1:50:25 PM11/9/16
to Gervase Markham, mozilla-dev-s...@lists.mozilla.org
On Wed, Nov 9, 2016 at 1:58 AM, Gervase Markham <ge...@mozilla.org> wrote:
> So, it is now possible to change Firefox to mandate the presence of
> id-kp-serverAuth for EE server certs from Mozilla-trusted roots? Or is
> there some reason I've missed we can't do that?

Here are some certs that appear to be for server authentication but
don't have that EKU:

https://crt.sh/?id=10621190
https://crt.sh/?id=32333854
https://crt.sh/?id=10621157
https://crt.sh/?id=12283906
https://crt.sh/?id=12797412

Jeremy Rowley

unread,
Nov 9, 2016, 1:55:37 PM11/9/16
to Peter Bowen, Gervase Markham, mozilla-dev-s...@lists.mozilla.org
Perhaps the CA didn't intend them to be used for Web PKI, making them out of
scope of the BRs. Playing devil's advocate, I'd say anything issued without
serverAuth isn't intended to be used for server authentication by the CA.
Because of this, either the CAB Forum should define all certs with anyEKU,
serverAuth or no EKU as in scope of the BRs or the browsers should require
an EKU to function.

-----Original Message-----
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla
.org] On Behalf Of Peter Bowen
Sent: Wednesday, November 9, 2016 11:50 AM
To: Gervase Markham <ge...@mozilla.org>
Cc: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Can we require id-kp-serverAuth now?

Peter Bowen

unread,
Nov 9, 2016, 1:58:09 PM11/9/16
to Jeremy Rowley, mozilla-dev-s...@lists.mozilla.org, Gervase Markham
I think it makes sense to have a new doc that applies to all CAs and
specifies when requirements apply to certificates. That way we can
say "SSL BRs apply if X, S/MIME BRs apply if Y, Code Signing applies
if Z, this doc applies to subCAs when A".

Kurt Roeckx

unread,
Nov 9, 2016, 2:47:05 PM11/9/16
to Peter Bowen, Gervase Markham, mozilla-dev-s...@lists.mozilla.org, Jeremy Rowley
On Wed, Nov 09, 2016 at 10:57:54AM -0800, Peter Bowen wrote:
> I think it makes sense to have a new doc that applies to all CAs and
> specifies when requirements apply to certificates. That way we can
> say "SSL BRs apply if X, S/MIME BRs apply if Y, Code Signing applies
> if Z, this doc applies to subCAs when A".

I agree that I consider a lot of things in the BR requirements to
be relevant for all certificates and not just those for SSL. It
seems that just a minor part of the BR documents are actually
specific to SSL.


Kurt

Nick Lamb

unread,
Nov 9, 2016, 2:57:54 PM11/9/16
to mozilla-dev-s...@lists.mozilla.org
On Wednesday, 9 November 2016 18:50:25 UTC, Peter Bowen wrote:
> Here are some certs that appear to be for server authentication but
> don't have that EKU:
>
> https://crt.sh/?id=10621190

I didn't look at all of these, but
* The issuer isn't trusted by Mozilla, so arguably it's out of scope in this discussion
* Some DNS names listed are clearly not FQDNs from the public Internet. As such although it was not in violation as issued, a BR-compliant CA should have revoked this certificate no later than 1st October 2016. But so far as I can tell although the issuing CA seems somewhat broken it still exists and did not revoke this certificate.

Gervase Markham

unread,
Nov 10, 2016, 7:51:19 AM11/10/16
to mozilla-dev-s...@lists.mozilla.org
On 09/11/16 18:50, Peter Bowen wrote:
> Here are some certs that appear to be for server authentication but
> don't have that EKU:
>
> https://crt.sh/?id=10621190

This one also contains Internal Server Names. And it contains bogus info
in the Certificate Policies field. But it's not trusted by Mozilla.

> https://crt.sh/?id=32333854
> https://crt.sh/?id=10621157

Both not trusted by Mozilla.

> https://crt.sh/?id=12283906

Another BR-non-compliant cert from Postecom - see Digicert's recent post
on what's happening there. :-|

> https://crt.sh/?id=12797412

This one chains up to the Taiwanese Government Root CA (GRCA). It's not
revoked. Seems like a BR violation to me.

Gerv

Gervase Markham

unread,
Nov 10, 2016, 10:28:44 AM11/10/16
to mozilla-dev-s...@lists.mozilla.org
On 09/11/16 09:58, Gervase Markham wrote:
> So, it is now possible to change Firefox to mandate the presence of
> id-kp-serverAuth for EE server certs from Mozilla-trusted roots? Or is
> there some reason I've missed we can't do that?

I've emailed the engineering team within Mozilla to see if they are
happy just dropping support, or whether they want telemetry first.

Gerv

Gervase Markham

unread,
Nov 14, 2016, 4:20:07 AM11/14/16
to mozilla-dev-s...@lists.mozilla.org
On 09/11/16 09:58, Gervase Markham wrote:
> So, it is now possible to change Firefox to mandate the presence of
> id-kp-serverAuth for EE server certs from Mozilla-trusted roots? Or is
> there some reason I've missed we can't do that?

I don't think there is, so I've filed a bug on it:

https://bugzilla.mozilla.org/show_bug.cgi?id=1317245

Gerv


Brian Smith

unread,
Dec 2, 2016, 10:42:19 PM12/2/16
to Gervase Markham, mozilla-dev-s...@lists.mozilla.org
On Tue, Nov 8, 2016 at 11:58 PM, Gervase Markham <ge...@mozilla.org> wrote:

> At the moment, Firefox recognises an EE cert as a server cert if it has
> an EKU extension with id-kp-serverAuth, or if it has no EKU at all.
>

The EKU extension indicates the limits of the key usage. A certificate
without an EKU extension has no limits on its key usage. In particular,
when no EKU is present, id-kp-serverAuth is allowed, as far as the CA is
concerned. Many X.509 features are defined this way, where the default is
"no limit"--pretty much all of them. The advantage of omitting these
extensions is that the resulting certificates are smaller. Smaller
certificates are better. Therefore, Mozilla should encourage behaviors that
result in smaller certificates, including in particular omitting the EKU
extension and other extensions where the defaults "work."

The problem is that CAB Forum stuff is defined in terms of "intended for,"
which is different than "trusted for." So, for example, some CAs have
argued that they issue certificates that say they are trusted for
id-kp-serverAuth (because they have no EKU), but since they're not
"intended for" id-kp-serverAuth, the baseline requirements don't apply to
them.

The solution to this problem is to get rid of the idea of "intent" from the
CA policy (including the baseline requirements, or in spit of the BRs if
the BRs cannot be changed), so that all that matters is the RFC 5280
"trusted for" semantics.

So, it is now possible to change Firefox to mandate the presence of
> id-kp-serverAuth for EE server certs from Mozilla-trusted roots? Or is
> there some reason I've missed we can't do that?
>

I'd like to point out that I've given the above explanation to you multiple
times.


> The advantage of doing this is that it makes it much easier to scope our
> root program to avoid capturing certs it's not meant to capture.
>

This is not true. Since no EKU extension implies id-kp-serverAuth, certs
without an EKU extension or with an EKU extension containing
id-kp-serverAuth or anyExtendedKeyUsage (even though Firefox doesn't
support that) should be within the scope of the program. You simply need to
define the scope of the program in terms of the **technical** semantics.

Cheers,
Brian

Gervase Markham

unread,
Dec 4, 2016, 5:10:51 AM12/4/16
to Brian Smith
On 03/12/16 03:42, Brian Smith wrote:
> The EKU extension indicates the limits of the key usage. A certificate
> without an EKU extension has no limits on its key usage. In particular,
> when no EKU is present, id-kp-serverAuth is allowed, as far as the CA is
> concerned. Many X.509 features are defined this way, where the default is
> "no limit"--pretty much all of them. The advantage of omitting these
> extensions is that the resulting certificates are smaller. Smaller
> certificates are better. Therefore, Mozilla should encourage behaviors that
> result in smaller certificates, including in particular omitting the EKU
> extension and other extensions where the defaults "work."

But this is not the only factor.

> The solution to this problem is to get rid of the idea of "intent" from the
> CA policy (including the baseline requirements, or in spit of the BRs if
> the BRs cannot be changed), so that all that matters is the RFC 5280
> "trusted for" semantics.

We intend to do that for the Mozilla policy. However, that then widens
the scope of the policy massively. It makes it cover, if I remember the
example correctly, millions of EKU-less certs on smart cards used for a
government ID program in Europe. These are not intended for server use,
but they are trusted for it, and so a misissuance here such that
something appears in a CN or SAN that is domain-name-like would mean
that cert could be used for a server.

This is why a change to "trusted for" rather than "intended for" needs
to be accompanied by a change to explicitly require id-kp-serverAuth, in
order to keep the scope correct, and stop the Mozilla policy extending
to cover certificates it's not supposed to cover and which CAs don't
want it to cover.

Requiring that every issuance under the publicly-trusted roots which is
using no EKU and which is not intended for server auth change to use an
EKU which explicitly does not include id-kp-serverAuth would have
unknown ramifications of unknown size. Changing both the Mozilla policy
and Firefox to require id-kp-serverAuth is reasonably confidently known
to have only minor ramifications, and we know what they will be.

> I'd like to point out that I've given the above explanation to you multiple
> times.

Have I explained why it's not determinative multiple times, or is this
the first time? :-)

>> The advantage of doing this is that it makes it much easier to scope our
>> root program to avoid capturing certs it's not meant to capture.
>
> This is not true. Since no EKU extension implies id-kp-serverAuth, certs
> without an EKU extension or with an EKU extension containing
> id-kp-serverAuth or anyExtendedKeyUsage (even though Firefox doesn't
> support that) should be within the scope of the program.

But given the current situation, doing that extends the scope of the
program beyond where we want it to be, and where CAs want it to be.

Gerv

Brian Smith

unread,
Dec 4, 2016, 10:11:49 PM12/4/16
to Gervase Markham, mozilla-dev-s...@lists.mozilla.org
Gervase Markham <ge...@mozilla.org> wrote:

> On 03/12/16 03:42, Brian Smith wrote:
> > The solution to this problem is to get rid of the idea of "intent" from
> the
> > CA policy (including the baseline requirements, or in spit of the BRs if
> > the BRs cannot be changed), so that all that matters is the RFC 5280
> > "trusted for" semantics.
>
> We intend to do that for the Mozilla policy. However, that then widens
> the scope of the policy massively. It makes it cover, if I remember the
> example correctly, millions of EKU-less certs on smart cards used for a
> government ID program in Europe. These are not intended for server use,
> but they are trusted for it, and so a misissuance here such that
> something appears in a CN or SAN that is domain-name-like would mean
> that cert could be used for a server.
>

If certificates without an EKU have dNSName or iPAddress subjectAltName
entries, then they should be considered in scope. Otherwise they don't need
to be considered in scope as long as Firefox doesn't use the Subject CN as
a dNSName. You've already started down the path of fixing the Subject CN
issue in https://bugzilla.mozilla.org/show_bug.cgi?id=1245280 and maybe
elsewhere.


> This is why a change to "trusted for" rather than "intended for" needs
> to be accompanied by a change to explicitly require id-kp-serverAuth, in
> order to keep the scope correct, and stop the Mozilla policy extending
> to cover certificates it's not supposed to cover and which CAs don't
> want it to cover.
>

See above. I bet that you can make the subjectAltName restrictions tighter
so that "trusted for" already works without requiring an explicit EKU.


> Requiring that every issuance under the publicly-trusted roots which is
> using no EKU and which is not intended for server auth change to use an
> EKU which explicitly does not include id-kp-serverAuth would have
> unknown ramifications of unknown size.


This is a textbook instance of FUD.


> Changing both the Mozilla policy
> and Firefox to require id-kp-serverAuth is reasonably confidently known
> to have only minor ramifications, and we know what they will be.
>

AFAICT almost all Mozilla software except for Firefox and Thunderbird,
would still trust the EKU-less certificates for id-kp-serverAuth. Thus
requiring an explicit id-kp-serverAuth in Firefox wouldn't even have the
intended ramifications for all of Mozilla's products.

Also, pretty much all non-Mozilla software is using RFC 5280 semantics
already. So, such a change wouldn't do anything to help non-Mozilla
software nor even all of Mozilla's products.


> >> The advantage of doing this is that it makes it much easier to scope our
> >> root program to avoid capturing certs it's not meant to capture.
> >
> > This is not true. Since no EKU extension implies id-kp-serverAuth, certs
> > without an EKU extension or with an EKU extension containing
> > id-kp-serverAuth or anyExtendedKeyUsage (even though Firefox doesn't
> > support that) should be within the scope of the program.
>
> But given the current situation, doing that extends the scope of the
> program beyond where we want it to be, and where CAs want it to be.
>

Limiting the scope to things that contain dNSName and iPAddress
subjectAltNames addresses this, right? And, more importantly, it addresses
it in a way that makes sense considering that other software doesn't
require an explicit EKU, because it doesn't rely on Firefox-specific
semantics.

To be clear, I'm not against the idea of Firefox making a technical change
that others have to catch up with, like name constraints. However, that
should be a last resort. There seems to be a better alternative in this
case.

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

Gervase Markham

unread,
Dec 5, 2016, 8:06:28 AM12/5/16
to Brian Smith
On 04/12/16 19:11, Brian Smith wrote:
> If certificates without an EKU have dNSName or iPAddress subjectAltName
> entries, then they should be considered in scope. Otherwise they don't need
> to be considered in scope as long as Firefox doesn't use the Subject CN as
> a dNSName. You've already started down the path of fixing the Subject CN
> issue in https://bugzilla.mozilla.org/show_bug.cgi?id=1245280 and maybe
> elsewhere.

That would be an alternative way to do it. The problem is that if you
try and do it this way, the issuing CA is always in scope for all its
issuances, because whether the certs it issues have these features is
inevitably a matter of CA policy, and could change at any time.
Therefore, the issuing CA has to be run in a BR-compliant way all the time.

Doing it based on the technical capabilities of the issuing CA allows us
to say "we don't care about any certs this CA issues", rather than "we
might care about some of the certs this CA has issued; we now have to
find and examine them all to see".

>> Requiring that every issuance under the publicly-trusted roots which is
>> using no EKU and which is not intended for server auth change to use an
>> EKU which explicitly does not include id-kp-serverAuth would have
>> unknown ramifications of unknown size.
>
> This is a textbook instance of FUD.

No; FUD is where someone raises uncertainties about a process or move
where the ramifications are actually pretty certain. Is my statement
false? Do you know what kind of impact it would have on the 60+ CAs in
our root program to tell them that they have to reissue every
intermediate in their publicly-trusted hierarchies to contain
non-server-auth name constraints?

> AFAICT almost all Mozilla software except for Firefox and Thunderbird,
> would still trust the EKU-less certificates for id-kp-serverAuth. Thus
> requiring an explicit id-kp-serverAuth in Firefox wouldn't even have the
> intended ramifications for all of Mozilla's products.

Are you talking about Firefox for iOS? Or something else?

> Also, pretty much all non-Mozilla software is using RFC 5280 semantics
> already. So, such a change wouldn't do anything to help non-Mozilla
> software nor even all of Mozilla's products.

Well, our policy doesn't take explicit account of non-Mozilla software :-)

I want the scope of what our software trusts to match the scope of what
our policy controls, and I want that united scope to both incorporate
all or the vast majority of certificates people are actually using for
server-auth, and to have clear and enforceable boundaries which are
administratively convenient for CAs and us. I think requiring
id-kp-serverAuth does that.

Gerv

Brian Smith

unread,
Dec 5, 2016, 5:43:56 PM12/5/16
to Gervase Markham, mozilla-dev-s...@lists.mozilla.org
Gervase Markham <ge...@mozilla.org> wrote:

> On 04/12/16 19:11, Brian Smith wrote:
> > If certificates without an EKU have dNSName or iPAddress subjectAltName
> > entries, then they should be considered in scope. Otherwise they don't
> need
> > to be considered in scope as long as Firefox doesn't use the Subject CN
> as
> > a dNSName. You've already started down the path of fixing the Subject CN
> > issue in https://bugzilla.mozilla.org/show_bug.cgi?id=1245280 and maybe
> > elsewhere.
>
> That would be an alternative way to do it. The problem is that if you
> try and do it this way, the issuing CA is always in scope for all its
> issuances, because whether the certs it issues have these features is
> inevitably a matter of CA policy, and could change at any time.
> Therefore, the issuing CA has to be run in a BR-compliant way all the time.
>

Let's consider the cases:

A root CA: It is in scope if it has the SSL trust bit.

An intermediate CA: It is in scope unless all the trusted certificates
issued for it have an EKU that excludes id-kp-serverAuth.

This is true regardless of whether you require an explicit id-kp-serverAuth
in the end-entity certificates, and/or if you base it on the subjectAltName
entries like I suggest, right? Because, at any time, the CA could issue an
end-entity certificate with id-kp-serverAuth in its EKU and/or a
certificate with a dNSName or iPAddress in its subjectAltNames.


> Doing it based on the technical capabilities of the issuing CA allows us
> to say "we don't care about any certs this CA issues", rather than "we
> might care about some of the certs this CA has issued; we now have to
> find and examine them all to see".
>

I do very much agree with this! But, what matters is the constraints placed
on the CA's certificate, not on the end-entity certificates it issues,
right?

Do you know what kind of impact it would have on the 60+ CAs in
> our root program to tell them that they have to reissue every
> intermediate in their publicly-trusted hierarchies to contain
> non-server-auth name constraints?
>

I wasn't suggesting anything to do with name constraints.

However, I do think that if a CA certificate is name constrained to not
allow any dNSName or iPAddress names, and/or it EKU that doesn't contain
id-kp-serverAuth, then it shouldn't be in scope of the proposal. Either
condition is sufficient.



> > AFAICT almost all Mozilla software except for Firefox and Thunderbird,
> > would still trust the EKU-less certificates for id-kp-serverAuth. Thus
> > requiring an explicit id-kp-serverAuth in Firefox wouldn't even have the
> > intended ramifications for all of Mozilla's products.
>
> Are you talking about Firefox for iOS? Or something else?
>

Besides Firefox for iOS, most other Mozilla software, such as software
written in Go or Python or anything except {Firefox, Thunderbird} for {Mac,
Windows, Linux}. IIUC, Firefox for Android sometimes contacts https://
servers using the native Android software stack, which won't require an
explicit EKU either.


> > Also, pretty much all non-Mozilla software is using RFC 5280 semantics
> > already. So, such a change wouldn't do anything to help non-Mozilla
> > software nor even all of Mozilla's products.
>
> Well, our policy doesn't take explicit account of non-Mozilla software :-)
>

That's true, but at the same time we want to have standardized behavior
right? Mozilla is or will be asking people to go beyond existing standards
by:

1. Honoring Microsoft's semantics for EKU in intermediates.
2. Dropping support for interpreting the subject CN as a domain name or IP
address.
3. Maybe requiring an explicit EKU in the end-entity certificate.

My point is that #1 and #2 are already sufficient to solve this problem.
Let's make it easy for people to agree with Mozilla, by not requiring more
than is necessary, #3.


> I want the scope of what our software trusts to match the scope of what
> our policy controls, and I want that united scope to both incorporate
> all or the vast majority of certificates people are actually using for
> server-auth, and to have clear and enforceable boundaries which are
> administratively convenient for CAs and us. I think requiring
> id-kp-serverAuth does that.
>

I think my proposal does the same, but in a way that's easier for other
software to adopt.

Rob Stradling

unread,
Dec 6, 2016, 4:46:35 AM12/6/16
to Brian Smith, Gervase Markham, mozilla-dev-s...@lists.mozilla.org
On 05/12/16 22:43, Brian Smith wrote:
<snip>
> That's true, but at the same time we want to have standardized behavior
> right? Mozilla is or will be asking people to go beyond existing standards
> by:
>
> 1. Honoring Microsoft's semantics for EKU in intermediates.
> 2. Dropping support for interpreting the subject CN as a domain name or IP
> address.
> 3. Maybe requiring an explicit EKU in the end-entity certificate.
>
> My point is that #1 and #2 are already sufficient to solve this problem.
> Let's make it easy for people to agree with Mozilla, by not requiring more
> than is necessary, #3.

Mozilla's CA Certificate Inclusion Policy already requires that
"issuance of certificates to be used for SSL-enabled servers must also
conform to" the BRs, and most other browser providers already require
this too.

For Subscriber Certificates, the CABForum BRs already require that...
"F. extKeyUsage (required)
Either the value id‐kp‐serverAuth [RFC5280] or id‐kp‐clientAuth
[RFC5280] or both values MUST be present."

Since the policy already requires #3, ISTM that the technical
implementation should enforce #3 (unless there's a really good reason
not to).

For it to make any sense to not enforce #3 technically, there would need
to be cross-industry agreement (and a corresponding update to the BRs)
that end-entity serverAuth certs need not contain the EKU extension.
Good luck with that!!

How much effort should we go to just to shave 21 bytes off the size of
each end-entity serverAuth cert?

0:d=0 hl=2 l= 19 cons: SEQUENCE
2:d=1 hl=2 l= 3 prim: OBJECT :X509v3 Extended Key Usage
7:d=1 hl=2 l= 12 prim: OCTET STRING
0000 - 30 0a 06 08 2b 06 01 05-05 07 03 01 0...+.......

Brian Smith

unread,
Dec 7, 2016, 5:45:09 PM12/7/16
to Rob Stradling, mozilla-dev-s...@lists.mozilla.org, Gervase Markham
Rob Stradling <rob.st...@comodo.com> wrote:

> Mozilla's CA Certificate Inclusion Policy already requires that "issuance
> of certificates to be used for SSL-enabled servers must also conform to"
> the BRs, and most other browser providers already require this too.
>
> For Subscriber Certificates, the CABForum BRs already require that...
> "F. extKeyUsage (required)
> Either the value id‐kp‐serverAuth [RFC5280] or id‐kp‐clientAuth
> [RFC5280] or both values MUST be present."
>
> Since the policy already requires #3, ISTM that the technical
> implementation should enforce #3 (unless there's a really good reason not
> to).
>

The policy (including the BRs) can and should be changed.

Notice in the BRs that the KeyUsage extension (not to be confused with the
ExtendedKeyUsage extension we're talking about here) is optional. Why is it
OK to be optional? Because the default implementation allows all usages,
including in particular the usages that browsers need.

Similarly, why are name constraints optional? Because the default is no
name constraints. Why are policy constraints optional? Because the default
is no constraints. In all these cases the defaults might be not as strict
as possible but they work out OK.


> For it to make any sense to not enforce #3 technically, there would need
> to be cross-industry agreement (and a corresponding update to the BRs) that
> end-entity serverAuth certs need not contain the EKU extension. Good luck
> with that!!
>

I would expect it to be easier than most other changes to the BRs, because
it doesn't require anybody to do any work.


> How much effort should we go to just to shave 21 bytes off the size of
> each end-entity serverAuth cert?
>

My proposal requires as close to zero effort as any proposal to change the
BRs.

In isolation, shaving off 21 bytes isn't a huge win. However, IIRC, based
on the last time we measured this, combined with other changes it adds up
to be, on average, larger than the size of the SCTs that we're adding to
certs and/or less than the size of an additional OCSP response (without
embedded signing cert) and/or the cost of a minimal OCSP response signing
cert.

Why don't browsers support OCSP multi-stapling (OCSP for intermediate CA
certs)? Part of the reason is that it would be inefficient because
certificates and OCSP responses are too big. Also some choose to avoid
using X.509 certificates completely due to size issues.

People are working on certificate compression to make certificates smaller.
See, for example, the messages in this thread:
https://www.ietf.org/mail-archive/web/tls/current/msg22065.html. Also see
Google's QUIC protocol, which implements compression. Unfortunately, not
every implementation can support GZIP-based compression, and it's a good
idea to minimize the size of the decompressed certs in any case. Also see
the work that BoringSSL/Chrome is doing to de-dupe certs in memory because
certs are taking up too much memory.

Also, like I said in my previous message, it seems like requiring the EKU
in the end-entity certificates doesn't actually solve the problem that it
was proposed to solve, so I'm not sure if there is any motivation for
requiring it now.

Gervase Markham

unread,
Dec 8, 2016, 2:53:49 PM12/8/16
to Brian Smith
On 05/12/16 12:43, Brian Smith wrote:
> Let's consider the cases:
>
> A root CA: It is in scope if it has the SSL trust bit.
>
> An intermediate CA: It is in scope unless all the trusted certificates
> issued for it have an EKU that excludes id-kp-serverAuth.

No; it's in scope unless it has constraints which prevent the issue of
(or rather, the trust of) certificates which contain id-kp-serverAuth.

> This is true regardless of whether you require an explicit id-kp-serverAuth
> in the end-entity certificates, and/or if you base it on the subjectAltName
> entries like I suggest, right? Because, at any time, the CA could issue an
> end-entity certificate with id-kp-serverAuth in its EKU and/or a
> certificate with a dNSName or iPAddress in its subjectAltNames.

Right, so your initial formulation is not correct. It's in scope whether
or not "all the trusted certificates issued for it [so far] have an EKU
that excludes id-kp-serverAuth".

> However, I do think that if a CA certificate is name constrained to not
> allow any dNSName or iPAddress names, and/or it EKU that doesn't contain
> id-kp-serverAuth, then it shouldn't be in scope of the proposal. Either
> condition is sufficient.

Are there not other relevant name types, such as svrName (or whatever
it's called)?

Gerv

Gervase Markham

unread,
Dec 8, 2016, 3:47:07 PM12/8/16
to Brian Smith, Rob Stradling
On 07/12/16 12:44, Brian Smith wrote:
> Notice in the BRs that the KeyUsage extension (not to be confused with the
> ExtendedKeyUsage extension we're talking about here) is optional. Why is it
> OK to be optional? Because the default implementation allows all usages,
> including in particular the usages that browsers need.

The fact that some defaults are suitable doesn't mean that all defaults
are suitable. You are assuming what you seek to prove.

> My proposal requires as close to zero effort as any proposal to change the
> BRs.

Changing the BRs in this way would (arguably, as the scope of the BRs is
a matter of ongoing debate, something we hope this line of work will
eventually clarify) bring a whole load of certs which are not currently
issued under the BRs and which aren't supposed to be under the BRs,
under the BRs. This is really quite obviously a bad idea.

Gerv

Brian Smith

unread,
Dec 8, 2016, 4:42:58 PM12/8/16
to Gervase Markham, mozilla-dev-s...@lists.mozilla.org
Gervase Markham <ge...@mozilla.org> wrote:
> On 05/12/16 12:43, Brian Smith wrote:
>> Let's consider the cases:
>>
>> A root CA: It is in scope if it has the SSL trust bit.
>>
>> An intermediate CA: It is in scope unless all the trusted certificates
>> issued for it have an EKU that excludes id-kp-serverAuth.
>
> No; it's in scope unless it has constraints which prevent the issue of
> (or rather, the trust of) certificates which contain id-kp-serverAuth.

Note I said "issued for", not "issued by". In particular, we are
saying the same thing, except that my statement acknowledges that an
intermediate CA may have multiple (intermediate) certificates with
different EKU (or name) constraints.

>> This is true regardless of whether you require an explicit id-kp-serverAuth
>> in the end-entity certificates, and/or if you base it on the subjectAltName
>> entries like I suggest, right? Because, at any time, the CA could issue an
>> end-entity certificate with id-kp-serverAuth in its EKU and/or a
>> certificate with a dNSName or iPAddress in its subjectAltNames.
>
> Right, so your initial formulation is not correct. It's in scope whether
> or not "all the trusted certificates issued for it [so far] have an EKU
> that excludes id-kp-serverAuth".

It's in scope regardless of the contents of the certificates issued
*by* it. The certificates issued *for* a CA are the intermediate CA
certificates that chain to it. The certificates issued *by* a CA are
the end-entity (or intermediate, if no path length constraints)
certificates.

Note that your proposal is talking about requiring id-kp-serverAuth in
the end-entity certificates issued *by* the CA, which shouldn't matter
insofar as determining scope is concerned.

>> However, I do think that if a CA certificate is name constrained to not
>> allow any dNSName or iPAddress names, and/or it EKU that doesn't contain
>> id-kp-serverAuth, then it shouldn't be in scope of the proposal. Either
>> condition is sufficient.
>
> Are there not other relevant name types, such as svrName (or whatever
> it's called)?

Fair point. But the constraint can be specified as a whitelist instead
of a blacklist: If the subjectAltName (and subject CN) consists only
of emailAddress and/or other non-webby names then it isn't in scope,
otherwise it is in scope.

Brian Smith

unread,
Dec 8, 2016, 4:49:22 PM12/8/16
to Gervase Markham, Rob Stradling, mozilla-dev-s...@lists.mozilla.org
Gervase Markham <ge...@mozilla.org> wrote:
> On 07/12/16 12:44, Brian Smith wrote:
>> Notice in the BRs that the KeyUsage extension (not to be confused with the
>> ExtendedKeyUsage extension we're talking about here) is optional. Why is it
>> OK to be optional? Because the default implementation allows all usages,
>> including in particular the usages that browsers need.
>
> The fact that some defaults are suitable doesn't mean that all defaults
> are suitable. You are assuming what you seek to prove.

In your proposal, an end-entity certificate is allowed to have any
EKUs in addition to id-kp-serverAuth, right? So, all EKUs are indeed
acceptable and so the default is acceptable.

> Changing the BRs in this way would (arguably, as the scope of the BRs is
> a matter of ongoing debate, something we hope this line of work will
> eventually clarify) bring a whole load of certs which are not currently
> issued under the BRs and which aren't supposed to be under the BRs,
> under the BRs.

If a certificate is in scope of the BRs then it must conform to the
requirements. In particular, it isn't the case that any certificate
that conforms to the requirements is in scope. Therefore, loosening
the requirements doesn't change the scope.

Gervase Markham

unread,
Dec 8, 2016, 4:50:24 PM12/8/16
to Brian Smith
On 05/12/16 12:43, Brian Smith wrote:
> However, I do think that if a CA certificate is name constrained to not
> allow any dNSName or iPAddress names, and/or it EKU that doesn't contain
> id-kp-serverAuth, then it shouldn't be in scope of the proposal. Either
> condition is sufficient.

Can we get a whitelist of types we care about? Note that we care about
email as well as server certs.

dNSName
iPAddress (this covers both v4 and v6?)
rfc822Name
SRVName

Any more?

Gerv

Brian Smith

unread,
Dec 8, 2016, 5:15:27 PM12/8/16
to Gervase Markham, mozilla-dev-s...@lists.mozilla.org
Gervase Markham <ge...@mozilla.org> wrote:
> On 05/12/16 12:43, Brian Smith wrote:
>> However, I do think that if a CA certificate is name constrained to not
>> allow any dNSName or iPAddress names, and/or it EKU that doesn't contain
>> id-kp-serverAuth, then it shouldn't be in scope of the proposal. Either
>> condition is sufficient.
>
> Can we get a whitelist of types we care about? Note that we care about
> email as well as server certs.
>
> dNSName
> iPAddress (this covers both v4 and v6?)
> rfc822Name
> SRVName

Here are the choices (from RFC 5280):

GeneralName ::= CHOICE {
otherName [0] OtherName,
rfc822Name [1] IA5String,
dNSName [2] IA5String,
x400Address [3] ORAddress,
directoryName [4] Name,
ediPartyName [5] EDIPartyName,
uniformResourceIdentifier [6] IA5String,
iPAddress [7] OCTET STRING,
registeredID [8] OBJECT IDENTIFIER }

Note that RFC 4985 defines srvName as an otherName { id-on 7}. See
also http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.8

If the issuing CA is trusted for email (as determined by root email
trust bit, and there are no EKU constraints that exclude
id-kp-emailProtection), then a certificate with an rfc822Name would be
in scope, unless all such names were excluded by the name constraints.

If the issuing CA is trusted for TLS (as determined by root SSL trust
bit, and there are no EKUs constraints that exclude id-kp-serverAuth),
then a certificate with dNSName and iPAddress or srvName (a subtype of
otherName), would be in scope, unless all such names were excluded by
the name constraints.

Not sure about whether you would want to include the URL type.

Jakob Bohm

unread,
Dec 9, 2016, 9:20:50 AM12/9/16
to mozilla-dev-s...@lists.mozilla.org
Someone who knows the NSS code should also check which values the
current NSS accepts for various scenarios/actual usages.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
0 new messages