[Servercert-wg] Ballot SC22: Reduce Certificate Lifetimes

[Ryan Sleevi]

On Tue, Aug 20, 2019 at 1:23 PM Christian Heutger <ch at psw.net> wrote:

> Hi,
>
>
>
> On Tue, Aug 20, 2019 at 10:33 AM Christian Heutger via Servercert-wg <
> servercert-wg at cabforum.org> wrote:
>
> Against phishing or other certificate misuse 1 year won’t help, 90 days
> also won’t help (I got some spam with a Let’s Encrypt cert and this
> phishing site was operated for the full 90 days), you need to reduce
> lifetime to day or better hours. Is this really an idea, which could work?
> Also if automation would be able to handle that, it will arise additional
> new pain points. And still it arise the question, is it worth to fix a
> completely different issue?
>
>
>
> I'm not sure, could you highlight where you heard that this was meant to
> address phishing?
> https://cabforum.org/pipermail/servercert-wg/2019-August/000894.html certainly
> doesn't list that as a motivation, and that has never been a motivation
> with this ballot from any of the proponents, so perhaps you received
> inaccurate information?
>
>
>
> I mentioned phishing as the most popular certificate misuse.
>

Certificates and phishing are entirely unrelated, which is why I asked. It
seems that there's some confusion that the two should be related, but
phishing is not a misuse of a certificate.

I've not responded to your points in detail, as I worry they suffer many of
the same confusing points. To respond more generally:

- While I appreciate the comparison of the Baseline Requirements to GDPR,
that's a bit like comparing Apples to Orangutans. The most salient bit to
point out is that the Baseline Requirements are not new, and the changes
are, at best, mildly incremental in response to ongoing security threats.
Much like organizations that wait days or weeks to patch their critical
systems will quickly find themselves compromised (and potentially out of
business), CAs that fail to be able to patch critical systems, like the Web
PKI, will quickly find themselves compromised and out of business. Even if
the GDPR analogy holds (and it doesn't), the notion of "implementing acts"
as incremental guidance is still very much a thing.

- Suggestions that Netcraft and revocation are somehow a substitute for a
CA being competent to implement things correctly is an area where we will
fundamentally disagree, and no amount of argument here would be fruitful.
As noted, revocation methods require Relying Parties to either compromise
their privacy (OCSP) or accept all the costs of CAs' poor practices (CRLs
or browser-based revocation methods). This is an unacceptable tradeoff for
the ecosystem, and for which reducing lifetime is the only system which
considers Relying Parties needs. Yes, this means some Enterprises will be
unhappy, but in a complex ecosystem, sometimes the needs of the many (the
security of every user on the Web) outweighs the needs of a few (select
Enterprises)

- The suggestion that Browsers and CAs work together is, indeed, something
we'd wholly support. However, in the years that we've been discussing this,
CAs have been unwilling or unable to provide any technical alternative that
appropriately balances the privacy and security needs of users. At this
point, continuing to delay leaves users at risk, and that's simply
unacceptable to the organizations that need to protect all of their users,
and not just a few small (in the global scheme of things) enterprises.

In any event, many of the points made make assumptions, such as revocation
works or that CAs are correctly implementing validation requirements, for
which we, as an industry, have ample evidence against. While automation is
suggested as harmful, that is entirely incorrect, and improved automation
of the PKI is no different in this regard than the long-standing automation
that exists within DNS or within BGP, where such systems "just work" once
configured correctly. Just as we would laugh at the notion of
hand-maintaining a hosts file (as was done prior to DNS) or
hand-maintaining global routing tables (as was done before the modern
routing protocols), we should be highly suspicious of any hand-maintaining
of certificates.

While the goal of any change to the Baseline Requirements is to minimize
unnecessary impact, it's undeniable that the systemic set of issues the
ecosystem faces, for which revocation is wholly inadequate for, and the
broader benefits to the whole ecosystem, more than justify some disruption
to a small set of users. The goal of this ballot, and broadly, this
discussion, should be to highlight whether there are any factors that have
not yet been discussed or considered, but which should be, as browsers look
for the best tools to protect their users in reasonable timeframes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190820/ac1d35fe/attachment.html>