[Servercert-wg] Ballot SC22: Reduce Certificate Lifetimes

[Christian Heutger]

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

That’s exactly, what I meant: If(!) there are such issues arising. An emergency change is something different and for sure could and should be handled, there should be methods and it should be optimized, that such issues won’t arise, but for “just in case” it’s no good idea to enforce a not well accepted solution as automation and it’s also not the idea of measurements on risks.

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

Automation is no(!) security best practice. Where can you state, that automation is a best practice, show me references beside the companies, which now try to sell AI and automation solutions as the new security approach!

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

Somehow all CA support possibilities for automation, so maybe there should be a reason, why automation is not established…

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

Again my question from before, what is the job of WebTrust and ETSI audits? Do all of them fail? What are they worth, if reading your statemtents look like that all CA always violate BR? If they do, continued, always and permanent, WebTrust and ETSI auditors need to be fired, as they seem not to do their job and you need to shut down KPMG, PWC, EY and all other auditing organisations, as they lie, misuse, get paid for reports and don’t do their job? It’s a bit confusing, if you claim mishandling on one hand and auditors certify such companies on the other? Looks a bit strange, isn’t it? I know, that RA should also perform WebTrust RA audits, therefor RA audit requirements exist, to ensure, that such issues as in the past with RA don’t arise anymore?

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

Again, then require such CA (or all CA) to use services which monitor such misissuances and require the CA to correct them in a timely manner. I know, that Netcraft has such a service. So it’s like a continued factor beside the WebTrust and ETSI audits. However, reducing the lifetime won’t let the CA do their job better, if e.g. goal is days or hours (you never stated yet, there the journey should end but to follow your argumentation, that’s the only valid possibility), they will then issue many certs each hour or day with the same misissuances practices, so I don’t see any improvement?

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

The ballot don’t require itself, however, it already has been stated, that you want to lower down more and more. So March 2020 we will have 1 year, March 2022 we will have 6 months, March 2024 we will have 3 months, … There is no reasonable outcome, if you really want to follow your argumentation, you should lower down to 1 day instead of 1 year, which will result In all the side effects mentioned before, so I don’t see any profit from 1 year, again, can you proof and show, what got better by reducing the lifetime from 3 to 2 years, which is measureable?

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

There are your study results? Please provide them? Which user base did you ask? CA like DigiCert and Entrust asked their partners, customers (certificate users), the information you got back speaks a completely different language. I’m sure, they will also provide the textual responses with reasons why. You may look for ways to ask the enterprises, as they won’t follow this discussion and forum, so if you don’t want to hear, that CA surveys of certificate users (which should involve the enterprises mentioned), you need to find another way to contact them. If CA contacting their customer base, you will have response of the certificate users, but again, if you want to reject that opinion, you need to do your own study, maybe would be best to find an independent valuable partner to do such a survey.

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

There are many nice RFC, which are fine, but have problems, are against best practices or adoption doesn’t bring the advantage as promoted. I privately tested many in the last weeks like DNSSEC, DANE, SPF, DKIM, DMARC, …

Domain validations shouldn’t be the goal. Domain validation is less valuable. I know, your CA and your close partners like Let’s Encrypt and Mozilla will talk different, but it subvert the CA idea by lowering the value down to a absolute minimum.

Again, one year is just the next step, we can be sure, your next ballot is on hold already.

Sure, everyone should switch to your CA, and everything else about validation is been told by Google, by paying, for sure.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190822/4a771661/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3860 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190822/4a771661/attachment-0001.bin>