[messaging] What counts as proof of ownership?

[Daniel Roesler]

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 <diafygi at gmail.com> 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