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