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

[Marcus Brinkmann <[e-mail]>]

On 06/27/2018 01:28 AM, Leo Gaspard wrote:
> On 06/26/2018 10:45 PM, Marcus Brinkmann wrote:
>> 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).

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

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.

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

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

> 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

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

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

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

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

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

> for the image attribute (the only one standardized afaik), I
> 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.

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

> 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