Re: [openpgp] Overhauling User IDs / Standardizing User Attributes

Wyllys Ingersoll <wyllys@gmail.com> Wed, 27 June 2018 13:56 UTC

Return-Path: <wyllys@gmail.com>
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 3131F130DCC for <openpgp@ietfa.amsl.com>; Wed, 27 Jun 2018 06:56:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 ZUJRatmGMiEQ for <openpgp@ietfa.amsl.com>; Wed, 27 Jun 2018 06:56:15 -0700 (PDT)
Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 422091294D7 for <openpgp@ietf.org>; Wed, 27 Jun 2018 06:56:15 -0700 (PDT)
Received: by mail-io0-x232.google.com with SMTP id r24-v6so1974461ioh.9 for <openpgp@ietf.org>; Wed, 27 Jun 2018 06:56:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UOPoR0rBFVt1Wf0MupI/rT/+udcVyLA93RM/QsCuYiQ=; b=saXL9jjKk/x/Jc2Ns2M4j2c4aC2ywBJ5uooCyMiTIUpJdE3QdNLPRjPJICffBwtO4Y y15AJV4L72jLFX4cTJBbpC+ZvDL1yrBLVxOSlZ0IwO78y3nI1AfU0CYOG+vKXjNeVOj/ C/41+9w4nwExjkm9kJla7NYsOhRfYvmqaXKLgZTSQ5KvQ+1HL+xk+h4n2n/AizaYeXZy F8aCtiVuGngLU1T3kdCAfZ/wpLQkOy9rJF1HG4zwAzVOY08NNWwAZDESplWjJwcur00H +jTTEMWQ5LtN2fpHnUE7/RDfSQS1MaQk1XLLQoMFVrpVmAXZjiAUxtN+VIw7YrH25Tp8 6WkA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UOPoR0rBFVt1Wf0MupI/rT/+udcVyLA93RM/QsCuYiQ=; b=uNT7RN11ruQDX7EnhKstxdD1yslX7VZ3BLJkkmGFlB7kWOzsZ9TdGxJ1s5VP+EIlvr S0/pmdTaaTIV/VGZERxdsWHJ33wVgk5fd4hUVpX2A20tHBbG/BtMdQdkFAckRU9qw16o bmriA/w9htaMxnZQjQJBpKbPXZ9mq6P7s/zZID5eAsQ80tx5qzAxNyFYgnAuf800ntxX 6T2d9bFCOHGPeojFO+DFxqe9dqxh+CTPX9uA8mm8zzsPks6OrA6+O3XyDyyxbvI+N7gR H+eBM2MZcYAn7hZlMnFBMDimxuoA6z4eqrUv3ocX1eKrcymxSA3ldRZa+nLiX58BmxVg mifA==
X-Gm-Message-State: APt69E0KTK+FWnA4NTKTUXDoCBQNZOpuhToBXqnuXgSpYfoPj+9kZtZn M9LScFG6uS0sbzEy7G6nA4Z8UoAV+jxzADei+1fCDQ==
X-Google-Smtp-Source: AAOMgpc+/TbIUiKWeh7V4AlfQ4vIcM7aIk3HtaFNc56Rd9gcms6Xjjmx6UZh1jdB/36ApzzCmXxU/I6fDqd/t3DLMG4=
X-Received: by 2002:a6b:abc6:: with SMTP id u189-v6mr5114137ioe.30.1530107774605; Wed, 27 Jun 2018 06:56:14 -0700 (PDT)
MIME-Version: 1.0
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> <2d737acb-0ce9-b703-ceb9-29c9a2ef2c0e@leo.gaspard.ninja> <6f540f57-637c-f94c-4001-96ea9d14007f@metacode.biz> <fcb5b381-b8d2-79a2-383c-b9eb7b556307@leo.gaspard.ninja> <16e7c274-80d2-e35b-2d3a-a70bf39ebddc@metacode.biz>
In-Reply-To: <16e7c274-80d2-e35b-2d3a-a70bf39ebddc@metacode.biz>
From: Wyllys Ingersoll <wyllys@gmail.com>
Date: Wed, 27 Jun 2018 09:56:02 -0400
Message-ID: <CAHRa8=VTC1n735fdrBsUHOfBc1PKDKG74J16D9D52Q18Vbeq6Q@mail.gmail.com>
To: wiktor=40metacode.biz@dmarc.ietf.org
Cc: openpgp@ietf.org
Content-Type: multipart/alternative; boundary="0000000000005fa069056f9ffa3e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/b2mEA-9n1-tVfD611dLJtuaXL5I>
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: Wed, 27 Jun 2018 13:56:19 -0000

