[Servercert-wg] Ballot SC22: Reduce Certificate Lifetimes

[Ryan Sleevi]

On Mon, Aug 26, 2019 at 12:35 AM Dimitris Zacharopoulos (HARICA) via
Servercert-wg <servercert-wg at cabforum.org> wrote:

> HARICA does not agree with further reducing the lifetime of TLS
> Certificates as it creates unnecessary burden to site operators. If the
> main problem we are trying to solve is Domain Validation and the fact that
> some domains are "changing owners", thus putting at risk the new Domain
> owners as BygoneSSL demonstrated, we should look for alternatives rather
> than having millions of site operators replace millions of Certificates at
> a shorter timeframe.
>

This is not the "main goal".

During earlier drafting, it was suggested by some members to provide a list
of the numerous benefits. This list is at
https://cabforum.org/pipermail/servercert-wg/2019-August/000894.html ,
which includes many suggestions from Apple previously, at
https://cabforum.org/pipermail/validation/2019-August/001296.html


> Certificates are used in far more systems than I could possibly list.
> Routers, modems, cameras, scientific equipment, proxys, are just to name a
> few that have zero (or close to zero) support for automation in certificate
> renewal.
>

Annual certificates do not require the use of automation. Certificates with
lifespans of <= 13 months, as this ballot proposes, make up 94% of the
existing valid certificate market.


> We could try to disconnect the Domain Validation part from the Certificate
> Installation part. The Domain Validation part is usually done via
> alternative channels and are easier for site operators to handle. Perhaps
> we have discussed this before but we could add rules in the BRs to
> re-validate Domain Names more frequently, like every 12 months. If the
> Domain is not re-validated within 13 months, the Certificate MUST be
> revoked (leaving 1 month "grace period" for reminders to be sent to the
> Domain owner).
>

You are correct that we did not explore it, because as noted in the ballot,
revocation does not work for the Web, especially with respect to privacy.
Any solution that relies on revocation is thus unacceptably broken.


> The fact that revocation doesn't work for some browsers is not (IMHO) an
> excuse for requiring millions of site operators to replace certificates in
> these "admin unfriendly"environments, every year, just to check if the site
> is still owned by the same individual/organization.
>

Thank you for sharing. Considering the hundreds of millions of sites which
are exposed to harm, danger, and CA misissuance as a result of the
long-lived lifetimes, and for which as Subscribers, they have no effective
recourse, Google's position is that we put the user first. In this case,
this means that the minority of sites and users - approximately 6% - may
have to encounter annual replacement. However, the industry has shown that
this does not require automation to do, as this is both the default for a
number of CAs, and long wide-spread before the rise of automated mechanisms
like RFC 8555. Automation simply improves things.


> As Christian supported, in case of emergency (like an algorithm failure or
> a CA failure/misussuance), as demonstrated in the recent serialNumber
> entropy issue, CAs and site operators can be pushed to replace certificates
> sooner. Site operators understand and respect the fact that there is an
> emergency or an anomaly, and can re-allocate resources accordingly to deal
> with an *unexpected* need for certificate replacement. Requiring the
> installation of new certificates every year is not an "emergency" task and
> will not be easy to justify and for site operators to accept.
>

CAs that still think of certificate replacement as an "emergency" task are
doing their users and customers a significant disservice and harm. Another
objective, as noted, is to reinforce that this is not and cannot be the
case.

Luckily, some CAs have recognized this, and in light of misissuance events
have already taken steps - before this ballot was circulated or proposed -
to reduce the lifetime of the certificates they issue to an annual basis. I
can think of one CA, which primarily targets government and enterprise
users, which recognized the challenges they and their customers had with
timely replacement of certificates, and saw a reduction in lifetime as the
most significant mitigation they could put in place.

It is understandable for CAs, given their direct dealings with customers,
to put their customers and business interests first, over the safety and
security of the ecosystem and users. It can be difficult to articulate to
them and their customers that the Web PKI is only as secure as its weakest
link, and that they are directly harming many countless tens of millions of
users and certificate holders that wish to have improved security.
Similarly, it can be difficult to explain to these customers the importance
of routine and regular certificate maintenance, as part of any cohesive
infrastructure readiness or disaster preparedness scenario, as they may be
relying on antiquated notions that certificate replacement is difficult.
That's why it's incumbent upon us, the CA/Browser Forum, and in particular,
the Browser Root Store operators who are tasked with ensuring the CAs in
their program are trustworthy and the certificates issued by these CAs
meaningfully secure users' connections, to lead and ensure that the minimum
bar of security is adequate.

I'm shocked and dismayed to see CAs advocating against any lifetime
reduction, as it suggests outdated or incomplete understanding of the core
business they're in. While I'm sympathetic to discussions about when best
to make these changes, and have tried earnestly to highlight repeatedly why
it requires no substantive process changes for any individual Subscribers
before 2021, I would have hoped the years of discussion that clearly
identified this was the end-goal would have prepared adequately.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190826/2efcf2da/attachment-0001.html>