Subject: Re: [openpgp] Scoped trust (signatures)

From: Jon Callas <[email-masked]>
Date: Fri, 01 Jun 2018 00:11:30 -0700

> On May 28, 2018, at 12:06 AM, Vincent Breitmoser <[email-masked]> wrote:
> 
> I believe you've described the very problem with this approach here: A powerful
> and flexible mechanism leads to many inconsistencies between implementations,
> that's just unavoidable. For sieve scripts you might be fine with that, at worst
> some messages will go in the wrong folder once in a while. But are you really
> okay with same level of inconsistency in a trust model?

I think I’ve described the opposite.

The filtering model in Sieve is well-defined. There are differences in a GUI overlay because different communities value different shortcuts, and also put different viewpoints on the shortcuts. The Sieve scripts generated by any one of those disparate GUIs will execute the same way on another. Now I, the user, may have to create a collection of filters to do what I want because of what gets exposed to me in the GUI, but the resulting script will execute the same.

Let’s suppose Neal does what he wants — it’s just a list of domains. That’s a really easy thing for him to implement (perhaps, as I’ll reply to him next) but the regex that he generates will execute the same everywhere.

However, that’s not the real point I wanted to make. That point is that there’s a difference between being an implementer and the protocol. A good implementer makes decisions about things for their own vision, but a protocol designer has to make something that satisfies different visions. Moreover, the protocol inevitably is a compromise between differing visions. A standard is something that is a compromise, and as such is not any one person’s vision whatever it ends up with. And as we all know, a compromise is something where everyone is more or less equally unhappy with it, but not so unhappy that they walked away.

I haven’t told you what I’d do (and did) with any of this so far, but I’d be happy to later. Advice I give as an implementer is usually different than advice I give as a protocol designer. The standard as it exists is something that got the rough consensus of the working group, and that rough consensus is worthy of a little respect. Perhaps not too much, but certainly a little. The problem with making the protocol match one’s own opinions is that it’s effectively saying not only that what one thinks is right in some sense, but also that other people’s opinions are wrong and that no one else should do something different.

	Jon

---

From: Jon Callas <[email-masked]>
Date: Fri, 01 Jun 2018 00:25:23 -0700

> On May 28, 2018, at 1:42 AM, Neal H. Walfield <[email-masked]> wrote:
> 
> On Mon, 28 May 2018 04:06:59 +0200,
> Jon Callas wrote:
>> Moreover, there's a regular expression helpfully defined in Section
>> 8 that is a pretty bog-simple language
> 
> Implementing regular expression support might be bog-simple, but I
> think it is still orders of magnitude more complicated than just a
> list of domains.  And, I think, the general lack of support for this
> feature is strong evidence that this is the case.
> 
> Thus, it seems to me, that making the complicated theoretically
> possible has made the simple practically impossible.  That's
> unfortunate.
> 
> Do you know of any examples where a list of domains is not sufficient?

As I alluded to in my previous missive, I think that a list of domains is harder than you think. My experience in dealing with other domain-based PKI leads me right there.

