[messaging] Linked Identities (was: affirmations)

[Vincent Breitmoser]

Hi Daniel,

I am at this point halfway through implementing support in
OpenKeychain. While thinking about it and talking with various people, I
have come to dislike the name "affirmation" as too arbitrary and
unspecific. Best I could come up with till now is "linked identity", but
maybe someone has an even better idea :)

> I really think that a user attribute is overkill -- a User ID should
> be sufficient, and existing implementations won't need to be
> modified to support it directly or to expose it to the user.

I thought about this at some point, but discarded the idea. Instead of
arguing this exact point, I will write some more on the current state of
my concept:

A linked identity is a mutual, verifiable connection between a pgp key
and a resource on the web. The keywords here are verifiable and mutual:
A linked identity should be considered valid if and only if the resource
it points to links back not only to the pgp key, but to that exact
linked identity packet, in a manner which can be verified by the client.

The reliable statement we want from a linked identity is that the owner
of the keyring simultaneously controlled both the keyring (ie, a subkey
with 'certify' capability, ie, its master key) and the (context of the)
linked resource at one point in time. This implies that the linked
identity packet requires some sort of identifier, which is then part of
the resource content.

So now, a linked identity consists of a URI to some resource, and an
identifier. We *could* encode this identifier in the uri, but I would
not consider the identifier as part of the URI to the resource - quite
the opposite actually, the identifier is what we expect to find in the
*content* of the resource, and is specifically un-involved in the
process of resolving the URI for its content.

Still, we could put the identifier in the URI and put that in a user
id. At that point, we have something like
pgpid:0123456789abcdef01234567 at dns:domain.com?TYPE=TXT
and I would argue that without client support, this is will not only not
lead the user to the right conclusions, but confuse or even mislead them.

Another important point is that, even though a resource may be correctly
identified by a URI, it might not be available by generic means. The
best example I have is twitter, where the https-uri of a tweet bears
sufficient information to find the tweet, but the implementation still
needs to specifically know how to parse just the tweet text from the
website, not any replies or whatever else may be on the website as
retrieved from the https URI. The generic 'fetch website, grep for
backlink' resource is actually the special case here, because it can
only be used if a user has guaranteed exclusive access to the linked
resource, which is not the case for many resources published by accounts
on social networks.

For linked identities to work, I think proper client support for
verification is a requirement. Conversely, being able to see a linked id
as something other than 'opaque user ids' in a client which does not
support them otherwise is hardly helpful. That said, handling a new user
attribute packet is trivial for any implementation which already has
routines for the jpeg type, and still very easy otherwise since user
attributes are extremely similar to user ids.

--

Different point: my current idea for the "link back" from the resource
to the linked identity packet, which I would intuitively call "cookie",
looks like this:

[Verifying my PGP key; pgp+linked:fingerprint#nonce]
e.g.
[Verifying my PGP key; pgp+linked:d4ab192964f76a7f8f8a9b357bd18320deadfa11#0123456789abcdef01234567]

So it's a very short text, followed by a uri including the fingerprint,
plus the identifier for the linked identity packet as fragment. The text
is meant to mitigate "hey tweet this text for me real quick lol"
attackers, since people will hopefully be more weary to post something
which implies they are verifying anything, than just random line noise.

Variables here are the exact leading text (obviously), and the uri
scheme. The openpgp4fpr: scheme looks like it might be a good candidate
(especially since it is one of the whitelisted schemes for browser
extensions), but I'm not sure if it's a good idea to just add semantics
to that scheme. I thought maybe openpgp4fpr+id, but that loses the
advantages of openpgp4fpr and is quite long.

The cookie is roughly 100 characters long like this, which should fit
into almost any reasonable resource. It is delimited by brackets so the
user can easily identify what parts of their resource they are allowed
to modify around the mandatory bit when they publish it.

It is noteworthy that the cookie does NOT have to be signed again. It is
to be considered valid exactly when there is a certified and non-revoked
linked identity as identified by the nonce, in the keyring identified by
the fingerprint. The owner of the keyring proves control over the
keyring with the certificate over the linked identity, and control over
the resource by publishing the cookie.


Thank you for your input so far! I will have to reason about all
conclusions I come to in my thesis, so the more ideas and opinions I
get, the better. :)


 - V