SC-XXX: Cleanup for ADN CNAME use

[richardwsmith]

Removes CNAME language from ADN definition and clarifies the use of FQDNs returned from DNS CNAME lookups to determine the ADN by method in section 3.2.2.4.

[aarongable]

In concert with my proposed definition change above, I would add something like the following language here:

Suggested change

	The CA MAY apply any of the below transformations any number of times, in any order, to derive an Authorization Domain Name from the applied-for FQDN. Some validation methods restrict which transformations are valid to yield an ADN for use in that validation method.
	1. Removing "`*.`" from the left-most portion of the FQDN. If the applied-for FQDN is a Wildcard Domain Name, then the CA MUST perform this transformation first.
	2. Pruning the leftmost Domain Label of the FQDN. If the FQDN is a Base Domain Name, then the CA MUST NOT perform this transformation.
	3. Replacing the FQDN with the FQDN returned from a DNS CNAME lookup of the first FQDN. If the FQDN has already had transformation #2 applied, then the CA MUST NOT perform this transformation.

Then the methods below which do allow CNAME delegation could be left alone, and the methods which disallow CNAME delegation could simply say "The CA MUST NOT use transformation #3 to derive the ADN used for this method."

[jsha]

It's confusing that the first sentence says "any number of times, in any order," but (1) can be performed only once and must be first. And (3) cannot be performed after (2). How about an algorithm style:

The CA MUST follow this process to choose an Authorization Domain Name "ADN" for validation of each applied-for FQDN or Wildcard Domain Name:

1. Initialize ADN to the applied-for FQDN or Wildcard Domain Name.
2. Remove "*." from the left-most portion of ADN, if present.
3. Optionally, if allowed by the validation method, replace ADN with the result of a DNS CNAME lookup of ADN.
4. Initialize BDN to the Base Domain Name of ADN.
5. Optionally, prune N Domain Labels from ADN, from left to right. The CA MUST choose a positive value of N such that BDN is either a suffix of or equal to the resulting ADN.

[aarongable]

I like that rewrite a lot.

[richardwsmith]

I like the direction, but I think it may be adding a more strict ruleset than is there currently, which I'm not totally opposed to, but I also think it may be more strict than needed and unnecessarily burden Subscribers.

[jsha]

What's an example of a use case that this would prohibit that is currently allowed? Pruning labels first, and then following a CNAME and setting ADN to the result?

[jsha]

setting the CNAME at the Base Domain level of the requested FQDN

This doesn't work, because the Base Domain needs NS records (it is always a zone cut), and NS records cannot coexist with a CNAME. Or as more commonly put, "no CNAMEs at the apex of a domain."

https://www.rfc-editor.org/rfc/rfc2181#section-10.1

An alias name (label of a CNAME record) may, if DNSSEC is in use, have SIG, NXT, and KEY RRs, but may have no other data.

(emphasis mine)

[jsha]

By the way, the use case you describe (verifying an entire domain in one go) is easily satisfied by:

1. CA chooses ADN = Base Domain (no CNAME chasing)
2. Subscriber puts a Random Value or Request Token in a TXT record for the ADN.
3. CA performs "3.2.2.4.7 DNS Change" for the ADN.
4. For any subsequent requests, e.g. some.subdomain.example.com, the CA again chooses ADN = Base Domain, and sees that there is a previous validation it can rely on.

[dzacharo]

setting the CNAME at the Base Domain level of the requested FQDN

This doesn't work, because the Base Domain needs NS records (it is always a zone cut), and NS records cannot coexist with a CNAME. Or as more commonly put, "no CNAMEs at the apex of a domain."

https://www.rfc-editor.org/rfc/rfc2181#section-10.1

An alias name (label of a CNAME record) may, if DNSSEC is in use, have SIG, NXT, and KEY RRs, but may have no other data.

(emphasis mine)

CNAMEs at the BDN are not allowed as you correctly explained but what about the case of 3.2.2.4.7 which allows the ADN to have a label starting with an underscore?

2. an Authorization Domain Name that is prefixed with a Domain Label that begins with an underscore character

If the BDN is example.com the domain owner could create a CNAME entry of _foo.example.com and point to delegated.myhostingprovider.com. Validating delegated.myhostingprovider.com with 3.2.2.4.7 would effectively validate the entire Domain Namespace of example.com.

Is this correct?

[aarongable]

Ugh, that's a mess.

How I think this should work is that _foo.example.com is not an ADN. It is "an ADN prefixed with a domain label that begins with an underscore"; i.e. the ADN is still example.com. Following a CNAME from _foo.example.com would be part of the validation process, just like following HTTP 3XX redirects is part of the Agreed-Upon Change To Website validation process, but it would not be part of deriving an ADN.

[dzacharo]

Right. The way 3.2.2.4.7 is written, indicates that the "ADN" and "ADN prefixed with...." are treated equally. I'm not sure if this was intended to be a "solution" to the restriction described by @jsha in #619 (comment).

My point is that a Domain Owner can redirect control of a BDN (example.com) to another Domain Owner using CNAME. The CA will follow the validation process starting with either and "ADN" or an "ADN prefixed with..." and follow aliases (CNAMEs) as needed.

[jsha]

It's confusing that the first sentence says "any number of times, in any order," but (1) can be performed only once and must be first. And (3) cannot be performed after (2). How about an algorithm style:

The CA MUST follow this process to choose an Authorization Domain Name "ADN" for validation of each applied-for FQDN or Wildcard Domain Name:

1. Initialize ADN to the applied-for FQDN or Wildcard Domain Name.
2. Remove "*." from the left-most portion of ADN, if present.
3. Optionally, if allowed by the validation method, replace ADN with the result of a DNS CNAME lookup of ADN.
4. Initialize BDN to the Base Domain Name of ADN.
5. Optionally, prune N Domain Labels from ADN, from left to right. The CA MUST choose a positive value of N such that BDN is either a suffix of or equal to the resulting ADN.

[defacto64]

Reflecting on this topic, this doubt came to mind:

if domain A "points" to domain B via a CNAME, and on domain B the CA finds what they expect to find—and consequently the Applicant has demonstrated control of A—is it correct to assume that the Applicant also has control of B? This seems obvious to me, therefore I believe it's entirely acceptable for a TLS certificate requested for A to also include domain B in its SAN extension, in such a circumstance. However, I don't see the BRs saying anything explicit about this... perhaps because it's unnecessary ?

What's your take?

[aarongable]

if domain A "points" to domain B via a CNAME, and on domain B the CA finds what they expect to find—and consequently the Applicant has demonstrated control of A—is it correct to assume that the Applicant also has control of B? This seems obvious to me, therefore I believe it's entirely acceptable for a TLS certificate requested for A to also include domain B in its SAN extension, in such a circumstance. However, I don't see the BRs saying anything explicit about this... perhaps because it's unnecessary ?

This depends on the validation method. For example, if doing validation under "3.2.2.4.19 Agreed-Upon Change to Website - ACME", definitely not. The BRs require that the validation be done as described by RFC 8555, and that RFC binds the random token only to Domain A. In order to validate Domain B, a different random token would need to be used. I think the same applies to all of the random token-based methods: reusing a random token across multiple domains feels like those latter validation weren't using a "random" token at all.

[jsha]

There are two questions @defacto64:

1. In what scope must the Random Value be unique?

This is, as Aaron said, different by validation method. For instance [3.2.2.4.7 DNS Change](https://cabforum.org/working-groups/server/baseline-requirements/requirements/#32247-dns-change] says "If a Random Value is used, the CA SHALL provide a Random Value unique to the Certificate request." 3.2.2.4.13 Email to DNS CAA Contact says "The Random Value SHALL be unique in each email." This could probably use some cleanup separately.

2. Can the CA treat successful validation of domain A as successful validation of domain B, given that there is a CNAME relationship?

That's the language we're trying to clear up here. In the current BRs, under the Authorization Domain Name definition "The CA may use the FQDN returned from a DNS CNAME lookup as the FQDN for the purposes of domain validation." So yes, a CA could use domain B as the ADN for a request for domain A and perform validation that way.

Under the language I've proposed here (https://github.com/cabforum/servercert/pull/619/files#r2389541048), the CA would do step 3, "Optionally, if allowed by the validation method, replace ADN with the result of a DNS CNAME lookup of ADN."

Perhaps a third question is: can a CA consider one validation attempt (for domain A) to "coincidentally" validate other domains encountered (domain B) without making additional validation attempts. Probably better to think of it in terms of the algorithm: the CA validates domain B; subsequently domain B is "used to obtain authorization for" domain A (current BR language).

Though come to think of it, another thing to clarify is that the CNAME lookup is a validation activity itself and is covered by MPIC and logging requirements.

[defacto64]

Thankyou @aarongable and @jsha for your comments, which lead me to believe that my question was not obvious and that some cleanup is really worth doing. Right now, based on current BR language, I am inclined to think that my deduction is correct at least in the non-ACME case, so if this is not in the "spirit" of the BRs it 'd better be clarified.

[jsha]

We talked before about how the validation methods say "FQDN", when they should really say "FQDN or Wildcard Domain".

But actually, I think we can do better: In this PR we should change each of the validation methods that currently say FQDN to say ADN instead. After all, validation methods are always validating an ADN. So the process goes:

1. The CA chooses an ADN for the requested FQDN.
2. The CA validates that ADN.

[timfromdigicert]

We talked before about how the validation methods say "FQDN", when they should really say "FQDN or Wildcard Domain".

But actually, I think we can do better: In this PR we should change each of the validation methods that currently say FQDN to say ADN instead. After all, validation methods are always validating an ADN. So the process goes:

1. The CA chooses an ADN for the requested FQDN.
2. The CA validates that ADN.

Exactly, this is a very succinct and accurate way of describing how this was intended to work.

-Tim

[jsha]

I went ahead and drafted a version with the changes I was suggesting here, and some more on top that seemed to be required for consistency: #627

[jsha]

@richardwsmith how do you feel about continuing collaboration on #627 and closing this one out?