<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
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.<br>
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.<br>
<br>
-Rich<br>
<br>
<div class="moz-cite-prefix">On 4/28/2016 3:23 PM, Ryan Sleevi
wrote:<br>
</div>
<blockquote
cite="mid:CACvaWvaMnpgrAGGEm7VVLM85TT+qKT1K9DKTsHz47irTucnC5A@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Thu, Apr 28, 2016 at 1:15 PM, Rich
Smith <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:richard.smith@comodo.com" target="_blank">richard.smith@comodo.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"> 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.</div>
</blockquote>
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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. </div>
</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>