Does “example.com” match “mail.example.com”? Either yes or no is completely reasonable. Does “*.example.com” (which obviously matches “mail.example.com") match “example.com”? In this case, I think that the answer is yes, but gentle persons can disagree. I’d just roll my eyes if you said no, because yeah, sure, there’s no problem in having your list of domains have both “example.com” and “*.example.com” to be explicit about it. I see the point.

Matching domains in the general case has all sorts of other weird edge cases especially in CCTLDs because many CCTLDs don’t issue anything on the bare country code. For example, for many years you couldn’t get “example.uk” but you could get “example.co.uk”. In any event, some CCTLDs allow a bare country code and some don’t. Do you take this into account in your list of domains? I think that an answer that is “whatever you put there is what we do” is a great answer, but there are people who will disagree. What about trailing dots on a domain? How are they handled?

I believe that a list of domains is harder than you think. Whatever decisions you make on the edge conditions of domains are something you yourself can do so that when I type in a list of domains, your interpretations will correctly be coded into it and that someone else will interpret them in the way you did.

Go look at the definition of regular expressions in RFC 4880. It’s basically just a paragraph. With my tongue partially in my cheek, I bet you can’t sort out what “list of domains” means in all the edge cases in less text than that definition of regular expressions. That is the reason that working group consensus went to the trouble of finding a minimal, utterly no-IP definition of a regular expression. It’s in a very real sense simpler than just about anything else.

---

From: Christian Huitema <[email-masked]>
Date: Fri, 1 Jun 2018 07:29:59 -0700

> On Jun 1, 2018, at 12:25 AM, Jon Callas <[email-masked]> wrote:
> 
> ...
> 

Matching domains is indeed hard, but people are working on it. You may want to check the list of public prefixes maintained by Mozilla et al as an open source project:

https://github.com/publicsuffix/list

-- Christian Huitema

---

From: Vincent Breitmoser <[email-masked]>
Date: Tue, 12 Jun 2018 13:20:16 +0200

Hey Jon,

> The standard as it exists is something that got the rough consensus of the
> working group, and that rough consensus is worthy of a little respect. Perhaps
> not too much, but certainly a little. The problem with making the protocol
> match one’s own opinions is that it’s effectively saying not only that what
> one thinks is right in some sense, but also that other people’s opinions are
> wrong and that no one else should do something different.

Thanks for your thoughtful reply! I think I understand where some of these
decisions are coming from a little better now.

 - V

---

From: Leo Gaspard <[email-masked]>
Date: Tue, 26 Jun 2018 17:27:49 +0200

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.

On 05/28/2018 12:27 AM, Leo Gaspard wrote:
> On 05/27/2018 10:56 PM, Neal H. Walfield wrote:
>>> Another issue of this scheme, obviously, is that noone “in the wild”
>>> currently uses regular expression subpackets (that I know of).
>>
>> Not only does almost no one use regular expressions, but regular
>> expression support is not very widely supported (GnuPG doesn't support
>> regular expressions on Windows), and until recently broken in GnuPG
>> (see https://dev.gnupg.org/T2923).
>>
>> I would like to make a counter proposal, that Vincent and I came up
>> with at FOSDEM: I think that we should deprecate Regular Expression
>> support and replace it with a list of domains (optionally prefixed
>> with "*." to indicate any subdomain).  First, most users don't
>> understand regular expressions.  And, although it would be possible to
>> allow users to enter one or more domains and then convert them to a
>> regular expression, it is not easy to reverse this process, which is
>> essential for explanatory purposes and editing.  Second, not including
>> an RE engine reduces complexity.
> 
> Issue
> -----
> 
> This is what I had in mind at the beginning, but then I came upon a
> stumbling block: User IDs. They are not at all standardized, so it's not
> possible to assume they are in the form “Name (Comment)
> <[email-masked]>”. And, even if assuming this, how could the
> implementation validate the “Name” and “Comment” parts, when the Regular
> Expression support is replaced by something to validate by domain?
> 
> So I think there are two problems here:
>  1. User IDs are not standardized
>  2. User IDs contain many unrelated information
> 
> I already explained point 1, so I'll now explain point 2. User IDs as
> currently used tie in a name and an email (I'll omit the Comment part).
> Which are two completely unrelated things: I have a single real-life
> name (well -- most people do), a pseudonym, and a lot of e-mail addresses.
> 
> 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?
> 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.
> 
> 
> Idea
> ----
> 
> 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)
> 
> 
> Consequences
> ------------
> 
> So what would happen were this done?
> 
> First, when picking my User IDs, I wouldn't have to think over whether I
> really want to associate such email address with my name or with my
> pseudonym.
> 
> Then, when signing User Attributes, I could just sign all user
> attributes I checked. I could sign “email” User Attributes after
> checking I could send and receive mail to the provided email, I could
> sign “name” attributes after checking a state-provided ID, and I could
> sign “pseudonym” and “comment” attributes depending on my local signing
> policy (which I haven't really determined yet).
> 
> Finally, this would make the scoping-by-domain-name proposal possible:
> it'd be “can only sign `email` User Attributes and the part after the
> last @ must match this restriction”.
> 
> 
> Possible extensions
> -------------------
> 
> So now with this change it would become possible to handle extensions of
> the User IDs that have been proposed.
> 
> First, the “[project] signing key” comment, that can be seen eg.
> [here](https://sks-keyservers.net/pks/lookup?op=vindex&search=0x8B3F30F9C8C0C2EF).
> This could be handled by adding a “role” User Attribute, that could be
> “Qubes OS developer” here. And thus the organization only needs to
> validate the keyholder is a QubesOS developer when signing this, without
> having to also validate a name, an email address or whatever else.
> 
> Then, the “I have this account on this website”, that can be seen eg.
> [here](https://sks-keyservers.net/pks/lookup?op=vindex&search=0xAC6D00DB7F24B2C2),
> and is the point that, as far as I understand, lead to the birth of
> keybase.io (which did show some traction). It could be handled by a
> “account-on” that would store both a domain name (for the website) and a
> username.
> 
> Finally, I think it would be good to stay more “open to extensions” than
> the current scheme of (mis)using User IDs, by eg. reserving attribute
> type 255 for “plaintext key-value user ID”, so that implementations that
> can't reasonably fit some data in one of these User Attributes could
> just use it with raw key/values instead of using one of the 100-110
> reserved values, which wouldn't be displayed by implementations not
> aware of them.
> 
> 
> Remaining issues
> ----------------
> 
> The foremost issue with this change is the one of the UI to display the
> user: currently, in Enigmail (the only end-user-oriented UI I know of),
> the primary User ID of the key is displayed. With this change, there
> would no longer be a primary User ID.
> 
> I can currently think of two UIs. The first would check that the name
> and the email address of the received mail are valid, and error-out
> otherwise. The second one would just pick a name and an email address
> from the list of valid ones, and display it.
> 
> In my opinion, the first option is *way* better than the second one, and
> it's the reason why I didn't propose an extension of the Primary User ID
> flag to handle multiple primary User Attributes (would be one name and
> one email, for instance).
> 
> For instance, a problem with primary User IDs/Attributes is the
> following: let's assume I can validate a few UIDs on the key, but not
> the primary one. What should I display? I think there is no good answer
> to this question apart from “validate the one it came as” or “show all
> the valid ones”, and thus removing the Primary UID may remove some traps
> naive implementations may fall in, like displaying a non-validated
> primary UID.

---

From: Wiktor Kwapisiewicz <[email-masked]>
Date: Tue, 26 Jun 2018 21:13:35 +0200

Hi Leo,

 > 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.

 >> 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").

 >> 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.

 >> “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.

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.

Sorry if this sounds negative.

Have a nice day!

Kind regards,
Wiktor

-- 
*/metacode/*

---

From: Marcus Brinkmann <[email-masked]>
Date: Tue, 26 Jun 2018 22:45:44 +0200

I think the problem you are facing is Zooko's triangle: Decentralised,
meaningful names for keys can not be secure.  The PGP (implementation)
answer to this is the web of trust, but that is pretty much out of scope
for OpenPGP (the standard).  This is also apparent from your description
by the introduction of external policies ("when I want to sign X, I need
to check Y"), that are also out of scope for OpenPGP.  This might
explain the lack of response here.

Once you are adding additional policies, you can create additional
restrictions for user id fields, or introduce additional (private use?)
user attributes ad lib, and those will be the least of your worries.

OTOH, without such additional policies (that can be enforced by
conforming implementations), the proposed fields will just be more free
form fields in OpenPGP that accumulate cruft over time. There are a
couple of those already, and we have a pretty bad track record
validating those.

---

From: Leo Gaspard <[email-masked]>
Date: Wed, 27 Jun 2018 01:28:40 +0200

On 06/26/2018 10:45 PM, Marcus Brinkmann wrote:
> meaningful names for keys can not be secure.

Indeed, this is similar to what I am thinking. But Zooko's triangle is
only for “decentralized” names, and what I see in all implementations
that I know of is that the end-user “validates” a particular (sub)set of
the names the key claims it has, and then uses these names. (similar to
handles defined in XEP-0165)

Also, I am not trying to solve Zooko's triangle, only to decouple
elements that are currently tightly interwoven without any reasonable
standard in the User ID field (hello @users.noreply.github.com, hello
roles in comments, etc.)

> The PGP (implementation)

Hmm… I think rfc4880bis§5.2, and in particular signature type 0x13 for
instance, do imply that “The issuer of this certification has done
substantial verification of the claim of identity.”?

And thus the standard doesn't currently address the “I want to sign an
email address but not the name associated to it, because I haven't
checked the name” use case, unless the one who generated the key (not
the one who wants to sign) did generate orthogonal User IDs.

And actually rfc4880bis even mentions “By convention, it includes an RFC
2822 [RFC2822] mail name-addr” (even if not enforcing it), thus
encouraging non-orthogonal User IDs.

> couple of those already, and we have a pretty bad track record

The point in these proposed fields, in my opinion, is that if User IDs
are removed from v5 keys altogether (if they aren't then there is no
point in doing it indeed), then there will be an enforced separation of
different parts of the (current) User ID into separate fields.

As for these fields becoming free form, I do hope that it wouldn't
happen: for the image attribute (the only one standardized afaik), I
haven't heard (yet?) of people using it for storing anything else than
an image. And with fields like:
 * name
 * pseudonym
 * email
 * role
 * free form UTF-8 tag=value
Then, contrarily to what currently happens with User IDs, I don't think
the first four fields would really be misused: what's the point? there'd
be a free form tag=value attribute type.

And this would already be enough to split the User ID tag into
orthogonal parts that could be signed independently, depending on the
signer's policy. And even type “free form tag=value” brings much more
display-ability than private-use types 100-110 that cannot be assumed to
have any type.

However, I do agree it'd be quite some maintenance burden, hence my hope
to get some feedback from an implementer. But I think it's necessary for
users and applications to behave consistently, and not mutilate the User
ID field just because it is the only one that is sanely rendered :)

---

From: Leo Gaspard <[email-masked]>
Date: Wed, 27 Jun 2018 01:47:27 +0200

Hi Wiktor,

> 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.

> 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.

> 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.

> 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?

> 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

---

From: Marcus Brinkmann <[email-masked]>
Date: Wed, 27 Jun 2018 02:42:24 +0200

> handles defined in XEP-0165)

If the use is purely local, you don't need OpenPGP at all, just store a
local label to name the key. That's what NeoPG will do and Sequoia wants
to do that, too, AFAIK.

The only reason to create (exportable) signatures is to convince
thirdparties of the binding, either by authority (centralized+secure,
CA-style) or by introduction (decentralized+insecure, web of trust).

OpenPGP (standard and implementations) has the concept of a local,
non-exportable signature. As far as I am concerned, that's just a leaky
abstraction due to historic implementation details being exposed, just
as with Trust Packets: Non-exportable signatures are by definition
local, and trust packets are local by a SHOULD rule (and in fact wholly
implementation defined).

> standard in the User ID field (hello @users.noreply.github.com, hello

There is value in standardization of user id field values, but I am not
sure that OpenPGP is the place for that. Not only has that ship sailed,
it is also mostly useful if embedded in a larger policy framework, as
you have suggested from the beginning.

> substantial verification of the claim of identity.”?

Doesn't mean anything. In fact, in the same section the standard says:

  "Please note that the vagueness of these meanings is not a flaw, but a
   feature of the system.  Because OpenPGP places final authority for
   validity upon the receiver of a signature, it may be that one
   signer's casual act might be more rigorous than some other
   authority's positive act."

> the one who wants to sign) did generate orthogonal User IDs.

You can just create your own user ids and bind them to the key. Don't
laugh! See https://bitbucket.org/skskeyserver/sks-keyserver/issues/41

I am not suggesting that you should do this, or that it is or should be
meaningful. Just pointing out that the standard is incomplete in many
more ways than you might think.

> encouraging non-orthogonal User IDs.

Doesn't mean anything. Here is a key with a key in the user id:
97E4CFC94B1D6212

> point in doing it indeed), then there will be an enforced separation

enforced by whom? according to which rules?

> of
> happen:

Here is a decentralised file storage based on OpenPGP user ids and
public keyserver networks;

https://github.com/yakamok/keyserver-fs

This is using uids, but if you remove them, hacks like this will move on
to other available fields.

> for the image attribute (the only one standardized afaik), I

"What's the point?" isn't the question. Either you can enforce something
or you can't. If you can't, then you can't rely on it, and then the
value of the rule will be severly diminished.

The 4.5 million or so keys on the SKS keyservers are public, you can
download them and investigate yourself what the consistency of the
existing dataset is.  I haven't looked at photo ids yet in detail, so
those might look favorable, but that's probably just because there is
low-hanging fruit.

Just to give you an example: A local non-profit created hundreds of keys
and added signatures to the gpg maintainer's key to wish him a merry
christmas:
http://a.keyserver.pki.scientia.net/pks/lookup?op=vindex&search=0xF2AD85AC1E42B367
(scroll down)

> ID field just because it is the only one that is sanely rendered :)

For NeoPG, I'd simply use an URI scheme in the user id field, if I felt
that it should be exported.

Thanks,
Marcus

---

From: Leo Gaspard <[email-masked]>
Date: Wed, 27 Jun 2018 03:30:58 +0200

> local, and trust packets are local by a SHOULD rule (and in fact wholly

Indeed my reply was completely off-track here, and I was thinking only
of local signatures when writing this… which was stupid, given that all
the point is about making signatures for others to use.

> you have suggested from the beginning.

Well… OpenPGP already has User Attributes, hence my hope User IDs could
disappear in v5 keys. I do agree that the ship has sailed for <v5 keys,
but still hope things could be “fixed” for v5 keys. Then… maybe I'm just
hoping for something other than OpenPGP, but I would much rather have
something actually specified than yet another home-grown protocol that
will ever have a single implementer, and re-starting from scratch
doesn't sound like a good way to not have yet another home-grown protocol.

>    authority's positive act."

Well, I'm not implying that this paragraph means anything, just that
there is a concept of signature in the OpenPGP spec, and that it sounds
legitimate (to me) to want to have a way to sign only the parts of the
User ID that I want to sign :)

> more ways than you might think.

Well, thanks for this link! I never noticed this indeed, and it could
come in handy… but I don't think it's a good idea either, indeed.

> Doesn't mean anything. Here is a key with a key in the user id:

Well, the fact that some people don't respect the conventions doesn't
mean they're not conventions: in practice, nearly all keys I exchange
information with have only User IDs in the “name <mail>” format. Which
is a problem from the “signing only the mail address” standpoint.

> enforced by whom? according to which rules?

Enforced technically by the absence of a User ID field. I'm not saying
it will not be possible to misuse fields, but that the convention should
naturally follow the namings: names in the “name” fields, pseudonyms in
the “pseudonym” fields, emails in the “email” fields, roles in the
“role” fields, etc.

> to other available fields.

Well, of course it's always possible to hack around things. But I don't
really care for these hacks, they can continue to use v4 keys, or any
other field of their choosing. It's not like I'm going to sign such an
identifier anyway.

What I'm saying is that if I can have, when signing a key, a series of
dialog boxes for all names and then for all pseudonyms and then for all
email addresses etc. that ask me whether I have signed the key, then as
an end-user I'm happy. On the other hand, if I always come back on the
name I haven't checked (like on 0x57B62140, which has User IDs with your
name), then I can only growl against the software and answer “no” to all
questions, despite my having checked the email address.

> value of the rule will be severly diminished.

Well, even if I can't *enforce* that people put the right data at the
right place, if I imagine a user seeing a form like:

    Name:      [                             ]
    Pseudonym: [                             ] (add another field)
    Email:     [                             ] (add another field)
    Role:      [                             ] (add another field)
    Other:     [            ] = [            ] (add another field)

(with the “Other” potentially replaced by more user-friendly “GitHub
username”, “GitLab username”, etc.)

Then I think that 99% of legitimate users will make the correct choice.

And then I can just assume that the rule is followed, and reap the
benefit. And even if some people have fun putting files in the “name”
field, then I just won't sign their keys, and who cares?

> http://a.keyserver.pki.scientia.net/pks/lookup?op=vindex&search=0xF2AD85AC1E42B367

Well… You're describing how broken the SKS network is (not saying these
bugs are not also features), I don't see how that relates to changing
the concept of User ID: such nonsense would (a priori) still be possible
after the change, but not worse than before :)

> that it should be exported.

Well… Honestly, I think this represents a failure of the standardization
process. This use case is already present in the real world, and people
have already started using work-arounds around it. For instance, SKS
keyservers return around 460 results for “users.noreply.github.com”, and
that's only the use case I searched for because I know someone with such
a UID.

Basically, what I remember from your message is “that ship has sailed,”
and… that makes me sad. I think these use cases (signing only an email
address, or signing a GitHub identity, or even an OTR identity) do fit
into the scope of the OpenPGP standard, and I'd love to see them addressed.

But maybe it'd be better to have another protocol that'd be dedicated to
only asserting some identities and linking them to the keys for certain
protocols… that'd be splitting off the WoT into a separate protocol, but
maybe it'd be better this way? Anyway, that's getting quite far
off-track for the OpenPGP working group, and I still hope such a change
could make sense for OpenPGP v5 keys.

---

From: Wiktor Kwapisiewicz <[email-masked]>
Date: Wed, 27 Jun 2018 10:07:06 +0200

Hi Leo,

Okay, after your explanations and thinking about this through the night 
I can see some benefits. Especially to the split of names (people 
usually have only one name and it's usually verified using government 
issued IDs) and e-mails (that can be automatically verified).

There are projects [0] that want to verify e-mails and add signatures to 
indicate "verified e-mail" but because e-mail and name are joined the 
signature also covers the name (that wouldn't be necessary in your design).

Sometimes the name in UID is not welcome (see "mailbox-only" in WKD [1]).

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 
[email-masked] 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,

E-mail ID could be generalized to an URI ID (e.g. e-mail would be 
"mailto:[email-masked]"), then your "account-on" ID could also be a 
URI (e.g. https://github.com/user, or XMPP account: 
xmpp:[email-masked]) [2].

But I think the most severe issue with your proposal is the ripple 
effect it would have on the trust system. Currently one valid User ID is 
necessary to mark the key as valid. And that valid User ID means both 
the name and the e-mail (in most scenarios). But with split names and 
e-mails a more elaborate design would be needed. And that's just one case.

Kind regards,
Wiktor

[0]: https://wiki.gnupg.org/OpenPGPEmailSummit201607/EmailValidation

[1]: 
https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-06#section-4.5

[2]: Actually I've been experimenting with URIs on User IDs with defined 
verification here: https://github.com/wiktor-k/distributed-ids This is 
another spin on Vincent's Linked Identities (but using User IDs and with 
declarative verification code).

---

From: Leo Gaspard <[email-masked]>
Date: Wed, 27 Jun 2018 12:07:15 +0200

> Sometimes the name in UID is not welcome (see "mailbox-only" in WKD [1]).

Yes, that's exactly what I'm thinking of.

>   - "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.

> xmpp:[email-masked]) [2].

Indeed that's possible too. I was more thinking that the XMPP account
would be set as one of the “free form tag=value” (with
`xmpp=[email-masked]` for your example), but the two sound just as
flexible to me, so no strong opinions here.

Actually the “role” and “pseudonym” could also be of the “free form
tag=value”, but I was thinking, when adding them specifically, that
encouraging standardization to things that already appear “in the wild”
would make sense. Without strong opinions either :)

> e-mails a more elaborate design would be needed. And that's just one case.

Indeed that is a big issue with implementation of this proposal.

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).

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.

Cheers,
Leo

---

From: Wiktor Kwapisiewicz <[email-masked]>
Date: Wed, 27 Jun 2018 14:05:41 +0200

Hi Leo,

> in their User ID fields. The aim of these fields is mostly to avoid

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 
).

> 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 
).

> 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.

Kind regards,
Wiktor

---

From: Wyllys Ingersoll <[email-masked]>
Date: Wed, 27 Jun 2018 09:56:02 -0400

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. 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.  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?

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.

-Wyllys Ingersoll

On Wed, Jun 27, 2018 at 8:06 AM Wiktor Kwapisiewicz <wiktor=
[email-masked]> wrote:

> _______________________________________________
> openpgp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/openpgp
>

---

From: Leo Gaspard <[email-masked]>
Date: Wed, 27 Jun 2018 16:41:56 +0200

> 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.

> 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.”

> along the path, for a standard so widely used as OpenPGP can be hard to

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 :)

---

From: Leo Gaspard <[email-masked]>
Date: Wed, 27 Jun 2018 16:56:39 +0200

On 06/27/2018 03:56 PM, Wyllys Ingersoll wrote:
> 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*
> 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

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)

> 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 :)

---

From: Wiktor Kwapisiewicz <[email-masked]>
Date: Wed, 27 Jun 2018 21:27:53 +0200

Hello,

> of a User ID and Public-Key packet,” which isn't “Generic certification

Yes, person X certifies User ID Y of key Z. Y and Z are part of the 
signature (signed User ID + Key ID [0]) but the other party - the person 
X (issuer) puts only their key ID as a part of the signature, not their 
User ID [1]. Thus you still need validity per key to know if you can 
trust Person X's certifications. [2]

[0]: This is described here: 
https://tools.ietf.org/html/rfc4880#section-5.2.4

[1]: There is Signer's User ID subpacket but it's rarely used and not 
used for key certifications as far as I know.

[2]: Personally, having issuer's User ID be part of trust calculations 
seems to be overly complex, what difference does it make if it's the 
same person signing the key?

> additional change that wouldn't be delayed as much :)

Well, this is the most complex change suggested that I've seen here, 
everything else is mostly backwards compatible (note that there is not 
much traffic here ;) ).

> IDs everyone with their custom scheme for this purpose 

This is already possible with trust signatures with domain restriction. 
If GitHub had their key (and that's a big if) and signed their user's 
IDs that have e-mails in form [email-masked] with trust sig 
level 1 then you could trust sign GitHub's key with trust signature 
level 2 limiting that to the users.noreply.github.com domain.

The same approach with trust signatures could be used by organizations 
and their "role" system.

This article goes into more detail:

https://www.linuxfoundation.org/blog/pgp-web-of-trust-delegated-trust-and-keyservers/

I think that's all from me now, take care!

Kind regards,
Wiktor

---

From: Leo Gaspard <[email-masked]>
Date: Thu, 28 Jun 2018 01:37:58 +0200

> same person signing the key?

Well, I agree with you until the “Thus”. You don't need validity per key
to know if you can trust Person X's certifications, you only need
ownertrust :)

And I think we stopped understanding each other at some point, at least
I didn't mean to imply that we should insert the issuer's User ID into
trust calculations.

What I'm saying is:

 * When you “sign a key”, you actually sign a (Key, User ID)
association, so the “validity” is actually a property of the (Key, User
ID) couple, not of the key.

 * When you want to verify a (Key, User ID) validity, you list the
signatures. In the signatures, you look for signatures of keys you trust
(as in ownertrust, which AFAIR isn't defined in rfc4880, apart from in
trust signatures). If you trust enough keys that signed the (Key, User
ID) couple, then you can consider it valid.

 * Trust is completely decoupled from validity, and you could perfectly
trust a key that's not valid to you (even though I can't think of a
reasonable use case for it).

 * Trust signatures extend this scheme by allowing a trusted key to
introduce you to other keys that will then become trusted (and most
likely valid, because the trust signature is also a signature -- all
this depends on local policy).

And, with this in mind, I can't find a reasonable concept of “valid
key”, only of “valid key-User Id associations”, which would become under
my proposal “valid key-User Attribute associations”, and would likely
decrease the risk of UIs misleading the user into thinking that a key is
“valid”, whatever that could mean.

And in particular of showing an unvalidated User ID just because it is
the primary User ID.

> everything else is mostly backwards compatible (note that there is not

Indeed, then anyway rfc4880bis isn't anywhere close to completion as the
WG was even closed, so I guess it's not really pressing matters. But
yes, implementation weight is, in my mind, the biggest (and potentially
blocking, though I can't speak for implementers) drawback of this idea.

> level 2 limiting that to the users.noreply.github.com domain.

Indeed, but that requires all users to “naturally standardize” on
[email-masked]. Everything I propose can be done with the
current User ID scheme. Heck, it's even possible to just “naturally
standardize” on putting “name=My Name”, “email=[email-masked]”,
etc. in the User ID fields.

The main thing I try to do with this proposal is to give things a place
“by standard”, thus allowing tools to rely on it and eg. assume that in
the “name” attribute then it is the name of the person, without having
to parse the User ID field and try to guess which “natural standard”
this specific key has followed :)

BTW, just for completeness, the current tsign-based scheme wouldn't
require GitHub to issue trust-signatures to keys, it could work the
following way:
 * Users put [email-masked] User IDs
 * GitHub issues normal signatures on validated (Key, User ID in
[email-masked] format) pairs
 * Users willing to trust GitHub add a Trust Packet with trust level 255
(because why not, trust level 1 would be enough but could be considered
lower than “marginal” and thus not actually be enough to validate
associations) and a limitation to [email-masked] to their
local copy of the GitHub key (or can alternatively use a trust signature
if they feel like it)

> https://www.linuxfoundation.org/blog/pgp-web-of-trust-delegated-trust-and-keyservers/

Indeed that's possible, but it requires “naturally standardizing” for
eg. roles in comment sections of User IDs. And in my mind de facto
standardization that isn't recognized by the standard means that de jure
standardization has failed.

Anyway, that's all I have to say, I think, so if I receive no positive
feedback I guess I'll just try to, within a few years, turn my idea into
yet another protocol with its single implementation, and see what
happens. :)

---

From: Jon Callas <[email-masked]>
Date: Wed, 27 Jun 2018 18:44:39 -0700

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?

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.

There’s no reason you can’t put whatever you want in some other sub-packet or what.

	Jon

---

From: Leo Gaspard <[email-masked]>
Date: Thu, 28 Jun 2018 11:35:24 +0200

> 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 attenti…

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…

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=[email-masked], 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? :)

> There’s no reason you can’t put whatever you want in some other
sub-packet or what.

The problem with putting it in another sub-packet is that it can't
replace User IDs, and User IDs will thus always be the thing that is
used for signature and verification. And this would mean there would be
no point in this change.

---

From: Jon Callas <[email-masked]>
Date: Thu, 28 Jun 2018 17:38:09 -0700

> On Jun 28, 2018, at 2:35 AM, Leo Gaspard <ietf=[email-masked]> wrote:
> 

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

---

From: Wiktor Kwapisiewicz <[email-masked]>
Date: Fri, 29 Jun 2018 09:45:55 +0200

Hi Jon,

This is slightly off-topic but...

> 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 addresse…

 From what I've seen Keybase is not interested in purely OpenPGP 
solution - they want to keep the data on their site [0].

And there already is I-D for "keybase but distributed" using OpenPGP - 
Linked Identities by Vincent [1]. Moreover this draft is already 
implemented in OpenKeychain and has verifications for Twitter, GitHub, 
etc. and works really well. I think the concept is proven to be working. 
(The only issue that I have with it it's that it's using experimental 
UAT IDs, but because Linked IDs is just a draft it cannot get proper 
assignment).

I've been experimenting on a slightly different implementation of 
Vincent's concept (using User IDs and notations instead of Attributes, 
and defined verification language) [2].

Also, a quote from Werner over the use of user attributes from 2017 [3]:

> (...) Anyway, I think that the User
> Attributes should not be extended over their use for an image.  URIs can
> simply be represented by plain User IDs and software can easily detected
> such URIs if desired.
> 
> The need to implement UAT only adds more complexity for a questionable
> purpose.  Note that these image UAT were introduced due to marketing
> needs of PGP or NAT and (iirc) only specified after they had been
> introduced in their software.

I didn't agree with him back then, but after longer thought I changed my 
opinion - user attributes do not have any fallback mechanism - either 
most software supports that custom special attribute or it's practically 
impossible to work with them (yes, they are supported, but displayed as 
an opaque string [4]). And I say this as a person that added this packet 
"by hand" and use it on my key.

(As a side note, photos could be expressed as links to images with a 
hash, that would reduce the key size significantly).

On the other hand I like the "hand wavy" approach to User IDs, I think 
it's underutilized :-)

Kind regards,
Wiktor

[0]: https://news.ycombinator.com/item?id=15352217

[1]: https://tools.ietf.org/html/draft-vb-openpgp-linked-ids-01

[2]: https://github.com/wiktor-k/distributed-ids

[3]: https://www.ietf.org/mail-archive/web/openpgp/current/msg08914.html

[4]: 
https://keyserver.ubuntu.com/pks/lookup?fingerprint=on&search=0x653909A2F0E37C106F5FAF546C8857E0D8E8F074

-- 
*/metacode/*

---

From: Leo Gaspard <[email-masked]>
Date: Fri, 29 Jun 2018 21:22:23 +0900

> 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, a…

Indeed, that's exactly what I was hoping for, sorry for forgetting to
put in my summary that it'd be in User Attribute packets that I'd put
the relevant data :)

However, I was thinking of something a bit more extreme for the switch:
completely forbidding the User ID packet type in v5 keys, so that
software written for it could just assume it's in the “split” format.
That said, that's maybe a bit too extreme indeed.

> 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 d…

Well that's likely best, but given I don't think I'll have time to
become a developer of OpenPGP software for at least a few months, I was
hoping to get positive feedback on the idea from at least one developer,
who'd be willing to try and implement such a draft were I to write it,
before spending too much time on writing the said draft :) but it sounds
like I'm having little luck for the time being.

---

From: Leo Gaspard <[email-masked]>
Date: Fri, 29 Jun 2018 21:40:25 +0900

> "by hand" and use it on my key.

Well, User IDs are not easier to work with than User Attributes. The
only difference is that User IDs have been defined to be free-form
UTF-8, while the only User Attribute that has been defined (up to now)
is the picture type. And thus the only User Attribute that's easy to
work with is the picture User Attribute… which sounds logical.

OTOH, supposing my idea was introduced, then the additionally-defined
User Attributes would become mandatorily supported in v5 keys (among
other reasons because there would no longer be any User ID), and there
would be a free-form tag=value type (with both tag and value being UTF-8).

Then it would become possible to just add “url=*” tags for the Linked
Identities, or even, as anyways the current draft requires that “An
implementation SHOULD NOT perform verification based on a generic
mechanism” (and thus that every supported service must be explicitly
listed), it could just be changed to “service=identifier”, thus without
a URI, easier to understand when the UI doesn't support it specifically
than a full-blown URL with access-to-the-cookie metadata. (if
access-to-the-cookie metadata is needed anyway, it can be put in a
Notation Data subpacket, thus being hidden from tools that don't care
about it, while being present for tools that can do automated verification)

> hash, that would reduce the key size significantly).

Well that'd be a possibility too, but I'm not sure people would want to
fetch a website (and thus enter into the logs of this website) when they
open a picture ID :)

---

From: Wiktor Kwapisiewicz <[email-masked]>
Date: Fri, 29 Jun 2018 14:55:30 +0200

> Well, User IDs are not easier to work with than User Attributes.

Leo by "are not easier to work with" did you mean "User Attributes 
*could be* as easy to work with as UIDs" if you proposal was accepted 
*and* supported by most OpenPGP software?

I think the difference is quite significant (by what is working now vs 
hypothetical future).

If you mean they are easy to work with now do tell me what's that 
attribute for that I've got on my key 
(0x653909A2F0E37C106F5FAF546C8857E0D8E8F074):

   uid  [ultimate] Wiktor Kwapisiewicz <[email-masked]>
   uid  [ultimate] [unknown attribute of size 83]

I had a lot of questions about this attribute from other people, so it's 
not like attributes are currently "easy to work with" in my opinion.

Kind regards,
Wiktor

-- 
*/metacode/*

---

From: Derek Atkins <[email-masked]>
Date: Fri, 29 Jun 2018 13:02:24 -0400

> would be a free-form tag=value type (with both tag and value being UTF-8).

May I point you to the (expired) document,
draft-atkins-openpgp-device-certificates which started down the road of
adding additional Attribute packets.

Would something like that help?

-derek
-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Leo Gaspard <[email-masked]>
Date: Sat, 30 Jun 2018 21:34:37 +0900

> *and* supported by most OpenPGP software?

I should have said “User IDs are not easier to work with than specified
User Attributes”, indeed. The fact that the only specified User
Attribute is a picture User Attribute, that has little use, is something
that contributes to the bad reputation of User Attributes.

But User IDs are (binary representation aside) exactly like a User
Attribute with type -1 that would be defined as “any UTF-8 string that
more or less represents the user”. Once reworded this way, would you
still oppose the addition of more well-defined attributes? (NB: this
would be for v5 keys, so software would have to be updated anyway, and
adding a basic representation for a few UTF-8 User Attributes doesn't
sound like the biggest change in the game -- though if User IDs were
removed too, as I'd love, then this may be the biggest change, at least
for the UI side)

All I'm saying is: we should not be wary of defining User Attributes.
It's a woefully underused part of the standard, and the fact it's so
underused (and specified for a single almost-useless purpose) makes
people fear using them.

> not like attributes are currently "easy to work with" in my opinion.

Well, using unspecified User Attributes will get you a lot of questions
indeed. But if you started putting packets with unspecified tags on your
key you likely would break a number of tools too, that doesn't mean
packets aren't easy to work with :)

BTW, it appears to contain

openpgpid+cookie:@https://gist.github.com/wiktor-k/389d589dd19250e1f9a42bc3d5d40c16
This is a typical example of something that would deserve a *specified*
User Attribute, like
    github=wiktor-k (with type “free-form tag=value” and notation
“automated-verification-gist=389d589dd19250e1f9a42bc3d5d40c16”)

Which would display neatly on platforms that support the very simple
type=“free-form tag=value” User Attribute I'm proposing (it's UTF-8),
and be quite easy-to-understand to the end-user seeing this if there is
no support in their software for the specific “github” tag (at least
more than the openpgpid+cookie URL).

Actually the “free-form tag=value” is really the most important type of
User Attribute I'm putting forward: it is a building block that is
enough for almost all other purposes, but that cannot be replicated
using only what we currently have without awful hacks (eg. storing
type=value directly in the User ID field, which is the “least bad”
option with RFC4880 as it is currently defined).

---

From: Leo Gaspard <[email-masked]>
Date: Sat, 30 Jun 2018 21:43:40 +0900

> Would something like that help?

Indeed, I hadn't seen this!

This is adding a User Attribute subpacket type for a reason completely
different from the reason I have, and even going a bit in opposition to
the movement I was trying to set (which would have led to the definition
of a “Device ID” attribute subpacket type that wouldn't “by convention,
[include] a mail name-addr”, because that possibly makes no sense, and
if it does it can be replicated with “Device ID” + “email” attribute
subpackets).

But the idea of adding User Attributes that are actually readable by
humans is the same, so that they can be easily understood by humans even
when using implementations that can't fully handle them (only the bare
minimum of displaying UTF-8) :)