[Servercert-wg] Voting is Starting on Ballot SC22: Reduce Certificate Lifetimes (v2)

[飯田 義朗]

SECOM votes "NO" on this ballot SC22.

We theoretically believe it is desirable to reduce the certificate life cycle,
from a long-term perspective.
On the other hand, the question remains in us as to whether shortening the
certificate lifecycle is appropriate at this time or not, taking into account
the current operations.

Also even if the certificate validity period would be set for one year in the
future, we figure out that it is rather difficult for our company and our
customers to establish the system fully by April 2020.
Considering that issue too, we'd like to vote "NO" on this ballot at the moment.







From: Servercert-wg [mailto:servercert-wg-bounces at cabforum.org] On Behalf Of Ryan
 Sleevi via Servercert-wg
Sent: Tuesday, September 03, 2019 3:00 AM
To: CA/B Forum Server Certificate WG Public Discussion List
Subject: [Servercert-wg] Voting is Starting on Ballot SC22: Reduce Certificate
 Lifetimes (v2)

As some members have suggested an interpretation that voting cannot start on
ballots until a final copy is reposted, this serves as notice of the intent to
start voting on Ballot SC22: Reduce Certificate Lifetimes.

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
programrequirements. Reducing certificate lifetimes reduces the window of exposur
e 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 accommodations 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

Voting (7 Days)
Start Time: 2019-09-02 18:00 GMT
End Time: 2019-09-09 18:00 GMT