[cabfpub] Default ballot timeline - Was: Ballot 173 - Removal of requirement to cease use of private key due to incorrect certificate info

Tim Hollebeek THollebeek at trustwave.com
Fri Jul 22 19:20:43 UTC 2016


For what it’s worth, I also think it would be useful to come to some agreement about a default policy, so we don’t have to keep discussing this over and over for every ballot.  Ballots that are exceptional could still have explicit deadlines.

Something along the lines of “CAs MAY comply with updated requirements upon adoption, and MUST comply within 90 days, unless otherwise specified in the ballot”.

I’ll also note that something like 30 days seems like a remarkably short time if it just so happens to correspond to the same month you are getting audited!  It’s always important to remember that organizations may have other priorities, and being forced to arbitrarily reallocate resources to comply with arbitrary deadlines around minor issues can due real harm.

-Tim

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Rich Smith
Sent: Friday, July 22, 2016 3:13 PM
To: Ryan Sleevi
Cc: CABFPub
Subject: Re: [cabfpub] Default ballot timeline - Was: Ballot 173 - Removal of requirement to cease use of private key due to incorrect certificate info

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.


________________________________

This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160722/56710927/attachment-0003.html>


More information about the Public mailing list