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

[Brian Smith]

Gerv,

Please note that Ryan and I appear to be suggesting exactly the same thing.
And, note that what I'm suggesting here is exactly the same argument I made
for interpreting EKU in end-entity certificates earlier this year or last
year: a lack of EKU is equivalent to "anyExtendedKeyUsage". This is what
all (AFAICT) certificate verification code does today.

Gervase Markham <gerv at mozilla.org> wrote:

> > However, I'm assuming that for the CAs for which the BRs apply, it is
> > already the case that all or most of their intermediates conform to the
> > BRs.
>
> I would hope so. But is it programmatically detectable that they do? If
> so, how? "Publicly audited" is not a determinable characteristic of an
> intermediate.
>

Your proposal has the same issue. In both proposals, just by looking at the
certificate chain, you can tell whether the intermediate is required to
conform to the BRs or not. The only difference is that the way Ryan and I
are suggesting already matches what Chrome (on Windows, at lesat), IE, and
Firefox are already doing, whereas you are proposing that all browsers
eventually (5-10 years from now?) be changed to do something new, without
any protection for users until then.

Also, your proposal 1) requires a re-issue of intermediates for all
> private PKIs, right? Because they all need to have EKUs in them?
>

If a CA certificate chains to a root for which the BRs apply, and that
sub-CA doesn't want to be held to the BRs (ostensibly because they don't
intend to issue SSL certificates), then they would need to have their
sub-CA cert re-issued (and the old one revoked) with an EKU extension that
does not include id-kp-serverAuth or anyExtendedKeyUsage, unless their
certificate already has such an EKU. That is the only situation in which
re-issuance would be necessary.

If private CAs don't issue SSL certificates, then it would be a good idea
to replace their CA certificates with ones that contain an EKU that doesn't
have id-kp-serverAuth or anyExtendedKeyUsage, to follow the principle of
least privilege. But, they wouldn't be required to make any change, because
the BRs don't apply to them, assuming that they don't chain to a trusted
root. If they do chain to a trusted root then they're not private and the
above paragraph applies.

Cheers,
Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20141105/29097608/attachment.html