[messaging] Linked Identities (was: affirmations)

[Vincent Breitmoser]

On 21 Jan 2015, Daniel Kahn Gillmor wrote:
> What attack does the cookie prevent?

The cookie helps in a scenario where the URI of a linked identity
changes, but the reference stays the same. For example, if I have a
linked identity to my website, with a pinned ssl fingerprint, I imagine
the URI something like this

pgpid:generic;fp=abcde at https://website.com/pgpkey.txt

Now, say I have to change my certificate for whatever reason. I revoke
the linked identity on my pgp key. Without a nonce on the website, I
have no way to "revoke" the cookie which is valid for that linked
identity with that fingerprint, other than never to use the resource uri
again for that keyring.

Granted, it's a slightly contrived scenario. I still think it can be
useful, and if we have a user attribute anyways it adds little to no
complexity to the verification mechanism.

Where it *does* add complexity is the UX. It makes the difference
between a one-way place-check-certify ("tell me the uri where the cookie
is placed - ok I checked, everything seems in order, create linked
identity for this?") and a generate-place-check-certify ("here's the
cookie, please place it at the site and hit ok to proceed - ok I
checked...") mechanism. I'm not sure if the latter is desirable in all
cases, but it does feel more foolproof.

On the topic of putting linked identity URIs in user ids, while this
would give more exposure, I feel it would also confuse users who have
clients which don't support it - especially since it is common practice
to just sign all user ids once you have seen a person's id and compared
fingerprints. "Watch out for those new URI user ids, don't sign them by
accident!" sounds like a bad position to be in.

 - V