Subject: [openpgp] Supporting services beyond email as uid

From: kellerfuchs <[email-masked]>
Date: Sun, 24 Jan 2016 19:39:01 +0000

Hello,

I couldn't help but notice a usecase that is gaining interest fast,
  yet seems to have been conspicuously absent from the WG's discussions:
  tying not an email address, but another kind of account (typically,
  so-called “social media”) to the OpenPGP key.

I believe this is relevant for two main reasons:
- enabling authenticated/encrypted communication over those services;
  this is the most immediate use, but perhaps not the most relevant;
- enabling people to establish secure communication channels with other
  users of such service; in that case, the identity they want to link to
  a key is not a (name, email) pair but a (username, service) pair.

A popular implementation of this is keybase.io, which make users publish a
  signed, parseable claim of ownership of the account in some location
  where only the account holder (and the service provider) can publish.

Unfortunately, keybase.io does so by acting as a central database[0] where
  users can publish URLs to the proofs of ownership.

However, I believe it should be possible to support that usecase without
  relying on a third-party database, by extending the notion of uid
  beyond mail addresses.  I would feel natural to use URIs there (or a
  subset thereof), as they work for designating a variety of things
  a user might wish to associate with their identity.

This makes verifying the ownership of an uid harder: in the case of email,
  it is done safely (by tools such as `caff`) by sending the signature as
  an encrypted email.  In our case, the 'acct' scheme is only an abstract
  identifier, and does not specify how to interact with the service.

It would be possible to specify the use of a given protocol, such as
  Web Finger [RFC 7033], to obtain the proof of ownership for the account.
  On the other hand, that solution would require active cooperation from
  the service, whereas the current, adhoc solution does not.

Moreover, certain services have strong size limitations, which would not
  allow publishing complete signed proofs of ownership (assuming we do not
  require the service to implement Web Finger or somesuch).  That can be
  handled by storing only a hash of the proof on the service, and either
  storing the proof as a key packet or storing a URL where the proof can
  be fetched.  In both cases, I do not believe it can be done for the
  current OpenPGP spec.

I hope this mail was readable, I'm afraid it has quite a bit of content.

Please take it as a request to discuss whether broadening the notion of
  uids would be relevant, what would be the “right” thing to use as a uid
  and how to actually check the validity of an uid.

Best regards,

  Keller Fuchs

[0]: I am aware that keybase now publishes their database in the Bitcoin
     blockchain.  keybase still acts as the single publisher for it,
     so this doesn't address the issues raised here.