ietf-openpgp
[Top] [All Lists]

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

2018-06-28 19:38:39


On Jun 28, 2018, at 2:35 AM, Leo Gaspard 
<ietf=40leo(_dot_)gaspard(_dot_)ninja(_at_)dmarc(_dot_)ietf(_dot_)org> 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=foo(_at_)example(_dot_)org, 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

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

<Prev in Thread] Current Thread [Next in Thread>