Hi Tobi, I don't really agree with your argument. Just because I don't think there is a good reason to do it, doesn't mean that we should get rid of it. I can't think of a good reason to have 10 levels of subdomains, yet we allow that.
It also feels weird to bring this up again as it was brought up in SC-86 and it seemed like the decision ended up being to block in-addr.arpa and ip6.arpa but not e164.arpa. Having this discussion again so soon when (as far as I know) very little has changed regarding the circumstances doesn't feel like a sensible use of time. Speculation regarding what the IETF might have plans for in the future also doesn't really feel like proper justification. As I said in my previous email, if I recall correctly the reason to block in-addr.arpa and ip6.arpa was to allow them to be used for CAA records for IP addresses. That is a very concrete and valid use-case and likely the best solution to the problem of CAA for IP addresses. Nothing like that exists for e164.arpa so any comparisons to in-addr.arpa/ip6.arpa seem inappropriate to me. I still haven't heard any real objective argument that isn't very vague speculation. Also I actually just thought of one reason, not a great one, but one nonetheless. If you want to be able to host a SIP server on your phone number, being able to get a publicly trusted TLS server cert would be useful. That is a use case that you can't otherwise accomplish unlike with the rDNS domains (as there you could simply host a server on the IP address itself). I'm not expecting that anyone is going to do that anytime soon but it just shows that I think there are more reasons against blocking e164 than rDNS domains and fewer reasons for blocking it. -Cynthia On Thu, Jul 23, 2026 at 7:17 PM Tobias S. Josefowitz <[email protected]> wrote: > > Hi Cynthia & all, > > On Tue, 21 Jul 2026, 'Cynthia Revström' via [email protected] > wrote: > > > While I will happily acknowledge that I don't think there's really any > > good reason to do this, I also haven't seen any proper arguments > > against it. > > The arguments against it feel like they mostly come from a place of > > people just not liking it for whatever reason rather than any real > > technical or other objective reason. > > Speaking for myself, I do not like it because, you said yourself, "I don't > think there's really any good reason to do this.". This suggests that > anyone actually using/depending on these certificates (at the time there > were less than a handful of valid, publicly trusted rdns certificates and > none in any way that demonstrated what we might be overlooking when it > comes to good reasons for using those) would be motivated by goals not > aligned with those of WebPKI (as generally seen by Browsers, at least), > and create future roadblocks or impediments when the WebPKI needs to move > to address a threat or an issue but thereby would come into conflict with > the purpose of these certificates. > > ...Like POS terminals & MD5 at the time. > > This logic applies generally to all of .arpa, of course. There has been > some pushback from the general direction of IETF participants, who had > potential future use cases under other parts of the .arpa tree in mind. > IIRC this was never resolved, instead we decided to at least cover rDNS. > > In that spirit, e164.arpa should be added to the list, I'd think, and if > we can identify more parts of the tree for which this is also true, then > they should be added as well. > > Tobi -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAKw1M3ODHPHh5g5e8uufK4oMXTUKT%2BwmKTzY1-tiVE7H8a4aUw%40mail.gmail.com.
