[cabfpub] Ballot 173 - Removal of requirement to cease use of private key due to incorrect certificate info

[Ryan Sleevi]

On Fri, Jul 22, 2016 at 10:27 AM, Rich Smith <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/70661b46/attachment-0003.html>