[Servercert-wg] [Ticket#2019081701000944] Ballot SC22: Reduce Certificate Lifetimes

Mon Aug 19 08:24:50 MST 2019

Dear Ryan,

>   * 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. 

It is not improvement at all. 2 years  issue will be not  resolved?! 

We can use simple solution:

 - Fill company registration number in SSL-certificate. 
 - CA must check by  number company information every  week.  

If information about company was changed. For example, is was changed company 
name or company was dissolved then CA should notify customer. If issue will 
be not resolved in 7 days then CA must  revoke certificate. 

>  * 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.

It will not work. If company have only one certificate then it will continue
to operate as usually.  If company have multiple certificates then anyway all
certificates already under control. Some systems still require manual
installation SSL-certificates and reducing  Certificate Lifetimes just
increase probability of human errors.

Reducing certificate lifetime will increase costs  for CA  and  end 
customers.

 --
Kind regards,
Aleksei Ivannov
Managing  Director
LeaderTelecom B.V. 

17/08/2019 08:27 - 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:

[1]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:
[2]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

[1] https://github.com/cabforum/documents/compare/master...sleevi:0a72b35f7c877e6aa1e7559f712ad9eb84b2da12?diff=split#diff-7f6d14a20e7f3beb696b45e1bf8196f2
[2] https://github.com/cabforum/documents/compare/master...sleevi:0a72b35f7c877e6aa1e7559f712ad9eb84b2da12?diff=split#diff-4d3fa7e751e9cac20a3014852be12e82
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190819/b63e0e75/attachment.html>