<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 29, 2017 at 7:59 PM, Kirk Hall <span dir="ltr"><<a href="mailto:Kirk.Hall@entrustdatacard.com" target="_blank">Kirk.Hall@entrustdatacard.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 lang="EN-US">
<div class="gmail-m_5523440619418982821WordSection1">
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">I
</span><span style="font-size:11pt;font-family:Calibri,sans-serif">can only respond to two of your questions. 
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif">As to your first question, a third level domain can be referred to as “higher” than a second level domain, and so on:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><a href="https://www.techopedia.com/definition/23811/third-level-domain" target="_blank">https://www.techopedia.com/<wbr>definition/23811/third-level-<wbr>domain</a></span></p></div></div></blockquote><div><br></div><div>Unfortunately, like many random pages on the Internet, it's not correct.</div><div><br></div><div><a href="https://tools.ietf.org/html/rfc1034#section-3.1">https://tools.ietf.org/html/rfc1034#section-3.1</a> outlines the relevant terminology here<br></div><div><br></div><div>Quoting:</div><div><div>The domain name of a node is the list of the labels on the path from the</div><div>node to the root of the tree.  By convention, the labels that compose a</div><div>domain name are printed or read left to right, from the most specific</div><div>(lowest, farthest from the root) to the least specific (highest, closest</div><div>to the root).</div></div><div><br></div><div>Hopefully this makes it clear that the current wording is technically incorrect.</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 lang="EN-US"><div class="gmail-m_5523440619418982821WordSection1"><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif">But I also see places where a third level domain is referred to as “lower” than a second level domain also.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif">I’m not confident our current definitions of Authorization Domain Name and Base Doman Name can be substituted for “higher domain name” without adding unwelcome complications
 – they doesn’t clearly say that once a CA has validated an Authorization Domain Name (which is
<i><u>before</u></i> pruning), the CA can then issue for other FQDNs with more nodes (higher level in my parlance) that are not the original Authorization Domain Name without revetting the new FQDN.  Plus there is the language “the Domain Name used to obtain
 authorization” which introduces a new complication.</span></p></div></div></blockquote><div><br></div><div>I'm not sure how best to address the confusion on your part - I suspect that, much like the use of 'higher level' being incorrect, the confusion you mention may be the result of improper use of terminology.</div><div><br></div><div>We've established that 3.2.2.4 and 4.2.1, as argued, allow for the reuse of validation. If a method explicitly permits an Authorization Domain Name (or Base Domain Name), then the validation (or documents or data) apply to that Authorization Domain Name / Base Domain Name. To argue otherwise would be to argue against the practice of CAs, and I know you're not inclined to do so.</div><div><br></div><div>The point, as it relates, is that 3.2.2.4.1 previously made use of Base Domain Name without invoking the Authorization Domain Name, but this note introduces a normative ambiguity here, hence the highlighting of the concern.</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 lang="EN-US"><div class="gmail-m_5523440619418982821WordSection1">
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif">I agree that we can do more work on this in the future, but for now, I think the Ballot 190 language is clear enough (Ballot 190 says a validated FQDN can be used to issue
 certs “</span><span style="font-size:11pt;font-family:Calibri,sans-serif">for FQDNs for higher level domain levels
<u>that end in the validated FQDN</u>”, so clearly the additional FQDN has to be longer than the validated FQDN, and not shorter). </span></p></div></div></blockquote><div><br></div><div>However, as both the terminology - and it's conflict with (or incompatibility with) authorization domain name - hopefully show, it's actually not clear enough on this point. Worse, it's actually materially incorrect.</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 lang="EN-US"><div class="gmail-m_5523440619418982821WordSection1">
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif">The only other question I can respond to is at the end of your message.  Bear in mind that after Ballots 180/181, many validations over many months were done using new Methods
 1 through 4 and 7 through 9 (as previously approved in Ballot 169) but these only happened under the Method 11 “any other method”, as these were not specifically re-authorized for many months (in fact, they are not specifically re-authorized yet – that’s what
 Ballot 190 is about).  So if we wipe out those prior validations under Method 11, we are eliminating many prior validations that clearly complied with our new Methods 1-10 – something we don’t want to do.  There’s really no way around it.</span></p></div></div></blockquote><div><br></div><div>Sure there is. As has been highlighted since the beginning of the (conflicting) discussion, Section 4.2.1 has allowed - and continues to allow - the reuse of documents and data. Similarly, Section 3.2.2.4's preface allows for the reuse of the validation.</div><div><br></div><div>This means that for those CAs - which, as you note, has been virtually every CA - that have adopted the new validation methods, and if their validation documents and data comply with the post-190 language (meaning that no further complications since 169 have been entered into 190), then they can reuse those documents or data - or previous validations - in full compliance with the BRs.</div><div><br></div><div>The only issue that is created is for those CAs that continued to use an insecure file-based demonstration of control outside of those permitted under 6, or which, such as you have noted for Entrust, failed to maintain an efficient and appropriate record keeping to allow them to determine whether or not they have properly complied with Methods 1-4 and 7-9 in the manner prescribed by 190. It is those CAs - which is a very limited subset, based on public evidence - that would need to do revalidation.</div><div><br></div><div>To put it differently: If a CA has adopted Methods 1-4, or 7-9, as a result of previous discussions, then they would not need to revalidate.</div><div><br></div><div>Hopefully, with this greater clarity, you can see why the issues being introduced with the proposed language changes - issues that pose real risk to the stability and security of the PKI - are issues that can be entirely avoided, and with minor to no inconvenience to CAs that have adopted secure practices.</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 lang="EN-US"><div class="gmail-m_5523440619418982821WordSection1">
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif">Again, I’d suggest we get Ballot 190 passed, then return immediately to address and improve the new language.</span></p><div><div>
</div>
</div>
</div>
</div>

</blockquote></div><br></div><div class="gmail_extra">Respectfully, Ballot 190 presents real security risk. Can you clarify what the 'rush' is? I would have hoped the unfortunate exercise of Ballot 193, Ballot 194, and Ballot 197 would highlight why rushing to get a ballot passed is detrimental to our long term interests.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Similarly, as you can see from the discussions related to Ballot 190, "improve the new language" is equally something that may take two years, so we should be careful to introduce known-flawed and security-risky language, and instead make sure we get it right the first time, as we simply may not have the opportunity - or, as Ballot 192 nearly risked, the quorum - to make much needed and necessary improvements.</div></div>