Hi,

I will start out by saying that I believe I was the first one to get a
publicly trusted TLS server cert for a domain under e164.arpa back in
2018 (and only one up until last year) if crt.sh is to be believed.

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.

Correct me if I'm wrong, but I believe the reasoning to disallow
ip6.arpa and in-addr.arpa was primarily to be able to use them for CAA
records for the IP addresses that they correspond with.
That is not relevant for phone numbers currently and I would be
surprised if it is anytime in the near-ish future.

CAs are also of course allowed to decide not to issue to any domains
under .arpa if they don't want to deal with this.
This was pretty much exactly what DigiCert did in 2019 after I managed
to get a cert issued for 1.0.168.192.in-addr.arpa. (I think they
didn't entirely block it but require explicit IANA approval if I
recall correctly)

I feel like we should not spend our time creating policies concerning
a miniscule number (currently 68 according to crt.sh) of certificates
that don't actually present any technical or security issues.

If there is any kind of technical or real objective reasoning for
blocking them then please inform me.

-Cynthia

On Tue, Jul 21, 2026 at 7:24 PM Wayne <[email protected]> wrote:
>
> There have been ongoing questions privately with regards to issuance of a 
> e164.arpa domain. This is not against the BRs, but the definition of Reverse 
> Zone Domain there is narrowed to ipv4/6.
>
> SHA256: e0388e2582f2d657614b75dea820b3e865b55ac3060eb6e5918330773c2a98a3
> Censys crt.sh
>
> I have similar concerns as stated by Corey Bonnell in the Ballot discussion. 
> The visible public discussion moves from forbidding all of .arpa to only 
> rDNS, but there is no explanation for the narrow scope of ipv4/6.
>
> For those unaware e164.arpa is a reverse lookup to a telephone in the same 
> manner as ipv4/6 reverse lookups. I do not see why any of the validation 
> concerns do not equally apply to this method.
>
> What is everyone's opinion?
>
> - Wayne
>
> --
> 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/e2e3bafd-59c6-432f-b7fe-84c47b1c3f37n%40mozilla.org.

-- 
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/CAKw1M3N_a%3DPc65NdCqtRxPwW7NMsr5P0h1A7Hy6BbpwP%3Djv1GA%40mail.gmail.com.

Reply via email to