SC-86 pre-ballot discussion: Sunset the Inclusion of Address and Routing Parameter Area Names
Corey Bonnell
Hello,
As previously discussed in the validation-sc, I am circulating a ballot that sunsets the inclusion of “.arpa” domain names in Subscriber Certificates. The PR is available here: https://github.com/cabforum/servercert/pull/573
I welcome suggestions to improve the ballot, either here on the list or on the PR. I plan on kicking off the discussion period late next week.
Thanks,
Corey
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Purpose of Ballot
The Address and Routing Parameter Area Names top-level domain (“.arpa”) is a component of the Internet infrastructure and is not intended to include hostnames. As a result, it is undesirable to permit the issuance of publicly trusted TLS certificates containing hostnames under “.arpa”. This ballot establishes a sunset on this practice.
Motion
The following motion has been proposed by Corey Bonnell (DigiCert) and endorsed by Clint Wilson (Apple) and Tobias Josefowitz (Opera).
Motion Begins
MODIFY the “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates” (“TLS Baseline Requirements”) based on Version 2.1.4 as specified in the following redline:
Motion Ends
This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:
Discussion (at least 7 days)
Start time: 2025-XX-XX XX:00 UTC
End time: Not before 2025-XX-YY XX:00 UTC
Vote for approval (7 days)
Start time: TBD
End time: TBD
Aaron Gable
--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/DS0PR14MB62168551E33AB53B8F2FD8BB92842%40DS0PR14MB6216.namprd14.prod.outlook.com.
Corey Bonnell
Hi Aaron,
Comments inline.
> In particular, I've seen a stat that several tens of thousands of .arpa names contain CNAME records rather than PTR records
Do you have a source for this? I’d be interested to look.
> As long as browsers are happy to load pages "hosted" at .arpa domain names, then those browsers' root programs should probably allow CAs to issue certificates for those same names.
I’m not sure I agree here. Browsers currently have the capability to connect to localhost via TLS. This is perfectly fine from a feature perspective. However, it is wholly unacceptable for a CA to issue publicly trusted TLS certificates certifying “localhost”. Sunsetting the inclusion of .arpa domain names in publicly trusted certificates is similar: there’s nothing preventing a domain owner from using private PKI to authenticate TLS services pointed to by their reverse zone, but it is an inappropriate (ab)use of Internet infrastructure to use the webPKI to authenticate those services.
This topic has been discussed at length several times over the past few years, and no one has been able to come up with a reason why the practice of allowing .arpa in TLS certificates should continue, despite it being contrary to established guidance.
If anyone has any information for such a use case, that would be appreciated.
Thanks,
Corey
Aaron Gable
Hi Aaron,
Comments inline.
> In particular, I've seen a stat that several tens of thousands of .arpa names contain CNAME records rather than PTR records
Do you have a source for this? I’d be interested to look.
> As long as browsers are happy to load pages "hosted" at .arpa domain names, then those browsers' root programs should probably allow CAs to issue certificates for those same names.
I’m not sure I agree here. Browsers currently have the capability to connect to localhost via TLS. This is perfectly fine from a feature perspective. However, it is wholly unacceptable for a CA to issue publicly trusted TLS certificates certifying “localhost”. Sunsetting the inclusion of .arpa domain names in publicly trusted certificates is similar: there’s nothing preventing a domain owner from using private PKI to authenticate TLS services pointed to by their reverse zone, but it is an inappropriate (ab)use of Internet infrastructure to use the webPKI to authenticate those services.
This topic has been discussed at length several times over the past few years, and no one has been able to come up with a reason why the practice of allowing .arpa in TLS certificates should continue, despite it being contrary to established guidance.
If anyone has any information for such a use case, that would be appreciated.
Dimitris Zacharopoulos (HARICA)
How about changing
**Address and Routing Parameter Area Name**: A Domain Name whose Top-Level Domain is "arpa". Examples: `1.2.0.192.in-addr.arpa` (IP version 4) and `1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa` (IP version 6)
to
**Address and Routing Parameter Area Name**: A Domain Name that ends with the labels "in-addr.arpa" or "ip6.arpa". Examples: `1.2.0.192.in-addr.arpa` (IP version 4) and `1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa` (IP version 6)?
I don't think there is need to remove the definition of "Top-Level Domain" because it's also used in the "Internal Name" definition.
Dimitris.
Aaron
--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.
Corey Bonnell
Hi Dimitris,
> Would it be preferable to only block domain names that end with the labels "in-addr.arpa" and "ip6.arpa" instead of blocking the entire "arpa" TLD?
I don’t think allowing e164.arpa is desirable for the same reason that in-addr.arpa or ip6.arpa are undesirable: the entire .arpa TLD (regardless of the second-level domain) is not intended to include host names. This guidance comes directly from the operator of the .arpa TLD [1], so I don’t think we should be making exceptions that go against the operator’s guidance.
Thanks,
Corey
From: 'Dimitris Zacharopoulos (HARICA)' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Wednesday, May 7, 2025 4:33 AM
To: server...@groups.cabforum.org
Subject: Re: [Servercert-wg] SC-86 pre-ballot discussion: Sunset the Inclusion of Address and Routing Parameter Area Names
On 29/4/2025 1:47 π.μ., 'Aaron Gable' via Server Certificate WG (CA/B Forum) wrote:
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/1a743fdd-92ec-4752-9ece-09bd7ade4e2f%40harica.gr.
Dimitris Zacharopoulos (HARICA)
Please consider the fact that TLS Certificates under the scope of the SCWG are related to Domain Names and IP Addresses (v4 and v6). From that perspective, perhaps it would be more appropriate to block arpa domains associated with IP addresses rather than E.164 numbers.
In any case I'm fine leaving the language as-is :)
Dimitris.
Tobias S. Josefowitz
On Mon, 28 Apr 2025, 'Aaron Gable' via Server Certificate WG (CA/B Forum) wrote:
> Here's a potential spanner in the works: although this ballot is correct
> not act as hostnames, that doesn't mean that the *practice* of .arpa names
>
> In particular, I've seen a stat that several tens of thousands of .arpa
> names contain CNAME records rather than PTR records. And browsers are happy
> to load a webpage at one of those CNAME records. For example, this
> site about important numbers <http://42.157.16.209.in-addr.arpa/>.
Looking at https://crt.sh/?dnsname=.arpa&exclude=expired&group=none, it
seems that this might be very much a non-issue. I did not find any
non-ip6.arpa or non-e164.arpa identities in the non-expired certificates
listed there.
> As long as browsers are happy to load pages "hosted" at .arpa domain names,
> then those browsers' root programs should probably allow CAs to issue
> certificates for those same names. Otherwise the browser is mandating that
> connections to those sites can never be private or secure, which seems
> counter to the purpose of the root program.
>
> It seems like there's a chicken-and-egg problem here. If the goal is to
> make it so that no one can host sites on .arpa names, then yes, someone has
> to be the first mover. Maybe the CA/BF should be that first mover. But in
> general I think I'd prefer it if browsers refused to load such pages and
not used in this way, it feels to me like the chicken-and-egg pretty much
collapses into non-existence. None of the listed, non-expired certificates
for .arpa domain names, from a first glance and random sampling, seems to
indicate that there is any kind of pattern or situation where they are
actually used, and serve a meaningful purpose.
Since it virtually does not happen and there is no indication of any
reasonable use case anyone might depend upon, I think it is immaterial if
browsers still support this or not.
Tobi
Aaron Gable
--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/7afa11bb-03fc-61c2-5526-494c66113de0%40opera.com.
Tobias S. Josefowitz
On Sat, 17 May 2025, 'Aaron Gable' via Server Certificate WG (CA/B Forum) wrote:
> Hi Tobi,
>
> Sorry, I'm confused about what point you're making. You say that you didn't
> find any non-ip6 or non-e164 addresses in that crt.sh list, but my claim
> had nothing to do with which specific foo.arpa subdomains people were
> using. My point was simply that people do intentionally host and advertise
> sites using .arpa domains, and without alternative hostnames available. And
> my point was that browsers are happy to navigate to such sites, seemingly
> making them part of the Web that I'd expect the We PKI to cover.
>
> I don't think this practice is widespread, and I think the total impact of
> passing this ballot will be small. But that impact will exist: real sites
> that have TLS today will be forbidden from ever getting another
> certificate. A small number, to be sure, but real nonetheless.
>
> I simply think that is unfortunate. My personal position is that CAs should
> be able to issue for all publicly-accessible sites that the browsers
> operated by root programs are willing to render. So I think that browsers
> should make the first move here, and stop navigating to these sites.
other hand, since this would seem to affect virtually noone and nothing,
the concerns are more theoretical than practical in this case. And in that
sense, maybe not so relevant.
Tobi
Peter Thomassen
Looking at https://crt.sh/?dnsname=.arpa&exclude=expired&group=none, it
seems that this might be very much a non-issue. I did not find any
non-ip6.arpa or non-e164.arpa identities in the non-expired certificates
listed there.
I don't think this practice is widespread, and I think the total impact of passing this ballot will be small. But that impact will exist: real sites that have TLS today will be forbidden from ever getting another certificate. A small number, to be sure, but real nonetheless.I simply think that is unfortunate. My personal position is that CAs should be able to issue for all publicly-accessible sites that the browsers operated by root programs are willing to render.