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

[Jon Callas <[e-mail]>]

> On Jun 28, 2018, at 2:35 AM, Leo Gaspard <ietf=[e-mail]> wrote:
> 
> On 06/28/2018 03:44 AM, Jon Callas wrote:
>> Forgive me, Leo, but I don’t understand what problem you’re trying to solve, but I’m going to say that’s my fault. Nonetheless, could you reiterate for those of us who weren’t paying proper attention before?
> 
> No problem!
> 
>> UserIDs are intentionally a huge hand wave. It’s an arbitrary UTF-8 field. Put whatever you want into it. Yes, by convention it’s an email address, but even at the time that that was common it was convention only. When I was with PGP Corporation, we made software signing keys that merely said they were software signing keys, as well as other keys that had no email address, but a text description of what they were.
> 
> Well, the idea is that User IDs are a huge hand wave indeed, and that
> seems to make exploiting this hard, esp. around signature, as that most
> often means (in my experience) that I can't sign an email address
> without signing a name and reciprocally.
> 
> So I think splitting the User IDs into orthogonal fields would make
> signing these fields (as well as setting trust signatures with
> constraints) much easier.
> 
> Currently, the fields I am thinking of would be defined as User
> Attributes, and would be:
> * name (for the real-world name of the owner)
> * email
> * role (would fit the software signing key case, or role of the owner
> of a key inside an organization)
> * pseudonym (not really sure this one would be really useful, but this
> would allow people's signing policy for pseudonyms to differ from the
> signing policy for names, eg. noticing persistent use of the same
> pseudonym vs. checking government-issued ID, without misleading
> verifiers into thinking that the pseudonym was actually a
> government-validated name)
> * free form tag=value (for eg. xmpp=[e-mail], github=bar, etc.)
> 
> Not all of these fields would need to be filled-in, obviously, and a key
> could have any number of each.
> 
> The main point of this is to make eg. automated signature of email
> addresses possible without impacting user interface by requiring an
> email address in a separate User ID.
> 
> Also, I don't think it would reduce the freedom currently offered by
> User IDs, because there would always be the free form tag=value User
> Attribute for marginal cases. But it would incite people to put the
> right value into the right field, and would likely make life easier for
> both automated and non-automated signers.
> 
> Is what I'm thinking of more clear now? :)

Absolutely. 

You could do this with User IDs. They are, after all, generic and you could thrown XML, JSON, or whatever else you wanted. It would be ugly (because most software presumes that it’s human-readable and human-useful), but it would work. 

Or you could do it with User Attribute Packets that are explicitly designed for this sort of thing. There’s only one type of attribute defined now, a photo. Section 5.12 defines them, notes that, also says that software SHOULD ignore types that it doesn’t recognize, and beyond that notes that (as usual) types of 100-110 are for private or experimental types. 

I suggest this because there is an established framework for you to experiment and show the usefulness of what you’re doing. Make your own packet, number it 110, and go ahead. Or, write up an RFC draft, propose in it that you use 2 as the type, and get rough consensus and running code to do it for you.

If you bend User IDs into what you want, then it effectively becomes everyone’s business as you’re veering from the spirit User IDs and there’s no good way for software that doesn’t want to play along to do something sensible. But if you use User Attributes, you’re in territory where the system is tilted in your favor. The standard says that an implementation that doesn’t understand yours SHOULD ignore it. It says, "Except as noted, a User Attribute packet may be used anywhere that a User ID packet may be used,” and that means that it falls into exactly what you want. It becomes your own thing that doesn’t affect those who don’t agree. It’s a much better place to be standing.

Heck, while you’re at it, talk to the Keybase people because they explicitly now have Twitter, Facebook, Github and DNS identifies, along with Reddit, Hacker News, Bitcoin addresses, Zcash addresses, and more I’m likely missing.

	Jon