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

[Rich Smith]

Gerv,
I've come down from 6 month suggested default to 90 days, as per 
feedback from Ryan, and I will fully support that as a default, however 
you've now moved the bar to 45 days, and while I'm fine with that on 
Ballot 173, I strongly disagree with it as a default.

As per this:
https://wiki.mozilla.org/RapidRelease/Calendar
Firefox is basically on a 3 to 5 month release cycle from alpha to final 
release.  Near as I can tell Chrome follows a similar type of 
over-lapping release schedule.  I don't think it would be fair to ask 
Mozilla or Google to incorporate a NON-CRITICAL update into a release 
which may be well into beta/QA testing in order to hit an arbitrary 45 
day deadline, and I don't think it's fair to ask it of CAs either.

CRITICAL updates are a different matter, and I think we have a pretty 
good track record of dealing with those, with one example being the 
Debian weak keys issue of a few years ago.  As I recall CAs managed to 
get those keys blocked and get certs that were issued with them replaced 
and revoked in a pretty short time frame and we did it not because of 
some arbitrary deadline, but because it was a CRITICAL security issue, 
it was recognized as such and we pulled out all the stops to make it 
happen.  But I certainly don't think every ballot warrants a Debian weak 
keys fire drill.

-Rich

On 7/23/2016 3:50 AM, Gervase Markham wrote:
> Hi Rich,
>
> On 22/07/16 18:27, Rich Smith wrote:
>> 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.
> As they told me in my first job, "what is a plan? A basis for change". I
> think any CA which decides what development it is going to do 6 months
> in advance and has no capacity to react to events is not using a
> development paradigm which fits the nature of its industry. Clearly
> something that involves major reworkings needs significant lead time,
> but most CAB Forum ballots are more at the "tweak" end of the scale -
> add this OID here, change this field there, modify this CPS here.
>
> So I think a shorter value should be normal, and a longer one needs to
> be argued for on a case-by-case basis. And if a particular CA keeps
> finding itself blindsided by 45-day requirements for cert contents
> tweaks that it can't meet, it needs to become more agile (small-a or
> big-A :-).
>
> Gerv