<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 10, 2017 at 10:25 AM, Christian Heutger <span dir="ltr"><<a href="mailto:ch@psw.net" target="_blank">ch@psw.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">







<div bgcolor="white" lang="DE">
<div class="gmail-m_-1195469585261826356WordSection1"><span class="gmail-">
<p class="MsoNormal"><span style="font-size:11pt;font-family:calibri">> </span>
However, as the Forum discusses changes to domain validation (Ballot 169/181/182 and the subsequent activities of the PAG), as it discusses CAA, as the Forum evaluates precision around the scope of the Baseline Requirements, these are all presently things which<u></u><u></u></p>
<p class="MsoNormal">> Relying Parties and Subscribers - such as yourself - cannot currently expect to take place sooner than 39 months.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
</span><p class="MsoNormal">I don’t believe, such changes need to wait 39 months. Why not introduce them to new certs from date x?</p></div></div></blockquote><div><br></div><div>That's actually the crux of the issue here :)</div><div><br></div><div>That is, we want (and do) do exactly that - new certificates get introduced.</div><div><br></div><div>The problem is that we have a large body of certificates using the 'old rules', and those certificates will stay valid for 39 months. That means browsers/software can't actually enforce those rules, since enforcing those rules means rejecting the 'old' (but still valid) certificates.</div><div><br></div><div>The consequence of this is that, without enforcement, we're simply relying on CAs to do the right things and not mess up. And unfortunately, many CAs aren't doing the right thing, or they are messing up frequently. And because even a single CA messing up puts the whole of the Internet at risk, browsers really want to be able to enforce the new rules (AFTER they've been phased in), and reject any certificate that does the 'old' thing.</div><div><br></div><div>Right now, it generally takes about 4 years for any change to become enforceable, at a minimum. However, because some CAs were able to issue 10 year certificates (~pre 2014) or 5 year certificates (~pre 2016), there are a LOT of old certificates out there, so many of the improvements we're making, we're just having to trust that CAs are taking them seriously. And, unfortunately, we keep finding out that CAs are not taking them seriously, and that makes everyone (... except that CA, and perhaps their customers) sad.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="white" lang="DE"><div class="gmail-m_-1195469585261826356WordSection1"><div>
</div>
<div><span class="gmail-">
<p class="MsoNormal">> If the answer is "The CAs should revoke those certificates," then again, as a customer, are you prepared for the possibility that your CA may suddenly make your site or server stop working - potentially even with no notification (again,
 as we've seen some CAs do)?<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
</span><p class="MsoNormal">If the CA doesn’t give me a deadline to replace because of bad validation, it’s the longest time, I was with this CA.</p></div></div></div></blockquote><div><br></div><div>I'm not sure I understand? </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="white" lang="DE"><div class="gmail-m_-1195469585261826356WordSection1"><div><span class="gmail-">
</span><p class="MsoNormal">If any practice is insecure, revoke, that’s one of the reasons for revocation. Why wait one year or is the final proposement certificates for hours or minutes, revoke and it’s done.</p></div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>Should all of your certificates be revoked then? Of course not.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="white" lang="DE"><div class="gmail-m_-1195469585261826356WordSection1"><div><span class="gmail-">
</span><p class="MsoNormal">The <b>Online Certificate Status Protocol</b> (<b>OCSP</b>) is an <a href="https://en.wikipedia.org/wiki/Internet_protocol" title="Internet protocol" target="_blank">Internet protocol</a> used for obtaining the revocation status of an <a href="https://en.wikipedia.org/wiki/X.509" title="X.509" target="_blank">X.509</a> <a href="https://en.wikipedia.org/wiki/Digital_certificate" title="Digital certificate" target="_blank">digital
 certificate</a>. ?! It’s the way to reject anything insecure by demanding revocation, when status can be checked via OCSP. If you disalike OCSP, you want to have CT logs for all certs in future. Then set the status in the CT log and check against that?</p></div></div></div></blockquote><div><br></div><div>CT is not a revocation method. It doesn't address the same set of problems.</div><div><br></div><div>However, even if revocation worked (and it doesn't), you still have the set of issues I highlighted in <a href="https://cabforum.org/pipermail/public/2017-February/009526.html">https://cabforum.org/pipermail/public/2017-February/009526.html</a> regarding warning fatigue. If you haven't heard that phrase before, you can learn more about it at <a href="https://en.wikipedia.org/wiki/Alarm_fatigue">https://en.wikipedia.org/wiki/Alarm_fatigue</a> . 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.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="white" lang="DE"><div class="gmail-m_-1195469585261826356WordSection1"><div><span class="gmail-">
</span><p class="MsoNormal">Updates are okay, but managed patch management (see ISO 27001 clause A.12.6.1 and best practice A.12.6.1 in ISO 27002). </p></div></div></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="white" lang="DE"><div class="gmail-m_-1195469585261826356WordSection1"><div><p class="MsoNormal">Mirai is a lack of awareness of users (no passwords, no updates at all), which is a problem of the consumer world, we
 talk about automation for enterprises or minimum users, which are able to run web, ... servers and may harm end users security while browsing the web and no noob installing a home router or camera without knowing anything about what he is doing there. For
 this ones, autoupdate may be a solution, however awareness is better.</p></div></div></div></blockquote><div><br></div><div>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.</div><div>  </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="white" lang="DE"><div class="gmail-m_-1195469585261826356WordSection1"><div><p class="MsoNormal"><u></u></p>
</div>
<div><span class="gmail-">
<p class="MsoNormal">> While I am unlikely to convince you that automation is the right answer, despite the industry widely moving towards that and recognizing it as a global "health" crisis, I do want to highlight that the opinion you're advocating is not
 one that is widely shared within the<u></u><u></u></p>
<p class="MsoNormal">> industry.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
</span><p class="MsoNormal">Depending on the target group I agree or disagree. Automatism, especially necessary required one, isn’t the solution for everything, <br></p></div></div></div></blockquote><div><br></div><div>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? </div></div><br></div></div>