From nobody Sat Jul 6 06:39:48 2019 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 D42291201D3 for ; Sat, 6 Jul 2019 06:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NONE=0.001] 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 K-xOmDN95nFV for ; Sat, 6 Jul 2019 06:39:44 -0700 (PDT) Received: from thumb.scru.org (thumb.scru.org [IPv6:2600:3c00:e000:227::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2FB41201CA for ; Sat, 6 Jul 2019 06:39:43 -0700 (PDT) Received: by thumb.scru.org (Postfix, from userid 1000) id C45B04332A; Sat, 6 Jul 2019 13:39:41 +0000 (UTC) Date: Sat, 6 Jul 2019 13:39:41 +0000 From: Clint Adams To: Daniel Kahn Gillmor , 931238@bugs.debian.org Cc: openpgp@ietf.org Message-ID: <20190706133941.tw3znn74q4iseiyo@scru.org> References: <87zhm1o0f7.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87zhm1o0f7.fsf@fifthhorseman.net> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [openpgp] Bug#931238: hot armor: please drop "Version: " header X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2019 13:39:46 -0000 On Fri, Jun 28, 2019 at 05:38:36PM -0400, Daniel Kahn Gillmor wrote: > "hot armor" currently adds a comment line to its enarmored content: > > Version: hot 0.21.3 > > Best practices these days omits indicators of what particular OpenPGP > implementation is in use. Please do not emit it by default! Should rfc4880bis deprecate this? From nobody Sat Jul 6 06:55:31 2019 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 EEA2B1201D3 for ; Sat, 6 Jul 2019 06:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 0rjJh3wPFe-3 for ; Sat, 6 Jul 2019 06:55:27 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 E6D4B1201D0 for ; Sat, 6 Jul 2019 06:55:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1562421323; bh=CLouN9J0hhFup6F8UPjBVadX0uW8gse4EN3cLt55bow=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=iu+3oWOlqDIEJqhPCtWWi3CqCIhFliLEKZpI7pz80d/Mi0cQkrWRFF+U331PRKzIm R7U83Erb5SH5lMAhTeREz9O+79LUJLWdIPujH+a/K/NJMOVCMK7arqKEcYbei5/tPq 3z/Aj0bfRCFlBWAdIdOAmCiWReZV1okWijif9gBE= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.24] ([87.171.251.7]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Ls8Qd-1iVmHU0WQZ-013reb for ; Sat, 06 Jul 2019 15:55:23 +0200 To: openpgp@ietf.org References: <87zhm1o0f7.fsf@fifthhorseman.net> <20190706133941.tw3znn74q4iseiyo@scru.org> From: Heiko Stamer Openpgp: preference=signencrypt Autocrypt: addr=HeikoStamer@gmx.net; prefer-encrypt=mutual; keydata= mQGiBDdYKNkRBACRdsFzaQn0HChOX38WHXlIYcNZAAxBQxa7gdmPXTUK+tgwQuwAr/XViQxn ExKwyOteRhwHZNSYdoKPlCOJ3c3FWCKAdflINr53NvN/qnnaF+3M1HaluiwVdfHD9a0+k7fd NFZMq2bTpzSCQBsPGipSK0K8ET8UPrXm54pXhqYL2wCgsuMBOv64bmg2zjg6vHSTKADGykcD /Agjoa7y7Cpifk4WEKDKu8nlrE9OFOJppjZ9bdJedrmZq5A/jHr35UOgbZItTmgBiz7bfMLq 7HD05ZQ3BplBmmiE0412f55GadCjN4vvnCdTqZ/ewzWdz/rzQGaJm9IvW6rupuFgrTx0GJhf we7cr6GQQo0nqA0LMCyhGHQASC56A/9NOroBzLM6wl9QlE9lybxd3cxI2UnrfHIu63tklFKF vL1XnjyJ4YR0sDs6/f56JbtEGUKTCI7ZAw+241Va4MrbDVmmsGJjQBcKxNbHDfkkjoJ9NBwr pUo2nMT3BWyKHCfnMqoyT+nN04b0Em1ffbhptKiLJSeY1mcPxvA1h7PrKbQiSGVpa28gU3Rh bWVyIDxoZWlrb3N0YW1lckBnbXgubmV0Poh4BBMRAgA4AhsDAh4BAheAFiEEdvcwETKdJ9uN fD+XT1hOuPsr4U8FAlzqvfMFCwkIBwIGFQoJCAsCBBYCAwEACgkQT1hOuPsr4U8jZQCfbz7N emwAJ2OdrBP9mmsySktb4IQAnRWJOYy4bH3R42nh6KCUkbDXQoNhuQMNBDdYKtkQDACuGU2S WXmjpoyGIX/UHze60OolxBdtKzhvDZHhy1Sz8NNrdkI3ozuYOMxkKZZLTw/iQigVNQfwy+5f AUw6KaH8OPnwInqyeguI6PwG0qQK2cWlSTZDlTW8B2D3Qpjt8sYnnjGEIGKGb7ZAUgODmWYd sS35otyEQT0Un/kRIqjyQcvWgNH++t+LypXUxu0eD0dlD/kx46TP9kqTYsr/8vWWhD2J98x0 ZFrFMN8QDCIhO9x3p+qPyfSiAdnuI4iN1RYsKtC2ikb+cIc5bYysnRots1anAy3Pd5Q8bFtj lzxPPRh90v/Yq5RM/3IgbsbS0zDI0ldznld+DInezLs/EROsITmmbXrhIAHC8TjcXtxWR3ht nFLnIgmQ3Rag0bQesNF4Y5bXSGcw/MxwWcm6EXwcbm7Uc64k8YxXMYyNy+XX/bi1o7r5JdH0 mKUFeXTF9WLrNpF4jBylHk1RNDbR6kp6M87vPJeg/nQh19ItQQxYJGYu9KBhBGhFtDUIAyLT nTcAAwUL/2tHe52rFeCVvZo7RZ5SQy/aclx7hnPsvb3yTXcvg5c7hweOL7Zfsh/XnE3acRO0 YAfGb0LxMFJlfpHgcPuTZEd5rPgJz68GccACBPw8Z8MgQEBE5H/UiAR/HM9AQmEN+wfjeDlv 6ZGElmnY59gYIuCGUVsqw5pwCCsLBs3xlMTyCiNwDHERRao3YTGhaNy9hsCdqNHQcXdSzdF6 OtvfMnXI67QGyiNcbjVwXwQHlGAsxo4O3FMOl138o1Oa00JMSk7td8bClMAp7Hu4zrw533TZ 2Avp+6OFjUAQ4U4hdEDGePNm2hbQinKnUCd30PboqIdZDmYq4SSeNMbWKwy3Etx/a0GX39F/ gnjmveBHSWGGB+wSKcrK3yfXNXMa4OW683m/aH1msS0L0SFwbm2w7XdALp0DCV031x1JoGAn c0mVcstbVM7KNUGnCOA9D4USKHrj/IoZVoapx0b+bWPFHtfLhcm2lSDlq7F140DlQVL1xZmA nPcpLyXMmEmnS2JCZYhGBBgRAgAGBQI3WCrZAAoJEE9YTrj7K+FPcRMAnige4x75lK1p7sbK sdhZb6tv4CJPAKCpDqRn9o7nfvLlouXNaIR1nri7cw== Message-ID: <54525144-b7bf-fa79-c497-ca8fbf77f89d@gmx.net> Date: Sat, 6 Jul 2019 15:55:06 +0200 MIME-Version: 1.0 In-Reply-To: <20190706133941.tw3znn74q4iseiyo@scru.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:nFnwxmvIpnrJtodI4xt69soElOntDVlW0Dxe6xhbMU0oDuGHnZl v3W4lBwnPueoy4JZeBCnVVSCOnBgzdp8BrTn+co0/Z+LfN96dm4i+tpLjnd74wzN52UzZFO 4Qy4HjQUy/iORU5OXbp+sDVA4wBM9qGLWB/fD5f1BqHO5AohakrO+zezH/tIuRi9gvPPEZ/ ekufxbGJDK2kZEVEoZXsQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:iN/w+z6EJsY=:peKvwXZ6LJ6o2mferPtIi8 k0H4y36FA0vdUwb09FmD05croZol0f8Ox4tuNvtIyN3X2VkNgQ/CB8lx3zXrLg/mtvZomPr1F abWWXYDXUkdk5sltHR/ETYfAAbQJxMmef2z0A8EBCIW2yxAAv1u+H/XXD2Ht+FpAKq1YBt5b5 N8cn9BkiJRF6g0bXhjiH2fvBTjeu9ATGt4aCgSN9ZO7PqG4KXQ9viytUyM7k5d0ZGkEPa5WL7 PwH4lSFtc0eyzlwgZNbRaBAPDU5N3Oj63OOKGdEBoxqvljP8C4Rt22U8xDiHwFoW8vXuY06w2 jBs93ATLGiQ7fr+M3Ss9R6TXX966SzfZ1gv9IUf9LpPmWxS3Rj+xJ0kL6o+U1dyVeJq0X11Ex Nm/t8cz3EqsffWHk1C9U3HO2dRDInlyRadkiWfA+4Q+VCuArfnng374KNuMXZ1twmrkrue/46 W7hZqV2tBeDrgXEcLtOaiptR0QX41Ychqj0VHiKmYj5l57oq2NwKOycrwgcyNCY5zE1zoDAD5 kh9VS6FkXJrEiQRK+PbDXpi7Tz3JTRjuSsXyOvH9sbtAwe/xJe0ndb8LDhII6X4hyw5lKPzuj F9yac8wKswvVBoSd2AKfbS41QI/ZrVKL+yF4+uRgDdqTZi7OPqAs/r/vtTyghy0De9LLqs55B ZJ9/LFfUKVqXaqmh+JpK2yqwyY62uFWt0+rqXEVF7W0CzDrGcnzYOXs+T9xG33Va0hHuNv5L5 kAU4nLgGQEI0KxqKIyprP9LU1Z1xwfXf6C0EMSNKa+v5EqtIu8rw1Gc6OusrUjnmcJulTGtVa GCJQW+ekhn2Fzy380Pl/44eINi8BvO4PCcunhJhRvuvqrcBS4FzS09tJOSAz6zNvYOLpn60Xh IuEu/yGjEo97N9agtN9jXmQXuVzh9CefFk5sACVi1m/+NhiZq/uim0Jhw8wGeSCTbR9qWcpkL VBadYlRUn4JjczCnltNMeTg+BgyEX0iFF0llrsHIN2x7xY26zYmMmiSguBDHM8wOu08h8ypLV us27NeZmwG7dadc8UodR1Dz2hBW4awSoE5h2Fv8TEX/lEn6GN5wul7tWZwNSU1JgnoJvCNMtC LCipJG8u4enC0xZ7x8GixTbm7WLiff1B/dC Archived-At: Subject: Re: [openpgp] Bug#931238: hot armor: please drop "Version: " header X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2019 13:55:29 -0000 On 06 July 2019 at 15:39, Clint Adams wrote: > On Fri, Jun 28, 2019 at 05:38:36PM -0400, Daniel Kahn Gillmor wrote: >> "hot armor" currently adds a comment line to its enarmored content: >> >> Version: hot 0.21.3 >> >> Best practices these days omits indicators of what particular OpenPGP >> implementation is in use. Please do not emit it by default! > > Should rfc4880bis deprecate this? There are many other indicators of a particular OpenPGP implementation (e.g. DKGPG uses four-octet packet lengths). If a somehow uniform encoding is desired, then IMO a new section "Privacy Considerations" should be added to rfc4880bis. =2D- Heiko From marcus.brinkmann@rub.de Sat Jul 6 16:56:26 2019 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 8006712010C for ; Sat, 6 Jul 2019 16:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rub.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 ATqYgU0Mf6F3 for ; Sat, 6 Jul 2019 16:56:23 -0700 (PDT) Received: from out3.mail.ruhr-uni-bochum.de (out3.mail.ruhr-uni-bochum.de [IPv6:2a05:3e00:8:1001::8693:359b]) (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 2A4201200FD for ; Sat, 6 Jul 2019 16:56:23 -0700 (PDT) Received: from mx3.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by out3.mail.ruhr-uni-bochum.de (Postfix mo-ext) with ESMTP id 45h7sH2pyKz8S9C for ; Sun, 7 Jul 2019 01:56:19 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=rub.de; s=mail-2017; t=1562457379; bh=mtXSpmYn2TiOZW0Om7SJru/AFHTiOQbi0jlxetQ8qXQ=; h=Subject:To:References:From:Date:In-Reply-To:From; b=FRbjRqtvtpTsU4NynXQW+gmCCSP64HMNViErtRsEbZ9AwrFil49SsE82eJz7n+Kff UNXLPXtggVSCWmg8jJ/iPx/BUmqG53ViVQC3kYCPrYF7f26MfZKhacmYZd99IeRJGJ vKPbHa49uZHMe24kCKeMniUnDOwmUABiNQk5/vHc= Received: from out3.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by mx3.mail.ruhr-uni-bochum.de (Postfix idis) with ESMTP id 45h7sH1LNfz8S73 for ; Sun, 7 Jul 2019 01:56:19 +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 out3.mail.ruhr-uni-bochum.de (Postfix mi-int) with ESMTP id 45h7sH0SSgz8S3b for ; Sun, 7 Jul 2019 01:56:18 +0200 (CEST) Received: from [192.168.142.139] (p5DCA4A43.dip0.t-ipconnect.de [93.202.74.67]) by mail1.mail.ruhr-uni-bochum.de (Postfix) with ESMTPSA id 45h7sH0mdBzysc for ; Sun, 7 Jul 2019 01:56:19 +0200 (CEST) To: openpgp@ietf.org References: <87zhm1o0f7.fsf@fifthhorseman.net> <20190706133941.tw3znn74q4iseiyo@scru.org> <54525144-b7bf-fa79-c497-ca8fbf77f89d@gmx.net> From: Marcus Brinkmann Openpgp: preference=signencrypt Message-ID: <8d960bb1-0fe8-c2e3-fcf4-4d00ed4adfce@rub.de> Date: Sun, 7 Jul 2019 01:56:19 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <54525144-b7bf-fa79-c497-ca8fbf77f89d@gmx.net> 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: X-Mailman-Approved-At: Sun, 07 Jul 2019 11:31:08 -0700 Subject: Re: [openpgp] Bug#931238: hot armor: please drop "Version: " header X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2019 18:08:22 -0000 That seems almost like a bottomless pit. Some thoughts (not meant to be exhaustive): For messages: 1. The embedded timestamp and filename in a literal data packet. 2. The block sizes for partial data packets, and when they are used. 3. The signature subpackets used and their order (hashed and unhashed). 4. Possibly the details of the compression. 5. The length of the base64 encoding. 6. Potentially the order of signature packets. 7. The value of any quick check bytes (some implementations set them to invalid values to discourage checking them). For keys: 1. Again the signature subpackets used and their order. 2. Potentially the details of the user id. 3. Algorithm and other preferences and flags. 4. The cryptographic parameters of public keys (RSA exponent etc) 5. S2K count. 6. Possibly resolution of any timestamps. On 7/6/19 3:55 PM, Heiko Stamer wrote: > On 06 July 2019 at 15:39, Clint Adams wrote: > >> On Fri, Jun 28, 2019 at 05:38:36PM -0400, Daniel Kahn Gillmor wrote: >>> "hot armor" currently adds a comment line to its enarmored content: >>> >>> Version: hot 0.21.3 >>> >>> Best practices these days omits indicators of what particular OpenPGP >>> implementation is in use. Please do not emit it by default! >> >> Should rfc4880bis deprecate this? > > There are many other indicators of a particular OpenPGP implementation > (e.g. DKGPG uses four-octet packet lengths). If a somehow uniform > encoding is desired, then IMO a new section "Privacy Considerations" > should be added to rfc4880bis. > > -- > Heiko > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > -- Dipl.-Math. Marcus Brinkmann Lehrstuhl für Netz- und Datensicherheit Ruhr Universität Bochum Universitätsstr. 150, Geb. ID 2/461 D-44780 Bochum Telefon: +49 (0) 234 / 32-25030 http://www.nds.rub.de/chair/people/mbrinkmann From nobody Sun Jul 7 13:29:25 2019 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 3E2B61200B4 for ; Sun, 7 Jul 2019 13:29:00 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=R3HEYamf; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=HxlFoqYQ 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 zOE_YKmWydZn for ; Sun, 7 Jul 2019 13:28:58 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFDDD12008F for ; Sun, 7 Jul 2019 13:28:57 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1562531336; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=ApFxaoForyqPQCVivS4NF2o1mVYlTussv2Ui9q/O2I4=; b=R3HEYamf9ktrnyo1MWi/z1vWIePV3jGDhSULKiSz5XuK0aUe4Jm0dj1L iN95B/MxrFCLd7dADAdvCC0mDXiiDg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1562531336; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=ApFxaoForyqPQCVivS4NF2o1mVYlTussv2Ui9q/O2I4=; b=HxlFoqYQ2kIx0oPyCQOntTgszTowIjjIWeWZ5l0s4jfNLtOmauLXa29K MXgT+hxtSkiku3eJ7eqV0U9dchpEZSlfuzSRriJ7ESFReBPmR4fJSk4f9m ULW4K7F4UulPjH/THSaRD0iDdys/UYLABkYwGkIN1yCyjqFh6vCbGlL77M rfU37tN4qml1NJwPGJ3I5LAMXAykWIx7F4ezXFo3OX64ZLtxGAJlAGBWkf zfDNbtUROlQb/WfccOm2skmFje1eJgHZMVaXeOFas/ZwSzKVW7s8MtzHy0 IWAInIi9+CQ8nTigQtceN53sWNcQ8ki+kp3XP1sDqv683w1aKe/rgA== Received: from fifthhorseman.net (unknown [IPv6:2001:470:1f07:60d:5cf3:eff:fee2:4b88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 4FA69F9A2; Sun, 7 Jul 2019 16:28:55 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id CEFDE20A70; Sun, 7 Jul 2019 16:23:19 -0400 (EDT) From: Daniel Kahn Gillmor To: Marcus Brinkmann , openpgp@ietf.org In-Reply-To: <8d960bb1-0fe8-c2e3-fcf4-4d00ed4adfce@rub.de> References: <87zhm1o0f7.fsf@fifthhorseman.net> <20190706133941.tw3znn74q4iseiyo@scru.org> <54525144-b7bf-fa79-c497-ca8fbf77f89d@gmx.net> <8d960bb1-0fe8-c2e3-fcf4-4d00ed4adfce@rub.de> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Sun, 07 Jul 2019 16:23:19 -0400 Message-ID: <87r2717fwo.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] Bug#931238: hot armor: please drop "Version: " header X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2019 20:29:03 -0000 --=-=-= Content-Type: text/plain On Sun 2019-07-07 01:56:19 +0200, Marcus Brinkmann wrote: > That seems almost like a bottomless pit. Totally agreed, fingerprinting surfaces are a drag. Nonetheless, the people best equipped to enumerate them are the folks with domain-specific knowledge, like you've done here. Thanks for starting up a list. You're basically identifying places where implementers have a non-obvious choice to make when generating OpenPGP constructs. Perhaps the right form for this guidance would be text that says what reasonable implementations should do. I'll propose a few below: > 1. The embedded timestamp and filename in a literal data packet. I'm not sure how these would vary across implementations. perhaps the guidance should say "in the absence of a requirement to the contrary, the timestamp should be set to zero and the filename should be zero octets in length." > 2. The block sizes for partial data packets, and when they are used. Partial data packets SHOULD NOT be generated. In the event that they are generated, partial data packets SHOULD have a length represented by the value 236 (meaning, the packet has a length of 1<<(236&0x1F) == 4096 octets). > 3. The signature subpackets used and their order (hashed and > unhashed). Which hashed subpackets to use: i'm not sure about this. suggestions? order: Implementations SHOULD emit signature subpackets in subpacket type order. If multiple subpackets of a given type are present, they SHOULD be ordered based on the binary representation of the subpacket. (0x01ffff comes before 0x020000, etc). Implementations SHOULD NOT emit unhashed subpackets without a concrete reason to do so. > 4. Possibly the details of the compression. Implementations SHOULD NOT generate compressed packets. If they do, they should prefer Bzip2 over Zlib over ZIP. (is this right? what about per-format compression details? > 5. The length of the base64 encoding. I think this means line length. Implementations SHOULD generate Radix-64 data encoded such that all full lines have 64 printable characters in them. > 6. Potentially the order of signature packets. I'm assuming this is about signature packets over a data, not user ID certifications or subkey signatures. If multiple signature packets are attached to a piece of data, they SHOULD be ordered by their creation date (oldest signature first). If multiple signatures share the same creation date, they SHOULD be ordered by their binary representation. > 7. The value of any quick check bytes (some implementations set them to > invalid values to discourage checking them). That's news to me, thanks for raising it. Can you point to documentation about that? > For keys: > > 1. Again the signature subpackets used and their order. Same as above, i think. > 2. Potentially the details of the user id. as most of this is entirely user-visible (and user-selected), i'm not sure how much implementations can do here. Perhaps we should recommend using Unicode canonicalization form C for the UTF-8 string though? > 3. Algorithm and other preferences and flags. These compatibility markers will invitably leak some information about the local implementation, as they are needed for interoperability. We can provide guidance on the ordering of those preference though. > 4. The cryptographic parameters of public keys (RSA exponent etc) The chosen RSA exponent SHOULD be 0x10001. (suggestions for other parameters for other pubkey algorithms welcome!) > 5. S2K count. Modern hardware is fast. Implementations that emit an S2K packet SHOULD use Iterated + Salted S2K, and the S2K count SHOULD be 65011712 (single-octet representation 255). > 6. Possibly resolution of any timestamps. Isn't the specification's 1-second resolution reasonable? Do we want to encourage something different? One other item for OpenPGP certificates ("keys")" 7. order of certification packets, order of user ids, etc: I proposed a canonicalized structure for OpenPGP certificates over here: https://dev.gnupg.org/T3389 Perhaps this should be a supplementary implementator guidance draft, distinct from the specifying RFC? Then we could also update it as new fingerprinting surface is discovered, without revising the RFC itself. Anyone interested in starting a draft? --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXSJUtwAKCRB2GBllKa5f +GQ5AQCMfw3JuciOBGwx8CMK6iFOKQpI3BPrqhtMb6auMzeWugD/cE7d7q+WBkVX xcIBRVp3b3JrgBZWaH9JzmFReZhW9Qo= =cra+ -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jul 7 13:36:15 2019 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 05F7F120254 for ; Sun, 7 Jul 2019 13:35:56 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=U/brRc8J; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=bsB4SPF5 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 zmKvQp_E8enM for ; Sun, 7 Jul 2019 13:35:54 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77C56120219 for ; Sun, 7 Jul 2019 13:35:54 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1562531336; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=dKYijZPOvQKhMp2sFprvRZSH44gGFUQuHSxffDuv/cM=; b=U/brRc8JFST+1d/yfaBKx3jH19DXH8hQFQXs5lfUmIVDTyFXVMm7D6CW tj05RPRE9X/IVuAnnz5u1doPv/cDDg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1562531336; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=dKYijZPOvQKhMp2sFprvRZSH44gGFUQuHSxffDuv/cM=; b=bsB4SPF5heJpW6XLj5WCjrwqjucu99LOgaUnn9uttYjaSq+lZ56NqSt4 S+pQdqJgKsehvf9vsODsnGbKFCyqfbI6FjICueCASOilVo2DuQZFvdZDfP 5cHno1Cw8zr2c17c1CNVMynytQmSR6C/bNKaYFhFqXQ0IDfUDAAhAuK1ea yytHfn41Z/9lvCOmhr+pcprfDjI7LbBa8dzdkHRNdp7aFE5coZ5ICYyV4q etLQ+FrWAAVQDYAyKiKTQ3YwhXUIbfn6ndkX4yh9nQjbpHwQCB3Bbmq7Yr nwKez6mvg6rpP0E9F6kQwpdu70rezIjq426ftxtiUJU9wFbyAHC0kA== Received: from fifthhorseman.net (ool-6c3a0662.static.optonline.net [108.58.6.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 22AEDF9A1; Sun, 7 Jul 2019 16:28:55 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 16917203C1; Sun, 7 Jul 2019 08:22:45 -0400 (EDT) From: Daniel Kahn Gillmor To: Heiko Stamer , openpgp@ietf.org In-Reply-To: <54525144-b7bf-fa79-c497-ca8fbf77f89d@gmx.net> References: <87zhm1o0f7.fsf@fifthhorseman.net> <20190706133941.tw3znn74q4iseiyo@scru.org> <54525144-b7bf-fa79-c497-ca8fbf77f89d@gmx.net> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Sun, 07 Jul 2019 08:22:44 -0400 Message-ID: <87tvby6nl7.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] Bug#931238: hot armor: please drop "Version: " header X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2019 20:36:14 -0000 --=-=-= Content-Type: text/plain On Sat 2019-07-06 15:55:06 +0200, Heiko Stamer wrote: > There are many other indicators of a particular OpenPGP implementation > (e.g. DKGPG uses four-octet packet lengths). If a somehow uniform > encoding is desired, then IMO a new section "Privacy Considerations" > should be added to rfc4880bis. totally agreed that this should be added, and i encourage you to send text to the openpgp@ietf.org mailing list. This should not block the removal of the Version: header from the output of "hot armor", though. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXSHkFAAKCRB2GBllKa5f +Fj9AQCp+MP+jlA7SzssZRwYZY1HBgINUefGrE6cVpqHozE7kAEApyPSL2A+Rg+W 0D2hbcn67mGeHyhE5FLR/soEPyZyIQ8= =r8fq -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jul 7 18:42:18 2019 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 313561202FC for ; Sun, 7 Jul 2019 18:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 R4YEdhyFO-1Y for ; Sun, 7 Jul 2019 18:42:12 -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 CE3BB1200B7 for ; Sun, 7 Jul 2019 18:42:10 -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=1562550132; x=1594086132; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=pu5kdB2zKJci8g26DFFXl53leev+JJyxFOUEvUNFGmI=; b=f3BUtEk/0XUpwYfla/UVmIwTrAd94uEwe5lyyTUE/NYfoUIAh4YAwPta HdYV43old3OVpGzlTdCpQZS+ERlWZRmZd5lA43RmZ4iDc+9RxBbfsZS2g L+BT2bnSqXKCHI1/MBXqnn/PYYr9afXahfT2VnjLVr83TB/xY59oFx+BL 8ML7wbftDC3eAOaXHkcHRfRdOonU2tcKwzR4iNL9v/UhaSzwdCMYA7Tm9 1AHFo1VluMLp6R5a3O+Iq1Kfz/pDmOfhwrYPNs3i3eK9QCLGbIA0uZgVy 96sp9qT5w8nHcsTmjsJn2UQqYgD/TKmOrYRcyCDatvEa9IVNlTlPPbWof Q==; X-IronPort-AV: E=Sophos;i="5.63,464,1557144000"; d="scan'208";a="69730030" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.5 - Outgoing - Outgoing Received: from uxcn13-tdc-d.uoa.auckland.ac.nz ([10.6.3.5]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 08 Jul 2019 13:42:06 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 8 Jul 2019 13:42:06 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Mon, 8 Jul 2019 13:42:06 +1200 From: Peter Gutmann To: Marcus Brinkmann , "openpgp@ietf.org" Thread-Topic: [openpgp] Bug#931238: hot armor: please drop "Version: " header Thread-Index: AQHVNABf9gFVsbkKWUCVNeGRYih4Bqa806oAgACn+oCAAnjnvQ== Date: Mon, 8 Jul 2019 01:42:05 +0000 Message-ID: <1562550125588.27272@cs.auckland.ac.nz> References: <87zhm1o0f7.fsf@fifthhorseman.net> <20190706133941.tw3znn74q4iseiyo@scru.org> <54525144-b7bf-fa79-c497-ca8fbf77f89d@gmx.net>, <8d960bb1-0fe8-c2e3-fcf4-4d00ed4adfce@rub.de> In-Reply-To: <8d960bb1-0fe8-c2e3-fcf4-4d00ed4adfce@rub.de> 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] Bug#931238: hot armor: please drop "Version: " header X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 01:42:18 -0000 Marcus Brinkmann writes:=0A= =0A= >That seems almost like a bottomless pit. Some thoughts (not meant to be= =0A= >exhaustive):=0A= =0A= Thanks, saved me typing all that. If it's going to be done as an RFC, it= =0A= needs to come with a warning that at best any countermeasures are going to= =0A= stop simple-minded fingerprinting, but not anything very advanced.=0A= =0A= Also if it's going to be done as an RFC then it should state what threat al= l=0A= this will be defending against. "An attacker knowing that you're running o= ut-=0A= of-date software" barely qualifies as a threat - they can just try and atta= ck=0A= you anyway - and I can't see what other purpose it serves.=0A= =0A= Peter.=0A= From nobody Mon Jul 8 03:49:06 2019 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 6F06C120152 for ; Mon, 8 Jul 2019 03:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] 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 M2drck9h_rxF for ; Mon, 8 Jul 2019 03:49:00 -0700 (PDT) Received: from smtpin.nadir.org (fry.nadir.org [217.114.68.218]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 098DD12014F for ; Mon, 8 Jul 2019 03:48:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtpin.nadir.org (Postfix) with ESMTP id 5ACB57CAAA5; Mon, 8 Jul 2019 12:48:56 +0200 (CEST) Received: from smtpin.nadir.org ([127.0.0.1]) by localhost (fry.nadir.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-AqMHU6r086; Mon, 8 Jul 2019 12:48:56 +0200 (CEST) Received: from snail.zeromail.org (mail.zeromail.org [217.114.68.185]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpin.nadir.org (Postfix) with ESMTPS id 203CD7CA980; Mon, 8 Jul 2019 12:48:56 +0200 (CEST) Received: from [127.0.0.1] (localhost [127.0.0.1])ng TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by snail.zeromail.org (Postfix) with ESMTPSA id 676C1BFE19; Mon, 8 Jul 2019 12:48:55 +0200 (CEST) Date: Mon, 8 Jul 2019 12:48:52 +0200 From: ilf To: openpgp@ietf.org Cc: 931238@bugs.debian.org Message-ID: <20190708104852.GH1362@zeromail.org> Mail-Followup-To: openpgp@ietf.org, 931238@bugs.debian.org References: <87zhm1o0f7.fsf@fifthhorseman.net> <20190706133941.tw3znn74q4iseiyo@scru.org> <54525144-b7bf-fa79-c497-ca8fbf77f89d@gmx.net> <8d960bb1-0fe8-c2e3-fcf4-4d00ed4adfce@rub.de> <1562550125588.27272@cs.auckland.ac.nz> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="jRdC2OsRnuV8iIl8" Content-Disposition: inline In-Reply-To: <1562550125588.27272@cs.auckland.ac.nz> Archived-At: Subject: Re: [openpgp] Bug#931238: hot armor: please drop "Version: " header X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 10:49:05 -0000 --jRdC2OsRnuV8iIl8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [openpgp] Bug#931238: hot armor: please drop "Version: " header Peter Gutmann: > "An attacker knowing that you're running out- of-date software" barely=20 > qualifies as a threat - they can just try and attack you anyway - and=20 > I can't see what other purpose it serves.=20 We had this debate three years ago over on gnupg-devel. dkg posted a patch - which was merged in upstream GnuPG: > The version of GnuPG in use is not particularly helpful. It is not > cryptographically verifiable, and it doesn't distinguish between > significant version differences like 2.0.x and 2.1.x. > Additionally, it leaks metadata that can be used to distinguish users > from one another, and can potentially be used to target specific > attacks if there are known behaviors that differ between major > versions. > It's probably better to take the more parsimonious approach to > metadata production by default. https://lists.gnupg.org/pipermail/gnupg-devel/2016-August/031424.html These were the original arguments: > Since "Pervasive Monitoring Is an Attack" [2], let's minimize metadata=20 > as much as possible, especially if it's unencrypted *and* not=20 > cryptographically verifiable. > The riseup.net "OpenPGP Best Practices" [3] refer to a gpg.conf [4]=20 > which already implements "no-emit-version". I and many other people have= =20 > been using this with many implementations on many plattforms for a long= =20 > time, without any problems. So I see no technical reason against the=20 > proposal. > Even RFC 4880 lists no pressing reason for including this by default: >> The Armor Headers are pairs of strings that can give the user or the=20 >> receiving OpenPGP implementation some information about how to decode=20 >> or use the message. [5] > I can't see how "Version: GnuPG v2" tells me or an OpenPGP=20 > implementation "how to decode or use the message". > Let's just drop it. > 2. https://tools.ietf.org/html/rfc7258 > 3. https://riseup.net/en/security/message-security/openpgp/best-practices > 4. https://raw.githubusercontent.com/ioerror/duraconf/master/configs/gnup= g/gpg.conf > 5. https://tools.ietf.org/html/rfc4880#page-55 https://lists.gnupg.org/pipermail/gnupg-devel/2016-August/031428.html After it was merged, a pratical attack was published: > Werner Koch: >> You are right, the "Version:" has no technical meaning. >> I just pushed dkg's patch to master. > Thanks again for this. Even after the decision, I want to add a=20 > real-world example of why this change helps against de-anonymization: >> Both "French Maid" and Force (operating as "Nob") used the exact same=20 >> brand of PGP software, a free brand called GnuPG. There are different=20 >> brands of PGP software so it is noteworthy that both Force (operating=20 >> as "Nob") and "French Main" used the same brand. Not only did Force=20 >> and "French Maid" both use the same brand of PGP software, they also=20 >> both used the same outdated version of that software, 1.4.12. Version=20 >> 1.4.12 was released on January 2012, and was replaced with a new=20 >> version by December 2012, and was one of several versions of GnuPG=20 >> software. As such, both "French Maid" and Force (as Nob) were using=20 >> the specific, older version of the GnuPG software, and neither of them= =20 >> replaced it with the other (free) version of GnuPG that came out=20 >> thereafter. [=E2=80=A6] >> There are also additional similarities between Force's (Nob's) and=20 >> "French Maid's" PGP patterns. Both "Nob" and "French Maid" left=20 >> certain default settings on their PGP software. For one thing, both=20 >> "French Maid" and Force (Nob) left a "tag" that appeared on every=20 >> message authored from their PGP key revealing the brand and version of= =20 >> PGP software they were using. This is akin to, for example, leaving=20 >> the phrase "sent from my iPhone" on the bottom of one's emails but=20 >> with greater detail: it would be akin to leaving a phrase like "sent=20 >> from my iPhone 6 iOS 8.0.1." Leaving this "tag" on typically reveals=20 >> that one is dealing with a fairly inexperienced user of PGP, because=20 >> someone that regularly uses PGP to communicate would normally have=20 >> changed their settings to omit this tag. > http://www.justice.gov/sites/default/files/opa/press-releases/attachments= /2015/03/30/criminal_complaint_forcev2.pdf > http://www.networkworld.com/article/2904395/microsoft-subnet/mistakes-tha= t-betrayed-anonymity-of-former-dea-agent-and-silk-road-investigator.html After that, the OpenPGP "Version:" header was dropped across the=20 ecosystem: GnuPG: https://git.gnupg.org/cgi-bin/gitweb.cgi?p=3Dgnupg.git;a=3Dcommit;h= =3Dc9387e41db7520d176edd3d6613b85875bdeb32c GPGTools: https://github.com/GPGTools/MacGPG2/commit/831c2ed77d2ce88134ad4d= 689414051dc99dc3b3 SKS: https://bitbucket.org/skskeyserver/sks-keyserver/commits/4af75b3526d9 To sum up: - there is no valid technical reason for it - there are active attacks which have put people in jail - it's now ecosystem standard not to generate it So please: 1. let's drop it by default in other implementations, like hOpenPGP 2. let's edit rfc4880bis to "SHOULD NOT emit a Version: header" --=20 ilf If you upload your address book to "the cloud", I don't want to be in it. --jRdC2OsRnuV8iIl8 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEy7FaaO86yASHXVxOFT/jmIIcg5QFAl0jH5IACgkQFT/jmIIc g5TtHQ//X9unGswe/HMXpDwNLiYcrAb/qERH2CASi9CPEeXxpVmpOnwtlXvtoFFP BynvUlN/UnHxaE4Qy7IAv3O1QOcCkUGF1sJLOYXVmzSgsYHfWFpJxZZc/qtoIaG9 EtD/GKdM7/Y0Da9XaqQCmhqa813prOYXzZG8xz8delIcQx2Y5su5Cn2OmlUUUGYG rkHi4LHfmxZuyb0K+0/nOM3mljaz4wFnDJqYZXRbTE8m/KkeO2soJFq0FuCCO8Vi ud2GnJW2G1OJ7KZlhEKy1vH6Q0t4/Cc+W+blUx4lKJhnwFlbYWToEAeemgQHdgOC sfvNJK69+2OgtDFVBHagqRMiPZ/Y5Zg31PUAwPjSnAdlgHiPWV1/jZepRi0Bxk+h 5asquo85gUQOsxrIzktM9KSMDt3N0mxV4h36KSa1Jy1QnW1r/WpVbhBd219XZ/vv GkF79aTXCVx2+F9gbxYZ5U33AxvXCRmvkgfRURFZm8i5DSBn6Xqs4EpBnwrJ1mm7 Hpkk9hKMeZfz5WiDgfTVDwQNlhFhxzO8DUExVpfRUyBPqkMjBnuDyXTdpN22pH/w KECvn+hcYyaWmzvi+lpd0ql0Xph+UxCEm5svZJ3VN24UobVqd1XyEhNILc2ZoJah Aqx8FenxhswHqwQncVJW938wpP+EGhROBjyOSIu+531s13FAStc= =xarY -----END PGP SIGNATURE----- --jRdC2OsRnuV8iIl8-- From nobody Wed Jul 10 00:42:06 2019 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 614DA12017D for ; Wed, 10 Jul 2019 00:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rub.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 giJmLfaNvbIF for ; Wed, 10 Jul 2019 00:42:01 -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 B4623120154 for ; Wed, 10 Jul 2019 00:42:00 -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 45kB392ZYXz4wJ4 for ; Wed, 10 Jul 2019 09:41:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=rub.de; s=mail-2017; t=1562744517; bh=su89ivCDUK45Sc4mk9b6YUUDTDaS/kS0dLf8I1/xkUk=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Q5nTia45G3ivEVXsrLqWJvYMCYYAAqjXn4UVnwp1UO2O6aO2jQIBUuTLpt/QJLgl+ oG1Gx8Y4UrrqQHHg4c7gDx8KcwQP3qQcWC4lUhrGcQJkCyS9E9GqfFmtcMYPhZQMpb mEIdBSWWxpV8dTzP8fNpzhpzYvSqEGyk1/9oMAS4= 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 45kB391XJNz4w66 for ; Wed, 10 Jul 2019 09:41:57 +0200 (CEST) X-Envelope-Sender: X-RUB-Notes: Internal origin=134.147.42.227 Received: from mail1.mail.ruhr-uni-bochum.de (mail.ruhr-uni-bochum.de [134.147.42.227]) by out2.mail.ruhr-uni-bochum.de (Postfix mi-int) with ESMTP id 45kB3908ljz4wJ4 for ; Wed, 10 Jul 2019 09:41:56 +0200 (CEST) Received: from [192.168.142.139] (p5DCA4BEB.dip0.t-ipconnect.de [93.202.75.235]) by mail1.mail.ruhr-uni-bochum.de (Postfix) with ESMTPSA id 45kB386fmnzytt for ; Wed, 10 Jul 2019 09:41:56 +0200 (CEST) To: openpgp@ietf.org References: <87zhm1o0f7.fsf@fifthhorseman.net> <20190706133941.tw3znn74q4iseiyo@scru.org> <54525144-b7bf-fa79-c497-ca8fbf77f89d@gmx.net> <8d960bb1-0fe8-c2e3-fcf4-4d00ed4adfce@rub.de> <87r2717fwo.fsf@fifthhorseman.net> From: Marcus Brinkmann Openpgp: preference=signencrypt Message-ID: <32605ef2-afb0-a7e3-8585-13ed7d0bc566@rub.de> Date: Wed, 10 Jul 2019 09:41:57 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <87r2717fwo.fsf@fifthhorseman.net> 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: Re: [openpgp] Bug#931238: hot armor: please drop "Version: " header X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 07:42:04 -0000 Hi, On 7/7/19 10:23 PM, Daniel Kahn Gillmor wrote: >> 1. The embedded timestamp and filename in a literal data packet. > > I'm not sure how these would vary across implementations. perhaps the > guidance should say "in the absence of a requirement to the contrary, > the timestamp should be set to zero and the filename should be zero > octets in length." Well, the encoding can be different, filenames can be typical for an operating system, etc. I'd just zero it all out. >> 2. The block sizes for partial data packets, and when they are used. > > Partial data packets SHOULD NOT be generated. In the event that they > are generated, partial data packets SHOULD have a length represented by > the value 236 (meaning, the packet has a length of 1<<(236&0x1F) == 4096 > octets). Actually, it would be more stable to always use partial data packets with a fixed chunk size (plus rest). >> 3. The signature subpackets used and their order (hashed and >> unhashed). > > Which hashed subpackets to use: i'm not sure about this. suggestions? That's a large topic, unfortunately. Probably requires some research, too. > order: > > Implementations SHOULD emit signature subpackets in subpacket type > order. If multiple subpackets of a given type are present, they SHOULD > be ordered based on the binary representation of the > subpacket. (0x01ffff comes before 0x020000, etc). Subpacket length must be canonicalized, too, like packet lengths. But there is some trouble here: There are private or experimental subpacket types, and a generic implementation won't know if the order matters. > Implementations SHOULD NOT emit unhashed subpackets without a concrete > reason to do so. > > >> 4. Possibly the details of the compression. > > Implementations SHOULD NOT generate compressed packets. If they do, > they should prefer Bzip2 over Zlib over ZIP. (is this right? what > about per-format compression details? For example, block size. In general, I think there is a lot of flexibility in choosing the huffman tree and such. Dunno if that actually happens in the real world. >> 5. The length of the base64 encoding. > > I think this means line length. Yes, sorry. > > Implementations SHOULD generate Radix-64 data encoded such that all full > lines have 64 printable characters in them. > >> 6. Potentially the order of signature packets. > > I'm assuming this is about signature packets over a data, not user ID > certifications or subkey signatures. > > If multiple signature packets are attached to a piece of data, they > SHOULD be ordered by their creation date (oldest signature first). If > multiple signatures share the same creation date, they SHOULD be ordered > by their binary representation. > >> 7. The value of any quick check bytes (some implementations set them to >> invalid values to discourage checking them). > > That's news to me, thanks for raising it. Can you point to > documentation about that? Unfortunately, I can't find it. It might just have been an idea I read about somewhere, without implementation, or an obscure niche implementation. It was an interesting idea, though, so it stuck in my head. > >> For keys: >> >> 1. Again the signature subpackets used and their order. > > Same as above, i think. > >> 2. Potentially the details of the user id. > > as most of this is entirely user-visible (and user-selected), i'm not > sure how much implementations can do here. Perhaps we should recommend > using Unicode canonicalization form C for the UTF-8 string though? I agree that user-visibility makes this different from the other items on this list. >> 3. Algorithm and other preferences and flags. > > These compatibility markers will invitably leak some information about > the local implementation, as they are needed for interoperability. We > can provide guidance on the ordering of those preference though. > >> 4. The cryptographic parameters of public keys (RSA exponent etc) > > The chosen RSA exponent SHOULD be 0x10001. > > (suggestions for other parameters for other pubkey algorithms welcome!) Prime generation and random number generation: The Million-Key Question—Investigating the Origins of RSA Public Keys (Petr Švenda, Matúš Nemec, Peter Sekan, Rudolf Kvašňovský, David Formánek, David Komárek, and Vashek Matyáš, Masaryk University), 25th USENIX Security Symposium https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_svenda.pdf > >> 5. S2K count. > > Modern hardware is fast. Implementations that emit an S2K packet SHOULD > use Iterated + Salted S2K, and the S2K count SHOULD be 65011712 > (single-octet representation 255). > >> 6. Possibly resolution of any timestamps. > > Isn't the specification's 1-second resolution reasonable? Do we want to > encourage something different? For example, when creating a new key with multiple subkeys, an implementation could have the same or different timestamps for them. > One other item for OpenPGP certificates ("keys")" > > 7. order of certification packets, order of user ids, etc: > > I proposed a canonicalized structure for OpenPGP certificates over here: > > https://dev.gnupg.org/T3389 > > Perhaps this should be a supplementary implementator guidance draft, > distinct from the specifying RFC? Then we could also update it as new > fingerprinting surface is discovered, without revising the RFC itself. > Anyone interested in starting a draft? Thanks, Marcus -- Dipl.-Math. Marcus Brinkmann Lehrstuhl für Netz- und Datensicherheit Ruhr Universität Bochum Universitätsstr. 150, Geb. ID 2/461 D-44780 Bochum Telefon: +49 (0) 234 / 32-25030 http://www.nds.rub.de/chair/people/mbrinkmann From nobody Wed Jul 10 12:52:08 2019 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 3436912004A for ; Wed, 10 Jul 2019 12:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] 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 3GOiwAh1c1pc for ; Wed, 10 Jul 2019 12:52:04 -0700 (PDT) Received: from smtpin.nadir.org (fry.nadir.org [217.114.68.218]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 828E8120043 for ; Wed, 10 Jul 2019 12:52:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtpin.nadir.org (Postfix) with ESMTP id 0AA917CAB31; Wed, 10 Jul 2019 21:52:00 +0200 (CEST) Received: from smtpin.nadir.org ([127.0.0.1]) by localhost (fry.nadir.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92dgcwbsFXuo; Wed, 10 Jul 2019 21:51:59 +0200 (CEST) Received: from snail.zeromail.org (mail.zeromail.org [217.114.68.185]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpin.nadir.org (Postfix) with ESMTPS id BDC6B7CAB2A; Wed, 10 Jul 2019 21:51:59 +0200 (CEST) Received: from [127.0.0.1] (localhost [127.0.0.1])ng TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by snail.zeromail.org (Postfix) with ESMTPSA id A02A4C1AB2; Wed, 10 Jul 2019 21:51:58 +0200 (CEST) Date: Wed, 10 Jul 2019 21:51:44 +0200 From: ilf To: openpgp@ietf.org Cc: 931238@bugs.debian.org Message-ID: <20190710195144.GA1362@zeromail.org> Mail-Followup-To: openpgp@ietf.org, 931238@bugs.debian.org References: <87zhm1o0f7.fsf@fifthhorseman.net> <20190706133941.tw3znn74q4iseiyo@scru.org> <54525144-b7bf-fa79-c497-ca8fbf77f89d@gmx.net> <8d960bb1-0fe8-c2e3-fcf4-4d00ed4adfce@rub.de> <1562550125588.27272@cs.auckland.ac.nz> <20190708104852.GH1362@zeromail.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="oAjj1ZwgLg4oRN9q" Content-Disposition: inline In-Reply-To: <20190708104852.GH1362@zeromail.org> Archived-At: Subject: Re: [openpgp] Bug#931238: hot armor: please drop "Version: " header X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 19:52:07 -0000 --oAjj1ZwgLg4oRN9q Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [openpgp] Bug#931238: hot armor: please drop "Version: " header ilf: > So please: > 1. let's drop it by default in other implementations, like hOpenPGP > 2. let's edit rfc4880bis to "SHOULD NOT emit a Version: header" After this mail: 1. LibTMCG dropped it by default:=20 http://git.savannah.nongnu.org/cgit/libtmcg.git/commit/?id=3D2c8a6861ab839c= b58b6483a04a7b584423a27811 2. Heiko Stamer submitted a pull request to rfc4880bis:=20 https://gitlab.com/openpgp-wg/rfc4880bis/merge_requests/17 I added a comment to slighty improve the wording: > To minimize metadata, implementations SHOULD NOT emit this key and its=20 > corresponding value except for debugging purposes with explicit user=20 > consent. --=20 ilf If you upload your address book to "the cloud", I don't want to be in it. --oAjj1ZwgLg4oRN9q Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEy7FaaO86yASHXVxOFT/jmIIcg5QFAl0mQdAACgkQFT/jmIIc g5Q6gQ//YKlKl9b3tXWn6hlxRyKvgtEWfSjiSLRu+Q8XMHeuu6zmp51YBcD8Jqav eT93Q3yg4RwnnnNyqx7VgQifJaNdCZ8VNqhx8GywnKt+M7KBcHgn/ZwRrtqYugdx TZmHhqijw+FYtQg56nQnfj2/t56/+oOetDFOY4c6WcJ2x8OFd2ooo74FJG5Rq8LR Nu/q4C4P71WiFNYg1I7VbSqIF8wzNh9hWcs5Kc4GbPjyapoSesjVs4aNjpLXcWqN tg82z3x0M5Gep8YQCnDGFJJF0mblSW0JG1B1FoQMzwISeoy1pjoxNT6f48CzTvie qWf5pvdh3VObKifi7Yxb4CqaBLY8BYZX3ajZaY+cvnkqbg6Xo3mmATYz9sBOWAnQ 4TNiRYvFg3AAwGCD8y/gPSmZiTiTNbyuxw18yOg3O7LLpUyN0KxtTlefu/8miu+R UyCfXHPrshMoUD9lrEu5za27vP2FHdZ61iAdSec9P/5Dnyn25UztDXbFdUqcxZ76 Xux8GCp9QReqt9JYHEOiQDK5INYXO6hS7wyE2EYrrEJevWxrkVynjeH6hqpi5NKk 0zrKfh/bSPg+Ux96i/BuuMHTFE3Oo7eTtJQ1Z0Xm0r0aMfWuKlBToFOLiII6urE7 EKsnjotKarHrvoiG8PHmGa+jdnu/H1mitxe26aLNLvM5U33FpPo= =5Yb9 -----END PGP SIGNATURE----- --oAjj1ZwgLg4oRN9q-- From nobody Sat Jul 13 01:38:51 2019 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 9BD53120155 for ; Sat, 13 Jul 2019 01:38:49 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 jgDV7zBR3iIp for ; Sat, 13 Jul 2019 01:38:48 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 9B4B01200F4 for ; Sat, 13 Jul 2019 01:38:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1563007119; bh=Pjz4Dcis31zOiEmUC45b8dN+qc5SajseacTSokH9vMA=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=fcDyzJpWTxRaCQw3y5Gd9lVn9/lu749JTYukF3S1/xTIIduoHpkC27uAPXwWu7Z+p ao6Rzgt+ZHJkLr+aY5FbxPTmsJLLC+giXBj+o/UU2b/8sZm1GsEC6pLuQ0JKbC4vtn PLNKAB0zv+zFLIio/g9Avxa/yejtOjuyZgHWGGok= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.30] ([80.132.227.94]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MIu7d-1hjjdv3PFR-002bsG; Sat, 13 Jul 2019 10:38:38 +0200 To: Daniel Kahn Gillmor , openpgp@ietf.org References: <87zhm1o0f7.fsf@fifthhorseman.net> <20190706133941.tw3znn74q4iseiyo@scru.org> <54525144-b7bf-fa79-c497-ca8fbf77f89d@gmx.net> <87tvby6nl7.fsf@fifthhorseman.net> From: Heiko Stamer Openpgp: preference=signencrypt Autocrypt: addr=HeikoStamer@gmx.net; prefer-encrypt=mutual; keydata= mQGiBDdYKNkRBACRdsFzaQn0HChOX38WHXlIYcNZAAxBQxa7gdmPXTUK+tgwQuwAr/XViQxn ExKwyOteRhwHZNSYdoKPlCOJ3c3FWCKAdflINr53NvN/qnnaF+3M1HaluiwVdfHD9a0+k7fd NFZMq2bTpzSCQBsPGipSK0K8ET8UPrXm54pXhqYL2wCgsuMBOv64bmg2zjg6vHSTKADGykcD /Agjoa7y7Cpifk4WEKDKu8nlrE9OFOJppjZ9bdJedrmZq5A/jHr35UOgbZItTmgBiz7bfMLq 7HD05ZQ3BplBmmiE0412f55GadCjN4vvnCdTqZ/ewzWdz/rzQGaJm9IvW6rupuFgrTx0GJhf we7cr6GQQo0nqA0LMCyhGHQASC56A/9NOroBzLM6wl9QlE9lybxd3cxI2UnrfHIu63tklFKF vL1XnjyJ4YR0sDs6/f56JbtEGUKTCI7ZAw+241Va4MrbDVmmsGJjQBcKxNbHDfkkjoJ9NBwr pUo2nMT3BWyKHCfnMqoyT+nN04b0Em1ffbhptKiLJSeY1mcPxvA1h7PrKbQiSGVpa28gU3Rh bWVyIDxoZWlrb3N0YW1lckBnbXgubmV0Poh4BBMRAgA4AhsDAh4BAheAFiEEdvcwETKdJ9uN fD+XT1hOuPsr4U8FAlzqvfMFCwkIBwIGFQoJCAsCBBYCAwEACgkQT1hOuPsr4U8jZQCfbz7N emwAJ2OdrBP9mmsySktb4IQAnRWJOYy4bH3R42nh6KCUkbDXQoNhuQMNBDdYKtkQDACuGU2S WXmjpoyGIX/UHze60OolxBdtKzhvDZHhy1Sz8NNrdkI3ozuYOMxkKZZLTw/iQigVNQfwy+5f AUw6KaH8OPnwInqyeguI6PwG0qQK2cWlSTZDlTW8B2D3Qpjt8sYnnjGEIGKGb7ZAUgODmWYd sS35otyEQT0Un/kRIqjyQcvWgNH++t+LypXUxu0eD0dlD/kx46TP9kqTYsr/8vWWhD2J98x0 ZFrFMN8QDCIhO9x3p+qPyfSiAdnuI4iN1RYsKtC2ikb+cIc5bYysnRots1anAy3Pd5Q8bFtj lzxPPRh90v/Yq5RM/3IgbsbS0zDI0ldznld+DInezLs/EROsITmmbXrhIAHC8TjcXtxWR3ht nFLnIgmQ3Rag0bQesNF4Y5bXSGcw/MxwWcm6EXwcbm7Uc64k8YxXMYyNy+XX/bi1o7r5JdH0 mKUFeXTF9WLrNpF4jBylHk1RNDbR6kp6M87vPJeg/nQh19ItQQxYJGYu9KBhBGhFtDUIAyLT nTcAAwUL/2tHe52rFeCVvZo7RZ5SQy/aclx7hnPsvb3yTXcvg5c7hweOL7Zfsh/XnE3acRO0 YAfGb0LxMFJlfpHgcPuTZEd5rPgJz68GccACBPw8Z8MgQEBE5H/UiAR/HM9AQmEN+wfjeDlv 6ZGElmnY59gYIuCGUVsqw5pwCCsLBs3xlMTyCiNwDHERRao3YTGhaNy9hsCdqNHQcXdSzdF6 OtvfMnXI67QGyiNcbjVwXwQHlGAsxo4O3FMOl138o1Oa00JMSk7td8bClMAp7Hu4zrw533TZ 2Avp+6OFjUAQ4U4hdEDGePNm2hbQinKnUCd30PboqIdZDmYq4SSeNMbWKwy3Etx/a0GX39F/ gnjmveBHSWGGB+wSKcrK3yfXNXMa4OW683m/aH1msS0L0SFwbm2w7XdALp0DCV031x1JoGAn c0mVcstbVM7KNUGnCOA9D4USKHrj/IoZVoapx0b+bWPFHtfLhcm2lSDlq7F140DlQVL1xZmA nPcpLyXMmEmnS2JCZYhGBBgRAgAGBQI3WCrZAAoJEE9YTrj7K+FPcRMAnige4x75lK1p7sbK sdhZb6tv4CJPAKCpDqRn9o7nfvLlouXNaIR1nri7cw== Message-ID: <9a2f6586-1bc3-9108-d166-bd83952dc7f4@gmx.net> Date: Sat, 13 Jul 2019 10:38:14 +0200 MIME-Version: 1.0 In-Reply-To: <87tvby6nl7.fsf@fifthhorseman.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JSe8lHlYOgSe98qAJx9EAGimkqCOYRKbq" X-Provags-ID: V03:K1:VBzQkq8KIzT26cFx821FpZjvgfu7My2cufKDEkQbT+Dz1xfiNjL No2T3Tbhwt2E/WX6TrbsR3+TK5RqBPhpoy927Izym/wkzEr8BPag4nBdcMrAeFYBdH/zMmV euJRXalWKgtLmyPuDG7vOWdzQlndIJqX7HnwBbJmle180V33/xOcE0OV+akh3RGuV/yH+7Y WngqZ4P61EEL2mZ9tfTRA== X-UI-Out-Filterresults: notjunk:1;V03:K0:Ani3OzjCudA=:CkTJilVub4MCmP9bFk1OI0 srCjNCLcLIUMK8VusyucqydHECAOYPsMz9+VStILyhCVrsQwOImQWahENKeKHH6IkkDHutGA+ vtm8K5l6Ljr8NehXZ1+ZHzMqkTAJSjfoeTDGXr+KIMq6dtH+a1oRDm+/viLI6YfTQbDdXnU/O MJTGdRQdrn4Gk4SRsN7SOFanPnvqyOlpRaAOfTA1JOB5UF/XU3eTyU2cNhJv0F3r9JiDYq/bI tRF/yoAqiGuhsGgLC63ngYyxRIXSDsrBtchonHdN0RQjjlb3N8VB3K67RHQmLqSQq/wchkXEy zkzTbQmKjmIGicVxQMVUaLGAIepwiZMkFU6T20schCEOHVO2R4pWvad1Vmyh5hDzZsEN1m0Id 4sUv12EYMyycjmImuOf1kdqCEEnSVX9LfnuSVfaSApkvHdtBSl99lPR1Ekz6LLNA7IPZx6pcS +p/FmLqHpYVzQULbzoYA/EddyvZfD43ZBs5Ez2a6FVOA1uozISyjMe/In6tDdnEVnhq9razh+ fyV3yAakC5cCbp1j3/FGfn7mCb8Ji2fV16uZ8ltJ+1bMJs3D0nfbiFcdfybP7UVI9RgBJ4dSl hk5iI77bfCtVppbWQ4y1F98OidF6tyAQafUkCQBpiRzvtGBPeMtic+JA5EwwzCOPZZi0r29DP uKsPLdnDRTaCuNGb0U1TXfVSCXh20970SmrlS/0VR2qTSoKbaNYmuillpBfEjeb7f16nuDi7Q hvjpM7G3x76pqFnQ3/YJjcamN0DNc0DkzO1hxTkeMLo22QD0GZ+WJQVk8CGtGTcVGrI6egorf Xg0fPIp1H2kIjEPExWS0kV5hunVCER+o779lVvEGOS5L0dDQMiRmsIMU/A0dwMv2SxPEZRoV7 0YofyT5ifmrhfzR3m/Goq6rzeXJ77wcEqz9sxIbL7RhYRa4KWolEdrhE5eX3FZcET+9pXfYMY XUvu2HS5MEkQrrMpONOmWHuxWLmpn+UJ804xWnIHiO9LlYuPDQGsg7P+RC5NZvFZzm32YHr9k BOpgHarwCpioJgYHlyhcHk3P5r7LVMJRIQiHVsEFJyfGUsDz88Sj+t70NTcx3uBNKlWt0mfIZ 3H3xJvXr14ZCVo= Archived-At: Subject: Re: [openpgp] Bug#931238: hot armor: please drop "Version: " header X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2019 08:38:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --JSe8lHlYOgSe98qAJx9EAGimkqCOYRKbq Content-Type: multipart/mixed; boundary="eWG49vLdjfe1ZO5O6cS9E3aG0uXHsDBru"; protected-headers="v1" From: Heiko Stamer To: Daniel Kahn Gillmor , openpgp@ietf.org Message-ID: <9a2f6586-1bc3-9108-d166-bd83952dc7f4@gmx.net> Subject: Re: [openpgp] Bug#931238: hot armor: please drop "Version: " header References: <87zhm1o0f7.fsf@fifthhorseman.net> <20190706133941.tw3znn74q4iseiyo@scru.org> <54525144-b7bf-fa79-c497-ca8fbf77f89d@gmx.net> <87tvby6nl7.fsf@fifthhorseman.net> In-Reply-To: <87tvby6nl7.fsf@fifthhorseman.net> --eWG49vLdjfe1ZO5O6cS9E3aG0uXHsDBru Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 07.07.2019 at 14:22, Daniel Kahn Gillmor wrote: > totally agreed that this should be added, and i encourage you to send > text to the openpgp@ietf.org mailing list. Regarding the fixed encoding of a (sub)packet length I suggest the following approach (AFAIK it's used by most OpenPGP implementations): if (len < 192) { // one-octet length format } else if (len < 8384) { // two-octet length format } else { // four-octet length format with 0xFF prefix } Recently, I the length encoding in LibTMCG/DKGPG for subpackets, where it was previously a four-octet length format with 0xFF prefix. --=20 Heiko --eWG49vLdjfe1ZO5O6cS9E3aG0uXHsDBru-- --JSe8lHlYOgSe98qAJx9EAGimkqCOYRKbq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQR29zARMp0n2418P5dPWE64+yvhTwUCXSmYewAKCRBPWE64+yvh T1frAKCFWz/8twu9sg5JRIk9RXFWA1JITQCgj/CtDd1lzXIY1pSln6DJ/CYCpeM= =xhGI -----END PGP SIGNATURE----- --JSe8lHlYOgSe98qAJx9EAGimkqCOYRKbq-- From nobody Mon Jul 22 06:27:19 2019 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 A82B912029F for ; Mon, 22 Jul 2019 06:27:08 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=LZks9Ipm; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=nCVvukMN 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 Aq79EFwWM750 for ; Mon, 22 Jul 2019 06:27:07 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 372C81202ED for ; Mon, 22 Jul 2019 06:27:07 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1563802026; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=vVUtGBfWc06Ne/y8gvq4LSJY1pEK/dK073ZrxKNMO3s=; b=LZks9Ipm9C6sfBsVVqu2xTiEJB8v4xOG/is2+lzf+i2zt4kfxVT8fDr+ wjneB5aP1X9fE07na33vK7h1RlIwDA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1563802025; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=vVUtGBfWc06Ne/y8gvq4LSJY1pEK/dK073ZrxKNMO3s=; b=nCVvukMNBbqmUpLIt1Vfa07Ny4BTHNiuzCH+1YtqUfylmk1NH4i7KfnD fYXC3MsQ5lLW924j5+cN6KMKpOiTGg9sX1lf403aHQERW/WUeI2uwH07FP P6WmhvArUoZUpTcGqA457hVTqkBaCSkx2+RfYLqgxuc5ooFno+YvymCumU 1wJ6WqZFa37oB6UzdKq1j6qppNJBob/Jov1z3qh6TxJbK+UVjht92RTHwa OAZ1JFbwXPbUs7beAPB2zdzWoLGh+GlYqqVmIfn3gOOTi56yA7jd9txqtE tiHYSXEtkKttcQ0E/RaY3PSwvmrkTzkcON0tY/hzf+Ys1FZA5auekg== Received: from fifthhorseman.net (dhcp-80e0.meeting.ietf.org [31.133.128.224]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 5A984F99E; Mon, 22 Jul 2019 09:27:05 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id F13A320828; Mon, 22 Jul 2019 09:15:33 -0400 (EDT) From: Daniel Kahn Gillmor To: Heiko Stamer , openpgp@ietf.org In-Reply-To: <9a2f6586-1bc3-9108-d166-bd83952dc7f4@gmx.net> References: <87zhm1o0f7.fsf@fifthhorseman.net> <20190706133941.tw3znn74q4iseiyo@scru.org> <54525144-b7bf-fa79-c497-ca8fbf77f89d@gmx.net> <87tvby6nl7.fsf@fifthhorseman.net> <9a2f6586-1bc3-9108-d166-bd83952dc7f4@gmx.net> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Mon, 22 Jul 2019 09:15:33 -0400 Message-ID: <87zhl6xlai.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [openpgp] Bug#931238: hot armor: please drop "Version: " header X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 13:27:13 -0000 On Sat 2019-07-13 10:38:14 +0200, Heiko Stamer wrote: > On 07.07.2019 at 14:22, Daniel Kahn Gillmor wrote: > >> totally agreed that this should be added, and i encourage you to send >> text to the openpgp@ietf.org mailing list. > > Regarding the fixed encoding of a (sub)packet length I suggest the > following approach (AFAIK it's used by most OpenPGP implementations): > > if (len < 192) > { > // one-octet length format > } > else if (len < 8384) > { > // two-octet length format > } > else > { > // four-octet length format with 0xFF prefix > } This looks reasonable to me, and i agree that it should be part of any proposed draft aimed at minimizing divergence in generated output across OpenPGP implementations. --dkg From nobody Wed Jul 31 13:34:54 2019 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 F109E12004F for ; Wed, 31 Jul 2019 13:34:51 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=uLcSzGBK; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=06fH4RKs 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 01fTxWxiLOfS for ; Wed, 31 Jul 2019 13:34:49 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52AEA120018 for ; Wed, 31 Jul 2019 13:34:49 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1564605288; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : from; bh=hmGnuW2KV/zvduIvu8TA4LcVT+R++tRZl1jg2eQGDSE=; b=uLcSzGBKo24iVcFX9gsOPFF3u1hTXneFEs3kqZNJuRJE3a/OTkzdexoy P+p5SQQLjR2mXldryk3lTUOLCxE7Dw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1564605288; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : from; bh=hmGnuW2KV/zvduIvu8TA4LcVT+R++tRZl1jg2eQGDSE=; b=06fH4RKs/5I40kvSZK2+9BMUDmZekShUwRkSb/mNIlwppiFmgXWxYRCN 0BvPSpwU6ZmyrKm11hH/xocNbIOUF0FTgyFK3oXnB6QDpn3M3k7mFf6YVP XOE9uGkFhUvzVkEcVPWhG7OfsfFvpSTg//TBND85r7kuc3vy/Tx6kgWeFU E5ZwqemuUc+tQq/geuZxtJpYeRKO9E++dp+cHXyH4gOlAt6+ifWvq6XH3O u+R+Ppp2nTprwEcDSDRBEcjfToJBBNbs3igIvnMTUuo7Mqo6Avz+3m/oSN /JPsoL/SQ0Bc4wJlp4Ana4IcFcxxUI2yqrSxS3YbW+k7qQOT8OnchQ== Received: from fifthhorseman.net (unknown [38.109.115.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id CDA0EF99D for ; Wed, 31 Jul 2019 16:34:47 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id F23252025E; Wed, 31 Jul 2019 16:34:44 -0400 (EDT) From: Daniel Kahn Gillmor To: IETF OpenPGP WG Date: Wed, 31 Jul 2019 16:34:44 -0400 Message-Id: <20190731203444.4822-1-dkg@fifthhorseman.net> X-Mailer: git-send-email 2.20.1 In-Reply-To: <87iocqepta.fsf@littlepip.fritz.box> References: <87iocqepta.fsf@littlepip.fritz.box> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: [openpgp] [RFC4880bis PATCH] Deprecate "Revocation Key", replacing with full-key "Designated Revoker" X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 20:34:52 -0000 The "revocation key" subpacket is problematic. It is the the most fragile piece of the specification wrt the fingerprint (collisions against a fingerprint can create surprising revocation effects). And it is potentially difficult to rely on for clients which might not be able to find the revoking key (for example, if keyservers are unavailable). It is also not currently widely used. This patch to the spec deprecates the "revocation key" subpacket and replaces it with a "designated revoker" subpacket that includes the full key, rather than the fingerprint. The only cost here appears to be slightly increased size of the new subpacket type by comparison, which is an entirely reasonable cost that the (rare) users of this feature should be able to bear. I've cargo-culted in the "class" octet from "Revocation Key". I'm not sure that octet is particularly useful, and i'd be happy to drop it if folks want to, but i didn't want to muddle the waters with a semantic change in addition to this mechanical change. Signed-off-by: Daniel Kahn Gillmor --- middle.mkd | 61 ++++++++++++++++++++++++++++++++++++++++-------------- 1 file changed, 46 insertions(+), 15 deletions(-) diff --git a/middle.mkd b/middle.mkd index 51f71a6..a2d3ae6 100644 --- a/middle.mkd +++ b/middle.mkd @@ -757,7 +757,7 @@ These meanings are as follows: directly on a key. It binds the information in the Signature subpackets to the key, and is appropriate to be used for subpackets that provide information about the key, such as - the Revocation Key subpacket. It is also appropriate for + the Designated Revoker subpacket. It is also appropriate for statements that non-self certifiers want to make about the key itself, rather than the binding between a key and a name. @@ -766,7 +766,7 @@ These meanings are as follows: : Key revocation signature. The signature is calculated directly on the key being revoked. A revoked key is not to be used. Only revocation signatures by the key being - revoked, or by an authorized revocation key, should be + revoked, or by a designated revoker, should be considered valid revocation signatures. 0x28 @@ -774,7 +774,7 @@ These meanings are as follows: directly on the subkey being revoked. A revoked subkey is not to be used. Only revocation signatures by the top-level signature key that is bound to this subkey, or by an - authorized revocation key, should be considered valid + designated revoker, should be considered valid revocation signatures. 0x30 @@ -782,7 +782,7 @@ These meanings are as follows: earlier User ID certification signature (signature class 0x10 through 0x13) or direct-key signature (0x1F). It should be issued by the same key that issued the revoked signature - or an authorized revocation key. The signature is computed + or a designated revoker. The signature is computed over the same data as the certificate that it revokes, and should have a later creation date than that certificate. @@ -1039,7 +1039,7 @@ The value of the subpacket type octet may be: 9 Key Expiration Time 10 Placeholder for backward compatibility 11 Preferred Symmetric Algorithms - 12 Revocation Key + 12 Revocation Key (deprecated) 13 to 15 Reserved 16 Issuer 17 to 19 Reserved @@ -1058,6 +1058,7 @@ The value of the subpacket type octet may be: 32 Embedded Signature 33 Issuer Fingerprint 34 Preferred AEAD Algorithms + 35 Designated Revoker 100 to 110 Private or experimental An implementation SHOULD ignore any subpacket of a type that it does @@ -1294,18 +1295,48 @@ description of the syntax is found in [](#regular-expressions) below. #### Revocation Key -(1 octet of class, 1 octet of public-key algorithm ID, 20 or 32 octets -of fingerprint) +(1 octet of class, 1 octet of public-key algorithm ID, 20 octets +of v4 fingerprint) -V4 keys use the full 20 octet fingerprint; V5 keys use the -full 32 octet fingerprint +This mechanism is deprecated. Applications MUST NOT generate such a +subpacket. An application that wants this functionality SHOULD +instead produce a Designated Revoker subpacket described in +[](#designated-revoker). The advantage of the Designated Revoker +packet is twofold: it can be used unambiguously to validate +revocations without causing an extra lookup; and it is resistant to +any flaws found in the fingerprint. -Authorizes the specified key to issue revocation signatures for this -key. Class octet must have bit 0x80 set. If the bit 0x40 is set, -then this means that the revocation information is sensitive. Other -bits are for future expansion to other kinds of authorizations. This -is only found on a direct-key self-signature (type 0x1f). The use on -other types of self-signatures is unspecified. +This packet authorizes the specified v4 key to issue revocation +signatures for this key. Class octet must have bit 0x80 set. If the +bit 0x40 is set, then this means that the revocation information is +sensitive. Other bits are reserved and MUST be 0. This is only found +on a direct-key self-signature (type 0x1f). The use on other types of +self-signatures is unspecified. + +If the "sensitive" flag is set, the keyholder feels this subpacket +contains private trust information that describes a real-world +sensitive relationship. If this flag is set, implementations SHOULD +NOT export this signature to other users except in cases where the +data needs to be available: when the signature is being sent to the +designated revoker, or when it is accompanied by a revocation +signature from that revoker. Note that it may be appropriate to +isolate this subpacket within a separate signature so that it is not +combined with other subpackets that need to be exported. + +#### Designated Revoker + +(1 octet of class, N octets of public key) + +Authorizes the embedded public key to issue revocation signatures for +this key. Class octet must have bit 0x80 set. If the bit 0x40 is +set, then this means that the revocation information is sensitive. +Other bits are for future expansion to other kinds of authorizations. +This is only found on a direct-key self-signature (type 0x1f). The +use on other types of self-signatures is unspecified. + +The remaining N octets of the of the packet MUST consist of a complete +Public-Key Packet (tag 6) that can be used to verify revocation +signatures. If the "sensitive" flag is set, the keyholder feels this subpacket contains private trust information that describes a real-world -- 2.20.1 From nobody Wed Jul 31 13:38:53 2019 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 B7A2012002F for ; Wed, 31 Jul 2019 13:38:50 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=bfeZ90Gs; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=vxpf3m75 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 yvLbj10tJ53G for ; Wed, 31 Jul 2019 13:38:49 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1E7B120018 for ; Wed, 31 Jul 2019 13:38:48 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1564605528; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=G93YToycBTtKKvkLDfkjUUBxigpLTUN2ZXLM28Yo94Q=; b=bfeZ90Gs8LumVKsDpaXCy0zld1696/F1ggzMYomdaPLfPGVGSsNuxpzs ZbXu1iCrvU9W8d/I4sZVs3Ggm57dBA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1564605528; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=G93YToycBTtKKvkLDfkjUUBxigpLTUN2ZXLM28Yo94Q=; b=vxpf3m75jGJb6uz6lKvG5ZowEL9qZ+6CjFkfGppPhvhfDWitR2vZnwNt oXwl+yn9uVsv+sDN8Lv9p/a7WWx/wBcEFHS7BprYQi1XcLkOFue7giB/U/ r+22TT2sAsvLlJ2JMFOZvIbKDZyIGMQ6TqWuSRBIkkjeOv6ALqgJ6B6Chj xfoaLap0PyhBpwMzf5+KIa5dHohseWn0Kvv1vyQTnRhW+GDzCJtF2HwuRS jfiMJ4rittl39y1xkIqBOGTt0+ksrG1Mq/uvNQpo3sIb+JMPZAjOrcvk+s xrkSwQCvzye6kgRjEwvHmsXxLKRbcr2xXcEVeb7PDtiTi041ENiohw== Received: from fifthhorseman.net (unknown [38.109.115.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 19FCFF99D for ; Wed, 31 Jul 2019 16:38:48 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id D90692025E; Wed, 31 Jul 2019 16:37:43 -0400 (EDT) From: Daniel Kahn Gillmor To: IETF OpenPGP WG In-Reply-To: <20190731203444.4822-1-dkg@fifthhorseman.net> References: <87iocqepta.fsf@littlepip.fritz.box> <20190731203444.4822-1-dkg@fifthhorseman.net> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Wed, 31 Jul 2019 16:37:43 -0400 Message-ID: <87a7curld4.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] [RFC4880bis PATCH] Deprecate "Revocation Key", replacing with full-key "Designated Revoker" X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 20:38:51 -0000 --=-=-= Content-Type: text/plain On Wed 2019-07-31 16:34:44 -0400, Daniel Kahn Gillmor wrote: > The "revocation key" subpacket is problematic. It is the the most > fragile piece of the specification wrt the fingerprint (collisions > against a fingerprint can create surprising revocation effects). And > it is potentially difficult to rely on for clients which might not be > able to find the revoking key (for example, if keyservers are > unavailable). > > It is also not currently widely used. > > This patch to the spec deprecates the "revocation key" subpacket and > replaces it with a "designated revoker" subpacket that includes the > full key, rather than the fingerprint. this is also at https://gitlab.com/openpgp-wg/rfc4880bis/merge_requests/18 --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXUH8FwAKCRB2GBllKa5f +EjtAQClmHcKrxmbPZaoj8xY28rAconFKghAlzxpLkjLkU7l5gEAidT4ifphLzQG eEqUgQl3qcj1949+c6a86wuFVrmZJwQ= =Aq29 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 31 13:55:28 2019 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 95B0112006D for ; Wed, 31 Jul 2019 13:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NONE=0.001] 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 SIoLF7_2RAvq for ; Wed, 31 Jul 2019 13:55:14 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) (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 1700E12002F for ; Wed, 31 Jul 2019 13:55:13 -0700 (PDT) Received: from p57b2294e.dip0.t-ipconnect.de ([87.178.41.78] helo=forster.huenfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1hsvct-00066f-Tq; Wed, 31 Jul 2019 20:55:11 +0000 Received: from grit.huenfield.org ([192.168.20.9] helo=grit.walfield.org) by forster.huenfield.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1hsvct-0007fr-BX; Wed, 31 Jul 2019 22:55:11 +0200 Date: Wed, 31 Jul 2019 22:55:11 +0200 Message-ID: <87v9vh53gw.wl-neal@walfield.org> From: "Neal H. Walfield" To: Daniel Kahn Gillmor Cc: IETF OpenPGP WG In-Reply-To: <20190731203444.4822-1-dkg@fifthhorseman.net> References: <87iocqepta.fsf@littlepip.fritz.box> <20190731203444.4822-1-dkg@fifthhorseman.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/26 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 192.168.20.9 X-SA-Exim-Mail-From: neal@walfield.org X-SA-Exim-Scanned: No (on forster.huenfield.org); SAEximRunCond expanded to false Archived-At: Subject: Re: [openpgp] [RFC4880bis PATCH] Deprecate "Revocation Key", replacing with full-key "Designated Revoker" X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 20:55:20 -0000 Hi Daniel, Justus proposed an embedded TPK subpacket for cases like this with this as a motivating example. See: Subject: [openpgp] Embedded TPK subpacket From: Justus Winter Date: Mon, 25 Mar 2019 10:20:45 +0100 Message-ID: <87ef6v71jm.fsf@europa.jade-hamburg.de> https://mailarchive.ietf.org/arch/msg/openpgp/F1Wdrldzd3k9tqOos4hmokOV0r0 Do you think a point solution is better? Thanks, :) Neal On Wed, 31 Jul 2019 22:34:44 +0200, Daniel Kahn Gillmor wrote: > > The "revocation key" subpacket is problematic. It is the the most > fragile piece of the specification wrt the fingerprint (collisions > against a fingerprint can create surprising revocation effects). And > it is potentially difficult to rely on for clients which might not be > able to find the revoking key (for example, if keyservers are > unavailable). > > It is also not currently widely used. > > This patch to the spec deprecates the "revocation key" subpacket and > replaces it with a "designated revoker" subpacket that includes the > full key, rather than the fingerprint. > > The only cost here appears to be slightly increased size of the new > subpacket type by comparison, which is an entirely reasonable cost > that the (rare) users of this feature should be able to bear. > > I've cargo-culted in the "class" octet from "Revocation Key". I'm not > sure that octet is particularly useful, and i'd be happy to drop it if > folks want to, but i didn't want to muddle the waters with a semantic > change in addition to this mechanical change. > > Signed-off-by: Daniel Kahn Gillmor > --- > middle.mkd | 61 ++++++++++++++++++++++++++++++++++++++++-------------- > 1 file changed, 46 insertions(+), 15 deletions(-) > > diff --git a/middle.mkd b/middle.mkd > index 51f71a6..a2d3ae6 100644 > --- a/middle.mkd > +++ b/middle.mkd > @@ -757,7 +757,7 @@ These meanings are as follows: > directly on a key. It binds the information in the Signature > subpackets to the key, and is appropriate to be used for > subpackets that provide information about the key, such as > - the Revocation Key subpacket. It is also appropriate for > + the Designated Revoker subpacket. It is also appropriate for > statements that non-self certifiers want to make about the > key itself, rather than the binding between a key and a > name. > @@ -766,7 +766,7 @@ These meanings are as follows: > : Key revocation signature. The signature is calculated > directly on the key being revoked. A revoked key is not to > be used. Only revocation signatures by the key being > - revoked, or by an authorized revocation key, should be > + revoked, or by a designated revoker, should be > considered valid revocation signatures. > > 0x28 > @@ -774,7 +774,7 @@ These meanings are as follows: > directly on the subkey being revoked. A revoked subkey is > not to be used. Only revocation signatures by the top-level > signature key that is bound to this subkey, or by an > - authorized revocation key, should be considered valid > + designated revoker, should be considered valid > revocation signatures. > > 0x30 > @@ -782,7 +782,7 @@ These meanings are as follows: > earlier User ID certification signature (signature class > 0x10 through 0x13) or direct-key signature (0x1F). It should > be issued by the same key that issued the revoked signature > - or an authorized revocation key. The signature is computed > + or a designated revoker. The signature is computed > over the same data as the certificate that it revokes, and > should have a later creation date than that certificate. > > @@ -1039,7 +1039,7 @@ The value of the subpacket type octet may be: > 9 Key Expiration Time > 10 Placeholder for backward compatibility > 11 Preferred Symmetric Algorithms > - 12 Revocation Key > + 12 Revocation Key (deprecated) > 13 to 15 Reserved > 16 Issuer > 17 to 19 Reserved > @@ -1058,6 +1058,7 @@ The value of the subpacket type octet may be: > 32 Embedded Signature > 33 Issuer Fingerprint > 34 Preferred AEAD Algorithms > + 35 Designated Revoker > 100 to 110 Private or experimental > > An implementation SHOULD ignore any subpacket of a type that it does > @@ -1294,18 +1295,48 @@ description of the syntax is found in [](#regular-expressions) below. > > #### Revocation Key > > -(1 octet of class, 1 octet of public-key algorithm ID, 20 or 32 octets > -of fingerprint) > +(1 octet of class, 1 octet of public-key algorithm ID, 20 octets > +of v4 fingerprint) > > -V4 keys use the full 20 octet fingerprint; V5 keys use the > -full 32 octet fingerprint > +This mechanism is deprecated. Applications MUST NOT generate such a > +subpacket. An application that wants this functionality SHOULD > +instead produce a Designated Revoker subpacket described in > +[](#designated-revoker). The advantage of the Designated Revoker > +packet is twofold: it can be used unambiguously to validate > +revocations without causing an extra lookup; and it is resistant to > +any flaws found in the fingerprint. > > -Authorizes the specified key to issue revocation signatures for this > -key. Class octet must have bit 0x80 set. If the bit 0x40 is set, > -then this means that the revocation information is sensitive. Other > -bits are for future expansion to other kinds of authorizations. This > -is only found on a direct-key self-signature (type 0x1f). The use on > -other types of self-signatures is unspecified. > +This packet authorizes the specified v4 key to issue revocation > +signatures for this key. Class octet must have bit 0x80 set. If the > +bit 0x40 is set, then this means that the revocation information is > +sensitive. Other bits are reserved and MUST be 0. This is only found > +on a direct-key self-signature (type 0x1f). The use on other types of > +self-signatures is unspecified. > + > +If the "sensitive" flag is set, the keyholder feels this subpacket > +contains private trust information that describes a real-world > +sensitive relationship. If this flag is set, implementations SHOULD > +NOT export this signature to other users except in cases where the > +data needs to be available: when the signature is being sent to the > +designated revoker, or when it is accompanied by a revocation > +signature from that revoker. Note that it may be appropriate to > +isolate this subpacket within a separate signature so that it is not > +combined with other subpackets that need to be exported. > + > +#### Designated Revoker > + > +(1 octet of class, N octets of public key) > + > +Authorizes the embedded public key to issue revocation signatures for > +this key. Class octet must have bit 0x80 set. If the bit 0x40 is > +set, then this means that the revocation information is sensitive. > +Other bits are for future expansion to other kinds of authorizations. > +This is only found on a direct-key self-signature (type 0x1f). The > +use on other types of self-signatures is unspecified. > + > +The remaining N octets of the of the packet MUST consist of a complete > +Public-Key Packet (tag 6) that can be used to verify revocation > +signatures. > > If the "sensitive" flag is set, the keyholder feels this subpacket > contains private trust information that describes a real-world > -- > 2.20.1 > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > From nobody Wed Jul 31 15:01:24 2019 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 54476120152 for ; Wed, 31 Jul 2019 15:01:19 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=0Sdwk4zR; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=iMdK/aNP 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 sEU6OD0VX2o7 for ; Wed, 31 Jul 2019 15:01:17 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36BF012006D for ; Wed, 31 Jul 2019 15:01:17 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1564610476; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=iePwTSuz+WuVDOGQqSDGZZ32mC9WZbZdDVd5GxotsPg=; b=0Sdwk4zRn5YTgGp+fZLaVXhz5wMOf8hHiSyn1FAOlAIBhTj36cyU0Yf5 tInmEBv22/LMitD8XuO15v5/cwBcCQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1564610475; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=iePwTSuz+WuVDOGQqSDGZZ32mC9WZbZdDVd5GxotsPg=; b=iMdK/aNPR1WlDdvo3pmCjW+Qd8oxDzyxRWb61d4Ho0adECoCCgLV6r4l Xl4/LM5xiakdIzCFbI5o3/vnLXOylCZScSRLyWEfjfz/CYBqqntY55ZAYe 5iLmynKBeO1q5CbskQt18RA0z1Z3pA0Xgl4G4CQJRILEC4ZZzkJhiCVerY oGVw/p5wNj6XYRZtoP1bfRLFgQk0DPRoAmn057XMjcgx8EKJBXdR50/e7s fzf8ShXLTcRZpKZXD8FGNYhxuDsVYP6btbD5zin15n0VgDpORn/GC1gu+X mPcVBzTvnmwML9ZcLDTavTW2tGAxqb1GKTYW40sNA6P8r+Eil7ZcUA== Received: from fifthhorseman.net (unknown [38.109.115.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id C9CA3F99D; Wed, 31 Jul 2019 18:01:15 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 7F49B2025E; Wed, 31 Jul 2019 18:01:12 -0400 (EDT) From: Daniel Kahn Gillmor To: "Neal H. Walfield" Cc: IETF OpenPGP WG In-Reply-To: <87v9vh53gw.wl-neal@walfield.org> References: <87iocqepta.fsf@littlepip.fritz.box> <20190731203444.4822-1-dkg@fifthhorseman.net> <87v9vh53gw.wl-neal@walfield.org> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Wed, 31 Jul 2019 18:01:12 -0400 Message-ID: <877e7xsw2f.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] [RFC4880bis PATCH] Deprecate "Revocation Key", replacing with full-key "Designated Revoker" X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 22:01:20 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed 2019-07-31 22:55:11 +0200, Neal H. Walfield wrote: > Justus proposed an embedded TPK subpacket for cases like this with > this as a motivating example. See: > > Subject: [openpgp] Embedded TPK subpacket > From: Justus Winter > Date: Mon, 25 Mar 2019 10:20:45 +0100 > Message-ID: <87ef6v71jm.fsf@europa.jade-hamburg.de> > > https://mailarchive.ietf.org/arch/msg/openpgp/F1Wdrldzd3k9tqOos4hmokOV0= r0 > > Do you think a point solution is better? sure, i think Embedded TPK is interesting, but it's much more than is needed for having a designated revoker. The additional complexity comes at a cost i'd rather not impose for implementers. For a designated revoker, we don't care about who the revoking key belongs to. we just care that we know it. once you have an embedded TPK, then you have some kind of potentially recursive situation (as Marcus pointed out). it's also strange because a TPK is not a static entity -- it changes over time as the composable certificate mutates. So embedding such a thing in a self-sig is looking at a particular version, and implies things like expiration, etc. we don't want an endpoint that is trying to process a designated revoker to be distracted by the additional non-public-key packets. it's also not clear that an embedded TPK subpacket in a self-sig that also has a "Revoker Key" subpacket is necessarily referring to the revoker key itself -- the semantics are potentially ambiguous, as an embedded TPK subpacket in a different signature packet would have different semantics. I'm not fond of that kind of ambiguity. Additionally, what if there are multiple embedded TPK subpackets, or if the embedded TPK subpacket's primary key fingerprint doesn't match the "revoker key" fingerprint? Finally, if a client processes a direct-key signature with a "revoker key" subpacket that *doesn't* have an embedded TPK, they're just back in the soup. I think the deprecation story is clearer to just burn the old subpacket type entirely (it was originally specified very much in v4-only mode), and have an unambiguous subpacket for this use case. It is at least marginally simpler for an implementation to say "i don't support 'revoker key' but i do support 'designated revoker'" than it is to say "i only support 'revoker key' if it is in a direct key signature that contains exactly one embedded TPK whose primary key fingerprint matches the 'revoker key' fingerprint".=20 In general, i think we should not aim for maximum flexibility in the format specification, because that flexibility is a major cost for implementers. I'd rather identify the specific use cases we want to support and clearly and unambiguously ensure that the spec meets those use cases. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXUIPqAAKCRB2GBllKa5f +LFNAP0fQq8KNtGab4Ugg+LyyPi2pvb4+tFOvku4QjKKA5GpCwEAtZDoKwfcT0wB P08N+Bwf2kJhhs+OQtrhlxePLNb0ng4= =IIGx -----END PGP SIGNATURE----- --=-=-=--