[Servercert-wg] Ballot SC22: Reduce Certificate Lifetimes (v2)

Mon Aug 26 11:56:41 MST 2019

Ryan,

Over the past 2-4 years there have been a lot of references to the reasons behind the shortening of the validity periods and data re-use, but what we’re lacking is a comprehensive security analysis that can be provided to our customers to demonstrate the value of this change to the community as a whole.  I thought you’d be including more of this background research and list of references along with a summary that would be consumable by everyone (I tried to get this across in a previous dialog, : https://cabforum.org/pipermail/validation/2019-August/001291.html )

As it stands (and by looking at your responses over the past couple of weeks), it’s more of demand and lacks the back-up details that can be consumed by website administrators.  If you can provide something like this, ideally a public blog that everyone can view and reference, then our customer base might  be  more inclined to “accept” the consequences of the changes in this ballot.  

=============

Here are just a few of your quotes from the recent past.  These are “Ryan’s opinion” rather than true data points.  I know you have the data points, I don’t doubt that, but they are not in a form that is consumable by the community as a whole and are spread out over the past 3 years without a sound, fact based justification surrounding this ballot.  Is this asking too much?

+++++++++++++++++

Oh, I'm sorry I gave that impression! I personally read each and every comment. They were fascinating as to the spectrum of confusion, which is why I've tried to address many of those points on the list, and I'm sure many responsible CAs following that discussion have been looking at ways to tailor their user education to address some of those misconceptions and misunderstandings about the change here.

Thankfully, the CA largely responsible for that misinformation has been distrusted, and so it's simply unfathomable to imagine CAs would still mislead their customers about effective dates set by Root Programs or those that might also appear in the Baseline Requirements. However, I do hope we can agree on the many years notice and prior discussion, such that it was no surprise to anyone when the Browser Programs mandated a particular date for SHA-1.

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.

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.

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.

Again, there is zero requirement to adopt any form of automation - whether automation of certificate deployment (e.g. Puppet) or through automation of issuance (e.g. RFC 8555). While both are recommended, it's not correct to suggest this ballot does anything to require them. Organizations are more than capable of making a change on an annual basis.

Everything we do, within the CA/Browser Forum, that improves security is a preventative measure. The Baseline Requirements are a preventative measure to prevent CAs from issuing certificates that harm users, by describing how to correctly issue certificates. Reactive measures, sometimes called "detective" measures, do not reduce probability nor improve security - they merely deal with harm once it has been caused.

Unfortunately, this is a bit like arguing it's best not to apply security patches until you're exploited. I understand that we'll not see eye-to-eye here, and that's OK. I'm concerned about ensuring our users, and the Internet at large, is sufficiently secure and robust when CAs mess up, which they do on a regular basis, and to minimize the impact to any organization: both those using that CA, and which may need to respond accordingly, and those that may not be using it, but nevertheless placed at risk by such CAs.

Unfortunately, the current practices these Enterprises practice makes the ecosystem less secure and less robust. All organizations MUST be prepared to replace certificates in a timely fashion, to ensure that users can be protected when, e.g. certificates need to be replaced because the issuing CA violated one or more Root Program requirements, when the method used to validate the authorization for the certificate is determined to be insecure, the CA is distrusted, etc.

It is not possible to accommodate the needs of Browser users, that is, the need for billions of users to have a reliably secure connection to the server indicated in/specified by the domain, while also accommodating the needs of organizations that reject basic security practices, such as the ability to replace certificates as needed, potentially even during holidays, production freezes, or other events.

A problem, which is one of many, is that these Enterprises reject practices that ensure they can replace certificates in a timely fashion. It is explicitly intentional that such cases become more costly, in terms of time and engineering effort, for organizations that wish to hold onto those antiquated notions. That's because right now, all users and all sites that wish to have reliably secure connections to their users are forced to bear the costs and risks introduced by these organizations. This change will rebalance that cost, reducing the costs and risks to users, although admittedly, at the potential risk of additional cost to organizations that reject such basic practices. However, the vast majority of organizations, if supported by a well-run CA, will likely find that both the cost, and risk to their organization, decreases. If your CA is not helping you realize those reduced costs, it may be worth re-evaluating the CA.

You get the point – If I missed specific references, I apologize.

From: Servercert-wg <servercert-wg-bounces at cabforum.org> On Behalf Of Ryan Sleevi via Servercert-wg
Sent: Monday, August 26, 2019 1:11 PM
To: CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Subject: [Servercert-wg] Ballot SC22: Reduce Certificate Lifetimes (v2)

Ballot SC22: Reduce Certificate Lifetimes (v2)

Motivation:
Since the adoption of the Baseline Requirements, the CA/Browser Forum has discussed and debated the merits and value in reducing certificate lifetimes, in order to adequately respond to changes in the TLS ecosystem.

Benefits of reduced lifetime:
  * Issues that result from the misinterpretation or misapplication of the Baseline Requirements are able to be more promptly resolved. Despite the best efforts of Browsers to ensure unambiguous requirements, there continue to be issues with CAs and their understanding and successful implementation of existing requirements. At present, due to the fact that validations may be reused for up to 825 days, and when they are reused, may be used to issue certificates valid for another 825 days, it may take up to four and a half years before issues are resolved. This proposal would halve that time, to a little more than two years, and represents a significant improvement.
  * Even when the Baseline Requirements are clear and unambiguous, implementation issues by CAs routinely introduces risks of improperly formed or validated certificates, allowing CAs to issue certificates which have never been permitted and should never have been issued. Reducing certificate lifetimes reduces the overall risk that the ecosystem is exposed to these improperly formed certificates, both in terms of usage and in the need for Relying Parties to support such certificates.
  * CRLs and OCSP have long been shown to be non-viable at Internet-scale, in terms of how they externalize costs like privacy, performance, and stability to Subscribers and Relying Parties. While alternative, browser-specific methods also exist, they also allow CAs to externalize the cost of their practices onto users and browsers, growing as the number of unexpired certificates grow.  Reducing certificate lifetimes meaningfully protects users, regardless of the revocation method used, and helps reduce the overall costs paid by users.
  * Operationally, the current extensive certificate lifetime has repeatedly led to issues, in that Subscribers frequently forget how or when to replace certificates. Aligning on an annual basis helps ensure and streamline continuity of operations, reducing the number of errors users see and disruptions that sites face.
  * Operationally, the prolonged reuse of validation information creates challenges in replacing certificates due to security risks identified with the existing validation methods permitted by the Baseline Requirements. Reducing this validity period similarly helps streamline the validation process, allowing site operators to ensure for relying parties that the certificates they use were meaningfully validated.
  * As shown by issues such as BygoneSSL, the misalignment between certificate lifetime and the domain name system poses availability and security risks to site operators. Despite such research being presented directly to the CA/Browser Forum, there have been no efforts by CAs, as an industry, to mitigate the risks posed to users. Certificate lifetimes currently represent the greatest mitigation to these risks.
  * Existing certificate validity periods create risk for Relying Parties wishing to enforce the Baseline Requirements or Root Program requirements, by allowing CAs to “backdate” certificates in order to attempt to bypass date-based program requirements. Reducing certificate lifetimes reduces the window of exposure to such bypasses. As this has happened multiple times, by past and present members of the CA/Browser Forum, reducing certificate lifetimes represents the safest way to detect and counter this risk.

While this ballot sets forward a proposal for an effective annual renewal and annual revalidation, both periods should be seen as a starting point for further improvements. In particular, multiple Browsers have noted that the current reuse of domain validation information represents a substantial security risk, and thus will seek to further reduce this in subsequent ballots. In general, CAs and Subscribers are recommended to pursue interoperable solutions for automation, such as RFC 8555, which allow for easier and seamless validation and replacement of certificates, and thus helping ensure users and Relying Parties are adequately secured.

While Browsers will be able to technically enforce these reduced validities as early as April 2020, they will not fully benefit from the reduction until 825 days after the last day such certificates can be issued, or June 2022. As a consequence, any further delays to the implementation period of April 2020 would represent an even greater security risk to users and Relying Parties.

This ballot further attempts to resolve ambiguities between the expectations of Root Programs and the interpretations of CAs. Namely, it attempts to clarify time periods in days and seconds, to avoid confusion with respect to months, fractional seconds, leap seconds, and other forms of date calculation, while also allowing an additional 86,400 seconds between the recommended period and the required period. To address issues with Validity Period, it defines the Validity Period in a way that can be objectively technically enforced and verified, by measuring the period between the notBefore and notAfter of certificates, as specified by RFC 5280. While historically the Forum has not specified timezones for effective dates, and thus this ballot continues the trend, consistent with the requirements of X.690, X.680, and X.509, the time and timezone for effective dates shall be interpreted as midnight, Coordinated Universal Time.

Changes since SC22 (V1)

(Informative) Redline: https://github.com/sleevi/cabforum-docs/compare/0a72b35f7c877e6aa1e7559f712ad9eb84b2da12...sleevi:069f785ebbdc82b819dcd045330ce61542097158

This updates the date from March 2020 to April 2020. While the adoption of this Ballot does not require functional or operational changes of Subscribers for 18 months, and thus ample time to evaluate and prepare for changes, concerns were shared that customers with freeze periods that last through February may feel unprepared, particularly once the changes begin to impact them in 2021. To account for this, an additional month of breathing room is provided, allowing for approximately 19 months until any organizational impact.

Prior to this change, there was a functional difference between the Baseline Requirements' maximum information reuse period (835 days) and the EV Guidelines' maximum information reuse period (13 months), although both shared the same maximum Validity Period. The EV Guidelines included provisions to allow for the issuance of additional EV certificates, subject to the reuse period specified by the Baseline Requirements (Section 11.14.1), including issuing additional certificates with different keys ("rekey" or "re-issuance", Section 11.14.2). The alignment of the Validity Period between DV, OV, and EV certificates, and the alignment of the reuse of information between DV, OV, and EV certificates, renders this special case unnecessary. To avoid confusion that may lead CAs to believe that the EV Guidelines contradict or supercede the Baseline Requirements, which could result from the special accomodations specific to the EV Guidelines, Section 11.14.3 has been modified to reduce and resolve any ambiguity. This attempts to be the smallest possible change, clarifying existing expectations. All certificates, whether DV, OV, or EV, are subject to the same information reuse period set forth in the Baseline Requirements, including permitting a CA to issue additional certificates for additional domain names, and without requiring additional validation for organizational information.

An interpretation of the Bylaws has been put forward that voting cannot start until an additional message is sent following the conclusion of discussion; that is, that the may that is specified within the Bylaws is, in fact, a MUST and a normative requirement. To avoid confusion or conflict with such an interpretation, and until such a matter can be resolved by Ballot, this v2 ballot does not specify a voting period start or end, and will not do so until after the conclusion of (or modification of) the discussion period.

The following motion has been proposed by Ryan Sleevi of Google and endorsed by Curt Spann of Apple and Jacob Hoffman-Andrews of ISRG / Let’s Encrypt.  

----- MOTION BEGINS -----

This ballot modifies the Baseline Requirements, version 1.6.5, to incorporate the following changes:

https://github.com/cabforum/documents/compare/master...sleevi:069f785ebbdc82b819dcd045330ce61542097158?diff=split#diff-7f6d14a20e7f3beb696b45e1bf8196f2

This ballot modifies the EV SSL Certificate Guidelines, version 1.7.0, to incorporate the following changes:
https://github.com/cabforum/documents/compare/master...sleevi:069f785ebbdc82b819dcd045330ce61542097158?diff=split#diff-4d3fa7e751e9cac20a3014852be12e82

Should this ballot be adopted, the Chair or Vice Chair shall be directed to modify “SCXX” to “SC22” and “XX-Xxx-2019” within both documents’ informative tables to the date of the completed ballot, prior to or following the IP Review Period, and “Xxxx XX” to the effective date/date of publication of the Final Maintenance Guidelines.

In addition, the Chair or Vice Chair shall be directed to modify X.X.X within both documents to an appropriate version, at the Chair or Vice Chair's discretion. The Chair is recommended to not use directly sequential or continuous numbering from prior versions, in order to ensure there is additional review by CAs as to the substance of these changes.

----- MOTION ENDS -----
This motion proposed a Final Maintenance Guideline.

The procedure for approval of this ballot is as follows:

Discussion (7 days)
Start Time: 2019-08-26 18:00 GMT
End Time: 2019-09-02 18:00 GMT

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190826/a1d1280b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5701 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190826/a1d1280b/attachment-0001.p7s>