[Servercert-wg] Ballot SC22: Reduce Certificate Lifetimes (v2)
doug.beattie at globalsign.com
Tue Sep 3 09:19:37 MST 2019
If I understood and agreed with the reasons for these changes, then I could certainly convey this to our customers, but you continue to skirt the real subject which is there is not a definitive place where the authors of this ballot have laid out the reasons for the change and tied that to the proposed timeline. I’m more than willing to send along the position statement and provide commentary on it.
I don’t buy the comment that incident reports are the driving reason for shorter periods, or that shorter periods will reduce the number of incident reports. Yes, there are a couple of incidents where stale data was re-used, but typically incidents are for issues other than this.
What’s missing is a public blog or position by the ballot authors on the reasons this is needed and why April 2020 is the drop dead date. The current ballot into is insufficient. We need a list of issues and attacks that have resulted in, or have a high potential to harm the eco system and exactly how these proposed changes help more than they hurt. Including the reasons across dozens of emails and multiple lists isn’t consumable by the community which will be most impacted by the proposed changes. Describe them without calling our specific CAs or organizations, intimidating the community, or demeaning those that have expressed their opinion in the past.
Something like this would be most beneficial where the issues are clearly articulated: https://wiki.mozilla.org/CA:Symantec_Issues
From: Ryan Sleevi <sleevi at google.com>
Sent: Tuesday, September 3, 2019 10:45 AM
To: Doug Beattie <doug.beattie at globalsign.com>
Cc: CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Subject: Re: [Servercert-wg] Ballot SC22: Reduce Certificate Lifetimes (v2)
This message made it fine: https://cabforum.org/pipermail/servercert-wg/2019-August/000970.html
In GlobalSign's vote, I'm not quite sure I understand the reference to https://cabforum.org/pipermail/validation/2019-August/001291.html , rather than this thread, but given the proximity, were you trying to equate the two as asking for the same thing?
I'm just trying to understand, because your reason for voting NO in https://cabforum.org/pipermail/servercert-wg/2019-September/001000.html was cited as https://cabforum.org/pipermail/validation/2019-August/001291.html , except that the Ballot Text specifically addressed that request (as, incidentally, did Apple - https://cabforum.org/pipermail/validation/2019-August/001296.html )
I would normally think that CAs are the best equipped to explain to their customers the ecosystem benefits, as well as to collectively represent them, but it seems you're advocating that individuals should have the tragedy of the commons explained to them.
For example, https://cabforum.org/pipermail/servercert-wg/2019-August/000983.html shows the complexity in unpacking a 'simple' remark, such as explaining why OCSP stapling doesn't work.
Could you explain what you mean about the lack of citations to ecosystem risks? Out of respect for CAs, and because I'd rather Incident Reports be a way of improving the ecosystem ( https://groups.google.com/d/msg/mozilla.dev.security.policy/oP8XuNXrANw/oIYt70IiAAAJ ) rather than being a way to shame CAs, I've specifically and intentionally avoided citing the many incidents from the CAs in this Forum which may have been better handled by reduced lifetimes. However, if you think it'd be valuable to GlobalSign customers, I'd be happy to walk through some of the incidents that GlobalSign has had in the past three years, and how a reduced lifetime would have reduced the risk to the ecosystem.
Otherwise, I'm not entirely sure what you're asking for, and I'm hoping you could expand. Perhaps you can point to example documentation GlobalSign has put out to help their customers understand complex issues?
On Tue, Sep 3, 2019 at 9:13 AM Doug Beattie <doug.beattie at globalsign.com <mailto:doug.beattie at globalsign.com> > wrote:
I was looking back and it seems this email from last week didn’t make it to the mail archives. A co-worker of mine received it, but it seems most others didn’t (for some reason). Apologizes for not identifying this sooner.
From: Doug Beattie
Sent: Monday, August 26, 2019 2:57 PM
To: Ryan Sleevi <sleevi at google.com <mailto:sleevi at google.com> >; CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org <mailto:servercert-wg at cabforum.org> >
Subject: RE: [Servercert-wg] Ballot SC22: Reduce Certificate Lifetimes (v2)
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 <mailto: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 <mailto:servercert-wg at cabforum.org> >
Subject: [Servercert-wg] Ballot SC22: Reduce Certificate Lifetimes (v2)
Ballot SC22: Reduce Certificate Lifetimes (v2)
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:
This ballot modifies the EV SSL Certificate Guidelines, version 1.7.0, to incorporate the following changes:
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...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 5701 bytes
Desc: not available
More information about the Servercert-wg