<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:宋体;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:宋体;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"\@宋体";
panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"批注框文本 Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:9.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle17
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.Char
{mso-style-name:"批注框文本 Char";
mso-style-priority:99;
mso-style-link:批注框文本;
font-family:宋体;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=ZH-CN link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span lang=EN-US style='font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D'>CFCA votes NO.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:宋体'>发件人<span lang=EN-US>:</span></span></b><span lang=EN-US style='font-size:10.0pt;font-family:宋体'> public-bounces@cabforum.org [mailto:public-bounces@cabforum.org] </span><b><span style='font-size:10.0pt;font-family:宋体'>代表 </span></b><span lang=EN-US style='font-size:10.0pt;font-family:宋体'>Steve Medin via Public<br></span><b><span style='font-size:10.0pt;font-family:宋体'>发送时间<span lang=EN-US>:</span></span></b><span lang=EN-US style='font-size:10.0pt;font-family:宋体'> 2017</span><span style='font-size:10.0pt;font-family:宋体'>年<span lang=EN-US>3</span>月<span lang=EN-US>2</span>日<span lang=EN-US> 2:08<br></span><b>收件人<span lang=EN-US>:</span></b><span lang=EN-US> CA/Browser Forum Public Discussion List<br></span><b>抄送<span lang=EN-US>:</span></b><span lang=EN-US> Steve Medin<br></span><b>主题<span lang=EN-US>:</span></b><span lang=EN-US> Re: [cabfpub] Ballot 188 - Clarify use of term "CA" in Baseline Requirements<o:p></o:p></span></span></p></div></div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Symantec votes NO. We appreciate both the original effort and the issues raised below.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div style='border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt'><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>From:</span></b><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif"'> Public [mailto:public-bounces@cabforum.org] <b>On Behalf Of </b>Ryan Sleevi via Public<br><b>Sent:</b> Friday, February 24, 2017 5:29 PM<br><b>To:</b> CA/Browser Forum Public Discussion List <public@cabforum.org><br><b>Cc:</b> Ryan Sleevi <sleevi@google.com><br><b>Subject:</b> Re: [cabfpub] Ballot 188 - Clarify use of term "CA" in Baseline Requirements<o:p></o:p></span></p></div></div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><div><p class=MsoNormal><span lang=EN-US>Apologies for this late batch of feedback; Google is continuing to discover new details related to various misissuances by CAs that is otherwise occupying significant time.<o:p></o:p></span></p><div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US>I have some concerns with some of these provisions, even if I think on the whole, the sum is certainly where we desire to see things. Given that voting has now begun, I'm hoping to gather feedback on how a secondary ballot might correct these matters, if indeed these concerns are valid, prior to voting. Otherwise, we will need to carefully evaluate whether the risk of these issues exceeds the value the overall ballot provides.<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US>That said, I appreciate the folks who have driven this ballot to this period, as it helps make sure we prioritize and provide the actionable feedback that might make it easier to support this or a future ballot, as below:<o:p></o:p></span></p><div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><div><p class=MsoNormal><span lang=EN-US>On Thu, Feb 16, 2017 at 11:08 AM, Ben Wilson via Public <<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>> wrote:<o:p></o:p></span></p><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'><p class=MsoNormal><span lang=EN-US>* 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." <o:p></o:p></span></p></blockquote><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'><p class=MsoNormal><span lang=EN-US>* 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."<o:p></o:p></span></p></blockquote><div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US>I think this is a potentially problematic definition, in that it relates to the scope of the operations of the audit, as well as matters below that I highlight. I'm hoping the proposers and drafters can clarify (or link to previous discussions) as to the reason in which "or its Affiliate" was introduced into these definitions, or to highlight where it was already a natural and existing part of these definitions.<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'><p class=MsoNormal><span lang=EN-US>In Section 4.9.1.2 (Reasons for Revoking a Subordinate CA Certificate)<br><br><br>Replace with:<br><br>The Issuing CA SHALL revoke a Subordinate CA Certificate within seven (7) days if one or more of the following occurs:<br><br>1. The Externally Operated Subordinate CA requests revocation in writing;<br>2. The Externally Operated Subordinate CA notifies the Issuing CA that the original certificate request was not authorized and does not retroactively grant authorization;<o:p></o:p></span></p></blockquote><div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US>Can you highlight/explain why this was limited to "Externally Operated"? I cannot see why these reasonings don't apply to Internally Operated Subordinate CAs as well, due to the above introduction of "or its Affiliate".<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US> <o:p></o:p></span></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'><p class=MsoNormal><span lang=EN-US>5. 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;<o:p></o:p></span></p></blockquote><div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US>This change seems problematic in that it suggests that revocation is not required for Internally Operated Subordinate CAs to comply with the Requirements or the applicable Certificate Policy or Certification Practice Statement.<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US>Can you clarify where the equivalent provision might already exist, or if this is adopted, where it would exist in the new document?<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US> <o:p></o:p></span></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'><p class=MsoNormal><span lang=EN-US>In Section 4.9.9 (On-line revocation/status checking availability)<br><br><br>Replace with:<br><br>OCSP responses MUST conform to RFC6960 and/or RFC5019. OCSP responses MUST either:<br><br>1. 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<br>2. 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.<br><br>In the latter case, the OCSP signing Certificate MUST contain an extension of type id-pkix-ocsp-nocheck, as defined by RFC6960.<o:p></o:p></span></p></blockquote><div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US>One potential problem with this change is that it removes the association of subject naming which previously existed. That is, I'm wondering whether or not this opens the opportunity for an OCSP response to be signed by the same key, but to present a different byName ResponderID within the ResponseData of the BasicOCSPResponse. The language present in 6960 4.2.2.3 states "The purpose of the ResponderID information is to allow clients to find the certificate used to sign a signed OCSP response. Therefore, the information MUST correspond to the certificate that was used to sign the response.", but the change from "signed by the CA" to "signed by the Private Key" arguably leaves it ambiguous as to the associated certificate used to sign a signed OCSP response.<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US>Put differently (since I understand this is subtle)<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US>Imagine Private Key A is associated with Certificate 1 and Certificate 2. Certificate 1's associated Issuer Name is "Foo", Certificate 2's associated Issuer Name is "Bar". At present, I do not believe this is forbidden under the Baseline Requirements (or under this proposal). Under this model, it seems that I potentially could issue a certificate whose issuer is Certificate 1 ("Foo"), but then create an OCSP response with responderID byName of "Bar", and then sign with Private Key A.<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US>Under 6960, this meets the definition that "the information MUST correspond to the certificate that was used to sign the response" - since Certificate 2 was 'used' to sign the response, using Certificate 1's Private Key.<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US>Have I missed somewhere in the intersection of this Ballot, the existing Baseline Requirements, and 6960 where this scenario (as insane as it is) is prohibited?<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US> <o:p></o:p></span></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'><p class=MsoNormal><span lang=EN-US>In Section 4.9.10 (On-line revocation checking requirements)<br><br><br>* Replace the first sentence with "Each CA SHALL support an OCSP capability using the GET method for Certificates issued in accordance with these Requirements".<br>* 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."<o:p></o:p></span></p></blockquote><div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US>This changes a MUST NOT into a SHOULD NOT, and a SHOULD NOT into a MAY, although I believe unintentionally. <o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US>The current MUST NOT is derived from two sentences in the existing language:<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US>"If the OCSP responder receives a request for status of a certificate that has not been issued, then the responder SHOULD NOT respond with a "good" status."<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US>"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"<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US>Combined, that makes it a MUST NOT for non-TCSCs, and SHOULD NOT for TCSCs.<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US>With this new language, it becomes<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US>"If the OCSP responder receives a request for status of a certificate that has not been issued, then the responder SHOULD NOT respond with a "good" status."<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US>"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."<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US>By removing the MUST NOT, non-existent certs from non-TCSCs fall into the first clause, which is SHOULD NOT.<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US>Further, by stating 'exempt from this prohibition', for TCSCs, this moves the SHOULD NOT into nothingness (effectively, a 'MAY')<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US>As per RFC 2119, "SHOULD NOT" is equivalent to "NOT RECOMMENDED (but allowed)", while MUST NOT (aka "SHALL NOT") means an absolute prohibition.<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US>Was this intentional?<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US> <o:p></o:p></span></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'><p class=MsoNormal><span lang=EN-US>In Section 5.4.1 (Types of events recorded)<br><br><br>Replace subsections 1 and 2 in the second paragraph of so that they read:<br><br>The CA SHALL record at least the following events:<br><br>1. Private Key lifecycle management events for the Root CA Certificate or Subordinate CA Certificate, including:<o:p></o:p></span></p></blockquote><div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US>Does this mean items A and B are removed, or was it proposed to leave them in place? The language is ambiguous, given the text below.<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US> <o:p></o:p></span></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'><p class=MsoNormal><span lang=EN-US><br>2. Certificate lifecycle management events for the Root CA Certificate, Subordinate CA Certificate, and Subscriber Certificates, including:<br><br>a. Certificate requests, renewal, and re-key requests, and revocation;<br>b. All verification activities stipulated in these Requirements and the CA's Certification Practice Statement;<br>c. Date, time, phone number used, persons spoken to, and end results of verification telephone calls;<br>d. Acceptance and rejection of certificate requests; Frequency of Processing Log<o:p></o:p></span></p></blockquote><div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US>Was this a typo? Can you explain what "Frequency of processing log" is meant to be in this context?<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US> <o:p></o:p></span></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'><p class=MsoNormal><span lang=EN-US>e. Issuance of Certificates; and<br>f. Generation of Certificate Revocation Lists and OCSP entries.<br><br><br>In Section 6.1.1.1 (CA Key Pair Generation)<br><br><br>Replace the first two paragraphs with the following:<br><br>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:<br><br>1. prepare and follow a Key Generation Script,<br>2. have a Qualified Auditor witness the Key Pair generation process or record a video of the entire Key Pair generation process, and<br>3. 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.<br><br>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:<o:p></o:p></span></p></blockquote><div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US>Why does this not use the term Internally Operated Subordinate CA? It would seem that this would be semantically accurate and correspond to the (ii) above to completely cover the set of Sub CA Certificates.<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US> <o:p></o:p></span></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'><p class=MsoNormal><span lang=EN-US><br>1. prepare and follow a Key Generation Script and<br>2. have a Qualified Auditor witness the Key Pair generation process or record a video of the entire Key Pair generation process.<br><br>In all cases, the CA SHALL:<br><br>1. generate the Key in a physically secured environment as described in the CA's Certificate Policy and/or Certification Practice Statement;<br>2. generate the Key using personnel in trusted roles under the principles of multiple person control and split knowledge;<br>3. 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;<br>4. log its Key generation activities; and<br>5. 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.<o:p></o:p></span></p></blockquote><div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US>This again is a subtle but important change. Under the existing language, keys plural is used, to indicate that it is a Key Pair - of Public and Private keys. The change to "the Key" leaves it ambiguous as to whether this was meant to be "the Key Pair", "the Public Key", or "the Private Key".<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US>The fact that 5 specifically states Private Key, but 1-4 does not, further amplifies this confusion as to whether the omission was intentional.<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US> <o:p></o:p></span></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'><p class=MsoNormal><span lang=EN-US>Change the title of Section 6.1.7 as "Key usage purposes (as per X.509 v3 key usage field)"<o:p></o:p></span></p></blockquote><div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US>It is not a field. It is an extension.<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US> <o:p></o:p></span></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'><p class=MsoNormal><span lang=EN-US>In Section 6.2.6 (Private key transfer into or from a cryptographic module)<br><br><br>Replace with:<br><br>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.<br><br>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.<o:p></o:p></span></p></blockquote><div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US>Similarly, this creates the scenario where an Internally Operated Subordinate CA is operated with different infrastructure than the audit, at least based on my current understanding about the scope of the engagement not necessarily covering the "Affiliates" portion.<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US>Is there a reason this was reduced in scope and/or can you highlight where the scope is functionally equivalent to the existing text?<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US> <o:p></o:p></span></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'><p class=MsoNormal><span lang=EN-US>In Section 7.1.5 (Name Constraints)<br><br><br>Replace the last paragraph with:<br><br>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.<o:p></o:p></span></p></blockquote><div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US>The preceding paragraph states "Subordinate CA Certificate is not allowed to issue certificates". This change introduces an asymmetry between the two. Was this intentional? Is it significant?<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US> <o:p></o:p></span></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'><p class=MsoNormal><span lang=EN-US>In Section 8.1 (Frequency or circumstances of assessment)<br><br><br>Replace the first paragraph with:<br><br>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 id-kp-anyExtendedKeyUsage [RFC5280] EKU, or the id-kp-serverAuth [RFC5280] EKU.<o:p></o:p></span></p></blockquote><div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US>Is the CA Certificate what is audited? My understanding is that the CP/CPS of the Organization are audited, which includes the operational security of the Private Key and what it signs/issues. I realize this is somewhat of a parallel bug to the existing text, but I'm surprised that the WG did not suggest this should be resolved.<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'><p class=MsoNormal><span lang=EN-US>In Section 8.7 (Self-Audits)<br><br><br>Replace the last paragraph with:<br><br>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.<o:p></o:p></span></p></blockquote><div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US>Much like several other changes mentioned above, this limits the scope of the existing text from "internal or external" to simply "external". Thus it reduces the scope of examination for internally operated subordinate CA certificates, which may be operated by an Afilliate under a distinct CP/CPS. Is that fair to say?<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US> <o:p></o:p></span></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'><p class=MsoNormal><span lang=EN-US>In Section 9.6.1 (CA representations and warranties)<br><br>Replace the last paragraph with:<br><br>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.<o:p></o:p></span></p></blockquote><div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US>Yet another asymmetry between the existing text that appears to introduce a loophole with respect to 'internally operated' subordinate CAs. <o:p></o:p></span></p></div></div></div></div></div></div></div></body></html>