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

Leo Gaspard <ietf@leo.gaspard.ninja> Fri, 29 June 2018 12:40 UTC

Return-Path: <ietf@leo.gaspard.ninja>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28A34130EA3 for <openpgp@ietfa.amsl.com>; Fri, 29 Jun 2018 05:40:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=leo.gaspard.ninja
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2y3pyQuwylNR for <openpgp@ietfa.amsl.com>; Fri, 29 Jun 2018 05:40:38 -0700 (PDT)
Received: from smtp.gaspard.ninja (grym.ekleog.org [94.23.42.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 328CD130EDA for <openpgp@ietf.org>; Fri, 29 Jun 2018 05:40:34 -0700 (PDT)
Received: by smtp.gaspard.ninja (OpenSMTPD) with ESMTP id c8a53c3a for <openpgp@ietf.org>; Fri, 29 Jun 2018 12:40:30 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=leo.gaspard.ninja; h=subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s= grym-20170528; bh=BNvCgzDehsXUeI8G1/8YyUG0+VA=; b=LRWtDnSUfPNND+ zMES0YdGiaDdpzo5mSop6zCz2m6I5i8xIpz3G6Q85uDFuS05qz4DB79qCWJSkV2P RveeeupiwGSNVTSeVOl9IgCiH80Yc+vs9cy5v28SaKZkHCbE+VQ5GMQePvseBLYD 7olxswqOCha+VYT6Mr5FUp55oPulo=
Received: by smtp.gaspard.ninja (OpenSMTPD) with ESMTPSA id 5545cb24 (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128:NO) for <openpgp@ietf.org>; Fri, 29 Jun 2018 12:40:30 +0000 (UTC)
To: openpgp@ietf.org
References: <39e598e1-2bc0-32c9-3489-4bb6ca2a631b@leo.gaspard.ninja> <871sdw24yd.wl-neal@walfield.org> <c2e6bbe7-0694-8193-bb76-dd50fde7d967@leo.gaspard.ninja> <d28d8f8b-b261-eb29-97bc-9c7159a62ce6@leo.gaspard.ninja> <118e5b9d-de9e-aa14-d8b4-19ef259f3d0a@ruhr-uni-bochum.de> <e63924fe-95b2-dcf8-5726-b0497945ac74@leo.gaspard.ninja> <f31349e2-e509-4e06-6db5-2ff0ffb213a5@ruhr-uni-bochum.de> <3996841a-b6ae-8769-2de8-b35351c54719@leo.gaspard.ninja> <8E4410C7-9370-492C-838F-857983CA67FC@icloud.com> <8a608b9f-f96b-466d-a0b8-7d1aa39ab011@leo.gaspard.ninja> <D3567617-4B9B-4BFE-AC39-11B0BEBB0B6B@icloud.com> <1cacc056-1ec7-f388-ee08-46468bd87bda@metacode.biz>
From: Leo Gaspard <ietf@leo.gaspard.ninja>
Message-ID: <bae4a6ec-36b5-6837-0b88-d009de139111@leo.gaspard.ninja>
Date: Fri, 29 Jun 2018 21:40:25 +0900
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <1cacc056-1ec7-f388-ee08-46468bd87bda@metacode.biz>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/H6_DLppnxPTmUm5fpXlH5KMAo1w>
Subject: Re: [openpgp] Overhauling User IDs / Standardizing User Attributes (was: Re: Scoped trust (signatures))
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Jun 2018 12:40:50 -0000

On 06/29/2018 04:45 PM, Wiktor Kwapisiewicz wrote:
> 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.

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)

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