<div dir="ltr">Dimitris,<div><br></div><div>I'm unclear on your goals with #2, despite having participated in the thread.</div><div><br></div><div>For example, despite being very familiar with this topic, I must admit, I'm confused as to what "participate in a hierarchy that issues Certificates with an extKeyUsage" means.</div><div><br></div><div>There's at least two possible readings:</div><div>1) From the root, through the intermediates, etc, a certificate is issued with id-kp-serverAuth. This is the "flow upward" approach, where *if* it's possible to issue such a certificate, this applies</div><div>2) It only applies if the root directly issues such a certificate</div><div><br></div><div>There's problems with both interpretations, however</div><div>1) As worded, it could be seen as 'not applying' if the server doesn't _issue_ such a certificate, but is technically capable of doing so.</div><div>  That is, consider a root with an anyEKU, an intermediate with an anyEKU, and a leaf with id-kp-timeStamping. As worded, this would be seen as "out of scope", while under the existing language, it would be clearly in scope, which is the desired outcome</div><div>2) would be seriously under-scoped, since we know it's rare for such intermediates to exist<br></div><div><br></div><div><br></div><div>Could you clarify a bit more on the timestamping concern here? The root MUST NOT sign an id-kp-timeStamping certificate directly, as worded, but it's unclear if you think that's incorrect and should be permitted.</div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 30, 2017 at 12:22 PM, Dimitris Zacharopoulos via Public <span dir="ltr"><<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  

    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <br>
    <div class="m_2205845482060338340moz-forward-container"><strong>Ballot 189 - Amend
        Section 6.1.7 of Baseline Requirements</strong> <span class="m_2205845482060338340anchor" id="m_2205845482060338340line-3"></span><span class="m_2205845482060338340anchor" id="m_2205845482060338340line-4"></span>
      <p class="m_2205845482060338340line874">The following motion has been proposed by
        Dimitris Zacharopoulos of HARICA and endorsed by Bruce Morton of
        Entrust and Jeremy Rowley of Digicert <span class="m_2205845482060338340anchor" id="m_2205845482060338340line-5"></span><span class="m_2205845482060338340anchor" id="m_2205845482060338340line-6"></span></p>
      <p class="m_2205845482060338340line867"><strong>Background</strong>: <span class="m_2205845482060338340anchor" id="m_2205845482060338340line-7"></span><span class="m_2205845482060338340anchor" id="m_2205845482060338340line-8"></span></p>
      <p class="m_2205845482060338340line874">Section 6.1.7 of the Baseline Requirements
        states that the Root CA Private Keys MUST NOT be used to sign
        end-entity certificates, with some exceptions. It is unclear if
        this exception list includes end-entity certificates with EKU
        id-kp-timeStamping. This ballot attempts to clarify two things:
        <span class="m_2205845482060338340anchor" id="m_2205845482060338340line-9"></span><span class="m_2205845482060338340anchor" id="m_2205845482060338340line-10"></span></p>
      <ol type="1">
        <li>that it affects Root Keys in a hierarchy that issues SSL
          Certificates and <span class="m_2205845482060338340anchor" id="m_2205845482060338340line-11"></span></li>
        <li>that it does not include time stamping certificates in the
          exception list. <span class="m_2205845482060338340anchor" id="m_2205845482060338340line-12"></span><span class="m_2205845482060338340anchor" id="m_2205845482060338340line-13"></span></li>
      </ol>
      <p class="m_2205845482060338340line874">It also clears the exception language for
        1024-bit RSA Subscriber Certificates and testing products with
        Certificates issued by a Root. <span class="m_2205845482060338340anchor" id="m_2205845482060338340line-14"></span><span class="m_2205845482060338340anchor" id="m_2205845482060338340line-15"></span></p>
      <p class="m_2205845482060338340line867"><strong>-- MOTION BEGINS --</strong> <span class="m_2205845482060338340anchor" id="m_2205845482060338340line-16"></span><span class="m_2205845482060338340anchor" id="m_2205845482060338340line-17"></span></p>
      <p class="m_2205845482060338340line867"><em>Current section 6.1.7</em> <span class="m_2205845482060338340anchor" id="m_2205845482060338340line-18"></span><span class="m_2205845482060338340anchor" id="m_2205845482060338340line-19"></span></p>
      <p class="m_2205845482060338340line874">Root CA Private Keys MUST NOT be used to sign
        Certificates except in the following cases: <span class="m_2205845482060338340anchor" id="m_2205845482060338340line-20"></span><span class="m_2205845482060338340anchor" id="m_2205845482060338340line-21"></span></p>
      <ol type="1">
        <li>Self-signed Certificates to represent the Root Certificate
          itself; <span class="m_2205845482060338340anchor" id="m_2205845482060338340line-22"></span></li>
        <li>Certificates for Subordinate CAs and Cross Certificates; <span class="m_2205845482060338340anchor" id="m_2205845482060338340line-23"></span></li>
        <li>Certificates for infrastructure purposes (e.g.
          administrative role certificates, internal CA operational
          device certificates, and OCSP Response verification
          Certificates); <span class="m_2205845482060338340anchor" id="m_2205845482060338340line-24"></span></li>
        <li>Certificates issued solely for the purpose of testing
          products with Certificates issued by a Root CA; and <span class="m_2205845482060338340anchor" id="m_2205845482060338340line-25"></span></li>
        <li>Subscriber Certificates, provided that: <span class="m_2205845482060338340anchor" id="m_2205845482060338340line-26"></span>
          <ol type="a">
            <li>The Root CA uses a 1024-bit RSA signing key that was
              created prior to the Effective Date; <span class="m_2205845482060338340anchor" id="m_2205845482060338340line-27"></span></li>
            <li>The Applicant’s application was deployed prior to the
              Effective Date; <span class="m_2205845482060338340anchor" id="m_2205845482060338340line-28"></span></li>
            <li>The Applicant’s application is in active use by the
              Applicant or the CA uses a documented process to establish
              that the Certificate’s use is required by a substantial
              number of Relying Parties; <span class="m_2205845482060338340anchor" id="m_2205845482060338340line-29"></span></li>
            <li>The CA follows a documented process to determine that
              the Applicant’s application poses no known security risks
              to Relying Parties; <span class="m_2205845482060338340anchor" id="m_2205845482060338340line-30"></span></li>
            <li>The CA documents that the Applicant’s application cannot
              be patched or replaced without substantial economic
              outlay. <span class="m_2205845482060338340anchor" id="m_2205845482060338340line-31"></span></li>
            <li>The CA signs the Subscriber Certificate on or before
              June 30, 2016; and <span class="m_2205845482060338340anchor" id="m_2205845482060338340line-32"></span></li>
            <li>The notBefore field in the Subscriber Certificate has a
              date on or before June 30, 2016 <span class="m_2205845482060338340anchor" id="m_2205845482060338340line-33"></span><span class="m_2205845482060338340anchor" id="m_2205845482060338340line-34"></span></li>
          </ol>
        </li>
      </ol>
      <p class="m_2205845482060338340line867"><em>Proposed section 6.1.7</em> <span class="m_2205845482060338340anchor" id="m_2205845482060338340line-35"></span><span class="m_2205845482060338340anchor" id="m_2205845482060338340line-36"></span></p>
      <p class="m_2205845482060338340line874">Private Keys corresponding to Root Certificates
        that participate in a hierarchy that issues Certificates with an
        extKeyUsage extension that includes the value id-kp-serverAuth
        [RFC5280] MUST NOT be used to sign Certificates except in the
        following cases: <span class="m_2205845482060338340anchor" id="m_2205845482060338340line-37"></span><span class="m_2205845482060338340anchor" id="m_2205845482060338340line-38"></span></p>
      <ol type="1">
        <li>Self-signed Certificates to represent the Root CA itself; <span class="m_2205845482060338340anchor" id="m_2205845482060338340line-39"></span></li>
        <li>Certificates for Subordinate CAs and Cross Certificates; <span class="m_2205845482060338340anchor" id="m_2205845482060338340line-40"></span></li>
        <li>Certificates for infrastructure purposes (administrative
          role certificates, internal CA operational device
          certificates) <span class="m_2205845482060338340anchor" id="m_2205845482060338340line-41"></span></li>
        <li>Certificates for OCSP Response verification; <span class="m_2205845482060338340anchor" id="m_2205845482060338340line-42"></span><span class="m_2205845482060338340anchor" id="m_2205845482060338340line-43"></span></li>
      </ol>
      <p class="m_2205845482060338340line867"><strong>These changes become Effective 30 days
          after the ballot passes.</strong> <span class="m_2205845482060338340anchor" id="m_2205845482060338340line-44"></span><span class="m_2205845482060338340anchor" id="m_2205845482060338340line-45"></span></p>
      <p class="m_2205845482060338340line867"><strong>-- MOTION ENDS --</strong> <span class="m_2205845482060338340anchor" id="m_2205845482060338340line-46"></span><span class="m_2205845482060338340anchor" id="m_2205845482060338340line-47"></span></p>
      <p class="m_2205845482060338340line874">The procedure for this ballot is as follows
        (exact start and end times may be adjusted to comply with
        applicable Bylaws and IPR Agreement): <span class="m_2205845482060338340anchor" id="m_2205845482060338340line-48"></span><span class="m_2205845482060338340anchor" id="m_2205845482060338340line-49"></span></p>
      <div>
        <table>
          <tbody>
            <tr>
              <td style="background-color:#e0e0ff">
                <p class="m_2205845482060338340line862">BALLOT 189 Status: Amend BR 6.1.7 </p>
              </td>
              <td colspan="2" style="background-color:#e0e0ff;text-align:center">
                <p class="m_2205845482060338340line862"> Start time (22:00 UTC) </p>
              </td>
              <td colspan="2" style="background-color:#e0e0ff;text-align:center">
                <p class="m_2205845482060338340line862"> End time (22:00 UTC) </p>
              </td>
            </tr>
            <tr>
              <td><span class="m_2205845482060338340anchor" id="m_2205845482060338340line-50"></span>
                <p class="m_2205845482060338340line862"> Discussion (7 days) </p>
              </td>
              <td colspan="2" style="text-align:center">
                <p class="m_2205845482060338340line862"> 30 March 2017 </p>
              </td>
              <td colspan="2" style="text-align:center">
                <p class="m_2205845482060338340line862"> 6 April 2017 </p>
              </td>
            </tr>
            <tr>
              <td><span class="m_2205845482060338340anchor" id="m_2205845482060338340line-51"></span>
                <p class="m_2205845482060338340line862"> Vote for approval (7 days) </p>
              </td>
              <td colspan="2" style="text-align:center">
                <p class="m_2205845482060338340line862"> 6 April 2017 </p>
              </td>
              <td colspan="2" style="text-align:center">
                <p class="m_2205845482060338340line862"> 13 April 2017 </p>
              </td>
            </tr>
            <tr>
              <td style="text-align:left"><span class="m_2205845482060338340anchor" id="m_2205845482060338340line-52"></span>
                <p class="m_2205845482060338340line862">If vote approves ballot: Review
                  Period (Chair to send Review Notice) (30 days)<br>
                  If Exclusion Notice(s) filed, ballot approval is
                  rescinded and PAG to be created.<br>
                  If no Exclusion Notices filed, ballot becomes
                  effective at end of Review Period.<br>
                  Votes must be cast by posting an on-list reply to this
                  thread on the Public Mail List.</p>
              </td>
              <td colspan="2" style="text-align:center">
                <p class="m_2205845482060338340line862">Upon filing of Review Notice by Chair</p>
              </td>
              <td colspan="2" style="text-align:center">
                <p class="m_2205845482060338340line862">30 days after filing of Review Notice
                  by Chair</p>
              </td>
            </tr>
          </tbody>
        </table>
      </div>
      <span class="m_2205845482060338340anchor" id="m_2205845482060338340line-53"></span><span class="m_2205845482060338340anchor" id="m_2205845482060338340line-54"></span>
      <p class="m_2205845482060338340line874">From Bylaw 2.3: If the Draft Guideline Ballot
        is proposing a Final Maintenance Guideline, such ballot will
        include a redline or comparison showing the set of changes from
        the Final Guideline section(s) intended to become a Final
        Maintenance Guideline, and need not include a copy of the full
        set of guidelines. Such redline or comparison shall be made
        against the Final Guideline section(s) as they exist at the time
        a ballot is proposed, and need not take into consideration other
        ballots that may be proposed subsequently, except as provided in
        Bylaw Section 2.3(j). <span class="m_2205845482060338340anchor" id="m_2205845482060338340line-55"></span><span class="m_2205845482060338340anchor" id="m_2205845482060338340line-56"></span></p>
      <p class="m_2205845482060338340line862">Votes must be cast by posting an on-list reply
        to this thread on the Public list. 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. 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: <a class="m_2205845482060338340https" href="https://cabforum.org/members/" target="_blank">https://cabforum.org/members/</a>
        <span class="m_2205845482060338340anchor" id="m_2205845482060338340line-57"></span><span class="m_2205845482060338340anchor" id="m_2205845482060338340line-58"></span></p>
      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 shown on CA/Browser Forum wiki. Under Bylaw
      2.2(g), at least the required quorum number must participate in
      the ballot for the ballot to be valid, either by voting in favor,
      voting against, or abstaining. <br>
    </div>
  </div>

<br>______________________________<wbr>_________________<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/<wbr>listinfo/public</a><br>
<br></blockquote></div><br></div></div></div>