[Servercert-wg] Ballot SC22: Reduce Certificate Lifetimes

Thu Aug 22 19:04:07 MST 2019

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.

>>No, that’s not what I was referring to, sorry if I didn’t explain it correctly. I was talking about the time from when we passed the ballot to when the change took effect. That was not 5 years. 

In terms of organizations making changes “in a reasonable amount of time”, I fear you did you not read the comments from the customers thoroughly. They read the ballot and the effective dates, hence the comments. Maybe we have a different interpretation.

And I never said anything about CAs ability to comply so I’m not sure where that is coming from. 

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.

>>I was on the CABF call today and did not hear this. It must be a very recent update. Curious what the motivation is for a 1 month delay? (BTW-this is not a complaint, just a question)

>>I certainly understand the motivations for the ballot and the implications you have outlined. Customer however, don’t seem to. Hence we all need to do a better job explaining it by posting information not only to CABF Public (which most customers don’t have time to read) but on public websites which can be pointed to. I wouldn’t be opposed to having a blog posted on the CABF website if it can’t be posted it on someone’s own company site. And if there are 2 viewpoints, perhaps we can do a point/counterpoint blog.

From: Ryan Sleevi <sleevi at google.com> 
Sent: Thursday, August 22, 2019 6:18 PM
To: Dean Coclin <dean.coclin at digicert.com>; CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Cc: Eric Mill <eric at konklone.com>; Chris Bailey <Chris.Bailey at entrustdatacard.com>
Subject: Re: [Servercert-wg] Ballot SC22: Reduce Certificate Lifetimes

On Thu, Aug 22, 2019 at 5:53 PM Dean Coclin via Servercert-wg <servercert-wg at cabforum.org <mailto: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/20190823/96fd494e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4916 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190823/96fd494e/attachment-0001.p7s>