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 On Fri, Jul 24, 2026 at 8:34 PM Tobias S. Josefowitz <[email protected]> wrote: > > Hi Cynthia, > > On Fri, Jul 24, 2026, 19:39 Cynthia Revström <[email protected]> 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 > -- 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/CAKw1M3OQqpr%2BWZDpb60-YLv-L13iWF-gvPTG%2Bc2kenA7EMWOHA%40mail.gmail.com.
