On 06/27/2018 02:05 PM, Wiktor Kwapisiewicz wrote:
Hi Leo,
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
user(_at_)developers(_dot_)qubes(_dot_)com 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.
I think the root of the problem is that people either input something
because there is a Comment field, or they think they need to input
something there (e.g. "Work").
In the first case it's slowly getting better as tools as gpg have
sensible defaults now (for example, they don't ask for comment when
creating keys).
In the second case a good solution would just be educating people (for
example making them familiar with this timeless piece:
https://dkg.fifthhorseman.net/blog/openpgp-user-id-comments-considered-harmful.html
).
Well, setting up proper user interfaces for this will likely end up with
two types of User IDs, the “name” one, and the “email” one, which would
be distinguished by putting brackets around the “email” User ID. Which
does the same thing as this proposal to split the User ID into User
Attributes.
But the issue is that then, tools will not be able to assume that all
User IDs conform to this “de facto standardization,” because some tools
likely won't follow this convention, and will still put User IDs of the
“Name <email>” format.
And this then increases the complexity of user interfaces, that have to
handle both cases.
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).
By "valid" I meant the strict technical term used by gpg (see e.g. this
excellent resource:
https://www.linux.com/learn/pgp-web-trust-core-concepts-behind-trusted-communication
).
Well, yes, and I claim this strict technical term designates something
that has no sensible meaning. If I remember correctly, GnuPG uses it to
show whether at least one User ID has been signed by a key that is
trusted. The validity should instead apply to the (key, User ID) couple,
and then it does make sense.
Actually, 4880bis§5.2.1 already defines type 0x10 (which is IIRC the
most used type for certification signatures) as “Generic certification
of a User ID and Public-Key packet,” which isn't “Generic certification
of a Public-Key packet.”
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.
Exactly. And this kind of modification that requires changing all tools
along the path, for a standard so widely used as OpenPGP can be hard to
pull off.
Well, my hope in pushing this for v5 is that a lot of tools will already
have to be changed along the path, so I was hoping this would be only an
additional change that wouldn't be delayed as much :)
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp