[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