SC-XXX: Clarify Authorization Domain Name (alternative to #619) #627
Conversation
Simplify the definition of ADN and move the algorithm in 3.2.2.4. Define Base Domain Name as a function of any given FQDN. Move the definition of Domain Contact into the only remaining method that uses it. Simplify the language in each method around pruning labels and wildcard issuance. Add corresponding language about following CNAMEs when choosing the ADN, and around onion issuance. Use "ADN" consistently in method definitions instead of "FQDN" (which is insufficiently precise as to whether it's the applied-for FQDN or the ADN). Clean up the language in the onion section around ADNs. Replace retired methods with language saying they are retired.
aarongable
changed the title
|
I pushed a change breaking out the ADN algorithm into two parts: one where the input is an FQDN and one where the input is a Wildcard Domain Name. The goal of this update is to forbid CNAME lookups when choosing the ADN, if the input was a Wildcard Domain Name. The intuition is that CNAMEs delegate control of a single FQDN and do not imply anything about control of subdomains. When validating |
Also, reuse more of existing pruning language.
|
Updated once more to reflect CNAME-or-prune semantics. I described my thinking in cabforum/definitions#5 (comment). This allowed simplifying things somewhat. I also reverted some of the new description of pruning to use more of the old language, which was fine. |
|
Maybe it's just me and my reading comprehension skills, but I do have a couple comments after reading the proposed verbiage here. If this is way off base, feel free to ignore! First, it seems like the intersection of allowances with the algorithm for choosing an ADN is complex and leaves room for ambiguity. For example, perhaps under 4 it would be worth explicitly stating that following CNAMEs is not allowed for selecting ADNs on Wildcard Domains regardless of if the method allows it or not. Second, further down in the text, there are references to ADNs that aren't clear whether they should be referring to an ADN that was selected from following a CNAME or not. An example of what I mean follows. Under 3.2.2.4.7, we see this heading: Under the ADN selection algorithm provided, however, this ADN could be my domain, a base domain of my domain, or a CNAME that one of those domains pointed to. Is this meant to allow the following condition? Similarly, under 3.2.2.4.4 the ADN is referenced multiple times as the target of the constructed email domains, suggesting in the above example that the emails would/should be send to the target of the CNAME domain (but in this case I assume no pruning would be allowed, therefore the emails would necessarily be to addresses like Again, if I'm just way off base here and these elements seem clear and unambiguous to others, then I can be safely ignored. I simply wanted to point out some items that I had questioned as I was reading through the proposed change. |
Good point. I'll have a think about the clearest way to express this. Ideally the validation methods would say something like "this has property
My goal in writing this is that, once the ADN is selected, the validation method shouldn't have any dependency on how it was selected (i.e. whether a CNAME was followed).
This example uses prune-then-CNAME, which IMO should not be allowed because it doesn't follow the actual semantics of control in DNS. The operator of Perhaps you meant to ask about a situation like this? In this example, the CA would be selecting The idea being that it's better for CNAME following to happen automatically as part of the normal DNS operations that occur during validation. So in this example, there could be
This is why CNAME-then-prune is convenient for subscribers. In my example above, if the validation method is "3.2.2.4.4 Constructed Email to Domain Contact," the CA would be allowed to first follow the single CNAME, resulting in |
Allow CNAME following for DNS Change
|
@cardonator thanks again for the feedback. To clear up the question of CNAME following during validation of a wildcard certificate, I moved the prose allowances ("This method allows CNAME lookups when choosing the ADN") into a table right next to the ADN algorithm. I also gave "3.2.2.4.7 DNS Change" a checkmark in the CNAME column - after thinking about the underscore-prefixed variant, I concluded that disallowing CNAMEs for this method would rule out some validations that were previously allowed and that were semantically valid in terms of how DNS assigns control. |
4 participants
Simplify the definition of ADN and move the algorithm in 3.2.2.4. Choosing an ADN is a precursor to doing validation. Every validation operates on an ADN.
Simplify the language in each method around pruning labels and wildcard issuance. Add corresponding language about following CNAMEs when choosing the ADN, and around onion issuance.
Require record keeping when choosing the ADN.
Replace retired methods with language saying they are retired.
Define Base Domain Name as a function of any given FQDN.
Move the definition of Domain Contact into the only remaining method that uses it (3.2.2.4.12 Validating Applicant as a Domain Contact). Note that this method does not allow CNAME lookups when choosing the ADN, because it previously relied on Base Domain Name, which previously had the language "applied-for FQDN".
Use "ADN" consistently in method definitions instead of "FQDN" (which is insufficiently precise as to whether it's the applied-for FQDN or the ADN).
Clean up the language in the onion section around ADNs.
Here's a table of the methods and what ADN operations can happen on them according to this PR (plus onion issuance):
This is a more in-depth follow-up to #619. It's bigger than I had hoped, but pulling on one thread pulls on many others.