I never said certificates are "useless". I am commenting only on this one IP address and one specific use of it, downloading zone files. How do you extrapolate that to be a general statement about certificates.
In this case you are downlaoding a file that is served at a number of other known, unchanging IP addresses, "root servers." Even more, the RRs in the file have been signed, "DNSSEC".
All I am saying is that a "bare IP address" in this case is still useful, even without a domain name and certificate.
> I never said certificates are "useless". I am commenting only on this one IP address and one specific use of it, downloading zone files.
I meant useless in this scenario. So same.
> All I am saying is that a "bare IP address" in this case is still useful, even without a domain name and certificate.
What? Then we don't disagree at all. You need to reread my earlier comments. I said a certificate with a name is better than a certificate with an IP. I never said anything about the value of the IP address itself, only what's validated.
"I said a certificate with a name is better than a certificate with an IP."
I think that's debatable. IMO, it depends in part on the perceived value of the ICANN "domain name business" as some sort of vetting mechanism. In this case the party being vetted is ICANN itself. Although they did pay for "EV".
Here is a question for the TLS certificate fanatics: Why do CAs provide non-http URLs to their CA certificates in the certificates they sell. For example,
I suspect it is a bootstrapping issue. At the top of the chain there is some notion of implict trust. No different than with DNS. Trust should be decided by the end user not by developers, nor by some self-appointed "authority".
In this case you are downlaoding a file that is served at a number of other known, unchanging IP addresses, "root servers." Even more, the RRs in the file have been signed, "DNSSEC".
All I am saying is that a "bare IP address" in this case is still useful, even without a domain name and certificate.