<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>