Also, how do I know whether to believe the link to the encryption key? That stuff should be in the HTTPS certificate, not a text file. Just use the server's public key to encrypt communications to the website owners.
Whois is not a good place for this data. Whois data is typically abused by spam bots (and most people don’t look there), it can’t be easily extended with security-specific info (a link to the encryption key? a link to the full security policy?), it works only for the registered domain (you can’t have different whois for maps.google.com and mail.google.com), and some registries might have policies that make it difficult to fetch WHOIS data (eg. by blocking IPs of cloud providers, or by forcing you to go to a website to see full subscriber information).
> it can’t be easily extended with security-specific info
Just put a public key into the address field, for example. More abuse of field names is good because it will keep trip up the bots that use e.g. the address field as a spam mail address or pass it to data brokers.
I'd love to see a data broker say "John Doe lives at === BEGIN PGP KEY === 0xA3243ABC3F... Do you want to dox them? Yes/No" and more spam mailers waste their money attempting to send ad mailers to "=== BEGIN PGP KEY === ..."
This is all done over TLS connections, including the link to the encryption key. So the provenance is already at the certificate level. Using PGP means that this provenance can be increased past that level if required.
I'm sure they'd be very excited if I sent them PGP encrypted email message using a public key extracted from some possibly stale public cert of their http server.
Also, how do I know whether to believe the link to the encryption key? That stuff should be in the HTTPS certificate, not a text file. Just use the server's public key to encrypt communications to the website owners.