<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body 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.<br>
    <br>
    -Rich<br>
    <br>
    <div class="moz-cite-prefix">On 4/28/2016 11:07 AM, Ryan Sleevi
      wrote:<br>
    </div>
    <blockquote
cite="mid:CACvaWvYkWs6rJdxJ=n1H8gN86uVT-nV9HBOBfonUkhRS3CB0Lg@mail.gmail.com"
      type="cite">
      <div dir="ltr"><br>
        <div class="gmail_extra"><br>
          <div class="gmail_quote">On Thu, Apr 28, 2016 at 5:16 AM,
            Eneli Kirme <span dir="ltr"><<a moz-do-not-send="true"
                href="mailto:Eneli.Kirme@sk.ee">Eneli.Kirme@sk.ee</a>></span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
              <div style="word-wrap:break-word">
                Hi, 
                <div><br>
                </div>
                <div>The current requirement was part of root program
                  conditions already before first version of BR-s were
                  published and could be taken as a requirement while
                  developing or purchasing the CA software. </div>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>Actually, at the time the BRs were published, the
              requirement was 64 bits. The BRs were looser (to 20 bits)
              than what Microsoft was requiring.</div>
            <div> </div>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
              <div style="word-wrap:break-word">
                <div>As the vendor claimed compliance, we believe to be
                  compliant.<br>
                  Changing to 64 bits may or may not make a difference -
                  we have to check with the vendor. Adding some other
                  restrictions on the types of acceptable RNGs is
                  another change in requirements that may or may not
                  make a difference.<br>
                  We also have to check with the auditors about what
                  evidence they would like to see to believe that long
                  enough seemingly random number comes from an
                  acceptable source.<br>
                  <br>
                  But the question is more general - to which level you
                  expect a CA to have control over the software it is
                  using and to which level auditors should have access
                  to it? </div>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>The expectation is that all CAs will be following the
              latest-published BRs, per Section 2.2 of the BRs,
              specifically:</div>
            <div><br>
            </div>
            <div>[Name of CA] conforms to the current version of the
              Baseline Requirements for the Issuance and Management of
              Publicly‐Trusted Certificates published at <a
                moz-do-not-send="true" href="http://www.cabforum.org">http://www.cabforum.org</a>.
              In the event of any inconsistency between this document
              and those Requirements, those Requirements take precedence
              over this document. <br>
            </div>
            <div><br>
            </div>
            <div>To the extent a given CA has concerns about the BRs,
              such as the timing of the deployment of updated software,
              that's useful information to bring forward during the
              discussion of the proposed changes, and may inform the
              voting on the ballot. But once a ballot has passed, the
              expectation is that the CA will adopt it operationally
              "immediately", even if the audit criteria for it is
              developed, and the audit expectation of compliance is not
              enforced until the audit criteria are adopted.</div>
            <div><br>
            </div>
            <div>This was discussed during the Scottsdale F2F as
              understanding when ballots come into effect - when the
              consensus about the understanding that the above clause
              represents an expectation to adopt immediately. That
              naturally follows that CAs should be prepared to adopt the
              Ballots as they're published, or their effective date, or
              to understand what challenges might exist to prevent that.</div>
            <div><br>
            </div>
            <div>That said, if there's concern about timing, arguably
              it's useful to know concretely what the timing is. </div>
          </div>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Public mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Public@cabforum.org">Public@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>