<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 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
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.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle19
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1199047242;
mso-list-template-ids:256274744;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1
{mso-list-id:1942687938;
mso-list-template-ids:961165258;}
@list l2
{mso-list-id:2086026529;
mso-list-template-ids:-1762598352;}
@list l2:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l2:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l2:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l2:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l2:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l2:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l2:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l2:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></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=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Thanks a ton Ryan for putting this together. This is great info.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><a name="_MailEndCompose"><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>I agree the BRs are missing a re-use of information section, which is odd because the section exists in the EV Guidelines (11.14.1 and 11.14.2). <o:p></o:p></span></a></p><p class=MsoNormal><span style='mso-bookmark:_MailEndCompose'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></span></p><p class=MsoNormal><span style='mso-bookmark:_MailEndCompose'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>I was planning on circulating the following proposal to sync the two requirement docs once the number of pending ballots declined:<o:p></o:p></span></span></p><p class=MsoNormal><span style='mso-bookmark:_MailEndCompose'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></span></p><p class=MsoNormal><span style='mso-bookmark:_MailEndCompose'>Add the following to 3.3.1 (taken from 11.14.2 of the EV Guidelines):<o:p></o:p></span></p><p class=MsoNormal><span style='mso-bookmark:_MailEndCompose'>A CA may rely on a previously submitted certificate request to issue a new certificate if: <o:p></o:p></span></p><p class=MsoNormal><span style='mso-bookmark:_MailEndCompose'>(1) The expiration date of the replacement certificate is the same as the expiration date of the Certificate being replaced, and <o:p></o:p></span></p><p class=MsoNormal><span style='mso-bookmark:_MailEndCompose'>(2) The Subject Information of the Certificate is the same as the Subject in the Certificate that is being replaced.<o:p></o:p></span></p><p class=MsoNormal><span style='mso-bookmark:_MailEndCompose'><o:p> </o:p></span></p><p class=MsoNormal><span style='mso-bookmark:_MailEndCompose'>Add the following to 4.2.1 (sort of taken from 11.14.1) after the third paragraph: <o:p></o:p></span></p><p class=MsoNormal><span style='mso-bookmark:_MailEndCompose'>If an Applicant has a currently valid Certificate issued by the CA, a CA MAY rely on the prior authentication and verification of: <o:p></o:p></span></p><p class=MsoNormal><span style='mso-bookmark:_MailEndCompose'>(1) The Applicant's identity under Section 3.2.2.1; <o:p></o:p></span></p><p class=MsoNormal><span style='mso-bookmark:_MailEndCompose'>(2) The Applicant’s DBA under Section 3.2.2.2;<o:p></o:p></span></p><p class=MsoNormal><span style='mso-bookmark:_MailEndCompose'>(3) The countryName under Section 3.2.2.3;<o:p></o:p></span></p><p class=MsoNormal><span style='mso-bookmark:_MailEndCompose'>(4) The Applicant’s individual identity under Section 3.2.3; and<o:p></o:p></span></p><p class=MsoNormal><span style='mso-bookmark:_MailEndCompose'>(5) The Applicant’s authorization to issue the Certificate under Section 3.2.5, provided that the CA receives or confirms the request for a Certificate using a Reliable Method of Communication.<o:p></o:p></span></p><p class=MsoNormal><span style='mso-bookmark:_MailEndCompose'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></span></p><p class=MsoNormal><span style='mso-bookmark:_MailEndCompose'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Thoughts?<o:p></o:p></span></span></p><p class=MsoNormal><span style='mso-bookmark:_MailEndCompose'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></span></p><p class=MsoNormal><span style='mso-bookmark:_MailEndCompose'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Jeremy<o:p></o:p></span></span></p><p class=MsoNormal><span style='mso-bookmark:_MailEndCompose'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></span></p><p class=MsoNormal><span style='mso-bookmark:_MailEndCompose'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></span></p><span style='mso-bookmark:_MailEndCompose'></span><p class=MsoNormal><b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>From:</span></b><span 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, April 14, 2017 10:55 AM<br><b>To:</b> CABFPub <public@cabforum.org><br><b>Cc:</b> Ryan Sleevi <sleevi@google.com><br><b>Subject:</b> [cabfpub] How a Certificate Is Issued - the Baseline Requirements Version<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>Peter asked, in <a href="https://cabforum.org/pipermail/public/2017-April/010392.html">https://cabforum.org/pipermail/public/2017-April/010392.html</a> , that I write up how I believe the Baseline Requirements permit a certificate to be issued.<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I will attempt to explain, with supporting citations to the existing Requirements, so that member CAs who disagree with this can provide the relevant Baseline Requirements clauses that may exempt from this.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><ol start=1 type=1><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l1 level1 lfo1'>A Certificate Request is received.<o:p></o:p></li></ol><ol start=1 type=1><ol start=1 type=1><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l1 level2 lfo1'>There is no technical requirement as to the format of the request. It could be a CSR, potentially even one with an invalid signature. It could be a call to an API. It could be a phone call requesting a certificate.<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l1 level2 lfo1'>The request, as used in the BRs, refers to the logical process that aggregates all of the information, and that information may be aggregated over a series of interactions or exchanges. At a minimum, a Request must include a public key, whether explicitly or implicitly (Section 6.1.1.3)<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l1 level2 lfo1'>The CA must archive the request, as well as all data supporting the request, for at least seven years after any certificate issued expires (Section 5.5.2)<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l1 level2 lfo1'>The CA must record that the request was made, all information generated and documentation received in conjunction with the request (Section 5.4.1)<o:p></o:p></li></ol></ol><ol start=2 type=1><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l1 level1 lfo1'>The CA must ensure it has an executed Subscriber Agreement or Terms of Use (Section 4.1.2)<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l1 level1 lfo1'>The request does not need to contain all of the information related to the certificate (Section 4.2.1). If it does not, the CA shall obtain it either from the applicant or a reliable, independent third-party data source which is then confirmed with the applicant.<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l1 level1 lfo1'>The CA must verify every request independent of any past actions (Section 4.2.1, "The CA SHALL establish and follow a documented procedure for verifying all data requested for inclusion in the Certificate by the Applicant.", "The CA MAY use the documents and data provided in Section 3.2 to verify certificate information" - note, active tense)<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l1 level1 lfo1'>The CA may use previously obtained information consistent with that validation, provided that it reverifies that data<o:p></o:p></li></ol><ol start=5 type=1><ol start=1 type=1><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l1 level2 lfo1'>For example, if a certificate request includes the name or address of an organization (Section 3.2.2.1), then the CA may verify that request by using data previously obtained from one of the data sources enumerated therein. The CA MUST verify that the information in the request is consistent with that dataset. For a programmatic verification, this may be as 'simple' as checking an equality check with the existing documents.<o:p></o:p></li></ol></ol><ol start=6 type=1><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l1 level1 lfo1'>The documents and data used MUST be consistent with the policies related to the certificate at the time of issuance.<o:p></o:p></li></ol><ol start=6 type=1><ol start=1 type=1><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l1 level2 lfo1'>For example, if a domain was verified using 3.2.2.4.11, and the data and documents used to support that verification are no longer accepted by the in-force version of the Baseline Requirements, the CA MUST NOT issue the certificate. This is consistent with Section 4.2.1 enumerating that the CA MUST verify the information.<o:p></o:p></li></ol></ol><ol start=7 type=1><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l1 level1 lfo1'>The CA MAY designate a third party to do this verification. This is called a Delegated Third Party (Section 1.3.2)<o:p></o:p></li></ol><ol start=7 type=1><ol start=1 type=1><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l1 level2 lfo1'>All Delegated Third Parties MUST meet the obligations stated within Section 1.3.2<o:p></o:p></li></ol></ol><ol start=7 type=1><ol start=1 type=1><ol start=1 type=1><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l1 level3 lfo1'>They must be qualified per Section 5.3.1<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l1 level3 lfo1'>They must retain all documentation per 5.5.2<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l1 level3 lfo1'>They must abide by the Baseline Requirements at all times<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l1 level3 lfo1'>They must comply either with the CA's CP/CPS or their CA/CPS, which must comply with the BRs<o:p></o:p></li></ol></ol></ol><ol start=7 type=1><ol start=2 type=1><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l1 level2 lfo1'>An Enterprise RA is a Delegated Third Party (Section 8.4, "If a Delegated Third Party is not currently audited in accordance with Section 8 and is not an Enterprise RA", "and the Delegated Third Party is not an Enterprise RA")<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l1 level2 lfo1'>If an Enterprise RA is used, then in addition to the above stipulations, the CA must ALSO ensure<o:p></o:p></li></ol></ol><ol start=7 type=1><ol start=3 type=1><ol start=1 type=1><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l1 level3 lfo1'>The CA confirms that the FQDN is within the Enterprise RA's verified Domain Namespace<o:p></o:p></li></ol></ol></ol><ol start=7 type=1><ol start=3 type=1><ol start=1 type=1><ol start=1 type=1><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l1 level4 lfo1'>While the use of the past-tense "verified" here may imply the use of a previous verification, this would not be consistent with the application of Section 4.2.1 and Section 3.2. The interpretation of this is that the CA must, for every certificate issued by the Enterprise RA, verify that Enterprise RA's domain namespace using one of the methods in Section 3.2, using data and documents that may have been previously obtained (Per Section 4.2.1). The Enterprise RA is thus responsible for verifying the portion of the Domain Namespace beneath that.<o:p></o:p></li></ol></ol></ol></ol><ol start=7 type=1><ol start=3 type=1><ol start=2 type=1><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l1 level3 lfo1'>For every name in the Subject other than the FQDN, the CA MUST ensure, for every certificate, that the name is either that of a delegated enterprise, or an affiliate of the delegated enterprise, or that the delegated enteprise is an agent of the named Subject.<o:p></o:p></li></ol></ol></ol><ol start=7 type=1><ol start=3 type=1><ol start=2 type=1><ol start=1 type=1><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l1 level4 lfo1'>This verification may also be implemented via technical controls as an equality check. For example, that "Document Foo" establishes that Applicant Bar (An Enterprise RA) is authorized for "ABC Co.". Any subsequent certificate requests can compare if the name is "ABC Co.", and if so, has met its obligations with respect to continuous verification and the reuse of information<o:p></o:p></li></ol></ol></ol></ol><ol start=7 type=1><ol start=4 type=1><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l1 level2 lfo1'>Unless the Enterprise RA is audited, the CA must have a Validation Specialist employed by the CA perform ongoing quarterly audits of the greater of one certificate or three percent of certificates issued (Section 8.7)<o:p></o:p></li></ol></ol><ol start=7 type=1><ol start=4 type=1><ol start=1 type=1><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l1 level3 lfo1'>This means all Enterprise RAs should be undergoing an audit performed by the CA's Validation Specialist<o:p></o:p></li></ol></ol></ol><ol start=7 type=1><ol start=5 type=1><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l1 level2 lfo1'>The CA must ensure that Delegated Third Parties, which includes Enterprise RAs, uses a process that provides at least the same level of assurance as the CA's own processes (Section 4.2.1)<o:p></o:p></li></ol></ol><ol start=7 type=1><ol start=5 type=1><ol start=1 type=1><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l1 level3 lfo1'>If a CA implements a domain blacklist, for example, it MUST ensure that Enterprise RAs implement the same domain blacklist<o:p></o:p></li></ol></ol></ol><ol start=8 type=1><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l1 level1 lfo1'>For domain names, and domain names only, "Completed Confirmations of Applicant Authority may be valid for the issuance of multiple certificates over time. In all cases, the confirmation must have been initiated within the time period specified in the relevant requirement (such as Section 3.3.1 of this document) prior to certificate issuance." (Section 3.2.2.4)<o:p></o:p></li></ol><ol start=8 type=1><ol start=1 type=1><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l1 level2 lfo1'>"such as" is illustrative, not exhaustive. As such, despite the relevant section number being incorrect (It's 4.2.1 not 3.3.1), that does not normatively change the requirement<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l1 level2 lfo1'>Individual sections may specify more or less restrictive timelines. This is the discussion related to Ballot 186 in conjunction with 190. The proposed 190, for example, limits the use of a Random Value in 3.2.2.4.4 to 30 days, which thus limits the use, even in the presence of Section 4.2.1<o:p></o:p></li></ol></ol><ol start=8 type=1><ol start=2 type=1><ol start=1 type=1><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l1 level3 lfo1'>Section 3.2.2.4.7 of Ballot 190 attempts to draw an equivalence to 30 days or that permitted by 4.2.1. While repeating the same mistake as the existing text, of referencing Section 3.3.1, it is a non-exhaustive example set, and thus accomplishes the intended goal, even if referencing the wrong section as an example.<o:p></o:p></li></ol></ol></ol><div><p class=MsoNormal>The combination of these means that an acceptable flow is as follows, using Peter's example<o:p></o:p></p></div></div><div><ul type=disc><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l0 level1 lfo2'>Customer contracts with CA for certificates and to establish an Enterprise RA<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l0 level1 lfo2'>Customer and CA negotiate credentials<o:p></o:p></li></ul><ul type=disc><ul type=circle><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l0 level2 lfo2'>The credentials used must conform with the NCSRs if the CA is audited to the NCSRs, because Enterprise RAs are DTPs, and thus the CA's relationship to them is subject to the NCSRs <o:p></o:p></li></ul></ul><ul type=disc><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l0 level1 lfo2'>CA obtains documents that cover evidence of identity (for OV/EV) and evidence of domain control/authorization for customer specified identities and domains<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l0 level1 lfo2'>CA receives application for certificate from Enterprise RA, authentication based on #2<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l0 level1 lfo2'>The CA uses information collection to verify the information in the request<o:p></o:p></li></ul><ul type=disc><ul type=circle><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l0 level2 lfo2'>The CA MUST verify the Enterprise RA is authorized for the Domain Namespace<o:p></o:p></li></ul></ul><ul type=disc><ul type=circle><ul type=square><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l0 level3 lfo2'>This MAY use the previously obtained data and documents. In this case, the CA MUST verify that the requested name matches the data or document as defined in Section 3.2.2.4. This may simply be an equality check using information a Validation Specialist previously entered as data to be associated with the document (Section 4.2.1). For some methods,such as 3.2.2.4.5, the CA MUST ensure it meets the clauses of either (i) or (ii), which are more than 'simple' equality checks. <o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l0 level3 lfo2'>OR This MAY reuse a completed confirmation of applicant authority, provided if and only if the applicant authority is consistent with the then-current Section 3.2.2.4 (Section 3.2.2.4), for (at present), a period of up to 39 months, unless that period is reduced a specific clause within Section 3.2.2.4.*, such as 3.2.2.4.6 (Section 3.2.2.4, Section 4.2.1, Section 3.2.2.4.*)<o:p></o:p></li></ul></ul></ul><ul type=disc><ul type=circle><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l0 level2 lfo2'>The CA MUST verify domain name is within the authorized Domain Namespace (Section 1.3.2)<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l0 level2 lfo2'>The CA MUST confirm that the Subject information, if any, meets the requirements of Enterprise RA authority (Section 1.3.2)<o:p></o:p></li></ul></ul><ul type=disc><ul type=circle><ul type=square><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l0 level3 lfo2'>This MAY use previously obtained data and documents. In this case, the CA MUST verify the requested Subject name matches the data or documents as defined in Section 3.2. This may simply be an equality check using information a Validation Specialist previously entered as data to be associated with the document (Section 4.2.1)<o:p></o:p></li></ul></ul></ul><ul type=disc><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l0 level1 lfo2'>If verified, issues certificate<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l0 level1 lfo2'>Every quarter, a Validation Specialist at the CA verifies the greater of one certificate or three percent of the certificates issued by the Enterprise RA to assess compliance with the contract and CP/CPS (Section 8.7), including restrictions on identifying and verifying High Risk Requests (Section 4.2.1)<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l0 level1 lfo2'>The Enterprise RA MUST maintain all documentation for a period of at least seven years since the last certificate expired (Section 1.3.2, Section 5.5.2)<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l0 level1 lfo2'>The Enterprise RA MUST ensure all of its personnel involved in issuance have had their identity and trustworthiness verified (Section 1.3.2, Section 5.3.1)<o:p></o:p></li></ul><div><p class=MsoNormal><o:p> </o:p></p></div></div><div><p class=MsoNormal>Here's the important takeaways:<o:p></o:p></p></div><div><ul type=disc><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l2 level1 lfo3'>There's nothing (that I can tell) to support the idea that a previously Completed Confirmation of Applicant Authority may be re-used if the previous method is no longer permitted under the current BRs<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l2 level1 lfo3'>There's nothing (that I can tell) to support the idea that for non-domain related changes, you can 'reuse' the previous verification. You must reverify the information, however, the act of reverifying may simply be a programatic check of the Validation Data associated with a previous request<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l2 level1 lfo3'>There's nothing (that I can tell) to support that you can obtain the data prior to an Applicant making a Certificate Request. The applicant may include that information in their request. Alternatively, the CA may get that information from a reliable, independent, third-party source after the Request is made, but must confirm that with the Applicant (per Section 4.2.1). This implies that a CA who obtains the information before the Request is no longer obtaining it from a reliable, independent, third-party source, but from a first-party source. This is perhaps an area of disagreement regarding the agreement between "the CA SHALL, ... or, having obtained..." as to whether the 'obtained' is allowed to precede the application.<o:p></o:p></li></ul></div></div></div></body></html>