[Servercert-wg] Ballot SC22: Reduce Certificate Lifetimes
Tobias S. Josefowitz
tobij at opera.com
Mon Aug 26 15:32:12 MST 2019
On Mon, 26 Aug 2019, Dimitris Zacharopoulos (HARICA) via Servercert-wg 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.
> 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. 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).
> 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.
In some sense, 100% secure revocation (from the browser perspective)
involves finding out if the certificate presented by a server is still
valid at the *then-current specific point in time*, and would require the
browser to reject the certificate presented if it cannot receive such
confirmation in pretty much real-time.
For OCSP this means to actively ask, for CRLs this means to make sure CRLs
present at the client are up to date (by actively asking), update if not,
and then to verify the certificate presented is not on the relevant CRLs.
In a 100% secure revocation scenario, both mechanisms require remote
network services to be queried and results received and verified to be
OCSP stapling has, in many ways, functional equivalences to extremely
short-lived certificates that are automatically renewed.
All of these mechanisms, especially if used to reach 100% secure
revocation, fundamentally change the nature of a certificate from
something that on its own could vouch for the identity of a site to (yes,
hyperbole) somewhat of a second factor in whatever online mechanism is
chosen for revocation. One might even say to rely on revocation means to
make certificates less certificate-y, maybe even to the degree where one
might ask: If we talk about an online, realtime component - do we even
need X509 certificates to begin with?
Now, 100% secure revocation is obviously quite a strict requirement
compared to a 13 months certificate lifetime; and nobody has really
suggested this anyway. Looking at this hypothetical scenario does however
hint to me that for browsers to rely much more on revocation than they do
today may have far-reaching implications for the ecosystem.
In comparison, how much does asking operators behind the 6% of
certificates with a currently greater than 13 months lifetime (as
according to Ryan) to renew more often actually burden them? I fully
understand few operators will be *excited* by the prospect, or even by not
having the option, and as demonstrated, there can be strong reactions from
But then really, how hard can it be? At most twice as hard as currently.
The amount of organizations and individuals that will actually be hit hard
by the reduced lifetime, if it comes to pass here or is enforced some
other way, especially in ways that are not remedied by changes in process
and approach will be limited. This group will presumably mostly consist of
those that operate devices/products that make it unnecessarily burdensome
to replace SSL/TLS certificates.
Having such devices/products hold back the entire ecosystem could at best
be described as tragic. In addition, for devices that really make it hard
to properly and swiftly manage SSL/TLS certificates, one would think that
they probably have other issues as well, I would assume one does not
generally make devices or products that require special persuasion to
update certificates but will have good and easy processes for applying
firmware updates. Futher, I doubt such devices will frequently be supplied
with firmware updates. That allegedly so many of these are operated with
publically trusted certificates - which implies some might need to be
globally reachable - is worrying as well.
I see no mechanism that we would have available to cause the producers of
such devices/products to make updating SSL/TLS certificates less
problematic in the future (so that we could adopt a 13 months lifetime at
reduced operator cost), and to overall improve the overall security
properties of their devices/products that would not burden the operator of
As stated above, SC22 will probably put a small amount of operators into a
situation that will be tricky for them, arguably at no fault of their own.
It will however also clearly generate market pressure that will lead to
devices (and other products) to have better management options for SSL/TLS
certificates in the future.
More information about the Servercert-wg