[cabfpub] Draft Ballot 185 - Limiting the Lifetime of Certificates: User input

Fri Feb 10 19:28:19 UTC 2017

> Indeed, if browsers aren't enforcing the rules, not following the rules can be a competitive advantage for CAs. That is, they can make more money by doing the wrong thing, even though its forbidden, and thus it's very hard to convince them to do the right thing, the thing
> that they agreed to. By being able to enforce it in software, we help CAs resist the temptation to put the Internet at risk.

So the CAs can break the rules now for one year after another instead of many years in row? I can’t really follow that arguement. If there are failures, revocation is required and reissue needed, if the validity period is 1, 3, 5 or 10 years. BR requirement failures are scanable, there are services out there doing that. CT already gives additional control. If you introduce new trusted validation rules, should be a one time thing and nothing done from year to year. So if you want a customer sign, I still promote the lock for encryption and a signal, everyone learned at school, for validation level. Red is self validated, yellow is domain validated, green is organization or extended validated (last one also stating the company name). If it’s on the new rules, it’s showing the signal in yellow or green, if it’s on the old ones, it’s like disabled EV sign just greyed out.

> I'm not sure I understand?

If I’m customer of a CA revoking certificates without notification and replacement deadline, I no longer will order any more certs from this CA.

> Odds are, whatever certificates you currently have, they were validated with a method prior to Ballot 169. As Ballot 169 significantly changed the rules for validation, to improve security, we can logically conclude that your certificates were issued with a practice that's
> insecure.

Honestly I don’t see a significant increase of security for the certificates we handled. Mis-issues should be revoked. If you really see there significant changes, which require an additional sign, find my idea above. If you see grievances in particular certs, this ones should be replaced.

> CT is not a revocation method. It doesn't address the same set of problems.

As you seem to see problems with OCSP, CTv2 may be a solution.

> However, even if revocation worked (and it doesn't), you still have the set of issues I highlighted in https://cabforum.org/pipermail/public/2017-February/009526.html regarding warning fatigue. If you haven't heard that phrase before, you can learn more about it
> at https://en.wikipedia.org/wiki/Alarm_fatigue . The basic idea is that the more warnings a system makes, the more likely they are to be ignored. It's a very primal part of human cognition.

I use HSTS for my private website. My home firewall has the strange problem, I can’t install intermediate certificates, so the chain is broken. Whatever I try to do, I can’t get Chrome let me open my firewall web admin with the domain of my website, so I need to workaround by the IP address. So warning fatigue is a problem, but preventing any other action doesn’t allow ignoring at all, however...

> So things which drastically increase the set of warnings - such as revoking all the certificates done with something insecure (like pre-169 validation), unfortunately drastically increases the number of false alarms (relative to the user's perceived risk), and the less secure the
> whole ecosystem becomes.

... you say yourself here „relative tot he user’s perceived risk“, so I don’t see the need to revoke all and immediate. Revoke the real mis-issues, for other urgent situations give deadlines, so there are real not ignorable warnings for the ones without reaction or really harming security, all others should be done better in future.

> Certificate updates are just patching the 'old' certificate with the 'new' standards. That is, it's an update, it's patch management. Luckily, applying patches once a year is something you're no doubt familiar with, so it's likely not an issue.

As responded to Gervase before, I don’t talk about the certificate updates, I talk about rolling out new algorithms or other major changes, which require infrastructural changes to the environment, which can’t be done in one year. Installing a new cert can be done once the year, if it’s only that and this process can be simplified, however I still don’t support it should be automated, but there is also no need for automation if it’s done once a year. My statement here was on automation is the better security of tomorrow, which I don’t support, my statement otherwise is, that for changing algorithms or major changes, which require infrastructural changes, 1 year is too less time, for broken security, revocation (with reissue deadline) is the means of choice.

> Unfortunately, the understanding of Mirai isn't quite accurate - many of the devices were compromised due to firmware issues, for which updates are available, but of course, few have installed. I was trying to make the point that not applying updates puts the Internet at risk.
> It sounds like you agree with me, and so I'm trying to convince you that replacing certificates once every 13 months is just another type of update.

I’m not talking about not doing any updates at all. I’m talking about updates in enterprises aren’t and shouldn’t be automated but following processes. Updates for consumers may be better automated, if the consumers aren’t aware of what they do and vendors provide software, which isn’t aware of security either e.g. by requiring a password at setup time before getting access via internet or set a default password, which is not guessable. Replacing certificates every 13 months following a process is inline with security best practices, however it’s not the goal of this ballot. The goal are (as you stated) not just (but also) algorithm changes and may be other changes, which can or can not harm enterprise infrastructure and could be handled better with existing methods, which are fitting the need much better.

> Thankfully, this proposal is only focused on 13 month certificates, and automation is not required for that, and it sounds like you agree with that. Does that hopefully address your concern about this specific proposal - of limiting certificates to (effectively) 13 months?

No, it doesn’t as automatism is only a side-effect discussed with this Ballot. The primary focus are the 13 months to phase out anything faster and moving forward faster and I see other methods for urgent issues the right solution instead of limiting the lifetime and also not to just 13 months, for evolution I believe 39 months are a good timeframe, followable by enterprises, as a compromise I would also vote (however, I can’t vote) for 27 months, but less is unrealistic.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170210/139ed5e5/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3400 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170210/139ed5e5/attachment-0003.bin>