[messaging] Linked Identities (was: affirmations)

[Daniel Kahn Gillmor]

(please use example.{com,org,net} or *.example for examples, so that we
don't start dragging actual sites like https://website.com/ into the
discussion!  cf. https://tools.ietf.org/html/rfc2606)

On Fri 2015-01-23 04:16:21 -0500, Vincent Breitmoser wrote:
> 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.

What change do you have to make?  do you have to make a new secret
primary key and revoke the old certificate entirely, or do you need to
make some other change in the existing certificate?  Do you still
control https://example.com/pgpkey.txt ?

> 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.

which keyring are we talking about?  how does the "keyring" here differ
from the "certificate" you mention above?  If you still hold the same
primary key, then the OpenPGPv4 fingerprint is still valid; if you still
control https://example.com/pgpkey.txt, no revocation is needed, right?

if you are changing primary keys, and you still control
https://example.com/pgpkey.txt, then you should just change the contents
of the webpage to refer to the new primary key.

> 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.

It makes the identity less comprehensible to other people who are
considering it; if it doesn't provide defense against some useful attack
or useful information to any third-party reviewing the cert, this seems
like a net loss.

> 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.

you're talking about the UX of the keyholder here; i agree it makes that
UX more complex.  It also makes the UX of any third-party: potential
certifiers now have a (slightly) more complex process to do, and relying
parties have a more complex process to make sense of.

> 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.

This is a bad common practice, and unfortunately, it extends to User
Attributes as well.  Consider the number of people who have certified
the User Attribute jpeg on B4150264073C98F1490D94FF8CA2ACE7F1530A35,
which looks like:

-------------- next part --------------
A non-text attachment was scrubbed...
Name: the_glu.jpg
Type: image/jpeg
Size: 5208 bytes
Desc: User Attribute from B4150264073C98F1490D94FF8CA2ACE7F1530A35
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20150123/855dd635/attachment.jpg>
-------------- next part --------------

> "Watch out for those new URI user ids, don't sign them by accident!"
> sounds like a bad position to be in.

We're already in this position, unfortunately, and using a UAT instead
of a UID doesn't fix things (the fix needs to happen in the toolchains
that people use for certification).

Using a UID at least makes things trivially visible to the end user,
since it's just a text string; choosing a simple user-comprehensible
representation of the text string makes it a little closer to plausible.
PKI authentication schemes are hard enough to get right when they're
simple (perhaps it's never even been done!); making them more complex
than they need to be seems likely to cause additional failures.

        --dkg