I can only respond to two of your questions. As to your first question, a third level domain can be referred to as “higher” than a second level domain, and so on: https://www.techopedia.com/definition/23811/third-level-domain
But I also see places where a third level domain is referred to as “lower” than a second level domain also. 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 before 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. Authorization Domain Name: The Domain Name used to obtain authorization for certificate issuance for a given FQDN. The CA may use the FQDN returned from a DNS CNAME lookup as the FQDN for the purposes of domain validation. If the FQDN contains a wildcard character, then the CA MUST remove all wildcard labels from the left most portion of requested FQDN. The CA may prune zero or more labels from left to right until encountering a Base Domain Name and may use any one of the intermediate values for the purpose of domain validation. Base Domain Name: The portion of an applied‐for FQDN that is the first domain name node left of a registrycontrolled or public suffix plus the registry‐controlled or public suffix (e.g. "example.co.uk" or "example.com"). For FQDNs where the right‐most domain name node is a gTLD having ICANN Specification 13 in its registry agreement, the gTLD itself may be used as the Base Domain Name. 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 “for FQDNs for higher level domain levels that end in the validated FQDN”, so clearly the additional FQDN has to be longer than the validated FQDN, and not shorter). 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. I will leave it to others to respond to your other comments on wording for specific validation methods – but the wording on these methods was worked on and reviewed many times over a two year period. Again, I’d suggest we get Ballot 190 passed, then return immediately to address and improve the new language. From: Public [mailto:[email protected]] On Behalf Of Ryan Sleevi via Public Sent: Thursday, June 29, 2017 11:52 AM To: Ben Wilson <[email protected]>; CA/Browser Forum Public Discussion List <[email protected]> Cc: Mads Egil Henriksveen <[email protected]> Subject: [EXTERNAL]Re: [cabfpub] Pre-ballot for Ballot 190 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). Consider 3.2.2.4.1 as an example. It includes the following draft text: "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." 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. 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 google.com<http://google.com>, the higher level domain is .com), or it is meant to redescribe the process of "Authorization Domain Name", in which I request "www.google.com<http://www.google.com>", I use "google.com<http://google.com>" as the Authorization Domain Name, and thus, the ADN == "validated FQDN". However, this conflicts with the plain reading earlier in the sentence. 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) 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. 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 "[email protected]<mailto:[email protected]>", but then also add "[email protected]<mailto:[email protected]>" in the re-sent message as a CC or BCC, leaving the TO line unmodified - as the recipient ([email protected]<mailto:[email protected]>) remains the same. (Unless we want to haggle over SMTP semantics, despite not stating SMTP be used) 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. T=0: Applicant submits request. CA generates Random Value, Applicant puts it in the TXT. Certificate 0 is created, expires T=1188 (39 months). 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) 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). 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. 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 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. 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 'example.com<http://example.com>'. 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 'example.com<http://example.com>' is authorized, provided that 'example.com<http://example.com>' 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). That is, consider the following: I, the true domain holder, approach CA Foo to issue a certificate for "example.com<http://example.com>", 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 "example.com<http://example.com>". CA Foo attempts to validate using 3.2.2.4.10, and sees that a certificate they previously issued is on example.com<http://example.com>. They then assert that the serial number in that certificate constitutes a "Random Value", thus authorizing Gerv's request, and issuing a certificate for example.com<http://example.com> to Gerv, with a private key Gerv controls. This would be fully permitted under 3.2.2.4.10. 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. 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?
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
