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