The problem I see with all of these suggestions is that there is no way to
actually "verify" the data that someone puts into these fields without some
sort of standardized and trusted verification service, which is way out of
scope for the OpenPGP spec. Also, adding many more user attributes *will*
complicate UIs beyond gnupg and enigmail. Consider mobile applications such
as ipgmail [mine] and others where screen real estate is at a premium and
users dont want to type lots of info into complex forms that are not well
understood by the average user.  The whole "web of trust" is not really
codified or enforced in a formal way, its pretty much up to individuals to
decide on the trust level they want to assign to a key (or userids
associated with the key), many users ignore it entirely and happily use the
key and assume the UID is correct.  Why would this be any better?

Im not convinced that the proposal to break up the UID into lots of
separate attributes is enhancing the security or usability for the general
PGP user community, though I can see it having value in some specialized
cases and perhaps it could be a foundation for building a better
trust/verification system.

-Wyllys Ingersoll





On Wed, Jun 27, 2018 at 8:06 AM Wiktor Kwapisiewicz <wiktor=
40metacode.biz@dmarc.ietf.org> wrote:

> Hi Leo,
>
> >> But I'm not in favor of other attributes:
> >>    - "role" (e.g. "Qubes OS developer"), who would verify that? Probably
> >> only some kind of master Qubes key should sign it but then how do we
> >> know if this is a correct master Qubes key? Wouldn't e-mail in form of
> >> user@developers.qubes.com better express that? (for the record I also
> >> don't like "project X signing key" comments but that's another story),
> >>    - "pseudonym", also not clear what are the rules of signing this ID,
> >
> > Well, I don't really like them either, but that'd be a way for people to
> > have a place to put the information they currently appear to want to put
> > in their User ID fields. The aim of these fields is mostly to avoid
> > misuse of other fields.
>
> I think the root of the problem is that people either input something
> because there is a Comment field, or they think they need to input
> something there (e.g. "Work").
>
> In the first case it's slowly getting better as tools as gpg have
> sensible defaults now (for example, they don't ask for comment when
> creating keys).
>
> In the second case a good solution would just be educating people (for
> example making them familiar with this timeless piece:
>
> https://dkg.fifthhorseman.net/blog/openpgp-user-id-comments-considered-harmful.html
> ).
>
> > I'd think the concept of saying “a key is valid” is likely a problem
> > anyway, as a key is always valid, and the only thing that can be checked
> > is the validity of the association between a User ID and a key (for the
> > WoT, there is no need to have a key “valid” for trusting it, so I guess
> > the change shouldn't generate any issue).
>
> By "valid" I meant the strict technical term used by gpg (see e.g. this
> excellent resource:
>
> https://www.linux.com/learn/pgp-web-trust-core-concepts-behind-trusted-communication
> ).
>
> > So this would require quite some changes especially around the user
> > interface, that couldn't just display a valid User ID as “key handle” as
> > is currently done by at least GnuPG and Enigmail, but would also have to
> > reconstruct something intelligent to display based on the set of
> > validated User Attributes.
>
> Exactly. And this kind of modification that requires changing all tools
> along the path, for a standard so widely used as OpenPGP can be hard to
> pull off.
>
> Kind regards,
> Wiktor
>
> _______________________________________________
> openpgp mailing list
> openpgp@ietf.org
> https://www.ietf.org/mailman/listinfo/openpgp
>