<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 17, 2017 at 12:17 PM, Kirk Hall via Public <span dir="ltr"><<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="m_-6506663678236423459WordSection1">
<p class="MsoNormal">Jeremy, Gerv, and I have worked on this revised version of Ballot 190, and offer it for comment as a preballot.
<u></u><u></u></p>
<p class="MsoNormal">A few points to highlight.<u></u><u></u></p>
<p class="m_-6506663678236423459MsoListParagraph"><u></u><span>-<span style="font:7.0pt "Times New Roman"">
</span></span><u></u>There is now a new fifth paragraph in the introductory part of BR 3.2.2.4 that requires CAs to maintain a record of which domain validation method they use (including version number) for each validated domain. This is to add more flexibility
in the future if methods must be changed and existing domains revalidated for some reason.<u></u><u></u></p>
<p class="m_-6506663678236423459MsoListParagraph"><u></u><span>-<span style="font:7.0pt "Times New Roman"">
</span></span><u></u>The new sixth paragraph clarifies that domains validated prior to the effective date of Ballot 190 are not required to be revalidated, but the validation data can be reused for the periods specified in BR 4.2.1 and EVGL 11.14.3.
<u></u><u></u></p>
<p class="m_-6506663678236423459MsoListParagraph"><u></u><span>-<span style="font:7.0pt "Times New Roman"">
</span></span><u></u>We also have added a line to each validation method indicating whether or not the validation method is suitable for wildcard certificates.</p></div></div></blockquote><div>In most specifications, certainly the majority of those related to the Web Platform, "notes" are non-normative 'suggestions'. That is, they're not even "SHOULD" level, to use RFC 2119 terminology - they're non-binding clarifications of intent.</div><div><br></div><div>As such, it's unclear what the intended outcome of this is. Is it meant to be binding on CAs? If so, we should look to be more explicit.</div><div><br></div><div>It's also unclear whether the 'intent' of the wildcard certificate was also to encompass the validation of subdomains, or their use in Authorization Domain Names.</div><div><br></div><div>As much as I think this is an exciting and worthwhile contribution, similar to my recent remarks to Jeremy, I think there's substantial technical detail and nuance to merit splitting out those changes.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="#0563C1" vlink="#954F72"><div class="m_-6506663678236423459WordSection1">
<p class="MsoNormal" style="line-height:normal;background:white">
<span lang="EN" style="font-family:"Times New Roman",serif">7) Edit Section 3.2.2.4.6:<u></u><u></u></span></p>
<p class="MsoNormal" style="line-height:normal;background:white">
<b><span lang="EN" style="font-family:"Times New Roman",serif">3.2.2.4.6 Agreed-Upon Change to Website<u></u><u></u></span></b></p>
<p class="MsoNormal" style="line-height:normal;background:white">
<span style="font-family:"Times New Roman",serif">Confirming the Applicant's control over the requested FQDN by confirming <u>the presence of a Request Token or Random Value contained in the content of a file or on a web page in the form of a meta tag</u> <s>one
of the following</s> under the "/.well</span><span style="font-family:"Cambria Math",serif">‐</span><span style="font-family:"Times New Roman",serif">known/pki</span><span style="font-family:"Cambria Math",serif">‐</span><span style="font-family:"Times New Roman",serif">validation"
directory, or another path registered with IANA for the purpose of Domain Validation, on the Authorization Domain Name that is accessible by the CA via HTTP/HTTPS over an Authorized Port<u>. The Request Token or Random Value MUST NOT appear in the request
for the file or web-page. </u> <s>:</s><u></u><u></u></span></p>
<p class="MsoNormal" style="line-height:normal;background:white">
<s><span style="font-family:"Times New Roman",serif">1. The presence of Required Website Content contained in the content of a file or on a web page in the form of a meta tag. The entire Required Website Content MUST NOT appear in the request used to retrieve
the file or web page, or</span></s><span style="font-family:"Times New Roman",serif"><u></u><u></u></span></p>
<p class="MsoNormal" style="line-height:normal;background:white">
<s><span style="font-family:"Times New Roman",serif">2. The presence of the Request Token or Request Value contained in the content of a file or on a webpage in the form of a meta tag where the Request Token or Random Value MUST NOT appear in the request.</span></s><span style="font-family:"Times New Roman",serif"><u></u><u></u></span></p>
<p class="MsoNormal" style="line-height:normal;background:white">
<span style="font-family:"Times New Roman",serif">If a Random Value is used, the CA or Delegated Third Party SHALL provide a Random Value unique to the certificate request and SHALL not use the Random Value after the longer of (i) 30 days or (ii) if the Applicant
submitted the certificate request, the timeframe permitted for reuse of validated information relevant to the certificate (such as in Section 3.3.1 of these Guidelines or Section 11.14.3 of the EV Guidelines).<u></u><u></u></span></p>
<p class="MsoNormal" style="line-height:normal;background:white">
<span style="font-family:"Times New Roman",serif">Note: Examples of Request Tokens include, but are not limited to: (i) a hash of the public key; (ii) a hash of the Subject Public Key Info [X.509]; and (iii) a hash of a PKCS#10 CSR. A Request Token may also
be concatenated with a timestamp or other data. If a CA wanted to always use a hash of a PKCS#10 CSR as a Request Token and did not want to incorporate a timestamp and did want to allow certificate key re</span><span style="font-family:"Cambria Math",serif">‐</span><span style="font-family:"Times New Roman",serif">use
then the applicant might use the challenge password in the creation of a CSR with OpenSSL to ensure uniqueness even if the subject and key are identical between subsequent requests. This simplistic shell command produces a Request Token which has a timestamp
and a hash of a CSR. E.g. </span><span lang="EN-GB" style="font-family:"Times New Roman",serif">echo `date -u +%Y%m%d%H%M` `sha256sum <r2.csr` | sed "s/[ -]//g"</span><span style="font-family:"Times New Roman",serif">. The script outputs:<wbr>201602251811c9c863405fe7675a39<wbr>88b97664ea6baf442019e4e52fa335<wbr>f406f7c5f26cf14f<u></u><u></u></span></p>
<p class="MsoNormal" style="line-height:normal;background:white">
<span style="font-family:"Times New Roman",serif;background:white">The CA should define in its CPS (or in a document referenced from the CPS) the format of Request Tokens it accepts.<u></u><u></u></span></p>
<p class="MsoNormal" style="line-height:normal;background:white">
<u><span lang="EN" style="font-family:"Times New Roman",serif">Note</span></u><span lang="EN" style="font-family:"Times New Roman",serif">:
</span><span style="font-family:"Times New Roman",serif">This method is suitable for validating domains for wildcard issuance.</span></p></div></div></blockquote><div><br></div><div>Why is this permitted for wildcard, but IP are not?</div><div><br></div><div>Speaking from a security perspective, it goes</div><div>3.2.2.4.6 (Website) < 3.2.2.4.10 (Random Value) < 3.2.2.4.9 (Test Cert) < 3.2.2.4.8 (IP) < [everything else that follows]</div><div><br></div><div>As such, it would seem that if 3.2.2.4.8 is prohibited from wildcards, .6, .9 and .10 should also be prohibited.</div><div><br></div></div></div></div>