Re: [openpgp] Overhauling User IDs / Standardizing User Attributes

[Leo Gaspard <[e-mail]>]

On 06/27/2018 10:07 AM, Wiktor Kwapisiewicz wrote:
> Hi Leo,
> 
> Okay, after your explanations and thinking about this through the night
> I can see some benefits. Especially to the split of names (people
> usually have only one name and it's usually verified using government
> issued IDs) and e-mails (that can be automatically verified).
> 
> There are projects [0] that want to verify e-mails and add signatures to
> indicate "verified e-mail" but because e-mail and name are joined the
> signature also covers the name (that wouldn't be necessary in your design).
> 
> Sometimes the name in UID is not welcome (see "mailbox-only" in WKD [1]).

Yes, that's exactly what I'm thinking of.

> But I'm not in favor of other attributes:
>   - "role" (e.g. "Qubes OS developer"), who would verify that? Probably
> only some kind of master Qubes key should sign it but then how do we
> know if this is a correct master Qubes key? Wouldn't e-mail in form of
> [e-mail] better express that? (for the record I also
> don't like "project X signing key" comments but that's another story),
>   - "pseudonym", also not clear what are the rules of signing this ID,

Well, I don't really like them either, but that'd be a way for people to
have a place to put the information they currently appear to want to put
in their User ID fields. The aim of these fields is mostly to avoid
misuse of other fields.

> E-mail ID could be generalized to an URI ID (e.g. e-mail would be
> "mailto:[e-mail]"), then your "account-on" ID could also be a
> URI (e.g. https://github.com/user, or XMPP account:
> xmpp:[e-mail]) [2].

Indeed that's possible too. I was more thinking that the XMPP account
would be set as one of the “free form tag=value” (with
`xmpp=[e-mail]` for your example), but the two sound just as
flexible to me, so no strong opinions here.

Actually the “role” and “pseudonym” could also be of the “free form
tag=value”, but I was thinking, when adding them specifically, that
encouraging standardization to things that already appear “in the wild”
would make sense. Without strong opinions either :)

> But I think the most severe issue with your proposal is the ripple
> effect it would have on the trust system. Currently one valid User ID is
> necessary to mark the key as valid. And that valid User ID means both
> the name and the e-mail (in most scenarios). But with split names and
> e-mails a more elaborate design would be needed. And that's just one case.

Indeed that is a big issue with implementation of this proposal.

I'd think the concept of saying “a key is valid” is likely a problem
anyway, as a key is always valid, and the only thing that can be checked
is the validity of the association between a User ID and a key (for the
WoT, there is no need to have a key “valid” for trusting it, so I guess
the change shouldn't generate any issue).

So this would require quite some changes especially around the user
interface, that couldn't just display a valid User ID as “key handle” as
is currently done by at least GnuPG and Enigmail, but would also have to
reconstruct something intelligent to display based on the set of
validated User Attributes.

Cheers,
Leo