e164.arpa Usage

[Wayne]

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

[Cynthia Revström]

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

> --
> You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
> To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/e2e3bafd-59c6-432f-b7fe-84c47b1c3f37n%40mozilla.org.

[Tobias S. Josefowitz]

Hi Cynthia & all,

On Tue, 21 Jul 2026, 'Cynthia Revström' via dev-secur...@mozilla.org 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

[Cynthia Revström]

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

[Tobias S. Josefowitz]

Hi Cynthia,

On Fri, Jul 24, 2026, 19:39 Cynthia Revström <m...@cynthia.re> wrote:

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.

Well, you asked, I think. It's not like I intend to focus all my energy on this, but that's what I think.

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 servers 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).

You are actually making my point for me. You are basically saying that a non-web use case you can think of can rely on WebPKI.

My perspective differs. Cooptation of WebPKI has burned us before and already existing cooptation will again and probably does right now, though I can't think of a good example, so maybe not, but as sure as sunrise it will again.

The core issue is that other consumers and RPs outside of web browser usage don't generally seem to be able to keep up with the speed required to keep our users safe when it comes to keeping up with changes in the BRs etc., and when a blocking use case can't just be left hanging out to dry (say pos terminals, or, uh, appmatus), it suddenly requires us to compromise between the security of our uses and not setting the world aflame.

I can respect that you don't share that perspective or consider it relevant, but within it I'd think the argument is valid.

Tobi

[Cynthia Revström]

I'll admit that it was a bad example.

It was just something I kinda tacked on at the end, it was by no means
the main point of my email.

More realistically someone could put a website there as a kind of
public proof of owning a phone number, which is exactly what my
e164.arpa domain has been doing for years. (although not currently
with a valid cert as I haven't renewed it in a while due to a lot of
CAs blocking .arpa)

-Cynthia