[Servercert-wg] Ballot SC22: Reduce Certificate Lifetimes

[Ryan Sleevi]

On Wed, Aug 21, 2019 at 6:23 PM Christian Heutger via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> > I think it's important to note that these responses can be read, and
> certainly read to me, as a powerful display of how dysfunctional many
> enterprise customers remain today, when it comes to
>
> > their certificate configuration and in how they view automation and
> modernization. That so many organizations continue to mistakenly believe
> that doubling their manual renewal rate would
>
> > cause severe disruption, or that automation of certificate issuance is
> an unimportant aspect of their own organizational security and agility, is
> a compelling reason to proceed with this ballot and
>
> > mandate reduced certificate lifetimes. The survey results make clear
> that many current enterprise customers are not prioritizing this work on
> their own, and that a mandate covering all CAs at
>
> > once is likely the only effective way to drive progress here.
>
>
>
> Or it shows, that enterprises reject automatism because of many reasons
> and prefer a systematic change management process. In which position are
> you to force enterprises to be unable to decide, if they prefer automation
> or want to stay on a formal change management? And it’s not about just a
> one year validity period, it’s about that this won’t be the last step. So
> this lowering down of lifetimes as workaround instead of working directly
> on the primary problem and issue should be negotiated at all and enforcing
> companies to follow your position on automation is really a bit arrogant.
>

Unfortunately, the current practices these Enterprises practice makes the
ecosystem less secure and less robust. All organizations MUST be prepared
to replace certificates in a timely fashion, to ensure that users can be
protected when, e.g. certificates need to be replaced because the issuing
CA violated one or more Root Program requirements, when the method used to
validate the authorization for the certificate is determined to be
insecure, the CA is distrusted, etc.

It is not possible to accommodate the needs of Browser users, that is, the
need for billions of users to have a reliably secure connection to the
server indicated in/specified by the domain, while also accommodating the
needs of organizations that reject basic security practices, such as the
ability to replace certificates as needed, potentially even during
holidays, production freezes, or other events.

A problem, which is one of many, is that these Enterprises reject practices
that ensure they can replace certificates in a timely fashion. It is
explicitly intentional that such cases become more costly, in terms of time
and engineering effort, for organizations that wish to hold onto those
antiquated notions. That's because right now, all users and all sites that
wish to have reliably secure connections to their users are forced to bear
the costs and risks introduced by these organizations. This change will
rebalance that cost, reducing the costs and risks to users, although
admittedly, at the potential risk of additional cost to organizations that
reject such basic practices. However, the vast majority of organizations,
if supported by a well-run CA, will likely find that both the cost, and
risk to their organization, decreases. If your CA is not helping you
realize those reduced costs, it may be worth re-evaluating the CA.

As a concrete example, consider what would happen if the CA used by these
organizations were distrusted, such as due to routine failure to implement
the required validation process, or failure to oversee their Registration
Authorities or their Subordinate CAs. Such a CA poses a risk to every
secure site on the Internet, and every user, in that the CA's failure to
exercise the required controls can and will likely result in a misissued
certificate. Attempting to accommodate such organizations, by delaying the
distrust of such a CA, simply transfers the risk and harm onto all other
users. This is unacceptable, and we do not plan to support such use cases
going forward.

This is not a hypothetical risk. It has happened to several CAs. Even on a
less significant level than complete and total distrust, a number of the
leading members of the Forum have had to require some subset of customers
replace their certificates, due to these CAs' misissuances and control
failures within the past year. There are, admittedly, organizations, even
very large and important organizations, that are not and were not
adequately prepared for this. I do not dispute this. However, as we've seen
from the past decade of discussion here in the Forum, and especially in the
past five years, attempting to accommodate these organizations harms the
overall security of the Internet. Reducing lifetimes helps balance that
risk and harm caused by attempting to accommodate these organizations.

To be clear, this ballot does not require automation. Nor does it require
any organizations to make any operational changes before the enforcement
date. Existing certificates continue to work and can be replaced on their
normal schedule. When they are replaced, they will be a shorter lifetime.
Thus, in practice, the earliest an organization should be impacted by this
should be 2021, not 2020.

One exception to this, is that if the CA is relying on information that has
not been revalidated in the past six months, they may need to revalidate it
within the next six months. That is not an unreasonable requirement, given
the risk stale information poses. However, this does not require any
operational changes by these organizations.

As noted earlier in this thread, CAs that wish to support their customers
in this transition can do so in a way that minimizes the need for
configuration management. Some CAs, such as Amazon, have clearly
demonstrated that it's possible to comply with the Baseline Requirements
and support customers in this way, without requiring additional recurring
validation steps nor additional automation. Regardless of this ballot,
there is no harm in organizations beginning revalidations now, nor does
revalidation of information require any disruption or configuration
changes, with or without this ballot. Thus, any holiday or production
freezes are irrelevant to that requirement, and customers do not need to
replace their certificates outside of their normal cycle anytime in the
next 18 months.

I am extremely interested if there are considerations that have been
overlooked in this calculus. We have been studying this problem for a
number of years, have extensively considered factors such as holiday
freezes, the effort involved in changes and revalidations, the risks posed
by CA's non-compliance and potential removal of trust, and the impact to
organizations large and small. Despite the small disruption this may cause
to some organizations and enterprises, this is still the right thing to do,
and the best thing the CA/Browser Forum can do to help protect and promote
a secure Internet. Regardless of the CA/Browser Forum, this remains one of
the best things that browsers can do to protect their users' HTTPS
connections, now and in the long-term. If organizations feel that something
has been overlooked, now would be the time to share that.

I'm similarly interested if there are any CAs not aware of or actively
promoting best practices here. To try to summarize some of the past
discussions.
* As discussed, automation solutions, such as RFC 8555, are robust, secure,
and widely available for a variety of servers and programming languages,
and represent ideal steps for organizations to move to.
* DNS-based validation solutions, such as those demonstrated by Amazon
during the ballot discussion, or even those HTTP-based methods with
redirects, offer ways to help organizations securely manage and mitigate
any impact from additional domain validations.
* Organizations that are worried about certificates expiring throughout the
year can easily and readily renew their certificates early, in order to
align their certificates on a common renewal period. Alternatively, they
can replace their existing certificates with those of a reduced lifetime,
such that they'd be renewed at a common time.
   * A number of CAs, particularly the well-managed CAs, allow their
customers to do so for free, without additional cost. If your CA does nor
or is not offering this, it may be worth reconsidering the CA used, if this
is a concern you (or organizations like yours) share.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190821/27d41863/attachment.html>