<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p class="line867">Trying to fix formatting issues. Let's hope this
goes through correctly.<br>
Dimitris.<br>
<strong></strong></p>
<p class="line867"><strong>Ballot 188 - Clarify use of term "CA" in
Baseline Requirements</strong> <span class="anchor" id="line-2"></span><span
class="anchor" id="line-3"></span></p>
<p class="line874">The following motion has been proposed by
Dimitris Zacharopoulos of HARICA and endorsed by Ben Wilson of
Digicert and Tim Hollebeek of Trustwave. <span class="anchor"
id="line-4"></span><span class="anchor" id="line-5"></span></p>
<p class="line867"><strong>Background</strong>: <span
class="anchor" id="line-6"></span><span class="anchor"
id="line-7"></span></p>
<p class="line874">The Policy Review Working Group has completed its
review of the Baseline Requirements for purposes of clarifying use
of the term "CA" and related terminology. The term "CA" is used in
the Baseline Requirements and other documents to refer to "CA" as
an organization or "CA" as a CA Certificate. The Policy Review WG
decided to update the Baseline Requirements first, and then update
the EV Guidelines and other documents so that the updated terms
are used consistently in all CA/B Forum documents. <span
class="anchor" id="line-8"></span><span class="anchor"
id="line-9"></span></p>
<p class="line874">One of the proposed changes is not related to
"CA" terminology. That proposed change is in Section 4.9.10. Also,
in section 6.1.7, some legacy language related to 1024-bit RSA
usage from Root CA, was removed. <span class="anchor"
id="line-10"></span><span class="anchor" id="line-11"></span></p>
<p class="line874">Some incorrect references (pointing to Section
3.3.1 instead of 4.2.1) are corrected in Sections 3.2.2.4 and
4.1.2 <span class="anchor" id="line-12"></span><span
class="anchor" id="line-13"></span></p>
<p class="line874">In accordance with the Bylaws, a PDF with
redlines to the Baseline Requirements as they currently exist is
attached to assist your review. <span class="anchor" id="line-14"></span><span
class="anchor" id="line-15"></span><span class="anchor"
id="line-16"></span></p>
<p class="line867"><strong>-- MOTION BEGINS --</strong> <span
class="anchor" id="line-17"></span><span class="anchor"
id="line-18"></span></p>
<p class="line867">
</p>
<h3 id="In_Section_1.1_.28Overview.29">In Section 1.1 (Overview)</h3>
<span class="anchor" id="line-19"></span>
<ul>
<li>Delete the last sentence of section 1.1, which reads, "These
Requirements are applicable to all Certification Authorities
within a chain of trust. They are to be flowed down from the
Root Certification Authority through successive Subordinate
Certification Authorities." <span class="anchor" id="line-20"></span></li>
<li>Insert as the last sentence of section 1.1 the following:
"These requirements are applicable to all CAs that can issue a
Certificate that appears in a particular certificate chain from
a Root Certificate that is publicly trusted. They are to be
flowed down from a Root Certificate through successive
Subordinate CA Certificates." <span class="anchor" id="line-21"></span><span
class="anchor" id="line-22"></span></li>
</ul>
<p class="line867">
</p>
<h3 id="In_Section_1.6.1_.28Definitions.29">In Section 1.6.1
(Definitions)</h3>
<span class="anchor" id="line-23"></span>
<ul>
<li>Insert a new definition for "CA Certificate" as: "A
Certificate in which the basicConstraints field has the cA
attribute set to TRUE." <span class="anchor" id="line-24"></span></li>
<li>Replace the definition of "Certificate Revocation List" with:
"A regularly updated time-stamped list of revoked Certificates
that is created and digitally signed by the Private Key
associated with the Root CA Certificate or Subordinate CA
Certificate that issued the revoked Certificates." <span
class="anchor" id="line-25"></span></li>
<li>Replace the definition of "Certification Authority" with: "An
organization that is responsible for the creation, issuance,
revocation, and management of Certificates. The term applies
equally to Root CA Operators and Subordinate CA Operators." <span
class="anchor" id="line-26"></span></li>
<li>Replace the definition of "Cross Certificate" with: "A CA
Certificate that is used to establish a trust relationship
between two Root CA Certificates." <span class="anchor"
id="line-27"></span></li>
<li>Insert a new definition for "Externally Operated Subordinate
CA" as: "A third party Subordinate CA Operator, not the Root CA
Operator or its Affiliate, that is in possession or control of
the Private Key associated with the Subordinate CA Certificate."
<span class="anchor" id="line-28"></span></li>
<li>Insert a new definition for "Internally Operated Subordinate
CA" as: "A Subordinate CA Operator, operated by a Root CA
Operator or its Affiliate, that is in possession or control of
the Private Key associated with the Subordinate CA Certificate."
<span class="anchor" id="line-29"></span></li>
<li>Replace the definition of "Issuing CA" with: "The Root CA
Operator or the Subordinate CA Operator that is in possession or
control of the Private Key of the "Issuer" named in a particular
Certificate." <span class="anchor" id="line-30"></span></li>
<li>Replace the definition of "Key Generation Script" with: "A
documented plan of procedures for the generation of the Key Pair
to be associated with a CA Certificate." <span class="anchor"
id="line-31"></span></li>
<li>Replace the definition of "OCSP Responder" with: "A system
that provides Online Certificate Status Protocol responses. See
also, Online Certificate Status Protocol." <span class="anchor"
id="line-32"></span></li>
<li>Replace the definition of "Root CA" with a new definition for
"Root CA Operator" as: "The top-level Certification Authority
(i.e. an organization) whose CA Certificate (or associated
Public Key) is distributed by Application Software Suppliers as
a trust anchor." <span class="anchor" id="line-33"></span></li>
<li>Replace the defined term "Root Certificate" with "Root CA
Certificate" and replace the definition with: "A CA Certificate
in which the Public Key has been digitally signed by its
corresponding Private Key." <span class="anchor" id="line-34"></span></li>
<li>Insert a new definition for "Subordinate CA Operator" as "A
Certification Authority in possession or control of the Private
Key associated with a Subordinate CA Certificate. A Subordinate
CA Operator is either an Externally Operated Subordinate CA or
an Internally Operated Subordinate CA." <span class="anchor"
id="line-35"></span></li>
<li>Replace the definition for "Subordinate CA" with "Subordinate
CA Certificate" as: "A CA Certificate that has been signed by
the Private Key associated with a Root CA Certificate or a
different Subordinate CA Certificate." <span class="anchor"
id="line-36"></span></li>
<li>Replace the definition of "Technically Constrained Subordinate
CA Certificate" with: "A Subordinate CA Certificate which uses a
combination of Extended Key Usage settings and Name Constraint
settings to limit the scope within which the Subordinate CA
Certificate may issue Subscriber or additional Subordinate CA
Certificates." <span class="anchor" id="line-37"></span><span
class="anchor" id="line-38"></span></li>
</ul>
<p class="line867">
</p>
<h3 id="In_Section_1.6.2_.28Acronyms.29">In Section 1.6.2 (Acronyms)</h3>
<span class="anchor" id="line-39"></span>
<ul>
<li>
<p class="line862">Insert a new acronym EKU --> "Extended Key
Usage" <span class="anchor" id="line-40"></span><span
class="anchor" id="line-41"></span></p>
</li>
</ul>
<p class="line867">
</p>
<h3
id="In_Section_3.2.2.4_.28Validation_of_Domain_Authorization_or_Control.29">In
Section 3.2.2.4 (Validation of Domain Authorization or Control)</h3>
<span class="anchor" id="line-42"></span>
<ul>
<li>In the third paragraph, replace "Section 3.3.1" with "Section
4.2.1". <span class="anchor" id="line-43"></span><span
class="anchor" id="line-44"></span></li>
</ul>
<p class="line867">
</p>
<h3 id="In_Section_3.2.2.4.6_.28Agreed-Upon_Change_to_Website.29">In
Section 3.2.2.4.6 (Agreed-Upon Change to Website)</h3>
<span class="anchor" id="line-45"></span>
<ul>
<li>In the 2nd paragraph, replace "Section 3.3.1 of these
Guidelines" with "Section 4.2.1 of this document". <span
class="anchor" id="line-46"></span><span class="anchor"
id="line-47"></span></li>
</ul>
<p class="line867">
</p>
<h3
id="In_Section_4.1.2_.28Enrollment_Process_and_Responsibilities.29">In
Section 4.1.2 (Enrollment Process and Responsibilities)</h3>
<span class="anchor" id="line-48"></span>
<ul>
<li>In the 3rd paragraph, replace "Section 3.3.1" with "Section
4.2.1". <span class="anchor" id="line-49"></span><span
class="anchor" id="line-50"></span></li>
</ul>
<p class="line867">
</p>
<h3
id="In_Section_4.9.1.1_.28Reasons_for_Revoking_a_Subscriber_Certificate.29">In
Section 4.9.1.1 (Reasons for Revoking a Subscriber Certificate)</h3>
<span class="anchor" id="line-51"></span>
<ul>
<li>Replace subsection 13 with: "The CA is made aware of a
possible compromise of the Private Key that signed the
Certificate". <span class="anchor" id="line-52"></span><span
class="anchor" id="line-53"></span></li>
</ul>
<p class="line867">
</p>
<h3
id="In_Section_4.9.1.2_.28Reasons_for_Revoking_a_Subordinate_CA_Certificate.29">In
Section 4.9.1.2 (Reasons for Revoking a Subordinate CA
Certificate)</h3>
<span class="anchor" id="line-54"></span>
<p class="line874">Replace with: <span class="anchor" id="line-55"></span><span
class="anchor" id="line-56"></span></p>
<p class="line874">The Issuing CA SHALL revoke a Subordinate CA
Certificate within seven (7) days if one or more of the following
occurs: <span class="anchor" id="line-57"></span><span
class="anchor" id="line-58"></span></p>
<ol type="1">
<li>The Externally Operated Subordinate CA requests revocation in
writing; <span class="anchor" id="line-59"></span></li>
<li>The Externally Operated Subordinate CA notifies the Issuing CA
that the original certificate request was not authorized and
does not retroactively grant authorization; <span
class="anchor" id="line-60"></span></li>
<li>The Issuing CA obtains evidence that the Private Key
corresponding to the Public Key in the Subordinate CA
Certificate suffered a Key Compromise or no longer complies with
the requirements of Sections 6.1.5 and 6.1.6; <span
class="anchor" id="line-61"></span></li>
<li>The Issuing CA obtains evidence that the Private Key
corresponding to the Public Key in the Subordinate CA
Certificate was misused; <span class="anchor" id="line-62"></span></li>
<li>The Issuing CA is made aware that the Subordinate CA
Certificate was not issued in accordance with, or that the
Externally Operated Subordinate CA has not complied with these
Requirements or the applicable Certificate Policy or
Certification Practice Statement; <span class="anchor"
id="line-63"></span></li>
<li>The Issuing CA determines that any of the information
appearing in the Subordinate CA Certificate is inaccurate or
misleading; <span class="anchor" id="line-64"></span></li>
<li>The Issuing CA or the Subordinate CA ceases operations for any
reason and has not made arrangements for another CA to provide
revocation support for the Subordinate CA Certificate; <span
class="anchor" id="line-65"></span></li>
<li>The Issuing CA's or Externally Operated Subordinate CA's right
to issue Certificates under these Requirements expires or is
revoked or terminated, unless the Issuing CA has made
arrangements to continue maintaining the CRL/OCSP Repository; <span
class="anchor" id="line-66"></span></li>
<li>Revocation is required by the Issuing CA's Certificate Policy
and/or Certification Practice Statement; or <span
class="anchor" id="line-67"></span></li>
<li>The technical content or format of the Subordinate CA
Certificate presents an unacceptable risk to Application
Software Suppliers or Relying Parties (e.g. the CA/Browser Forum
might determine that a deprecated cryptographic/signature
algorithm or key size presents an unacceptable risk and that
such Subordinate CA Certificates should be revoked and replaced
by CAs within a given period of time). <span class="anchor"
id="line-68"></span><span class="anchor" id="line-69"></span></li>
</ol>
<p class="line867">
</p>
<h3
id="In_Section_4.9.9_.28On-line_revocation.2BAC8-status_checking_availability.29">In
Section 4.9.9 (On-line revocation/status checking availability)</h3>
<span class="anchor" id="line-70"></span>
<p class="line874">Replace with: <span class="anchor" id="line-71"></span><span
class="anchor" id="line-72"></span></p>
<p class="line874">OCSP responses MUST conform to RFC6960 and/or
RFC5019. OCSP responses MUST either: <span class="anchor"
id="line-73"></span><span class="anchor" id="line-74"></span></p>
<ol type="1">
<li>Be signed by the Private Key associated with the Root CA
Certificate or the Subordinate CA Certificate that issued the
Certificates whose revocation status is being checked, or <span
class="anchor" id="line-75"></span></li>
<li>Be signed by an OCSP Responder whose Certificate is issued by
the Root CA Certificate or Subordinate CA Certificate that
issued the Certificate whose revocation status is being checked.
<span class="anchor" id="line-76"></span><span class="anchor"
id="line-77"></span></li>
</ol>
<p class="line862">In the latter case, the OCSP signing Certificate
MUST contain an extension of type <em>id-pkix-ocsp-nochec</em>k,
as defined by RFC6960. <span class="anchor" id="line-78"></span><span
class="anchor" id="line-79"></span></p>
<p class="line867">
</p>
<h3
id="In_Section_4.9.10_.28On-line_revocation_checking_requirements.29">In
Section 4.9.10 (On-line revocation checking requirements)</h3>
<span class="anchor" id="line-80"></span>
<ul>
<li>Replace the first sentense with "Each CA SHALL support an OCSP
capability using the GET method for Certificates issued in
accordance with these Requirements". <span class="anchor"
id="line-81"></span></li>
<li>Replace the last sentence, which currently reads: "Effective 1
August 2013, OCSP responders for CAs which are not Technically
Constrained in line with Section 7.1.5 MUST NOT respond with a
'good' status for such certificates." with: "OCSP Responders for
Subordinate CA Certificates that are Technically Constrained in
accordance with Section 7.1.5 are exempt from this prohibition
on responding "good" to OCSP requests for the status on
Certificates that have not been issued." <span class="anchor"
id="line-82"></span><span class="anchor" id="line-83"></span></li>
</ul>
<p class="line867">
</p>
<h3
id="In_Section_5.2.2_.28Number_of_Individuals_Required_per_Task.29">In
Section 5.2.2 (Number of Individuals Required per Task)</h3>
<span class="anchor" id="line-84"></span>
<ul>
<li>Replace with: "The Private Key associated with a Root CA
Certificate or Subordinate CA Certificate SHALL be backed up,
stored, and recovered only by personnel in trusted roles using,
at least, dual control in a physically secured environment." <span
class="anchor" id="line-85"></span><span class="anchor"
id="line-86"></span></li>
</ul>
<p class="line867">
</p>
<h3 id="In_Section_5.4.1_.28Types_of_events_recorded.29">In Section
5.4.1 (Types of events recorded)</h3>
<span class="anchor" id="line-87"></span>
<p class="line874">Replace subsections 1 and 2 in the second
paragraph of so that they read: <span class="anchor" id="line-88"></span><span
class="anchor" id="line-89"></span></p>
<p class="line874">The CA SHALL record at least the following
events: <span class="anchor" id="line-90"></span><span
class="anchor" id="line-91"></span></p>
<p class="line874">1. Private Key lifecycle management events for
the Root CA Certificate or Subordinate CA Certificate, including:
<span class="anchor" id="line-92"></span><span class="anchor"
id="line-93"></span></p>
<p class="line874">2. Certificate lifecycle management events for
the Root CA Certificate, Subordinate CA Certificate, and
Subscriber Certificates, including: <span class="anchor"
id="line-94"></span><span class="anchor" id="line-95"></span></p>
<ol type="a">
<li>Certificate requests, renewal, and re-key requests, and
revocation; <span class="anchor" id="line-96"></span></li>
<li>All verification activities stipulated in these Requirements
and the CA's Certification Practice Statement; <span
class="anchor" id="line-97"></span></li>
<li>Date, time, phone number used, persons spoken to, and end
results of verification telephone calls; <span class="anchor"
id="line-98"></span></li>
<li>Acceptance and rejection of certificate requests; Frequency of
Processing Log <span class="anchor" id="line-99"></span></li>
<li>Issuance of Certificates; and <span class="anchor"
id="line-100"></span></li>
<li>Generation of Certificate Revocation Lists and OCSP entries. <span
class="anchor" id="line-101"></span><span class="anchor"
id="line-102"></span></li>
</ol>
<p class="line867">
</p>
<h3
id="In_Section_5.7.1_.28Incident_and_compromise_handling_procedures.29">In
Section 5.7.1 (Incident and compromise handling procedures)</h3>
<span class="anchor" id="line-103"></span>
<p class="line874">* Delete the word "organizations" in the first
sentence of so that it reads, "CAs shall have an Incident Response
Plan and a Disaster Recovery Plan." <span class="anchor"
id="line-104"></span><span class="anchor" id="line-105"></span></p>
<p class="line867">
</p>
<h3 id="In_Section_6.1.1.1_.28CA_Key_Pair_Generation.29">In Section
6.1.1.1 (CA Key Pair Generation)</h3>
<span class="anchor" id="line-106"></span>
<p class="line874">Replace the first two paragraphs with the
following: <span class="anchor" id="line-107"></span><span
class="anchor" id="line-108"></span></p>
<p class="line874">For a Key Pair generated to be associated with
either (i) a Root CA Certificate or (ii) a Subordinate CA
Certificate to be operated by an Externally Operated Subordinate
CA, the CA SHALL: <span class="anchor" id="line-109"></span><span
class="anchor" id="line-110"></span></p>
<ol type="1">
<li>prepare and follow a Key Generation Script, <span
class="anchor" id="line-111"></span></li>
<li>have a Qualified Auditor witness the Key Pair generation
process or record a video of the entire Key Pair generation
process, and <span class="anchor" id="line-112"></span></li>
<li>have a Qualified Auditor issue a report opining that the CA
followed its key ceremony during its Key and Certificate
generation process and the controls used to ensure the integrity
and confidentiality of the Key Pair. <span class="anchor"
id="line-113"></span><span class="anchor" id="line-114"></span></li>
</ol>
<p class="line874">For a Key Pair generated to be associated with a
Subordinate CA Certificate to be operated by the Root CA Operator
or its Affiliates, the CA SHOULD: <span class="anchor"
id="line-115"></span><span class="anchor" id="line-116"></span></p>
<ol type="1">
<li>prepare and follow a Key Generation Script and <span
class="anchor" id="line-117"></span></li>
<li>have a Qualified Auditor witness the Key Pair generation
process or record a video of the entire Key Pair generation
process. <span class="anchor" id="line-118"></span><span
class="anchor" id="line-119"></span></li>
</ol>
<p class="line874">In all cases, the CA SHALL: <span class="anchor"
id="line-120"></span><span class="anchor" id="line-121"></span></p>
<ol type="1">
<li>generate the Key in a physically secured environment as
described in the CA's Certificate Policy and/or Certification
Practice Statement; <span class="anchor" id="line-122"></span></li>
<li>generate the Key using personnel in trusted roles under the
principles of multiple person control and split knowledge; <span
class="anchor" id="line-123"></span></li>
<li>generate the Key within cryptographic modules meeting the
applicable technical and business requirements as disclosed in
the CA's Certificate Policy and/or Certification Practice
Statement; <span class="anchor" id="line-124"></span></li>
<li>log its Key generation activities; and <span class="anchor"
id="line-125"></span></li>
<li>maintain effective controls to provide reasonable assurance
that the Private Key was generated and protected in conformance
with the procedures described in its Certificate Policy and/or
Certification Practice Statement and (if applicable) its Key
Generation Script. <span class="anchor" id="line-126"></span><span
class="anchor" id="line-127"></span></li>
</ol>
<p class="line867">
</p>
<h3
id="Change_the_title_of_Section_6.1.7_as_.22Key_usage_purposes_.28as_per_X.509_v3_key_usage_field.29.22">Change
the title of Section 6.1.7 as "Key usage purposes (as per X.509 v3
key usage field)"</h3>
<span class="anchor" id="line-128"></span>
<p class="line874">In Section 6.1.7 replace with: <span
class="anchor" id="line-129"></span><span class="anchor"
id="line-130"></span></p>
<p class="line874">Private Keys associated with Root CA Certificates
MUST NOT be used to sign Certificates except in the following
cases: <span class="anchor" id="line-131"></span><span
class="anchor" id="line-132"></span></p>
<ol type="1">
<li>Self-signed Root CA Certificates themselves; <span
class="anchor" id="line-133"></span></li>
<li>Subordinate CA Certificates and Cross Certificates; <span
class="anchor" id="line-134"></span></li>
<li>Certificates for infrastructure purposes (e.g. administrative
role certificates, internal CA operational device certificates,
and OCSP Response verification Certificates); and <span
class="anchor" id="line-135"></span></li>
<li>Certificates issued solely for the purpose of testing products
with Certificates issued by a Root CA Certificate. <span
class="anchor" id="line-136"></span><span class="anchor"
id="line-137"></span></li>
</ol>
<p class="line867">
</p>
<h3 id="In_Section_6.2.5_.28Private_key_archival.29">In Section
6.2.5 (Private key archival)</h3>
<span class="anchor" id="line-138"></span>
<p class="line874">Replace with: <span class="anchor" id="line-139"></span><span
class="anchor" id="line-140"></span></p>
<p class="line874">"Parties other than the Subordinate CA Operator
SHALL NOT archive the Private Keys associated with the Subordinate
CA Certificate without authorization by the Subordinate CA
Operator." <span class="anchor" id="line-141"></span><span
class="anchor" id="line-142"></span></p>
<p class="line867">
</p>
<h3
id="In_Section_6.2.6_.28Private_key_transfer_into_or_from_a_cryptographic_module.29">In
Section 6.2.6 (Private key transfer into or from a cryptographic
module)</h3>
<span class="anchor" id="line-143"></span>
<p class="line874">Replace with: <span class="anchor" id="line-144"></span><span
class="anchor" id="line-145"></span></p>
<p class="line874">If the Issuing CA generated the Private Key on
behalf of an Externally Operated Subordinate CA, then the Issuing
CA SHALL encrypt the Private Key for transport to the Externally
Operated Subordinate CA. <span class="anchor" id="line-146"></span><span
class="anchor" id="line-147"></span></p>
<p class="line874">If the Issuing CA becomes aware that an
Externally Operated Subordinate CA's Private Key has been
communicated to an unauthorized person or an organization not
affiliated with the Externally Operated Subordinate CA, then the
Issuing CA SHALL revoke all Subordinate CA Certificates that
include the Public Key corresponding to the communicated Private
Key. <span class="anchor" id="line-148"></span><span
class="anchor" id="line-149"></span></p>
<p class="line867">
</p>
<h3 id="In_Section_7.1.2.1_.28Root_CA_Certificate.29">In Section
7.1.2.1 (Root CA Certificate)</h3>
<span class="anchor" id="line-150"></span>
<p class="line874">Replace subsection b. (keyUsage), with: <span
class="anchor" id="line-151"></span><span class="anchor"
id="line-152"></span></p>
<p class="line862">"This extension MUST be present and MUST be
marked critical. Bit positions for <em>keyCertSign </em>and <em>cRLSign
</em>MUST be set. If the Private Key associated with the Root CA
Certificate is to be used for signing OCSP responses, then the <em>digitalSignature
</em>bit MUST be set." <span class="anchor" id="line-153"></span><span
class="anchor" id="line-154"></span></p>
<p class="line867">
</p>
<h3 id="In_Section_7.1.2.2_.28Subordinate_CA_Certificate.29">In
Section 7.1.2.2 (Subordinate CA Certificate)</h3>
<span class="anchor" id="line-155"></span>
<p class="line874">Replace subsection a. through c, subsections e.
and g. with the following: <span class="anchor" id="line-156"></span><span
class="anchor" id="line-157"></span></p>
<p class="line874">a. certificatePolicies <span class="anchor"
id="line-158"></span><span class="anchor" id="line-159"></span></p>
<p class="line874">This extension MUST be present and SHOULD NOT be
marked critical. <span class="anchor" id="line-160"></span><span
class="anchor" id="line-161"></span></p>
<ul>
<li style="list-style-type:none">certificatePolicies:policyIdentifier
(Required) <span class="anchor" id="line-162"></span><span
class="anchor" id="line-163"></span></li>
<li class="gap" style="list-style-type:none">The following fields
MAY be present: <span class="anchor" id="line-164"></span><span
class="anchor" id="line-165"></span></li>
</ul>
<p class="line874">certificatePolicies:policyQualifiers:policyQualifierId
(Optional) <span class="anchor" id="line-166"></span><span
class="anchor" id="line-167"></span></p>
<ul>
<li>id-qt 1 [RFC 5280] <span class="anchor" id="line-168"></span><span
class="anchor" id="line-169"></span></li>
</ul>
<p class="line874">certificatePolicies:policyQualifiers:qualifier:cPSuri
(Optional) <span class="anchor" id="line-170"></span><span
class="anchor" id="line-171"></span></p>
<ul>
<li>HTTP URL for the CA's Certificate Policy, Certification
Practice Statement, Relying Party Agreement, or other pointer to
online policy information provided by the CA. <span
class="anchor" id="line-172"></span><span class="anchor"
id="line-173"></span></li>
</ul>
<p class="line874">b. cRLDistributionPoints <span class="anchor"
id="line-174"></span><span class="anchor" id="line-175"></span></p>
<ul>
<li style="list-style-type:none">This extension MUST be present
and MUST NOT be marked critical. It MUST contain the HTTP URL of
the Issuing CA's CRL service where revocation of the Subordinate
CA Certificate will be published. <span class="anchor"
id="line-176"></span><span class="anchor" id="line-177"></span></li>
</ul>
<p class="line874">c. authorityInformationAccess <span
class="anchor" id="line-178"></span><span class="anchor"
id="line-179"></span></p>
<ul>
<li style="list-style-type:none">With the exception of stapling,
which is noted below, this extension MUST be present. It MUST
NOT be marked critical, and it MUST contain the HTTP URL of the
Issuing CA's OCSP responder that provides the status of the
Subordinate CA Certificate (accessMethod = 1.3.6.1.5.5.7.48.1).
It SHOULD also contain the HTTP URL of the Issuing CA's CA
Certificate (accessMethod = 1.3.6.1.5.5.7.48.2). <span
class="anchor" id="line-180"></span></li>
<li style="list-style-type:none"><span class="anchor"
id="line-181"></span><br>
</li>
<li style="list-style-type:none">The HTTP URL of the Issuing CA's
OCSP responder MAY be omitted, provided that the Subscriber
"staples" the OCSP response for the Certificate in its TLS
handshakes [RFC4366]. <span class="anchor" id="line-182"></span><span
class="anchor" id="line-183"></span></li>
</ul>
<p class="line874">e. keyUsage <span class="anchor" id="line-184"></span><span
class="anchor" id="line-185"></span></p>
<ul>
<li style="list-style-type:none">
<p class="line862">This extension MUST be present and MUST be
marked critical. Bit positions for <em>keyCertSign </em>and
<em>cRLSign </em>MUST be set. If the Private Key that
corresponds to the Subordinate CA Certificate is used for
signing OCSP responses, then the <em>digitalSignature </em>bit
MUST be set. <span class="anchor" id="line-186"></span><span
class="anchor" id="line-187"></span></p>
</li>
</ul>
<p class="line874">g. extkeyUsage (optional) <span class="anchor"
id="line-188"></span><span class="anchor" id="line-189"></span></p>
<p class="line874">For Subordinate CA Certificates to be Technically
constrained in line with section 7.1.5, then either the value
id-kp-serverAuth [RFC5280] or id-kp-clientAuth [RFC5280] or both
values MUST be present**. <span class="anchor" id="line-190"></span><span
class="anchor" id="line-191"></span></p>
<p class="line874">Other values MAY be present. <span
class="anchor" id="line-192"></span><span class="anchor"
id="line-193"></span></p>
<p class="line874">If present, this extension SHOULD be marked
non-critical. <span class="anchor" id="line-194"></span><span
class="anchor" id="line-195"></span></p>
<p class="line874">** Generally Extended Key Usage will only appear
within end entity certificates (as highlighted in RFC 5280
(4.2.1.12)), however, Subordinate CA Operators MAY include the
extension to further protect relying parties until the use of the
extension is consistent between Application Software Suppliers
whose software is used by a substantial portion of Relying Parties
worldwide. <span class="anchor" id="line-196"></span><span
class="anchor" id="line-197"></span></p>
<p class="line867">
</p>
<h3 id="In_Section_7.1.2.3_.28Subscriber_Certificate.29">In Section
7.1.2.3 (Subscriber Certificate)</h3>
<span class="anchor" id="line-198"></span>
<p class="line874">Replace subsection a. with the following: <span
class="anchor" id="line-199"></span><span class="anchor"
id="line-200"></span></p>
<p class="line874">a. certificatePolicies <span class="anchor"
id="line-201"></span><span class="anchor" id="line-202"></span></p>
<p class="line874">This extension MUST be present and SHOULD NOT be
marked critical. <span class="anchor" id="line-203"></span><span
class="anchor" id="line-204"></span></p>
<ul>
<li style="list-style-type:none">certificatePolicies:policyIdentifier
(Required) <span class="anchor" id="line-205"></span><span
class="anchor" id="line-206"></span></li>
<li class="gap">A Policy Identifier, defined by the issuing CA,
that indicates a Certificate Policy asserting the issuing CA's
adherence to and compliance with these Requirements. The
following extensions MAY be present:
certificatePolicies:policyQualifiers:policyQualifierId
(Recommended) <span class="anchor" id="line-207"></span><span
class="anchor" id="line-208"></span></li>
<li class="gap">id-qt 1 [RFC 5280].
certificatePolicies:policyQualifiers:qualifier:cPSuri (Optional)
<span class="anchor" id="line-209"></span><span class="anchor"
id="line-210"></span></li>
<li class="gap">HTTP URL for the Subordinate CA Operator's
Certification Practice Statement, Relying Party Agreement or
other pointer to online information provided by the CA. <span
class="anchor" id="line-211"></span><span class="anchor"
id="line-212"></span></li>
</ul>
<p class="line874">Replace subsection c. with the following: <span
class="anchor" id="line-213"></span><span class="anchor"
id="line-214"></span></p>
<p class="line874">c. authorityInformationAccess <span
class="anchor" id="line-215"></span><span class="anchor"
id="line-216"></span></p>
<p class="line874">With the exception of stapling, which is noted
below, this extension MUST be present. It MUST NOT be marked
critical, and it MUST contain the HTTP URL of the Issuing CA's
OCSP responder that provides the status of the Certificate
(accessMethod = 1.3.6.1.5.5.7.48.1). It SHOULD also contain the
HTTP URL of the Issuing CA's CA Certificate (accessMethod =
1.3.6.1.5.5.7.48.2). <span class="anchor" id="line-217"></span><span
class="anchor" id="line-218"></span></p>
<p class="line874">The HTTP URL of the Issuing CA's OCSP responder
MAY be omitted provided that the Subscriber "staples" OCSP
responses for the Certificate in its TLS handshakes [RFC4366]. <span
class="anchor" id="line-219"></span><span class="anchor"
id="line-220"></span></p>
<p class="line867">
</p>
<h3 id="In_Section_7.1.3_.28Algorithm_object_identifiers.29">In
Section 7.1.3 (Algorithm object identifiers)</h3>
<span class="anchor" id="line-221"></span>
<p class="line874">Replace the first paragraph with: <span
class="anchor" id="line-222"></span><span class="anchor"
id="line-223"></span></p>
<p class="line874">"CAs MUST NOT sign Certificates using the SHA-1
hash algorithm. This Section (7.1.3) does not apply to existing
Root CA Certificates or Cross Certificates. CAs MAY continue to
use their existing SHA-1 Root CA Certificates. SHA-2 Subscriber
Certificates SHOULD NOT chain up to a SHA-1 Subordinate CA
Certificate". <span class="anchor" id="line-224"></span><span
class="anchor" id="line-225"></span></p>
<p class="line867">
</p>
<h3 id="In_Section_7.1.4.1_.28Issuing_CA_Certificate_Subject.29">In
Section 7.1.4.1 (Issuing CA Certificate Subject)</h3>
<span class="anchor" id="line-226"></span>
<p class="line874">Replace with: <span class="anchor" id="line-227"></span><span
class="anchor" id="line-228"></span></p>
<p class="line874">"The content of the Certificate Issuer
Distinguished Name field MUST match the Subject DN of the Issuing
CA's CA Certificate to support name chaining as specified in RFC
5280, section 4.1.2.4." <span class="anchor" id="line-229"></span><span
class="anchor" id="line-230"></span></p>
<p class="line867">
</p>
<h3 id="In_Section_7.1.5_.28Name_Constraints.29">In Section 7.1.5
(Name Constraints)</h3>
<span class="anchor" id="line-231"></span>
<p class="line874">Replace the last paragraph with: <span
class="anchor" id="line-232"></span><span class="anchor"
id="line-233"></span></p>
<p class="line874">If the Subordinate CA Operator is not allowed to
issue certificates with dNSNames, then the Subordinate CA
Certificate MUST include a zero-length dNSName in
excludedSubtrees. Otherwise, the Subordinate CA Certificate MUST
include at least one dNSName in permittedSubtrees. <span
class="anchor" id="line-234"></span><span class="anchor"
id="line-235"></span></p>
<p class="line867">
</p>
<h3
id="In_Section_7.1.6.1_.28Reserved_Certificate_Policy_Identifiers.29">In
Section 7.1.6.1 (Reserved Certificate Policy Identifiers)</h3>
<span class="anchor" id="line-236"></span>
<p class="line874">Replace the first sentence with: <span
class="anchor" id="line-237"></span><span class="anchor"
id="line-238"></span></p>
<p class="line874">This section describes the content requirements
for the Root CA Certificates, Subordinate CA Certificates, and
Subscriber Certificates, as they relate to the identification of
Certificate Policy. <span class="anchor" id="line-239"></span><span
class="anchor" id="line-240"></span></p>
<p class="line867">
</p>
<h3 id="In_Section_7.1.6.3_.28Subordinate_CA_Certificates.29">In
Section 7.1.6.3 (Subordinate CA Certificates)</h3>
<span class="anchor" id="line-241"></span>
<p class="line874">Replace with: <span class="anchor" id="line-242"></span><span
class="anchor" id="line-243"></span></p>
<p class="line874">A Subordinate CA Certificate issued after the
Effective Date to an Externally Operated Subordinate CA: <span
class="anchor" id="line-244"></span><span class="anchor"
id="line-245"></span></p>
<ol type="1">
<li>MUST include one or more explicit policy identifiers that
indicates the Externally Operated Subordinate CA's adherence to
and compliance with these Requirements (i.e. either the
CA/Browser Forum reserved identifiers or identifiers defined by
the CA in its Certificate Policy and/or Certification Practice
Statement) and <span class="anchor" id="line-246"></span></li>
<li>MUST NOT contain the "anyPolicy" identifier (2.5.29.32.0). <span
class="anchor" id="line-247"></span><span class="anchor"
id="line-248"></span></li>
</ol>
<p class="line874">A Subordinate CA Certificate issued after the
Effective Date to an Internally Operated Subordinate CA: <span
class="anchor" id="line-249"></span><span class="anchor"
id="line-250"></span></p>
<ol type="1">
<li>MAY include the CA/Browser Forum reserved identifiers or an
identifier defined by the CA in its Certificate Policy and/or
Certification Practice Statement to indicate the Internally
Operated Subordinate CA's compliance with these Requirements and
<span class="anchor" id="line-251"></span></li>
<li>MAY contain the "anyPolicy" identifier (2.5.29.32.0) in place
of an explicit policy identifier. <span class="anchor"
id="line-252"></span><span class="anchor" id="line-253"></span></li>
</ol>
<p class="line874">All CAs SHALL represent, in their Certificate
Policy and/or Certification Practice Statement, that all
Certificates containing a policy identifier indicating compliance
with these Requirements are issued and managed in accordance with
these Requirements. <span class="anchor" id="line-254"></span><span
class="anchor" id="line-255"></span></p>
<p class="line867">
</p>
<h3
id="In_Section_8.1_.28Frequency_or_circumstances_of_assessment.29">In
Section 8.1 (Frequency or circumstances of assessment)</h3>
<span class="anchor" id="line-256"></span>
<p class="line874">Replace the first paragraph with: <span
class="anchor" id="line-257"></span><span class="anchor"
id="line-258"></span></p>
<p class="line862">CA Certificates MUST either be (a) Technically
Constrained in line with section 7.1.5 and be audited in line with
section 8.7 only, or (b) be fully audited in line with all
requirements of this section (8). A Certificate is deemed capable
of being used to issue certificates for server authentication if
it contains an X.509v3 basicConstraints extension with the CA
boolean set to true and has no EKU, the <em>id-kp-anyExtendedKeyUsage</em>
[RFC5280] EKU, or the <em>id-kp-serverAuth</em> [RFC5280] EKU. <span
class="anchor" id="line-259"></span><span class="anchor"
id="line-260"></span></p>
<p class="line867">
</p>
<h3 id="In_Section_8.7_.28Self-Audits.29">In Section 8.7
(Self-Audits)</h3>
<span class="anchor" id="line-261"></span>
<p class="line874">Replace the last paragraph with: <span
class="anchor" id="line-262"></span><span class="anchor"
id="line-263"></span></p>
<p class="line874">During the period in which a Technically
Constrained Externally Operated Subordinate CA issues
Certificates, the Issuing CA SHALL monitor adherence to the
Issuing CA's Certificate Policy and/or Certification Practice
Statement and the Externally Operated Subordinate CA's Certificate
Policy and/or Certification Practice Statement. On at least a
quarterly basis, against a randomly selected sample of the greater
of one certificate or at least three percent of the Certificates
issued by the Externally Operated Subordinate CA, during the
period commencing immediately after the previous audit sample was
taken, the CA SHALL ensure adherence to all applicable Certificate
Policies and/or Certification Practice Statements. <span
class="anchor" id="line-264"></span><span class="anchor"
id="line-265"></span></p>
<p class="line867">
</p>
<h3 id="In_Section_9.6.1_.28CA_representations_and_warranties.29">In
Section 9.6.1 (CA representations and warranties)</h3>
<span class="anchor" id="line-266"></span>
<p class="line874">Replace subsection 2 with: <span class="anchor"
id="line-267"></span><span class="anchor" id="line-268"></span></p>
<p class="line874">"2. All Application Software Suppliers with whom
the Root CA Operator has entered into a contract for inclusion of
its Root CA Certificate in software distributed by such
Application Software Supplier; and" <span class="anchor"
id="line-269"></span><span class="anchor" id="line-270"></span></p>
<p class="line874">Replace the last paragraph with: <span
class="anchor" id="line-271"></span><span class="anchor"
id="line-272"></span></p>
<p class="line874">The Root CA Operator SHALL be responsible for the
performance and warranties of its Externally Operated Subordinate
CAs, for the Externally Operated Subordinate CAs' compliance with
these Requirements, and for all liabilities and indemnification
obligations of the Externally Operated Subordinate CAs under these
Requirements, as if the Root CA Operator were the Externally
Operated Subordinate CA issuing the Certificates. <span
class="anchor" id="line-273"></span><span class="anchor"
id="line-274"></span></p>
<p class="line867"><strong>-- MOTION ENDS --</strong> <span
class="anchor" id="line-275"></span><span class="anchor"
id="line-276"></span></p>
<p class="line874">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="anchor"
id="line-277"></span></p>
<div>
<table>
<tbody>
<tr>
<td>
<p class="line862">BALLOT 188 Status: Clarify use of term
"CA" in Baseline Requirements </p>
</td>
<td colspan="2" style="text-align:center">
<p class="line862">Start time (22:00 UTC) </p>
</td>
<td colspan="2" style="text-align:center">
<p class="line862">End time (22:00 UTC) </p>
</td>
</tr>
<tr>
<td><span class="anchor" id="line-278"></span>
<p class="line862">Discussion (7 days) </p>
</td>
<td colspan="2" style="text-align:center">
<p class="line862">16 Feb. 2017 </p>
</td>
<td colspan="2" style="text-align:center">
<p class="line862">23 Feb. 2017 </p>
</td>
</tr>
<tr>
<td><span class="anchor" id="line-279"></span>
<p class="line862">Vote for approval (7 days) </p>
</td>
<td colspan="2" style="text-align:center">
<p class="line862">23 Feb. 2017 </p>
</td>
<td colspan="2" style="text-align:center">
<p class="line862">2 Mar. 2017 </p>
</td>
</tr>
<tr>
<td><span class="anchor" id="line-280"></span>
<p class="line862">If vote approves ballot: Review Period
(Chair to send Review Notice) (30 calendar days). If
Exclusion Notice(s) filed, ballot approval is rescinded
and PAG to be created. If no Exclusion Notices filed,
ballot becomes effective at end of Review Period. </p>
</td>
<td colspan="2" style="text-align:center">
<p class="line862">Upon filing of Review Notice by Chair </p>
</td>
<td colspan="2" style="text-align:center">
<p class="line862">30 days after filing of Review Notice
by Chair </p>
</td>
</tr>
</tbody>
</table>
</div>
<span class="anchor" id="line-281"></span><span class="anchor"
id="line-282"></span><span class="anchor" id="line-283"></span>
<p class="line874">This is a Draft Guideline Ballot that proposes a
Final Maintenance Guideline. In accordance with Section 2.3 of the
Bylaws this ballot includes a full set of the Baseline
Requirements with a redline or comparison showing the set of
changes from the Final Guideline section(s) intended to become a
Final Maintenance Guideline. Such redline or comparison has been
made against the Final Guideline section(s) as they exist at the
time that this ballot is proposed. <span class="anchor"
id="line-284"></span><span class="anchor" id="line-285"></span></p>
<p class="line874">Votes must be cast by posting an on-list reply to
this thread on the Public Mail List. <span class="anchor"
id="line-286"></span><span class="anchor" id="line-287"></span></p>
<p class="line862">A vote in favor of the ballot 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-288"></span><span class="anchor"
id="line-289"></span></p>
In order for the ballot 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 ten (10) Members – at least ten Members must
participate in the ballot, either by voting in favor, voting
against, or abstaining.
</body>
</html>