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

[Gervase Markham]

On 05/11/14 18:21, kirk_hall at trendmicro.com wrote:
> I asked our team, and they were doubtful about having to reserve
> intermediates for SSL only – for example, they might want to use the
> same intermediate for S/MIME, etc.

That wouldn't be a problem. I'm not saying an intermediate should _only_
have id-kpServerAuth, just that it must have it. It can also have other
EKUs.

> What if we add a rule that all CAs must list all intermediates “that are
> intended for use in SSL” in a specific part of their CPS, and stating
> that those intermediates must all be audited?  Wouldn’t that end
> ambiguity as to intent?

The reason I am interested in a programmatic check is that it allows us
to exclude certificates which are clearly not meant for the web SSL. As
we know, some previous misissuance events have come from unexpected
quarters, and I think everyone benefits from a clear and
programmatically-determinable definition of what is in and what is out,
which involves the whole chain and not just the EE cert (as misissuance
by a root, thereby allowing the attacker to control the whole chain, is
a far less likely event).

The risk is that an intermediate is cut for an entirely different
purpose, and so is not subject to the BR checks, but then has a
misissuance event - either directly or via a sub-CA it has issued to
another organization for another purpose. Neither the intermediate nor
the other organization is required by the BRs or Network Security
guidelines to have any particular security measures in place.

Gerv