[cabfpub] Misissuance of certificates

[Ryan Sleevi]

On Mon, Jan 18, 2016 at 1:27 PM, Geoff Keating <geoffk at apple.com> wrote:

> For me, one outcome of the previous discussion was that it’d be a lot
> easier if browsers could require serverAuth in EKU.  The number of
> remaining unexpired certificates without serverAuth is now very small; the
> only thing preventing me from saying we should all switch to it ASAP is
> that the SHA-1 and RC4 deprecations are in the pipeline, are more
> important, and there are limited resources.
>
> Once that’s done, I think there’s a strong case for saying that anyone who
> wants an certificate with anyEKU must comply with all the requirements for
> each kind of certificate; if there are contradictions then those need to be
> worked out.


As much as I would like to think that's reasonable, it has two very
detrimental side-effects:
- It doesn't cover the case of intermediates, which can then cause issuance
of serverAuth EKUs. In practice, I think those are far more concerning and
important to encourage disclosure of.
- It only serves to protect the bleeding edge of users. Historically, the
changes that the CA/B Forum have adopted have applied ecosystem wide -
which is generally a strength, but understandably causes some concerns with
some deprecations (e.g. SHA-1). I can say at Google we're very concerned
not just for what users using the bleeding edge of (Chrome, Android,
ChromeOS) see, but also those on the long-tail. While the Chrome and
ChromeOS long tail is rather short, Android is... unfortunately long. So we
try to look for improvements that affect the entire ecosystem.

Thinking more holistically at the Internet community, such a change really
doesn't help users using other HTTPS-validation libraries (that is, they're
not user agents, but they're accessing the same resources using the same
technologies). Think of PHP, Perl, Python, Ruby, Curl, Wget, etc. Those are
all TLS certificates used for server authentication of domain names, but
which may validate things slightly differently.

That's not to say we can't make changes that take time to filter in, but I
think we should definitely bias our risk equations to finding solutions
that work to protect the maximum number of users. That's why I'm inclined
to favor solutions that look at whether something is capable of X, rather
than just intended for X.

We've definitely got options for CAs that wish to carve out issuance, and
we can explore more ways to carve out such issuances that don't negatively
impact the ecosystem, but I'm loathe to endorse solutions where you're only
protected if you're on the sharpest of bleeding edges.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160118/3522387e/attachment-0003.html>