<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 22, 2016 at 10:27 AM, Rich Smith <span dir="ltr"><<a href="mailto:richard.smith@comodo.com" target="_blank">richard.smith@comodo.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
Ryan,<br>
As I believe I stated the last time I brought this up, I chose 6
months because I know for a fact that several member CAs plan their
dev roadmaps out that far because they have stated as much in
discussion of time tables on various ballots. And because I don't
think it is an excessive amount of time for a NON-CRITICAL update. </div></blockquote><div><br></div><div>As mentioned in the past, couldn't this argument be made for 12months?</div><div><br></div><div>I get the argument that "This is how CA's have done it," but as in the past, I fundamentally question whether "This is the right way to do it".</div><div><br></div><div>As a CA, you're no doubt familiar with the fact that the less often a customer changes a certificate, the more likely they are to do it wrong when they have to. That is, a 3y cert will easily expire without notice, because people forget about it. Similarly, organizations can easily forget how to change a cert or all the places that they need to change a cert when it's an infrequent task.</div><div><br></div><div>I'm not opposed to picking a sane default, but I think anything beyond 3 months should really require exceptional justification, and largely predicated not on the hardship to CAs, but the hardship to subscribers. For example, the transitions from SHA-1 and Internal Server Names were security critical, for sure, but the need for infrastructure changes on infrastructure necessitated a longer phase-in.</div><div><br></div><div>Without wanting to appear disrespectful to the members here in the Forum, it's become an unfortunately routine experience to see CAs either entirely failing to adopt the necessary policies or, equally common, making an evaluation about security that we respectfully (and, in some situations and for the worse, empirically) disagree with. As such, I struggle to think that the discussions will go differently each time a ballot comes forward - we'll argue it's security or operationally relevant, you or other CAs will disagree, and the result is users end up less secure. I'd much rather if, as an industry, we recognized the security-critical role that CAs play, the opportunities that exist to be industry leaders and agile in the way that reflects their critical position in security, and by default moved at a "fast-but-reasonable" pace by default. I believe 3 months meets that, but I struggle to see how 6 months, in a world dominated by 90 day disclosure policies, could reasonably be argued as such.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">My primary goal is to let everyone, including those who write the
audit standards, get out from behind the eight ball constantly
chasing ballots with immediate effect, which seems to be the current
default, by moving the default to 6 months. </div></blockquote><div><br></div><div>I'm not sure I share your goal, precisely because of the fact that the continued operational failures of some CAs are constantly eroding trust in the whole CA market, and the so-called "constantly chasing ballots" is one way in which the ecosystem, as a whole, shows its committed to responding in a timely fashion.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"> I think it fits well
with, say, a quarterly release cycle because it allows the CA to see
what's coming and plan for it, but not have to interrupt the current
in-development version with an emergency change. They can let the
current version proceed as planned, and add in whatever CA/B
required change into the next cycle.<br>
<br>
I've made my case why I think it's a reasonable default (twice now),
and stated that even though it would be the <i>default</i> it is
certainly mutable if the situation requires it. Please make your
case for why you don't.<br></div></blockquote><div><br></div><div>Simply put, I think we may reasonably disagree whether or not it's responsible or appropriate for a CA to update on such an extended timetable. </div></div></div></div>