[cabfpub] Default ballot timeline - Was: Ballot 173 - Removal of requirement to cease use of private key due to incorrect certificate info
Rich Smith
richard.smith at comodo.com
Fri Jul 22 19:13:14 UTC 2016
Ryan,
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.
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.
-Rich
On 7/22/2016 12:56 PM, Ryan Sleevi wrote:
>
>
> On Fri, Jul 22, 2016 at 10:27 AM, Rich Smith <richard.smith at comodo.com
> <mailto:richard.smith at comodo.com>> wrote:
>
> Ryan,
> 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.
>
>
> As mentioned in the past, couldn't this argument be made for 12months?
>
> 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".
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
>
> 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.
>
> 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.
>
> I've made my case why I think it's a reasonable default (twice
> now), and stated that even though it would be the /default/ it is
> certainly mutable if the situation requires it. Please make your
> case for why you don't.
>
>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160722/1a935cac/attachment-0003.html>
More information about the Public
mailing list