[cabfpub] Pre-Ballot 164 - Certificate Serial Number Entropy

[Rich Smith]

I chose six months because 1) I think it's a reasonable timeframe for a 
non-critical update, and 2) if memory serves, a couple of CAs have in 
the past stated that that's about how long it takes in their 
organizations to get a non-critical update through their dev cycle.
Compliance with the BRs is arguably the top priority for a CA in regards 
to system development, however it is not the only priority. Other things 
do go on, and if we're making a change to the BRs that does not 
constitute a critical security update, then I don't think it's too much 
to ask to respect the fact that development teams do have other things 
they are working on and to give them time to address the new requirement 
without throwing a wrench into their normal dev cycle.

-Rich

On 4/28/2016 3:23 PM, Ryan Sleevi wrote:
>
>
> On Thu, Apr 28, 2016 at 1:15 PM, Rich Smith <richard.smith at comodo.com 
> <mailto:richard.smith at comodo.com>> wrote:
>
>     I do think this brings up a good point though.  This has come up
>     before under other ballots requiring code changes to CA core
>     systems.  I think that any change requiring such code changes
>     should have a minimum lead time of 6 months from passage of the
>     ballot before becoming mandatory, unless it is deemed to be a
>     security threat sufficient to require more immediate action. 
>     Admittedly I do not have the technical expertise to know if this
>     is such a case.
>
>
> Could you explain how you chose six months, as opposed to one month 
> (the time for legal review for Final Guidelines) or, say, three months?
>
> Our experience with responding to security threats, at Google, in 
> Chrome, and in conjunction with other vendors (such as through efforts 
> like Project Zero), is that, in the worst case, the ability to respond 
> to a security threat in a timely manner is directly related to the 
> ability to release and deploy new versions and products of code. That 
> is, even if we were to say that an incident is security related, and 
> thus perhaps requires 14 days to effect change, there will be some 
> portion of CAs who, through the structure of business operations and 
> third party engagements, will have difficulty responding to anything 
> outside of their contracted timeframe - such as the six months you 
> propose. By setting the expectation lower, such that it's clear what 
> the 'worst case' scenario may be, the overall security of the 
> ecosystem improves.
>
> That said, I would also argue it's difficult to quantify what 
> represents a change to CA core systems, because that varies largely 
> depending upon how the CA has structured their operations. Because 
> that's such a subjective measure, and one for which there is an 
> unfortunate long-tail of CAs who are unable to take any necessary 
> precautions in a timely fashion, setting that as the bar may be 
> disproportionately disadvantageous to security.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20160428/cbdde664/attachment.html