[Servercert-wg] Ballot SC22: Reduce Certificate Lifetimes

Tue Aug 20 13:05:15 MST 2019

Hi,

> Certificates and phishing are entirely unrelated, which is why I asked. It seems that there's some confusion that the two should be related, but phishing is not a misuse of a certificate.

I’m sorry, but that’s not my point of view, but I’m sure, Google, Mozilla and Let’s Encrypt have other points of view on that topic. From my point of view, certificates wouldn’t be required at all, if there should be only encryption. Certificates make sense (and it makes sense to have them), to add validation. Validation should provide the possibility, that the anonymous internet could get a bit cleared up by being able to see, with whom I’m talking. Phishing is using the effect of anonymous internet and that there is a lack of information, if the one, you’re corresponding with, is the one, who it seems to be. So certificates are for being able to add a trust factor. Based on the quality of validation, it may be a strong or weaker trust factor, but it’s a trust factor in my opinion. As mistakes by happen, it should not be the only trust factor, but one of them. Weak validation and weak identification of validation troubles this idea and it’s a bit confusing talking about increasing the trust on one hand and decreasing the trust on the other.

> - While I appreciate the comparison of the Baseline Requirements to GDPR, that's a bit like comparing Apples to Orangutans. The most salient bit to point out is that the Baseline Requirements
> are not new, and the changes are, at best, mildly incremental in response to ongoing security threats. Much like organizations that wait days or weeks to patch their critical systems will quickly
> find themselves compromised (and potentially out of business), CAs that fail to be able to patch critical systems, like the Web PKI, will quickly find themselves compromised and out of business.
> Even if the GDPR analogy holds (and it doesn't), the notion of "implementing acts" as incremental guidance is still very much a thing.

I believe, that your comparison is somehow the same. Patching and critical issues to be patched, shouldn’t be something to be covered by the Baseline Requirements. The Baseline Requirements should be like a law, management systems requirements etc. and be e.g. audited by WebTrust or ETSI. Critical problems need to be covered different. If CA don’t, they are gone like DigiNotar, StartSSL, WoSign, DarkMatter etc. Implementing acts also need time to be arranged and followed-up, that’s the nature of changes, patches are completely different. Although propagating automation, it seems like at e.g. Google Plus, your security controls also didn’t work well.

> - Suggestions that Netcraft and revocation are somehow a substitute for a CA being competent to implement things correctly is an area where we will fundamentally disagree, and no amount of
> argument here would be fruitful. As noted, revocation methods require Relying Parties to either compromise their privacy (OCSP) or accept all the costs of CAs' poor practices (CRLs or browser-
> based revocation methods). This is an unacceptable tradeoff for the ecosystem, and for which reducing lifetime is the only system which considers Relying Parties needs. Yes, this means some
> Enterprises will be unhappy, but in a complex ecosystem, sometimes the needs of the many (the security of every user on the Web) outweighs the needs of a few (select Enterprises)

Google is concerned about privacy? Do you have relying numbers or studies, that this are the topics, relying parties need? What about OCSP stapling? What about the requirement to monitor, if CA do their job as expected. What are the numbers of correct implementations against wrong implementations? Do this numbers justify such step? Which issues arise, which loss did they brought to users, did you compare that with e.g. the loss by removing EV and falling victim to phishing sites? How could CA pass WebTrust and ETSI audits, if they do things incorrectly or do you shame the full audit system, that they don’t do their job? However, as mentioned before, if we only talk about BR to be implemented correctly, state them clearly in the BR, state them more clearly (if BR don’t fit your needs) in your root CA program(s), require BR version to be added to a certificate, if you feel, it does not comply to such requirements (I remember, it was required, that CSP should be machine-readable, so everything could be crosschecked), feel free to show such certs in a more deprecated manner (e.g. yellow checkmark instead of green one). We talk about maybe a few against the whole amount of users in the internet, but if talking about the userbase of enterprises to be required adopt against all enterprises, which will be covered by the change, it’s a stronger number and you want to enforce all of them to use automation, as being the only possible solution at the end, because of a few ones, a possibility, that there may be a misuse?

> - The suggestion that Browsers and CAs work together is, indeed, something we'd wholly support. However, in the years that we've been discussing this, CAs have been unwilling or unable to
> provide any technical alternative that appropriately balances the privacy and security needs of users. At this point, continuing to delay leaves users at risk, and that's simply unacceptable to the
> organizations that need to protect all of their users, and not just a few small (in the global scheme of things) enterprises.

Did you provide an alternative to improve revocation instead of a workaround like reducing lifetime? What about OCSP stapling? What about all the users using Google DNS? Will fix privacy issues with OCSP, but still ask Google DNS for resolving IP address? My recent touchpoints with Google staff I only learned about solutions against PKIX ecosystem like how DANE has been promoted, instead of trying to find solutions to strength the PKIX ecosystem with affordable problem oriented solutions.

> In any event, many of the points made make assumptions, such as revocation works or that CAs are correctly implementing validation requirements, for which we, as an industry, have ample
> evidence against. While automation is suggested as harmful, that is entirely incorrect, and improved automation of the PKI is no different in this regard than the long-standing automation that
> exists within DNS or within BGP, where such systems "just work" once configured correctly. Just as we would laugh at the notion of hand-maintaining a hosts file (as was done prior to DNS) or
> hand-maintaining global routing tables (as was done before the modern routing protocols), we should be highly suspicious of any hand-maintaining of certificates.

Again the question, so I need to expect, that you suppose, that any WebTrust and ETSI auditor don’t do their job? If they would do, how couldn’t that arise in any audit and result in no action? Or is your interpretation of the BR wrong? They don’t obligate then to such CA you found to work against the requirements, to be audited by another party, deprecated in representation, be required to use such services to correct the flaws, or if they won’t follow in the end remove the CA from the root certificate program? Maintaining DNS files or routing tables is something different than my representation outside, which should involve reliable validation and revalidation (not performed by machines but with human interaction to prevent misuse). However, this long-standing automation also wasn’t adopt worldwide in about 7 months.

> While the goal of any change to the Baseline Requirements is to minimize unnecessary impact, it's undeniable that the systemic set of issues the ecosystem faces, for which revocation is wholly
> inadequate for, and the broader benefits to the whole ecosystem, more than justify some disruption to a small set of users. The goal of this ballot, and broadly, this discussion, should be to
> highlight whether there are any factors that have not yet been discussed or considered, but which should be, as browsers look for the best tools to protect their users in reasonable timeframes.

Reducing lifetimes is as well inadequate for, it’s just the lowest hanging fruit, ignoring the effort and pressure behind. Looking at the history of Chrome, protecting users looks not as being the front line goal.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190820/d2a5ba06/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/20190820/d2a5ba06/attachment-0001.bin>