<html>
  <head>
    <meta http-equiv="content-type" content="text/html; charset=utf-8">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p class="line874">Following the discussion around timestamping
      certificates and Root key usage, I prepared the following ballot.
      Looking for two endorsers.<br>
    </p>
    <p class="line874">Thank you,<br>
      Dimitris.<br>
      <br>
    </p>
    <p class="line874"><b>Background</b>: <span class="anchor"
        id="line-6"></span><span class="anchor" id="line-7"></span></p>
    <p class="line874">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="anchor" id="line-8"></span><span class="anchor"
        id="line-9"></span></p>
    <ol type="1">
      <li>that it affects Root Keys in a hierarchy that issues SSL
        Certificates and <span class="anchor" id="line-10"></span></li>
      <li>that it does not include time stamping certificates in the
        exception list. <span class="anchor" id="line-11"></span><span
          class="anchor" id="line-12"></span></li>
    </ol>
    <p class="line874">It also clears the exception language for
      1024-bit RSA Subscriber Certificates and testing products with
      Certificates issued by a Root. <span class="anchor" id="line-13"></span><span
        class="anchor" id="line-14"></span></p>
    <p class="line874"><b>-- MOTION BEGINS --</b> <span class="anchor"
        id="line-15"></span><span class="anchor" id="line-16"></span></p>
    <p class="line867"><i>Current section 6.1.7</i> <span
        class="anchor" id="line-17"></span><span class="anchor"
        id="line-18"></span></p>
    <p class="line874">Root CA Private Keys MUST NOT be used to sign
      Certificates except in the following cases: <span class="anchor"
        id="line-19"></span><span class="anchor" id="line-20"></span></p>
    <ol type="1">
      <li>Self-signed Certificates to represent the Root CA itself; <span
          class="anchor" id="line-21"></span></li>
      <li>Certificates for Subordinate CAs and Cross Certificates; <span
          class="anchor" id="line-22"></span></li>
      <li>Certificates for infrastructure purposes (e.g. administrative
        role certificates, internal CA operational device certificates,
        and OCSP Response verification Certificates); <span
          class="anchor" id="line-23"></span></li>
      <li>Certificates issued solely for the purpose of testing products
        with Certificates issued by a Root CA; and <span class="anchor"
          id="line-24"></span></li>
      <li>Subscriber Certificates, provided that: <span class="anchor"
          id="line-25"></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="anchor"
              id="line-26"></span></li>
          <li>The Applicant’s application was deployed prior to the
            Effective Date; <span class="anchor" id="line-27"></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="anchor"
              id="line-28"></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="anchor" id="line-29"></span></li>
          <li>The CA documents that the Applicant’s application cannot
            be patched or replaced without substantial economic outlay.
            <span class="anchor" id="line-30"></span></li>
          <li>The CA signs the Subscriber Certificate on or before June
            30, 2016; and <span class="anchor" id="line-31"></span></li>
          <li>The notBefore field in the Subscriber Certificate has a
            date on or before June 30, 2016 <span class="anchor"
              id="line-32"></span><span class="anchor" id="line-33"></span></li>
        </ol>
      </li>
    </ol>
    <p class="line867"><i>Proposed section 6.1.7</i> <span
        class="anchor" id="line-34"></span><span class="anchor"
        id="line-35"></span></p>
    <p class="line874">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="anchor" id="line-36"></span><span
        class="anchor" id="line-37"></span></p>
    <ol type="1">
      <li>Self-signed Certificates to represent the Root Certificate
        itself; <span class="anchor" id="line-38"></span></li>
      <li>Certificates for Subordinate CAs and Cross Certificates; <span
          class="anchor" id="line-39"></span></li>
      <li>Certificates for infrastructure purposes (administrative role
        certificates, internal CA operational device certificates) <span
          class="anchor" id="line-40"></span></li>
      <li>Certificates for OCSP Response verification; <span
          class="anchor" id="line-41"></span><span class="anchor"
          id="line-42"></span></li>
    </ol>
    <p class="line867"><i><strong>Note:</strong></i> After the Effective
      Date Feb 1st 2017, Certificates for Time Stamping Authorities
      SHALL NOT be directly issued from these Root Certificates. <span
        class="anchor" id="line-43"></span><span class="anchor"
        id="line-44"></span></p>
    <p class="line874"><b>-- MOTION ENDS -- </b><span class="anchor"
        id="line-45"></span><span class="anchor" id="line-46"></span></p>
    <p class="line874">The review period for this ballot shall commence
      at 2200 UTC on Tuesday October XX 2016, and will close at 2200 UTC
      on Tuesday October XX 2016. Unless the motion is withdrawn during
      the review period, the voting period will start immediately
      thereafter and will close at 2200 UTC on Tuesday October XX 2016.
      Votes must be cast by posting an on-list reply to this thread. <span
        class="anchor" id="line-47"></span><span class="anchor"
        id="line-48"></span></p>
    <p class="line862">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="https"
        href="https://cabforum.org/members/">https://cabforum.org/members/</a>
      <span class="anchor" id="line-49"></span><span class="anchor"
        id="line-50"></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 currently nine (9) members– at least nine members must
    participate in the ballot, either by voting in favor, voting
    against, or abstaining.
  </body>
</html>