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

[Dimitris Zacharopoulos (HARICA)]

HARICA went over the entire discussion related to Ballot SC22.

One of the facts that came out of this discussion is that Google 
supports that revocation check for TLS Certificates is "broken" beyond 
repair for various reasons. HARICA does not consider revocation to be 
broken (as explained it already works for other popular browsers) and 
revocation is a fundamental piece of the technology used in the Web PKI. 
The privacy issues that were discussed can be mitigated by using OCSP 
stapling. The privacy for OCSP queries is similar with the privacy of 
the DNS.

We re-visited our original proposal to re-validate Domains annually and 
leaving the Certificates to live longer, and we concluded that it is a 
lot more challenging to implement rather than performing validation and 
issuance at the same time. However, if it was a strong (auditable) 
requirement and Subscribers were aware of it via the updated Subscriber 
Agreements (that their Certificate will be revoked in case of no 
re-validation at least every 13 months), it would be better for the CAs 
to be more impacted by extra work in their validation/revocation systems 
rather than moving the burden of Certificate re-installation to Subscribers.

The balance of 2-year certificates seems to be the right one so that 
enterprises have the choice to implement either automation or change 
management policies (with 2-person rules, etc) according to their 
security assessment and risk management. We respect this freedom of 
choice for security experts in large Enterprises.

The industry and device/appliance vendors do not currently support the 
necessary level of automation to replace Certificates in a short 
time-frame. We expect the industry/vendors to listen to the voices of 
security experts supporting for automation and adapt their devices to 
this increasing need. Hopefully if we could re-visit this ballot 1 year 
from now, the landscape will be more accommodating to reduce the 
validity of Certificates.

For the argument related to SHA1 deprecation, the Forum has learned its 
lessons and will not delay future algorithm deprecation the way it did 
for SHA1. In case an algorithm is suspected to be compromised and the 
research papers are out there, the Forum must quickly allow for other 
secure algorithms and set a deprecation timeline for the compromised 
ones that should not be more than 12 months. 2-year end-entity 
certificates are not considered a significant security threat, because 
the same algorithms are used for CA Certificates which are valid for 
several years. How can we justify the fact that CAs issue subCAs for 5+ 
years and require Subscribers to have 1-year Certificates?

When a validation method becomes invalid but has been used to validate 
2-year certificates, it would not be used in the re-validation process 
therefore the security goal would be similar. If revocation is not an 
option, there cannot be any meaningful discussion about any security 
change that the CA/B Forum decides. For example, if the Forum votes that 
a validation method is completely broken and all Certificates issued 
with that method must be either re-validated or revoked within -say- 3 
months, how will that work if revocation is not an option? Perhaps it 
will affect one of the largest Browser vendors (Chrome) but others will 
be ok.

Another argument that was considered is the fact that the CT ecosystem 
will receive a big increase of certificate volume being logged. LE had 
big challenges and Google assigned a special log server just for LE. 
Reducing the lifetime to 1 year without evaluating this parameter seems 
to be a risk to the certificate ecosystem. We currently don't know if 
the CT ecosystem is ready for CAs to double the number of certificates 
being logged.

The arguments of both sides proved how controversial this topic is. In 
any case, HARICA agrees with some of the arguments to increase the 
agility of the ecosystem but overall doesn't support reducing the 
lifetime of certificates at this particular moment in time.

HARICA votes "abstain" to Ballot SC22.


Dimitris.


On 2/9/2019 9:00 μ.μ., Ryan Sleevi via Servercert-wg wrote:
> 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 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 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
>
> _______________________________________________
> 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/20190906/3ed920db/attachment-0001.html>