From nobody Fri Jun 1 00:11:39 2018 Return-Path: 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 C2C3F1270A3 for ; Fri, 1 Jun 2018 00:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.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 mqbbDJVvXScv for ; Fri, 1 Jun 2018 00:11:36 -0700 (PDT) Received: from st13p27im-asmtp003.me.com (st13p27im-asmtp003.me.com [17.162.190.112]) (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 D40351270A0 for ; Fri, 1 Jun 2018 00:11:36 -0700 (PDT) Received: from process-dkim-sign-daemon.st13p27im-asmtp003.me.com by st13p27im-asmtp003.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) id <0P9M00X00UCE1W00@st13p27im-asmtp003.me.com> for openpgp@ietf.org; Fri, 01 Jun 2018 07:11:35 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1527837095; bh=99HyHahQZRjbxILbw5mtECbOOL7I/Jg2O7syCKt3q4g=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=oUlUfAiPgDLUtvJi+dwMcKXnlmb7E9Ren6PsoYaS6BC+E44hGSNs6ssrm228gIJ5p ZWpDkH+1cE7mhhbzqma34pgvmCkhbugjeIBDLijq+JYhVTAevtNBOQpK0/r2knKdpN uacBjuQbN9s36c+TH+Ee2OmnoTOpndqT08EHqMUdwp0+gwFaWOUz03Jg7f45tzDDzE dHJr2aHTbPGOpixS/VwBGUoEO0mYjareU6ayA9Hhb1b3b1I2NQwElPgxidT56g/MN5 QwnM0uZ15Uvijh6kx+tcqAmy4huvpxEH7pPqE41X7aOQEZMoX3k8ISD+ACypPxe96h t4O0eSRBUUNDg== Received: from icloud.com ([127.0.0.1]) by st13p27im-asmtp003.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) with ESMTPSA id <0P9M00LCAUN7M010@st13p27im-asmtp003.me.com>; Fri, 01 Jun 2018 07:11:34 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-06-01_05:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1806010081 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Jon Callas In-reply-to: <20180528070559.5cj2y7ebqzt7rplc@calamity> Date: Fri, 01 Jun 2018 00:11:30 -0700 Cc: Jon Callas , "Neal H. Walfield" , openpgp@ietf.org, Leo Gaspard Content-transfer-encoding: quoted-printable Message-id: <37E755B9-324E-4106-8889-40F2AEC96471@icloud.com> References: <39e598e1-2bc0-32c9-3489-4bb6ca2a631b@leo.gaspard.ninja> <871sdw24yd.wl-neal@walfield.org> <20180528070559.5cj2y7ebqzt7rplc@calamity> To: Vincent Breitmoser X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [openpgp] Scoped trust (signatures) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 07:11:38 -0000 > On May 28, 2018, at 12:06 AM, Vincent Breitmoser = wrote: >=20 > I believe you've described the very problem with this approach here: A = powerful > and flexible mechanism leads to many inconsistencies between = implementations, > that's just unavoidable. For sieve scripts you might be fine with = that, at worst > some messages will go in the wrong folder once in a while. But are you = really > okay with same level of inconsistency in a trust model? I think I=E2=80=99ve described the opposite. The filtering model in Sieve is well-defined. There are differences in a = GUI overlay because different communities value different shortcuts, and = also put different viewpoints on the shortcuts. The Sieve scripts = generated by any one of those disparate GUIs will execute the same way = on another. Now I, the user, may have to create a collection of filters = to do what I want because of what gets exposed to me in the GUI, but the = resulting script will execute the same. Let=E2=80=99s suppose Neal does what he wants =E2=80=94 it=E2=80=99s = just a list of domains. That=E2=80=99s a really easy thing for him to = implement (perhaps, as I=E2=80=99ll reply to him next) but the regex = that he generates will execute the same everywhere. However, that=E2=80=99s not the real point I wanted to make. That point = is that there=E2=80=99s a difference between being an implementer and = the protocol. A good implementer makes decisions about things for their = own vision, but a protocol designer has to make something that satisfies = different visions. Moreover, the protocol inevitably is a compromise = between differing visions. A standard is something that is a compromise, = and as such is not any one person=E2=80=99s vision whatever it ends up = with. And as we all know, a compromise is something where everyone is = more or less equally unhappy with it, but not so unhappy that they = walked away. I haven=E2=80=99t told you what I=E2=80=99d do (and did) with any of = this so far, but I=E2=80=99d be happy to later. Advice I give as an = implementer is usually different than advice I give as a protocol = designer. The standard as it exists is something that got the rough = consensus of the working group, and that rough consensus is worthy of a = little respect. Perhaps not too much, but certainly a little. The = problem with making the protocol match one=E2=80=99s own opinions is = that it=E2=80=99s effectively saying not only that what one thinks is = right in some sense, but also that other people=E2=80=99s opinions are = wrong and that no one else should do something different. Jon From nobody Fri Jun 1 00:25:33 2018 Return-Path: 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 663681270AC for ; Fri, 1 Jun 2018 00:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.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 hjuw9TmgVvAi for ; Fri, 1 Jun 2018 00:25:30 -0700 (PDT) Received: from st13p27im-asmtp004.me.com (st13p27im-asmtp004.me.com [17.162.190.113]) (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 23AD7124239 for ; Fri, 1 Jun 2018 00:25:30 -0700 (PDT) Received: from process-dkim-sign-daemon.st13p27im-asmtp004.me.com by st13p27im-asmtp004.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) id <0P9M00T00UUPDW00@st13p27im-asmtp004.me.com> for openpgp@ietf.org; Fri, 01 Jun 2018 07:25:26 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1527837926; bh=4Z0IAgBoN/NG1Pp8rmIyOdL2ojdMTuSyFT83M4yCI/g=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=pxmbUhYHQC9Gv8bv6v3v+to8fVAcKUjJbEusIP99TgVZj55POBvWBzbaxhW+cST98 rejFCuM2BZZwsnRflQhOtcZ0/0uPT99ohrVXZLD2G9M45G/8ffDbicFW6kzkCnc77V T84wXCbV5K4s2G0rVf6C0+dVdh2yofo4noEPIC4+95dt3ubAbMoqeJnUVrE3sygs43 JPzbj9GNrZk7gHdU4L5ycXVn57b8Sco5l17hEI2CcV5PZM+5NOz9z0btK94tM6JShR SEU9N8AWHfzSeI/eN3h71L7LoxsBqb5qC+VkZj0SKTb/R5x7fKmPvwr4mbTxdVOsAG mA/eP6fzn6WEQ== Received: from icloud.com ([127.0.0.1]) by st13p27im-asmtp004.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) with ESMTPSA id <0P9M00R3FVAC8W50@st13p27im-asmtp004.me.com>; Fri, 01 Jun 2018 07:25:26 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-06-01_05:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1015 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1806010084 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Jon Callas In-reply-to: <87vab8yxw1.wl-neal@walfield.org> Date: Fri, 01 Jun 2018 00:25:23 -0700 Cc: Jon Callas , openpgp@ietf.org, Leo Gaspard Content-transfer-encoding: quoted-printable Message-id: <1889E5F8-066A-4175-82FC-531B8608909E@icloud.com> References: <39e598e1-2bc0-32c9-3489-4bb6ca2a631b@leo.gaspard.ninja> <871sdw24yd.wl-neal@walfield.org> <87vab8yxw1.wl-neal@walfield.org> To: "Neal H. Walfield" X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [openpgp] Scoped trust (signatures) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 07:25:32 -0000 > On May 28, 2018, at 1:42 AM, Neal H. Walfield = wrote: >=20 > On Mon, 28 May 2018 04:06:59 +0200, > Jon Callas wrote: >> Moreover, there's a regular expression helpfully defined in Section >> 8 that is a pretty bog-simple language >=20 > Implementing regular expression support might be bog-simple, but I > think it is still orders of magnitude more complicated than just a > list of domains. And, I think, the general lack of support for this > feature is strong evidence that this is the case. >=20 > Thus, it seems to me, that making the complicated theoretically > possible has made the simple practically impossible. That's > unfortunate. >=20 > Do you know of any examples where a list of domains is not sufficient? As I alluded to in my previous missive, I think that a list of domains = is harder than you think. My experience in dealing with other = domain-based PKI leads me right there. Does =E2=80=9Cexample.com=E2=80=9D match =E2=80=9Cmail.example.com=E2=80=9D= ? Either yes or no is completely reasonable. Does =E2=80=9C*.example.com=E2= =80=9D (which obviously matches =E2=80=9Cmail.example.com") match = =E2=80=9Cexample.com=E2=80=9D? In this case, I think that the answer is = yes, but gentle persons can disagree. I=E2=80=99d just roll my eyes if = you said no, because yeah, sure, there=E2=80=99s no problem in having = your list of domains have both =E2=80=9Cexample.com=E2=80=9D and = =E2=80=9C*.example.com=E2=80=9D to be explicit about it. I see the = point. Matching domains in the general case has all sorts of other weird edge = cases especially in CCTLDs because many CCTLDs don=E2=80=99t issue = anything on the bare country code. For example, for many years you = couldn=E2=80=99t get =E2=80=9Cexample.uk=E2=80=9D but you could get = =E2=80=9Cexample.co.uk=E2=80=9D. In any event, some CCTLDs allow a bare = country code and some don=E2=80=99t. Do you take this into account in = your list of domains? I think that an answer that is =E2=80=9Cwhatever = you put there is what we do=E2=80=9D is a great answer, but there are = people who will disagree. What about trailing dots on a domain? How are = they handled? I believe that a list of domains is harder than you think. Whatever = decisions you make on the edge conditions of domains are something you = yourself can do so that when I type in a list of domains, your = interpretations will correctly be coded into it and that someone else = will interpret them in the way you did. Go look at the definition of regular expressions in RFC 4880. It=E2=80=99s= basically just a paragraph. With my tongue partially in my cheek, I bet = you can=E2=80=99t sort out what =E2=80=9Clist of domains=E2=80=9D means = in all the edge cases in less text than that definition of regular = expressions. That is the reason that working group consensus went to the = trouble of finding a minimal, utterly no-IP definition of a regular = expression. It=E2=80=99s in a very real sense simpler than just about = anything else.= From nobody Fri Jun 1 07:30:19 2018 Return-Path: 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 F0AD512D880 for ; Fri, 1 Jun 2018 07:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_OBFUSCATE_10_20=0.093, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 Y_CrhdiX6Eyr for ; Fri, 1 Jun 2018 07:30:16 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 DD51612D875 for ; Fri, 1 Jun 2018 07:30:15 -0700 (PDT) Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx62.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1fOl4G-000CQs-Vq for openpgp@ietf.org; Fri, 01 Jun 2018 16:30:14 +0200 Received: from [10.5.2.52] (helo=xmail12.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1fOl47-0004PX-Bn for openpgp@ietf.org; Fri, 01 Jun 2018 10:30:09 -0400 Received: (qmail 22404 invoked from network); 1 Jun 2018 14:30:01 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.246]) (envelope-sender ) by xmail12.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 1 Jun 2018 14:30:01 -0000 Content-Type: multipart/alternative; boundary=Apple-Mail-41AA58EF-2157-4341-B8DA-D94EDB09FCF2 Mime-Version: 1.0 (1.0) From: Christian Huitema X-Mailer: iPhone Mail (15E302) In-Reply-To: <1889E5F8-066A-4175-82FC-531B8608909E@icloud.com> Date: Fri, 1 Jun 2018 07:29:59 -0700 Cc: "Neal H. Walfield" , openpgp@ietf.org, Leo Gaspard Content-Transfer-Encoding: 7bit Message-Id: <191F8A70-0019-4154-865C-0FC2A34E0F29@huitema.net> References: <39e598e1-2bc0-32c9-3489-4bb6ca2a631b@leo.gaspard.ninja> <871sdw24yd.wl-neal@walfield.org> <87vab8yxw1.wl-neal@walfield.org> <1889E5F8-066A-4175-82FC-531B8608909E@icloud.com> To: Jon Callas X-Originating-IP: 168.144.250.223 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.20) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5qHmjChROEILyXV1sCY1+4B602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvOzru8NNmGiOQqImVw2q8oD6Ibg6INTucL51iwLVw9Lt6EBrDd9L8isx9h1IkPhqpR58j cRWGrGPw27W+gUvIvJNVr8eP+Wmp/y/AB2KysgGDtZYnVUBFGGZHk0uFiyMplLUJ8oN+d2/1YClf NOnZIS+k7MxK87c44TynDTcugpM/kRBtrTRM/4TRHmTy40yDhnXc9h1jP0GCLUBD5fsSyyeBaQIi fdaGzMoXcgXnOXfsRAwX31WVY5lWjWxuGSRuxURW8UvT0kUDO7BO02wlaiMJNrZqjoiSWdcjcZLv /Am2ptBB9icD2fnZzw/HNF6wGm/P3Q658NtotfOVlwP9Y9difvX7GxYM34o1TppnqMQvRsaiauSV ohXqcOBLfm7uY6BmNlijRSWQzbBZx5Si4hrQHolQlVdf0A32Xtl5FAWDghl42JYqqDQ3Y4iSUDm3 2q0jiD6XqsJZtjQxlyCdsewAXriecQRcQmCLLh6f2LA2F8FcHzzV3acxBudgYcInb6ijpGixFRT3 rd8R2HZmTseZ4+t4LK79cWIqQA4tGr3po0jfgLl+Ahd0TIbt0Zij6hgeJ07QR0GiieIKGR3KfdmQ xACKGgjW6av7lJfpYBfZhfURd0e4QPXFipyALWtbLFwBl1z1+w2zS/h3e6UiVRfwaCeVXpCv1sFg cqoPk5QcFiGH7Duhk0ap5LnfGgDarmeqA47D/juB1cx4exzYk7zGRNvb2Jhdd2bCgCq95vNY647l NwN4qOsSZg+fYhVZGwX3xdN+1KruynacUoWIYszVwaDsyRiTeu4Ip+KAECko9HdE0Smt1e6HZuGs N7RwePAFMvX7q8M4x6bP/gjzw0OFbIWNJOiaifOc2xlkb46Pa4K5MPGI7fF8+j7E9IwdcQR2aish SbQcCCOvcJLn8v/2OKHH5lr9xXvSM4nM3avg X-Report-Abuse-To: spam@quarantine6.antispamcloud.com Archived-At: Subject: Re: [openpgp] Scoped trust (signatures) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 14:30:18 -0000 --Apple-Mail-41AA58EF-2157-4341-B8DA-D94EDB09FCF2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On Jun 1, 2018, at 12:25 AM, Jon Callas wrote: >=20 > ... >=20 > Does =E2=80=9Cexample.com=E2=80=9D match =E2=80=9Cmail.example.com=E2=80=9D= ? Either yes or no is completely reasonable. Does =E2=80=9C*.example.com=E2=80= =9D (which obviously matches =E2=80=9Cmail.example.com") match =E2=80=9Cexam= ple.com=E2=80=9D? In this case, I think that the answer is yes, but gentle p= ersons can disagree. I=E2=80=99d just roll my eyes if you said no, because y= eah, sure, there=E2=80=99s no problem in having your list of domains have bo= th =E2=80=9Cexample.com=E2=80=9D and =E2=80=9C*.example.com=E2=80=9D to be e= xplicit about it. I see the point. Matching domains is indeed hard, but people are working on it. You may want t= o check the list of public prefixes maintained by Mozilla et al as an open s= ource project: https://github.com/publicsuffix/list -- Christian Huitema=20 --Apple-Mail-41AA58EF-2157-4341-B8DA-D94EDB09FCF2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Jun 1, 2018, at 12:25 AM, Jon C= allas <joncallas@icloud.com&g= t; wrote:

...=

