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

[Ryan Sleevi]

A near term solution would be what I proposed during the MTV F2F - which
was to say that the absence of any EKUs or the presence of (anyEKU,
kp-serverAuth) makes it in scope for BR compliance requirements.

This avoids the objections of those PKI purists that dislike the effective
behaviors of NSS and CryptoAPI, while still gaining from the compliance
requirements.
On Nov 3, 2014 12:45 PM, "Gervase Markham" <gerv at mozilla.org> wrote:

> Hi everyone,
>
> 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.
>
> This is primarily aimed at intermediates; EE certs all currently have
> this anyway. 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.
>
> 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. Once this
> change had filtered through, it would be clear - they would not be.
>
> 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.
>
> 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? :-)
>
> Gerv
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20141103/89fd18e9/attachment.html