Hi 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.
Standarization and implementation of new User Attributes would take
ages, and the existing User IDs are just good enough.
Well, I think User IDs are not good enough, but I do agree it's an
implementation burden… seeing only the “end-user” side of the story I
can't tell much about this implementation burden, though.
For standardization, as soon as there is a consensus that User IDs are a
problem because they couple orthogonal things and that they should be
replaced by a more orthogonal scheme, I think that having one or many
User Attributes wouldn't change much… and anyway that'd be only for v5
keys, which are going to take loooong before they are actually deployed
everywhere.
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 to
verify if your role is "super administrator" or nickname is "XYZ").
Indeed, that's exactly the issue I try to solve with this proposal: User
IDs couple unrelated things, including some I want to sign and some I
don't want to sign, and I'd love to be able to sign only the parts I
actually want to sign.
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 just
that. And then add one more with e-mail, works just fine.
Yes, but the issue is mostly the other way around. When I check the name
of someone, I have no problem in checking their e-mail too. What I do
have problems is checking people's names, while the email address is
really easy to check (a challenge-response over the mail and it's done).
I'd like to be able to sign only the email address of people… but then
that means I have to ask people to change the way they allot User IDs:
one User ID per real-world name, one User ID per pseudonym, one User ID
per email address, and one User ID per role.
And… here comes my 4 main User Attributes, that are just a way to both
enforce and standardize these use cases. For instance, I could likely
sign a “This key uses pseudonym Hello World” after relatively minor
checks, but I wouldn't sign a “This key has User ID Hello World” without
extensive checks, because I would assume it's a name, not a pseudonym.
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 to
the signer if they want to sign "pseudonym" user attribute or not. You
just gain marginal benefit of having "name", "email" and "pseudonym"
parts separated for a big effort in supporting this new scheme.
Well, if everyone did separate the User IDs this way, then it wouldn't
be necessary. But even rfc4880bis§5.12 mentions “By convention, it
includes an RFC 2822 [RFC2822] mail name-addr” and that it “is intended
to represent the name and email address of the key holder.”
So I think the spec itself is currently discouraging people from doing
the Right Thing (ie. separate orthogonal information into separate User
IDs).
And if the spec is to incite people to standardize on separate meanings
for the User ID field… wouldn't it be better to just enforce it by
dropping them in the v5 key format, and having only User Attributes?
Actually I was also thinking on using User Attributes at one time (for
Linked IDs) but luckily the idea was shot on this ML. User IDs are
better because they have a fallback already - a human can read the
string just fine, not be confused by "[unknown attribute of size 83]"
(check my key).
For extensibility - notations - they are also human readable and can be
made critical for special purposes.
Hmm… I would agree with you, but here I'm talking not of using User
Attributes on v4 keys (which are IMO quite useless, apart from photo
IDs, which are useless too), but of User Attributes on v5 keys, for
which the spec (were the changes I'm thinking of accepted) would give
specific meanings, and would enforce implementation.
Thus, these User Attributes would be all the users would have to claim
their identity. And thus they would necessarily be well-supported, as
everyone would be using them for v5 keys.
That said, it is a quite large development burden, especially around the
UI, as currently UIs can just assume they can dump a raw User ID to the
output and be done with it, while with the changes they would have to
actually find intelligent (eg. relevant and verified) User Attribute(s),
and display only them.
Sorry if this sounds negative.
Negative feedback is great too, thank you for your answer! I hope I have
better explained why I think such a change would improve the situation
around User IDs, now :)
Have a nice day too!
Cheers,
Leo
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp