<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 30/3/2017 7:49 μμ, Ryan Sleevi
wrote:<br>
</div>
<blockquote
cite="mid:CACvaWvatFeZUvnv4L-M=ESoNtQLCUgkFTjos4scHqvzMbdi5RQ@mail.gmail.com"
type="cite">
<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>
</blockquote>
<br>
The intention is that it MUST NOT be permitted to directly sign a
id-kp-timeStamping certificate from such a Root. The reason behind
this is that only Roots that participate in a hierarchy that
eventually issues publicly trusted SSL certificates should have this
rule. Roots that participate in a hierarchy that does not issue SSL
end-entity certificates should not need to follow this rule. Could
you please offer some improvement language to make this clearer?<br>
<br>
<br>
Thanks,<br>
Dimitris.<br>
<br>
<blockquote
cite="mid:CACvaWvatFeZUvnv4L-M=ESoNtQLCUgkFTjos4scHqvzMbdi5RQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<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
moz-do-not-send="true"
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
moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
<a moz-do-not-send="true"
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>
</blockquote>
<br>
</body>
</html>