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

Hi Leo,

> 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 4880bisright now.

Standarization and implementation of new User Attributes would takeages, and the existing User IDs are just good enough.


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

That depends on your personal key-signing policy. I - for example -don't sign User IDs with comments (because I can't or don't want toverify if your role is "super administrator" or nickname is "XYZ").


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

You can create User ID without e-mail, actually a lot of people do justthat. And then add one more with e-mail, works just fine.


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

And how is that different from what we have in User ID? It's still up tothe signer if they want to sign "pseudonym" user attribute or not. Youjust gain marginal benefit of having "name", "email" and "pseudonym"parts separated for a big effort in supporting this new scheme.

Actually I was also thinking on using User Attributes at one time (forLinked IDs) but luckily the idea was shot on this ML. User IDs arebetter because they have a fallback already - a human can read thestring just fine, not be confused by "[unknown attribute of size 83]"(check my key).

For extensibility - notations - they are also human readable and can bemade critical for special purposes.


Sorry if this sounds negative.

Have a nice day!

Kind regards,
Wiktor

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)
<email(_at_)example(_dot_)org>”. 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.


--
*/metacode/*

_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp

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