[Servercert-wg] Ballot SC22: Reduce Certificate Lifetimes

[Ryan Sleevi]

It's not really a change, though, if you look at it.

I'm trying to highlight the options a Root Program has at its disposal when
the Baseline Requirements do not provide an adequate degree of security for
that browser's users. The spectrum of responses are going to vary, based on
what's being discussed, and include:

- Forbidding the practice via Root Policy (i.e. removing trust in CAs
and/or the certificates that issue to the weaker security)
- Require disclosure within the CP/CPS to assert the necessary level of
security
- Require additional audits (such as Agreed Upon Procedure audits) to the
necessary level of security
- Remove display of information, if it can be reliably assured that the
information will not show through other channels
- Warn and inform users about the risks

It's a spectrum.

The AUP/audit approach has the downside that it would preclude ETSI-based
audits, as such procedures would not (nor should they be) integrated within
the ETSI relevant standards. As such, CAs that are audited to ETSI-based
audit criteria would need to procedure additional audits from additional
auditors, which would be doable, but unfortunate.

CP/CPS changes are tempting, and somewhat similar to forbidding via Root
Policy in terms of practical impact, but they lack any substantive value
for the security of users in a technically verifiable way with third-party
assurance.

Warning users is never desirable, and is really only reserved for the most
extreme cases. In general, blocking the certificate outright, thus ensuring
users are safe by default, represents a much better security boundary.

So, in practice, rejecting certificates from the Root Program is the most
desirable of these. Of course, if all certificates a CA is issuing fail to
meet the necessary and minimum security requirements of that product, it
may be necessary to remove or refuse trust in that CA. However, that's no
different than the status quo today, where plenty of Enterprise and
organization-specific CAs are not trusted by default by Root Programs, due
to failing to meet the minimum bars set by the Baseline Requirements.

The hierarchy is always such that the BRs represent a minimum which then
Root Programs improve. Placing something in the BRs represents a much
higher level of assurance than leaving it to Root Program policy, and thus
the preference to include it in a ballot. However, should that be
undesirable for CAs, I'm sure we can explore the other options!

On Fri, Aug 23, 2019 at 10:07 AM Doug Beattie <doug.beattie at globalsign.com>
wrote:

> This is a different approach that the one you had previously sent along on
> Augusts 1st.  I had assumed that longer re-use periods for OV level
> validation would continue and that if a CA didn’t want to do that, then the
> browsers could implement mechanisms to hide the info.  It sounds like now
> following the BRs (or Root program requirements should the ballot fail)
> will include mandatory shorter re-use periods.  I was just making sure I
> understood your current view on the subject.
>
>
>
> From your email:
>
>
>
> Right. I think that without shortening the organizational data, the value
> provided to relying parties is going to vary based on how the information
> was validated. That is, if the maximum is too great, there may not be any
> value in displaying it, and may be harmful to do so. But that's really a
> per-product/per-browser decision, and I'm fully happy to treat those
> orthogonally. In the worst case, if the reuse period was too great,
> browsers could always gate the display/use of that information to only CAs
> which they knew validated under the more frequent timescale, such as by
> separate audits to establish that. This would allow the BR audits to have
> the more general, less secure upper bound, but the benefit of not requiring
> CAs to do any changes to avoid qualified audits nor require all UAs to
> adopt the same policies simultaneously. The validity period and domain
> validation parts, however, are far more critical and impactful to user
> security, which is why I'm totally happy to treat them separate.
>
>
>
>
>
> *From:* Ryan Sleevi <sleevi at google.com>
> *Sent:* Friday, August 23, 2019 9:53 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
>
>
>
> During the past discussions, I mentioned that omitting it from the
> Baseline Requirements would not and does not impact Root Programs
> requirements for fresh information.
>
>
>
> The concern was that if it was omitted from the BRs and the audits, one
> likely result is that CAs may be required to either modify their CP/CPS to
> the lesser date by Root Programs, or potentially obtain additional audits.
> Alternatively, to avoid confusing users, it may be that removing all
> display vectors for such unvalidated information, such as removing the
> portions of the Certificate UI showing such information, or adding warnings
> about the CA's lack of reliability when it comes to asserting such
> information.
>
>
>
> Given that the EV Guidelines have long-aligned on a thirteen-month period,
> with even more stringent validation requirements, hopefully aligning the
> lax validation practices of OV certificates with the same reuse period will
> not represent a challenge. Do you believe this to not be the case? Do you
> know examples of regulatory oversight agencies which have not aligned on
> annual review? For example, LEI, as overseen by GLEIF, and which folks seem
> to find a desirable model, is aligned on an annual review cycle, so we
> certainly know it's possible.
>
>
>
> The concerns with the organization validation are similar to those of the
> domain validation: can we reasonably be assured it's freshly validated? A
> significant number of issues have shown, over the past five years, that the
> continued reuse of this information represents a real and tangible risk to
> the ecosystem. I've avoided pulling out specific examples, so that CAs do
> not feel targeted, but I would say the overall sentiment is that the 27
> month revalidation represents a real and unacceptable risk, and we plan to
> take all steps necessary to ensure users are adequately protected.
>
>
>
> Unfortunately, so long as the maximum is permitted, no one can benefit
> from CAs that wish to improve security - users and sites will always be at
> risk from the weakest of CAs.
>
>
>
> It would be ideal to capture these in the Baseline Requirements, rather
> than Root Program requirements, so that we can avoid any complications or
> confusions with respect to audits. Naturally, we should expect Root
> Programs to do what is necessary to protect their users regardless.
> However, if there were a significant number of members that felt that it
> would be better to add warnings or to remove the communication of such
> information, for any CA that didn't document its procedures at 398 months
> and provide accompanying audits to that fact, I'm more than happy to remove
> that section.
>
>
>
> On Fri, Aug 23, 2019 at 7:39 AM Doug Beattie <doug.beattie at globalsign.com>
> wrote:
>
> Ryan,
>
>
>
> Have you considered keeping the organizational level data re-use period at
> 27 months?  When we discussed last month you seemed open to that.
>
>
>
> Doug
>
>
>
> *From:* Servercert-wg <servercert-wg-bounces at cabforum.org> *On Behalf Of *Ryan
> Sleevi via Servercert-wg
> *Sent:* Saturday, August 17, 2019 2:27 AM
> *To:* CA/B Forum Server Certificate WG Public Discussion List <
> servercert-wg at cabforum.org>
> *Subject:* [Servercert-wg] Ballot SC22: Reduce Certificate Lifetimes
>
>
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190823/3996cd91/attachment-0001.html>