[Top] [All Lists]

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

2018-06-26 19:42:53
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, 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

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:

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?

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;

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


openpgp mailing list

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