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

From: Jon Callas <[email-masked]>
Date: Sun, 01 Jul 2018 17:10:22 -0700

> On Jun 29, 2018, at 12:45 AM, Wiktor Kwapisiewicz <wiktor=[email-masked]> wrote:
> 
> Hi Jon,
> 
> This is slightly off-topic but...
> 
>> Heck, while you’re at it, talk to the Keybase people because they explicitly now have Twitter, Facebook, Github and DNS identifies, along with Reddit, Hacker News, Bitcoin addresses, Zcash 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.

> 
> And there already is I-D for "keybase but distributed" using OpenPGP - Linked Identities by Vincent [1]. Moreover this draft is already implemented in OpenKeychain and has verifications for Twitter, GitHub, etc. and works really well. I think the concept is proven to be working. (The only issue that I have with it it's that it's using experimental UAT IDs, but because Linked IDs is just a draft it cannot get proper assignment).
> 
> I've been experimenting on a slightly different implementation of Vincent's concept (using User IDs and notations instead of Attributes, and defined verification language) [2].
> 
> Also, a quote from Werner over the use of user attributes from 2017 [3]:
> 
>> (...) Anyway, I think that the User
>> Attributes should not be extended over their use for an image.  URIs can
>> simply be represented by plain User IDs and software can easily detected
>> such URIs if desired.
>> The need to implement UAT only adds more complexity for a questionable
>> purpose.  Note that these image UAT were introduced due to marketing
>> needs of PGP or NAT and (iirc) only specified after they had been
>> introduced in their software.
> 
> I didn't agree with him back then, but after longer thought I changed my opinion - user attributes do not have any fallback mechanism - either most software supports that custom special attribute or it's practically impossible to work with them (yes, they are supported, but displayed as an opaque string [4]). And I say this as a person that added this packet "by hand" and use it on my key.

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

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

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

---

From: Bill Frantz <[email-masked]>
Date: Sun, 1 Jul 2018 17:20:18 -0700

On 7/1/18 at 5:10 PM, [email-masked] (Jon Callas) wrote:

>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

---

From: Wiktor Kwapisiewicz <[email-masked]>
Date: Mon, 2 Jul 2018 07:42:29 +0200

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

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

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

> 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