[messaging] What counts as proof of ownership?

[Daniel Roesler]

Howdy all,

Over the weekend, I made a script that gets certificate signing
requests signed by the Let's Encrypt Demo CA[1]. You have to prove to
the CA that you own the domain you're requesting a signature for, so I
spent quite a bit of time digging into the ACME spec for automatically
determining ownership of a domain[2].

So it got me wondering what is considered best practice or ideal for
proving your ownership of a resource? What will create the widest
adoption? What will people trust?

For ACME, there are several challenges that can prove you have control
over the domain:

1. Simple HTTPS - Serve a specific file at a specific domain on port 443
2. DVSNI - Serve a TLS cert with a specific subjectAltName on port 443
3. DNS - Add a specific TXT record to your DNS
4. Email (undocumented, possibly in the future)
5. DNSSEC (undocumented, possibly in the future)
6. WHOIS (undocumented, possibly in the future)

For KeyBase, #1 or #3 is used[3]. For StartSSL, Comodo, and other SSL
cert retailers, #4 and #6 are used[4]. App.net and Google use html
tags to verify ownership (which is not on the ACME list)[5][6]. EV
certificates require a legal entity to be verified[7].

What about other resources? Package managers use PGP keys to sign
packages (yet another method). As far as I know there's not a similar
way to sign javascript libraries that you might serve from a CDN, but
clients could use Subresource Integrity[8] to manually restrict file
hashes. another great use for signed code instead of TLS would be for
keyserver pools like SKS[9].

So what's best? We have a ton of methods for proving ownership of
domains and web content, which makes things very confusing.

-Daniel

[1]: https://github.com/diafygi/letsencrypt-nosudo
[2]: https://letsencrypt.github.io/acme-spec/#rfc.section.6
[3]: https://github.com/keybase/keybase-issues/issues/261
[4]: https://konklone.com/post/switch-to-https-now-for-free
[5]: http://blog.app.net/2013/04/29/announcing-domain-verification/
[6]: https://support.google.com/webmasters/answer/35179?hl=en
[7]: https://cabforum.org/overview-of-the-extended-validation-ssl-vetting-process/
[8]: http://www.w3.org/TR/SRI/
[9]: https://sks-keyservers.net/overview-of-pools.php