[messaging] What counts as proof of ownership?
diafygi at gmail.com
Mon Jan 19 22:34:24 PST 2015
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, SKS by emailing Kristian. Others
are automatically performed: CAs for non-EV certs, Keybase using
signatures on social network profiles. Also, there was recently a
paper on how to mitigate Sybil attacks on distributed social
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?
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. 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.
> 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. For StartSSL, Comodo, and other SSL
> cert retailers, #4 and #6 are used. App.net and Google use html
> tags to verify ownership (which is not on the ACME list). EV
> certificates require a legal entity to be verified.
> 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
> clients could use Subresource Integrity to manually restrict file
> hashes. another great use for signed code instead of TLS would be for
> keyserver pools like SKS.
> So what's best? We have a ton of methods for proving ownership of
> domains and web content, which makes things very confusing.
> : https://github.com/diafygi/letsencrypt-nosudo
> : https://letsencrypt.github.io/acme-spec/#rfc.section.6
> : https://github.com/keybase/keybase-issues/issues/261
> : https://konklone.com/post/switch-to-https-now-for-free
> : http://blog.app.net/2013/04/29/announcing-domain-verification/
> : https://support.google.com/webmasters/answer/35179?hl=en
> : https://cabforum.org/overview-of-the-extended-validation-ssl-vetting-process/
> : http://www.w3.org/TR/SRI/
> : https://sks-keyservers.net/overview-of-pools.php
More information about the Messaging