Re: [openpgp] Overhauling User IDs / Standardizing User Attributes
Leo Gaspard <ietf@leo.gaspard.ninja> Tue, 26 June 2018 23:47 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 313B2130E6A for <openpgp@ietfa.amsl.com>; Tue, 26 Jun 2018 16:47:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.99
X-Spam-Level:
X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_FILL_THIS_FORM_SHORT=0.01] 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 tze59mu1GH9v for <openpgp@ietfa.amsl.com>; Tue, 26 Jun 2018 16:47:33 -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 2A2A1130E61 for <openpgp@ietf.org>; Tue, 26 Jun 2018 16:47:32 -0700 (PDT)
Received: by smtp.gaspard.ninja (OpenSMTPD) with ESMTP id e671e5e4 for <openpgp@ietf.org>; Tue, 26 Jun 2018 23:47:28 +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=w0qSVzMPeZmNHNlRzrZT1hAdj6I=; b=GFhaVqyI8JIMKP xkXWgCZoihP5uWuwPUAVMK9Z7gSYFfAmKzNdpU1PZCvIcvvw053EeNpo6GbUy7CK jum1E68DvZT8E1cS9A+aLCCk+EN5+geraPCAii2aWclSUdxH7csQwtsPkqhgV6EO aRAwRhga/yj2EahVh8UpFYjxANO1Q=
Received: by smtp.gaspard.ninja (OpenSMTPD) with ESMTPSA id 48b21f4c (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128:NO) for <openpgp@ietf.org>; Tue, 26 Jun 2018 23:47:28 +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> <67153bb3-8ec7-5b30-3d11-22fce0681b47@metacode.biz>
From: Leo Gaspard <ietf@leo.gaspard.ninja>
Message-ID: <2d737acb-0ce9-b703-ceb9-29c9a2ef2c0e@leo.gaspard.ninja>
Date: Wed, 27 Jun 2018 01:47:27 +0200
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: <67153bb3-8ec7-5b30-3d11-22fce0681b47@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/77jeWrumqqNCPPcfzsdCk4PNMxs>
Subject: Re: [openpgp] Overhauling User IDs / Standardizing User Attributes
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: Tue, 26 Jun 2018 23:47:37 -0000
Hi Wiktor, >> Are there really no opinions on this idea of decoupling names and email >> addresses through standardization of more User Attributes and removal of >> User ID packets in v5 keys? Not having any feedback from any software >> maintainer makes me wary of starting to write a patch for 4880bis > right now. > > Standarization and implementation of new User Attributes would take > ages, and the existing User IDs are just good enough. Well, I think User IDs are not good enough, but I do agree it's an implementation burden… seeing only the “end-user” side of the story I can't tell much about this implementation burden, though. For standardization, as soon as there is a consensus that User IDs are a problem because they couple orthogonal things and that they should be replaced by a more orthogonal scheme, I think that having one or many User Attributes wouldn't change much… and anyway that'd be only for v5 keys, which are going to take loooong before they are actually deployed everywhere. >>> When I want to sign someone's User ID, I need to both check their >>> real-life name (with eg. a state-provided ID) and their e-mail address. >>> And if someone has put a pseudonym on the User ID, should I sign it? > > That depends on your personal key-signing policy. I - for example - > don't sign User IDs with comments (because I can't or don't want to > verify if your role is "super administrator" or nickname is "XYZ"). Indeed, that's exactly the issue I try to solve with this proposal: User IDs couple unrelated things, including some I want to sign and some I don't want to sign, and I'd love to be able to sign only the parts I actually want to sign. >>> This tight coupling of name and email address in User IDs is already an >>> issue for me (in choosing what User ID(s) I should put, choosing whether >>> to sign a User ID I only know part of…), and is now again an issue in >>> fixing the standard to be both more simple and more usable. > > You can create User ID without e-mail, actually a lot of people do just > that. And then add one more with e-mail, works just fine. Yes, but the issue is mostly the other way around. When I check the name of someone, I have no problem in checking their e-mail too. What I do have problems is checking people's names, while the email address is really easy to check (a challenge-response over the mail and it's done). I'd like to be able to sign only the email address of people… but then that means I have to ask people to change the way they allot User IDs: one User ID per real-world name, one User ID per pseudonym, one User ID per email address, and one User ID per role. And… here comes my 4 main User Attributes, that are just a way to both enforce and standardize these use cases. For instance, I could likely sign a “This key uses pseudonym Hello World” after relatively minor checks, but I wouldn't sign a “This key has User ID Hello World” without extensive checks, because I would assume it's a name, not a pseudonym. >>> So here is my idea: drop User IDs in v5 keys, and standardize more User >>> Attributes. In particular, standardize at least a “name”, an “email” and >>> a “pseudonym” user attribute. (I'm not sure about the “comment” user >>> attribute, and would prefer seeing it handled otherwise, see the >>> “Possible extensions” section) > > And how is that different from what we have in User ID? It's still up to > the signer if they want to sign "pseudonym" user attribute or not. You > just gain marginal benefit of having "name", "email" and "pseudonym" > parts separated for a big effort in supporting this new scheme. Well, if everyone did separate the User IDs this way, then it wouldn't be necessary. But even rfc4880bis§5.12 mentions “By convention, it includes an RFC 2822 [RFC2822] mail name-addr” and that it “is intended to represent the name and email address of the key holder.” So I think the spec itself is currently discouraging people from doing the Right Thing (ie. separate orthogonal information into separate User IDs). And if the spec is to incite people to standardize on separate meanings for the User ID field… wouldn't it be better to just enforce it by dropping them in the v5 key format, and having only User Attributes? > Actually I was also thinking on using User Attributes at one time (for > Linked IDs) but luckily the idea was shot on this ML. User IDs are > better because they have a fallback already - a human can read the > string just fine, not be confused by "[unknown attribute of size 83]" > (check my key). > > For extensibility - notations - they are also human readable and can be > made critical for special purposes. Hmm… I would agree with you, but here I'm talking not of using User Attributes on v4 keys (which are IMO quite useless, apart from photo IDs, which are useless too), but of User Attributes on v5 keys, for which the spec (were the changes I'm thinking of accepted) would give specific meanings, and would enforce implementation. Thus, these User Attributes would be all the users would have to claim their identity. And thus they would necessarily be well-supported, as everyone would be using them for v5 keys. That said, it is a quite large development burden, especially around the UI, as currently UIs can just assume they can dump a raw User ID to the output and be done with it, while with the changes they would have to actually find intelligent (eg. relevant and verified) User Attribute(s), and display only them. > Sorry if this sounds negative. Negative feedback is great too, thank you for your answer! I hope I have better explained why I think such a change would improve the situation around User IDs, now :) Have a nice day too! Cheers, Leo
- Re: [openpgp] Overhauling User IDs / Standardizin… Leo Gaspard
- Re: [openpgp] Overhauling User IDs / Standardizin… Leo Gaspard
- Re: [openpgp] Overhauling User IDs / Standardizin… Wyllys Ingersoll
- Re: [openpgp] Overhauling User IDs / Standardizin… Leo Gaspard
- Re: [openpgp] Overhauling User IDs / Standardizin… Wiktor Kwapisiewicz
- Re: [openpgp] Overhauling User IDs / Standardizin… Leo Gaspard
- [openpgp] Overhauling User IDs / Standardizing Us… Marcus Brinkmann
- Re: [openpgp] Overhauling User IDs / Standardizin… Leo Gaspard
- Re: [openpgp] Overhauling User IDs / Standardizin… Leo Gaspard
- Re: [openpgp] Overhauling User IDs / Standardizin… Marcus Brinkmann
- Re: [openpgp] Overhauling User IDs / Standardizin… Wiktor Kwapisiewicz
- Re: [openpgp] Overhauling User IDs / Standardizin… Leo Gaspard
- Re: [openpgp] Scoped trust (signatures) Vincent Breitmoser
- Re: [openpgp] Overhauling User IDs / Standardizin… Wiktor Kwapisiewicz
- Re: [openpgp] Overhauling User IDs / Standardizin… Wiktor Kwapisiewicz
- Re: [openpgp] Overhauling User IDs / Standardizin… Jon Callas
- [openpgp] Overhauling User IDs / Standardizing Us… Leo Gaspard
- Re: [openpgp] Overhauling User IDs / Standardizin… Leo Gaspard
- Re: [openpgp] Overhauling User IDs / Standardizin… Jon Callas
- Re: [openpgp] Overhauling User IDs / Standardizin… Wiktor Kwapisiewicz
- Re: [openpgp] Overhauling User IDs / Standardizin… Wiktor Kwapisiewicz
- Re: [openpgp] Overhauling User IDs / Standardizin… Leo Gaspard
- Re: [openpgp] Overhauling User IDs / Standardizin… Leo Gaspard
- Re: [openpgp] Overhauling User IDs / Standardizin… Derek Atkins
- Re: [openpgp] Overhauling User IDs / Standardizin… Leo Gaspard
- Re: [openpgp] Overhauling User IDs / Standardizin… Leo Gaspard
- Re: [openpgp] Overhauling User IDs / Standardizin… Bill Frantz
- Re: [openpgp] Overhauling User IDs / Standardizin… Jon Callas
- Re: [openpgp] Overhauling User IDs / Standardizin… Wiktor Kwapisiewicz
- [openpgp] Scoped trust (signatures) Leo Gaspard
- Re: [openpgp] Scoped trust (signatures) Neal H. Walfield
- [openpgp] Overhauling User IDs / Standardizing Us… Leo Gaspard
- Re: [openpgp] Overhauling User IDs / Standardizin… Vincent Breitmoser
- Re: [openpgp] Overhauling User IDs / Standardizin… Leo Gaspard
- Re: [openpgp] Scoped trust (signatures) Jon Callas
- Re: [openpgp] Scoped trust (signatures) Jon Callas
- Re: [openpgp] Scoped trust (signatures) Leo Gaspard
- Re: [openpgp] Scoped trust (signatures) Vincent Breitmoser
- Re: [openpgp] Scoped trust (signatures) Neal H. Walfield
- Re: [openpgp] Scoped trust (signatures) Jon Callas
- Re: [openpgp] Scoped trust (signatures) Jon Callas
- Re: [openpgp] Scoped trust (signatures) Christian Huitema