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

[Leo Gaspard <[e-mail]>]

Are there really no opinions on this idea of decoupling names and email
addresses through standardization of more User Attributes and removal of
User ID packets in v5 keys? Not having any feedback from any software
maintainer makes me wary of starting to write a patch for 4880bis right now.


On 05/28/2018 12:27 AM, Leo Gaspard wrote:
> On 05/27/2018 10:56 PM, Neal H. Walfield wrote:
>>> Another issue of this scheme, obviously, is that noone “in the wild”
>>> currently uses regular expression subpackets (that I know of).
>>
>> Not only does almost no one use regular expressions, but regular
>> expression support is not very widely supported (GnuPG doesn't support
>> regular expressions on Windows), and until recently broken in GnuPG
>> (see https://dev.gnupg.org/T2923).
>>
>> I would like to make a counter proposal, that Vincent and I came up
>> with at FOSDEM: I think that we should deprecate Regular Expression
>> support and replace it with a list of domains (optionally prefixed
>> with "*." to indicate any subdomain).  First, most users don't
>> understand regular expressions.  And, although it would be possible to
>> allow users to enter one or more domains and then convert them to a
>> regular expression, it is not easy to reverse this process, which is
>> essential for explanatory purposes and editing.  Second, not including
>> an RE engine reduces complexity.
> 
> Issue
> -----
> 
> This is what I had in mind at the beginning, but then I came upon a
> stumbling block: User IDs. They are not at all standardized, so it's not
> possible to assume they are in the form “Name (Comment)
> <[e-mail]>”. And, even if assuming this, how could the
> implementation validate the “Name” and “Comment” parts, when the Regular
> Expression support is replaced by something to validate by domain?
> 
> So I think there are two problems here:
>  1. User IDs are not standardized
>  2. User IDs contain many unrelated information
> 
> I already explained point 1, so I'll now explain point 2. User IDs as
> currently used tie in a name and an email (I'll omit the Comment part).
> Which are two completely unrelated things: I have a single real-life
> name (well -- most people do), a pseudonym, and a lot of e-mail addresses.
> 
> When I want to sign someone's User ID, I need to both check their
> real-life name (with eg. a state-provided ID) and their e-mail address.
> And if someone has put a pseudonym on the User ID, should I sign it?
> This tight coupling of name and email address in User IDs is already an
> issue for me (in choosing what User ID(s) I should put, choosing whether
> to sign a User ID I only know part of…), and is now again an issue in
> fixing the standard to be both more simple and more usable.
> 
> 
> Idea
> ----
> 
> So here is my idea: drop User IDs in v5 keys, and standardize more User
> Attributes. In particular, standardize at least a “name”, an “email” and
> a “pseudonym” user attribute. (I'm not sure about the “comment” user
> attribute, and would prefer seeing it handled otherwise, see the
> “Possible extensions” section)
> 
> 
> Consequences
> ------------
> 
> So what would happen were this done?
> 
> First, when picking my User IDs, I wouldn't have to think over whether I
> really want to associate such email address with my name or with my
> pseudonym.
> 
> Then, when signing User Attributes, I could just sign all user
> attributes I checked. I could sign “email” User Attributes after
> checking I could send and receive mail to the provided email, I could
> sign “name” attributes after checking a state-provided ID, and I could
> sign “pseudonym” and “comment” attributes depending on my local signing
> policy (which I haven't really determined yet).
> 
> Finally, this would make the scoping-by-domain-name proposal possible:
> it'd be “can only sign `email` User Attributes and the part after the
> last @ must match this restriction”.
> 
> 
> Possible extensions
> -------------------
> 
> So now with this change it would become possible to handle extensions of
> the User IDs that have been proposed.
> 
> First, the “[project] signing key” comment, that can be seen eg.
> [here](https://sks-keyservers.net/pks/lookup?op=vindex&search=0x8B3F30F9C8C0C2EF).
> This could be handled by adding a “role” User Attribute, that could be
> “Qubes OS developer” here. And thus the organization only needs to
> validate the keyholder is a QubesOS developer when signing this, without
> having to also validate a name, an email address or whatever else.
> 
> 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.
> 
> Finally, I think it would be good to stay more “open to extensions” than
> the current scheme of (mis)using User IDs, by eg. reserving attribute
> type 255 for “plaintext key-value user ID”, so that implementations that
> can't reasonably fit some data in one of these User Attributes could
> just use it with raw key/values instead of using one of the 100-110
> reserved values, which wouldn't be displayed by implementations not
> aware of them.
> 
> 
> Remaining issues
> ----------------
> 
> The foremost issue with this change is the one of the UI to display the
> user: currently, in Enigmail (the only end-user-oriented UI I know of),
> the primary User ID of the key is displayed. With this change, there
> would no longer be a primary User ID.
> 
> I can currently think of two UIs. The first would check that the name
> and the email address of the received mail are valid, and error-out
> otherwise. The second one would just pick a name and an email address
> from the list of valid ones, and display it.
> 
> In my opinion, the first option is *way* better than the second one, and
> it's the reason why I didn't propose an extension of the Primary User ID
> flag to handle multiple primary User Attributes (would be one name and
> one email, for instance).
> 
> For instance, a problem with primary User IDs/Attributes is the
> following: let's assume I can validate a few UIDs on the key, but not
> the primary one. What should I display? I think there is no good answer
> to this question apart from “validate the one it came as” or “show all
> the valid ones”, and thus removing the Primary UID may remove some traps
> naive implementations may fall in, like displaying a non-validated
> primary UID.