[Servercert-wg] Proposal to address ballot effective date problem

Ryan Sleevi sleevi at google.com
Wed Oct 17 17:00:08 MST 2018


I think the comparison to software development scheduling is apt - as this
is effectively encouraging a "waterfall" model. It means that necessary
improvements may take up to 3 additional months to be implemented, which
means it may take up to 3 additional months for Subscribers and Relying
Parties needs can be effectively met.

The issue here is also one without data, and I suppose it comes as no
surprise that I'm generally not sympathetic to claims without evidence.

For example, if you examine our five most recent ballots for the Baseline
Requirements, you'll find that of 224, 223, 219, 220, and 218, only two
(220 and 218) provided a more restrictive interpretation, and those two
both included defined transition dates relative to the risk and goal.

Perhaps you'd be able to take what you believe is a representative sample -
if you don't believe the past calendar year's worth of changes is
representative - to demonstrate and explain the value. To be honest, based
on the above methodology, I don't see the problem as stated or presented
being fair or accurate, and I see substantial downside compared to the
alternatives discussed, so I'm hoping you can help better illustrate the
problem that is worth solving relative to those tradeoffs.

On Wed, Oct 17, 2018 at 1:26 PM Richard Smith <rich at comodoca.com> wrote:

> Dates/time between freezing the version and publication can be debated.  I
> think this addresses the same problem as the alternate proposal in a better
> way.  CAs don’t have to try to keep track of arbitrary dates.  We will know
> well ahead of time what to expect and when to expect it.  It also makes
> life significantly easier for the maintainers of the documents and the web
> site administrators because they won’t have to push out new publications on
> an arbitrary and random basis.  I think this would solve a host of problems
> just like version control and development scheduling in software does.
>
>
>
> Regards,
>
> Rich
>
>
>
> *From:* Ryan Sleevi <sleevi at google.com>
> *Sent:* Wednesday, October 17, 2018 3:11 AM
> *To:* Richard Smith <rich at comodoca.com>; servercert-wg at cabforum.org
> *Subject:* Re: [Servercert-wg] Proposal to address ballot effective date
> problem
>
>
>
> Could you specifically explain the benefits you see for such a fixed
> schedule? It seems the only real element of the discussion today that this
> is addresses is that it allows for as little as two weeks from the adoption
> of a ballot to enforcement.
>
>
>
> It seems like the alternative proposal offered - to set a common fixed
> expectation - is more beneficial to the CAs and the auditors tasked with
> actually performing those assessments (as opposed to developing the
> criteria). That is, ballots that complete the IP review will be
> consistently brought into force 30 days later, unless there is a specific
> consideration mentioned in the ballot.
>
>
>
> I can't help but feel your proposal is optimizing for a different problem,
> one which wasn't discussed, and so I fear I may be missing what you believe
> the additional value compared to the other proposal.
>
>
>
> On Wed, Oct 17, 2018 at 3:01 AM Richard Smith via Servercert-wg <
> servercert-wg at cabforum.org> wrote:
>
> As discussed at the Shanghai F2F today, there is a lot of confusion around
> ballot effective date and the current procedure is difficult to follow.
>
>
>
> To fix the problem I propose that we move to a quarterly release schedule
> for both BR and EVG using the following method:
>
>    1. Dates of publication:
>
>
>    1. February 1: Will include ballots which complete IPR review between
>       October 16 and January 15
>       2. May 1: Ballots which complete IPR review between January 16 and
>       April 15
>       3. August 1: Ballots which complete IPR review between April 16 and
>       July 15
>       4. November 1: ballots which complete IPR review between July 16
>       and October 15
>
> Ballot effective date will be the date upon which the BR or EVG containing
> it is published unless otherwise specified in the ballot itself and voted
> upon accordingly.  We need to keep the ability to specify an alternate date
> in the ballot in order to address critical items more quickly if necessary
> and also to allow additional time for some items if that is deemed
> necessary.
>
>
>
> I also think this type of scheduled publication will help our associates
> at WebTrust and ETSI to track changes and get them incorporated into their
> audit criteria more smoothly.
>
>
>
> Regards,
>
> *Rich Smith*
>
> *Senior Compliance Manager*
>
> ComodoCA.com
>
>
>
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> http://cabforum.org/mailman/listinfo/servercert-wg
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20181017/9915fd8e/attachment.html>


More information about the Servercert-wg mailing list