<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 21, 2017 at 12:45 PM, Alex Wight (awight) <span dir="ltr"><<a href="mailto:awight@cisco.com" target="_blank">awight@cisco.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="white" lang="EN-US"><div class="gmail-m_7903437104460171403WordSection1"><p class="MsoNormal"><span style="font-size:10pt;font-family:tahoma">Yes, that is the path I'm heading down.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:10pt;font-family:tahoma"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:10pt;font-family:tahoma">I also noticed that in section 3.2.2.4 (Validation of Domain Authorization or Control), it mentions…<u></u><u></u></span></p><p class="MsoNormal"><i><span style="font-size:10pt;font-family:tahoma">"The CA SHALL confirm that, *<u>as of the date the Certificate issues</u>*, either the CA or a Delegated Third Party has validated each Fully</span></i><i><span style="font-size:10pt;font-family:calibri">‐</span></i><i><span style="font-size:10pt;font-family:tahoma">Qualified Domain Name (FQDN) listed in the Certificate…"</span></i><span style="font-size:10pt;font-family:tahoma"><u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:10pt;font-family:tahoma"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:10pt;font-family:tahoma">…which seems to imply that every cert issuance needs to recheck domain authorization/control.</span></p></div></div></blockquote><div><br></div><div>Correct. The reuse of data or documents is permitted, where the data or documents obtained might be, for example, the contents of a file at /.well-known/ that uses a random value.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="white" lang="EN-US"><div class="gmail-m_7903437104460171403WordSection1"><p class="MsoNormal"><span style="font-size:10pt;font-family:tahoma"> But, it then goes on to say…<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:10pt;font-family:tahoma"><u></u> <u></u></span></p><p class="MsoNormal"><i><u><span style="font-size:10pt;font-family:tahoma">"Completed confirmations</span></u></i><i><span style="font-size:10pt;font-family:tahoma"> of Applicant authority <u>may be valid for the issuance of multiple certificates</u> 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."<u></u><u></u></span></i></p><p class="MsoNormal"><span style="font-size:10pt;font-family:tahoma">…which seems to imply that domain authorization/control can be cached along with the rest of the I&A data and reused for subsequent issuance. (I'll leave aside the fact that Section 3.3.1 is completely blank, yet is being referenced here)</span></p></div></div></blockquote><div><br></div><div>Right. Section 3.3.1 is an illustrative, non-exhaustive example. Section 4.2.1 sets the upper-bound, but I suppose some want to argue that even 4.2.1 doesn't apply to the reuse of completed confirmations (were that the case, domain validation would only ever have to be performed once)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="white" lang="EN-US"><div class="gmail-m_7903437104460171403WordSection1"><p class="MsoNormal"><span style="font-size:10pt;font-family:tahoma">Am I correct to assume that the tasks performed to demonstrate domain authorization/control are considered part of the same set of cacheable subscriber identity information and can thus be reused without revalidation as long as it's within the cache window? (I'm pretty sure the answer is yes, but it's conveyed in a bit of a confusing way, in my opinion)</span></p></div></div></blockquote><div><br></div><div>I would say no, and so far, no one else has chimed up :P</div><div><br></div><div><a href="https://cabforum.org/pipermail/public/2017-April/010539.html">https://cabforum.org/pipermail/public/2017-April/010539.html</a> maybe helps answer this?</div><div><br></div><div>You could use this to compare 3.2.2.4.6 vs 3.2.2.4.10, because they actually provide different guidance:</div><div><br></div><div>3.2.2.4.6 - Allowed to use Required Website Content or a Request Token or (Request/Random) Value.</div><div>  - RWC validity period: Bounded by 4.2.1 (it's "data")</div><div>  - RT validity period: Bounded by 4.2.1 (it's "data")</div><div>  - Random Value validity period: Bounded by 3.2.2.4.6, as the longer of 30 days or... the validity period of 4.2.1 (also referencing 3.3.1 as illustrative, but non-exhaustive)</div><div><br></div><div>3.2.2.4.10 - Allowed to use TLS with a Random Value within a certificate</div><div>  - Random Value validity period: Not specified within 3.2.2.4.10, so bounded to the bounds of 4.2.1 (it's "data")</div><div><br></div><div>However, both of these methods' restrictions are made moot by 3.2.2.4, which allows "Completed confirmation" to be reused. However, there is apparently some disagreement about whether or not the "Completed Confirmations" must have been conducted in accordance with 3.2.2.4 at the time it was issued, or whether it's valid to use a "completed confirmation" obtained at any time, ever, in the past (... and whether or not that's bounded by 4.2.1). That's the discussion Gerv and I have been having in <a href="https://cabforum.org/pipermail/public/2017-April/010483.html">https://cabforum.org/pipermail/public/2017-April/010483.html</a></div></div></div></div>