Re: [openpgp] Overhauling User IDs / Standardizing User Attributes (was: Re: Scoped trust (signatures))

[Leo Gaspard <[e-mail]>]

On 05/28/2018 12:55 AM, Vincent Breitmoser wrote:
>> Then, the “I have this account on this website”, that can be seen eg.
>> [here](https://sks-keyservers.net/pks/lookup?op=vindex&search=0xAC6D00DB7F24B2C2),
>> and is the point that, as far as I understand, lead to the birth of
>> keybase.io (which did show some traction). It could be handled by a
>> “account-on” that would store both a domain name (for the website) and a
>> username.
> 
> Been there, done that: https://tools.ietf.org/html/draft-vb-openpgp-linked-ids-01
> It's also implemented and deployed as an experimental feature in OpenKeychain.

Hmm, this sounds like not solving the exact same issue: I was thinking
of a user asserting “I am [X] on service [Y]”, and (if I read correctly
your I-D) your proposal included having the OpenPGP implementation doing
the validation of this statement.

I think having the OpenPGP implementation doing the validation of such
statements is *really* hard to do. For instance, the section 4.4 of your
I-D doesn't explain how to do it, and I don't think it reasonably could
(you mention yourself that a proper VERIFY operation requires additional
insight on the specifics of each service).

This is the reason why I was only proposing a way to include in a User
ID “I am [this person]”, and then leave validation of this statement to
the same mechanism as the usual User IDs: I think this has a chance to
get in RFC4880bis, while having a more complex and
modifying-the-trust-model scheme could only live in a separate RFC,
especially when it potentially has implications on the privacy (as the
services would then know when I attempt to verify a User ID).

As for the validation of this User ID, with only my proposal, it could
be handled in the same way as email addresses: scoped trust for the
domain, that would be trusted to sign User IDs. Or scoped trust for
keybase.io (or any other equivalent service), that would be trusted to
validate the cookie online and sign the keys accordingly. Actually,
email is just a special case of an account on an online service, but I
think handling it separately makes sense, as eg. @github.com email
addresses won't be the same as @users.noreply.github.com ones.

That said, I do believe there is value in your proposal (eg. not relying
on a trusted third-party when the upstream service doesn't have a public
key that could be trusted), but I also think these two approaches are
complementary.

> As a more general note, it would be nice if we could drop the requirement to
> have at least one (unsigned) user id, in which case the primary key gets its
> properties from a (then mandatory) direct key signature. For key distribution
> models other than searchable-by-uid keyservers (including autocrypt and wkd),
> user ids can quickly become unnecessary metadata.

With the changes I proposed, there would no longer be any User ID in v5
keys (the User ID subpacket would just be forbidden there, and likely
Primary User ID too).

There could be an arbitrary number of User Attributes, like now,
because, as you mentioned, it may make sense to not have any for eg.
TOFU use.