[cabfpub] Certificate validity periods

[Ryan Sleevi]

On Mon, Feb 6, 2017 at 9:52 PM, Scott Rea via Public <public at cabforum.org>
wrote:

> Perhaps the best thing we can do for the WebPKI community, is make it as
> simple and easy as possible to replace or upgrade existing certificates
> - then it matters less how long the existing cert was issued for,
> because if an issue arises that requires a current cert to be updated,
> then that becomes a simple process and no longer a barrier, so just
> replace it, and there is no need to wait until an expiration. By
> greasing the skids of cert replacement, a lot of the challenges
> discussed on this thread could be mitigated. So instead of heaping an
> ever increasing regulatory load on CAs, lets just encourage them to
> deploy simple easy replace strategies instead.
>

While I absolutely agree that we (as an industry) can and should encourage
more automation, and I'm encouraged that ACME adds yet another protocol to
do so - but one that works well with the Internet (rather than the
Enterprise PKI) - I'm not sure that it's sufficient to say that if we
automate, we've solved the problems. I think that may be a core disconnect
here.

The difference here is whether or not automation is forced; if automation
isn't forced - that is, if we allow 39 month certs, but say you should
replace them every 13 - then we know that a large number of customers won't
do so, because there's no forcing function. As a consequence, no matter how
much evangelism we make that "This change is coming and your existing certs
won't work and you should replace them", if browsers make a change to
enforce that requirement, they'll be the ones that take the blame when
things break.

This is a principle we've encountered time and time again - my colleague
Adam Langley has summarized this as "The most recent system to change is
the system that will be blamed". That is, if browsers enforce something,
the browsers will be blamed - as we see with any deprecations or
enforcements (whether it be SHA-1 or validity periods or potentially things
like EKUs or policy OIDs, as we saw with Microsoft's recent root program
update). Similarly, a system that required CAs to revoke such 'old' certs
(imagining a system where revocation works) simply shifts that blame to CAs
- that is, the CAs get blamed by their customers for revoking the certs,
and I don't think we want that either.

So this is where expiration shifts that balance, by reusing the existing
set of systems and controls (namely, the need to periodically replace
certificates). By shifting the 'burden of change' to the client, we shift
the blame 'to the client'.

Now, I can fully understand the perspective of some CAs that reducing the
validity AND imposing changes (e.g. via the Forum) sets them to be the
point of blame - that is, whenever a customer then approaches for their new
certificate, and the CA tells them "Sorry, this isn't allowed anymore,"
they'll be the ones blamed. But at some point, it's unavoidable that
there's going to be blame. The benefit of shifting that relationship to the
CA<->Subscriber (through the renewal process) rather than the current
ecosystem of Browser<->Subscriber, we shift to a better communication
medium and one that causes the least amount of harm and damage to Relying
Parties - which I think is a shared goal of everyone here, or so I'd hope.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170207/3aae2141/attachment-0003.html>