Subject: [openpgp] Linked Identities / URI Attributes status

From: Wiktor Kwapisiewicz <[email-masked]>
Date: Fri, 6 Oct 2017 11:11:34 +0200

Hello everyone,

I'd like to ask about Linked Identities for OpenPGP [0]. I'm planning to
write tooling to manage Linked Identities UAT packets but as far as I
can see Linked Identities rely on URI Attributes [1] and URI Attributes
(because it's still draft) do not have IANA-assigned User Attribute Type
[2]. The only implementation that I know of (OpenKeychain) use
experimental value for these packets.

Is there anything that blocks URI Attributes [1] from being approved and
having an official (2-99) User Attribute type?

Thank you for you time!

Kind regards,

Wiktor

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

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

[2]:
https://www.iana.org/assignments/pgp-parameters/pgp-parameters.xhtml#pgp-parameters-3

-- 
*/metacode/*

---

From: Werner Koch <[email-masked]>
Date: Fri, 06 Oct 2017 12:41:17 +0200

> having an official (2-99) User Attribute type?

I was not aware of that (expired) I-D.  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.

Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

---

From: Vincent Breitmoser <[email-masked]>
Date: Fri, 6 Oct 2017 18:26:35 +0200

Hi there,

this draft of linked identities (and the corresponding implementation in
openkeychain) is by me :) cheers Wiktor for bringing it up again!

> URIs can simply be represented by plain User IDs and software can
> easily detected such URIs if desired.

I'll try to describe some more why I went with a user attribute over
simple user ids.

Most importantly, URI attribute are intended for identities that are
encoded as URIs, not simply user-facing urls that might have some
unspecified association to the user. This means that a typical URI in
there won't be "clickable", which will be confusing at best (and a
security issue at worst) for the user.

For instance, this is one of the uri attributes on my key:
openpgpid+cookie:@https://twitter.com/Valodim/status/592675006880022529

A secondary thought is that, while the content explicitly isn't
restricted, overloading user ids with more stuff adds to the amount of
guesswork implementations have to do to interpret and display them in a
helpful way. For URI Attributes, if an implementation has no handler for
the schema, then not showing them at all is the reasonable thing to do.

On a related note, personally I would be happier if user ids were
name-addr not only by convention, and we made better use of the user
attribute namespace for stuff like telephone numbers or whatever other
types of identities some people want to stuff in their keys.

> purpose.

User attributes with unknown attribute id already have to be handled as
opaque packets, so it adds zero complexity to implementations that don't
want to handle them. If an implementation chokes on user attributes in
general, that's a bug in the implementation, not the spec.

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

While this is an interesting historical note, I don't believe it's a
good basis for a decision here. If avoiding use of uats for this reason
is in fact general consensus, they should be deprecated in rfc4880-bis.
If it's not, I don't see anything wrong with assigning new attribute
ids.

 - V

---

From: Werner Koch <[email-masked]>
Date: Sat, 07 Oct 2017 10:37:54 +0200

> guesswork implementations have to do to interpret and display them in a

You don't need to do any guesswork.  We have notation data which can be
used to add meta data to a user id.

Hiding things which might act as identities in UAT does not feel right.
We better keep UAT for what they are used today - for the more or less
useless photo-ids

Shalom-Salam,

   Werner

---

From: Wiktor Kwapisiewicz <[email-masked]>
Date: Thu, 12 Oct 2017 15:18:38 +0200

> simply be represented by plain User IDs and software can easily detected

This is an excellent idea. Coupled with signature notation data, that
can be made critical one can assure that unknown Linked Identity UIDs
would be considered invalid by software that does not understand a
particular notation data proof.

Not to mention UIDs and Notation Data can be added using command line
tools that already exist.

But I do have to agree with Vincent that if UATs are deprecated they
should be marked as such.

Actually, previously I got a very different impression when I diffed RFC
4880 and 4880 bis-02 and saw new section "5.13.2.  User ID Attribute
Subpacket" [0] that was introduced for Device Certificates [1]. Is this
something old to be removed or an entirely different case?

Kind regards,

Wiktor

[0]:
https://tools.ietf.org/html/draft-ietf-openpgp-rfc4880bis-02#section-5.13.2

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