[cabfpub] (Eventually) requiring id-kpServerAuth for all certs in the chain?

Brian Smith brian at briansmith.org
Mon Nov 3 21:20:37 UTC 2014

On Mon, Nov 3, 2014 at 11:45 AM, Gervase Markham <gerv at mozilla.org> wrote:

> I wonder if the BRs should say that all non-root certs in a chain issued
> for SSL server use, which were issued after <date>, should have EKU
> id-kpServerAuth in them. Date would be, say, six months from now.


1. Require all intermediate certificates that are NOT to be subject to the
BRs to include an EKU extension which does NOT include ip-kp-serverAuth or

2. Require the revocation of any intermediate certificates that do not have
an EKU extension or have an EKU extension with anyExtendedKeyUsage and/or
have an EKU extension with id-kp-serverAuth.

3. When necessary, issue replacements for the certificates revoked in #2
with the appropriate EKU extension added.

In other words, explicitly state what already logically has to already be
the case today.

> It would mean that, over time (years) as intermediates got
> replaced, we could eventually move to a position where it was entirely
> clear what certs were intended for Web PKI SSL use and what certs were not.

It is already clear: If the CA certificate can issue certificates that web
browsers will trust for web usage, then that CA is required to conform to
the BRs. If the CA certificate is technically constrained such that it is
impossible for it to issue certificates that web browsers accept for web
usage, then the BRs don't apply to it.

> Currently, any intermediate in the world issued by a publicly-trusted
> root can issue for SSL, even those intermediates which are not intended
> for such use. This leads to numerous problems, including the question of
> whether such intermediates need to be covered by a BR audit.

Of course they do, unless they are technically constrained as explained in
the BRs. The argument that they aren't covered by the BRs because they
aren't "intended" to be used for SSL is not reasonable. Intentions are
irrelevant, because browsers cannot use intentions to decide whether to
trust a certificate. Also, nobody intends for mis-issuance for occur, but
it sometimes does, so even an intermediate that isn't intended to issue SSL
certificates might be abused to do so.

AIUI, EKU "chaining" (i.e. requiring an EKU to be present all the way up
> the chain) is not standard, but is implemented in NSS and elsewhere.

It is not implemented in NSS. It is implemented in mozilla::pkix and in
Microsoft's library. We can write a standard for it.

> I know this is a thing which only pays off in the long term, but I still
> think it's worth it. Does this make any sense, or have I missed
> something obvious? :-)

It would be very far in the future before browsers could enforce your
proposed requirement in a way that would allow this change of position in
the BRs. It seems more practical to make the change I suggest, because it
can take effect immediately (retroactively) and codifies the assumptions
we're already making today.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20141103/610b3fa9/attachment-0003.html>

More information about the Public mailing list