[Servercert-wg] Ballot SC22: Reduce Certificate Lifetimes

Christian Heutger ch at psw.net
Mon Aug 26 12:13:49 MST 2019


> While I disagree with cherry picking participants, particularly those that demonstrate good practices, I do worry that some others may have this mistaken and incorrect understanding. Thus, I think it bears addressing this misconception that somehow Let's Encrypt is significantly impacting these numbers. If you wholly exclude Let's Encrypt from considerations, the numbers remain fairly close - 86% of certificates in use are already prepared, vs 13% which, when renewed, would have lower lifetimes.

I used many statistics out there and they look different. If you remove LE, which may have a completely different approach, which otherwise won’t let them operate their „business“ sponsored by Google, Mozilla and others. In entering root program, many strange behaviors occured, so I won’t see them as „the best practice“. Also although their cert lifetime is short, I saw e.g. phishing sites running for days with a valid cert, which would never get a cert by the flagging system of others.

> However, this sort of analysis entirely misses the metapoint, which is that this is both right and necessary for the security of users online, and simply measuring the lifetime of extant certificates doesn't reveal particularly compelling information. Of substance, and useful, is to understand specifically the challenges and incompatibilities, so that a holistic ecosystem view can be taken. I'm sure individual IT managers will, out of understandable necessity, fixate on their local impact. We've seen as much in discussions of HTTPS or any change in anything. However, that does not mean that the changes are not justified or necessary; it merely provides opportunities for CAs to better help their customers understand the role in which normative requirements, such as those in the Baseline Requirements or Root Programs, helps keep everyone secure.

If you state best practice with huge numbers, it should also be negotiated, if this numbers are reliable. I believe, everyone understands the challenges, but they don’t follow the solution approach as neither it has been shown, that past reductions worked on the goal (if it’s the right measurement, there should already be any valuable quick-wins) nor that it fit the problem, it’s working around the problems instead of addressing the issues themselves. So this „solution“ is just „a try“ for „in case“ issues, some people may consider other reasons for this step, as it burden much effort without any proof of success, it’s just a trial.

-------------- 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/20190826/386e3c49/attachment.bin>

More information about the Servercert-wg mailing list