[Servercert-wg] Ballot SC22: Reduce Certificate Lifetimes

Christian Heutger ch at psw.net
Tue Aug 27 23:10:20 MST 2019


Hi,

I‘m currently a bit spare of time, but OCSP stapling as a solution I tried in my private 100%+ researches for my private sites and I activated it without any issues in nginx, one of the most wide spread and reliable web server. Postfix (instead of Exim) was my only drawback, not to support stapling yet. For sure, if it would be a requirement, software would really quick adopt.

> Unfortunately, the structure of the Forum makes it difficult for CAs to vote for the right thing (for users and security), although it provides an excellent venue for discussion about considerations and tradeoffs, which I really appreciate you doing here. This is something that I'd been looking for from a variety of CAs, to make sure I understand the tradeoffs.

CA are for sure concerned about users and security but also need to focus on solutions and timeframes, which could realistic been rolled out. If that would fail, no-one has an advantage.

> Namely, before the transition date, issue a bunch of certificates using the old profile, so that folks didn't have to deploy right away. That was such an inbuilt assumption here that it's why I was highlighting the value proposition as being June (now July) 2022 - I assume there's going to be a supernova-style burst of issuance in the weeks before, and that's why the change to April, rather than March - to avoid February freezes that might make that challenging.

Did you thought about, why this practice has been performed? Maybe as enterprises raised concerns about the timeline and have the only two options, to be offline until their projects have been done or get a workaround to delay the effective date. As well as reducing lifetime for the reasons is a workaround (although Eric stated, it may, for some, especially the ones, who are willing and able to automate, be a valuable option), workarounds are looked for as well on unrealistic timeframes.

> For OV and EV certificates, these are, by design, manual processes which require a lot of hand-holding activity by CAs. On the one side, they allow for additional information which, if validated correctly, consistently, can provide value to relying parties that might want to make use of this information. On the other, however, these certificate profiles continue to be used as a reason to hold back the ecosystem from changes, because many of the beneficial changes that might be discussed, such as strengthening validation methods, reducing information reuse, or anything that might require certificate replacement or reissuance, end up impacting these profiles much more than the core DV profile.

I‘m concerned about reading, how browsers see and yet deprecated OV and EV. They are the only profiles, which are valuable to call it certificate. DV is somehow just a baseline to prevent warnings, but this weak validation finally tells nothing. If talking about security of users, OV and EV are the most important profiles, there is (as always in an ecosystem) space for improvement, but if not recognized by the users as expected behavior, there may be the need of a good job by the browsers as well. I’m concerned if talking about security on one end comes in the same times, cuttig security on the other.
-------------- 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/20190828/f95f8e06/attachment.bin>


More information about the Servercert-wg mailing list