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

Wed Oct 17 17:53:50 MST 2018

It’s also worth pointing out that this has been a _very_ anomalous year for ballots, because of the governance reform transition, and various bylaw controversies that caused the work of the forum to come to a screeching halt on several occasions.

-Tim

From: Servercert-wg <servercert-wg-bounces at cabforum.org> On Behalf Of Bruce Morton via Servercert-wg
Sent: Wednesday, October 17, 2018 8:32 PM
To: Ryan Sleevi <sleevi at google.com>; CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>; Rich Smith <rich at comodoca.com>
Subject: Re: [Servercert-wg] [EXTERNAL]Re: Proposal to address ballot effective date problem

SC3 and SC6, both provided new policies to the CAs with no future effective date.

Bruce.

From: Servercert-wg [mailto:servercert-wg-bounces at cabforum.org] On Behalf Of Ryan Sleevi via Servercert-wg
Sent: October 17, 2018 8:00 PM
To: Rich Smith <rich at comodoca.com <mailto:rich at comodoca.com> >
Cc: servercert-wg at cabforum.org <mailto:servercert-wg at cabforum.org> 
Subject: [EXTERNAL]Re: [Servercert-wg] Proposal to address ballot effective date problem

WARNING: This email originated outside of Entrust Datacard.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.

  _____  

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 <mailto: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 <mailto:sleevi at google.com> > 
Sent: Wednesday, October 17, 2018 3:11 AM
To: Richard Smith <rich at comodoca.com <mailto:rich at comodoca.com> >; servercert-wg at cabforum.org <mailto: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 <mailto: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:

a.	February 1: Will include ballots which complete IPR review between October 16 and January 15
b.	May 1: Ballots which complete IPR review between January 16 and April 15 
c.	August 1: Ballots which complete IPR review between April 16 and July 15
d.	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 <mailto: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/20181018/f0c3321f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4940 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20181018/f0c3321f/attachment-0001.p7s>