[Servercert-wg] Ballot SC22: Reduce Certificate Lifetimes

Ryan Sleevi sleevi at google.com
Thu Aug 22 15:18:11 MST 2019


On Thu, Aug 22, 2019 at 5:53 PM Dean Coclin via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> For this ballot, that would not be the case as it seems to affect
> thousands of customer with the an even greater number of certificates. I
> don’t have actionable data to say whether or not this would be reasonable,
> but perhaps the proposers can look at moving the target date out to give
> enterprises more time to prepare.
>

Hi Dean,

I must admit, I'm rather surprised to hear something stated as "The
implementation was quick (due to the associated security threats)." for
SHA-1. If you recall, that was announced with five years of lead time, and
with significant messaging before-hand, including additional in-browser UI
and messaging.

Does DigiCert believe five years for a CA to implement a single change is
too quick?

The comparison here is neither apt nor applicable, even though appealing,
because unlike SHA-1, this does not represent a change in certificate
profile. There are no known compatibility issues with reduced lifetime.
They do not cause incompatibilities with any existing clients. This does
not require the revocation or replacement of any existing certificates.

Quite literally, no organization, other than a CA, needs to make any
functional or operational changes in response to this ballot, in any
reasonable amount of time. If CAs are unable to make configuration changes
within 6 months, or if they're concerned they're unable to revalidate a
fraction of their certificates sooner than expected, then I do fear that
those CAs are in dire straights, and it may be time to discuss phasing out
trust in them.

The comments definitely provide an opportunity for CAs to help their
customers understand that this change has limited to no impact on them. If
you believe something is being misunderstood or overlooked, I do hope you
can highlight it, because what I see is ample confusion for which the CAs
can and should correct, since much of the anticipated impact is, in fact,
non-existent. For the remainder, the CAs are well-placed to minimize both
that and any future impact from future reductions or changes, by both
education and improving automation. I know some CAs are very keen on user
education as a solution to security problems, so perhaps this is a great
chance to actually practice that and share insights from that education
campaign.

That said, from discussing with several CAs, it sounded like an April date,
rather than March, is more than reasonable and sufficient, and I'll be
updating the ballot to reflect that. Can you share if there are any
technical problems with DigiCert changing its system? Based on the customer
communications shared previously, it sounds like DigiCert believes it's
more than capable of meeting the March date set out, and would have no
problems configuring its system accordingly.

Given that any practical impact of this change is delayed for over a year
and a half, that gives organizations more than sufficient time to adjust
without any disruption. Considering that the ecosystem needs to be prepared
for replacing certificates with five days notice - for example, when it's
discovered that the CA was failing to validate certificates and instead
issuing them for "Default City" in "Some-State" - I truly hope that 18
months notice is more than adequate. Certainly, I hope you of all people
can appreciate the importance of ensuring customers are able to migrate
away, in a timely fashion, from CAs that are or are being distrusted, and
the challenges faced by these customers if their certificates become
untrusted before they expire, or if they forget how to replace or
revalidate.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190822/6e8eb306/attachment.html>


More information about the Servercert-wg mailing list