<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix"><br>
In light of recent developments related to the CA/B Forum IPR
policy process, I would like to suspend this ballot until these
issues are resolved.<br>
<br>
<br>
Best regards,<br>
Dimitris.<br>
<br>
On 30/9/2016 10:26 πμ, Dimitris Zacharopoulos wrote:<br>
</div>
<blockquote
cite="mid:91147d92-860f-a41e-bbbc-00bba5e69a5f@it.auth.gr"
type="cite">
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<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
moz-do-not-send="true" 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. <br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Public mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Public@cabforum.org">Public@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a>
</pre>
</blockquote>
<br>
</body>
</html>