[Servercert-wg] Ballot SC22: Reduce Certificate Lifetimes

[Dimitris Zacharopoulos (HARICA)]

HARICA does not agree with further reducing the lifetime of TLS 
Certificates as it creates unnecessary burden to site operators. If the 
main problem we are trying to solve is Domain Validation and the fact 
that some domains are "changing owners", thus putting at risk the new 
Domain owners as BygoneSSL demonstrated, we should look for alternatives 
rather than having millions of site operators replace millions of 
Certificates at a shorter timeframe.

Certificates are used in far more systems than I could possibly list. 
Routers, modems, cameras, scientific equipment, proxys, are just to name 
a few that have zero (or close to zero) support for automation in 
certificate renewal. We could try to disconnect the Domain Validation 
part from the Certificate Installation part. The Domain Validation part 
is usually done via alternative channels and are easier for site 
operators to handle. Perhaps we have discussed this before but we could 
add rules in the BRs to re-validate Domain Names more frequently, like 
every 12 months. If the Domain is not re-validated within 13 months, the 
Certificate MUST be revoked (leaving 1 month "grace period" for 
reminders to be sent to the Domain owner).

The fact that revocation doesn't work for some browsers is not (IMHO) an 
excuse for requiring millions of site operators to replace certificates 
in these "admin unfriendly"environments, every year, just to check if 
the site is still owned by the same individual/organization.

As Christian supported, in case of emergency (like an algorithm failure 
or a CA failure/misussuance), as demonstrated in the recent serialNumber 
entropy issue, CAs and site operators can be pushed to replace 
certificates sooner. Site operators understand and respect the fact that 
there is an emergency or an anomaly, and can re-allocate resources 
accordingly to deal with an *unexpected* need for certificate 
replacement. Requiring the installation of new certificates every year 
is not an "emergency" task and will not be easy to justify and for site 
operators to accept.


Thank you,
Dimitris.



On 17/8/2019 9:26 π.μ., Ryan Sleevi via Servercert-wg wrote:
> Ballot SC22: Reduce Certificate Lifetimes
>
> 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 March 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 delays to the 
> implementation period of March 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.
>
> 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:0a72b35f7c877e6aa1e7559f712ad9eb84b2da12?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:0a72b35f7c877e6aa1e7559f712ad9eb84b2da12?diff=split#diff-4d3fa7e751e9cac20a3014852be12e82
>
> Should this ballot be adopted, the Chair or Vice Chair shall be 
> directed to correct “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.
>
> ----- MOTION ENDS -----
> This motion proposed a Final Maintenance Guideline.
>
> The procedure for approval of this ballot is as follows:
>
> Discussion (14+ days)
> Start Time: 2019-08-19 17:00 GMT
> End Time: 2019-09-02 17:00 GMT
>
> Vote for approval (7 days)
> Start Time: 2019-09-02 17:00 GMT
> End Time: 2019-09-09 17:00 GMT
>
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> http://cabforum.org/mailman/listinfo/servercert-wg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190826/5a104cc6/attachment.html>