<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 18, 2016 at 4:10 PM, Dean Coclin 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Given that the current TBS certs have passed cryptanalysis, could you allow<br>
the issuance of the TBS certs as presented, and mandate that the CA revoke<br>
those<br>
certs on 12/31 (or the next business day). This is an auditable event and<br>
browsers can push that revocation out to their clients via their own methods.<br>
<br>
I believe this meets the intent of the affected browsers by protecting their<br>
users after that date. It also avoids disruption to First Data clients on<br>
October 27th.<br></blockquote><div><br></div><div>Symantec has suggested this several times, for other incidents, as have other members of the CA/Browser Forum.</div><div><br></div><div>Our position is that revocation, while it can be useful in reducing risk to (some of) our immediate user populations, does not represent a sufficient or suitable solution for protecting the broader ecosystem or reducing the moral hazards of various proposals.</div><div><br></div><div>My understanding is that these certificates begin expiring October 27, and the current urgency was and is created by Symantec hoping to use the precedent of the previous failure to follow policy as an indicator that the policy has been changed. While unfortunate, I agree with Gerv's remarks on the moral hazard of this line of reasoning and this line of utility, and while I appreciate Symantec's exceptional efforts to work on an alternative solution for their customer, I think it's best to follow the policy as outlined some time ago. We discussed and gathered feedback on this precisely to avoid the situation we're in now - we wanted to have an objective, rather subjective, process, which you're now asking that we undermine because Symantec made an assumption, based on Symantec's previous mistake which was not caught (amidst all the other issues Symantec had with the previous request).</div></div></div></div>