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

[Leo Gaspard <[e-mail]>]

On 06/27/2018 03:56 PM, Wyllys Ingersoll wrote:
> The problem I see with all of these suggestions is that there is no way to
> actually "verify" the data that someone puts into these fields without some
> sort of standardized and trusted verification service, which is way out of
> scope for the OpenPGP spec.

Well, verifying the data that someone puts into these fields is out of
the scope of the OpenPGP spec just as much as verifying the data that
people put into User ID fields is out of scope of the OpenPGP spec.

The difference is that currently the spec is actively hostile to any
kind of eg. automated verification of email addresses, by coupling names
with email addresses :)

> Also, adding many more user attributes *will*
> complicate UIs beyond gnupg and enigmail. Consider mobile applications such
> as ipgmail [mine] and others where screen real estate is at a premium and
> users dont want to type lots of info into complex forms that are not well
> understood by the average user.

Indeed it will complicate the code of UIs. But I'm not sure it wouldn't
lead to more usability and security in the end, just because UIs could
still display data “the old way” if they want, but they could also
display a well-thought subset of the information, eg. displaying only
the name if it's validated, or only the email if the email is validated,
thus even winning screen estate.

About “complex forms”, if I compare:

    Name:  [             ]
    Email: [             ] [+]

With:

    User ID: [ type in your User ID in Name <Email> format ] [+]

Then I know I find the first much easier :) And actually it even wins
screen horizontal real estate, which is quite a bit more precious than
screen vertical real estate on mobile devices.

> The whole "web of trust" is not really
> codified or enforced in a formal way, its pretty much up to individuals to
> decide on the trust level they want to assign to a key (or userids
> associated with the key), many users ignore it entirely and happily use the
> key and assume the UID is correct.  Why would this be any better?

Well, if users just assume the User ID is correct, then splitting the
User ID into User Attributes isn't going to help them (but won't make
them worse off).

However, for people who actually check things before they sign keys and
verify validity of the keys, then the change would make signature much
easier, and thus would increase the likelihood of having a validated key
for a random email address they'd want to speak to.

(note: I've answered this part of your message by assuming by “trust
level” you meant “validity”, if that wasn't what you meant then I'm
sorry I misunderstood)

> Im not convinced that the proposal to break up the UID into lots of
> separate attributes is enhancing the security or usability for the general
> PGP user community, though I can see it having value in some specialized
> cases and perhaps it could be a foundation for building a better
> trust/verification system.

Well, for direct users, it should change relatively little, apart from
at signature time, where “to be signed” elements would be presented by
User Attribute and not by User ID.

It could change a bit in interfaces, where an example UI would be to
only display validated User Attributes that match the From: header, for
instance, for emails.

It could also help projects, where, if I'm a project and I sign the key
of a contributor, I want to sign their key as “yes this is a member of
the project”, not to sign their identity, because I maybe haven't
checked the real-world identity of the developer I'm giving commit
rights, and only looked at the key's history of making good commits.

All this could help particularly in relation to scoped trust, allowing
to trust certain keys only for signatures on certain User Attributes,
eg. allowing a GitHub official key to sign all “free form tag=value”
User Attributes for which “tag” is “github”. Which would be next to
impossible to do without at least a minimal amount of standardization in
User Attributes, as is currently the case with everyone misusing User
IDs everyone with their custom scheme for this purpose :)