Clarify validation requirements for .arpa

[sleevi]

In zmap/zlint#343, there were questions raised about whether the special use in.arpa and in6.arpa domains may make use of wildcards.

BRs section 3.2.2.6 has special provisions for when the wildcard appears to the left of particular domain labels, and it’s ambiguous whether or not that section is triggered, based on how IANA administers that root zone and delegates to the RIRs.

[dzacharo]

Although the safest approach would be to prohibit issuance to these "special" TLDs, it might be worth considering requiring that:

• for the ip.arpa special TLD all 4 numerical labels (with numbers from 0 to 255) separated by the dot-decimal notation
• for the ip6.arpa special TLD all 32 labels (with hex values only) separated by the dot-decimal notation

MUST be present in the dNSName value.
Of course, this prohibits IPv6 reverse representations to be included in the subject:commonName field.

These "Domain Names" shall be validated by using the validation methods for IP addresses according to section 3.2.2.5, and wildcards shall not be allowed.

Thoughts?

[sleevi]

There seemed strong consensus for forbidding, and there is a compelling argument they are already forbidden as they are registry controlled, so perhaps you can explain the use case more?

It important to explain the “why” - and not just saying “because people might want them” - as it is to figure out the how. The description of the “how” has issues, but if you’d like to articulate the “why”, that might help figure if they’re worth resolving.

[dzacharo]

I was the one who first proposed to forbid this on the call, and there were two more voices on the call that said "ok". We need a lot more discussion to determine if there is broader consensus for this decision.

I am having second thoughts exactly because I am not aware of what might "break" if we forbid this.

Until we discuss more about the use cases (I hope others will come forward to share their experience), we could save some time if you can share your thoughts about any risks with my proposal. I think it would be very useful.

[sleevi]

Thanks for clarifying. I’m not a fan of allowing something difficult to get right because it “might” be useful. I think it remains a better position to start by disallowing it, and if there are CAs with concrete use cases, they can share them so we can discuss. Absent a use case, it’s difficult to respond properly on how to address that use case.

Given we have iPAddress SANs, the use case you seem to be wanting to address is already met.

[dzacharo]

Fair enough 🙂

[enygren]

It's also worth noting that RFC 8738 overloads .arpa as a way to validate IP address certificates,
including sending an {in-addr,in6}.arpa name as the SNI value.
While it uses a separate type ("ip" vs "dns"), it also uses this form as a way to
embed an IP address in SNI. See: https://datatracker.ietf.org/doc/html/rfc8738

Allowing these names to have certs creates some additional ambiguity.

Forbidding certs from having .arpa names also opens up some possibilities for IP address certs:

• It might allow more general use of the .arpa names as a way to indicate an IP address via SNI
• It might allow the {in-addr,ip6}.arpa namespace to be used for CAA records for IP address certs covering IP address prefixes

(Neither of these two items is standardized today, but it may make sense to do so.)

[CBonnell]

According to this Censys query, publicly trusted CAs have not issued any certificates with a .arpa dNSName in 2023: https://search.censys.io/search?resource=certificates&q=parsed.extensions.subject_alt_name.dns_names%3A%2F.%2B%5C.arpa%2F+and+parsed.validity_period.not_before%3A%5B2023-01-01+TO+*%5D. There is always the possibility that such certificates were issued but never logged to CT, but the number of such certificates would be very small.

We should consider prohibiting the issuance of such certificates, especially since the current impact of such a prohibition would be nil.