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 _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
