[openpgp] Scoped trust (signatures)

[Neal H. Walfield]

Hi Leo,

On Fri, 18 May 2018 22:26:03 +0200,

As I understand it, RFC4880 already has a provision for such a model,
with $B!x(B5.2.3.14 _Regular Expression_.
However, there is from my reading an issue with (the wording of) this
section: it only restricts one-level trust signatures. In other words,

For reference, here's the relevant text:

5.2.3.14. Regular Expression

Used in conjunction with trust Signature packets (of level > 0) to
limit the scope of trust that is extended. Only signatures by the
target key on User IDs that match the regular expression in the body
of this packet have trust extended by the trust Signature subpacket.

I interpret this differently. I interpret "to limit the scope of the
trust that is extended" to mean that the source extends *its* trust to
the target. That is, trust is not somehow reset when following an
edge in the graph, but either passed on as is or narrowed.

think all regular expressions in the trust chain should have to match in
order to not be rejected -- in a similar fashion as the DNSSEC model.

Even if the standard is wrong here, this is definitely a more useful
and non-broken approach, and, I suspect, almost certainly what was
intended.

Another issue of this scheme, obviously, is that noone $B!H(Bin the wild$B!I(B
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.

:) Neal

[Leo Gaspard]

Post by Neal H. Walfield

Another issue of this scheme, obviously, is that noone $B!H(Bin the wild$B!I(B
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 $B!H(BName (Comment)
<***@example.org>$B!I(B. And, even if assuming this, how could the
implementation validate the $B!H(BName$B!I(B and $B!H(BComment$B!I(B 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$B!D(B), 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 $B!H(Bname$B!I(B, an $B!H(Bemail$B!I(B and
a $B!H(Bpseudonym$B!I(B user attribute. (I'm not sure about the $B!H(Bcomment$B!I(B user
attribute, and would prefer seeing it handled otherwise, see the
$B!H(BPossible extensions$B!I(B 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 $B!H(Bemail$B!I(B User Attributes after
checking I could send and receive mail to the provided email, I could
sign $B!H(Bname$B!I(B attributes after checking a state-provided ID, and I could
sign $B!H(Bpseudonym$B!I(B and $B!H(Bcomment$B!I(B 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 $B!H(Bcan only sign `email` User Attributes and the part after the
last @ must match this restriction$B!I(B.


Possible extensions
-------------------

So now with this change it would become possible to handle extensions of
the User IDs that have been proposed.

First, the $B!H(B[project] signing key$B!I(B comment, that can be seen eg.
[here](https://sks-keyservers.net/pks/lookup?op=vindex&search=0x8B3F30F9C8C0C2EF).
This could be handled by adding a $B!H(Brole$B!I(B User Attribute, that could be
$B!H(BQubes OS developer$B!I(B 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 $B!H(BI have this account on this website$B!I(B, 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
$B!H(Baccount-on$B!I(B that would store both a domain name (for the website) and a
username.

Finally, I think it would be good to stay more $B!H(Bopen to extensions$B!I(B than
the current scheme of (mis)using User IDs, by eg. reserving attribute
type 255 for $B!H(Bplaintext key-value user ID$B!I(B, 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 $B!H(Bvalidate the one it came as$B!I(B or $B!H(Bshow all
the valid ones$B!I(B, and thus removing the Primary UID may remove some traps
naive implementations may fall in, like displaying a non-validated
primary UID.

Post by Neal H. Walfield

As I understand it, RFC4880 already has a provision for such a model,
with $B!x(B5.2.3.14 _Regular Expression_.
However, there is from my reading an issue with (the wording of) this
section: it only restricts one-level trust signatures. In other words,

[snip]
I interpret this differently. I interpret "to limit the scope of the
trust that is extended" to mean that the source extends *its* trust to
the target. That is, trust is not somehow reset when following an
edge in the graph, but either passed on as is or narrowed.

Indeed, it looks like I had misinterpreted this, thanks!

[Vincent Breitmoser]

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.

Been there, done that: https://tools.ietf.org/html/draft-vb-openpgp-linked-ids-01
It's also implemented and deployed as an experimental feature in OpenKeychain.

As a more general note, it would be nice if we could drop the requirement to
have at least one (unsigned) user id, in which case the primary key gets its
properties from a (then mandatory) direct key signature. For key distribution
models other than searchable-by-uid keyservers (including autocrypt and wkd),
user ids can quickly become unnecessary metadata.

- V

[Leo Gaspard]

Post by Vincent Breitmoser

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.

Been there, done that: https://tools.ietf.org/html/draft-vb-openpgp-linked-ids-01
It's also implemented and deployed as an experimental feature in OpenKeychain.

Hmm, this sounds like not solving the exact same issue: I was thinking
of a user asserting “I am [X] on service [Y]”, and (if I read correctly
your I-D) your proposal included having the OpenPGP implementation doing
the validation of this statement.

I think having the OpenPGP implementation doing the validation of such
statements is *really* hard to do. For instance, the section 4.4 of your
I-D doesn't explain how to do it, and I don't think it reasonably could
(you mention yourself that a proper VERIFY operation requires additional
insight on the specifics of each service).

This is the reason why I was only proposing a way to include in a User
ID “I am [this person]”, and then leave validation of this statement to
the same mechanism as the usual User IDs: I think this has a chance to
get in RFC4880bis, while having a more complex and
modifying-the-trust-model scheme could only live in a separate RFC,
especially when it potentially has implications on the privacy (as the
services would then know when I attempt to verify a User ID).

As for the validation of this User ID, with only my proposal, it could
be handled in the same way as email addresses: scoped trust for the
domain, that would be trusted to sign User IDs. Or scoped trust for
keybase.io (or any other equivalent service), that would be trusted to
validate the cookie online and sign the keys accordingly. Actually,
email is just a special case of an account on an online service, but I
think handling it separately makes sense, as eg. @github.com email
addresses won't be the same as @users.noreply.github.com ones.

That said, I do believe there is value in your proposal (eg. not relying
on a trusted third-party when the upstream service doesn't have a public
key that could be trusted), but I also think these two approaches are
complementary.

Post by Vincent Breitmoser
As a more general note, it would be nice if we could drop the requirement to
have at least one (unsigned) user id, in which case the primary key gets its
properties from a (then mandatory) direct key signature. For key distribution
models other than searchable-by-uid keyservers (including autocrypt and wkd),
user ids can quickly become unnecessary metadata.

With the changes I proposed, there would no longer be any User ID in v5
keys (the User ID subpacket would just be forbidden there, and likely
Primary User ID too).

There could be an arbitrary number of User Attributes, like now,
because, as you mentioned, it may make sense to not have any for eg.
TOFU use.

[Leo Gaspard]

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.

Post by Leo Gaspard

Post by Neal H. Walfield

Another issue of this scheme, obviously, is that noone $B!H(Bin the wild$B!I(B
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 $B!H(BName (Comment)
implementation validate the $B!H(BName$B!I(B and $B!H(BComment$B!I(B parts, when the Regular
Expression support is replaced by something to validate by domain?
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$B!D(B), 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 $B!H(Bname$B!I(B, an $B!H(Bemail$B!I(B and
a $B!H(Bpseudonym$B!I(B user attribute. (I'm not sure about the $B!H(Bcomment$B!I(B user
attribute, and would prefer seeing it handled otherwise, see the
$B!H(BPossible extensions$B!I(B 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 $B!H(Bemail$B!I(B User Attributes after
checking I could send and receive mail to the provided email, I could
sign $B!H(Bname$B!I(B attributes after checking a state-provided ID, and I could
sign $B!H(Bpseudonym$B!I(B and $B!H(Bcomment$B!I(B attributes depending on my local signing
policy (which I haven't really determined yet).
it'd be $B!H(Bcan only sign `email` User Attributes and the part after the
Possible extensions
-------------------
So now with this change it would become possible to handle extensions of
the User IDs that have been proposed.
First, the $B!H(B[project] signing key$B!I(B comment, that can be seen eg.
[here](https://sks-keyservers.net/pks/lookup?op=vindex&search=0x8B3F30F9C8C0C2EF).
This could be handled by adding a $B!H(Brole$B!I(B User Attribute, that could be
$B!H(BQubes OS developer$B!I(B 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 $B!H(BI have this account on this website$B!I(B, 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
$B!H(Baccount-on$B!I(B that would store both a domain name (for the website) and a
username.
Finally, I think it would be good to stay more $B!H(Bopen to extensions$B!I(B than
the current scheme of (mis)using User IDs, by eg. reserving attribute
type 255 for $B!H(Bplaintext key-value user ID$B!I(B, 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 $B!H(Bvalidate the one it came as$B!I(B or $B!H(Bshow all
the valid ones$B!I(B, and thus removing the Primary UID may remove some traps
naive implementations may fall in, like displaying a non-validated
primary UID.

[Wiktor Kwapisiewicz]

Hi Leo,

Post by Leo Gaspard
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.

Standarization and implementation of new User Attributes would take
ages, and the existing User IDs are just good enough.

Post by Leo Gaspard

Post by Leo Gaspard
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?

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

Post by Leo Gaspard

Post by Leo Gaspard
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$B!D(B), and is now again an issue in
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.

Post by Leo Gaspard

Post by Leo Gaspard
So here is my idea: drop User IDs in v5 keys, and standardize more User
Attributes. In particular, standardize at least a $B!H(Bname$B!I(B, an $B!H(Bemail$B!I(B and
a $B!H(Bpseudonym$B!I(B user attribute. (I'm not sure about the $B!H(Bcomment$B!I(B user
attribute, and would prefer seeing it handled otherwise, see the
$B!H(BPossible extensions$B!I(B 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

Post by Leo Gaspard
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.

Post by Leo Gaspard

Post by Neal H. Walfield

Another issue of this scheme, obviously, is that noone $B!H(Bin the wild$B!I(B
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 $B!H(BName (Comment)
implementation validate the $B!H(BName$B!I(B and $B!H(BComment$B!I(B parts, when the Regular
Expression support is replaced by something to validate by domain?
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$B!D(B), 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 $B!H(Bname$B!I(B, an $B!H(Bemail$B!I(B and
a $B!H(Bpseudonym$B!I(B user attribute. (I'm not sure about the $B!H(Bcomment$B!I(B user
attribute, and would prefer seeing it handled otherwise, see the
$B!H(BPossible extensions$B!I(B 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 $B!H(Bemail$B!I(B User Attributes after
checking I could send and receive mail to the provided email, I could
sign $B!H(Bname$B!I(B attributes after checking a state-provided ID, and I could
sign $B!H(Bpseudonym$B!I(B and $B!H(Bcomment$B!I(B attributes depending on my local signing
policy (which I haven't really determined yet).
it'd be $B!H(Bcan only sign `email` User Attributes and the part after the
Possible extensions
-------------------
So now with this change it would become possible to handle extensions of
the User IDs that have been proposed.
First, the $B!H(B[project] signing key$B!I(B comment, that can be seen eg.
[here](https://sks-keyservers.net/pks/lookup?op=vindex&search=0x8B3F30F9C8C0C2EF).
This could be handled by adding a $B!H(Brole$B!I(B User Attribute, that could be
$B!H(BQubes OS developer$B!I(B 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 $B!H(BI have this account on this website$B!I(B, 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
$B!H(Baccount-on$B!I(B that would store both a domain name (for the website) and a
username.
Finally, I think it would be good to stay more $B!H(Bopen to extensions$B!I(B than
the current scheme of (mis)using User IDs, by eg. reserving attribute
type 255 for $B!H(Bplaintext key-value user ID$B!I(B, 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 $B!H(Bvalidate the one it came as$B!I(B or $B!H(Bshow all
the valid ones$B!I(B, and thus removing the Primary UID may remove some traps
naive implementations may fall in, like displaying a non-validated
primary UID.

[Leo Gaspard]

Hi Wiktor,

Post by Leo Gaspard

Post by Leo Gaspard
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.
Standarization and implementation of new User Attributes would take
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.

Post by Leo Gaspard

Post by Leo Gaspard

Post by Leo Gaspard
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?

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

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.

Post by Leo Gaspard

Post by Leo Gaspard

Post by Leo Gaspard
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.

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.

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.

Post by Leo Gaspard

Post by Leo Gaspard

Post by Leo Gaspard
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)

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.

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?

Post by Leo Gaspard
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.

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.

Post by Leo Gaspard
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

[Wiktor Kwapisiewicz]

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
***@developers.qubes.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,

E-mail ID could be generalized to an URI ID (e.g. e-mail would be
"mailto:***@example.com"), then your "account-on" ID could also be a
URI (e.g. https://github.com/user, or XMPP account:
xmpp:***@example.com) [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).

[Leo Gaspard]

Post by Neal H. Walfield
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]).

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

Post by Neal H. Walfield
  - "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
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.

Post by Neal H. Walfield
E-mail ID could be generalized to an URI ID (e.g. e-mail would be

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=***@example.com` 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 :)

Post by Neal H. Walfield
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.

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

[Wiktor Kwapisiewicz]

Hi Leo,

Post by Leo Gaspard

Post by Neal H. Walfield
  - "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
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
).

Post by Leo Gaspard
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
).

Post by Leo Gaspard
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.

Kind regards,
Wiktor

[Wyllys Ingersoll]

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=

Post by Neal H. Walfield
Hi Leo,

Post by Leo Gaspard

Post by Wiktor Kwapisiewicz
- "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
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
https://dkg.fifthhorseman.net/blog/openpgp-user-id-comments-considered-harmful.html
).

Post by Leo Gaspard
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
https://www.linux.com/learn/pgp-web-trust-core-concepts-behind-trusted-communication
).

Post by Leo Gaspard
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.
Kind regards,
Wiktor
_______________________________________________
openpgp mailing list
https://www.ietf.org/mailman/listinfo/openpgp

[Leo Gaspard]

Post by Wyllys Ingersoll
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 :)

Post by Wyllys Ingersoll
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.

Post by Wyllys Ingersoll
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)

Post by Wyllys Ingersoll
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 :)

[Leo Gaspard]

Post by Neal H. Walfield
Hi Leo,

Post by Leo Gaspard

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

Post by Neal H. Walfield

Post by Leo Gaspard
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
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.”

Post by Neal H. Walfield

Post by Leo Gaspard
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 :)

[Wiktor Kwapisiewicz]

Hello,

Post by Leo Gaspard
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.”

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?

Post by Leo Gaspard

Post by Wiktor Kwapisiewicz
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 :)

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

Post by Leo Gaspard
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

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 *@users.noreply.github.com 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

[Leo Gaspard]

Hello,

Post by Leo Gaspard
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.”

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

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.

Post by Leo Gaspard

Post by Wiktor Kwapisiewicz
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 :)

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

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.

Post by Leo Gaspard
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

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
level 1 then you could trust sign GitHub's key with trust signature
level 2 limiting that to the users.noreply.github.com domain.

Indeed, but that requires all users to “naturally standardize” on
*@users.noreply.github.com. 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=***@example.org”,
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 *@users.noreply.github.com User IDs
* GitHub issues normal signatures on validated (Key, User ID in
*@users.noreply.github.com 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 *@users.noreply.github.com to their
local copy of the GitHub key (or can alternatively use a trust signature
if they feel like it)

The same approach with trust signatures could be used by organizations
and their "role" system.
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. :)

[Marcus Brinkmann]

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.

Post by Leo Gaspard
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.

[Leo Gaspard]

Post by Marcus Brinkmann
I think the problem you are facing is Zooko's triangle: Decentralised,
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.)

Post by Marcus Brinkmann
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.

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.

Post by Marcus Brinkmann
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.

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

[Marcus Brinkmann]

Post by Leo Gaspard

Post by Marcus Brinkmann
I think the problem you are facing is Zooko's triangle: Decentralised,
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)

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

Post by Leo Gaspard
Also, I am not trying to solve Zooko's triangle, only to decouple
elements that are currently tightly interwoven without any reasonable
roles in comments, etc.)

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.

Post by Leo Gaspard

Post by Marcus Brinkmann
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.

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

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

Post by Leo Gaspard
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.

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.

Post by Leo Gaspard
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.

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

Post by Leo Gaspard
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

enforced by whom? according to which rules?

Post by Leo Gaspard
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

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.

Post by Leo Gaspard
for the image attribute (the only one standardized afaik), I
haven't heard (yet?) of people using it for storing anything else than
* 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.

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

Post by Leo Gaspard
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 :)

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

Thanks,
Marcus

[Leo Gaspard]

Post by Marcus Brinkmann

Post by Leo Gaspard

Post by Marcus Brinkmann
I think the problem you are facing is Zooko's triangle: Decentralised,
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)

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

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.

Post by Marcus Brinkmann

Post by Leo Gaspard
Also, I am not trying to solve Zooko's triangle, only to decouple
elements that are currently tightly interwoven without any reasonable
roles in comments, etc.)

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.

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.

Post by Marcus Brinkmann

Post by Leo Gaspard

Post by Marcus Brinkmann
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.

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

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

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

Post by Marcus Brinkmann

Post by Leo Gaspard
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.

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.

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.

Post by Marcus Brinkmann

Post by Leo Gaspard
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.

97E4CFC94B1D6212

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.

Post by Marcus Brinkmann

Post by Leo Gaspard
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

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.

Post by Marcus Brinkmann

Post by Leo Gaspard
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

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.

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.

Post by Marcus Brinkmann

Post by Leo Gaspard
for the image attribute (the only one standardized afaik), I
haven't heard (yet?) of people using it for storing anything else than
* 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.

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

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?

Post by Marcus Brinkmann
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
http://a.keyserver.pki.scientia.net/pks/lookup?op=vindex&search=0xF2AD85AC1E42B367
(scroll down)

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

Post by Marcus Brinkmann

Post by Leo Gaspard
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 :)

For NeoPG, I'd simply use an URI scheme in the user id field, if I felt
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.

[Jon Callas]

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

[Leo Gaspard]

Post by Jon Callas
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!

Post by Jon Callas
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=***@example.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? :)

Post by Jon Callas
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.

[Jon Callas]

Post by Leo Gaspard

Post by Jon Callas
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!

Post by Jon Callas
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
* 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)
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

[Wiktor Kwapisiewicz]

Hi Jon,

This is slightly off-topic but...

Post by Jon Callas
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.

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

Post by Jon Callas
(...) 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

[Leo Gaspard]

Post by Wiktor Kwapisiewicz

Post by Jon Callas
(...) 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.

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)

Post by Wiktor Kwapisiewicz
(As a side note, photos could be expressed as links to images with a
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 :)

[Wiktor Kwapisiewicz]

Post by Leo Gaspard
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 <***@metacode.biz>
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

[Leo Gaspard]

Post by Wiktor Kwapisiewicz

Post by Leo Gaspard
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 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.

Post by Wiktor Kwapisiewicz
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
  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.

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

[Derek Atkins]

Post by Leo Gaspard
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).

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

[Leo Gaspard]

Post by Derek Atkins

Post by Leo Gaspard
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).

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?

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

[Jon Callas]

Post by Wiktor Kwapisiewicz
Hi Jon,
This is slightly off-topic but...

Post by Jon Callas
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.

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

So it’s not worthwhile solving this problem? Or are you saying that because they are doing it no one else should do it in a standard way?

I think it’s really cool that Keybase lets you authenticate these other networking points. And it sounds like this is at least part of the problem.

Post by Wiktor Kwapisiewicz
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].

Post by Jon Callas
(...) 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.

I don’t agree with him now. This is *precisely* the sort of thing that User Attributes were created to solve.

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

Sounds like a privacy-surly mechanism to me.

There are many problems around the Internet today where external links cause fetches that then cause DNS lookups, SSL fetches, leakages of SNI information and others. Keeping the relevant data in a blob is privacy-friendly.

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

Sure, but it means that you are using a generic text field in ways that are hard to parse. Why not define it?

Jon

[Wiktor Kwapisiewicz]

Post by Jon Callas

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

So it’s not worthwhile solving this problem? Or are you saying that because they are doing it no one else should do it in a standard way?

I'm saying Keybase - as a company - will not do it in a standard way,
that's all, no hidden meaning there.

Post by Jon Callas
I think it’s really cool that Keybase lets you authenticate these other networking points. And it sounds like this is at least part of the problem.

Yeah, I like it too. But you know what's really cool? That there already
*is* an I-D for that but using OpenPGP:
https://tools.ietf.org/html/draft-vb-openpgp-linked-ids-01

I highly recommend reading that, it's already implemented and working in
OpenKeychain. It uses User Attributes.

Actually I asked for it to get the proper User Attribute ID assigned:

https://www.ietf.org/mail-archive/web/openpgp/current/msg08913.html

It did not happen.

Post by Jon Callas

Post by Wiktor Kwapisiewicz
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.

I don’t agree with him now. This is *precisely* the sort of thing that User Attributes were created to solve.

Maybe that's just me but what's the difference between User Attribute
that has value "https://github.com/wiktor-k" and a User ID that has
value "https://github.com/wiktor-k"? I see only one - you can read the
User ID just fine using existing frontends and UAT will be "opaque".
User Attribute will have ID, right.

Post by Jon Callas
Sure, but it means that you are using a generic text field in ways that are hard to parse. Why not define it?

I'm not opposed to defining it (actually I'd very much welcome that!).
But the difference between User ID that has URI format and User
Attribute that has URI format does not affect the difficulty of parsing
(you still need to handle broken data in both cases).

Kind regards,
Wiktor

[Leo Gaspard]

Post by Jon Callas

Post by Leo Gaspard
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.

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.

Post by Jon Callas
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.

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.

[Jon Callas]

Hello,
I have subscribed to this list only recently (late 2016), so please
forgive me if this has already been discussed, as I couldn't find it in
the ML archives. I also hope I didn't miss something fundamental while
writing down this idea.

No problem. Since I wrote that text, I can provide some color. I think gentle persons can also disagree, so I'm not saying what I think is law, merely that I wrote it, and therefore I think I can give some indication of what the group consensus meant. Group consensus is often vague, wishy-washy, etc.

As I understand it, currently, with OpenPGP, it is possible to simulate
* The clients wishing to use it assign full trust to the root CAs
* Root CAs use 255-trust trust signatures for subordinate CAs
* Subordinate CAs sign the verified OpenPGP keys

That's pretty much the intent. The idea is that you should be able to mark a key as being something like a CA.

Two important things to remember about OpenPGP philosophy are: (1) OpenPGP democratizes being a CA. All keys can sign, endorse, etc. and (2) Trust is also democratized in that trust is in the eye of the beholder. Also note that in many cases the beholder might be an organization. That organization might push its policy to its members, and be polite enough to scope that trust only to keys operating in that environment.

I think it would be great to also be able to simulate the DNSSEC model,
so that as a client I would be able to say “I trust [this key] to make
statements about [this set of keys].” I see it as, is in a way, a
logical follow-up of Web Key Directory.

I suppose.

As I understand it, RFC4880 already has a provision for such a model,
with §5.2.3.14 _Regular Expression_.
However, there is from my reading an issue with (the wording of) this
section: it only restricts one-level trust signatures. In other words,
think all regular expressions in the trust chain should have to match in
order to not be rejected -- in a similar fashion as the DNSSEC model.

Well, I think I disagree. I think that if I am trusting ca-a.com with scope at the root, subordinates cannot widen that scope. Scope is supposed to be narrowed only through subordinates. If that weren't true, then your subordinate that issues trust for example.org could just as easily issue it for ".*" and now all of a sudden the subordinate gets to sign everything, and that's the opposite of what scoping even means.

Another issue of this scheme, obviously, is that noone “in the wild”
currently uses regular expression subpackets (that I know of). However,
I hope this could change, were this change to allow creation of scoped
CAs, that would interact nicely with WKD.

Yup, it's a little-used feature. So little used that I don't know of anyone using it, either.

For instance, a mail provider could set up such a “CA”, that would
automatically sign all keys that would pass the WKD test, and for which
the UID would be confirmed as valid by the internal database. Then,
users could start trusting such mail-provider-provided CAs, for
additional validation of the user ID (in addition to the localpart
already “validated” by HTTPS), while still restricting them for only
being valid for the domain(s) they own. For easy discovery,
mail-provider-provided CAs could have a path at
.well-known/openpgpkey/mail-provider-key, and the user could decide to
add some trust to this CA.

I believe that is pretty much the intended use case. The idea is that if I'm a member of an club (or company, etc.), then that club can bring in new members and I don't have to go to the trouble of trusting their keys, it happens for me.

In the naive trust model, I can say, "Whatever Alice signs is okay with me." This is obviously giving Alice a lot of power.

The trust-extension feature says, "Alice can deputize others to sign for her" and also permits those deputies to have deputies to some specified depth. This is obviously extending Alice's power in huge ways. Even with a level of only one, the only limit on Alice's power is that she has to deputize new deputies, but she has unbounded power to deputize.

The scoping feature is there so you can say, "Whatever Alice signs about our club is okay with me." It limits Alice's power. This is a reasonable and arguably important thing, especially if you're going to let Alice deputize people who can deputize people. It's so that the second assistant to the deputy undersecretary of the membership committee can't just go sign anything and I'll believe it.

The aim of this proposal being to make OpenPGP easier to use by
introducing ways to reduce the work required for setting up a secure
channel, while leaving control over these to the user (or to the
implementer, for opinionated implementations)

Sure! If there's anything OpenPGP needs it's more ease of use and work reduction.

What do you think about this?

I am not sure what you're really proposing, though. I think you might be proposing the very thing I described, but I'm not sure.


If that's not what I described, then do me a favor and describe the problem you want solved.

Jon

Cheers,
Leo
_______________________________________________
openpgp mailing list
https://www.ietf.org/mailman/listinfo/openpgp

[Leo Gaspard]

Post by Jon Callas

The aim of this proposal being to make OpenPGP easier to use by
introducing ways to reduce the work required for setting up a secure
channel, while leaving control over these to the user (or to the
implementer, for opinionated implementations)

Sure! If there's anything OpenPGP needs it's more ease of use and work reduction.

What do you think about this?

I am not sure what you're really proposing, though. I think you might be proposing the very thing I described, but I'm not sure.

You're right, now that I understand that the RFC already meant what I
was trying to do, my message didn't make much sense.

Post by Jon Callas
If that's not what I described, then do me a favor and describe the problem you want solved.

The problem I want solved is “no-one is using regular expressions and
thus implementations are likely non-existent or broken”. At first I
assumed it was because of what I thought was an issue of wording in the
RFC that would make it useless (hence my first post), but upon more

Post by Jon Callas
The scoping feature is there so you can say, "Whatever Alice signs
about our club is okay with me." It limits Alice's power.

I think the issue here is this “Whatever Alice signs about our club is
okay with me”. It can't really be encoded well in regular expressions: I
can not even say “Alice is only allowed to sign UIDs that end with
@myclub.example.org>”, because that would allow Alice to sign keys with
any name in it, and I would then implicitly trust Alice to have verified
the real-world identity of the key.

So upon more thought, I think the issue I'm feeling is there is better
described by my forked-from-this-thread “[openpgp] Overhauling User IDs
/ Standardizing User Attributes (was: Re: Scoped trust (signatures))”,
as with these changes it would become possible to scope the trust of
Alice to verify email addresses in @myclub.example.org and roles ending
with “at my club”, and even to scope the trust of a government's key to
sign any name whatsoever (as they already can issue any state-provided
ID thus make anyone fall for it at a keysigning party) but not any email
or role.

That said, it is a big change and I'm not sure it could gather enough
momentum to be accepted. But I think (hope?) that with such a
simplification in the way User IDs are handled (ie. without coupling of
unrelated parts of a user's identity), regex filtering (or by-domain
filtering) would become a tool adapted to the problem to solve, that is
delegating limited trust. This way, automated CA-like systems for
OpenPGP could appear without having issues with signing real names,
mailbox providers could sign their user's email addresses without having
to fear the risk that a user's real name is not the one on the User ID, etc.

Does what I'm saying make sense?
Anyway, thank you for this information on the background of this RFC!
Leo

[Jon Callas]

[...[\]

Post by Neal H. Walfield
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).

I believe you can do this.

A regexp that is "domain_1|domain_2" does this just fine.

Post by Neal H. Walfield
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.

My response is that that was not what the working group consensus was.

The working group consensus was that we didn't want to debate specifics, but regular expressions are sufficiently powerful to meet any reasonable (and probably lots of unreasonable) scoping.

I understand what you're saying, but I gotta reply, "So what?" I think I'm going to end up in a small rant in the following. I apologize in advance for any offense I might give in this small rant.

Let me shift the discussion to something slightly related. I have email accounts on a number of servers, and several of them allow me to do server-side filtering of my email. They provide a handy web page that lets me set up my own filtering rules. At the bottom of everything, all of these sites do filtering with Sieve. Sieve, like OpenPGP is an IETF standard, it is RFC 5228 and a lot more.

Each of the email servers I use has a slightly different web-GUI framework for specifying a rule. One of them, for example, is structured so that I have to enter "To" and "CC" on separate lines. Another one lets me specify "To" or "Any Recipient" (which means either To or CC). On another, I have to actually use the generic filter on some line and type in the CC if I want to filter on CC. In the actions phase of this, one of them automatically terminates after matching one other rule, while another one makes me put in an action line to stop processing following rules. But at the end of the day, they're all Sieve scripts.

(Oh, and one of them lets me upload my own Sieve script, but If I do that, I can no longer use the web GUI. Well, I can, but the GUI will likely overwrite all or part of the rules in ways that might totally break everything.)

There is *nothing* in OpenPGP that says you have to expose the full details of regular expressions to the user. Just like with Sieve, there's a full grammar that has expressive power that doesn't need to be used, and probably shouldn't be.

I agree completely that most users don't understand regexes. I agree that they shouldn't be subjected to them, and that the vast majority of what anyone needs is pretty much what you said — a list of domains. And yes, sensible software that does something nice for the user is not going to be able to ingest in an arbitrary regular expression and display it simply. Just like these server filtering web pages don't expose all the power of Sieve, a sensible program that lets people construct trust scope doesn't have to be just a text box that someone types a regexp into.

A protocol standard like OpenPGP specifies a grammar for messages. It's a way to encode a message so that other people can understand it as well as a way to interpret a message that someone else hands you.

In English, you can go up a staircase. You can also mount the staircase, ascend it, climb it, mount it, and even more. Grammar and vocabulary do not require you to put all the synonyms on the sign by the stairs. Up and Down are wonderful things to put on the sign. Ascend and Descend are a bit pretentious and non-native speakers might have trouble with them; thus they're compliant but have UX issues. The symbol ⬆ (that's the "Up Arrow" emoji in case it doesn't display properly) is not strictly standards-compliant, but if you're a fan of the Postel meta-rule, knock yourself out.

Protocol standards are not specifications for software implementations nor are they requirements documents. GnuPG is a wonderful piece of software that tries very hard to be a reference implementation that implements every single feature. It is not a requirement that every implementation implement every feature. That's why we have the RFC 2119 keywords. You gotta do the MUSTs. It would be nice to do the SHOULDs. You don't have to do the MAYs.

If you look at Section 5.2.3.1 of RFC 4880, it is perhaps more convoluted than it could be, but whatever. The gist of it is that since it says that an implementation SHOULD implement the preference subpackets as well as the Reason for Revocation, which at least implies that the others are all MAYs. It further says that you SHOULD ignore anything you don't "recognize" (which I interpret to be a synonym for "implement") and that if the critical bit it set, you SHOULD sit in the corner and sulk about anything you don't recognize.

Moreover, there's a regular expression helpfully defined in Section 8 that is a pretty bog-simple language, but like any regular expression matcher, you can create patterns that will drive weak people to strong drink. Nowhere are you *required* to let your user do things legal but silly. The reason it's there is to *permit* people to do complex things, not to expose the complexity to every user. It doesn't break the standard to implement a list of domains. It doesn't break the standard to let someone type in "*.example.com" for their scoping as opposed to ".*\.example\.com".

I believe that part of the reason so many people rail about the horrors of OpenPGP is that lots of us have the idea that OpenPGP is a software specification for GnuPG. That GnuPG is such a good piece of software is ironically part of the problem. It's as if every web browser revolved around the "curl" command.

I agree with you completely about scoping up until you want to change the standard. The scoping is the way it is so that simple things are easy and complex things are possible. If we make it so that only simple things are possible it doesn't help anyone. (And as I said before, working group consensus was such that the bog-simple regular expressions were the way to go.

Okay, thanks for reading this far.

Jon

[Vincent Breitmoser]

Post by Jon Callas
Each of the email servers I use has a slightly different web-GUI framework for
specifying a rule. One of them, for example, is structured so that I have to
enter "To" and "CC" on separate lines. Another one lets me specify "To" or
"Any Recipient" (which means either To or CC). On another, I have to actually
use the generic filter on some line and type in the CC if I want to filter on
CC. In the actions phase of this, one of them automatically terminates after
matching one other rule, while another one makes me put in an action line to
stop processing following rules. But at the end of the day, they're all Sieve
scripts.

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?

- V

[Jon Callas]

Post by Vincent Breitmoser
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

[Vincent Breitmoser]

Hey Jon,

Post by Jon Callas
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

[Neal H. Walfield]

On Mon, 28 May 2018 04:06:59 +0200,

Post by Jon Callas
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?

Thanks!

:) Neal

[Jon Callas]

Post by Neal H. Walfield
On Mon, 28 May 2018 04:06:59 +0200,

Post by Jon Callas
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.

[Christian Huitema]

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

[Bill Frantz]

Post by Jon Callas

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

Sure, but it means that you are using a generic text field in
ways that are hard to parse. Why not define it?

And needing to parse hard to parse fields is a well known
security problem because the resulting bugs are often exploitable.

Cheers - Bill

--------------------------------------------------------------
Bill Frantz | There are now so many exceptions to the
408-356-8506 | Fourth Amendment that it operates only by
www.pwpconsult.com | accident. - William Hugh Murray