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

Wed Oct 17 18:26:30 MST 2018

You were dismissive of the observation that this year was an odd year for ballots.  Despite the fact that the observation is correct.

I would encourage using a larger, more significant dataset.  Reasoning about what our procedures should be going forward based on two datapoints is not a good strategy.

Three to five years seems like a reasonable balance between preferring modern history and having a significant sample.

-Tim

From: Servercert-wg <servercert-wg-bounces at cabforum.org> On Behalf Of Ryan Sleevi via Servercert-wg
Sent: Wednesday, October 17, 2018 9:16 PM
To: Bruce Morton <Bruce.Morton at entrustdatacard.com>
Cc: servercert-wg at cabforum.org
Subject: Re: [Servercert-wg] [EXTERNAL]Re: Proposal to address ballot effective date problem

Thanks Bruce! I think this is a very helpful analysis, much more than simply saying "Last year was different" without actually doing the analysis or report.

I think it's worth mentioning that SC6 relaxed the process controls, but it did introduce a new disclosure requirement to the CP/CPS. However, it's also worth mentioning that this disclosure requirement already existed in the BRs, the only change was harmonizing the section. Do you think that requiring a CA move existing documentation from one section to another represented a significant risk and/or a need for an effective date?

As for SC3, that touched the Network Security, and you're correct that this was a material change. It's interesting to note that the ballot proposer and author is one of the folks raising the concern about a lack of effective dates - I'm not sure how to square the complaint when it is somewhat a self-inflicted thing. That's part of why I question the significance and impact - it sounds like CAs concerned can make an effort to highlight these concerns during the balloting and drafting stage, and that might simply be sufficient for the problem as stated?

I think this is a productive discussion of the substance of concerns, and helps us better evaluated proposed solutions against the problems they solve. I'm not trying to dismiss the concerns - but am trying to make sure we've better documented the concerns.

On Wed, Oct 17, 2018 at 8:32 PM Bruce Morton <Bruce.Morton at entrustdatacard.com <mailto:Bruce.Morton at entrustdatacard.com> > wrote:

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 <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/6c9715f3/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/6c9715f3/attachment-0001.p7s>