<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 9, 2017 at 1:41 PM, Dean Coclin <span dir="ltr"><<a href="mailto:Dean_Coclin@symantec.com" target="_blank">Dean_Coclin@symantec.com</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 lang="EN-US">
<div class="gmail-m_-8914543666119978405WordSection1"><span class="gmail-">
<p class="MsoNormal">Without discussing product roadmaps or timelines, can you help me understand what you believe is challenging about such a change or why it might take anything more than a week or two to implement?<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
</span><p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)">>>This solely focuses on the technical implementation and unfortunately misses the greater challenges to users, many which have applications outside of the traditional
 browser-server relationship. I and other members have received a steady flow of emails from customers, partners and organizations concerned about this reduction in validity and especially the corresponding lead time.</span></p></div></div></blockquote><div><br></div><div>Except, as noted, this doesn't cause any form of outage or breakage until June 2018. I do hope this is ample time to develop polices and practices - since no automation is required at 13 months - to prepare for that.</div><div><br></div><div>If not, we're doing the PKI wrong.</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 lang="EN-US"><div class="gmail-m_-8914543666119978405WordSection1">
<p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)">What about Managed SSL customers that have prepaid two and three year certs on invoices? What about contracts and the time to renegotiate them? It’s not only
 the CA’s portal that needs to be updated but perhaps partners and all their contracts that may have commitments.</span></p></div></div></blockquote><div><br></div><div>Do you believe the CAs who find themselves in such cases were making a good faith effort to participate in the CA/Browser Forum, knowing that discussions have been occurring for three years on this topic? Did such CAs simply assume that any possible attempt to change would be blocked?</div><div><br></div><div>Doesn't this capture the very problem we're trying to solve quite well? That is, because some members have baked certain practices into contracts, and because such contracts have prolonged validity periods, what I'm hearing you say is that it's difficult for such CAs to make or enforce such changes until those contracts can be changed.</div><div><br></div><div>What you're hearing from browsers is that because certain practices are baked into certificates, and because such certificates have prolonged validity periods, it's difficult to make or enforce such changes until those certificates can be changed.</div><div><br></div><div>How wonderfully fortuitous that we have a path whose principles might be able to be applied to contracts much in the way they're applied to certificates, and how illuminating as to the dangers and difficulties of phasing out insecure practices.</div><div><br></div><div>However, I take heart in Doug's most recent suggestion - <a href="https://cabforum.org/pipermail/public/2017-February/009532.html">https://cabforum.org/pipermail/public/2017-February/009532.html</a> - and suspect that the right approach to the problem you raise is similar to the approach Doug has suggested and which browsers, such as Microsoft Edge and Google Chrome, are taking: "go ahead and block them, they’ve all been warned and should be prepared for the consequences"</div></div></div></div>