Howdy all, I've been asked to clarify my goal for this thread. The goals was not to talk about web PKI, but instead to discuss ways that a centralized PKI can automatically verify ownership and voracity of a claim to a particular profile (in the previous post: domains, Keybase, App.net, and SKS pools).
Some of the existing centralized PKI rely on manually establishing ownership: CAs for EV certs[1], SKS by emailing Kristian[2]. Others are automatically performed: CAs for non-EV certs[3], Keybase using signatures on social network profiles[4]. Also, there was recently a paper on how to mitigate Sybil attacks on distributed social networks[5]. There seems to be a discord on whether automatic means can be used by a centralized authority to confirm ownership of a profile. For domains, apparently the answer is yes. Is that possible with other ownership-verification systems like keyserver pools, social networks, and messaging networks? Should we insist that profile ownership be established through a manual web-of-trust style personal verification or is a centralized automatic verification enough? -Daniel [1]: https://cabforum.org/overview-of-the-extended-validation-ssl-vetting-process/ [2]: https://sks-keyservers.net/verify_tls.php [3]: https://www.digicert.com/ssl-validation-process.htm [4]: https://keybase.io/docs/command_line [5]: http://isec.uta.edu/mwright/papers/persea-poster.pdf On Mon, Jan 19, 2015 at 3:26 PM, Daniel Roesler <[email protected]> wrote: > 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
