<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I realize this is super late feedback, but after doing an internal review of this ballot, I think it actually makes a key issue worse rather than solving it.</div><div class=""><br class=""></div><div class="">According to the ballot, "Root CA Certificate” is now defined as "A CA Certificate in which the Public Key has been digitally signed by its corresponding Private Key.” This basically means that every self-signed certificate is now considered a Root CA Certificate. This definition is then used in section 6.1.1.1: "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:” and in 6.1.7 when discussing the limitations of key usage.</div><div class=""><br class=""></div><div class="">This effectively means that any CA that wants to create a self-signed certificate, even if it is intended to be used as a subordinate CA, must follow the key generation procedure where they must have an auditor witness or write a report based on watching the video tape. It also means that any key found in a self-signed certificate cannot be used to sign end-entity certificates. </div><div class=""><br class=""></div><div class="">Given the clear focus on compliance to specifications as written, I think that this is a bug that can easily bite many CAs. I know I don’t want to be restricted using a CA for issuing server certificates just because I happened to create a self-signed certificate for that CA.</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Peter</div><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 16, 2017, at 12:39 PM, Dimitris Zacharopoulos via Public <<a href="mailto:public@cabforum.org" class="">public@cabforum.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
<div bgcolor="#FFFFFF" text="#000000" class=""><p class="line867">Trying to fix formatting issues. Let's hope this
goes through correctly.<br class="">
Dimitris.<br class="">
<strong class=""></strong></p><p class="line867"><strong class="">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 class="">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 class="">-- MOTION BEGINS --</strong> <span class="anchor" id="line-17"></span><span class="anchor" id="line-18"></span></p><div class="">
<br class="webkit-block-placeholder"></div>
<h3 id="In_Section_1.1_.28Overview.29" class="">In Section 1.1 (Overview)</h3>
<span class="anchor" id="line-19"></span>
<ul class="">
<li class="">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 class="">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><div class="">
<br class="webkit-block-placeholder"></div>
<h3 id="In_Section_1.6.1_.28Definitions.29" class="">In Section 1.6.1
(Definitions)</h3>
<span class="anchor" id="line-23"></span>
<ul class="">
<li class="">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 class="">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 class="">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 class="">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 class="">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 class="">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 class="">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 class="">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 class="">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 class="">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 class="">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 class="">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 class="">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 class="">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><div class="">
<br class="webkit-block-placeholder"></div>
<h3 id="In_Section_1.6.2_.28Acronyms.29" class="">In Section 1.6.2 (Acronyms)</h3>
<span class="anchor" id="line-39"></span>
<ul class="">
<li class=""><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><div class="">
<br class="webkit-block-placeholder"></div>
<h3 id="In_Section_3.2.2.4_.28Validation_of_Domain_Authorization_or_Control.29" class="">In
Section 3.2.2.4 (Validation of Domain Authorization or Control)</h3>
<span class="anchor" id="line-42"></span>
<ul class="">
<li class="">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><div class="">
<br class="webkit-block-placeholder"></div>
<h3 id="In_Section_3.2.2.4.6_.28Agreed-Upon_Change_to_Website.29" class="">In
Section 3.2.2.4.6 (Agreed-Upon Change to Website)</h3>
<span class="anchor" id="line-45"></span>
<ul class="">
<li class="">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><div class="">
<br class="webkit-block-placeholder"></div>
<h3 id="In_Section_4.1.2_.28Enrollment_Process_and_Responsibilities.29" class="">In
Section 4.1.2 (Enrollment Process and Responsibilities)</h3>
<span class="anchor" id="line-48"></span>
<ul class="">
<li class="">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><div class="">
<br class="webkit-block-placeholder"></div>
<h3 id="In_Section_4.9.1.1_.28Reasons_for_Revoking_a_Subscriber_Certificate.29" class="">In
Section 4.9.1.1 (Reasons for Revoking a Subscriber Certificate)</h3>
<span class="anchor" id="line-51"></span>
<ul class="">
<li class="">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><div class="">
<br class="webkit-block-placeholder"></div>
<h3 id="In_Section_4.9.1.2_.28Reasons_for_Revoking_a_Subordinate_CA_Certificate.29" class="">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" class="">
<li class="">The Externally Operated Subordinate CA requests revocation in
writing; <span class="anchor" id="line-59"></span></li>
<li class="">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 class="">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 class="">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 class="">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 class="">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 class="">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 class="">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 class="">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 class="">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><div class="">
<br class="webkit-block-placeholder"></div>
<h3 id="In_Section_4.9.9_.28On-line_revocation.2BAC8-status_checking_availability.29" class="">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" class="">
<li class="">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 class="">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 class="">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><div class="">
<br class="webkit-block-placeholder"></div>
<h3 id="In_Section_4.9.10_.28On-line_revocation_checking_requirements.29" class="">In
Section 4.9.10 (On-line revocation checking requirements)</h3>
<span class="anchor" id="line-80"></span>
<ul class="">
<li class="">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 class="">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><div class="">
<br class="webkit-block-placeholder"></div>
<h3 id="In_Section_5.2.2_.28Number_of_Individuals_Required_per_Task.29" class="">In
Section 5.2.2 (Number of Individuals Required per Task)</h3>
<span class="anchor" id="line-84"></span>
<ul class="">
<li class="">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><div class="">
<br class="webkit-block-placeholder"></div>
<h3 id="In_Section_5.4.1_.28Types_of_events_recorded.29" class="">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" class="">
<li class="">Certificate requests, renewal, and re-key requests, and
revocation; <span class="anchor" id="line-96"></span></li>
<li class="">All verification activities stipulated in these Requirements
and the CA's Certification Practice Statement; <span class="anchor" id="line-97"></span></li>
<li class="">Date, time, phone number used, persons spoken to, and end
results of verification telephone calls; <span class="anchor" id="line-98"></span></li>
<li class="">Acceptance and rejection of certificate requests; Frequency of
Processing Log <span class="anchor" id="line-99"></span></li>
<li class="">Issuance of Certificates; and <span class="anchor" id="line-100"></span></li>
<li class="">Generation of Certificate Revocation Lists and OCSP entries. <span class="anchor" id="line-101"></span><span class="anchor" id="line-102"></span></li>
</ol><div class="">
<br class="webkit-block-placeholder"></div>
<h3 id="In_Section_5.7.1_.28Incident_and_compromise_handling_procedures.29" class="">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><div class="">
<br class="webkit-block-placeholder"></div>
<h3 id="In_Section_6.1.1.1_.28CA_Key_Pair_Generation.29" class="">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" class="">
<li class="">prepare and follow a Key Generation Script, <span class="anchor" id="line-111"></span></li>
<li class="">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 class="">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" class="">
<li class="">prepare and follow a Key Generation Script and <span class="anchor" id="line-117"></span></li>
<li class="">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" class="">
<li class="">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 class="">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 class="">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 class="">log its Key generation activities; and <span class="anchor" id="line-125"></span></li>
<li class="">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><div class="">
<br class="webkit-block-placeholder"></div>
<h3 id="Change_the_title_of_Section_6.1.7_as_.22Key_usage_purposes_.28as_per_X.509_v3_key_usage_field.29.22" class="">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" class="">
<li class="">Self-signed Root CA Certificates themselves; <span class="anchor" id="line-133"></span></li>
<li class="">Subordinate CA Certificates and Cross Certificates; <span class="anchor" id="line-134"></span></li>
<li class="">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 class="">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><div class="">
<br class="webkit-block-placeholder"></div>
<h3 id="In_Section_6.2.5_.28Private_key_archival.29" class="">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><div class="">
<br class="webkit-block-placeholder"></div>
<h3 id="In_Section_6.2.6_.28Private_key_transfer_into_or_from_a_cryptographic_module.29" class="">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><div class="">
<br class="webkit-block-placeholder"></div>
<h3 id="In_Section_7.1.2.1_.28Root_CA_Certificate.29" class="">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 class="">keyCertSign </em>and <em class="">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 class="">digitalSignature
</em>bit MUST be set." <span class="anchor" id="line-153"></span><span class="anchor" id="line-154"></span></p><div class="">
<br class="webkit-block-placeholder"></div>
<h3 id="In_Section_7.1.2.2_.28Subordinate_CA_Certificate.29" class="">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 class="">
<li style="list-style-type:none" class="">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 class="">
<li class="">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 class="">
<li class="">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 class="">
<li style="list-style-type:none" class="">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 class="">
<li style="list-style-type:none" class="">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" class=""><span class="anchor" id="line-181"></span><br class="">
</li>
<li style="list-style-type:none" class="">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 class="">
<li style="list-style-type:none" class=""><p class="line862">This extension MUST be present and MUST be
marked critical. Bit positions for <em class="">keyCertSign </em>and
<em class="">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 class="">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><div class="">
<br class="webkit-block-placeholder"></div>
<h3 id="In_Section_7.1.2.3_.28Subscriber_Certificate.29" class="">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 class="">
<li style="list-style-type:none" class="">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><div class="">
<br class="webkit-block-placeholder"></div>
<h3 id="In_Section_7.1.3_.28Algorithm_object_identifiers.29" class="">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><div class="">
<br class="webkit-block-placeholder"></div>
<h3 id="In_Section_7.1.4.1_.28Issuing_CA_Certificate_Subject.29" class="">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><div class="">
<br class="webkit-block-placeholder"></div>
<h3 id="In_Section_7.1.5_.28Name_Constraints.29" class="">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><div class="">
<br class="webkit-block-placeholder"></div>
<h3 id="In_Section_7.1.6.1_.28Reserved_Certificate_Policy_Identifiers.29" class="">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><div class="">
<br class="webkit-block-placeholder"></div>
<h3 id="In_Section_7.1.6.3_.28Subordinate_CA_Certificates.29" class="">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" class="">
<li class="">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 class="">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" class="">
<li class="">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 class="">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><div class="">
<br class="webkit-block-placeholder"></div>
<h3 id="In_Section_8.1_.28Frequency_or_circumstances_of_assessment.29" class="">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 class="">id-kp-anyExtendedKeyUsage</em>
[RFC5280] EKU, or the <em class="">id-kp-serverAuth</em> [RFC5280] EKU. <span class="anchor" id="line-259"></span><span class="anchor" id="line-260"></span></p><div class="">
<br class="webkit-block-placeholder"></div>
<h3 id="In_Section_8.7_.28Self-Audits.29" class="">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><div class="">
<br class="webkit-block-placeholder"></div>
<h3 id="In_Section_9.6.1_.28CA_representations_and_warranties.29" class="">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 class="">-- 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 class="">
<table class="">
<tbody class="">
<tr class="">
<td class=""><p class="line862">BALLOT 188 Status: Clarify use of term
"CA" in Baseline Requirements </p>
</td>
<td colspan="2" style="text-align:center" class=""><p class="line862">Start time (22:00 UTC) </p>
</td>
<td colspan="2" style="text-align:center" class=""><p class="line862">End time (22:00 UTC) </p>
</td>
</tr>
<tr class="">
<td class=""><span class="anchor" id="line-278"></span><p class="line862">Discussion (7 days) </p>
</td>
<td colspan="2" style="text-align:center" class=""><p class="line862">16 Feb. 2017 </p>
</td>
<td colspan="2" style="text-align:center" class=""><p class="line862">23 Feb. 2017 </p>
</td>
</tr>
<tr class="">
<td class=""><span class="anchor" id="line-279"></span><p class="line862">Vote for approval (7 days) </p>
</td>
<td colspan="2" style="text-align:center" class=""><p class="line862">23 Feb. 2017 </p>
</td>
<td colspan="2" style="text-align:center" class=""><p class="line862">2 Mar. 2017 </p>
</td>
</tr>
<tr class="">
<td class=""><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" class=""><p class="line862">Upon filing of Review Notice by Chair </p>
</td>
<td colspan="2" style="text-align:center" class=""><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.
</div>
<span id="cid:FBBC03AB-6BBA-4349-A61E-EE6CA57AD0CE@amazon.com"><Ballot 188 - Clarify the term CA in BR 1.4.2 red-lined-final.pdf></span>_______________________________________________<br class="">Public mailing list<br class=""><a href="mailto:Public@cabforum.org" class="">Public@cabforum.org</a><br class="">https://cabforum.org/mailman/listinfo/public<br class=""></div></blockquote></div><br class=""></body></html>