<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 10, 2017 at 2:32 AM, Christian Heutger via Public <span dir="ltr"><<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</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"><span class="gmail-">> If the effort of replacing a certificate is equivalent to the effort of deploying a new version of Windows, then something is very wrong in that environment.<br>
<br>
</span>I don’t talk about the effort of replacing a certificate. I talk about the driver behind limiting the lifetime and what would and primarly (as it’s the driver of this ballot) will happen on limiting the lifetime: Algorithm changes in 1 year. </blockquote><div><br></div><div>Apologies for any miscommunication I may have contributed to, but I think it's significant to address this:</div><div><br></div><div>The driver is not _just_ algorithm changes in a year. I fully and wholeheartedly agree with you that, as an industry, that there are far greater ecosystem challenges to such systems than we can reasonably accomplish, and am not trying to suggest that in a years time (or less!) we can move to a new algorithm.</div><div><br></div><div>Rather, the driver is that we set the _minimum_ time for any change in practices to be 13 months. That's not to say that the _maximum_ for any change takes 13 months - we still may and very likely will need to phase some changes in over years.</div><div><br></div><div>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 Relying Parties and Subscribers - such as yourself - cannot currently expect to take place sooner than 39 months.</div><div><br></div><div>Put differently, imagine that the validation practices presently practiced by CAs are insecure (which, by the way, they unfortunately are). As a customer, don't you feel better assured that you can have consistent protection within a years time, as opposed to knowing that browsers and relying parties will continue to accept 'bad' certificates for years?</div><div><br></div><div>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)?</div><div><br></div><div>In many ways, as a customer, this reduction helps protect you and your users. It does so by ensuring that if any practice is deemed to be insecure - whether it's something like an algorithm (which has a whole host of ecosystem dependencies) or something like how the CA validates a certificate request for your domain (which I'm sure you would only want them to issue to you, and not a malicious attacker) - the damage is limited to, at worst, a year.</div><div><br></div><div>However, you can only be assured that when Relying Party software (browsers and libraries) actually enforce whatever the 'new' requirements are, making sure they reject anything that uses the 'insecure' thing. However, browsers and software can only enforce when the 'old' certificates are expired. This is why it allows for a more rapid rotation.</div><div><br></div><div>The 'cost' to you, as a customer, is that you have to replace your certificate once every 13 months, rather than once every 39 months. However, hopefully you can see how that small cost - easily human maintainable - comes with significantly more assurance that bad practices will be stopped.</div><div><br></div><div>If it would help, if you'd like to share which CA or CAs you use, I'd be happy to go through and find practices or issues that the CA has, which you may not be aware of, and that would show why you and your customers are at risk from their negligence or lack of care.</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">I propose, we shouldn’t go to an automated job as this conflicts with many security best practices as stated before. Simple it can be (the technical job itself), but should not be automated.<br></blockquote><div><br></div><div>On this point, we must respectfully disagree. Across the spectrum of Internet security - whether through the IETF, through the practices software vendors practice (Apple, Microsoft, Google, Mozilla, among just a few), or through what you see through modern web development - there's universal agreement that regular security updates is a necessary thing. This is why 'native' software is released regularly, on the order of days (websites), weeks (applications in the Android and Apple App Stores), or even within months (modern browsers). The lack of such routine and modern updates is also why we have such Internet-crippling issues like Mirai ( <a href="https://en.wikipedia.org/wiki/Mirai_(malware)">https://en.wikipedia.org/wiki/Mirai_(malware)</a> ) </div><div><br></div><div>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 industry.</div><div> </div></div></div></div>