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.
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp