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

[Tim Hollebeek]

I do indeed have the concerns you mentioned about batching, especially with regards to permissive ballots (and clarifications).

 

I would hope the rules would take that into account, for example, by allowing compliance as early as the effective date, and mandating compliance by the next scheduled publication date.  This would automatically create a transition period for each ballot, without having to explicitly encode it.  The length of the transition would vary, but I think that could be managed.

 

Operationalizing that, if it turns out to be the direction we want to go, might be hard.

 

I tend to think that a simpler solution along the lines we discussed, like a X day window after effective date to comply, is better.  And easier to put into effect in the short term.  Though scheduled updates are attractive, longer term, if we can figure them out.

 

Another advantage to scheduled updates is that it is easier to automatically avoid holidays, blackout periods, and so on.  That’s an issue that we’ve had several times before, for example, I remember discussing it with you extensively in Bilbao.

 

-Tim

 

From: Ryan Sleevi <sleevi at google.com> 
Sent: Wednesday, October 17, 2018 9:42 PM
To: Tim Hollebeek <tim.hollebeek at digicert.com>
Cc: servercert-wg at cabforum.org; Bruce Morton <Bruce.Morton at entrustdatacard.com>
Subject: Re: [Servercert-wg] [EXTERNAL]Re: Proposal to address ballot effective date problem

 

 

On Wed, Oct 17, 2018 at 9:26 PM Tim Hollebeek <tim.hollebeek at digicert.com <mailto:tim.hollebeek at digicert.com> > wrote:

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.

 

I don't think it's fair to say it's 2 data points - as discussed, it's actually multiple ballots. It's also been a year of activity where we have been sensitive and attentive to the concerns. If the statement is that we should look at how bad a problem it was five years ago, then I hope such advocates will actually do the analysis and report back about which ballots caused trouble. I think we should also be mindful of the fact that the Forum has changed. Much in the same way I'm sure CAs would not want to be dismissed as "actively misissuing" when they had an incident five years ago, revised their CPS, and haven't demonstrated the problem since, I think it's reasonable to examine the historic context, while also being mindful that members have been more actively sensitive to these issues in the years since CAs remarked.

 

So I suppose concretely: Can you provide data that you believe demonstrates the concern? We can then look at both how the Forum practices have changed, as well as better understand why the concern. Given the flexibility afforded by the current process, and the clear demonstration that in the past year, it hasn't been significantly painful when browsers have been proposing changes.

 

I would have thought CAs would be more actively concerned with such proposals as batching. As the data for the past year shows, the majority of the ballots have been offering CAs more flexibility, not less. Having to wait 3 or more months to take advantage of that flexibility - or risking a qualified audit - doesn't seem in CAs interests either.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20181018/29d73269/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/29d73269/attachment-0001.p7s>