[cabf_validation] Draft Ballot SCXX: Improve Certificate Lifetimes

[Richard Smith]

From: Ryan Sleevi <sleevi at google.com> 
Sent: Monday, August 5, 2019 1:09 PM



On Mon, Aug 5, 2019 at 1:37 PM Richard Smith <rich at sectigo.com <mailto:rich at sectigo.com> > wrote:

Ryan,

Sectigo is willing to endorse this ballot, but we have a couple of concerns, primarily around (1) timing of implementation and (2) future validity period changes. 

 

Glad to hear!

 

Before getting into the details of those concerns we would like to thank you for bringing this to the Forum rather than going it alone as some trust store operators have done with significant policy changes in the recent past.  While we acknowledge that trust store operators are not obligated to do so, we feel it's very important that in general, and barring serious and immediate security concerns, policy changes take place in the CA/B Forum in order to foster the continued cooperation between CAs and trust store operators. 

 

I suspect this will continue to be an area where we politely agree to disagree. The strength of the Forum is in facilitating discussions to allow multiple independent trust frameworks to avoid making incompatible changes. It similarly provides an excellent venue to gather feedback from CAs as to browsers' efforts to better secure their users, but as with most feedback related to security changes, the most important thing is that users are protected in meaningful and timely ways.

[Rich Smith] I think we’re mostly in agreement, Ryan.  Where maybe we disagree is that our view is that all things being equal policy changes should at least be discussed and attempted here before a trust store takes unilateral action.  I’m not suggesting at all that you or others shouldn’t take whatever action you feel you need to take to protect your users.  Just that, barring an immediate threat, you should attempt to take that action here first.

 

 

Timing of implementation:

We've been reaching out to customers to get feedback, and what’s coming back is concern that March may be too soon for some of our customers, large enterprises and resellers, to prepare for this kind of change, so we'd like to push implementation date out to September 1, 2020.

 

Thanks. If this change is required for Sectigo's support, it may be better to decline at present. This request unfortunately comes with no meaningful and actionable information, and no explanation about the logic behind the change, alternatives considered, the factors being evaluated, or any of the other things that might allow for substantive discussion. I appreciate the sensitivity of trying to distill some of your large enterprise customers feedback, but I'm afraid the summary is lacking in constructive feedback that allows this to be a dialog towards consensus.

[Rich Smith] We’re still gathering information and will try to get back you the Forum with more concrete feedback.

 

Future validity period changes:

Since the validity period has been discussed for quite some time, and has been somewhat contentious, we hope to gain an understanding and possibly consensus about how changes to it in the future are viewed.  Our thinking is that due to the non-trivial downstream impact to enterprises that result from the changes that we make, we have to carefully weigh how frequently the validity period should be changed.  Barring significant and immediate security concerns, we’d like all parties to consider calling certificate validity settled for 3 to 5 years after this ballot. Note that this does not include discussion of modifications of data re-use validity to address issues which have come up in discussion of this ballot.

 

Thanks. This similarly lacks substance to allow any understanding of the reasoning, and as a consequence, while an attractive call for some, doesn't really explain the tradeoffs that justify leaving domain holders at risk. As seen by the Apple feedback, and as shared with the Forum in a presentation for its members, the security risks involved in the domain validation and reuse of that validation are significant enough that there's a need for further reductions. Similarly, the broader ecosystem considerations - such as it being functionally two years (plus, in situations like proposed, an additional one year of "phase in time", for a total of three) to make meaningful changes to certificate profiles, simply does not reflect the serious security risks the ecosystem faces.

 

My hope is that this serves as a starting point for the discussions to better understand the risks facing the ecosystem, and CAs can develop a better understanding of the unique position they play in supporting that role. As with many technologies, if we fail to adequately respond with the changing needs, it's not inconceivable to see the current Web PKI being replaced with more agile, better secured systems. To minimize the risk of that, we should work to ensure relevance and competitiveness in the security landscape. This is merely a first step, reflecting the real risks the ecosystem is facing, but clearly, not a sufficient one.

[Rich Smith] Most of the above two paragraphs seem to be addressing problems with data re-use, specifically re-use of domain verification.  Perhaps I was unclear in that we are very willing to have discussion on that topic in near future ballots as you’ve suggested previously in this thread.  What we’re not as willing to discuss in the near future is further reductions to max certificate validity after this ballot, because as has also been stated previously in this thread, continued adjustment to certificate validity represents a hardship particularly to large enterprises who are either unwilling or unable to automate for various reasons.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20190805/3aefe8aa/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5707 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20190805/3aefe8aa/attachment-0001.p7s>