<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Ryan,<br>
My primary reason for selection of 6 months was in deference to
stated dev cycles of several members. As to making the same
argument for 12 months, even I would say that's excessive. I'm not
sure I agree with you that 6 months is when you're dealing with a
large organization and talking about things which touch upon core CA
infrastructure, customer facing websites, along with possible
customer documentation, CP/CPS changes which inevitably must involve
legal departments, etc. That's a lot of potential cat-wrangling.<br>
<br>
For the record I think Comodo would be fine with a default 90 days,
but I can also see where a larger and more dispersed organization
may see 90 days as a very short time line. But my primary goal is
that as a group we come to an agreement that the default should be
some reasonable amount of time greater than "immediate effect". If
the consensus is 90 days I'm OK with that.<br>
<br>
-Rich<br>
<br>
<div class="moz-cite-prefix">On 7/22/2016 12:56 PM, Ryan Sleevi
wrote:<br>
</div>
<blockquote
cite="mid:CACvaWvZdGG4tOT1TBGwoTDS4rHPm3sGUG8o2+1i-E6yboKr6rg@mail.gmail.com"
type="cite">
<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 moz-do-not-send="true"
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>
</blockquote>
<br>
</body>
</html>