<div dir="ltr">For an industry based on trust, 6 months to make changes seems an exceptionally long time, and you haven't really provided a justification for why that date over, say, 18 months, 3 months, or 3 days.<div><br></div><div>I totally understand and appreciate changes take time, but I still believe we need to take it on a case-by-case basis and default to sooner, with a willingness to discuss what's commercially reasonable or viable if some reason prevents it being made sooner.</div><div><br></div><div>For example, consider the practical implications of this - any CA that allows a subscriber to add and remove SANs from certs, whether as part of a managed PKI or as part of a product offering, is potentially in breach of this obligation if they don't force a mandatory rekey (and I suspect many don't, precisely because of the consumer hassle).</div><div><br></div><div>That is, if you have a cert for "<a href="http://a.example.com">a.example.com</a>" and "<a href="http://b.example.com">b.example.com</a>", and you remove "<a href="http://b.example.com">b.example.com</a>" from the cert, then according to this, the subscriber needs to request revocation (the information is "incorrect" or "inaccurate"), and needs to change keys.</div><div><br></div><div>Surely that's the kind of situation we'd rather fix sooner than later, right? So if we said 45 days - or even went for an even 60 - does that meet your needs?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 22, 2016 at 9:26 AM, Rich Smith <span dir="ltr"><<a 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've said in the past that I believe any non-critical change should
    have a 6 month lead time by default.  I stand by that statement and
    submit it again.  And yes, Ryan, that goes whether the change
    toughens or relaxes the requirements.  CAs are of course free and
    encouraged to bring themselves into compliance sooner if they are
    able to do so without turning their existing dev cycle on it's head,
    but I don't think 6 months is unreasonable for a non-critical change
    either way.<span class="HOEnZb"><font color="#888888"><br>
    <br>
    -Rich</font></span><div><div class="h5"><br>
    <br>
    <div class="m_7461708476670458621moz-cite-prefix">On 7/21/2016 11:02 PM, Ryan Sleevi
      wrote:<br>
    </div>
    <blockquote type="cite">
      <p dir="ltr">Dean,</p>
      <p dir="ltr">In the past, when CAs have had concerns, there's been
        a suggestion of a timeframe that might be reasonable to make
        changes.</p>
      <p dir="ltr">Is thirty days sufficient? Why or why not?</p>
      <p dir="ltr">When the proposed changes relax, rather than toughen,
        a requirement, do you share the same concerns?</p>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On Jul 21, 2016 7:32 PM, "Dean Coclin"
          <<a href="mailto:Dean_Coclin@symantec.com" target="_blank">Dean_Coclin@symantec.com</a>>
          wrote:<br type="attribution">
          <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Josh,<br>
            <br>
            This is not a criticism of this specific ballot; I have no
            comment on its merit. However, in reviewing several recent
            ballots, I think it's problematic to have a ballot state
            that it is effective as of the date of passage.<br>
            <br>
            If a CA has to make technical or policy changes, it's going
            to take some time to do so. If the ballot takes effect on
            the day of passage, then the CA has to make immediate
            changes, lest they be technically out of compliance as of
            that day.<br>
            <br>
            For example, this ballot will require CAs to make CPS
            changes. How are they supposed to do this in one day? Am I
            reading this correctly?<br>
            <br>
            Thanks,<br>
            Dean<br>
            <br>
            <br>
            <br>
            -----Original Message-----<br>
            From: <a href="mailto:public-bounces@cabforum.org" target="_blank">public-bounces@cabforum.org</a>
            [mailto:<a href="mailto:public-bounces@cabforum.org" target="_blank">public-bounces@cabforum.org</a>]
            On Behalf Of Josh Aas<br>
            Sent: Thursday, July 14, 2016 10:18 AM<br>
            To: CABFPub <<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>><br>
            Subject: [cabfpub] Ballot 173 - Removal of requirement to
            cease use of private key due to incorrect certificate info<br>
            <br>
            Ballot 173 - Removal of requirement to cease use of private
            key due to incorrect certificate info<br>
            <br>
            The following motion has been proposed by Josh Aas of ISRG /
            Let's Encrypt. Ben Wilson of Digicert and Chris Bailey of
            Entrust endorse.<br>
            <br>
            Background:<br>
            <br>
            BR Section 9.6.3 point 5 says:<br>
            <br>
            "Reporting and Revocation: An obligation and warranty to
            promptly cease using a Certificate and its associated
            Private Key, and promptly request the CA to revoke the
            Certificate, in the event that: (a) any information in the
            Certificate is, or becomes, incorrect or inaccurate, or (b)
            there is any actual or suspected misuse or compromise of the
            Subscriber’s Private Key associated with the Public Key
            included in the Certificate;"<br>
            <br>
            There is a problem here, which is that this requires a
            subscriber to stop using a private key just because
            information in a certificate is inaccurate or incorrect.
            People should stop using a cert with inaccurate or incorrect
            information, but they shouldn't be required to stop using a
            key pair unless there is known or suspected compromise.<br>
            <br>
            This is particularly problematic for HPKP.<br>
            <br>
            --Motion Begins--<br>
            <br>
            Effective upon the date of passage, the following
            modifications are made to the Baseline Requirements:<br>
            <br>
            Change the following text in Section 9.6.3:<br>
            =======================<br>
            Reporting and Revocation: An obligation and warranty to
            promptly cease using a Certificate and its associated
            Private Key, and promptly request the CA to revoke the
            Certificate, in the event that: (a) any information in the
            Certificate is, or becomes, incorrect or inaccurate, or (b)
            there is any actual or suspected misuse or compromise of the
            Subscriber’s Private Key associated with the Public Key
            included in the Certificate; =======================<br>
            <br>
            To:<br>
            =======================<br>
            Reporting and Revocation: An obligation and warranty to: (a)
            promptly request revocation of the Certificate, and cease
            using it and its associated Private Key, if there is any
            actual or suspected misuse or compromise of the Subscriber’s
            Private Key associated with the Public Key included in the
            Certificate; and (b) promptly request revocation of the
            Certificate, and cease using it, if any information in the
            Certificate is or becomes incorrect or inaccurate.<br>
            =======================<br>
            <br>
            --Motion Ends--<br>
            <br>
            The review period for this ballot shall commence at 2200 UTC
            on 14 July 2016, and will close at 2200 UTC on 21 July 2016.
            Unless the motion is withdrawn during the review period, the
            voting period will start immediately thereafter and will
            close at 2200 UTC on 28 July 2016. Votes must be cast by
            posting an on-list reply to this thread.<br>
            <br>
            A vote in favor of the motion must indicate a clear 'yes' in
            the response. A vote against must indicate a clear 'no' in
            the response. A vote to abstain must indicate a clear
            'abstain' in the response.<br>
            Unclear responses will not be counted. The latest vote
            received from any representative of a voting member before
            the close of the voting period will be counted. Voting
            members are listed here:<br>
            <a href="https://cabforum.org/members/" rel="noreferrer" target="_blank">https://cabforum.org/members/</a><br>
            <br>
            In order for the motion to be adopted, two thirds or more of
            the votes cast by members in the CA category and greater
            than 50% of the votes cast by members in the browser
            category must be in favor. Quorum is currently ten (10)
            members– at least ten members must participate in the
            ballot, either by voting in favor, voting against, or
            abstaining.<br>
            <br>
            --<br>
            Josh Aas<br>
            Executive Director<br>
            Internet Security Research Group<br>
            Let's Encrypt: A Free, Automated, and Open CA
            _______________________________________________<br>
            Public mailing list<br>
            <a href="mailto:Public@cabforum.org" target="_blank">Public@cabforum.org</a><br>
            <a href="https://cabforum.org/mailman/listinfo/public" rel="noreferrer" target="_blank">https://cabforum.org/mailman/listinfo/public</a><br>
            <br>
            _______________________________________________<br>
            Public mailing list<br>
            <a href="mailto:Public@cabforum.org" target="_blank">Public@cabforum.org</a><br>
            <a href="https://cabforum.org/mailman/listinfo/public" rel="noreferrer" target="_blank">https://cabforum.org/mailman/listinfo/public</a><br>
            <br>
          </blockquote>
        </div>
      </div>
      <br>
      <fieldset class="m_7461708476670458621mimeAttachmentHeader"></fieldset>
      <br>
      <pre>_______________________________________________
Public mailing list
<a class="m_7461708476670458621moz-txt-link-abbreviated" href="mailto:Public@cabforum.org" target="_blank">Public@cabforum.org</a>
<a class="m_7461708476670458621moz-txt-link-freetext" href="https://cabforum.org/mailman/listinfo/public" target="_blank">https://cabforum.org/mailman/listinfo/public</a>
</pre>
    </blockquote>
    <br>
  </div></div></div>

<br>_______________________________________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
<a href="https://cabforum.org/mailman/listinfo/public" rel="noreferrer" target="_blank">https://cabforum.org/mailman/listinfo/public</a><br>
<br></blockquote></div><br></div>