<div dir="ltr"><div class="gmail_extra">There is confusing language - which can be ambiguous - and then language that may be actively detrimental (that is, the plain reading is a normative change).</div><div class="gmail_extra"><br></div><div class="gmail_extra">Consider 3.2.2.4.1 as an example. It includes the following draft text:</div><div class="gmail_extra">"Note: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for FQDNs for higher level domain levels that end in the validated FQDN. This method is suitable for validating Wildcard Domain Names."</div><div class="gmail_extra"><br></div><div class="gmail_extra">This has a few issues. First, the ability to validate an FQDN by pruning one or more labels is already addressed by the definition of "Authorization Domain Name", which is the domain used for authorization. It's unclear whether this Note is offering an alternative definition (e.g. it is not describing the ADN process) or whether it's meant to be a non-normative statement of ADNs. </div><div class="gmail_extra"><br></div><div class="gmail_extra">In further considering the language, note the specific choice of "higher level domain levels". DNS is a hierarchy, working from a 'top' to 'bottom'. This is why we say "top level domain" (or TLD). The scope of authority flows downwards, not upwards. Thus, the choice of "higher level domain levels" is ambiguous - is it meant to say lower-level, or subordinate, domain levels? As it stands, there can either be no "higher level domain levels that end in the validated FQDN" (that is, if I validated <a href="http://google.com">google.com</a>, the higher level domain is .com), or it is meant to redescribe the process of "Authorization Domain Name", in which I request "<a href="http://www.google.com">www.google.com</a>", I use "<a href="http://google.com">google.com</a>" as the Authorization Domain Name, and thus, the ADN == "validated FQDN". However, this conflicts with the plain reading earlier in the sentence.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Similarly, the statement "This method is suitable for validating Wildcard Domain Names" is either redundant (by virtue of ADNs describing how to validate), or it's redefining (defining a mechanism alternative to ADNs)</div><div class="gmail_extra"><br></div><div class="gmail_extra">My concrete suggestion: Remove the entire "Note" section to avoid the hopefully unintentional ambiguity. This same probably, notably, persists through every "Note" being introduced - in the effort of trying to introduce clarity, it actually introduces conflicting language that either disagrees with the definition of ADN, or redefines it.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">With respect to 3.2.2.4.4, it's worth calling out the ambiguity derived from a plurality disagreement that isn't present in 3.2.2.4.2. That is, 3.2.2.4.4 notes "provided that its entire contents and recipient SHALL remain unchanged", but notes that it may be sent to one or more addresses (in the opening sentence). 3.2.2.2.4.2 resolves this ambiguity by noting that "provided that the communication's entire contents and recipient(s) remain unchanged" - that is, note the plurality "(s)" that provides stronger guidance. A misreading of this, but one which is technically correct, would be that I could send a mail to "<a href="mailto:webmaster@example.com">webmaster@example.com</a>", but then also add "<a href="mailto:ryan@example.com">ryan@example.com</a>" in the re-sent message as a CC or BCC, leaving the TO line unmodified - as the recipient (<a href="mailto:webmaster@example.com">webmaster@example.com</a>) remains the same. (Unless we want to haggle over SMTP semantics, despite not stating SMTP be used)</div><div class="gmail_extra"><br></div><div class="gmail_extra">3.2.2.4.7 also presents an interesting challenge - whether or not it's ambiguous language or intentional. It notes that the Random Value SHALL not be used after "(ii) if the Applicant submitted the Certificate request, the timeframe permitted for reuse of validated information relevant to the Certificate". Consider the following, and determine whether or not this is desired, where T= the particular day.</div><div class="gmail_extra">T=0: Applicant submits request. CA generates Random Value, Applicant puts it in the TXT. Certificate 0 is created, expires T=1188 (39 months).</div><div class="gmail_extra">T=1095: Applicant submits another certificate request. CA is allowed to reused Random Value (as it's within the 4.2.1 window for overall time), thus constituting a newly completed validation. (1095 = 3 years / 36 months). Certificate 1 is created, expires T=1918 (1095 + 27 months)</div><div class="gmail_extra">T=1825: Applicant submits another certificate request. CA is allowed to reuse previously completed validation (as its within the 4.2.1 for completed validations), thus issuing a 27 month certificate (1825 = 5 years / 60 months). Certificate 2 is created, expires T=2648 (1825 + 27 months).</div><div class="gmail_extra"><br></div><div class="gmail_extra">As currently worded, 3.2.2.4.7 allows you to use a single random value - provided the domain holder does not remove the TXT record between T=0 and T=1188 - for approximately 2648 days (or more), or roughly over seven years.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Given the proposed modifications to 4.2.1, simply removing (ii) entirely would suffice, and ensure the Random Value is only used for 30 days, but the completed validation is usable for the time permitted by 4.2.1</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Notably, in the process of reviewing this text, a certain asymmetry stood out with our existing adoption, which likely represents a critical security flaw that should be remediated as soon as possible, or considered in the context of the new methods being introduced.</div><div class="gmail_extra"><br></div><div class="gmail_extra">3.2.2.4.10 - This method does NOT restrict the Random Value duration, as done so in 3.2.2.4.7 or 3.2.2.4.2. This could, for example, allow 'perpetual' authentication. A good example of this would be a CA issuing a certificate for '<a href="http://example.com">example.com</a>'. As 3.2.2.4.10 does NOT require that the Random Value be unique to the certificate request (as done by 3.2.2.4.7 or 3.2.2.4.2), the CA could argue that the serial number constitutes a Random Value that was pre-generated. In this method, a CA could determine that any request for '<a href="http://example.com">example.com</a>' is authorized, provided that '<a href="http://example.com">example.com</a>' continues to serve the same certificate. While I can understand that may be ideal for some CAs looking to validate a subscriber once, and never having to do so again, it opens up an ambiguity that represents a critical security flaw - there's no binding that the Applicant is the same (or that the public key is the same).</div><div class="gmail_extra"><br></div><div class="gmail_extra">That is, consider the following: I, the true domain holder, approach CA Foo to issue a certificate for "<a href="http://example.com">example.com</a>", which they duly issue after validating (using some means other than 3.2.2.4.10). I install this certificate on my domain. At some time later, Gerv, the unauthorized requester, approaches CA Foo, with a new public key, and requests a certificate for "<a href="http://example.com">example.com</a>". CA Foo attempts to validate using 3.2.2.4.10, and sees that a certificate they previously issued is on <a href="http://example.com">example.com</a>. They then assert that the serial number in that certificate constitutes a "Random Value", thus authorizing Gerv's request, and issuing a certificate for <a href="http://example.com">example.com</a> to Gerv, with a private key Gerv controls. This would be fully permitted under 3.2.2.4.10.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Given 3.2.2.4.2 and 3.2.2.4.7 are 'new' to this ballot, we need to decide whether or not it was intentional to require those two use a Random Value "unique to the Certificate request" and whether it should be permitted to remain valid in a confirming response for longer than 30 days from its creation. I would argue that 3.2.2.4.2 and 3.2.2.4.7 do it correctly, and 3.2.2.4.10 is flawed in its security, which is only apparent through the comparison.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Finally, in considering the proposed changes to 4.2.1, it's worth noting that the provision beginning "After the change to any validation method" - as worded, this would permit CAs to continue to use the "Any other method" of validation for another three years. Is it intentional that, after nearly 3 years of discussion, CAs are still permitted to use insecure validations?</div></div>