Does =E2=80=9Cexample.com=E2=80=9D match =E2=80=9Cmail.example.com=E2=80=9D? Either yes or no is completely reasonable.= Does =E2=80=9C*.example.com=E2=80=9D (wh= ich obviously matches =E2=80=9Cmail.exam= ple.com") match =E2=80=9Cexample.com=E2= =80=9D? In this case, I think that the answer is yes, but gentle persons can= disagree. I=E2=80=99d just roll my eyes if you said no, because yeah, sure,= there=E2=80=99s no problem in having your list of domains have both =E2=80=9C= example.com=E2=80=9D and =E2=80=9C*.example.com=E2=80=9D to be explicit about it. I= see the point.


<= div>Matching domains is indeed hard, but people are working on it. You may w= ant to check the list of public prefixes maintained by Mozilla et al as an o= pen source project:

https://github.com/publicsuffix/list


-- Christian Huitema&nbs= p;

= = --Apple-Mail-41AA58EF-2157-4341-B8DA-D94EDB09FCF2-- From nobody Tue Jun 12 04:20:32 2018 Return-Path: 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 81858130E1C for ; Tue, 12 Jun 2018 04:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no 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 9NYhQ_YTDYyP for ; Tue, 12 Jun 2018 04:20:21 -0700 (PDT) Received: from mail.mugenguild.com (mugenguild.com [5.135.189.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFB2A130DDA for ; Tue, 12 Jun 2018 04:20:21 -0700 (PDT) Received: from localhost (gate.ibr.cs.tu-bs.de [134.169.34.1]) by mail.mugenguild.com (Postfix) with ESMTPSA id C3FAD5FAA1; Tue, 12 Jun 2018 13:20:18 +0200 (CEST) Date: Tue, 12 Jun 2018 13:20:16 +0200 From: Vincent Breitmoser To: Jon Callas Cc: "Neal H. Walfield" , openpgp@ietf.org, Leo Gaspard Message-ID: <20180612112016.ixqq6affuwvcuc3x@calamity> References: <39e598e1-2bc0-32c9-3489-4bb6ca2a631b@leo.gaspard.ninja> <871sdw24yd.wl-neal@walfield.org> <20180528070559.5cj2y7ebqzt7rplc@calamity> <37E755B9-324E-4106-8889-40F2AEC96471@icloud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <37E755B9-324E-4106-8889-40F2AEC96471@icloud.com> Autocrypt: addr=look@my.amazin.horse; keydata=mQINBFAB3UABEADCyB/vbIBA3m1Bwc yjTieEMLySwYgt54EQ2hglOocdtIhqC+b05t6sLSkwx2ukxrU2cegnCBkdyF/FZ/+Et638CUEBbf 4bjplwpt2IPLazQgjkwjMuhz0OcYDpMhwimTvh3mIl+0wzpOts6mEmMw0QZdl3RXvIW+NSynOn7q mz/fAv4Htt6lv2Ka0s6R2voyi+5U7CcIqizPad5qZVn2uxmovcFreTzFt6nk37ZbbTfvA3e5F0bR RQeH3viT5XxpJF4Y76v/Ua+5N3Kd18K0sX85rD1G7cmxR2CZ5gW1X24sDqdYZdDbf10N39UIwjJH PTeuVMQqry792Ap0Etyj135YFCE0loDnZYKvy2Y1i0RuEdTUIonIHrLhe2J0bXQGbQImHIyMgB9/ lva8D+yvy2gyf2vjRhmJEEco7w9FdzP7p3PhKrUiTjRsjHw8iV8LOCFx9njZOq9mism9ZZ16tZpx 9mXOf11HcH1RtVuyyQRS/4ytQPzwshXdSDDW6Btkmo9AbZQKC54/hSyzpp3Br2T2xDH7ecnonDB/ jv8rWuKXSTbX3xWAIrNBNDcTYaNe4jkms4HF7jJE19eRlqsXMMx6Fxvrh4TtKICwJYJ3AUmXrK3X Ti/mjqYfJ1fpBn54rWs8nhSR1fuZPD+aMlcP8BDUPlNKPKtj0DGSh3/VlnnwARAQABtClWaW5jZW 50IEJyZWl0bW9zZXIgPGxvb2tAbXkuYW1hemluLmhvcnNlPokCOAQTAQIAIgUCVTNZmgIbAwYLCQ gHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQe9GDIN6t+hHcVg//aeiijNqsQ3pjbFQn3VvND7hNfJ vrVcLZ+U4kOzXPF818aVdOnDyNXyE17vBDDcvaZ730sCsZIRZJ3KhUJ+nPvdttKjUIGLARmx+pA3 Jl3IIv2uLtOb3I0TMuyfIGJVGF+q10/CeDMKVjKlmyOVrR0opkel+KEoN7VLq3Hf3zPKENO1HBgp LHeP31tlb9cgs+u4o2wLrVe9myHbuFBW7EjWbSvdz2zliwbsFeFVLMNcWrKAU0GkkiH69SgnwmXU RkhGma4L27GLtkHHufsxfbcPqPtmtCttsGZU4EmrghGUqVyDOxnn8ZqybzLrRfpin+OCIX+aHJz5 r2L8qtrP0LorNMX3Gopd26vfhNvq/wq8xk++bW1R5FmkaUhx9h+DhO2ybcg7p/E8JHc8zrWv+bb3 0o9lkrOaU8GxXrgtb1cjtbb+MxFvjm0Elw7MSZDG7sF/APFU6cwuIA9Nai/OGAUCSt/W2ecS8Zox cWWbGSEiDvjtEctkpmHjfVuGoL34966Olm41VdH+NjgoSYUJKx4Mty8DRcZxdyoXll84LvDkEEYK ZqOIACsJf8CDFvUkmhXc+moCj15Yxtj3/RslRVEiOUyrpDwB72zWcZG8YnzoyGxhcRIc/gFejO/y SI8bzCpYngeuTb5NjFG+ChGiInHbQcFeHBlaHtKi2o/B5axIO5Ag0EVDvOgQEQALJby/ztliToGE u1lslvWQUQ6teKZVUQ7hy9bM4N83G0AGLatUBHtY6PkJBe4XkIw3sK7LoFCV2W4GSt4zWp9l+kG3 /J8Ow7EFjN0F7DrCg0M0lMg9dQz9jYSoBR8skaH3BRzCq9AKIVKV94poL/G65289L7zKDHoZnnyF qbBtedYZir0SZx+kiouZ1qnmxRPaYmH2fkuiuvYEAyzLDLYM8F5gQhdZM4YVtuvSICYPet0z4CDi JX/vZmDi3AzzoEVaKeAM/0H9f9Ni547J2+8dZSllgTrA+fq0aMJVScAObIxTAQtEq0DoNBzPpVrm W10b4bmgePrAvNkifqSr5StymSBgwvoeW6GrJiyN4XhoLOadZzwgjqioR1nXw5tXtrr5sYdkZ06b 1WWHkxtu1hFTdLC7RYNxY07ytLNM+C2lplCwCwlWB7RwI9BL1Dhre4kv8uaaX2Gksaq9mDf9MSDW qQ0TJ/RAiwMGmFrzBEYI1J2Oyeshi/dqW4/OiZAukOIlxOnt6u8zU2KL6Qjxqqna0oTbS4Zv3fRd YkuUCL6CDEJdkuRAiW+Gw+lKcMjXqApEqixhaDkoB/kwtu+2gIFTzAxMfwFN1YtNc0kJZWnFkGIW MrrwTcOwAFzlFz7wn/EyMFtg+ERcqMX0+olXDwM8MODI2+BzulPuEDEteCw09hABEBAAGJAh8EGA ECAAkFAlQ7zoECGwwACgkQe9GDIN6t+hFjuQ//UQyg49f8TytUYQaBb8R0UfI+KhQFs1Nsz2z8a3 0CD1MeiHHYWdAcomVvTkg4g5LbnYHVDrj/XagY3FN/AIE97usFbsTG+rsWAOLi7N2dN2ehWZ634k MvrgyC9uTiOdkw31+B8K5MpyySgD8e6SAzRfiu06/bcQOUyJifw8Hudpj9by4uyGhSH+kHu4afrp OduUighbsGFtcuRwwQ/w/oSk68XvPUgiOQWMZh/pVoXdFyFvrt/hgArCi8dfy5UPK58nl7jPnu/I uQXrJ50nNAFIIxPVeo2/B83KAnEZPU+qWZsdba0V+FIIQQVizLtQFMuJJk4/UTAOfJ2tBpQ9PADX 6/scqDE7unXNWdxcHTjK7KmWjXC8CyhGOx8V/rb7Ial4mZo4cTED6SNlO7dV1XYwnSctL2HCYNM3 RUe4eJ7JWuu7/Nbf6yip2eq7BQKZ9hAH/se/OSZNYsEkZ4pxUc8W5U3uAZImUwC6L74SM0jBZIuD mQhOYX6sZZ6urIn/MYlj4/hqSBFS4vTK7nXRLmtr7+5T5U5srVseUiYc+l9pu9/XD8zGIu+M2xEd 41NwP44GDQTQm0bFljRv5fSblwmi56YHPFQUIh2RZNX3kOJgeyQ3enw5uY+7ocKRVP38hpnffliL lJcO6TtHWnElS3pACbTQM0RHJox3zqU3q6K3c= User-Agent: NeoMutt/20180323 Archived-At: Subject: Re: [openpgp] Scoped trust (signatures) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 11:20:29 -0000 Hey Jon, > The standard as it exists is something that got the rough consensus of the > working group, and that rough consensus is worthy of a little respect. Perhaps > not too much, but certainly a little. The problem with making the protocol > match one’s own opinions is that it’s effectively saying not only that what > one thinks is right in some sense, but also that other people’s opinions are > wrong and that no one else should do something different. Thanks for your thoughtful reply! I think I understand where some of these decisions are coming from a little better now. - V From nobody Tue Jun 26 08:28:04 2018 Return-Path: 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 7D7AB131038 for ; Tue, 26 Jun 2018 08:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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, URIBL_BLOCKED=0.001] 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 3MmO25dQKaJR for ; Tue, 26 Jun 2018 08:27:58 -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 2F555130EAF for ; Tue, 26 Jun 2018 08:27:57 -0700 (PDT) Received: by smtp.gaspard.ninja (OpenSMTPD) with ESMTP id 8f6278bb for ; Tue, 26 Jun 2018 15:27:53 +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=U6oJvHM7F6mrZhrLFeaNOCwUa00=; b=rzhDtRFxdQkDsO Y3vqxniWyOi2e2kFo9XozW10uCyf0NemRhcE874mPeFG9Bk7SxhOgchLHnvI4A+E 5E+qbKWaTcuJDkDEcxTwQUQWSLgPoCgN6ulHAwtdaQsMhI/vVe7bUBjLnrvnwKAS iRRSJmwnGbgkjjERQFSGmEFerQqck= Received: by smtp.gaspard.ninja (OpenSMTPD) with ESMTPSA id 0603363c (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128:NO) for ; Tue, 26 Jun 2018 15:27:50 +0000 (UTC) To: openpgp@ietf.org References: <39e598e1-2bc0-32c9-3489-4bb6ca2a631b@leo.gaspard.ninja> <871sdw24yd.wl-neal@walfield.org> From: Leo Gaspard Message-ID: Date: Tue, 26 Jun 2018 17:27:49 +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: Content-Type: text/plain; charset=iso-2022-jp Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 15:28:03 -0000 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. On 05/28/2018 12:27 AM, Leo Gaspard wrote: > On 05/27/2018 10:56 PM, Neal H. Walfield wrote: >>> Another issue of this scheme, obviously, is that noone $B!H(Bin the wild$B!I(B >>> currently uses regular expression subpackets (that I know of). >> >> Not only does almost no one use regular expressions, but regular >> expression support is not very widely supported (GnuPG doesn't support >> regular expressions on Windows), and until recently broken in GnuPG >> (see https://dev.gnupg.org/T2923). >> >> I would like to make a counter proposal, that Vincent and I came up >> with at FOSDEM: I think that we should deprecate Regular Expression >> support and replace it with a list of domains (optionally prefixed >> with "*." to indicate any subdomain). First, most users don't >> understand regular expressions. And, although it would be possible to >> allow users to enter one or more domains and then convert them to a >> regular expression, it is not easy to reverse this process, which is >> essential for explanatory purposes and editing. Second, not including >> an RE engine reduces complexity. > > Issue > ----- > > This is what I had in mind at the beginning, but then I came upon a > stumbling block: User IDs. They are not at all standardized, so it's not > possible to assume they are in the form $B!H(BName (Comment) > $B!I(B. And, even if assuming this, how could the > implementation validate the $B!H(BName$B!I(B and $B!H(BComment$B!I(B parts, when the Regular > Expression support is replaced by something to validate by domain? > > So I think there are two problems here: > 1. User IDs are not standardized > 2. User IDs contain many unrelated information > > I already explained point 1, so I'll now explain point 2. User IDs as > currently used tie in a name and an email (I'll omit the Comment part). > Which are two completely unrelated things: I have a single real-life > name (well -- most people do), a pseudonym, and a lot of e-mail addresses. > > 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? > 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$B!D(B), and is now again an issue in > fixing the standard to be both more simple and more usable. > > > Idea > ---- > > So here is my idea: drop User IDs in v5 keys, and standardize more User > Attributes. In particular, standardize at least a $B!H(Bname$B!I(B, an $B!H(Bemail$B!I(B and > a $B!H(Bpseudonym$B!I(B user attribute. (I'm not sure about the $B!H(Bcomment$B!I(B user > attribute, and would prefer seeing it handled otherwise, see the > $B!H(BPossible extensions$B!I(B section) > > > Consequences > ------------ > > So what would happen were this done? > > First, when picking my User IDs, I wouldn't have to think over whether I > really want to associate such email address with my name or with my > pseudonym. > > Then, when signing User Attributes, I could just sign all user > attributes I checked. I could sign $B!H(Bemail$B!I(B User Attributes after > checking I could send and receive mail to the provided email, I could > sign $B!H(Bname$B!I(B attributes after checking a state-provided ID, and I could > sign $B!H(Bpseudonym$B!I(B and $B!H(Bcomment$B!I(B attributes depending on my local signing > policy (which I haven't really determined yet). > > Finally, this would make the scoping-by-domain-name proposal possible: > it'd be $B!H(Bcan only sign `email` User Attributes and the part after the > last @ must match this restriction$B!I(B. > > > Possible extensions > ------------------- > > So now with this change it would become possible to handle extensions of > the User IDs that have been proposed. > > First, the $B!H(B[project] signing key$B!I(B comment, that can be seen eg. > [here](https://sks-keyservers.net/pks/lookup?op=vindex&search=0x8B3F30F9C8C0C2EF). > This could be handled by adding a $B!H(Brole$B!I(B User Attribute, that could be > $B!H(BQubes OS developer$B!I(B here. And thus the organization only needs to > validate the keyholder is a QubesOS developer when signing this, without > having to also validate a name, an email address or whatever else. > > Then, the $B!H(BI have this account on this website$B!I(B, that can be seen eg. > [here](https://sks-keyservers.net/pks/lookup?op=vindex&search=0xAC6D00DB7F24B2C2), > and is the point that, as far as I understand, lead to the birth of > keybase.io (which did show some traction). It could be handled by a > $B!H(Baccount-on$B!I(B that would store both a domain name (for the website) and a > username. > > Finally, I think it would be good to stay more $B!H(Bopen to extensions$B!I(B than > the current scheme of (mis)using User IDs, by eg. reserving attribute > type 255 for $B!H(Bplaintext key-value user ID$B!I(B, so that implementations that > can't reasonably fit some data in one of these User Attributes could > just use it with raw key/values instead of using one of the 100-110 > reserved values, which wouldn't be displayed by implementations not > aware of them. > > > Remaining issues > ---------------- > > The foremost issue with this change is the one of the UI to display the > user: currently, in Enigmail (the only end-user-oriented UI I know of), > the primary User ID of the key is displayed. With this change, there > would no longer be a primary User ID. > > I can currently think of two UIs. The first would check that the name > and the email address of the received mail are valid, and error-out > otherwise. The second one would just pick a name and an email address > from the list of valid ones, and display it. > > In my opinion, the first option is *way* better than the second one, and > it's the reason why I didn't propose an extension of the Primary User ID > flag to handle multiple primary User Attributes (would be one name and > one email, for instance). > > For instance, a problem with primary User IDs/Attributes is the > following: let's assume I can validate a few UIDs on the key, but not > the primary one. What should I display? I think there is no good answer > to this question apart from $B!H(Bvalidate the one it came as$B!I(B or $B!H(Bshow all > the valid ones$B!I(B, and thus removing the Primary UID may remove some traps > naive implementations may fall in, like displaying a non-validated > primary UID. From nobody Tue Jun 26 12:13:47 2018 Return-Path: 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 3945113110D for ; Tue, 26 Jun 2018 12:13:46 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=metacode.biz 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 WWryVRfj8HfW for ; Tue, 26 Jun 2018 12:13:42 -0700 (PDT) Received: from mail-wr0-x241.google.com (mail-wr0-x241.google.com [IPv6:2a00:1450:400c:c0c::241]) (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 1502B131109 for ; Tue, 26 Jun 2018 12:13:42 -0700 (PDT) Received: by mail-wr0-x241.google.com with SMTP id p1-v6so2729149wrs.9 for ; Tue, 26 Jun 2018 12:13:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metacode.biz; s=2017; h=subject:to:references:from:openpgp:autocrypt:organization :message-id:date:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Ue1qWgSNBIWNf0wlFDS5XOCNVws155XJ9K8LM+5VBuo=; b=2M1QBzZ7W+pdKGxWfa1Ff6wZxzopVB8OFcs+C5OeNJD4W5FqngNlkTv8h8Ilg2oMKX WYvvcwoyx/m4BnnIhO8XbVMvSao7SLuPnoH1Cbo0juKHer17MTdOn8q3puErV9CsSnqV 1+Sev2grlR6QNCYgwv9phd/rFjlYXLWqWOB3FOAQQEue1mc+bJEnkGNNQbJRpvpuiTZ5 QMDCXOa4pFs+KuZ7+FnPwTqOj63fNllOmSSQg0+xZ8fsIYEY7Lnc5erocIeY5bby17RD 5YYoGuCNX/qWD3jVor89eg7j9VgBcbqeEsub5UPuRLy7tlaLP92sL6V+JN9jWVtxNS2l QpqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt :organization:message-id:date:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=Ue1qWgSNBIWNf0wlFDS5XOCNVws155XJ9K8LM+5VBuo=; b=W/JC+hQjpAAmv4Ry3V28rkBBXFRzba/TFLA4w3/29wvGawB4r/o5jYl1u/Y2uoUJOF B6/VdgsLaEjmB/GLHRqPYvZZPnmLPKrZgv4VtRsWydjnFrOHrOww1abV8tc8LPr5tPdq o6tmE0zS8Y4Np11k3bjEPWh7pmMHB2bXc2eAWm+OocekZOFFfo3faX+aLWLEisGRdqQ/ 2Qd9V7iS7UuHUF+fjYEekD5GjpyINC/kZIYgNLJoTINVsyATdDamFd6grS+7cHiHrRZ/ BQodhmxceTiZMhxQaSybZvGMIOn5GWLdrndAqQEmIes2Ixvnn9I0jAbiKTbPnXaUPnUD OrlQ== X-Gm-Message-State: APt69E1gKH5EJ4KdNN2Ti9DJLK2n4JlFhKJZ5F1B0CZ0jt445HsF0bMs OAnYiWhOaqZWU8wQAocbdSLy+8+6av8= X-Google-Smtp-Source: AAOMgpeYbUOxsLu+2jMI4BpJ8E7iOLCPPLya0uTISECW2nyWum1tlP4YUxP0AhlgUdsBMPwfBVutkQ== X-Received: by 2002:adf:a18f:: with SMTP id u15-v6mr2502932wru.194.1530040420298; Tue, 26 Jun 2018 12:13:40 -0700 (PDT) Received: from ?IPv6:2a00:f41:388b:98b6:dd1c:a7e0:c7d4:84fb? ([2a00:f41:388b:98b6:dd1c:a7e0:c7d4:84fb]) by smtp.googlemail.com with ESMTPSA id x16-v6sm4174309wme.12.2018.06.26.12.13.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Jun 2018 12:13:39 -0700 (PDT) To: Leo Gaspard , openpgp@ietf.org References: <39e598e1-2bc0-32c9-3489-4bb6ca2a631b@leo.gaspard.ninja> <871sdw24yd.wl-neal@walfield.org> From: Wiktor Kwapisiewicz Openpgp: id=653909A2F0E37C106F5FAF546C8857E0D8E8F074; url=https://metacode.biz/@wiktor/openpgp/key Autocrypt: addr=wiktor@metacode.biz; keydata= xsFNBFhoYHoBEADzmg9UuwDrtvyejU01gDY1J1iJiCi4XGJ4lCfYeLC2jSagIxU/5Lu0lRft 0Loi2tsjpo0c8docP7HFxafEEvnnt/iabd6I536llMuw0uno4PgnD3ljcCMZLT+vn+amIDta lzVoMnSqzoNUotMNMtjIFuAaQ/wr4/Mp9CIgJdviGUc3PscqUiiUVVtk6uF0x657NULZgSIT /Mrqlr2i4RuyPwXe2Qt0uEA3KWWjF0l2NpAMVrqz+nHsLoNOaAsfdx94bzKQrrSeSQqEO2f+ /eO/hbUAFAmEhrotmUO8wJNygo8TgkdlzFI+UE4p8/KW0aCgGGgR8YkCvHq2OQhAAYFNJoNz Hqw0FGxdsY8qWFkYpoSB8zKspNy8KliofCamMYXoPF7eVIxIiKvxrAykGP4jNnzSoV0cn+bY fXnox1IhnqbnoJIT7kTmXv4JmWoYm8ThHqpEgcQOUUQzSRXb9OiNwiXT71ijeO1qswMRpsgk 6AGKSZGWxa3c4ive/p8z1Ax27BFZSh2FceIcMCcGLrDjnQYgeFsAJ1jSxZQXkGuJFHfb4nff Big7aq/vyKrQFQXG0NQQL7rZAdk/s665vifos0yPmRDu7yDT1ggdyBp4Pa4re+ZJcNRNzNHo zU9al+CoImCQjnTtKMXmOe/BzGrpHI4QR3NNzVa423WCIWkHfwARAQABzSlXaWt0b3IgS3dh cGlzaWV3aWN6IDx3aWt0b3JAbWV0YWNvZGUuYml6PsLB7gQTAQoAmAIbAQgLCQgHDQwLCgUV CgkICwIeAQIXgHMUgAAAAAAqAEB0aW1lc3RhbXArYml0Y29pbi10cmFuc2FjdGlvbkBtZXRh Y29kZS5iaXphZmNiMDkyYzVjYTY0MDk1MjZkMThhZTljZjIyZDNiNTVkMzdlNzIzZWIxYjc0 ZTNmODRmN2U2YjA1MmExNjJhBQJaLoPdBQkDwPuGAAoJEGyIV+DY6PB0CNkQAKGTFHzG4YO6 yne5jfMlGcF8JUYq0EGHE9DRK6oAyGo+1TGFbf1bS4wULvA6LFBOLd+aI7uuN062kDdtHVUf 0S0AZ9ByjIBdQJsqx47W6uXsRX/pB0a70QqS6NbS3AL/fdwZOj/TBk8bdsfg7Z+hH+ykMcOs EYLmdMLmrqYgl9EyP4FmsnU9H8x4yKp0/Kv4BQYfjn68CFvyM2NQU3MR/H3sqvM/uY5AJwTp A8X1ZbN8pjZO5YRTiQtMrXekNzhP3p0ep1+cu2UxQO6jXV6Sjdm8D8RJzGaxCuhN/VhLNSvh cb2T5sejBAhU8JmKNle4+z5wZWB4bl5Dfkg1NpSEEdv7so+KXCnszo89UJJijlfgBFtm5WjK u7gCR8CVOeGQwQolEzi18zihCwRy1rg/xKokk7q6ZBEvxM1sBYNd81mi1PgrNwgH4jPULfQk UJtU7HLRVNLbnrIyEQbLOJegBLaWHgR4T69blBGg1oqiq/1PHnZuJauZhhNEAViX42VKJP1z w6PIfvbjg27wf4OjEDtVVXCrxqqljHRilagFQHGlU+iF6Ii2C3pNod11+lqJC0riFylxK/wu zHpoZdFg10gqMWIE2Exm7nJ6ToKv5kZqKC97mWrmh6FFEr6HmjDDuo+N4RER3VGj0dSey5nc eFQ2vry17IGN1ljV9TiARDgizsFNBFhoYf0BEACidQ4OVAKliYOnNzG5ltod8GS0eJj3CSnY 0gszCjS6Hm0OkvCN5RfEagALuLuJe06nFDB/mEvsV3CKO1rxPUrQnijxjl/L5LopdEVhwQoL UBhvMvdX62krk6CtsFUlQvHPS923+YoQ1/HWR8jbWLJq/PNJp3fE9FKbWX6BchOeZ/KCZ/Ip 6vv7YOVVyBVL8O/slSkEEaUS40ac/F70/wfUPXRgiOLYVikRNlphvmTu54F0KWFUbPYAhyr/ xSz8Joy34+e9h5ipEb+Cv9CrjQaHp8aLDAR1VJ3A+SjSt20mU1CuhKwpR+z0t/hjlOLHv0zR qWl3QNYmNBJ9I2oW4mH9FEDM3DRsWEaqdaL1uVeQ8rE4QZ6tbk76YS8eyRWjScLQm61USHxq 7KpUI73k6ST0Ylyj8D1a03dKUTuytgU0NhbFyArI2UHNvhm73X6qo7ofHlfgA6mVAaI4jW7r /CY0GLs29PyetdII/+6F50HAEXBswTesgx/2P6k+vHhReyZF7NgSkqEWaGgKdRlSyTpu/U+Q TRmLB/yWfL89+BMJZosX0oMWZxG7XPu18GXSeHNoSPw9xLNGWGMbKErIbyVqQyd6fu2gpYzO n9J57ImHvgoENvcyRl7sSOiZto/5EJiHubUBTeeuZf2V7QxfrP15h1SVkzDjIOP3qXF+oCI8 jQARAQABwsFlBBgBCgAPBQJYaGH9AhsMBQkB4TOAAAoJEGyIV+DY6PB0I94P/iFsWZcgYNaN JxXK99755nzKKDSqjCOkTgoV9h9cNaIZV944pupdugRW5ek6BV2/Cj93iCGMzrfzzvETPT4t 8oaC/0yJ0pzPUrFe9Uht2ghtmXQK6Mw0fM4daPKJtCQyMlfYljqKhxgIJ24cB+O04yOrvfCS FRQw/T4ngmqCvI1wRzxU98yljKKxcvQWZ6qY6izNeUZJ6Ie1iujQOEmnLSXMikcptGf5YC9C KY0f9MsCI75uCx2HKQRRcj/nOHE+dkwo5XyUbSuWhQu6bOHJI5S0ixkjVp6JQ4E1NBLR3P3V Kr1jg6ODbJ0w9B8peSumzFhGf0qo2RYkPYKkUFfejmUhphSAS2WmdGHbut32ibDn6vd/XTjs vGQUDQ2Bp3fXdqeTw79T5zGpS87omdnz/Wpavntjv9IbVTnCmJMfSBYUmMoBK94IEWttKmL/ UCmcoruhhLs1A3Xdn17gt6k+AkBapBd8IC15QiMedzCINtug399M9MMfgkW5NpGOunpLBbhG xUD2nqdK2j347/dGTT53sUa6tQw6IDNZrCWOJTqTeP6PD7BJt67tlywPgmLSBGYgWpnRNJhb 9QKzyn3KnUzp9lzUDLReEu2gdY2Kz1N5PVmmF/ysfKVJZ0ZGWPB4iR/HgAc6OY2TnHXiifKT EXmAO6RvoR7+8se4PUnv0mR1wsFlBBgBCgAPAhsMBQJaLoRUBQkDwPoDAAoJEGyIV+DY6PB0 XoMP/i+6XvyNE/XsdFgeAO/rtdELWphFUu1HbaKYeh6YMYjg71eR8KbYe2sz3M1Bawj/D7Kb tGRsxFshkLHau0N0cJHEr3U6j/U7sEWCW/YDlWSIyBWYg+j1k/aBczfL/oC9E9h8LOUUjjj3 vpRs2rHmIHT2aAvbRom1d4xaFh1kwn7sUKtc+0AoP5PCeBcfqMduunEPqsfsbmz1Dz+O5FJ7 LRG8YXyV+5YTT1pEuNjFm+GNBEvwhfJqN+H459ngMdZUkCyKwWLAMaJj6y9/ZJ8lrPLCjGDR p9FzhLg39gQqV5Vu41VyBr+9YucX/sWfQ1SuvWDMBnTKSOKX01RAHGvnOmtl3Vr4SqWDhFsO VdWluKugMiIdajKwgM9Bp+35O/l8QQbxxrRAy/TI+dB4w8Urn2oVPkAq8RgYJIzpYYUFnhKD EwcdoG8Lk2EqO60g9UR6tGVsW9/vYvVGHlm0kArIDF9o0zAo5wsuZE9kO4oneoIsCRLwjuZk bqQ+2V+8R3P5YkV8VogwwYPCAhkpGD/ACblux5ip1ilLWFm75Hj3aPkvJSWi5DfkoxzntZBM KrhpyhCKJFUPZovREteTzl8ns3/KvoUJ5VQF3HqXKw49sWrWSDHEugt9ERfCBzAuYl4WB7Qt xwe2q0voV3BFy8kd04NRiyJkBU0BeBHEHblrGY23 Organization: Metacode Message-ID: <67153bb3-8ec7-5b30-3d11-22fce0681b47@metacode.biz> Date: Tue, 26 Jun 2018 21:13:35 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=iso-2022-jp; format=flowed; delsp=yes Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 19:13:46 -0000 Hi Leo, > 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. >> 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"). >> 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$B!D(B), 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. >> So here is my idea: drop User IDs in v5 keys, and standardize more User >> Attributes. In particular, standardize at least a $B!H(Bname$B!I(B, an $B!H(Bemail$B!I(B and >> a $B!H(Bpseudonym$B!I(B user attribute. (I'm not sure about the $B!H(Bcomment$B!I(B user >> attribute, and would prefer seeing it handled otherwise, see the >> $B!H(BPossible extensions$B!I(B 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. 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. Sorry if this sounds negative. Have a nice day! Kind regards, 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. > > > On 05/28/2018 12:27 AM, Leo Gaspard wrote: >> On 05/27/2018 10:56 PM, Neal H. Walfield wrote: >>>> Another issue of this scheme, obviously, is that noone $B!H(Bin the wild$B!I(B >>>> currently uses regular expression subpackets (that I know of). >>> >>> Not only does almost no one use regular expressions, but regular >>> expression support is not very widely supported (GnuPG doesn't support >>> regular expressions on Windows), and until recently broken in GnuPG >>> (see https://dev.gnupg.org/T2923). >>> >>> I would like to make a counter proposal, that Vincent and I came up >>> with at FOSDEM: I think that we should deprecate Regular Expression >>> support and replace it with a list of domains (optionally prefixed >>> with "*." to indicate any subdomain). First, most users don't >>> understand regular expressions. And, although it would be possible to >>> allow users to enter one or more domains and then convert them to a >>> regular expression, it is not easy to reverse this process, which is >>> essential for explanatory purposes and editing. Second, not including >>> an RE engine reduces complexity. >> >> Issue >> ----- >> >> This is what I had in mind at the beginning, but then I came upon a >> stumbling block: User IDs. They are not at all standardized, so it's not >> possible to assume they are in the form $B!H(BName (Comment) >> $B!I(B. And, even if assuming this, how could the >> implementation validate the $B!H(BName$B!I(B and $B!H(BComment$B!I(B parts, when the Regular >> Expression support is replaced by something to validate by domain? >> >> So I think there are two problems here: >> 1. User IDs are not standardized >> 2. User IDs contain many unrelated information >> >> I already explained point 1, so I'll now explain point 2. User IDs as >> currently used tie in a name and an email (I'll omit the Comment part). >> Which are two completely unrelated things: I have a single real-life >> name (well -- most people do), a pseudonym, and a lot of e-mail addresses. >> >> 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? >> 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$B!D(B), and is now again an issue in >> fixing the standard to be both more simple and more usable. >> >> >> Idea >> ---- >> >> So here is my idea: drop User IDs in v5 keys, and standardize more User >> Attributes. In particular, standardize at least a $B!H(Bname$B!I(B, an $B!H(Bemail$B!I(B and >> a $B!H(Bpseudonym$B!I(B user attribute. (I'm not sure about the $B!H(Bcomment$B!I(B user >> attribute, and would prefer seeing it handled otherwise, see the >> $B!H(BPossible extensions$B!I(B section) >> >> >> Consequences >> ------------ >> >> So what would happen were this done? >> >> First, when picking my User IDs, I wouldn't have to think over whether I >> really want to associate such email address with my name or with my >> pseudonym. >> >> Then, when signing User Attributes, I could just sign all user >> attributes I checked. I could sign $B!H(Bemail$B!I(B User Attributes after >> checking I could send and receive mail to the provided email, I could >> sign $B!H(Bname$B!I(B attributes after checking a state-provided ID, and I could >> sign $B!H(Bpseudonym$B!I(B and $B!H(Bcomment$B!I(B attributes depending on my local signing >> policy (which I haven't really determined yet). >> >> Finally, this would make the scoping-by-domain-name proposal possible: >> it'd be $B!H(Bcan only sign `email` User Attributes and the part after the >> last @ must match this restriction$B!I(B. >> >> >> Possible extensions >> ------------------- >> >> So now with this change it would become possible to handle extensions of >> the User IDs that have been proposed. >> >> First, the $B!H(B[project] signing key$B!I(B comment, that can be seen eg. >> [here](https://sks-keyservers.net/pks/lookup?op=vindex&search=0x8B3F30F9C8C0C2EF). >> This could be handled by adding a $B!H(Brole$B!I(B User Attribute, that could be >> $B!H(BQubes OS developer$B!I(B here. And thus the organization only needs to >> validate the keyholder is a QubesOS developer when signing this, without >> having to also validate a name, an email address or whatever else. >> >> Then, the $B!H(BI have this account on this website$B!I(B, that can be seen eg. >> [here](https://sks-keyservers.net/pks/lookup?op=vindex&search=0xAC6D00DB7F24B2C2), >> and is the point that, as far as I understand, lead to the birth of >> keybase.io (which did show some traction). It could be handled by a >> $B!H(Baccount-on$B!I(B that would store both a domain name (for the website) and a >> username. >> >> Finally, I think it would be good to stay more $B!H(Bopen to extensions$B!I(B than >> the current scheme of (mis)using User IDs, by eg. reserving attribute >> type 255 for $B!H(Bplaintext key-value user ID$B!I(B, so that implementations that >> can't reasonably fit some data in one of these User Attributes could >> just use it with raw key/values instead of using one of the 100-110 >> reserved values, which wouldn't be displayed by implementations not >> aware of them. >> >> >> Remaining issues >> ---------------- >> >> The foremost issue with this change is the one of the UI to display the >> user: currently, in Enigmail (the only end-user-oriented UI I know of), >> the primary User ID of the key is displayed. With this change, there >> would no longer be a primary User ID. >> >> I can currently think of two UIs. The first would check that the name >> and the email address of the received mail are valid, and error-out >> otherwise. The second one would just pick a name and an email address >> from the list of valid ones, and display it. >> >> In my opinion, the first option is *way* better than the second one, and >> it's the reason why I didn't propose an extension of the Primary User ID >> flag to handle multiple primary User Attributes (would be one name and >> one email, for instance). >> >> For instance, a problem with primary User IDs/Attributes is the >> following: let's assume I can validate a few UIDs on the key, but not >> the primary one. What should I display? I think there is no good answer >> to this question apart from $B!H(Bvalidate the one it came as$B!I(B or $B!H(Bshow all >> the valid ones$B!I(B, and thus removing the Primary UID may remove some traps >> naive implementations may fall in, like displaying a non-validated >> primary UID. > > -- */metacode/* From nobody Tue Jun 26 13:45:53 2018 Return-Path: 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 7F165130ED2 for ; Tue, 26 Jun 2018 13:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.291 X-Spam-Level: X-Spam-Status: No, score=-4.291 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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=ruhr-uni-bochum.de 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 5Nlc-WUMjm39 for ; Tue, 26 Jun 2018 13:45:49 -0700 (PDT) Received: from out2.mail.ruhr-uni-bochum.de (out2.mail.ruhr-uni-bochum.de [IPv6:2a05:3e00:c:1001::8693:2ae5]) (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 71CE6130ECB for ; Tue, 26 Jun 2018 13:45:49 -0700 (PDT) Received: from mx2.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by out2.mail.ruhr-uni-bochum.de (Postfix mo-ext) with ESMTP id 41FdNV5f2Pz4wVJ for ; Tue, 26 Jun 2018 22:45:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ruhr-uni-bochum.de; s=mail-2017; t=1530045946; bh=URD9TGr6dqlXuG3dll/Iqg3YRANVuD6Gx5YD2BTtLZ4=; h=Subject:To:References:From:Date:In-Reply-To:From; b=hXwbX5B5JzDHtcpBIewsXMMCy+mnYHo8QS959gzPUBDOMHwGzqMjvTmPmGWZ5ar5h lvpgWVOdZWrm1ctePNt2hl2OvNvC3pLCXqDabYGWAMhoJkT8vVq/9C9mknsRtKzsEW 4JRe5FdESCza8m4bL50lOE7VtlwfMTFbLCw+5Cyg= Received: from out2.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by mx2.mail.ruhr-uni-bochum.de (Postfix idis) with ESMTP id 41FdNV4lmzz4x30 for ; Tue, 26 Jun 2018 22:45:46 +0200 (CEST) X-Envelope-Sender: X-RUB-Notes: Internal origin=134.147.42.227 Received: from mail1.mail.ruhr-uni-bochum.de (mail1.mail.ruhr-uni-bochum.de [134.147.42.227]) by out2.mail.ruhr-uni-bochum.de (Postfix mi-int) with ESMTP id 41FdNV4Gzdz4wVJ for ; Tue, 26 Jun 2018 22:45:46 +0200 (CEST) Received: from [192.168.142.139] (p4FE3FC17.dip0.t-ipconnect.de [79.227.252.23]) by mail1.mail.ruhr-uni-bochum.de (Postfix) with ESMTPSA id 41FdNV09QhzyVv for ; Tue, 26 Jun 2018 22:45:46 +0200 (CEST) To: openpgp@ietf.org References: <39e598e1-2bc0-32c9-3489-4bb6ca2a631b@leo.gaspard.ninja> <871sdw24yd.wl-neal@walfield.org> From: Marcus Brinkmann Openpgp: preference=signencrypt Message-ID: <118e5b9d-de9e-aa14-d8b4-19ef259f3d0a@ruhr-uni-bochum.de> Date: Tue, 26 Jun 2018 22:45:44 +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: Content-Type: text/plain; charset=iso-2022-jp Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.4 at mail1.mail.ruhr-uni-bochum.de X-Virus-Status: Clean Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 20:45:52 -0000 I think the problem you are facing is Zooko's triangle: Decentralised, meaningful names for keys can not be secure. The PGP (implementation) answer to this is the web of trust, but that is pretty much out of scope for OpenPGP (the standard). This is also apparent from your description by the introduction of external policies ("when I want to sign X, I need to check Y"), that are also out of scope for OpenPGP. This might explain the lack of response here. Once you are adding additional policies, you can create additional restrictions for user id fields, or introduce additional (private use?) user attributes ad lib, and those will be the least of your worries. OTOH, without such additional policies (that can be enforced by conforming implementations), the proposed fields will just be more free form fields in OpenPGP that accumulate cruft over time. There are a couple of those already, and we have a pretty bad track record validating those. On 06/26/2018 05:27 PM, Leo Gaspard wrote: > 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. From nobody Tue Jun 26 16:28:48 2018 Return-Path: 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 848CD130E69 for ; Tue, 26 Jun 2018 16:28:46 -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 RwcFUuyKYFfo for ; Tue, 26 Jun 2018 16:28:44 -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 0C277130E5E for ; Tue, 26 Jun 2018 16:28:43 -0700 (PDT) Received: by smtp.gaspard.ninja (OpenSMTPD) with ESMTP id 114359dd for ; Tue, 26 Jun 2018 23:28:40 +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=PGPY6jLeSmkM71dfaUV6WJ7Z/Zo=; b=XaTczYS062+gyQ gWl4ozttS4VwgEFb9Uv2IWYNY3nRQTJjTZWQiugRYQckGqY5PnULabPoXjZSHfal qZYOe1b+4eJOWH1Lx/U/xbxy/1r6kTXNLuQE1/3cNTVptmZUsMm7QKdgnUxqHjik ZtSAQ0NPYjjLQpamMwXqHmTQwWjNc= Received: by smtp.gaspard.ninja (OpenSMTPD) with ESMTPSA id 983bacc5 (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128:NO) for ; Tue, 26 Jun 2018 23:28:40 +0000 (UTC) To: openpgp@ietf.org References: <39e598e1-2bc0-32c9-3489-4bb6ca2a631b@leo.gaspard.ninja> <871sdw24yd.wl-neal@walfield.org> <118e5b9d-de9e-aa14-d8b4-19ef259f3d0a@ruhr-uni-bochum.de> From: Leo Gaspard Message-ID: Date: Wed, 27 Jun 2018 01:28:40 +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: <118e5b9d-de9e-aa14-d8b4-19ef259f3d0a@ruhr-uni-bochum.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 23:28:47 -0000 On 06/26/2018 10:45 PM, Marcus Brinkmann wrote: > I think the problem you are facing is Zooko's triangle: Decentralised, > meaningful names for keys can not be secure. Indeed, this is similar to what I am thinking. But Zooko's triangle is only for “decentralized” names, and what I see in all implementations that I know of is that the end-user “validates” a particular (sub)set of the names the key claims it has, and then uses these names. (similar to handles defined in XEP-0165) Also, I am not trying to solve Zooko's triangle, only to decouple elements that are currently tightly interwoven without any reasonable standard in the User ID field (hello @users.noreply.github.com, hello roles in comments, etc.) > The PGP (implementation) > answer to this is the web of trust, but that is pretty much out of scope > for OpenPGP (the standard). This is also apparent from your description > by the introduction of external policies ("when I want to sign X, I need > to check Y"), that are also out of scope for OpenPGP. This might > explain the lack of response here. > > Once you are adding additional policies, you can create additional > restrictions for user id fields, or introduce additional (private use?) > user attributes ad lib, and those will be the least of your worries. Hmm… I think rfc4880bis§5.2, and in particular signature type 0x13 for instance, do imply that “The issuer of this certification has done substantial verification of the claim of identity.”? And thus the standard doesn't currently address the “I want to sign an email address but not the name associated to it, because I haven't checked the name” use case, unless the one who generated the key (not the one who wants to sign) did generate orthogonal User IDs. And actually rfc4880bis even mentions “By convention, it includes an RFC 2822 [RFC2822] mail name-addr” (even if not enforcing it), thus encouraging non-orthogonal User IDs. > OTOH, without such additional policies (that can be enforced by > conforming implementations), the proposed fields will just be more free > form fields in OpenPGP that accumulate cruft over time. There are a > couple of those already, and we have a pretty bad track record > validating those. The point in these proposed fields, in my opinion, is that if User IDs are removed from v5 keys altogether (if they aren't then there is no point in doing it indeed), then there will be an enforced separation of different parts of the (current) User ID into separate fields. As for these fields becoming free form, I do hope that it wouldn't happen: for the image attribute (the only one standardized afaik), I haven't heard (yet?) of people using it for storing anything else than an image. And with fields like: * name * pseudonym * email * role * free form UTF-8 tag=value Then, contrarily to what currently happens with User IDs, I don't think the first four fields would really be misused: what's the point? there'd be a free form tag=value attribute type. And this would already be enough to split the User ID tag into orthogonal parts that could be signed independently, depending on the signer's policy. And even type “free form tag=value” brings much more display-ability than private-use types 100-110 that cannot be assumed to have any type. However, I do agree it'd be quite some maintenance burden, hence my hope to get some feedback from an implementer. But I think it's necessary for users and applications to behave consistently, and not mutilate the User ID field just because it is the only one that is sanely rendered :) From nobody Tue Jun 26 16:47:38 2018 Return-Path: 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 ; 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 ; 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 ; Tue, 26 Jun 2018 16:47:32 -0700 (PDT) Received: by smtp.gaspard.ninja (OpenSMTPD) with ESMTP id e671e5e4 for ; 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 ; 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> <67153bb3-8ec7-5b30-3d11-22fce0681b47@metacode.biz> From: Leo Gaspard 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: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From nobody Tue Jun 26 17:42:33 2018 Return-Path: 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 4894F130F04 for ; Tue, 26 Jun 2018 17:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ruhr-uni-bochum.de 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 0_0qxHO5Ov9n for ; Tue, 26 Jun 2018 17:42:28 -0700 (PDT) Received: from out2.mail.ruhr-uni-bochum.de (out2.mail.ruhr-uni-bochum.de [134.147.42.229]) (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 0D83D127332 for ; Tue, 26 Jun 2018 17:42:27 -0700 (PDT) Received: from mx2.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by out2.mail.ruhr-uni-bochum.de (Postfix mo-ext) with ESMTP id 41FkdY4ZgKz4x5W for ; Wed, 27 Jun 2018 02:42:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ruhr-uni-bochum.de; s=mail-2017; t=1530060145; bh=A1MSl7AuACweeMMkXWT3aZrSVw0UF/+YlC8Wt4cPHcg=; h=From:Subject:To:References:Date:In-Reply-To:From; b=fcLZzO/wRbfGQ/Z+S2noYt4RfcuiHC+xbGSZ44xYkorGHQ2O5CfzFCK6IEkO1RkTB KJhzTtxcYi6XOrPdnZ+TffiKaHhkheBvIhGGMK6WnhebKlDLMBx7TE29ySBTm/Wu/E mtjX8B2NAPPBmpqe29ByiwayTU1C3ex04S7AUiec= Received: from out2.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by mx2.mail.ruhr-uni-bochum.de (Postfix idis) with ESMTP id 41FkdY3x8nz4xSr for ; Wed, 27 Jun 2018 02:42:25 +0200 (CEST) X-Envelope-Sender: X-RUB-Notes: Internal origin=134.147.42.227 Received: from mail1.mail.ruhr-uni-bochum.de (mail1.mail.ruhr-uni-bochum.de [134.147.42.227]) by out2.mail.ruhr-uni-bochum.de (Postfix mi-int) with ESMTP id 41FkdY3gqgz4x5W for ; Wed, 27 Jun 2018 02:42:25 +0200 (CEST) Received: from [192.168.142.139] (p4FE3FC17.dip0.t-ipconnect.de [79.227.252.23]) by mail1.mail.ruhr-uni-bochum.de (Postfix) with ESMTPSA id 41FkdX5yvkzyWJ for ; Wed, 27 Jun 2018 02:42:24 +0200 (CEST) From: Marcus Brinkmann To: openpgp@ietf.org References: <39e598e1-2bc0-32c9-3489-4bb6ca2a631b@leo.gaspard.ninja> <871sdw24yd.wl-neal@walfield.org> <118e5b9d-de9e-aa14-d8b4-19ef259f3d0a@ruhr-uni-bochum.de> Openpgp: preference=signencrypt Message-ID: Date: Wed, 27 Jun 2018 02:42:24 +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: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.4 at mail1.mail.ruhr-uni-bochum.de X-Virus-Status: Clean Archived-At: Subject: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 00:42:32 -0000 On 06/27/2018 01:28 AM, Leo Gaspard wrote: > On 06/26/2018 10:45 PM, Marcus Brinkmann wrote: >> I think the problem you are facing is Zooko's triangle: Decentralised, >> meaningful names for keys can not be secure. > > Indeed, this is similar to what I am thinking. But Zooko's triangle is > only for “decentralized” names, and what I see in all implementations > that I know of is that the end-user “validates” a particular (sub)set of > the names the key claims it has, and then uses these names. (similar to > handles defined in XEP-0165) If the use is purely local, you don't need OpenPGP at all, just store a local label to name the key. That's what NeoPG will do and Sequoia wants to do that, too, AFAIK. The only reason to create (exportable) signatures is to convince thirdparties of the binding, either by authority (centralized+secure, CA-style) or by introduction (decentralized+insecure, web of trust). OpenPGP (standard and implementations) has the concept of a local, non-exportable signature. As far as I am concerned, that's just a leaky abstraction due to historic implementation details being exposed, just as with Trust Packets: Non-exportable signatures are by definition local, and trust packets are local by a SHOULD rule (and in fact wholly implementation defined). > Also, I am not trying to solve Zooko's triangle, only to decouple > elements that are currently tightly interwoven without any reasonable > standard in the User ID field (hello @users.noreply.github.com, hello > roles in comments, etc.) There is value in standardization of user id field values, but I am not sure that OpenPGP is the place for that. Not only has that ship sailed, it is also mostly useful if embedded in a larger policy framework, as you have suggested from the beginning. >> The PGP (implementation) >> answer to this is the web of trust, but that is pretty much out of scope >> for OpenPGP (the standard). This is also apparent from your description >> by the introduction of external policies ("when I want to sign X, I need >> to check Y"), that are also out of scope for OpenPGP. This might >> explain the lack of response here. >> >> Once you are adding additional policies, you can create additional >> restrictions for user id fields, or introduce additional (private use?) >> user attributes ad lib, and those will be the least of your worries. > > Hmm… I think rfc4880bis§5.2, and in particular signature type 0x13 for > instance, do imply that “The issuer of this certification has done > substantial verification of the claim of identity.”? Doesn't mean anything. In fact, in the same section the standard says: "Please note that the vagueness of these meanings is not a flaw, but a feature of the system. Because OpenPGP places final authority for validity upon the receiver of a signature, it may be that one signer's casual act might be more rigorous than some other authority's positive act." > And thus the standard doesn't currently address the “I want to sign an > email address but not the name associated to it, because I haven't > checked the name” use case, unless the one who generated the key (not > the one who wants to sign) did generate orthogonal User IDs. You can just create your own user ids and bind them to the key. Don't laugh! See https://bitbucket.org/skskeyserver/sks-keyserver/issues/41 I am not suggesting that you should do this, or that it is or should be meaningful. Just pointing out that the standard is incomplete in many more ways than you might think. > And actually rfc4880bis even mentions “By convention, it includes an RFC > 2822 [RFC2822] mail name-addr” (even if not enforcing it), thus > encouraging non-orthogonal User IDs. Doesn't mean anything. Here is a key with a key in the user id: 97E4CFC94B1D6212 > The point in these proposed fields, in my opinion, is that if User IDs > are removed from v5 keys altogether (if they aren't then there is no > point in doing it indeed), then there will be an enforced separation enforced by whom? according to which rules? > of > different parts of the (current) User ID into separate fields. > > As for these fields becoming free form, I do hope that it wouldn't > happen: Here is a decentralised file storage based on OpenPGP user ids and public keyserver networks; https://github.com/yakamok/keyserver-fs This is using uids, but if you remove them, hacks like this will move on to other available fields. > for the image attribute (the only one standardized afaik), I > haven't heard (yet?) of people using it for storing anything else than > an image. And with fields like: > * name > * pseudonym > * email > * role > * free form UTF-8 tag=value > Then, contrarily to what currently happens with User IDs, I don't think > the first four fields would really be misused: what's the point? there'd > be a free form tag=value attribute type. "What's the point?" isn't the question. Either you can enforce something or you can't. If you can't, then you can't rely on it, and then the value of the rule will be severly diminished. The 4.5 million or so keys on the SKS keyservers are public, you can download them and investigate yourself what the consistency of the existing dataset is. I haven't looked at photo ids yet in detail, so those might look favorable, but that's probably just because there is low-hanging fruit. Just to give you an example: A local non-profit created hundreds of keys and added signatures to the gpg maintainer's key to wish him a merry christmas: http://a.keyserver.pki.scientia.net/pks/lookup?op=vindex&search=0xF2AD85AC1E42B367 (scroll down) > And this would already be enough to split the User ID tag into > orthogonal parts that could be signed independently, depending on the > signer's policy. And even type “free form tag=value” brings much more > display-ability than private-use types 100-110 that cannot be assumed to > have any type. > > However, I do agree it'd be quite some maintenance burden, hence my hope > to get some feedback from an implementer. But I think it's necessary for > users and applications to behave consistently, and not mutilate the User > ID field just because it is the only one that is sanely rendered :) For NeoPG, I'd simply use an URI scheme in the user id field, if I felt that it should be exported. Thanks, Marcus From nobody Tue Jun 26 18:31:09 2018 Return-Path: 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 877E1130DD0 for ; Tue, 26 Jun 2018 18:31:06 -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 uCx9H8Fy12cK for ; Tue, 26 Jun 2018 18:31:02 -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 4F42C126DBF for ; Tue, 26 Jun 2018 18:31:02 -0700 (PDT) Received: by smtp.gaspard.ninja (OpenSMTPD) with ESMTP id 9e8fe51f for ; Wed, 27 Jun 2018 01:30:58 +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=V6XxnnEbNfQqED1t7JHqyLFCpck=; b=2SiXJ0aSOeC1I1 Ontmpe7HJvUu6VTLt5dIXFSoLDBCNuWRAUhV6SUmcXESspR5PIJ/HqIBJ5z19PsE 80d2Ve3uyzgHQBquCHofgQ7eb4URUK8uMYYaBNIaHFEqziCJ9ohjJgp6FsMs+uFG rUkt2qeFgNznWA/oJhmnU6hw2WzPA= Received: by smtp.gaspard.ninja (OpenSMTPD) with ESMTPSA id f1621f78 (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128:NO) for ; Wed, 27 Jun 2018 01:30:58 +0000 (UTC) To: openpgp@ietf.org References: <39e598e1-2bc0-32c9-3489-4bb6ca2a631b@leo.gaspard.ninja> <871sdw24yd.wl-neal@walfield.org> <118e5b9d-de9e-aa14-d8b4-19ef259f3d0a@ruhr-uni-bochum.de> From: Leo Gaspard Message-ID: <3996841a-b6ae-8769-2de8-b35351c54719@leo.gaspard.ninja> Date: Wed, 27 Jun 2018 03:30:58 +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: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 01:31:07 -0000 On 06/27/2018 02:42 AM, Marcus Brinkmann wrote: > On 06/27/2018 01:28 AM, Leo Gaspard wrote: >> On 06/26/2018 10:45 PM, Marcus Brinkmann wrote: >>> I think the problem you are facing is Zooko's triangle: Decentralised, >>> meaningful names for keys can not be secure. >> >> Indeed, this is similar to what I am thinking. But Zooko's triangle is >> only for “decentralized” names, and what I see in all implementations >> that I know of is that the end-user “validates” a particular (sub)set of >> the names the key claims it has, and then uses these names. (similar to >> handles defined in XEP-0165) > > If the use is purely local, you don't need OpenPGP at all, just store a > local label to name the key. That's what NeoPG will do and Sequoia wants > to do that, too, AFAIK. > > The only reason to create (exportable) signatures is to convince > thirdparties of the binding, either by authority (centralized+secure, > CA-style) or by introduction (decentralized+insecure, web of trust). > > OpenPGP (standard and implementations) has the concept of a local, > non-exportable signature. As far as I am concerned, that's just a leaky > abstraction due to historic implementation details being exposed, just > as with Trust Packets: Non-exportable signatures are by definition > local, and trust packets are local by a SHOULD rule (and in fact wholly > implementation defined). Indeed my reply was completely off-track here, and I was thinking only of local signatures when writing this… which was stupid, given that all the point is about making signatures for others to use. >> Also, I am not trying to solve Zooko's triangle, only to decouple >> elements that are currently tightly interwoven without any reasonable >> standard in the User ID field (hello @users.noreply.github.com, hello >> roles in comments, etc.) > > There is value in standardization of user id field values, but I am not > sure that OpenPGP is the place for that. Not only has that ship sailed, > it is also mostly useful if embedded in a larger policy framework, as > you have suggested from the beginning. Well… OpenPGP already has User Attributes, hence my hope User IDs could disappear in v5 keys. I do agree that the ship has sailed for >> The PGP (implementation) >>> answer to this is the web of trust, but that is pretty much out of scope >>> for OpenPGP (the standard). This is also apparent from your description >>> by the introduction of external policies ("when I want to sign X, I need >>> to check Y"), that are also out of scope for OpenPGP. This might >>> explain the lack of response here. >>> >>> Once you are adding additional policies, you can create additional >>> restrictions for user id fields, or introduce additional (private use?) >>> user attributes ad lib, and those will be the least of your worries. >> >> Hmm… I think rfc4880bis§5.2, and in particular signature type 0x13 for >> instance, do imply that “The issuer of this certification has done >> substantial verification of the claim of identity.”? > > Doesn't mean anything. In fact, in the same section the standard says: > > "Please note that the vagueness of these meanings is not a flaw, but a > feature of the system. Because OpenPGP places final authority for > validity upon the receiver of a signature, it may be that one > signer's casual act might be more rigorous than some other > authority's positive act." Well, I'm not implying that this paragraph means anything, just that there is a concept of signature in the OpenPGP spec, and that it sounds legitimate (to me) to want to have a way to sign only the parts of the User ID that I want to sign :) >> And thus the standard doesn't currently address the “I want to sign an >> email address but not the name associated to it, because I haven't >> checked the name” use case, unless the one who generated the key (not >> the one who wants to sign) did generate orthogonal User IDs. > > You can just create your own user ids and bind them to the key. Don't > laugh! See https://bitbucket.org/skskeyserver/sks-keyserver/issues/41 > > I am not suggesting that you should do this, or that it is or should be > meaningful. Just pointing out that the standard is incomplete in many > more ways than you might think. Well, thanks for this link! I never noticed this indeed, and it could come in handy… but I don't think it's a good idea either, indeed. >> And actually rfc4880bis even mentions “By convention, it includes an RFC >> 2822 [RFC2822] mail name-addr” (even if not enforcing it), thus >> encouraging non-orthogonal User IDs. > > Doesn't mean anything. Here is a key with a key in the user id: > 97E4CFC94B1D6212 Well, the fact that some people don't respect the conventions doesn't mean they're not conventions: in practice, nearly all keys I exchange information with have only User IDs in the “name ” format. Which is a problem from the “signing only the mail address” standpoint. >> The point in these proposed fields, in my opinion, is that if User IDs >> are removed from v5 keys altogether (if they aren't then there is no >> point in doing it indeed), then there will be an enforced separation > > enforced by whom? according to which rules? Enforced technically by the absence of a User ID field. I'm not saying it will not be possible to misuse fields, but that the convention should naturally follow the namings: names in the “name” fields, pseudonyms in the “pseudonym” fields, emails in the “email” fields, roles in the “role” fields, etc. >> of >> different parts of the (current) User ID into separate fields. >> >> As for these fields becoming free form, I do hope that it wouldn't >> happen: > > Here is a decentralised file storage based on OpenPGP user ids and > public keyserver networks; > > https://github.com/yakamok/keyserver-fs > > This is using uids, but if you remove them, hacks like this will move on > to other available fields. Well, of course it's always possible to hack around things. But I don't really care for these hacks, they can continue to use v4 keys, or any other field of their choosing. It's not like I'm going to sign such an identifier anyway. What I'm saying is that if I can have, when signing a key, a series of dialog boxes for all names and then for all pseudonyms and then for all email addresses etc. that ask me whether I have signed the key, then as an end-user I'm happy. On the other hand, if I always come back on the name I haven't checked (like on 0x57B62140, which has User IDs with your name), then I can only growl against the software and answer “no” to all questions, despite my having checked the email address. >> for the image attribute (the only one standardized afaik), I >> haven't heard (yet?) of people using it for storing anything else than >> an image. And with fields like: >> * name >> * pseudonym >> * email >> * role >> * free form UTF-8 tag=value >> Then, contrarily to what currently happens with User IDs, I don't think >> the first four fields would really be misused: what's the point? there'd >> be a free form tag=value attribute type. > > "What's the point?" isn't the question. Either you can enforce something > or you can't. If you can't, then you can't rely on it, and then the > value of the rule will be severly diminished. Well, even if I can't *enforce* that people put the right data at the right place, if I imagine a user seeing a form like: Name: [ ] Pseudonym: [ ] (add another field) Email: [ ] (add another field) Role: [ ] (add another field) Other: [ ] = [ ] (add another field) (with the “Other” potentially replaced by more user-friendly “GitHub username”, “GitLab username”, etc.) Then I think that 99% of legitimate users will make the correct choice. And then I can just assume that the rule is followed, and reap the benefit. And even if some people have fun putting files in the “name” field, then I just won't sign their keys, and who cares? > The 4.5 million or so keys on the SKS keyservers are public, you can > download them and investigate yourself what the consistency of the > existing dataset is. I haven't looked at photo ids yet in detail, so > those might look favorable, but that's probably just because there is > low-hanging fruit. > > Just to give you an example: A local non-profit created hundreds of keys > and added signatures to the gpg maintainer's key to wish him a merry > christmas: > http://a.keyserver.pki.scientia.net/pks/lookup?op=vindex&search=0xF2AD85AC1E42B367 > (scroll down) Well… You're describing how broken the SKS network is (not saying these bugs are not also features), I don't see how that relates to changing the concept of User ID: such nonsense would (a priori) still be possible after the change, but not worse than before :) >> And this would already be enough to split the User ID tag into >> orthogonal parts that could be signed independently, depending on the >> signer's policy. And even type “free form tag=value” brings much more >> display-ability than private-use types 100-110 that cannot be assumed to >> have any type. >> >> However, I do agree it'd be quite some maintenance burden, hence my hope >> to get some feedback from an implementer. But I think it's necessary for >> users and applications to behave consistently, and not mutilate the User >> ID field just because it is the only one that is sanely rendered :) > > For NeoPG, I'd simply use an URI scheme in the user id field, if I felt > that it should be exported. Well… Honestly, I think this represents a failure of the standardization process. This use case is already present in the real world, and people have already started using work-arounds around it. For instance, SKS keyservers return around 460 results for “users.noreply.github.com”, and that's only the use case I searched for because I know someone with such a UID. Basically, what I remember from your message is “that ship has sailed,” and… that makes me sad. I think these use cases (signing only an email address, or signing a GitHub identity, or even an OTR identity) do fit into the scope of the OpenPGP standard, and I'd love to see them addressed. But maybe it'd be better to have another protocol that'd be dedicated to only asserting some identities and linking them to the keys for certain protocols… that'd be splitting off the WoT into a separate protocol, but maybe it'd be better this way? Anyway, that's getting quite far off-track for the OpenPGP working group, and I still hope such a change could make sense for OpenPGP v5 keys. From nobody Wed Jun 27 01:07:22 2018 Return-Path: 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 64D64130E87 for ; Wed, 27 Jun 2018 01:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=metacode.biz 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 wfWglUUeja-P for ; Wed, 27 Jun 2018 01:07:17 -0700 (PDT) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (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 5763A1277D2 for ; Wed, 27 Jun 2018 01:07:17 -0700 (PDT) Received: by mail-wr0-x22f.google.com with SMTP id c5-v6so1009304wrs.10 for ; Wed, 27 Jun 2018 01:07:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metacode.biz; s=2017; h=subject:to:references:from:openpgp:autocrypt:organization :message-id:date:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=JBMBEc1te8zUs7KKLf1GYBCoL+qvEoQ2FoD3BP7eedo=; b=Ni7pRQI5QWq6ZCz/88LcZt0aqMi167P8/TH32NP5LrHfkPa9OPVQe6E6KNo4FWTSR0 3dISpU9Wy5of/EMdQODqiKq6e6EVxQ0mKAfK6qkSs4Z1jcejrdYErvYG0IOeM30WAyrX kc5uW11NSwK9AISops1tZorJmYkHFak4S7kuxz9S/GjvKDRY4Mv0w1o2N/hwQX0Sdb8a SPMOyUMjL+ivpk9W5rkzNAGAUD3pmDtxjevDJd6pF4Q0BxGo9wdqnx/dJAi8Sn5h/xGz iegRxwAfff27D3JUbmqt5VE9+aj13PQA/TNxyGY9vD4wPWUascJYLQbJZZgjcJ0vs2XG eu0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt :organization:message-id:date:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=JBMBEc1te8zUs7KKLf1GYBCoL+qvEoQ2FoD3BP7eedo=; b=lMEy6zfzTDuD2Fhyumo/VsZ0oUN96QmdARZgCURkNtJpMZ4peLzfMoqboLvyDmXVmJ kkitRWO4toEPYmxvdaiBUfXmgz9s/gGeMCepoS0o38Unn3bbOoEAnYwuasW/hJPzVVhS R+ZUedC3np+YpiD6hwg20X7cASnpdowC8wbo4GdeOOZZfTmka8fr78A61dFt4VwzYXgB OCvjK6VQJw1heVBmTfpHNABr21W8c6Us0Zg78AogpWfh8DSJXcKY2KMoazQVdtor7KGq Hv0DuG5g2WGkE4WryFFfVw/LiBYRCfzmehayr9vfWIvg54Gf7LKaWvi0+HrQkPTdy+li k6zQ== X-Gm-Message-State: APt69E1S0NmaZ4dsxvPMCHsPTEK1LKMnck3niBAgI14L9BtC1h6Na8AE oVVDSwdXELlgLAaW8DqUIzD5D2lTWQ4= X-Google-Smtp-Source: AAOMgpe3wLLBH2VdJHtP8KPP+pYDPiTIwlLtBthMP1CE066qkwUiWpk3evDd/QCUpWtld0Ijciv7Xw== X-Received: by 2002:adf:de8e:: with SMTP id w14-v6mr810013wrl.72.1530086835479; Wed, 27 Jun 2018 01:07:15 -0700 (PDT) Received: from ?IPv6:2a00:f41:386d:3f8f:3161:3c69:519:f582? ([2a00:f41:386d:3f8f:3161:3c69:519:f582]) by smtp.googlemail.com with ESMTPSA id h77-v6sm6267729wmd.9.2018.06.27.01.07.12 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Jun 2018 01:07:14 -0700 (PDT) To: openpgp@ietf.org References: <39e598e1-2bc0-32c9-3489-4bb6ca2a631b@leo.gaspard.ninja> <871sdw24yd.wl-neal@walfield.org> <67153bb3-8ec7-5b30-3d11-22fce0681b47@metacode.biz> <2d737acb-0ce9-b703-ceb9-29c9a2ef2c0e@leo.gaspard.ninja> From: Wiktor Kwapisiewicz Openpgp: id=653909A2F0E37C106F5FAF546C8857E0D8E8F074; url=https://metacode.biz/@wiktor/openpgp/key Autocrypt: addr=wiktor@metacode.biz; keydata= xsFNBFhoYHoBEADzmg9UuwDrtvyejU01gDY1J1iJiCi4XGJ4lCfYeLC2jSagIxU/5Lu0lRft 0Loi2tsjpo0c8docP7HFxafEEvnnt/iabd6I536llMuw0uno4PgnD3ljcCMZLT+vn+amIDta lzVoMnSqzoNUotMNMtjIFuAaQ/wr4/Mp9CIgJdviGUc3PscqUiiUVVtk6uF0x657NULZgSIT /Mrqlr2i4RuyPwXe2Qt0uEA3KWWjF0l2NpAMVrqz+nHsLoNOaAsfdx94bzKQrrSeSQqEO2f+ /eO/hbUAFAmEhrotmUO8wJNygo8TgkdlzFI+UE4p8/KW0aCgGGgR8YkCvHq2OQhAAYFNJoNz Hqw0FGxdsY8qWFkYpoSB8zKspNy8KliofCamMYXoPF7eVIxIiKvxrAykGP4jNnzSoV0cn+bY fXnox1IhnqbnoJIT7kTmXv4JmWoYm8ThHqpEgcQOUUQzSRXb9OiNwiXT71ijeO1qswMRpsgk 6AGKSZGWxa3c4ive/p8z1Ax27BFZSh2FceIcMCcGLrDjnQYgeFsAJ1jSxZQXkGuJFHfb4nff Big7aq/vyKrQFQXG0NQQL7rZAdk/s665vifos0yPmRDu7yDT1ggdyBp4Pa4re+ZJcNRNzNHo zU9al+CoImCQjnTtKMXmOe/BzGrpHI4QR3NNzVa423WCIWkHfwARAQABzSlXaWt0b3IgS3dh cGlzaWV3aWN6IDx3aWt0b3JAbWV0YWNvZGUuYml6PsLB7gQTAQoAmAIbAQgLCQgHDQwLCgUV CgkICwIeAQIXgHMUgAAAAAAqAEB0aW1lc3RhbXArYml0Y29pbi10cmFuc2FjdGlvbkBtZXRh Y29kZS5iaXphZmNiMDkyYzVjYTY0MDk1MjZkMThhZTljZjIyZDNiNTVkMzdlNzIzZWIxYjc0 ZTNmODRmN2U2YjA1MmExNjJhBQJaLoPdBQkDwPuGAAoJEGyIV+DY6PB0CNkQAKGTFHzG4YO6 yne5jfMlGcF8JUYq0EGHE9DRK6oAyGo+1TGFbf1bS4wULvA6LFBOLd+aI7uuN062kDdtHVUf 0S0AZ9ByjIBdQJsqx47W6uXsRX/pB0a70QqS6NbS3AL/fdwZOj/TBk8bdsfg7Z+hH+ykMcOs EYLmdMLmrqYgl9EyP4FmsnU9H8x4yKp0/Kv4BQYfjn68CFvyM2NQU3MR/H3sqvM/uY5AJwTp A8X1ZbN8pjZO5YRTiQtMrXekNzhP3p0ep1+cu2UxQO6jXV6Sjdm8D8RJzGaxCuhN/VhLNSvh cb2T5sejBAhU8JmKNle4+z5wZWB4bl5Dfkg1NpSEEdv7so+KXCnszo89UJJijlfgBFtm5WjK u7gCR8CVOeGQwQolEzi18zihCwRy1rg/xKokk7q6ZBEvxM1sBYNd81mi1PgrNwgH4jPULfQk UJtU7HLRVNLbnrIyEQbLOJegBLaWHgR4T69blBGg1oqiq/1PHnZuJauZhhNEAViX42VKJP1z w6PIfvbjg27wf4OjEDtVVXCrxqqljHRilagFQHGlU+iF6Ii2C3pNod11+lqJC0riFylxK/wu zHpoZdFg10gqMWIE2Exm7nJ6ToKv5kZqKC97mWrmh6FFEr6HmjDDuo+N4RER3VGj0dSey5nc eFQ2vry17IGN1ljV9TiARDgizsFNBFhoYf0BEACidQ4OVAKliYOnNzG5ltod8GS0eJj3CSnY 0gszCjS6Hm0OkvCN5RfEagALuLuJe06nFDB/mEvsV3CKO1rxPUrQnijxjl/L5LopdEVhwQoL UBhvMvdX62krk6CtsFUlQvHPS923+YoQ1/HWR8jbWLJq/PNJp3fE9FKbWX6BchOeZ/KCZ/Ip 6vv7YOVVyBVL8O/slSkEEaUS40ac/F70/wfUPXRgiOLYVikRNlphvmTu54F0KWFUbPYAhyr/ xSz8Joy34+e9h5ipEb+Cv9CrjQaHp8aLDAR1VJ3A+SjSt20mU1CuhKwpR+z0t/hjlOLHv0zR qWl3QNYmNBJ9I2oW4mH9FEDM3DRsWEaqdaL1uVeQ8rE4QZ6tbk76YS8eyRWjScLQm61USHxq 7KpUI73k6ST0Ylyj8D1a03dKUTuytgU0NhbFyArI2UHNvhm73X6qo7ofHlfgA6mVAaI4jW7r /CY0GLs29PyetdII/+6F50HAEXBswTesgx/2P6k+vHhReyZF7NgSkqEWaGgKdRlSyTpu/U+Q TRmLB/yWfL89+BMJZosX0oMWZxG7XPu18GXSeHNoSPw9xLNGWGMbKErIbyVqQyd6fu2gpYzO n9J57ImHvgoENvcyRl7sSOiZto/5EJiHubUBTeeuZf2V7QxfrP15h1SVkzDjIOP3qXF+oCI8 jQARAQABwsFlBBgBCgAPBQJYaGH9AhsMBQkB4TOAAAoJEGyIV+DY6PB0I94P/iFsWZcgYNaN JxXK99755nzKKDSqjCOkTgoV9h9cNaIZV944pupdugRW5ek6BV2/Cj93iCGMzrfzzvETPT4t 8oaC/0yJ0pzPUrFe9Uht2ghtmXQK6Mw0fM4daPKJtCQyMlfYljqKhxgIJ24cB+O04yOrvfCS FRQw/T4ngmqCvI1wRzxU98yljKKxcvQWZ6qY6izNeUZJ6Ie1iujQOEmnLSXMikcptGf5YC9C KY0f9MsCI75uCx2HKQRRcj/nOHE+dkwo5XyUbSuWhQu6bOHJI5S0ixkjVp6JQ4E1NBLR3P3V Kr1jg6ODbJ0w9B8peSumzFhGf0qo2RYkPYKkUFfejmUhphSAS2WmdGHbut32ibDn6vd/XTjs vGQUDQ2Bp3fXdqeTw79T5zGpS87omdnz/Wpavntjv9IbVTnCmJMfSBYUmMoBK94IEWttKmL/ UCmcoruhhLs1A3Xdn17gt6k+AkBapBd8IC15QiMedzCINtug399M9MMfgkW5NpGOunpLBbhG xUD2nqdK2j347/dGTT53sUa6tQw6IDNZrCWOJTqTeP6PD7BJt67tlywPgmLSBGYgWpnRNJhb 9QKzyn3KnUzp9lzUDLReEu2gdY2Kz1N5PVmmF/ysfKVJZ0ZGWPB4iR/HgAc6OY2TnHXiifKT EXmAO6RvoR7+8se4PUnv0mR1wsFlBBgBCgAPAhsMBQJaLoRUBQkDwPoDAAoJEGyIV+DY6PB0 XoMP/i+6XvyNE/XsdFgeAO/rtdELWphFUu1HbaKYeh6YMYjg71eR8KbYe2sz3M1Bawj/D7Kb tGRsxFshkLHau0N0cJHEr3U6j/U7sEWCW/YDlWSIyBWYg+j1k/aBczfL/oC9E9h8LOUUjjj3 vpRs2rHmIHT2aAvbRom1d4xaFh1kwn7sUKtc+0AoP5PCeBcfqMduunEPqsfsbmz1Dz+O5FJ7 LRG8YXyV+5YTT1pEuNjFm+GNBEvwhfJqN+H459ngMdZUkCyKwWLAMaJj6y9/ZJ8lrPLCjGDR p9FzhLg39gQqV5Vu41VyBr+9YucX/sWfQ1SuvWDMBnTKSOKX01RAHGvnOmtl3Vr4SqWDhFsO VdWluKugMiIdajKwgM9Bp+35O/l8QQbxxrRAy/TI+dB4w8Urn2oVPkAq8RgYJIzpYYUFnhKD EwcdoG8Lk2EqO60g9UR6tGVsW9/vYvVGHlm0kArIDF9o0zAo5wsuZE9kO4oneoIsCRLwjuZk bqQ+2V+8R3P5YkV8VogwwYPCAhkpGD/ACblux5ip1ilLWFm75Hj3aPkvJSWi5DfkoxzntZBM KrhpyhCKJFUPZovREteTzl8ns3/KvoUJ5VQF3HqXKw49sWrWSDHEugt9ERfCBzAuYl4WB7Qt xwe2q0voV3BFy8kd04NRiyJkBU0BeBHEHblrGY23 Organization: Metacode Message-ID: <6f540f57-637c-f94c-4001-96ea9d14007f@metacode.biz> Date: Wed, 27 Jun 2018 10:07:06 +0200 MIME-Version: 1.0 In-Reply-To: <2d737acb-0ce9-b703-ceb9-29c9a2ef2c0e@leo.gaspard.ninja> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 08:07:21 -0000 Hi Leo, Okay, after your explanations and thinking about this through the night I can see some benefits. Especially to the split of names (people usually have only one name and it's usually verified using government issued IDs) and e-mails (that can be automatically verified). There are projects [0] that want to verify e-mails and add signatures to indicate "verified e-mail" but because e-mail and name are joined the signature also covers the name (that wouldn't be necessary in your design). Sometimes the name in UID is not welcome (see "mailbox-only" in WKD [1]). 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, E-mail ID could be generalized to an URI ID (e.g. e-mail would be "mailto:user@example.com"), then your "account-on" ID could also be a URI (e.g. https://github.com/user, or XMPP account: xmpp:user@example.com) [2]. But I think the most severe issue with your proposal is the ripple effect it would have on the trust system. Currently one valid User ID is necessary to mark the key as valid. And that valid User ID means both the name and the e-mail (in most scenarios). But with split names and e-mails a more elaborate design would be needed. And that's just one case. Kind regards, Wiktor [0]: https://wiki.gnupg.org/OpenPGPEmailSummit201607/EmailValidation [1]: https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-06#section-4.5 [2]: Actually I've been experimenting with URIs on User IDs with defined verification here: https://github.com/wiktor-k/distributed-ids This is another spin on Vincent's Linked Identities (but using User IDs and with declarative verification code). From nobody Wed Jun 27 03:07:24 2018 Return-Path: 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 40974130EF7 for ; Wed, 27 Jun 2018 03:07:22 -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 BvFF_JIpj1S1 for ; Wed, 27 Jun 2018 03:07:19 -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 6D78A1277CC for ; Wed, 27 Jun 2018 03:07:18 -0700 (PDT) Received: by smtp.gaspard.ninja (OpenSMTPD) with ESMTP id 0a3ac3e2 for ; Wed, 27 Jun 2018 10:07:15 +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=w3PaDvttOCz3aXOOg1+6gJSlEQA=; b=ErjFI2u/caDHMd iXtCjfv9oi8Fo6yRDm0/RlRlwW5rl9B0rSoPt7HmvPVpZrveWt8SRAne84ncKitl lmmKZAhlQ0TynZbCgkDZdi99h7qW7aPn6cOFeROYgQON74FA321xSy+24LYMejW1 lQ7f/yUg+kvMN/8mJZEhO+28UWs2w= Received: by smtp.gaspard.ninja (OpenSMTPD) with ESMTPSA id 9dd59664 (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128:NO) for ; Wed, 27 Jun 2018 10:07:15 +0000 (UTC) To: openpgp@ietf.org References: <39e598e1-2bc0-32c9-3489-4bb6ca2a631b@leo.gaspard.ninja> <871sdw24yd.wl-neal@walfield.org> <67153bb3-8ec7-5b30-3d11-22fce0681b47@metacode.biz> <2d737acb-0ce9-b703-ceb9-29c9a2ef2c0e@leo.gaspard.ninja> <6f540f57-637c-f94c-4001-96ea9d14007f@metacode.biz> From: Leo Gaspard Message-ID: Date: Wed, 27 Jun 2018 12:07:15 +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: <6f540f57-637c-f94c-4001-96ea9d14007f@metacode.biz> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 10:07:22 -0000 On 06/27/2018 10:07 AM, Wiktor Kwapisiewicz wrote: > Hi Leo, > > Okay, after your explanations and thinking about this through the night > I can see some benefits. Especially to the split of names (people > usually have only one name and it's usually verified using government > issued IDs) and e-mails (that can be automatically verified). > > There are projects [0] that want to verify e-mails and add signatures to > indicate "verified e-mail" but because e-mail and name are joined the > signature also covers the name (that wouldn't be necessary in your design). > > Sometimes the name in UID is not welcome (see "mailbox-only" in WKD [1]). Yes, that's exactly what I'm thinking of. > 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. > E-mail ID could be generalized to an URI ID (e.g. e-mail would be > "mailto:user@example.com"), then your "account-on" ID could also be a > URI (e.g. https://github.com/user, or XMPP account: > xmpp:user@example.com) [2]. Indeed that's possible too. I was more thinking that the XMPP account would be set as one of the “free form tag=value” (with `xmpp=user@example.com` for your example), but the two sound just as flexible to me, so no strong opinions here. Actually the “role” and “pseudonym” could also be of the “free form tag=value”, but I was thinking, when adding them specifically, that encouraging standardization to things that already appear “in the wild” would make sense. Without strong opinions either :) > But I think the most severe issue with your proposal is the ripple > effect it would have on the trust system. Currently one valid User ID is > necessary to mark the key as valid. And that valid User ID means both > the name and the e-mail (in most scenarios). But with split names and > e-mails a more elaborate design would be needed. And that's just one case. Indeed that is a big issue with implementation of this proposal. 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). 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. Cheers, Leo From nobody Wed Jun 27 05:05:52 2018 Return-Path: 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 E18BC1277C8 for ; Wed, 27 Jun 2018 05:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=metacode.biz 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 YxYpx8DyrDy9 for ; Wed, 27 Jun 2018 05:05:48 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::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 5436D127148 for ; Wed, 27 Jun 2018 05:05:48 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id n17-v6so4691263wmh.2 for ; Wed, 27 Jun 2018 05:05:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metacode.biz; s=2017; h=subject:to:references:from:openpgp:autocrypt:organization :message-id:date:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=PAAraCEihfgAatXmFOQr1/2hYZd3fNRLe7YW8ZczXdo=; b=Rno6KESkt7d+L16Qx/MvMEu3WUq0fRNMNznO84DPSmS81znWFRM7vbbIEpCGy7TaCY sBj5cdRLstsUo0m2hmZA8ENmPSteNE6GRJ0DEc802MENYl+aZODFfZ8M3NJZhtdUWBBt 5LdrcxMdksO6OWAKNbyB2tpTDyjiZe1+QlmnzZUnuOzVuPimIY9Z8o2MkY+dVCFf61wH 5YQUvb8KgGbpkVROQ1TKCgizO00YgEPmskrCxTs4bEE126WaIxDQ5mvmh27D2wLw5P4a 6Kq3LHe5WdpsGQjPupoZvOYjQ2AArEVC6iJa0V0SMghknjbMaAneAz8riod6rtekhGEP svGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt :organization:message-id:date:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=PAAraCEihfgAatXmFOQr1/2hYZd3fNRLe7YW8ZczXdo=; b=lyDgM2PibYSdZHte6MXBJHX5GJF+GnOTlHff5stnd3iNhD5IyRa3ETSUDDUBoW2XX/ x5QufriJhk+Rd9nznp+nJMbE9uganepHunFHEbQ7l+OkovV9t5XBvv16lzjARp6/yhPR CsEzB5uu+5FFi+0L5vJV/smmZGMao6OEcsvRj9prIBul2QoJS702c6qxvTv/w857/wlx 3/2TNpiC/KBHwXFWMcHtbzq6qYAXtge8bXfhDpsBppVpo9NyVLEpJU2kDheAF3OgMKoe FdmjgkC8hgyr/vYtjKsWIOeL6N4d7FXfEeHejCvSw7Wppnk213aurOrUAczt0Q7nCFmy 2fqQ== X-Gm-Message-State: APt69E0CTracBnE++HvfCuge4UzwH0eR0fVkLFmPhD2ZvJiiQSh+umX/ hbZFtXk0IfB2M13FV4EngMYHo/8jP7E= X-Google-Smtp-Source: AAOMgpc1JsLP01xXE5lmEky/SYK9Ld9VD7t9F98A+zJ3wZUHXu3NTSfCH+ql3L0n8AsmT4YFfUyN6Q== X-Received: by 2002:a1c:6f5a:: with SMTP id k87-v6mr4538775wmc.142.1530101146188; Wed, 27 Jun 2018 05:05:46 -0700 (PDT) Received: from ?IPv6:2a00:f41:386d:3f8f:3161:3c69:519:f582? ([2a00:f41:386d:3f8f:3161:3c69:519:f582]) by smtp.googlemail.com with ESMTPSA id h77-v6sm7216831wmd.9.2018.06.27.05.05.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Jun 2018 05:05:45 -0700 (PDT) To: openpgp@ietf.org References: <39e598e1-2bc0-32c9-3489-4bb6ca2a631b@leo.gaspard.ninja> <871sdw24yd.wl-neal@walfield.org> <67153bb3-8ec7-5b30-3d11-22fce0681b47@metacode.biz> <2d737acb-0ce9-b703-ceb9-29c9a2ef2c0e@leo.gaspard.ninja> <6f540f57-637c-f94c-4001-96ea9d14007f@metacode.biz> From: Wiktor Kwapisiewicz Openpgp: id=653909A2F0E37C106F5FAF546C8857E0D8E8F074; url=https://metacode.biz/@wiktor/openpgp/key Autocrypt: addr=wiktor@metacode.biz; keydata= xsFNBFhoYHoBEADzmg9UuwDrtvyejU01gDY1J1iJiCi4XGJ4lCfYeLC2jSagIxU/5Lu0lRft 0Loi2tsjpo0c8docP7HFxafEEvnnt/iabd6I536llMuw0uno4PgnD3ljcCMZLT+vn+amIDta lzVoMnSqzoNUotMNMtjIFuAaQ/wr4/Mp9CIgJdviGUc3PscqUiiUVVtk6uF0x657NULZgSIT /Mrqlr2i4RuyPwXe2Qt0uEA3KWWjF0l2NpAMVrqz+nHsLoNOaAsfdx94bzKQrrSeSQqEO2f+ /eO/hbUAFAmEhrotmUO8wJNygo8TgkdlzFI+UE4p8/KW0aCgGGgR8YkCvHq2OQhAAYFNJoNz Hqw0FGxdsY8qWFkYpoSB8zKspNy8KliofCamMYXoPF7eVIxIiKvxrAykGP4jNnzSoV0cn+bY fXnox1IhnqbnoJIT7kTmXv4JmWoYm8ThHqpEgcQOUUQzSRXb9OiNwiXT71ijeO1qswMRpsgk 6AGKSZGWxa3c4ive/p8z1Ax27BFZSh2FceIcMCcGLrDjnQYgeFsAJ1jSxZQXkGuJFHfb4nff Big7aq/vyKrQFQXG0NQQL7rZAdk/s665vifos0yPmRDu7yDT1ggdyBp4Pa4re+ZJcNRNzNHo zU9al+CoImCQjnTtKMXmOe/BzGrpHI4QR3NNzVa423WCIWkHfwARAQABzSlXaWt0b3IgS3dh cGlzaWV3aWN6IDx3aWt0b3JAbWV0YWNvZGUuYml6PsLB7gQTAQoAmAIbAQgLCQgHDQwLCgUV CgkICwIeAQIXgHMUgAAAAAAqAEB0aW1lc3RhbXArYml0Y29pbi10cmFuc2FjdGlvbkBtZXRh Y29kZS5iaXphZmNiMDkyYzVjYTY0MDk1MjZkMThhZTljZjIyZDNiNTVkMzdlNzIzZWIxYjc0 ZTNmODRmN2U2YjA1MmExNjJhBQJaLoPdBQkDwPuGAAoJEGyIV+DY6PB0CNkQAKGTFHzG4YO6 yne5jfMlGcF8JUYq0EGHE9DRK6oAyGo+1TGFbf1bS4wULvA6LFBOLd+aI7uuN062kDdtHVUf 0S0AZ9ByjIBdQJsqx47W6uXsRX/pB0a70QqS6NbS3AL/fdwZOj/TBk8bdsfg7Z+hH+ykMcOs EYLmdMLmrqYgl9EyP4FmsnU9H8x4yKp0/Kv4BQYfjn68CFvyM2NQU3MR/H3sqvM/uY5AJwTp A8X1ZbN8pjZO5YRTiQtMrXekNzhP3p0ep1+cu2UxQO6jXV6Sjdm8D8RJzGaxCuhN/VhLNSvh cb2T5sejBAhU8JmKNle4+z5wZWB4bl5Dfkg1NpSEEdv7so+KXCnszo89UJJijlfgBFtm5WjK u7gCR8CVOeGQwQolEzi18zihCwRy1rg/xKokk7q6ZBEvxM1sBYNd81mi1PgrNwgH4jPULfQk UJtU7HLRVNLbnrIyEQbLOJegBLaWHgR4T69blBGg1oqiq/1PHnZuJauZhhNEAViX42VKJP1z w6PIfvbjg27wf4OjEDtVVXCrxqqljHRilagFQHGlU+iF6Ii2C3pNod11+lqJC0riFylxK/wu zHpoZdFg10gqMWIE2Exm7nJ6ToKv5kZqKC97mWrmh6FFEr6HmjDDuo+N4RER3VGj0dSey5nc eFQ2vry17IGN1ljV9TiARDgizsFNBFhoYf0BEACidQ4OVAKliYOnNzG5ltod8GS0eJj3CSnY 0gszCjS6Hm0OkvCN5RfEagALuLuJe06nFDB/mEvsV3CKO1rxPUrQnijxjl/L5LopdEVhwQoL UBhvMvdX62krk6CtsFUlQvHPS923+YoQ1/HWR8jbWLJq/PNJp3fE9FKbWX6BchOeZ/KCZ/Ip 6vv7YOVVyBVL8O/slSkEEaUS40ac/F70/wfUPXRgiOLYVikRNlphvmTu54F0KWFUbPYAhyr/ xSz8Joy34+e9h5ipEb+Cv9CrjQaHp8aLDAR1VJ3A+SjSt20mU1CuhKwpR+z0t/hjlOLHv0zR qWl3QNYmNBJ9I2oW4mH9FEDM3DRsWEaqdaL1uVeQ8rE4QZ6tbk76YS8eyRWjScLQm61USHxq 7KpUI73k6ST0Ylyj8D1a03dKUTuytgU0NhbFyArI2UHNvhm73X6qo7ofHlfgA6mVAaI4jW7r /CY0GLs29PyetdII/+6F50HAEXBswTesgx/2P6k+vHhReyZF7NgSkqEWaGgKdRlSyTpu/U+Q TRmLB/yWfL89+BMJZosX0oMWZxG7XPu18GXSeHNoSPw9xLNGWGMbKErIbyVqQyd6fu2gpYzO n9J57ImHvgoENvcyRl7sSOiZto/5EJiHubUBTeeuZf2V7QxfrP15h1SVkzDjIOP3qXF+oCI8 jQARAQABwsFlBBgBCgAPBQJYaGH9AhsMBQkB4TOAAAoJEGyIV+DY6PB0I94P/iFsWZcgYNaN JxXK99755nzKKDSqjCOkTgoV9h9cNaIZV944pupdugRW5ek6BV2/Cj93iCGMzrfzzvETPT4t 8oaC/0yJ0pzPUrFe9Uht2ghtmXQK6Mw0fM4daPKJtCQyMlfYljqKhxgIJ24cB+O04yOrvfCS FRQw/T4ngmqCvI1wRzxU98yljKKxcvQWZ6qY6izNeUZJ6Ie1iujQOEmnLSXMikcptGf5YC9C KY0f9MsCI75uCx2HKQRRcj/nOHE+dkwo5XyUbSuWhQu6bOHJI5S0ixkjVp6JQ4E1NBLR3P3V Kr1jg6ODbJ0w9B8peSumzFhGf0qo2RYkPYKkUFfejmUhphSAS2WmdGHbut32ibDn6vd/XTjs vGQUDQ2Bp3fXdqeTw79T5zGpS87omdnz/Wpavntjv9IbVTnCmJMfSBYUmMoBK94IEWttKmL/ UCmcoruhhLs1A3Xdn17gt6k+AkBapBd8IC15QiMedzCINtug399M9MMfgkW5NpGOunpLBbhG xUD2nqdK2j347/dGTT53sUa6tQw6IDNZrCWOJTqTeP6PD7BJt67tlywPgmLSBGYgWpnRNJhb 9QKzyn3KnUzp9lzUDLReEu2gdY2Kz1N5PVmmF/ysfKVJZ0ZGWPB4iR/HgAc6OY2TnHXiifKT EXmAO6RvoR7+8se4PUnv0mR1wsFlBBgBCgAPAhsMBQJaLoRUBQkDwPoDAAoJEGyIV+DY6PB0 XoMP/i+6XvyNE/XsdFgeAO/rtdELWphFUu1HbaKYeh6YMYjg71eR8KbYe2sz3M1Bawj/D7Kb tGRsxFshkLHau0N0cJHEr3U6j/U7sEWCW/YDlWSIyBWYg+j1k/aBczfL/oC9E9h8LOUUjjj3 vpRs2rHmIHT2aAvbRom1d4xaFh1kwn7sUKtc+0AoP5PCeBcfqMduunEPqsfsbmz1Dz+O5FJ7 LRG8YXyV+5YTT1pEuNjFm+GNBEvwhfJqN+H459ngMdZUkCyKwWLAMaJj6y9/ZJ8lrPLCjGDR p9FzhLg39gQqV5Vu41VyBr+9YucX/sWfQ1SuvWDMBnTKSOKX01RAHGvnOmtl3Vr4SqWDhFsO VdWluKugMiIdajKwgM9Bp+35O/l8QQbxxrRAy/TI+dB4w8Urn2oVPkAq8RgYJIzpYYUFnhKD EwcdoG8Lk2EqO60g9UR6tGVsW9/vYvVGHlm0kArIDF9o0zAo5wsuZE9kO4oneoIsCRLwjuZk bqQ+2V+8R3P5YkV8VogwwYPCAhkpGD/ACblux5ip1ilLWFm75Hj3aPkvJSWi5DfkoxzntZBM KrhpyhCKJFUPZovREteTzl8ns3/KvoUJ5VQF3HqXKw49sWrWSDHEugt9ERfCBzAuYl4WB7Qt xwe2q0voV3BFy8kd04NRiyJkBU0BeBHEHblrGY23 Organization: Metacode Message-ID: <16e7c274-80d2-e35b-2d3a-a70bf39ebddc@metacode.biz> Date: Wed, 27 Jun 2018 14:05:41 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 12:05:51 -0000 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 From nobody Wed Jun 27 06:56:20 2018 Return-Path: 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 ; 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 ; 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 ; Wed, 27 Jun 2018 06:56:15 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id r24-v6so1974461ioh.9 for ; 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> <67153bb3-8ec7-5b30-3d11-22fce0681b47@metacode.biz> <2d737acb-0ce9-b703-ceb9-29c9a2ef2c0e@leo.gaspard.ninja> <6f540f57-637c-f94c-4001-96ea9d14007f@metacode.biz> <16e7c274-80d2-e35b-2d3a-a70bf39ebddc@metacode.biz> In-Reply-To: <16e7c274-80d2-e35b-2d3a-a70bf39ebddc@metacode.biz> From: Wyllys Ingersoll Date: Wed, 27 Jun 2018 09:56:02 -0400 Message-ID: To: wiktor=40metacode.biz@dmarc.ietf.org Cc: openpgp@ietf.org Content-Type: multipart/alternative; boundary="0000000000005fa069056f9ffa3e" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 13:56:19 -0000 --0000000000005fa069056f9ffa3e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 wrote: > Hi Leo, > > >> But I'm not in favor of other attributes: > >> - "role" (e.g. "Qubes OS developer"), who would verify that? Probab= ly > >> 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 t= o > > have a place to put the information they currently appear to want to pu= t > > 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-ha= rmful.html > ). > > > I'd think the concept of saying =E2=80=9Ca key is valid=E2=80=9D is lik= ely a problem > > anyway, as a key is always valid, and the only thing that can be checke= d > > is the validity of the association between a User ID and a key (for the > > WoT, there is no need to have a key =E2=80=9Cvalid=E2=80=9D for trustin= g 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-co= mmunication > ). > > > So this would require quite some changes especially around the user > > interface, that couldn't just display a valid User ID as =E2=80=9Ckey h= andle=E2=80=9D as > > is currently done by at least GnuPG and Enigmail, but would also have t= o > > 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 > --0000000000005fa069056f9ffa3e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The problem I see with all of these suggestions is that th= ere is no way to actually "verify" the data that someone puts int= o these fields without some sort of standardized and trusted verification s= ervice, which is way out of scope for the OpenPGP spec. Also, adding many m= ore user attributes *will* complicate UIs beyond gnupg and enigmail. Consid= er 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 comple= x forms that are not well understood by the average user.=C2=A0 The whole &= quot;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 t= o assign to a key (or userids associated with the key), many users ignore i= t entirely and happily use the key and assume the UID is correct.=C2=A0 Why= would this be any better?

Im not convinced that the pro= posal 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 founda= tion for building a better trust/verification system.

<= div>-Wyllys Ingersoll




=

On Wed, J= un 27, 2018 at 8:06 AM Wiktor Kwapisiewicz <wiktor=3D40metacode.biz@dmarc.ietf.org> wrote:<= br>
Hi Leo,

>> But I'm not in favor of other attributes:
>>=C2=A0 =C2=A0 - "role" (e.g. "Qubes OS developer&quo= t;), 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
>> use= r@developers.qubes.com better express that? (for the record I also
>> don't like "project X signing key" comments but that= 's another story),
>>=C2=A0 =C2=A0 - "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 p= ut
> 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.fifth= horseman.net/blog/openpgp-user-id-comments-considered-harmful.html
).

> I'd think the concept of saying =E2=80=9Ca key is valid=E2=80=9D i= s likely a problem
> anyway, as a key is always valid, and the only thing that can be check= ed
> is the validity of the association between a User ID and a key (for th= e
> WoT, there is no need to have a key =E2=80=9Cvalid=E2=80=9D for trusti= ng 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.linu= x.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 =E2=80=9C= key handle=E2=80=9D 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<= br> https://www.ietf.org/mailman/listinfo/openpgp
--0000000000005fa069056f9ffa3e-- From nobody Wed Jun 27 07:42:05 2018 Return-Path: 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 AB269130E13 for ; Wed, 27 Jun 2018 07:42:03 -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 t98gAuO2TmQK for ; Wed, 27 Jun 2018 07:42:01 -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 85FAE130DDD for ; Wed, 27 Jun 2018 07:42:00 -0700 (PDT) Received: by smtp.gaspard.ninja (OpenSMTPD) with ESMTP id 3beb2c73 for ; Wed, 27 Jun 2018 14:41:56 +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=4wCnVozkrFcZIYz9mYIPmNl35oM=; b=0rUFkaOPqtRhgj sTlufL7c4joot1nuqHqvLqa8WPp41gTQ/e9816BtaNq6/QyiVMDGCApRHUS/cm3B f1HUdQDx8qMMDl1njDAF16WcuSvzACRzAd2BBh6byib/RKGt00mS86kO6yW79FGR LE/DGP3MtmLaj1xVU6CFAW7sdJZeI= Received: by smtp.gaspard.ninja (OpenSMTPD) with ESMTPSA id 08f0bcde (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128:NO) for ; Wed, 27 Jun 2018 14:41:56 +0000 (UTC) To: openpgp@ietf.org References: <39e598e1-2bc0-32c9-3489-4bb6ca2a631b@leo.gaspard.ninja> <871sdw24yd.wl-neal@walfield.org> <67153bb3-8ec7-5b30-3d11-22fce0681b47@metacode.biz> <2d737acb-0ce9-b703-ceb9-29c9a2ef2c0e@leo.gaspard.ninja> <6f540f57-637c-f94c-4001-96ea9d14007f@metacode.biz> <16e7c274-80d2-e35b-2d3a-a70bf39ebddc@metacode.biz> From: Leo Gaspard Message-ID: <48725c27-b11b-84b5-a3f2-b94e2c502aa3@leo.gaspard.ninja> Date: Wed, 27 Jun 2018 16:41:56 +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: <16e7c274-80d2-e35b-2d3a-a70bf39ebddc@metacode.biz> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 14:42:04 -0000 On 06/27/2018 02:05 PM, Wiktor Kwapisiewicz 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 > ). Well, setting up proper user interfaces for this will likely end up with two types of User IDs, the “name” one, and the “email” one, which would be distinguished by putting brackets around the “email” User ID. Which does the same thing as this proposal to split the User ID into User Attributes. But the issue is that then, tools will not be able to assume that all User IDs conform to this “de facto standardization,” because some tools likely won't follow this convention, and will still put User IDs of the “Name ” format. And this then increases the complexity of user interfaces, that have to handle both cases. >> 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 > ). Well, yes, and I claim this strict technical term designates something that has no sensible meaning. If I remember correctly, GnuPG uses it to show whether at least one User ID has been signed by a key that is trusted. The validity should instead apply to the (key, User ID) couple, and then it does make sense. Actually, 4880bis§5.2.1 already defines type 0x10 (which is IIRC the most used type for certification signatures) as “Generic certification of a User ID and Public-Key packet,” which isn't “Generic certification of a Public-Key packet.” >> 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. Well, my hope in pushing this for v5 is that a lot of tools will already have to be changed along the path, so I was hoping this would be only an additional change that wouldn't be delayed as much :) From nobody Wed Jun 27 07:56:48 2018 Return-Path: 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 3273E130DE9 for ; Wed, 27 Jun 2018 07:56:46 -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 rAj7mThnCNBH for ; Wed, 27 Jun 2018 07:56:43 -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 42956130DE8 for ; Wed, 27 Jun 2018 07:56:42 -0700 (PDT) Received: by smtp.gaspard.ninja (OpenSMTPD) with ESMTP id dd181a0f for ; Wed, 27 Jun 2018 14:56:39 +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=roTotZ5UQiXZ41Idm6iyV5YLApg=; b=GMt3omGAbyVvI9 w2xE26Omj8mIr33d00T+EHnx9lewb8kH0W65OEcFKXXi6j+SFF0rz0yTTwn4X3On eiJTsqpXHHbK5eYBiUmTElSXwU7us80rfsxCKjjLqVahIKlh60xh5lzQb8W5R50J nROM3TVec/hoZ0f0KL95yWbB1V7eE= Received: by smtp.gaspard.ninja (OpenSMTPD) with ESMTPSA id 99efb2cc (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128:NO) for ; Wed, 27 Jun 2018 14:56:39 +0000 (UTC) To: openpgp@ietf.org References: <39e598e1-2bc0-32c9-3489-4bb6ca2a631b@leo.gaspard.ninja> <871sdw24yd.wl-neal@walfield.org> <67153bb3-8ec7-5b30-3d11-22fce0681b47@metacode.biz> <2d737acb-0ce9-b703-ceb9-29c9a2ef2c0e@leo.gaspard.ninja> <6f540f57-637c-f94c-4001-96ea9d14007f@metacode.biz> <16e7c274-80d2-e35b-2d3a-a70bf39ebddc@metacode.biz> From: Leo Gaspard Message-ID: <60e169b8-7f49-d453-56db-c4220a38cfc2@leo.gaspard.ninja> Date: Wed, 27 Jun 2018 16:56:39 +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: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 14:56:47 -0000 On 06/27/2018 03:56 PM, Wyllys Ingersoll wrote: > 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. Well, verifying the data that someone puts into these fields is out of the scope of the OpenPGP spec just as much as verifying the data that people put into User ID fields is out of scope of the OpenPGP spec. The difference is that currently the spec is actively hostile to any kind of eg. automated verification of email addresses, by coupling names with email addresses :) > 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. Indeed it will complicate the code of UIs. But I'm not sure it wouldn't lead to more usability and security in the end, just because UIs could still display data “the old way” if they want, but they could also display a well-thought subset of the information, eg. displaying only the name if it's validated, or only the email if the email is validated, thus even winning screen estate. About “complex forms”, if I compare: Name: [ ]  Email: [ ] [+] With: User ID: [ type in your User ID in Name format ] [+] Then I know I find the first much easier :) And actually it even wins screen horizontal real estate, which is quite a bit more precious than screen vertical real estate on mobile devices. > 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? Well, if users just assume the User ID is correct, then splitting the User ID into User Attributes isn't going to help them (but won't make them worse off). However, for people who actually check things before they sign keys and verify validity of the keys, then the change would make signature much easier, and thus would increase the likelihood of having a validated key for a random email address they'd want to speak to. (note: I've answered this part of your message by assuming by “trust level” you meant “validity”, if that wasn't what you meant then I'm sorry I misunderstood) > 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. Well, for direct users, it should change relatively little, apart from at signature time, where “to be signed” elements would be presented by User Attribute and not by User ID. It could change a bit in interfaces, where an example UI would be to only display validated User Attributes that match the From: header, for instance, for emails. It could also help projects, where, if I'm a project and I sign the key of a contributor, I want to sign their key as “yes this is a member of the project”, not to sign their identity, because I maybe haven't checked the real-world identity of the developer I'm giving commit rights, and only looked at the key's history of making good commits. All this could help particularly in relation to scoped trust, allowing to trust certain keys only for signatures on certain User Attributes, eg. allowing a GitHub official key to sign all “free form tag=value” User Attributes for which “tag” is “github”. Which would be next to impossible to do without at least a minimal amount of standardization in User Attributes, as is currently the case with everyone misusing User IDs everyone with their custom scheme for this purpose :) From nobody Wed Jun 27 12:28:05 2018 Return-Path: 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 932C0130E9C for ; Wed, 27 Jun 2018 12:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=metacode.biz 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 hNrELKlq3kL3 for ; Wed, 27 Jun 2018 12:28:00 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 8AB5C1292F1 for ; Wed, 27 Jun 2018 12:28:00 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id v16-v6so7063328wmv.5 for ; Wed, 27 Jun 2018 12:28:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metacode.biz; s=2017; h=subject:to:references:from:openpgp:autocrypt:organization :message-id:date:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=dtrWPWQaiscVPlV7/nj6i/XS1xgI+iVE+QJ+Smcq5Vo=; b=rXEc+Qzs6tZ7tuNMbMXRIK9lWlpNOdRHQpXbz0i9lCHlDO0egVRyhgRP5NhVLB7Fdy 94Q3CqzZmKhklfd7clRnXeuWog8KyDkNKYO7OFTsUKq44wfoPAw1Z209NyB1PMmfpDPV Fu3p8hCM4+v0xXSzgifztDUc6hnefAfjRpFDvv68U3tULWRirQPxIAj4WdlXbZf9MfM3 Fv/GmIAcQM2dOkL9peyWdDs6t7k5w9a0pDSTMmFkjI9lst+49eWFlhDAX+VCZQRbOqPT 2A6hpM/SIsyuMEkfW3cb0RKL/QsZhWh3PU4q9SAG86WYVZ9Pb5w1qUZ1WWUAef9mNZSa FXpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt :organization:message-id:date:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=dtrWPWQaiscVPlV7/nj6i/XS1xgI+iVE+QJ+Smcq5Vo=; b=nU15qrPUbkLn91uSUz9XxSupMnkm39gGC1vP1vs22ILdnZMrWjY5Q+OxcYDPHUekG6 7n+Tld6NZa7b/W2gpuxl4I3Q94i7gUxEM7L6SrPGZRFGHbOB8wXMWEFXqJP7YAcXRScK 3UDq7JmK9CR1385K2SI1O+XbkHZatWcMaXdklDbSd05VDEt2478FKYuI1k6YdJqp16iV 8dVZXrLbaaI/Wn8MRfzNaOzprOV4xhZW+6Zq7yxYjueLBCYAsFVwzEkX+f8LaBqtj8kZ L24P7s7wgHvx5ENM8ubZkm+l5GHRYHdp2MAG6mXttGohMepEoGSCghtYds2YdPOacLJq x/aQ== X-Gm-Message-State: APt69E0ymMgFxSpwTfV9OhRBv5Ichxpdff3lGR+GPWpCLdUvelKaHW8c SKt1EwWQcif2K5D940EWD5cp9mc6kGg= X-Google-Smtp-Source: AAOMgpehzZmVnczdy4OslrxQLqUvZbe2Yvsd+Gf6Y6ysdFpAiAf6dYmwoxvuRagUg9+9wUDe1ekSoA== X-Received: by 2002:a1c:78b:: with SMTP id 133-v6mr6291487wmh.59.1530127678030; Wed, 27 Jun 2018 12:27:58 -0700 (PDT) Received: from ?IPv6:2a00:f41:386d:3f8f:49d4:8069:d0e0:4bcd? ([2a00:f41:386d:3f8f:49d4:8069:d0e0:4bcd]) by smtp.googlemail.com with ESMTPSA id q17-v6sm4567742wro.30.2018.06.27.12.27.55 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Jun 2018 12:27:56 -0700 (PDT) To: openpgp@ietf.org References: <39e598e1-2bc0-32c9-3489-4bb6ca2a631b@leo.gaspard.ninja> <871sdw24yd.wl-neal@walfield.org> <67153bb3-8ec7-5b30-3d11-22fce0681b47@metacode.biz> <2d737acb-0ce9-b703-ceb9-29c9a2ef2c0e@leo.gaspard.ninja> <6f540f57-637c-f94c-4001-96ea9d14007f@metacode.biz> <16e7c274-80d2-e35b-2d3a-a70bf39ebddc@metacode.biz> <48725c27-b11b-84b5-a3f2-b94e2c502aa3@leo.gaspard.ninja> From: Wiktor Kwapisiewicz Openpgp: id=653909A2F0E37C106F5FAF546C8857E0D8E8F074; url=https://metacode.biz/@wiktor/openpgp/key Autocrypt: addr=wiktor@metacode.biz; keydata= xsFNBFhoYHoBEADzmg9UuwDrtvyejU01gDY1J1iJiCi4XGJ4lCfYeLC2jSagIxU/5Lu0lRft 0Loi2tsjpo0c8docP7HFxafEEvnnt/iabd6I536llMuw0uno4PgnD3ljcCMZLT+vn+amIDta lzVoMnSqzoNUotMNMtjIFuAaQ/wr4/Mp9CIgJdviGUc3PscqUiiUVVtk6uF0x657NULZgSIT /Mrqlr2i4RuyPwXe2Qt0uEA3KWWjF0l2NpAMVrqz+nHsLoNOaAsfdx94bzKQrrSeSQqEO2f+ /eO/hbUAFAmEhrotmUO8wJNygo8TgkdlzFI+UE4p8/KW0aCgGGgR8YkCvHq2OQhAAYFNJoNz Hqw0FGxdsY8qWFkYpoSB8zKspNy8KliofCamMYXoPF7eVIxIiKvxrAykGP4jNnzSoV0cn+bY fXnox1IhnqbnoJIT7kTmXv4JmWoYm8ThHqpEgcQOUUQzSRXb9OiNwiXT71ijeO1qswMRpsgk 6AGKSZGWxa3c4ive/p8z1Ax27BFZSh2FceIcMCcGLrDjnQYgeFsAJ1jSxZQXkGuJFHfb4nff Big7aq/vyKrQFQXG0NQQL7rZAdk/s665vifos0yPmRDu7yDT1ggdyBp4Pa4re+ZJcNRNzNHo zU9al+CoImCQjnTtKMXmOe/BzGrpHI4QR3NNzVa423WCIWkHfwARAQABzSlXaWt0b3IgS3dh cGlzaWV3aWN6IDx3aWt0b3JAbWV0YWNvZGUuYml6PsLB7gQTAQoAmAIbAQgLCQgHDQwLCgUV CgkICwIeAQIXgHMUgAAAAAAqAEB0aW1lc3RhbXArYml0Y29pbi10cmFuc2FjdGlvbkBtZXRh Y29kZS5iaXphZmNiMDkyYzVjYTY0MDk1MjZkMThhZTljZjIyZDNiNTVkMzdlNzIzZWIxYjc0 ZTNmODRmN2U2YjA1MmExNjJhBQJaLoPdBQkDwPuGAAoJEGyIV+DY6PB0CNkQAKGTFHzG4YO6 yne5jfMlGcF8JUYq0EGHE9DRK6oAyGo+1TGFbf1bS4wULvA6LFBOLd+aI7uuN062kDdtHVUf 0S0AZ9ByjIBdQJsqx47W6uXsRX/pB0a70QqS6NbS3AL/fdwZOj/TBk8bdsfg7Z+hH+ykMcOs EYLmdMLmrqYgl9EyP4FmsnU9H8x4yKp0/Kv4BQYfjn68CFvyM2NQU3MR/H3sqvM/uY5AJwTp A8X1ZbN8pjZO5YRTiQtMrXekNzhP3p0ep1+cu2UxQO6jXV6Sjdm8D8RJzGaxCuhN/VhLNSvh cb2T5sejBAhU8JmKNle4+z5wZWB4bl5Dfkg1NpSEEdv7so+KXCnszo89UJJijlfgBFtm5WjK u7gCR8CVOeGQwQolEzi18zihCwRy1rg/xKokk7q6ZBEvxM1sBYNd81mi1PgrNwgH4jPULfQk UJtU7HLRVNLbnrIyEQbLOJegBLaWHgR4T69blBGg1oqiq/1PHnZuJauZhhNEAViX42VKJP1z w6PIfvbjg27wf4OjEDtVVXCrxqqljHRilagFQHGlU+iF6Ii2C3pNod11+lqJC0riFylxK/wu zHpoZdFg10gqMWIE2Exm7nJ6ToKv5kZqKC97mWrmh6FFEr6HmjDDuo+N4RER3VGj0dSey5nc eFQ2vry17IGN1ljV9TiARDgizsFNBFhoYf0BEACidQ4OVAKliYOnNzG5ltod8GS0eJj3CSnY 0gszCjS6Hm0OkvCN5RfEagALuLuJe06nFDB/mEvsV3CKO1rxPUrQnijxjl/L5LopdEVhwQoL UBhvMvdX62krk6CtsFUlQvHPS923+YoQ1/HWR8jbWLJq/PNJp3fE9FKbWX6BchOeZ/KCZ/Ip 6vv7YOVVyBVL8O/slSkEEaUS40ac/F70/wfUPXRgiOLYVikRNlphvmTu54F0KWFUbPYAhyr/ xSz8Joy34+e9h5ipEb+Cv9CrjQaHp8aLDAR1VJ3A+SjSt20mU1CuhKwpR+z0t/hjlOLHv0zR qWl3QNYmNBJ9I2oW4mH9FEDM3DRsWEaqdaL1uVeQ8rE4QZ6tbk76YS8eyRWjScLQm61USHxq 7KpUI73k6ST0Ylyj8D1a03dKUTuytgU0NhbFyArI2UHNvhm73X6qo7ofHlfgA6mVAaI4jW7r /CY0GLs29PyetdII/+6F50HAEXBswTesgx/2P6k+vHhReyZF7NgSkqEWaGgKdRlSyTpu/U+Q TRmLB/yWfL89+BMJZosX0oMWZxG7XPu18GXSeHNoSPw9xLNGWGMbKErIbyVqQyd6fu2gpYzO n9J57ImHvgoENvcyRl7sSOiZto/5EJiHubUBTeeuZf2V7QxfrP15h1SVkzDjIOP3qXF+oCI8 jQARAQABwsFlBBgBCgAPBQJYaGH9AhsMBQkB4TOAAAoJEGyIV+DY6PB0I94P/iFsWZcgYNaN JxXK99755nzKKDSqjCOkTgoV9h9cNaIZV944pupdugRW5ek6BV2/Cj93iCGMzrfzzvETPT4t 8oaC/0yJ0pzPUrFe9Uht2ghtmXQK6Mw0fM4daPKJtCQyMlfYljqKhxgIJ24cB+O04yOrvfCS FRQw/T4ngmqCvI1wRzxU98yljKKxcvQWZ6qY6izNeUZJ6Ie1iujQOEmnLSXMikcptGf5YC9C KY0f9MsCI75uCx2HKQRRcj/nOHE+dkwo5XyUbSuWhQu6bOHJI5S0ixkjVp6JQ4E1NBLR3P3V Kr1jg6ODbJ0w9B8peSumzFhGf0qo2RYkPYKkUFfejmUhphSAS2WmdGHbut32ibDn6vd/XTjs vGQUDQ2Bp3fXdqeTw79T5zGpS87omdnz/Wpavntjv9IbVTnCmJMfSBYUmMoBK94IEWttKmL/ UCmcoruhhLs1A3Xdn17gt6k+AkBapBd8IC15QiMedzCINtug399M9MMfgkW5NpGOunpLBbhG xUD2nqdK2j347/dGTT53sUa6tQw6IDNZrCWOJTqTeP6PD7BJt67tlywPgmLSBGYgWpnRNJhb 9QKzyn3KnUzp9lzUDLReEu2gdY2Kz1N5PVmmF/ysfKVJZ0ZGWPB4iR/HgAc6OY2TnHXiifKT EXmAO6RvoR7+8se4PUnv0mR1wsFlBBgBCgAPAhsMBQJaLoRUBQkDwPoDAAoJEGyIV+DY6PB0 XoMP/i+6XvyNE/XsdFgeAO/rtdELWphFUu1HbaKYeh6YMYjg71eR8KbYe2sz3M1Bawj/D7Kb tGRsxFshkLHau0N0cJHEr3U6j/U7sEWCW/YDlWSIyBWYg+j1k/aBczfL/oC9E9h8LOUUjjj3 vpRs2rHmIHT2aAvbRom1d4xaFh1kwn7sUKtc+0AoP5PCeBcfqMduunEPqsfsbmz1Dz+O5FJ7 LRG8YXyV+5YTT1pEuNjFm+GNBEvwhfJqN+H459ngMdZUkCyKwWLAMaJj6y9/ZJ8lrPLCjGDR p9FzhLg39gQqV5Vu41VyBr+9YucX/sWfQ1SuvWDMBnTKSOKX01RAHGvnOmtl3Vr4SqWDhFsO VdWluKugMiIdajKwgM9Bp+35O/l8QQbxxrRAy/TI+dB4w8Urn2oVPkAq8RgYJIzpYYUFnhKD EwcdoG8Lk2EqO60g9UR6tGVsW9/vYvVGHlm0kArIDF9o0zAo5wsuZE9kO4oneoIsCRLwjuZk bqQ+2V+8R3P5YkV8VogwwYPCAhkpGD/ACblux5ip1ilLWFm75Hj3aPkvJSWi5DfkoxzntZBM KrhpyhCKJFUPZovREteTzl8ns3/KvoUJ5VQF3HqXKw49sWrWSDHEugt9ERfCBzAuYl4WB7Qt xwe2q0voV3BFy8kd04NRiyJkBU0BeBHEHblrGY23 Organization: Metacode Message-ID: Date: Wed, 27 Jun 2018 21:27:53 +0200 MIME-Version: 1.0 In-Reply-To: <48725c27-b11b-84b5-a3f2-b94e2c502aa3@leo.gaspard.ninja> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 19:28:04 -0000 Hello, > Well, yes, and I claim this strict technical term designates something > that has no sensible meaning. If I remember correctly, GnuPG uses it to > show whether at least one User ID has been signed by a key that is > trusted. The validity should instead apply to the (key, User ID) couple, > and then it does make sense. > > Actually, 4880bis§5.2.1 already defines type 0x10 (which is IIRC the > most used type for certification signatures) as “Generic certification > of a User ID and Public-Key packet,” which isn't “Generic certification > of a Public-Key packet.” Yes, person X certifies User ID Y of key Z. Y and Z are part of the signature (signed User ID + Key ID [0]) but the other party - the person X (issuer) puts only their key ID as a part of the signature, not their User ID [1]. Thus you still need validity per key to know if you can trust Person X's certifications. [2] [0]: This is described here: https://tools.ietf.org/html/rfc4880#section-5.2.4 [1]: There is Signer's User ID subpacket but it's rarely used and not used for key certifications as far as I know. [2]: Personally, having issuer's User ID be part of trust calculations seems to be overly complex, what difference does it make if it's the same person signing the key? >> 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. > > Well, my hope in pushing this for v5 is that a lot of tools will already > have to be changed along the path, so I was hoping this would be only an > additional change that wouldn't be delayed as much :) Well, this is the most complex change suggested that I've seen here, everything else is mostly backwards compatible (note that there is not much traffic here ;) ). > All this could help particularly in relation to scoped trust, allowing > to trust certain keys only for signatures on certain User Attributes, > eg. allowing a GitHub official key to sign all “free form tag=value” > User Attributes for which “tag” is “github”. Which would be next to > impossible to do without at least a minimal amount of standardization in > User Attributes, as is currently the case with everyone misusing User > IDs everyone with their custom scheme for this purpose This is already possible with trust signatures with domain restriction. If GitHub had their key (and that's a big if) and signed their user's IDs that have e-mails in form *@users.noreply.github.com with trust sig level 1 then you could trust sign GitHub's key with trust signature level 2 limiting that to the users.noreply.github.com domain. The same approach with trust signatures could be used by organizations and their "role" system. This article goes into more detail: https://www.linuxfoundation.org/blog/pgp-web-of-trust-delegated-trust-and-keyservers/ I think that's all from me now, take care! Kind regards, Wiktor From nobody Wed Jun 27 16:38:14 2018 Return-Path: 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 0F7CE130E40 for ; Wed, 27 Jun 2018 16:38:13 -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 QMFOjcYShIaM for ; Wed, 27 Jun 2018 16:38:09 -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 454DB130E3F for ; Wed, 27 Jun 2018 16:38:08 -0700 (PDT) Received: by smtp.gaspard.ninja (OpenSMTPD) with ESMTP id f0d49a3f for ; Wed, 27 Jun 2018 23:38:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=leo.gaspard.ninja; h=from:subject:to:references:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s= grym-20170528; bh=nPl9a4jjzBbkOTQ5tmPeGs48eI0=; b=N0PPs1/Rx1e8Zz wiD1mIq4xF9yMZ5ZfU0tkR+nd2aXrXu6nbaKo+LX5gIR21TJ3b1bnp0Ua3tShGtp 59qZQNnUD3oacKJryCpmDTjn4q6FYn9h/JgXBqDbgCPzr5r2wO14R9cMRI4L2X5D 7Z92vD+Q9rcw58GVs3M5FJ+RBFF4U= Received: by smtp.gaspard.ninja (OpenSMTPD) with ESMTPSA id e64a64ec (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128:NO) for ; Wed, 27 Jun 2018 23:38:05 +0000 (UTC) From: Leo Gaspard To: openpgp@ietf.org References: <39e598e1-2bc0-32c9-3489-4bb6ca2a631b@leo.gaspard.ninja> <871sdw24yd.wl-neal@walfield.org> <67153bb3-8ec7-5b30-3d11-22fce0681b47@metacode.biz> <2d737acb-0ce9-b703-ceb9-29c9a2ef2c0e@leo.gaspard.ninja> <6f540f57-637c-f94c-4001-96ea9d14007f@metacode.biz> <16e7c274-80d2-e35b-2d3a-a70bf39ebddc@metacode.biz> <48725c27-b11b-84b5-a3f2-b94e2c502aa3@leo.gaspard.ninja> Message-ID: <02d1de9c-1494-d217-fbe9-a5ba116f69d5@leo.gaspard.ninja> Date: Thu, 28 Jun 2018 01:37:58 +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: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 23:38:13 -0000 On 06/27/2018 09:27 PM, Wiktor Kwapisiewicz wrote: > Hello, > >> Well, yes, and I claim this strict technical term designates something >> that has no sensible meaning. If I remember correctly, GnuPG uses it to >> show whether at least one User ID has been signed by a key that is >> trusted. The validity should instead apply to the (key, User ID) couple, >> and then it does make sense. >> >> Actually, 4880bis§5.2.1 already defines type 0x10 (which is IIRC the >> most used type for certification signatures) as “Generic certification >> of a User ID and Public-Key packet,” which isn't “Generic certification >> of a Public-Key packet.” > > Yes, person X certifies User ID Y of key Z. Y and Z are part of the > signature (signed User ID + Key ID [0]) but the other party - the person > X (issuer) puts only their key ID as a part of the signature, not their > User ID [1]. Thus you still need validity per key to know if you can > trust Person X's certifications. [2] > > [0]: This is described here: > https://tools.ietf.org/html/rfc4880#section-5.2.4 > > [1]: There is Signer's User ID subpacket but it's rarely used and not > used for key certifications as far as I know. > > [2]: Personally, having issuer's User ID be part of trust calculations > seems to be overly complex, what difference does it make if it's the > same person signing the key? Well, I agree with you until the “Thus”. You don't need validity per key to know if you can trust Person X's certifications, you only need ownertrust :) And I think we stopped understanding each other at some point, at least I didn't mean to imply that we should insert the issuer's User ID into trust calculations. What I'm saying is: * When you “sign a key”, you actually sign a (Key, User ID) association, so the “validity” is actually a property of the (Key, User ID) couple, not of the key. * When you want to verify a (Key, User ID) validity, you list the signatures. In the signatures, you look for signatures of keys you trust (as in ownertrust, which AFAIR isn't defined in rfc4880, apart from in trust signatures). If you trust enough keys that signed the (Key, User ID) couple, then you can consider it valid. * Trust is completely decoupled from validity, and you could perfectly trust a key that's not valid to you (even though I can't think of a reasonable use case for it). * Trust signatures extend this scheme by allowing a trusted key to introduce you to other keys that will then become trusted (and most likely valid, because the trust signature is also a signature -- all this depends on local policy). And, with this in mind, I can't find a reasonable concept of “valid key”, only of “valid key-User Id associations”, which would become under my proposal “valid key-User Attribute associations”, and would likely decrease the risk of UIs misleading the user into thinking that a key is “valid”, whatever that could mean. And in particular of showing an unvalidated User ID just because it is the primary User ID. >>> 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. >> >> Well, my hope in pushing this for v5 is that a lot of tools will already >> have to be changed along the path, so I was hoping this would be only an >> additional change that wouldn't be delayed as much :) > > Well, this is the most complex change suggested that I've seen here, > everything else is mostly backwards compatible (note that there is not > much traffic here ;) ). Indeed, then anyway rfc4880bis isn't anywhere close to completion as the WG was even closed, so I guess it's not really pressing matters. But yes, implementation weight is, in my mind, the biggest (and potentially blocking, though I can't speak for implementers) drawback of this idea. >> All this could help particularly in relation to scoped trust, allowing >> to trust certain keys only for signatures on certain User Attributes, >> eg. allowing a GitHub official key to sign all “free form tag=value” >> User Attributes for which “tag” is “github”. Which would be next to >> impossible to do without at least a minimal amount of standardization in >> User Attributes, as is currently the case with everyone misusing User >> IDs everyone with their custom scheme for this purpose > > This is already possible with trust signatures with domain restriction. > If GitHub had their key (and that's a big if) and signed their user's > IDs that have e-mails in form *@users.noreply.github.com with trust sig > level 1 then you could trust sign GitHub's key with trust signature > level 2 limiting that to the users.noreply.github.com domain. Indeed, but that requires all users to “naturally standardize” on *@users.noreply.github.com. Everything I propose can be done with the current User ID scheme. Heck, it's even possible to just “naturally standardize” on putting “name=My Name”, “email=my.email@example.org”, etc. in the User ID fields. The main thing I try to do with this proposal is to give things a place “by standard”, thus allowing tools to rely on it and eg. assume that in the “name” attribute then it is the name of the person, without having to parse the User ID field and try to guess which “natural standard” this specific key has followed :) BTW, just for completeness, the current tsign-based scheme wouldn't require GitHub to issue trust-signatures to keys, it could work the following way: * Users put *@users.noreply.github.com User IDs * GitHub issues normal signatures on validated (Key, User ID in *@users.noreply.github.com format) pairs * Users willing to trust GitHub add a Trust Packet with trust level 255 (because why not, trust level 1 would be enough but could be considered lower than “marginal” and thus not actually be enough to validate associations) and a limitation to *@users.noreply.github.com to their local copy of the GitHub key (or can alternatively use a trust signature if they feel like it) > The same approach with trust signatures could be used by organizations > and their "role" system. > > This article goes into more detail: > > https://www.linuxfoundation.org/blog/pgp-web-of-trust-delegated-trust-and-keyservers/ Indeed that's possible, but it requires “naturally standardizing” for eg. roles in comment sections of User IDs. And in my mind de facto standardization that isn't recognized by the standard means that de jure standardization has failed. Anyway, that's all I have to say, I think, so if I receive no positive feedback I guess I'll just try to, within a few years, turn my idea into yet another protocol with its single implementation, and see what happens. :) From nobody Wed Jun 27 18:44:46 2018 Return-Path: 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 9BC73127332 for ; Wed, 27 Jun 2018 18:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.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 wWk4iVu6qHUU for ; Wed, 27 Jun 2018 18:44:43 -0700 (PDT) Received: from st13p27im-asmtp003.me.com (st13p27im-asmtp003.me.com [17.162.190.112]) (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 75A56130E7B for ; Wed, 27 Jun 2018 18:44:43 -0700 (PDT) Received: from process-dkim-sign-daemon.st13p27im-asmtp003.me.com by st13p27im-asmtp003.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) id <0PB001000F9M8C00@st13p27im-asmtp003.me.com> for openpgp@ietf.org; Thu, 28 Jun 2018 01:44:42 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1530150282; bh=Jj9/pFnL80VSH3O2r8y+vMhi/c2bz2ZfMINKM41Vxbw=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=DxTqvHIfkmYo0r/hkMiDqEbKPo9GSShV5AOZCLxG81NAkpeQEYOUBUFrQahRV7Nhb H0wWmW7bwCweZKIi013yOZRMxLpm2n7TPz6W+bWur0oqt1zFyVzH5PWXDXk1z2BChd UUJu+0BAWJ3CToVYtDgZSv/dB1vrc+lv3eqp/aV4I3zvpaEC+iw6nOrTM2DW/P7mjV DNkA1UJdDsR0S3vDHPuc4cwDkQGnuCwMSI7E0waRzkU5K7M8NedyHUymnPQ0e1OhgO TL1uqQtOxWGp2rq/5evvFh+oX2oQL6dJe83umtr2KcV1HXgbjA8TxNano7oVO/onYF SBH2DP7wd7uIw== Received: from icloud.com ([127.0.0.1]) by st13p27im-asmtp003.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) with ESMTPSA id <0PB00122WFIFWZ00@st13p27im-asmtp003.me.com>; Thu, 28 Jun 2018 01:44:42 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-06-27_08:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1015 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1806280015 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Jon Callas In-reply-to: <3996841a-b6ae-8769-2de8-b35351c54719@leo.gaspard.ninja> Date: Wed, 27 Jun 2018 18:44:39 -0700 Cc: Jon Callas , openpgp@ietf.org Content-transfer-encoding: quoted-printable Message-id: <8E4410C7-9370-492C-838F-857983CA67FC@icloud.com> References: <39e598e1-2bc0-32c9-3489-4bb6ca2a631b@leo.gaspard.ninja> <871sdw24yd.wl-neal@walfield.org> <118e5b9d-de9e-aa14-d8b4-19ef259f3d0a@ruhr-uni-bochum.de> <3996841a-b6ae-8769-2de8-b35351c54719@leo.gaspard.ninja> To: Leo Gaspard X-Mailer: Apple Mail (2.3445.8.2) Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 01:44:45 -0000 Forgive me, Leo, but I don=E2=80=99t understand what problem you=E2=80=99r= e trying to solve, but I=E2=80=99m going to say that=E2=80=99s my fault. = Nonetheless, could you reiterate for those of us who weren=E2=80=99t = paying proper attention before? UserIDs are intentionally a huge hand wave. It=E2=80=99s an arbitrary = UTF-8 field. Put whatever you want into it. Yes, by convention it=E2=80=99= s an email address, but even at the time that that was common it was = convention only. When I was with PGP Corporation, we made software = signing keys that merely said they were software signing keys, as well = as other keys that had no email address, but a text description of what = they were. There=E2=80=99s no reason you can=E2=80=99t put whatever you want in = some other sub-packet or what. Jon From nobody Thu Jun 28 02:35:34 2018 Return-Path: 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 257DB130F2D for ; Thu, 28 Jun 2018 02:35:32 -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 JFcEBdg7EI53 for ; Thu, 28 Jun 2018 02:35:29 -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 7107C130E89 for ; Thu, 28 Jun 2018 02:35:29 -0700 (PDT) Received: by smtp.gaspard.ninja (OpenSMTPD) with ESMTP id c5549cc3 for ; Thu, 28 Jun 2018 09:35:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=leo.gaspard.ninja; h=subject:references:from:to:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s= grym-20170528; bh=LP21YjrEcMPk657hORVKnx6CdV8=; b=sZGwNmQ/vqSClw 4mwGXKmOwfehOU7AOJTkXxSdV1DQDjzoM5hGZ46Hc/u5Byh2Zc86K+IipZx63KW7 McN7ZAfPhKbal84XvJgsJDHj1UHt/eELcFPg+8rAyZ0XSauVbJwHXbEMBj1H54Jx NyphDn/37fzwsT6uUPvl7Dh1kb/GA= Received: by smtp.gaspard.ninja (OpenSMTPD) with ESMTPSA id 3055fb69 (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128:NO) for ; Thu, 28 Jun 2018 09:35:24 +0000 (UTC) References: <39e598e1-2bc0-32c9-3489-4bb6ca2a631b@leo.gaspard.ninja> <871sdw24yd.wl-neal@walfield.org> <118e5b9d-de9e-aa14-d8b4-19ef259f3d0a@ruhr-uni-bochum.de> <3996841a-b6ae-8769-2de8-b35351c54719@leo.gaspard.ninja> <8E4410C7-9370-492C-838F-857983CA67FC@icloud.com> From: Leo Gaspard To: openpgp@ietf.org Message-ID: <8a608b9f-f96b-466d-a0b8-7d1aa39ab011@leo.gaspard.ninja> Date: Thu, 28 Jun 2018 11:35:24 +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: <8E4410C7-9370-492C-838F-857983CA67FC@icloud.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 09:35:33 -0000 On 06/28/2018 03:44 AM, Jon Callas wrote: > Forgive me, Leo, but I don’t understand what problem you’re trying to solve, but I’m going to say that’s my fault. Nonetheless, could you reiterate for those of us who weren’t paying proper attention before? No problem! > UserIDs are intentionally a huge hand wave. It’s an arbitrary UTF-8 field. Put whatever you want into it. Yes, by convention it’s an email address, but even at the time that that was common it was convention only. When I was with PGP Corporation, we made software signing keys that merely said they were software signing keys, as well as other keys that had no email address, but a text description of what they were. Well, the idea is that User IDs are a huge hand wave indeed, and that seems to make exploiting this hard, esp. around signature, as that most often means (in my experience) that I can't sign an email address without signing a name and reciprocally. So I think splitting the User IDs into orthogonal fields would make signing these fields (as well as setting trust signatures with constraints) much easier. Currently, the fields I am thinking of would be defined as User Attributes, and would be: * name (for the real-world name of the owner) * email * role (would fit the software signing key case, or role of the owner of a key inside an organization) * pseudonym (not really sure this one would be really useful, but this would allow people's signing policy for pseudonyms to differ from the signing policy for names, eg. noticing persistent use of the same pseudonym vs. checking government-issued ID, without misleading verifiers into thinking that the pseudonym was actually a government-validated name) * free form tag=value (for eg. xmpp=foo@example.org, github=bar, etc.) Not all of these fields would need to be filled-in, obviously, and a key could have any number of each. The main point of this is to make eg. automated signature of email addresses possible without impacting user interface by requiring an email address in a separate User ID. Also, I don't think it would reduce the freedom currently offered by User IDs, because there would always be the free form tag=value User Attribute for marginal cases. But it would incite people to put the right value into the right field, and would likely make life easier for both automated and non-automated signers. Is what I'm thinking of more clear now? :) > There’s no reason you can’t put whatever you want in some other sub-packet or what. The problem with putting it in another sub-packet is that it can't replace User IDs, and User IDs will thus always be the thing that is used for signature and verification. And this would mean there would be no point in this change. From nobody Thu Jun 28 17:38:18 2018 Return-Path: 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 2348A130E3F for ; Thu, 28 Jun 2018 17:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.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 W_aIcnBlIGEV for ; Thu, 28 Jun 2018 17:38:14 -0700 (PDT) Received: from st13p27im-asmtp003.me.com (st13p27im-asmtp003.me.com [17.162.190.112]) (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 0D636130DEF for ; Thu, 28 Jun 2018 17:38:14 -0700 (PDT) Received: from process-dkim-sign-daemon.st13p27im-asmtp003.me.com by st13p27im-asmtp003.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) id <0PB200C006R2EE00@st13p27im-asmtp003.me.com> for openpgp@ietf.org; Fri, 29 Jun 2018 00:38:12 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1530232692; bh=RmypMITspzPKcniSnVMll7ho6hqdhs4cIZ0HCAESqyM=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=Og6xxbCA49dLev6yvbe9OL5vL8uFJqxbow4B8CjBE8GEYEVAfHYP0nZNdRDA3rCO9 fIk6qbJbAoBtKI1COyt+HaBUvpo3/uTuD69qBJ3UWTdZ6/FlfIWToFOczBggAysn5t 0jRfYMAaPCd9kTPlzCray/0l/uc9czv5ynlPPYyZ7flAotIW6vdmg/Woxk4q72wKtJ aPhAUMoDSilfQ2mcA94q4OJ0hPXpsOVdy1uuglcQa4a02DjqW7BGPKZYLcUseNFlDi qjk+kJzuabu0g0TABdz+ldOQAUXGLVk2+9ODeoE00J+V7sAUg4zTl/g0G0t/vTSRpW be8ay1XgfBU3g== Received: from icloud.com ([127.0.0.1]) by st13p27im-asmtp003.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) with ESMTPSA id <0PB2006ZC73LKF00@st13p27im-asmtp003.me.com>; Fri, 29 Jun 2018 00:38:12 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-06-28_09:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1015 suspectscore=2 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1806290004 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Jon Callas In-reply-to: <8a608b9f-f96b-466d-a0b8-7d1aa39ab011@leo.gaspard.ninja> Date: Thu, 28 Jun 2018 17:38:09 -0700 Cc: Jon Callas , openpgp@ietf.org Content-transfer-encoding: quoted-printable Message-id: References: <39e598e1-2bc0-32c9-3489-4bb6ca2a631b@leo.gaspard.ninja> <871sdw24yd.wl-neal@walfield.org> <118e5b9d-de9e-aa14-d8b4-19ef259f3d0a@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> To: Leo Gaspard X-Mailer: Apple Mail (2.3445.8.2) Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 00:38:17 -0000 > On Jun 28, 2018, at 2:35 AM, Leo Gaspard = wrote: >=20 > On 06/28/2018 03:44 AM, Jon Callas wrote: >> Forgive me, Leo, but I don=E2=80=99t understand what problem you=E2=80=99= re trying to solve, but I=E2=80=99m going to say that=E2=80=99s my = fault. Nonetheless, could you reiterate for those of us who weren=E2=80=99= t paying proper attention before? >=20 > No problem! >=20 >> UserIDs are intentionally a huge hand wave. It=E2=80=99s an arbitrary = UTF-8 field. Put whatever you want into it. Yes, by convention it=E2=80=99= s an email address, but even at the time that that was common it was = convention only. When I was with PGP Corporation, we made software = signing keys that merely said they were software signing keys, as well = as other keys that had no email address, but a text description of what = they were. >=20 > Well, the idea is that User IDs are a huge hand wave indeed, and that > seems to make exploiting this hard, esp. around signature, as that = most > often means (in my experience) that I can't sign an email address > without signing a name and reciprocally. >=20 > So I think splitting the User IDs into orthogonal fields would make > signing these fields (as well as setting trust signatures with > constraints) much easier. >=20 > Currently, the fields I am thinking of would be defined as User > Attributes, and would be: > * name (for the real-world name of the owner) > * email > * role (would fit the software signing key case, or role of the owner > of a key inside an organization) > * pseudonym (not really sure this one would be really useful, but this > would allow people's signing policy for pseudonyms to differ from the > signing policy for names, eg. noticing persistent use of the same > pseudonym vs. checking government-issued ID, without misleading > verifiers into thinking that the pseudonym was actually a > government-validated name) > * free form tag=3Dvalue (for eg. xmpp=3Dfoo@example.org, github=3Dbar, = etc.) >=20 > Not all of these fields would need to be filled-in, obviously, and a = key > could have any number of each. >=20 > The main point of this is to make eg. automated signature of email > addresses possible without impacting user interface by requiring an > email address in a separate User ID. >=20 > Also, I don't think it would reduce the freedom currently offered by > User IDs, because there would always be the free form tag=3Dvalue User > Attribute for marginal cases. But it would incite people to put the > right value into the right field, and would likely make life easier = for > both automated and non-automated signers. >=20 > Is what I'm thinking of more clear now? :) Absolutely.=20 You could do this with User IDs. They are, after all, generic and you = could thrown XML, JSON, or whatever else you wanted. It would be ugly = (because most software presumes that it=E2=80=99s human-readable and = human-useful), but it would work.=20 Or you could do it with User Attribute Packets that are explicitly = designed for this sort of thing. There=E2=80=99s only one type of = attribute defined now, a photo. Section 5.12 defines them, notes that, = also says that software SHOULD ignore types that it doesn=E2=80=99t = recognize, and beyond that notes that (as usual) types of 100-110 are = for private or experimental types.=20 I suggest this because there is an established framework for you to = experiment and show the usefulness of what you=E2=80=99re doing. Make = your own packet, number it 110, and go ahead. Or, write up an RFC draft, = propose in it that you use 2 as the type, and get rough consensus and = running code to do it for you. If you bend User IDs into what you want, then it effectively becomes = everyone=E2=80=99s business as you=E2=80=99re veering from the spirit = User IDs and there=E2=80=99s no good way for software that doesn=E2=80=99t= want to play along to do something sensible. But if you use User = Attributes, you=E2=80=99re in territory where the system is tilted in = your favor. The standard says that an implementation that doesn=E2=80=99t = understand yours SHOULD ignore it. It says, "Except as noted, a User = Attribute packet may be used anywhere that a User ID packet may be = used,=E2=80=9D and that means that it falls into exactly what you want. = It becomes your own thing that doesn=E2=80=99t affect those who don=E2=80=99= t agree. It=E2=80=99s a much better place to be standing. Heck, while you=E2=80=99re 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=E2=80=99m likely missing. Jon From nobody Fri Jun 29 00:46:10 2018 Return-Path: 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 F075D130EA1 for ; Fri, 29 Jun 2018 00:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=metacode.biz 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 JgRsfU7ogB9e for ; Fri, 29 Jun 2018 00:46:02 -0700 (PDT) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (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 5833E130DE5 for ; Fri, 29 Jun 2018 00:46:02 -0700 (PDT) Received: by mail-wm0-x244.google.com with SMTP id n17-v6so1003281wmh.2 for ; Fri, 29 Jun 2018 00:46:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metacode.biz; s=2017; h=subject:to:references:from:openpgp:autocrypt:organization :message-id:date:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=gnlU3KTVdeI0mQiEa+yunWM/OHt0TwR6bibJn6/WsEI=; b=r0foCm3zmxjABGA46zttSI7GJG/acybn3AmlUFGQ9QLu17Jn4PIsahA3N7kv40PfIV GIaY2CPHCltkgUx8c2K6RaCgGjWTKqh4DjhnoUH1T7rt1aioHfSGJb1kS09OmDcsL/6O lXVNhz++qLPPrimu7nrJMQlHZURWf/BUy943gPd9FgIu/kCPUqktyRMz9kBEGxMsTeBX TpzxIguY9BhSoy79tzrPv7SmTa4OP+rJeBIMLh8jEKAlXGSxTD+z6l1cAh926leWWYb4 ARXqUTOeyO9kgDSzRROyjSd+Tfs1+l3/ei/7nvc6O3MwstUyO69B8AezeTAne+kn5u7K 3RFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt :organization:message-id:date:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=gnlU3KTVdeI0mQiEa+yunWM/OHt0TwR6bibJn6/WsEI=; b=d88raWl8YI30ETdKklK7DETPGHpoAro5d8OP0R2LYzJ61e5HO0+X7Db6lckHymnYzG rXBub1c1+JBgrWiB5LKG9W35hcW2p0kwER9OXiWJUk4eVolORm3W4rXdeIp8XU2JKLwG s4Wdxx+vR1xIeQnjFpW0mL+GuTAaZdO7a2yotSZ+jRvVQ998YuVAWVIQE4OtIn0RRxqk vGW5CVOMJctGgRsr6yqmmaF7A1A4n2CvtDAiAnsqRSBjLUz9OZhuPNh8z+Vh0v9wqNHQ 8bE9d33gAYUjcI28dDFVhC+cgcDzqPxQqFSSd8w7Iff7IDMgNixiJzrdM9Ugr2y2tMqP 3WEA== X-Gm-Message-State: APt69E2w/b4s492jebTQ67bCvK+ZfDXM7SVTM7IsjcjLREOSOrAF9SM9 gudR4MYRIGNo8WYJ9/vvVF6i+VQSgLY= X-Google-Smtp-Source: AAOMgpcWhQoiPps5frW8HGKLD6cRX1wBPGAswj2Lwozg+koxzGS7sBQQYtHlzV5QGy2c66v6Fn01Gg== X-Received: by 2002:a1c:9c0b:: with SMTP id f11-v6mr903150wme.148.1530258360273; Fri, 29 Jun 2018 00:46:00 -0700 (PDT) Received: from ?IPv6:2a00:f41:3860:62f5:f85f:30b1:f057:9192? ([2a00:f41:3860:62f5:f85f:30b1:f057:9192]) by smtp.googlemail.com with ESMTPSA id i190-v6sm700778wmd.33.2018.06.29.00.45.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Jun 2018 00:45:59 -0700 (PDT) To: openpgp@ietf.org References: <39e598e1-2bc0-32c9-3489-4bb6ca2a631b@leo.gaspard.ninja> <871sdw24yd.wl-neal@walfield.org> <118e5b9d-de9e-aa14-d8b4-19ef259f3d0a@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> From: Wiktor Kwapisiewicz Openpgp: id=653909A2F0E37C106F5FAF546C8857E0D8E8F074; url=https://metacode.biz/@wiktor/openpgp/key Autocrypt: addr=wiktor@metacode.biz; keydata= xsFNBFhoYHoBEADzmg9UuwDrtvyejU01gDY1J1iJiCi4XGJ4lCfYeLC2jSagIxU/5Lu0lRft 0Loi2tsjpo0c8docP7HFxafEEvnnt/iabd6I536llMuw0uno4PgnD3ljcCMZLT+vn+amIDta lzVoMnSqzoNUotMNMtjIFuAaQ/wr4/Mp9CIgJdviGUc3PscqUiiUVVtk6uF0x657NULZgSIT /Mrqlr2i4RuyPwXe2Qt0uEA3KWWjF0l2NpAMVrqz+nHsLoNOaAsfdx94bzKQrrSeSQqEO2f+ /eO/hbUAFAmEhrotmUO8wJNygo8TgkdlzFI+UE4p8/KW0aCgGGgR8YkCvHq2OQhAAYFNJoNz Hqw0FGxdsY8qWFkYpoSB8zKspNy8KliofCamMYXoPF7eVIxIiKvxrAykGP4jNnzSoV0cn+bY fXnox1IhnqbnoJIT7kTmXv4JmWoYm8ThHqpEgcQOUUQzSRXb9OiNwiXT71ijeO1qswMRpsgk 6AGKSZGWxa3c4ive/p8z1Ax27BFZSh2FceIcMCcGLrDjnQYgeFsAJ1jSxZQXkGuJFHfb4nff Big7aq/vyKrQFQXG0NQQL7rZAdk/s665vifos0yPmRDu7yDT1ggdyBp4Pa4re+ZJcNRNzNHo zU9al+CoImCQjnTtKMXmOe/BzGrpHI4QR3NNzVa423WCIWkHfwARAQABzSlXaWt0b3IgS3dh cGlzaWV3aWN6IDx3aWt0b3JAbWV0YWNvZGUuYml6PsLB7gQTAQoAmAIbAQgLCQgHDQwLCgUV CgkICwIeAQIXgHMUgAAAAAAqAEB0aW1lc3RhbXArYml0Y29pbi10cmFuc2FjdGlvbkBtZXRh Y29kZS5iaXphZmNiMDkyYzVjYTY0MDk1MjZkMThhZTljZjIyZDNiNTVkMzdlNzIzZWIxYjc0 ZTNmODRmN2U2YjA1MmExNjJhBQJaLoPdBQkDwPuGAAoJEGyIV+DY6PB0CNkQAKGTFHzG4YO6 yne5jfMlGcF8JUYq0EGHE9DRK6oAyGo+1TGFbf1bS4wULvA6LFBOLd+aI7uuN062kDdtHVUf 0S0AZ9ByjIBdQJsqx47W6uXsRX/pB0a70QqS6NbS3AL/fdwZOj/TBk8bdsfg7Z+hH+ykMcOs EYLmdMLmrqYgl9EyP4FmsnU9H8x4yKp0/Kv4BQYfjn68CFvyM2NQU3MR/H3sqvM/uY5AJwTp A8X1ZbN8pjZO5YRTiQtMrXekNzhP3p0ep1+cu2UxQO6jXV6Sjdm8D8RJzGaxCuhN/VhLNSvh cb2T5sejBAhU8JmKNle4+z5wZWB4bl5Dfkg1NpSEEdv7so+KXCnszo89UJJijlfgBFtm5WjK u7gCR8CVOeGQwQolEzi18zihCwRy1rg/xKokk7q6ZBEvxM1sBYNd81mi1PgrNwgH4jPULfQk UJtU7HLRVNLbnrIyEQbLOJegBLaWHgR4T69blBGg1oqiq/1PHnZuJauZhhNEAViX42VKJP1z w6PIfvbjg27wf4OjEDtVVXCrxqqljHRilagFQHGlU+iF6Ii2C3pNod11+lqJC0riFylxK/wu zHpoZdFg10gqMWIE2Exm7nJ6ToKv5kZqKC97mWrmh6FFEr6HmjDDuo+N4RER3VGj0dSey5nc eFQ2vry17IGN1ljV9TiARDgizsFNBFhoYf0BEACidQ4OVAKliYOnNzG5ltod8GS0eJj3CSnY 0gszCjS6Hm0OkvCN5RfEagALuLuJe06nFDB/mEvsV3CKO1rxPUrQnijxjl/L5LopdEVhwQoL UBhvMvdX62krk6CtsFUlQvHPS923+YoQ1/HWR8jbWLJq/PNJp3fE9FKbWX6BchOeZ/KCZ/Ip 6vv7YOVVyBVL8O/slSkEEaUS40ac/F70/wfUPXRgiOLYVikRNlphvmTu54F0KWFUbPYAhyr/ xSz8Joy34+e9h5ipEb+Cv9CrjQaHp8aLDAR1VJ3A+SjSt20mU1CuhKwpR+z0t/hjlOLHv0zR qWl3QNYmNBJ9I2oW4mH9FEDM3DRsWEaqdaL1uVeQ8rE4QZ6tbk76YS8eyRWjScLQm61USHxq 7KpUI73k6ST0Ylyj8D1a03dKUTuytgU0NhbFyArI2UHNvhm73X6qo7ofHlfgA6mVAaI4jW7r /CY0GLs29PyetdII/+6F50HAEXBswTesgx/2P6k+vHhReyZF7NgSkqEWaGgKdRlSyTpu/U+Q TRmLB/yWfL89+BMJZosX0oMWZxG7XPu18GXSeHNoSPw9xLNGWGMbKErIbyVqQyd6fu2gpYzO n9J57ImHvgoENvcyRl7sSOiZto/5EJiHubUBTeeuZf2V7QxfrP15h1SVkzDjIOP3qXF+oCI8 jQARAQABwsFlBBgBCgAPBQJYaGH9AhsMBQkB4TOAAAoJEGyIV+DY6PB0I94P/iFsWZcgYNaN JxXK99755nzKKDSqjCOkTgoV9h9cNaIZV944pupdugRW5ek6BV2/Cj93iCGMzrfzzvETPT4t 8oaC/0yJ0pzPUrFe9Uht2ghtmXQK6Mw0fM4daPKJtCQyMlfYljqKhxgIJ24cB+O04yOrvfCS FRQw/T4ngmqCvI1wRzxU98yljKKxcvQWZ6qY6izNeUZJ6Ie1iujQOEmnLSXMikcptGf5YC9C KY0f9MsCI75uCx2HKQRRcj/nOHE+dkwo5XyUbSuWhQu6bOHJI5S0ixkjVp6JQ4E1NBLR3P3V Kr1jg6ODbJ0w9B8peSumzFhGf0qo2RYkPYKkUFfejmUhphSAS2WmdGHbut32ibDn6vd/XTjs vGQUDQ2Bp3fXdqeTw79T5zGpS87omdnz/Wpavntjv9IbVTnCmJMfSBYUmMoBK94IEWttKmL/ UCmcoruhhLs1A3Xdn17gt6k+AkBapBd8IC15QiMedzCINtug399M9MMfgkW5NpGOunpLBbhG xUD2nqdK2j347/dGTT53sUa6tQw6IDNZrCWOJTqTeP6PD7BJt67tlywPgmLSBGYgWpnRNJhb 9QKzyn3KnUzp9lzUDLReEu2gdY2Kz1N5PVmmF/ysfKVJZ0ZGWPB4iR/HgAc6OY2TnHXiifKT EXmAO6RvoR7+8se4PUnv0mR1wsFlBBgBCgAPAhsMBQJaLoRUBQkDwPoDAAoJEGyIV+DY6PB0 XoMP/i+6XvyNE/XsdFgeAO/rtdELWphFUu1HbaKYeh6YMYjg71eR8KbYe2sz3M1Bawj/D7Kb tGRsxFshkLHau0N0cJHEr3U6j/U7sEWCW/YDlWSIyBWYg+j1k/aBczfL/oC9E9h8LOUUjjj3 vpRs2rHmIHT2aAvbRom1d4xaFh1kwn7sUKtc+0AoP5PCeBcfqMduunEPqsfsbmz1Dz+O5FJ7 LRG8YXyV+5YTT1pEuNjFm+GNBEvwhfJqN+H459ngMdZUkCyKwWLAMaJj6y9/ZJ8lrPLCjGDR p9FzhLg39gQqV5Vu41VyBr+9YucX/sWfQ1SuvWDMBnTKSOKX01RAHGvnOmtl3Vr4SqWDhFsO VdWluKugMiIdajKwgM9Bp+35O/l8QQbxxrRAy/TI+dB4w8Urn2oVPkAq8RgYJIzpYYUFnhKD EwcdoG8Lk2EqO60g9UR6tGVsW9/vYvVGHlm0kArIDF9o0zAo5wsuZE9kO4oneoIsCRLwjuZk bqQ+2V+8R3P5YkV8VogwwYPCAhkpGD/ACblux5ip1ilLWFm75Hj3aPkvJSWi5DfkoxzntZBM KrhpyhCKJFUPZovREteTzl8ns3/KvoUJ5VQF3HqXKw49sWrWSDHEugt9ERfCBzAuYl4WB7Qt xwe2q0voV3BFy8kd04NRiyJkBU0BeBHEHblrGY23 Organization: Metacode Message-ID: <1cacc056-1ec7-f388-ee08-46468bd87bda@metacode.biz> Date: Fri, 29 Jun 2018 09:45:55 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 07:46:09 -0000 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]. 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. (As a side note, photos could be expressed as links to images with a hash, that would reduce the key size significantly). On the other hand I like the "hand wavy" approach to User IDs, I think it's underutilized :-) Kind regards, Wiktor [0]: https://news.ycombinator.com/item?id=15352217 [1]: https://tools.ietf.org/html/draft-vb-openpgp-linked-ids-01 [2]: https://github.com/wiktor-k/distributed-ids [3]: https://www.ietf.org/mail-archive/web/openpgp/current/msg08914.html [4]: https://keyserver.ubuntu.com/pks/lookup?fingerprint=on&search=0x653909A2F0E37C106F5FAF546C8857E0D8E8F074 -- */metacode/* From nobody Fri Jun 29 05:22:39 2018 Return-Path: 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 E364E1271FF for ; Fri, 29 Jun 2018 05:22:37 -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 heo5YDib-NYk for ; Fri, 29 Jun 2018 05:22:35 -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 BCA5B1277CC for ; Fri, 29 Jun 2018 05:22:34 -0700 (PDT) Received: by smtp.gaspard.ninja (OpenSMTPD) with ESMTP id b06a1570; Fri, 29 Jun 2018 12:22:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=leo.gaspard.ninja; h=subject:to:cc:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s= grym-20170528; bh=Hv+GOVkJS1fB1ZjEtCGKjC4vSnM=; b=HFB9Ir+ZkPHQuh zNe4m2jNveVFygTKTDW6y+mgfywQ6/EU6AQ0TEgynq2pBkZRy1SmR7YV0I7Nap5g 8g6NAgo9pdLCLJ9jGyhGx3Pj161otfbdvLLUDJH/hiqSKt4ppDu0YocbCXrX7cAC XBNiIoB6WqMQjtBiKQcLecjeSGITs= Received: by smtp.gaspard.ninja (OpenSMTPD) with ESMTPSA id d6089a33 (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128:NO); Fri, 29 Jun 2018 12:22:29 +0000 (UTC) To: Jon Callas Cc: openpgp@ietf.org References: <39e598e1-2bc0-32c9-3489-4bb6ca2a631b@leo.gaspard.ninja> <871sdw24yd.wl-neal@walfield.org> <118e5b9d-de9e-aa14-d8b4-19ef259f3d0a@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> From: Leo Gaspard Message-ID: <0b7a844a-7281-1372-977d-e96bb38a36e7@leo.gaspard.ninja> Date: Fri, 29 Jun 2018 21:22:23 +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: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 12:22:38 -0000 On 06/29/2018 09:38 AM, Jon Callas wrote: >> The main point of this is to make eg. automated signature of email >> addresses possible without impacting user interface by requiring an >> email address in a separate User ID. >> >> Also, I don't think it would reduce the freedom currently offered by >> User IDs, because there would always be the free form tag=value User >> Attribute for marginal cases. But it would incite people to put the >> right value into the right field, and would likely make life easier for >> both automated and non-automated signers. >> >> Is what I'm thinking of more clear now? :) > > Absolutely. > > You could do this with User IDs. They are, after all, generic and you could thrown XML, JSON, or whatever else you wanted. It would be ugly (because most software presumes that it’s human-readable and human-useful), but it would work. > > Or you could do it with User Attribute Packets that are explicitly designed for this sort of thing. There’s only one type of attribute defined now, a photo. Section 5.12 defines them, notes that, also says that software SHOULD ignore types that it doesn’t recognize, and beyond that notes that (as usual) types of 100-110 are for private or experimental types. Indeed, that's exactly what I was hoping for, sorry for forgetting to put in my summary that it'd be in User Attribute packets that I'd put the relevant data :) However, I was thinking of something a bit more extreme for the switch: completely forbidding the User ID packet type in v5 keys, so that software written for it could just assume it's in the “split” format. That said, that's maybe a bit too extreme indeed. > I suggest this because there is an established framework for you to experiment and show the usefulness of what you’re doing. Make your own packet, number it 110, and go ahead. Or, write up an RFC draft, propose in it that you use 2 as the type, and get rough consensus and running code to do it for you. Well that's likely best, but given I don't think I'll have time to become a developer of OpenPGP software for at least a few months, I was hoping to get positive feedback on the idea from at least one developer, who'd be willing to try and implement such a draft were I to write it, before spending too much time on writing the said draft :) but it sounds like I'm having little luck for the time being. From nobody Fri Jun 29 05:40:51 2018 Return-Path: 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 ; 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 ; 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 ; Fri, 29 Jun 2018 05:40:34 -0700 (PDT) Received: by smtp.gaspard.ninja (OpenSMTPD) with ESMTP id c8a53c3a for ; 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 ; 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> <118e5b9d-de9e-aa14-d8b4-19ef259f3d0a@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> <1cacc056-1ec7-f388-ee08-46468bd87bda@metacode.biz> From: Leo Gaspard Message-ID: 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: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 :) From nobody Fri Jun 29 05:55:40 2018 Return-Path: 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 F2573130E82 for ; Fri, 29 Jun 2018 05:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=metacode.biz 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 OPGgX4QwHZek for ; Fri, 29 Jun 2018 05:55:37 -0700 (PDT) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (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 A58E7130E81 for ; Fri, 29 Jun 2018 05:55:36 -0700 (PDT) Received: by mail-wr0-x233.google.com with SMTP id l2-v6so8187615wro.7 for ; Fri, 29 Jun 2018 05:55:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metacode.biz; s=2017; h=subject:to:references:from:openpgp:autocrypt:organization :message-id:date:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ZpQiPLykxDffkfevWhccZAJiWXFwRML5ybkOIjhbCTc=; b=cs/MnVG4RwPkOTwcMv3qpwcfdwAB481w3ByndY0NyJWWT80IemGDrZvgj1LnRQ3kos iX1OwP5Nm1L9pshuPg0Kekwx47JUi0ZaLYv9LwB2kljKpLcA+p/McFwkCrM3+eBxH/+2 gsAWHtESzl9fNAZT6ZndhRJyUQfgLYBHLvhvIbWxSnDlHsA+1O2kNyKs+sPr6PbbgOXy gw8G0L0AdE8kI3zEQe1hn01llDuGchqJNO8iXmLAts0EQHHiUKbnCsubxW6xoMqK+Fhf avrrhc4rL93jQVUylS2TDz1EHMJxrQd1ZItI1N10FcFBM6yGRlF3igKKfHue94hGHpdF yIWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt :organization:message-id:date:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=ZpQiPLykxDffkfevWhccZAJiWXFwRML5ybkOIjhbCTc=; b=mVPaBdnCALsvtl2RMDj9Kp+h+cqqMDtwrq2IyssKLZxY/MF0zTlY0JDkITTOVQ3k1D wJ5LgPwwTdrIJf4dT5QmycLpbTQ+6s50ss0rw1NinU/uulWlAqTEOpD0HQwxH2Wdqbi4 HC3qunty6ho2/ocSJYKFRxJOHG8jr5G28PYo1G8v/obpMm5CEMnGz829sa/WoYVQzfJN M0KvOnT5RIqpWUG79tOlA2vVRlbhgkbk5dohja5TzLundl5Fp+Qbta0NxtuaLeFioeuI e/cAskLEIVZ7h9Hd7LG+U6roF5JaqJGJHhWKEe9jfajtzajpxCgaJxzl2lyVTbQUKnbJ RJ7w== X-Gm-Message-State: APt69E3WzDpckHVJD/09TH6ofgfWObGIO2OKEwxhxYWiua2bySJ+7OhT sQ8DixeQZahsf4dLXHW9gGnW5FNQhJ8= X-Google-Smtp-Source: AAOMgpd2pUBRl/rlz6ITVaONDDEt+Mcfoz2c5D9cOP1VdMqzAGGyinwsQR0xLlZvA8lEt2rjQPXzSA== X-Received: by 2002:adf:af27:: with SMTP id z36-v6mr11654780wrc.59.1530276934885; Fri, 29 Jun 2018 05:55:34 -0700 (PDT) Received: from ?IPv6:2a00:f41:3860:62f5:f85f:30b1:f057:9192? ([2a00:f41:3860:62f5:f85f:30b1:f057:9192]) by smtp.googlemail.com with ESMTPSA id b16-v6sm14093942wrm.15.2018.06.29.05.55.33 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Jun 2018 05:55:33 -0700 (PDT) To: openpgp@ietf.org References: <39e598e1-2bc0-32c9-3489-4bb6ca2a631b@leo.gaspard.ninja> <871sdw24yd.wl-neal@walfield.org> <118e5b9d-de9e-aa14-d8b4-19ef259f3d0a@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> <1cacc056-1ec7-f388-ee08-46468bd87bda@metacode.biz> From: Wiktor Kwapisiewicz Openpgp: id=653909A2F0E37C106F5FAF546C8857E0D8E8F074; url=https://metacode.biz/@wiktor/openpgp/key Autocrypt: addr=wiktor@metacode.biz; keydata= xsFNBFhoYHoBEADzmg9UuwDrtvyejU01gDY1J1iJiCi4XGJ4lCfYeLC2jSagIxU/5Lu0lRft 0Loi2tsjpo0c8docP7HFxafEEvnnt/iabd6I536llMuw0uno4PgnD3ljcCMZLT+vn+amIDta lzVoMnSqzoNUotMNMtjIFuAaQ/wr4/Mp9CIgJdviGUc3PscqUiiUVVtk6uF0x657NULZgSIT /Mrqlr2i4RuyPwXe2Qt0uEA3KWWjF0l2NpAMVrqz+nHsLoNOaAsfdx94bzKQrrSeSQqEO2f+ /eO/hbUAFAmEhrotmUO8wJNygo8TgkdlzFI+UE4p8/KW0aCgGGgR8YkCvHq2OQhAAYFNJoNz Hqw0FGxdsY8qWFkYpoSB8zKspNy8KliofCamMYXoPF7eVIxIiKvxrAykGP4jNnzSoV0cn+bY fXnox1IhnqbnoJIT7kTmXv4JmWoYm8ThHqpEgcQOUUQzSRXb9OiNwiXT71ijeO1qswMRpsgk 6AGKSZGWxa3c4ive/p8z1Ax27BFZSh2FceIcMCcGLrDjnQYgeFsAJ1jSxZQXkGuJFHfb4nff Big7aq/vyKrQFQXG0NQQL7rZAdk/s665vifos0yPmRDu7yDT1ggdyBp4Pa4re+ZJcNRNzNHo zU9al+CoImCQjnTtKMXmOe/BzGrpHI4QR3NNzVa423WCIWkHfwARAQABzSlXaWt0b3IgS3dh cGlzaWV3aWN6IDx3aWt0b3JAbWV0YWNvZGUuYml6PsLB7gQTAQoAmAIbAQgLCQgHDQwLCgUV CgkICwIeAQIXgHMUgAAAAAAqAEB0aW1lc3RhbXArYml0Y29pbi10cmFuc2FjdGlvbkBtZXRh Y29kZS5iaXphZmNiMDkyYzVjYTY0MDk1MjZkMThhZTljZjIyZDNiNTVkMzdlNzIzZWIxYjc0 ZTNmODRmN2U2YjA1MmExNjJhBQJaLoPdBQkDwPuGAAoJEGyIV+DY6PB0CNkQAKGTFHzG4YO6 yne5jfMlGcF8JUYq0EGHE9DRK6oAyGo+1TGFbf1bS4wULvA6LFBOLd+aI7uuN062kDdtHVUf 0S0AZ9ByjIBdQJsqx47W6uXsRX/pB0a70QqS6NbS3AL/fdwZOj/TBk8bdsfg7Z+hH+ykMcOs EYLmdMLmrqYgl9EyP4FmsnU9H8x4yKp0/Kv4BQYfjn68CFvyM2NQU3MR/H3sqvM/uY5AJwTp A8X1ZbN8pjZO5YRTiQtMrXekNzhP3p0ep1+cu2UxQO6jXV6Sjdm8D8RJzGaxCuhN/VhLNSvh cb2T5sejBAhU8JmKNle4+z5wZWB4bl5Dfkg1NpSEEdv7so+KXCnszo89UJJijlfgBFtm5WjK u7gCR8CVOeGQwQolEzi18zihCwRy1rg/xKokk7q6ZBEvxM1sBYNd81mi1PgrNwgH4jPULfQk UJtU7HLRVNLbnrIyEQbLOJegBLaWHgR4T69blBGg1oqiq/1PHnZuJauZhhNEAViX42VKJP1z w6PIfvbjg27wf4OjEDtVVXCrxqqljHRilagFQHGlU+iF6Ii2C3pNod11+lqJC0riFylxK/wu zHpoZdFg10gqMWIE2Exm7nJ6ToKv5kZqKC97mWrmh6FFEr6HmjDDuo+N4RER3VGj0dSey5nc eFQ2vry17IGN1ljV9TiARDgizsFNBFhoYf0BEACidQ4OVAKliYOnNzG5ltod8GS0eJj3CSnY 0gszCjS6Hm0OkvCN5RfEagALuLuJe06nFDB/mEvsV3CKO1rxPUrQnijxjl/L5LopdEVhwQoL UBhvMvdX62krk6CtsFUlQvHPS923+YoQ1/HWR8jbWLJq/PNJp3fE9FKbWX6BchOeZ/KCZ/Ip 6vv7YOVVyBVL8O/slSkEEaUS40ac/F70/wfUPXRgiOLYVikRNlphvmTu54F0KWFUbPYAhyr/ xSz8Joy34+e9h5ipEb+Cv9CrjQaHp8aLDAR1VJ3A+SjSt20mU1CuhKwpR+z0t/hjlOLHv0zR qWl3QNYmNBJ9I2oW4mH9FEDM3DRsWEaqdaL1uVeQ8rE4QZ6tbk76YS8eyRWjScLQm61USHxq 7KpUI73k6ST0Ylyj8D1a03dKUTuytgU0NhbFyArI2UHNvhm73X6qo7ofHlfgA6mVAaI4jW7r /CY0GLs29PyetdII/+6F50HAEXBswTesgx/2P6k+vHhReyZF7NgSkqEWaGgKdRlSyTpu/U+Q TRmLB/yWfL89+BMJZosX0oMWZxG7XPu18GXSeHNoSPw9xLNGWGMbKErIbyVqQyd6fu2gpYzO n9J57ImHvgoENvcyRl7sSOiZto/5EJiHubUBTeeuZf2V7QxfrP15h1SVkzDjIOP3qXF+oCI8 jQARAQABwsFlBBgBCgAPBQJYaGH9AhsMBQkB4TOAAAoJEGyIV+DY6PB0I94P/iFsWZcgYNaN JxXK99755nzKKDSqjCOkTgoV9h9cNaIZV944pupdugRW5ek6BV2/Cj93iCGMzrfzzvETPT4t 8oaC/0yJ0pzPUrFe9Uht2ghtmXQK6Mw0fM4daPKJtCQyMlfYljqKhxgIJ24cB+O04yOrvfCS FRQw/T4ngmqCvI1wRzxU98yljKKxcvQWZ6qY6izNeUZJ6Ie1iujQOEmnLSXMikcptGf5YC9C KY0f9MsCI75uCx2HKQRRcj/nOHE+dkwo5XyUbSuWhQu6bOHJI5S0ixkjVp6JQ4E1NBLR3P3V Kr1jg6ODbJ0w9B8peSumzFhGf0qo2RYkPYKkUFfejmUhphSAS2WmdGHbut32ibDn6vd/XTjs vGQUDQ2Bp3fXdqeTw79T5zGpS87omdnz/Wpavntjv9IbVTnCmJMfSBYUmMoBK94IEWttKmL/ UCmcoruhhLs1A3Xdn17gt6k+AkBapBd8IC15QiMedzCINtug399M9MMfgkW5NpGOunpLBbhG xUD2nqdK2j347/dGTT53sUa6tQw6IDNZrCWOJTqTeP6PD7BJt67tlywPgmLSBGYgWpnRNJhb 9QKzyn3KnUzp9lzUDLReEu2gdY2Kz1N5PVmmF/ysfKVJZ0ZGWPB4iR/HgAc6OY2TnHXiifKT EXmAO6RvoR7+8se4PUnv0mR1wsFlBBgBCgAPAhsMBQJaLoRUBQkDwPoDAAoJEGyIV+DY6PB0 XoMP/i+6XvyNE/XsdFgeAO/rtdELWphFUu1HbaKYeh6YMYjg71eR8KbYe2sz3M1Bawj/D7Kb tGRsxFshkLHau0N0cJHEr3U6j/U7sEWCW/YDlWSIyBWYg+j1k/aBczfL/oC9E9h8LOUUjjj3 vpRs2rHmIHT2aAvbRom1d4xaFh1kwn7sUKtc+0AoP5PCeBcfqMduunEPqsfsbmz1Dz+O5FJ7 LRG8YXyV+5YTT1pEuNjFm+GNBEvwhfJqN+H459ngMdZUkCyKwWLAMaJj6y9/ZJ8lrPLCjGDR p9FzhLg39gQqV5Vu41VyBr+9YucX/sWfQ1SuvWDMBnTKSOKX01RAHGvnOmtl3Vr4SqWDhFsO VdWluKugMiIdajKwgM9Bp+35O/l8QQbxxrRAy/TI+dB4w8Urn2oVPkAq8RgYJIzpYYUFnhKD EwcdoG8Lk2EqO60g9UR6tGVsW9/vYvVGHlm0kArIDF9o0zAo5wsuZE9kO4oneoIsCRLwjuZk bqQ+2V+8R3P5YkV8VogwwYPCAhkpGD/ACblux5ip1ilLWFm75Hj3aPkvJSWi5DfkoxzntZBM KrhpyhCKJFUPZovREteTzl8ns3/KvoUJ5VQF3HqXKw49sWrWSDHEugt9ERfCBzAuYl4WB7Qt xwe2q0voV3BFy8kd04NRiyJkBU0BeBHEHblrGY23 Organization: Metacode Message-ID: Date: Fri, 29 Jun 2018 14:55:30 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 12:55:39 -0000 > Well, User IDs are not easier to work with than User Attributes. Leo by "are not easier to work with" did you mean "User Attributes *could be* as easy to work with as UIDs" if you proposal was accepted *and* supported by most OpenPGP software? I think the difference is quite significant (by what is working now vs hypothetical future). If you mean they are easy to work with now do tell me what's that attribute for that I've got on my key (0x653909A2F0E37C106F5FAF546C8857E0D8E8F074): uid [ultimate] Wiktor Kwapisiewicz uid [ultimate] [unknown attribute of size 83] I had a lot of questions about this attribute from other people, so it's not like attributes are currently "easy to work with" in my opinion. Kind regards, Wiktor -- */metacode/* From nobody Fri Jun 29 11:57:36 2018 Return-Path: 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 CEFFE130E14 for ; Fri, 29 Jun 2018 11:57:13 -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_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.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 MVvqcMpcwySc for ; Fri, 29 Jun 2018 11:57:12 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B8C7130E19 for ; Fri, 29 Jun 2018 11:57:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 88944E2049; Fri, 29 Jun 2018 13:03:00 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 03901-02; Fri, 29 Jun 2018 13:02:41 -0400 (EDT) Received: from securerf.ihtfp.org (IHTFP-DHCP-158.IHTFP.ORG [192.168.248.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 1157DE203F; Fri, 29 Jun 2018 13:02:41 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1530291761; bh=qJ9Sui0sgLm8zFW40NzfmyXR8XVddUdjsgPq3AKEsbk=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=P+N0sZiyBUESXqbwv2aRVjYYnxNBVOvr6xEFIoLnhiDq25g8wGlk5EMAUFY7AVLbC 4AXfy34Wwvnklx0QYULvQoVzBN5MBLMgW+44iwfB/ZKjuob3EaxcSp3W5oJ7d2HDLO Ysk/mVfyFtwo61g981IidfiSiuiN+QQ7CkAWN9bw= Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.15.2/Submit) id w5TH2Onv031449; Fri, 29 Jun 2018 13:02:24 -0400 From: Derek Atkins To: Leo Gaspard Cc: openpgp@ietf.org References: <39e598e1-2bc0-32c9-3489-4bb6ca2a631b@leo.gaspard.ninja> <871sdw24yd.wl-neal@walfield.org> <118e5b9d-de9e-aa14-d8b4-19ef259f3d0a@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> <1cacc056-1ec7-f388-ee08-46468bd87bda@metacode.biz> Date: Fri, 29 Jun 2018 13:02:24 -0400 In-Reply-To: (Leo Gaspard's message of "Fri, 29 Jun 2018 21:40:25 +0900") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 18:57:14 -0000 Leo Gaspard writes: > 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=E2=80=A6 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=3Dvalue type (with both tag and value being UTF-= 8). May I point you to the (expired) document, draft-atkins-openpgp-device-certificates which started down the road of adding additional Attribute packets. Would something like that help? -derek --=20 Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Sat Jun 30 05:34:54 2018 Return-Path: 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 E38621310B7 for ; Sat, 30 Jun 2018 05:34:51 -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, URIBL_BLOCKED=0.001] 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 wDYtdqdd2vxY for ; Sat, 30 Jun 2018 05:34:49 -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 95202130DFA for ; Sat, 30 Jun 2018 05:34:48 -0700 (PDT) Received: by smtp.gaspard.ninja (OpenSMTPD) with ESMTP id 01292e8e for ; Sat, 30 Jun 2018 12:34:44 +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=GKMl41qV2rWVrTX5M2Nzb79YraA=; b=FIfvgt+HCNfqFf bUNppXo8wiHJ9uUZUlsxncit2tPd5aciuLov7UkYWesJ9JSawHcs43UAtjtgWtFA u1SlzW5W/dZUfQWWDpghtvcWOpoRCTWz34dIwzXlixT7VDvsOPXDkZw94DA67kM8 EbH5QiPTdDR9e7wsXSHTMJOftxlyw= Received: by smtp.gaspard.ninja (OpenSMTPD) with ESMTPSA id 9317a2fb (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128:NO) for ; Sat, 30 Jun 2018 12:34:44 +0000 (UTC) To: openpgp@ietf.org References: <39e598e1-2bc0-32c9-3489-4bb6ca2a631b@leo.gaspard.ninja> <871sdw24yd.wl-neal@walfield.org> <118e5b9d-de9e-aa14-d8b4-19ef259f3d0a@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> <1cacc056-1ec7-f388-ee08-46468bd87bda@metacode.biz> From: Leo Gaspard Message-ID: Date: Sat, 30 Jun 2018 21:34:37 +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: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2018 12:34:52 -0000 On 06/29/2018 09:55 PM, Wiktor Kwapisiewicz wrote: >> Well, User IDs are not easier to work with than User Attributes. > > Leo by "are not easier to work with" did you mean "User Attributes > *could be* as easy to work with as UIDs" if you proposal was accepted > *and* supported by most OpenPGP software? I should have said “User IDs are not easier to work with than specified User Attributes”, indeed. The fact that the only specified User Attribute is a picture User Attribute, that has little use, is something that contributes to the bad reputation of User Attributes. But User IDs are (binary representation aside) exactly like a User Attribute with type -1 that would be defined as “any UTF-8 string that more or less represents the user”. Once reworded this way, would you still oppose the addition of more well-defined attributes? (NB: this would be for v5 keys, so software would have to be updated anyway, and adding a basic representation for a few UTF-8 User Attributes doesn't sound like the biggest change in the game -- though if User IDs were removed too, as I'd love, then this may be the biggest change, at least for the UI side) All I'm saying is: we should not be wary of defining User Attributes. It's a woefully underused part of the standard, and the fact it's so underused (and specified for a single almost-useless purpose) makes people fear using them. > I think the difference is quite significant (by what is working now vs > hypothetical future). > > If you mean they are easy to work with now do tell me what's that > attribute for that I've got on my key > (0x653909A2F0E37C106F5FAF546C8857E0D8E8F074): > >   uid  [ultimate] Wiktor Kwapisiewicz >   uid  [ultimate] [unknown attribute of size 83] > > I had a lot of questions about this attribute from other people, so it's > not like attributes are currently "easy to work with" in my opinion. Well, using unspecified User Attributes will get you a lot of questions indeed. But if you started putting packets with unspecified tags on your key you likely would break a number of tools too, that doesn't mean packets aren't easy to work with :) BTW, it appears to contain openpgpid+cookie:@https://gist.github.com/wiktor-k/389d589dd19250e1f9a42bc3d5d40c16 This is a typical example of something that would deserve a *specified* User Attribute, like github=wiktor-k (with type “free-form tag=value” and notation “automated-verification-gist=389d589dd19250e1f9a42bc3d5d40c16”) Which would display neatly on platforms that support the very simple type=“free-form tag=value” User Attribute I'm proposing (it's UTF-8), and be quite easy-to-understand to the end-user seeing this if there is no support in their software for the specific “github” tag (at least more than the openpgpid+cookie URL). Actually the “free-form tag=value” is really the most important type of User Attribute I'm putting forward: it is a building block that is enough for almost all other purposes, but that cannot be replicated using only what we currently have without awful hacks (eg. storing type=value directly in the User ID field, which is the “least bad” option with RFC4880 as it is currently defined). From nobody Sat Jun 30 05:43:53 2018 Return-Path: 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 67DDC1310B9 for ; Sat, 30 Jun 2018 05:43:51 -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, URIBL_BLOCKED=0.001] 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 SsyOlByEgSq2 for ; Sat, 30 Jun 2018 05:43:49 -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 F332F130DFA for ; Sat, 30 Jun 2018 05:43:48 -0700 (PDT) Received: by smtp.gaspard.ninja (OpenSMTPD) with ESMTP id abd838c8 for ; Sat, 30 Jun 2018 12:43:45 +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=Z+AjEScd2BzjfFizCKBWqZoCcwA=; b=sVFdiF9qmvtbjR EpxSKQNkZ84VrayJ/DQkQEsv26z66BFPxi/79vW7mHvUE+ah8UeUIYdAaAklsD2X cGg/JyAOx4YKCsLEOiX/KMOCFO6xr+1hPDuTfcOIMvFCFcuzW+lXVk0lR3XlNE8i WBXXNU91ROydDYI/PN5bcicayNNe4= Received: by smtp.gaspard.ninja (OpenSMTPD) with ESMTPSA id 3568deb1 (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128:NO) for ; Sat, 30 Jun 2018 12:43:44 +0000 (UTC) To: openpgp@ietf.org References: <39e598e1-2bc0-32c9-3489-4bb6ca2a631b@leo.gaspard.ninja> <871sdw24yd.wl-neal@walfield.org> <118e5b9d-de9e-aa14-d8b4-19ef259f3d0a@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> <1cacc056-1ec7-f388-ee08-46468bd87bda@metacode.biz> From: Leo Gaspard Message-ID: Date: Sat, 30 Jun 2018 21:43:40 +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: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2018 12:43:52 -0000 On 06/30/2018 02:02 AM, Derek Atkins wrote: > Leo Gaspard writes: > >> 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). > > May I point you to the (expired) document, > draft-atkins-openpgp-device-certificates which started down the road of > adding additional Attribute packets. > > Would something like that help? Indeed, I hadn't seen this! This is adding a User Attribute subpacket type for a reason completely different from the reason I have, and even going a bit in opposition to the movement I was trying to set (which would have led to the definition of a “Device ID” attribute subpacket type that wouldn't “by convention, [include] a mail name-addr”, because that possibly makes no sense, and if it does it can be replicated with “Device ID” + “email” attribute subpackets). But the idea of adding User Attributes that are actually readable by humans is the same, so that they can be easily understood by humans even when using implementations that can't fully handle them (only the bare minimum of displaying UTF-8) :) From nobody Sat Jun 30 09:00:48 2018 Return-Path: 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 C3AAA1310C3 for ; Sat, 30 Jun 2018 09:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ruhr-uni-bochum.de 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 g7XD-yaAQ8IV for ; Sat, 30 Jun 2018 09:00:44 -0700 (PDT) Received: from out2.mail.ruhr-uni-bochum.de (out2.mail.ruhr-uni-bochum.de [134.147.42.229]) (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 59432130F5C for ; Sat, 30 Jun 2018 09:00:44 -0700 (PDT) Received: from mx2.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by out2.mail.ruhr-uni-bochum.de (Postfix mo-ext) with ESMTP id 41Hysj5GPsz4y1C for ; Sat, 30 Jun 2018 18:00:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ruhr-uni-bochum.de; s=mail-2017; t=1530374441; bh=jkxj8R+sPE1NsVzvpeksTesNV05lOakVKLmlW1dGmhA=; h=To:From:Subject:Date:From; b=F2gkurNr6gv5v2jkPlJGCnUlFT8FtJZ81oUpvLgqlwW4kLDjseO4Z2YOjJPifNVgX +DWoUDRTPGcdjwvulU6NTSOcD2eGAuiZ9FQMH3uVtmcl52FXKCIile8AzCvxuoL4Bd Qo/Yj5L93lBUdOwraaADGnCEpalQDP+GRm06CdR0= Received: from out2.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by mx2.mail.ruhr-uni-bochum.de (Postfix idis) with ESMTP id 41Hysj4YN3z4y3N for ; Sat, 30 Jun 2018 18:00:41 +0200 (CEST) X-Envelope-Sender: X-RUB-Notes: Internal origin=134.147.42.227 Received: from mail1.mail.ruhr-uni-bochum.de (mail1.mail.ruhr-uni-bochum.de [134.147.42.227]) by out2.mail.ruhr-uni-bochum.de (Postfix mi-int) with ESMTP id 41Hysj4FBTz4y1C for ; Sat, 30 Jun 2018 18:00:41 +0200 (CEST) Received: from [192.168.142.139] (p4FE3FA2B.dip0.t-ipconnect.de [79.227.250.43]) by mail1.mail.ruhr-uni-bochum.de (Postfix) with ESMTPSA id 41Hysh4zXmzyXy for ; Sat, 30 Jun 2018 18:00:40 +0200 (CEST) To: IETF OpenPGP From: Marcus Brinkmann Openpgp: preference=signencrypt Message-ID: Date: Sat, 30 Jun 2018 18:00:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.4 at mail1.mail.ruhr-uni-bochum.de X-Virus-Status: Clean Archived-At: Subject: [openpgp] AEAD mode chunk size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2018 16:00:47 -0000 Hi, RFC4880bis contains this segment: The chunk size octet specifies the size of chunks using the following formula (in C), where c is the chunk size octet: chunk_size = ((uint64_t)1 << (c + 6)) An implementation MUST support chunk size octets with values from 0 to 56. Chunk size octets with other values are reserved for future extensions. This allows chunk size up to 2^(6+56) = 4 EiB. It is impossible to implement AEAD correctly with chunk sizes larger than can be buffered in RAM. A large chunk size would require output of unverified plaintext, enabling attacks like EFAIL but also others. To implement AEAD correctly, chunk size must be limited to reasonable sizes. TLS uses a chunk size up to 2^14 (16 KiB), but any reasonable limit will do, for example 64 KiB. I suggest to change the text to this: The chunk size octet specifies the size of chunks using the following formula (in C), where c is the chunk size octet: chunk_size = ((uint64_t)1 << c) An implementation MUST support chunk size octets with values from 0 to 16. Chunk size octets with other values are reserved for future extensions. Thanks, Marcus Brinkmann From nobody Sat Jun 30 09:10:16 2018 Return-Path: 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 18865130E6E for ; Sat, 30 Jun 2018 09:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ruhr-uni-bochum.de 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 65ikroWgsa9v for ; Sat, 30 Jun 2018 09:10:13 -0700 (PDT) Received: from out2.mail.ruhr-uni-bochum.de (out2.mail.ruhr-uni-bochum.de [134.147.42.229]) (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 EFBCC127148 for ; Sat, 30 Jun 2018 09:10:12 -0700 (PDT) Received: from mx2.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by out2.mail.ruhr-uni-bochum.de (Postfix mo-ext) with ESMTP id 41Hz4g423wz4yGK for ; Sat, 30 Jun 2018 18:10:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ruhr-uni-bochum.de; s=mail-2017; t=1530375011; bh=RI8NM21dzdM/n916LKaiwWPUU/O35GcUIwuF1q8JIBc=; h=To:From:Subject:Date:From; b=Sd+5AtoYJ3bp9GNueilZbOIu7CbQZ8JjCTWV9l+WLoAlwi5KKZ2xc3HyqPLXwrqJz yeXfCgUP3aOyInfAamAGvVclhrW3HDTsPNnUO9Lvnn5w5m0MQLPY3g6iM8TCOAq1/h MzQoiCY3MXX/VbE1mDtIKzpuZSNInhk8fmvc7dtY= Received: from out2.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by mx2.mail.ruhr-uni-bochum.de (Postfix idis) with ESMTP id 41Hz4g3DH1z4yJP for ; Sat, 30 Jun 2018 18:10:11 +0200 (CEST) X-Envelope-Sender: X-RUB-Notes: Internal origin=134.147.42.227 Received: from mail1.mail.ruhr-uni-bochum.de (mail1.mail.ruhr-uni-bochum.de [134.147.42.227]) by out2.mail.ruhr-uni-bochum.de (Postfix mi-int) with ESMTP id 41Hz4g2sMpz4yGK for ; Sat, 30 Jun 2018 18:10:11 +0200 (CEST) Received: from [192.168.142.139] (p4FE3FA2B.dip0.t-ipconnect.de [79.227.250.43]) by mail1.mail.ruhr-uni-bochum.de (Postfix) with ESMTPSA id 41Hz4g0JrDzyYl for ; Sat, 30 Jun 2018 18:10:11 +0200 (CEST) To: IETF OpenPGP From: Marcus Brinkmann Openpgp: preference=signencrypt Message-ID: Date: Sat, 30 Jun 2018 18:10:10 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.4 at mail1.mail.ruhr-uni-bochum.de X-Virus-Status: Clean Archived-At: Subject: [openpgp] AEAD mode unverified chunks X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2018 16:10:15 -0000 RFC4880bis should clarify that unverified plaintext must not be output in AEAD mode. I suggest adding this sentence: 5.16 AEAD Encrypted Data Packet (Tag 20) [...] If a chunk can not be authenticated, implementations MUST discard the plaintext without further processing. Unauthenticated plaintext MUST not be output to other applications or the user. From nobody Sat Jun 30 23:54:00 2018 Return-Path: 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 8A39F130E77 for ; Sat, 30 Jun 2018 23:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 nEUKfXPeM3zM for ; Sat, 30 Jun 2018 23:53:55 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (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 9BC22130F01 for ; Sat, 30 Jun 2018 23:53:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1530428034; x=1561964034; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ccafiXUXBzbRKURkc0EwmSX/4sgTkIGypcg32Az0+jg=; b=SPRlZcqCwi3XZrmgzp7DcYWap5H1MTmF4/HWJwnVmU7SYzImsRL3H/LC Gwg3DAvRw4s5etjeqBw1bHNwj0FSR+2hudKdauGYHqSRvSJcwHsI3vpeQ dP7KXw9IRCG1i2Y0ghOeV94x714Fffd+Tlun5xnBbsA9HSvGcRKuOr9kj KfnHcy3QYfinj6RRSbNND/E4UQBkxDctPNpcA8i2VcWUyypfKLNVt4TRX 8jnUWWZucbaPV4zr7UxZhcuwyKLyM3FF//zAVEtVwAk7mUIxPqV+5OOIx LStUOUYDW8zGXzA23TjUI7p18Q6NJ8RCCZGnhszoQ0Wu8uL4eDdRTLW0T w==; X-IronPort-AV: E=Sophos;i="5.51,293,1526299200"; d="scan'208";a="18929156" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.2 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-ogg-a.UoA.auckland.ac.nz) ([10.6.2.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 01 Jul 2018 18:53:47 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) by uxcn13-ogg-a.UoA.auckland.ac.nz (10.6.2.22) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 1 Jul 2018 18:53:46 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::ccab:7bf5:3d4a:aed8]) by uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::ccab:7bf5:3d4a:aed8%14]) with mapi id 15.00.1263.000; Sun, 1 Jul 2018 18:53:47 +1200 From: Peter Gutmann To: Marcus Brinkmann , IETF OpenPGP Thread-Topic: [openpgp] AEAD mode unverified chunks Thread-Index: AQHUEIzhW94Nj+WvxkKsWz4Icn2RHaR571i4 Date: Sun, 1 Jul 2018 06:53:46 +0000 Message-ID: <1530428015814.83795@cs.auckland.ac.nz> References: In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [openpgp] AEAD mode unverified chunks X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jul 2018 06:53:58 -0000 Marcus Brinkmann w= rites:=0A= =0A= >If a chunk can not be authenticated, implementations MUST discard the=0A= >plaintext without further processing. Unauthenticated plaintext MUST not = be=0A= >output to other applications or the user.=0A= =0A= Unfortunately it's nowhere near as simple as that, in general, this is an= =0A= unsolveable problem. See:=0A= =0A= https://tools.ietf.org/html/rfc6476#section-6=0A= =0A= for a discussion.=0A= =0A= Peter.=0A=