From nobody Fri Feb 5 09:23:31 2021 Return-Path: X-Original-To: openpgp@ietf.org Delivered-To: openpgp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 350083A13B1; Fri, 5 Feb 2021 09:23:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: openpgp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: openpgp@ietf.org Message-ID: <161254580617.29620.7114088127291075805@ietfa.amsl.com> Date: Fri, 05 Feb 2021 09:23:26 -0800 Archived-At: Subject: [openpgp] I-D Action: draft-ietf-openpgp-crypto-refresh-01.txt X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2021 17:23:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Specification for Pretty Good Privacy WG of the IETF. Title : OpenPGP Message Format Authors : Werner Koch Paul Wouters Filename : draft-ietf-openpgp-crypto-refresh-01.txt Pages : 94 Date : 2021-02-05 Abstract: { Work in progress to update the OpenPGP specification from RFC4880 } This document specifies the message formats used in OpenPGP. OpenPGP provides encryption with public-key or symmetric cryptographic algorithms, digital signatures, compression and key management. This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-openpgp-crypto-refresh/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-01.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-openpgp-crypto-refresh-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 5 09:55:30 2021 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 5B9823A0DB3 for ; Fri, 5 Feb 2021 09:55:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=nohats.ca 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 6MCAknaK7sAI for ; Fri, 5 Feb 2021 09:55:26 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 18CEF3A0DAD for ; Fri, 5 Feb 2021 09:55:25 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4DXNP7077pz9nn for ; Fri, 5 Feb 2021 18:55:23 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1612547723; bh=op5pH4LrXRr5IiLw+IUMiYVY4/etvLgs23UWYIbWIX0=; h=Date:From:To:Subject:In-Reply-To:References; b=QfN1g/6KUYEyR+lyvQx3Tse5U3/ZCG07tPTFSOkU8oFTjNQMDuaf273VbWqE8Ujj3 8vECM09gMAwd6iHB0ABYzzhU5dTu793KSR2QqAH4bGZfUscOpgEgJvm1Wi9P3wYNz/ 0t7Jco1vCX9BfEsC5iEZe+4eLyyaSQPoRIHISckk= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id yh6LRUUu6Vr9 for ; Fri, 5 Feb 2021 18:55:21 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Fri, 5 Feb 2021 18:55:21 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 4833A6029B62; Fri, 5 Feb 2021 12:55:20 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 3EAF066B1E for ; Fri, 5 Feb 2021 12:55:20 -0500 (EST) Date: Fri, 5 Feb 2021 12:55:20 -0500 (EST) From: Paul Wouters To: openpgp@ietf.org In-Reply-To: <161254580617.29620.7114088127291075805@ietfa.amsl.com> Message-ID: <44a9245e-d6af-8919-6d35-3c7672bfa54b@nohats.ca> References: <161254580617.29620.7114088127291075805@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [openpgp] I-D Action: draft-ietf-openpgp-crypto-refresh-01.txt 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: Fri, 05 Feb 2021 17:55:28 -0000 On Fri, 5 Feb 2021, internet-drafts@ietf.org wrote: > Subject: [openpgp] I-D Action: draft-ietf-openpgp-crypto-refresh-01.txt We just submitted -01 version. You can see the diff here: > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-openpgp-crypto-refresh-01 You can also look at the working group git repository. The changes in this document are: Update introduction Update version terminology around old PGP versions. normalize punctuation and capitalization refer to SHA2 hash algos as SHA2-XXX, not SHAXXX Fix erratum 2271 Fix erratum 2270 Fix erratum 3298 Fix erratum 2242 Merge Camellia references (obsoleting RFC 5581) Identify RSA Sign-Only by algorithm number Drop unused reference to RFC 1423 drop unused reference to MAURER normalize on upper-case hexadecimal clarify blank lines and whitespace These changes should only represent what the WG previously thought it had reached consensus on. If you see anything where you think this might not be the case, please discuss that on the list here. If you have read the -01 (and -00) version and it all looks good, feel free to also let us know here on the list. Paul & Werner From nobody Fri Feb 5 11:14:43 2021 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 5F5633A0EE6 for ; Fri, 5 Feb 2021 11:14:42 -0800 (PST) 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, NICE_REPLY_A=-0.001, 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=cs.tcd.ie 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 BehSmJvUXff9 for ; Fri, 5 Feb 2021 11:14:40 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 242FF3A0EE1 for ; Fri, 5 Feb 2021 11:14:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D01DCBE50; Fri, 5 Feb 2021 19:14:37 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y80s-Q9G-BpD; Fri, 5 Feb 2021 19:14:36 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2A1B4BE47; Fri, 5 Feb 2021 19:14:36 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1612552476; bh=OsjzB94nB5/VCiKRBHx9tyt+fYc5gCbNGsGcoWBT5co=; h=Subject:To:References:From:Date:In-Reply-To:From; b=M3Q5wEPcp+GVBxgykQfFPVjJgmoa9kqXl7UOTCY5ew0En7BoyxUMQQ2j/nJ2FSsGC rAGc9ba/OKimEEw4XgOyDl2ut7fZ7/zxk1/lZWmkEymMj1TojiueSSaIYOHqFKKy3F YLvCP/63kYmsAeaiwFUSGmC0GBFA/uNj3XRXbotM= To: Paul Wouters , openpgp@ietf.org References: <161254580617.29620.7114088127291075805@ietfa.amsl.com> <44a9245e-d6af-8919-6d35-3c7672bfa54b@nohats.ca> From: Stephen Farrell Message-ID: <42567509-8e46-701d-e435-a8cf2b6cab64@cs.tcd.ie> Date: Fri, 5 Feb 2021 19:14:35 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: <44a9245e-d6af-8919-6d35-3c7672bfa54b@nohats.ca> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="m6e31YXnOijEEzafhxu9rxJK2CDC2rj2G" Archived-At: Subject: Re: [openpgp] I-D Action: draft-ietf-openpgp-crypto-refresh-01.txt 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: Fri, 05 Feb 2021 19:14:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --m6e31YXnOijEEzafhxu9rxJK2CDC2rj2G Content-Type: multipart/mixed; boundary="xi0oeARJGLdX206KzNOITsuqNKrSoSsZ3"; protected-headers="v1" From: Stephen Farrell To: Paul Wouters , openpgp@ietf.org Message-ID: <42567509-8e46-701d-e435-a8cf2b6cab64@cs.tcd.ie> Subject: Re: [openpgp] I-D Action: draft-ietf-openpgp-crypto-refresh-01.txt References: <161254580617.29620.7114088127291075805@ietfa.amsl.com> <44a9245e-d6af-8919-6d35-3c7672bfa54b@nohats.ca> In-Reply-To: <44a9245e-d6af-8919-6d35-3c7672bfa54b@nohats.ca> --xi0oeARJGLdX206KzNOITsuqNKrSoSsZ3 Content-Type: multipart/mixed; boundary="------------675DA2DD3055C32811327F56" Content-Language: en-US This is a multi-part message in MIME format. --------------675DA2DD3055C32811327F56 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Thanks Paul and Werner! On 05/02/2021 17:55, Paul Wouters wrote: > =C2=A0If=C2=A0you=C2=A0have=C2=A0read > the=C2=A0-01=C2=A0(and=C2=A0-00)=C2=A0version=C2=A0and=C2=A0it=C2=A0all= =C2=A0looks=C2=A0good,=C2=A0feel=C2=A0free=C2=A0to=C2=A0also=C2=A0let > us=C2=A0know=C2=A0here=C2=A0on=C2=A0the=C2=A0list. Yes please - it'd be good to get a few such mails, so we know people are checking and all seems well. About 4 or 5 acks should be plenty if nobody finds problems. Thanks, S. --------------675DA2DD3055C32811327F56 Content-Type: application/pgp-keys; name="OpenPGP_0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="OpenPGP_0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh5= Cg8 gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+QtaFq= 978 CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGu= D/Q 9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4= tNn cejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqB= wV+ 4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghVB5Uir= 1GC YChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5FmBKjG7cGcpBGmWav= ACY Ea7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK7uB7E7HlVE1IM1zNkVTYYGkKreU8D= VQu 8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER= 8la 5lsEEPbU/cDTcwARAQABzSFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT7CwX0EE= wEI ACcFAlo9UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qGC= xAA pYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKkrRl8beJ7j1CWX= Az9 +VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBrsjC+1uULaTU8zYEyET//GOGPL= F+X +degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZsdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4= g1U QAcCA4xlucY8QkJEyCrSNGpGnvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advre= k3U P71CKxpgtPmkd3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2= niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBGFEZYJGuaL= 4Nw tBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wVN3p46RyBQuXqJV8ccE11m= 6vt ZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8vovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7= +8A CcxRU3b9Ihd7WYjJ+pQPCoWYKozvtEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQ= LvC wFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8= rpK o9OkCz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqmuKhYr= qJs CcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMTAAr2p7PSaHgo+hIVa= W/r KSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQIAQlFxtgvOqpPOZNzeKBa/+KbE8TG= gMW rkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3u= rqR 1cLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/= 0A9 J9nrnBMqZpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5hc= JBD EN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPpMyEs04zvsbsl4= vrp 2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouBur45UDKTZkMZrr9FGrtkyXCGA= xvK dcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQyoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaK= xlf tjO+Bj3Jj73Cr5eqej3qB5+V4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjg= Uky o1s4vjUOY8DyI+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIO= aHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg2YVf0izSp= yyz JeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc/MoSjTS65vNWbpzONZWMZ= uLE FraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5w= sDc BBABCgAGBQJbxcflAAoJEGo7ETk8pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer= 3UM TVQg10vpa7pmqOGhjIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCP= jt5 uAxmbBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6+uWyK= 171 RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh5EQsn0pIh9wZIAbMR= Lpg RKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6KLChn2aEHQd+PdY1GBpZEcmNEUPuov= wza tM0h64hCzTm41eDqRfihZVBT7TbfXQnv8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0= zG3 6VdZTQF7TF/4Lz7/3cJ56jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQ= eah r2ez3DRBg3qsHEjBV80yU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQ= GNz LnRjZC5pZT7CwYAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o= 3cC GQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKo= w5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3h= Rcs RvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmC= Y98 iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jd= h2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4= EIk CXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZ= DIJ pdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelceZTzC4= tvy a7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4= ul3 qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIc= G9g ivQd8MxYNAbNYgSPtkbhZ8TCwFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGt= w/r 1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZ= Jaf 3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u1= 4Q0 7+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGf= qtu Sw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/C= gHw 26293tlve2Q6UTrmHxP5U22DlsLBfQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKC= wIE FgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eL= rfb e5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWF= etu O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8= v39 +qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr= 1oD 3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Pr= m2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yoby= y/A UOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxO= jao P0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPkhnwYz= leL Z7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC= 2X4 pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jsLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g= 1MS BQJbtySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/l//34= YT0 auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX4Iec8+9ot6tIVg4sb= edD Sgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo7kD9FDHCjRN8XfhHQ4Q9cYyt06uF3= 1qG /aumgWYC9geCGgAwiHgwxNYb9GoJ0iZjCROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcV= YW6 R0a3Ra8KudX+nt25H5DRGd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg= 4Im VOLGqsUgVm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGxm= qyH eLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88zllsqhZAFQjNx= qnk SzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2EtMBhgojWwrGMvdLN6X3mnzNJ= Esc YyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezIz60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n= 2Hw xyRL5dVMyMdyQmntubbctfqrZ0tIwsDcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4F= eIY jlIXGghFWzsB4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8E= AuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwlvpNwiiBr4= 2AY R751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGkbPlPkztahsFqktgacIgXH= X5v aT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joBp823L7r5KfpqWTPpSCzVstQKZUGmmoE1q= Csw Y/Ud5wvp9SccpIILkRXj0rZRtfnE5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tq= yA4 3niUMy2n6q690of3berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7m= Eer 0rCL3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP80uU3RlcGhlbiBGYXJyZWxsI= Dxz dGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPsLBfQQTAQgAJwUCWj1RWgIbAwUJCZQmAAULC= QgH AgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZ= i0B igofkbcGfdhJyMSs19C0dhvncrAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhn= i9g OJLlUpXViQtgrlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTy= sIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1n= 66v xxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIqhCljJ9x40Fkn/= 3r2 BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjM= YtU N1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr= 5iW XO3qx1HtEiGEqkporMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/= zek ZyXRdS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78b= a0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdMLAXAQQAQgABgUCWj1SoAAKCRAvP= Ic2 gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06TQgW5wsqtNcrwn81yZTq6= XE6 i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I1= 16u /HwA9/FXsPo5isbh4ZqD4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/J= G9a SSYvk3lznNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IW= OMq N2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBwsFzBBABCAAdFiEEfhcKBFyEz= 0YO K3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0H6FJ23A9Ftpy+aXZ4= vYl zkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQOJSSHbQ49BFRLwb1J/wBZG4bbmrkLx= nNb KDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrhB+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+= 5HN HltSL3DF1c2fFOf2JrgBKVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq= 4hn l5+VC/48ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPwn= Zbg JO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2MvoolsW08FiZh3Ej4d= nJj j25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJlMbVLrMo2GXeo03OzNyvbs+u8= WLI aGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilc= dPC Yk4BsOlzpwwO74hNG7iyl0KdAlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTX= o4+ Ira2JUErL2cYzQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YvCwNwEEAEKAAYFAlvFx+UACgkQajsRO= Tyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04fZ2Ry4nF9= hZM 0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4NkC9JMpecfq62/teOAU2e5= P3f WYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOosp= cL2 lJTmy8e3r79R24hPlSB4LDe0wEN8AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbk= etP GRmWvx5xUvb2ALFBBdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3= zRq k3mttto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+QgevYE0= 20q pKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7vxflUEDuzsFNBFo9U= DIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4HJee+R9+5x= /nL PCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHE= hOV fBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1D= VI9 DYo2D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbT= uW/ eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yD= aWT 3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDPck/Q6= 1df mr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8= MAv 2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOA= HZR 5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQo= qj1 gwARAQABwsFlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6= Mas qXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOxi= RkM dNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB= ++/ KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lX= xMD rvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrf= ZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN= 2OE 0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHT= zcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7= IKP 3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeW= Iys s6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3D40Nd -----END PGP PUBLIC KEY BLOCK----- --------------675DA2DD3055C32811327F56-- --xi0oeARJGLdX206KzNOITsuqNKrSoSsZ3-- --m6e31YXnOijEEzafhxu9rxJK2CDC2rj2G Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAmAdmRsFAwAAAAAACgkQWrL68XsXK+q4 KQ//VTkN34Fqqp7g08W1JvfXzxgXySlNX5ka0ioLe5lAthDyz1NFhzQtG123dh0mDY06Voii7fQ+ lCkB5hEqZivSxinxNaxYUG5pfvE+c9FjQt0XApKJyIPtGgoxjxnWcsUcdTwLdGcDYaDQO7SzQbO5 bJc/DfvPaPMJz0MTWadCGk8jlbp5wrbGseCddsWCCR3TJ6Dg8LRWCCp3Byf+ZInSIVC4bQ9Ebv0l vpe4ZUWNJCSwLWXlTump9fH/hjH9skXXXxFAhgFxPxI7K7/Ss/xhVdpMpVVAw6vDXU+dkRHhuvfh 0TbtVGP288jfi1wE85LgXaGLg5gs22FL+PRfmO3ulYTFVFHf8gGEsyxJyo27yNKirjdGsnOn9qR+ dxsheM8YWEwDhPFbmr4fsce6DH0bgdDj27tVTs79M1PxKHExlOdOTkjd+gv4aZqxaer0sfHULEH7 ER48m/n3TTdxTWN8/qUwNktTR2eXoHvZN0+wP8kXnVTjuVc2hjq2A74iUIDStlU7QsEcmehwN2M8 wRYl8JCD6MCDX/d/YZ3GCu21QOLNKnyoQfJiK5iHbmbf25glOqn+feEwLnh7Aa5dwtL19Ey5t9++ J/Vh7f1oXT+oXC96YTyRjmW/lG4DUBAXp3pKFv3jgIGAtwdssDEEb0Bxf+2fF9oB9Zg0ed427WxV 7O4= =xwp6 -----END PGP SIGNATURE----- --m6e31YXnOijEEzafhxu9rxJK2CDC2rj2G-- From nobody Fri Feb 5 12:55:51 2021 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 EE8783A089C for ; Fri, 5 Feb 2021 12:55:49 -0800 (PST) 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_HELO_NONE=0.001, SPF_PASS=-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 FsWl4Q_5--fh for ; Fri, 5 Feb 2021 12:55:47 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54AA23A0888 for ; Fri, 5 Feb 2021 12:55:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 69CFF3899E; Fri, 5 Feb 2021 15:58:45 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id C85NYDo1RVZ8; Fri, 5 Feb 2021 15:58:44 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id D776A3898C; Fri, 5 Feb 2021 15:58:43 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 7FB738F8; Fri, 5 Feb 2021 15:55:43 -0500 (EST) From: Michael Richardson To: Daniel Kahn Gillmor cc: Paul Wouters , openpgp@ietf.org In-Reply-To: <87o8h7cgrq.fsf@fifthhorseman.net> References: <161193808437.14457.1252111225434038573@ietfa.amsl.com> <629addad-3dc3-a490-46db-5fafab95c7d5@nohats.ca> <87o8h7cgrq.fsf@fifthhorseman.net> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [openpgp] I-D Action: draft-ietf-openpgp-crypto-refresh-00.txt 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: Fri, 05 Feb 2021 20:55:50 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Daniel Kahn Gillmor wrote: > On Fri 2021-01-29 11:59:31 -0500, Paul Wouters wrote: >> The -00 document is just the re-generated version of RFC4880. The on= ly >> changes are the updated boilerplate and generating code differences = of >> the xml tools over the years, as well as the document author, role a= nd >> name/time of the draft. > Thanks for this, Paul! >> You can see the diff with RFC4880 using this url: >> >> https://tools.ietf.org//rfcdiff?url1=3Dhttps://tools.ietf.org/rfc/rf= c4880.txt&url2=3Dhttps://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-= refresh-00.txt Looks good to me. Some significant pagination differences later on, but the text all looks consistent. > I've proposed some document editing workflow clarifications over on > https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/31, includi= ng > an ephemeral section (to be removed when we make it to an RFC) that > describes how to collaborate on the document. Good. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmAdsM8ACgkQgItw+93Q 3WUeNAf+JajcvKe76haoeaZZdJhgtyKjPj+sb1I4EYYf6XLZvUvKhwBVvhs/a8No 4TbPT0skONGT/UQs0EB6RSxRoDFVWKY/S3svBqQVPSPXn2IN8Lo8DvCPgH3pZVl3 XERnLewkBfteRMwz8fYuWJQmkq7Mo5MInnCvE4TSxXlEhCSdsX4CymJIEVA7/3+L a/+Y2PeLLnBmqvg8zmlC9EU+XovUB4ROZd7pKbT7nmicsVmUEGBGu+f8VN3s+LOM sSdNRH4+0bTpBNpReIcHH9sycnanIJ9QcDPT8M+nkJ+dGvoNRR9XaMXLqJU4OwhC j26PagvGgIaNmjRlQCnPsVAWDiK7YA== =VINm -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Feb 5 13:07:55 2021 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 F30D93A0A8E for ; Fri, 5 Feb 2021 13:07:53 -0800 (PST) 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_HELO_NONE=0.001, SPF_PASS=-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 s_v7gZGFjCZw for ; Fri, 5 Feb 2021 13:07:51 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 427BC3A0ABB for ; Fri, 5 Feb 2021 13:07:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id A44793899E; Fri, 5 Feb 2021 16:10:50 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id vPLe7dPLLQQZ; Fri, 5 Feb 2021 16:10:50 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 3A4EC38990; Fri, 5 Feb 2021 16:10:50 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D271B8F8; Fri, 5 Feb 2021 16:07:49 -0500 (EST) From: Michael Richardson To: Daniel Kahn Gillmor cc: Paul Wouters , openpgp@ietf.org In-Reply-To: <87o8h7cgrq.fsf@fifthhorseman.net> References: <161193808437.14457.1252111225434038573@ietfa.amsl.com> <629addad-3dc3-a490-46db-5fafab95c7d5@nohats.ca> <87o8h7cgrq.fsf@fifthhorseman.net> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [openpgp] I-D Action: draft-ietf-openpgp-crypto-refresh-00.txt 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: Fri, 05 Feb 2021 21:07:54 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Daniel Kahn Gillmor wrote: > On Fri 2021-01-29 11:59:31 -0500, Paul Wouters wrote: >> The -00 document is just the re-generated version of RFC4880. The on= ly >> changes are the updated boilerplate and generating code differences = of >> the xml tools over the years, as well as the document author, role a= nd >> name/time of the draft. > Thanks for this, Paul! >> You can see the diff with RFC4880 using this url: >> >> https://tools.ietf.org//rfcdiff?url1=3Dhttps://tools.ietf.org/rfc/rf= c4880.txt&url2=3Dhttps://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-= refresh-00.txt Looks good to me. Some significant pagination differences later on, but the text all looks consistent. > I've proposed some document editing workflow clarifications over on > https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/31, includi= ng > an ephemeral section (to be removed when we make it to an RFC) that > describes how to collaborate on the document. Good. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmAdsM8ACgkQgItw+93Q 3WUeNAf+JajcvKe76haoeaZZdJhgtyKjPj+sb1I4EYYf6XLZvUvKhwBVvhs/a8No 4TbPT0skONGT/UQs0EB6RSxRoDFVWKY/S3svBqQVPSPXn2IN8Lo8DvCPgH3pZVl3 XERnLewkBfteRMwz8fYuWJQmkq7Mo5MInnCvE4TSxXlEhCSdsX4CymJIEVA7/3+L a/+Y2PeLLnBmqvg8zmlC9EU+XovUB4ROZd7pKbT7nmicsVmUEGBGu+f8VN3s+LOM sSdNRH4+0bTpBNpReIcHH9sycnanIJ9QcDPT8M+nkJ+dGvoNRR9XaMXLqJU4OwhC j26PagvGgIaNmjRlQCnPsVAWDiK7YA== =VINm -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Feb 5 13:18:02 2021 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 D28A73A0B02 for ; Fri, 5 Feb 2021 13:18:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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=pass (1024-bit key) header.d=ihtfp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T0-ivRoDbArn for ; Fri, 5 Feb 2021 13:17:59 -0800 (PST) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C1E43A0B01 for ; Fri, 5 Feb 2021 13:17:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id D79B3E2040; Fri, 5 Feb 2021 16:17:57 -0500 (EST) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 16756-07; Fri, 5 Feb 2021 16:17:56 -0500 (EST) Received: by mail2.ihtfp.org (Postfix, from userid 48) id ACED7E2046; Fri, 5 Feb 2021 16:17:56 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1612559876; bh=eXgu9E7hlqpWZasdwhiTx4ni1phoJSIbv7MBdBOupQo=; h=In-Reply-To:References:Date:Subject:From:To:Cc; b=lKFsoJE/bj4T+5sorOlIwg2aO85/g4+cFOOg/IkCFPBzTjTwWh1dc2HBugeOB3Hz8 6ZkfCPsWamwYrE6L8vgKxIYY2XD9RYxgxV0HUlNQwTySPBNIRLozdahQacVFOaMZll AaQpYaDzTcOwab69uN2ByiOktLv1/0g1v8wiZ9IQ= Received: from 192.168.248.239 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Fri, 5 Feb 2021 16:17:56 -0500 Message-ID: In-Reply-To: <24870.1612559269@localhost> References: <161193808437.14457.1252111225434038573@ietfa.amsl.com> <629addad-3dc3-a490-46db-5fafab95c7d5@nohats.ca> <87o8h7cgrq.fsf@fifthhorseman.net> <24870.1612559269@localhost> Date: Fri, 5 Feb 2021 16:17:56 -0500 From: "Derek Atkins" To: "Michael Richardson" Cc: "Daniel Kahn Gillmor" , "Paul Wouters" , openpgp@ietf.org User-Agent: SquirrelMail/1.4.22-14.fc20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Subject: Re: [openpgp] I-D Action: draft-ietf-openpgp-crypto-refresh-00.txt 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: Fri, 05 Feb 2021 21:18:01 -0000 On Fri, February 5, 2021 4:07 pm, Michael Richardson wrote: > > Daniel Kahn Gillmor wrote: > > On Fri 2021-01-29 11:59:31 -0500, Paul Wouters wrote: > >> The -00 document is just the re-generated version of RFC4880. The > only > >> changes are the updated boilerplate and generating code differences > of > >> the xml tools over the years, as well as the document author, role > and > >> name/time of the draft. > > > Thanks for this, Paul! > > >> You can see the diff with RFC4880 using this url: > >> > >> https://tools.ietf.org//rfcdiff?url1=https://tools.ietf.org/rfc/rfc4880.txt&url2=https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-00.txt > > Looks good to me. > Some significant pagination differences later on, but the text all looks > consistent. Ditto. The ToC doesn't include anything beyond x.y.z, and there is some differences in text wrapping and pagination, but I don't see any content differences. > > I've proposed some document editing workflow clarifications over on > > https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/31, > including > > an ephemeral section (to be removed when we make it to an RFC) that > > describes how to collaborate on the document. > > Good. I have no objection to this merge. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Sat Feb 6 04:43:59 2021 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 36C253A1215 for ; Sat, 6 Feb 2021 04:43:57 -0800 (PST) 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_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=my.amazin.horse 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 xJy4Hq-v56T5 for ; Sat, 6 Feb 2021 04:43:55 -0800 (PST) Received: from my.amazin.horse (my.amazin.horse [5.181.49.53]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1B6A3A1208 for ; Sat, 6 Feb 2021 04:43:55 -0800 (PST) Received: from localhost (ip4d17562c.dynamic.kabel-deutschland.de [77.23.86.44]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by my.amazin.horse (Postfix) with ESMTPSA id EF79171D20; Sat, 6 Feb 2021 13:43:53 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=my.amazin.horse; s=2020; t=1612615434; bh=NaXM4Ow6fM0kcJgZ/41Ym81U7KpW5S2gKST9OBnHxBA=; h=In-Reply-To:References:Date:From:To:Cc:Subject; b=skvY7+YU2qrzmi34oiaWF1zKF803IyS5JpSwfDcE4cG8M+7xxVwVVC3dsursHs8Wl mOPL3UKCo4/gigh1oiJiuBUsgIXEq1h65/Hkl4yuIgJuFhlg6GDkIOztDTv2Km96NL h10ILRXYet2Ox//X86977DQjSuDeKyvlZEqmsUxg= Message-Id: <2L2KDX15YBZ7W.3AUG9OZLSN823@my.amazin.horse> In-Reply-To: <629addad-3dc3-a490-46db-5fafab95c7d5@nohats.ca> References: <629addad-3dc3-a490-46db-5fafab95c7d5@nohats.ca> <161193808437.14457.1252111225434038573@ietfa.amsl.com> Date: Sat, 06 Feb 2021 13:43:51 +0100 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Vincent Breitmoser To: Paul Wouters Cc: openpgp@ietf.org Autocrypt: addr=look@my.amazin.horse; keydata=mQINBFAB3UABEADCyB/vbIBA3m1Bwc yjTieEMLySwYgt54EQ2hglOocdtIhqC+b05t6sLSkwx2ukxrU2cegnCBkdyF/FZ/+Et638CUEBbf 4bjplwpt2IPLazQgjkwjMuhz0OcYDpMhwimTvh3mIl+0wzpOts6mEmMw0QZdl3RXvIW+NSynOn7q mz/fAv4Htt6lv2Ka0s6R2voyi+5U7CcIqizPad5qZVn2uxmovcFreTzFt6nk37ZbbTfvA3e5F0bR RQeH3viT5XxpJF4Y76v/Ua+5N3Kd18K0sX85rD1G7cmxR2CZ5gW1X24sDqdYZdDbf10N39UIwjJH PTeuVMQqry792Ap0Etyj135YFCE0loDnZYKvy2Y1i0RuEdTUIonIHrLhe2J0bXQGbQImHIyMgB9/ lva8D+yvy2gyf2vjRhmJEEco7w9FdzP7p3PhKrUiTjRsjHw8iV8LOCFx9njZOq9mism9ZZ16tZpx 9mXOf11HcH1RtVuyyQRS/4ytQPzwshXdSDDW6Btkmo9AbZQKC54/hSyzpp3Br2T2xDH7ecnonDB/ jv8rWuKXSTbX3xWAIrNBNDcTYaNe4jkms4HF7jJE19eRlqsXMMx6Fxvrh4TtKICwJYJ3AUmXrK3X Ti/mjqYfJ1fpBn54rWs8nhSR1fuZPD+aMlcP8BDUPlNKPKtj0DGSh3/VlnnwARAQABtClWaW5jZW 50IEJyZWl0bW9zZXIgPGxvb2tAbXkuYW1hemluLmhvcnNlPokCOAQTAQIAIgUCVTNZmgIbAwYLCQ gHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQe9GDIN6t+hHcVg//aeiijNqsQ3pjbFQn3VvND7hNfJ vrVcLZ+U4kOzXPF818aVdOnDyNXyE17vBDDcvaZ730sCsZIRZJ3KhUJ+nPvdttKjUIGLARmx+pA3 Jl3IIv2uLtOb3I0TMuyfIGJVGF+q10/CeDMKVjKlmyOVrR0opkel+KEoN7VLq3Hf3zPKENO1HBgp LHeP31tlb9cgs+u4o2wLrVe9myHbuFBW7EjWbSvdz2zliwbsFeFVLMNcWrKAU0GkkiH69SgnwmXU RkhGma4L27GLtkHHufsxfbcPqPtmtCttsGZU4EmrghGUqVyDOxnn8ZqybzLrRfpin+OCIX+aHJz5 r2L8qtrP0LorNMX3Gopd26vfhNvq/wq8xk++bW1R5FmkaUhx9h+DhO2ybcg7p/E8JHc8zrWv+bb3 0o9lkrOaU8GxXrgtb1cjtbb+MxFvjm0Elw7MSZDG7sF/APFU6cwuIA9Nai/OGAUCSt/W2ecS8Zox cWWbGSEiDvjtEctkpmHjfVuGoL34966Olm41VdH+NjgoSYUJKx4Mty8DRcZxdyoXll84LvDkEEYK ZqOIACsJf8CDFvUkmhXc+moCj15Yxtj3/RslRVEiOUyrpDwB72zWcZG8YnzoyGxhcRIc/gFejO/y SI8bzCpYngeuTb5NjFG+ChGiInHbQcFeHBlaHtKi2o/B5axIO5Ag0EVDvOgQEQALJby/ztliToGE u1lslvWQUQ6teKZVUQ7hy9bM4N83G0AGLatUBHtY6PkJBe4XkIw3sK7LoFCV2W4GSt4zWp9l+kG3 /J8Ow7EFjN0F7DrCg0M0lMg9dQz9jYSoBR8skaH3BRzCq9AKIVKV94poL/G65289L7zKDHoZnnyF qbBtedYZir0SZx+kiouZ1qnmxRPaYmH2fkuiuvYEAyzLDLYM8F5gQhdZM4YVtuvSICYPet0z4CDi JX/vZmDi3AzzoEVaKeAM/0H9f9Ni547J2+8dZSllgTrA+fq0aMJVScAObIxTAQtEq0DoNBzPpVrm W10b4bmgePrAvNkifqSr5StymSBgwvoeW6GrJiyN4XhoLOadZzwgjqioR1nXw5tXtrr5sYdkZ06b 1WWHkxtu1hFTdLC7RYNxY07ytLNM+C2lplCwCwlWB7RwI9BL1Dhre4kv8uaaX2Gksaq9mDf9MSDW qQ0TJ/RAiwMGmFrzBEYI1J2Oyeshi/dqW4/OiZAukOIlxOnt6u8zU2KL6Qjxqqna0oTbS4Zv3fRd YkuUCL6CDEJdkuRAiW+Gw+lKcMjXqApEqixhaDkoB/kwtu+2gIFTzAxMfwFN1YtNc0kJZWnFkGIW MrrwTcOwAFzlFz7wn/EyMFtg+ERcqMX0+olXDwM8MODI2+BzulPuEDEteCw09hABEBAAGJAh8EGA ECAAkFAlQ7zoECGwwACgkQe9GDIN6t+hFjuQ//UQyg49f8TytUYQaBb8R0UfI+KhQFs1Nsz2z8a3 0CD1MeiHHYWdAcomVvTkg4g5LbnYHVDrj/XagY3FN/AIE97usFbsTG+rsWAOLi7N2dN2ehWZ634k MvrgyC9uTiOdkw31+B8K5MpyySgD8e6SAzRfiu06/bcQOUyJifw8Hudpj9by4uyGhSH+kHu4afrp OduUighbsGFtcuRwwQ/w/oSk68XvPUgiOQWMZh/pVoXdFyFvrt/hgArCi8dfy5UPK58nl7jPnu/I uQXrJ50nNAFIIxPVeo2/B83KAnEZPU+qWZsdba0V+FIIQQVizLtQFMuJJk4/UTAOfJ2tBpQ9PADX 6/scqDE7unXNWdxcHTjK7KmWjXC8CyhGOx8V/rb7Ial4mZo4cTED6SNlO7dV1XYwnSctL2HCYNM3 RUe4eJ7JWuu7/Nbf6yip2eq7BQKZ9hAH/se/OSZNYsEkZ4pxUc8W5U3uAZImUwC6L74SM0jBZIuD mQhOYX6sZZ6urIn/MYlj4/hqSBFS4vTK7nXRLmtr7+5T5U5srVseUiYc+l9pu9/XD8zGIu+M2xEd 41NwP44GDQTQm0bFljRv5fSblwmi56YHPFQUIh2RZNX3kOJgeyQ3enw5uY+7ocKRVP38hpnffliL lJcO6TtHWnElS3pACbTQM0RHJox3zqU3q6K3c= Archived-At: Subject: Re: [openpgp] I-D Action: draft-ietf-openpgp-crypto-refresh-00.txt 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 Feb 2021 12:43:57 -0000 The whitespace of the listing here looks slightly funky, not sure if it's intended like that?: https://tools.ietf.org//rfcdiff?url1=https://tools.ietf.org/rfc/rfc4880.txt&url2=https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-00.txt#part-21 Otherwise, I found no issues 👍️ - V From nobody Sat Feb 6 09:08:40 2021 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 743983A1308 for ; Sat, 6 Feb 2021 09:08:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.306 X-Spam-Level: X-Spam-Status: No, score=-1.306 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=/RiL2u4H; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=bHLMkQcH 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 9ovq6mpefCUr for ; Sat, 6 Feb 2021 09:08:38 -0800 (PST) Received: from che.mayfirst.org (unknown [162.247.75.117]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0CC73A1461 for ; Sat, 6 Feb 2021 09:08:37 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1612631313; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=GwVefirC/x+G98v9P70PveeWcHolYE3Z4yGRvutEBl4=; b=/RiL2u4HJBtg0PiqtRoNthhnstJEc+1LGwYqOMNcCAqCQgWuy1RV3NH7EAPltZpI76GEQ dP6MeKjM1MmypaGBA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1612631313; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=GwVefirC/x+G98v9P70PveeWcHolYE3Z4yGRvutEBl4=; b=bHLMkQcHxFpnZGssV7Jrv1SjvYQ8m/fVs4oxurIETZH6QD7kTs6aW52+mmroL64CX9OiL JGmDmiZBRMV3zity/1wJhyAFrxfcSfYAPjqNd5D1tXA7yVOYTJ91rlQejpafBB0RJmqodo7 sUsNGESS0axoaC8Qfo5/gOHsl0AMlhD2WhfIq5BK9UE6Sm34CRdefrp45qKi1QZOAS6p1wL p0AeZzqnAbBx4SMBb54dVx0j90ogAUTZ1Pqo72M6r9wp+PnJFMgJTxYHA65vzloRukcQBHu HDGDFiDnDgZ6H+p3XdSrVPqvNUl6war98JrY8Hzq3/WBYtIxGtCdM0Lg7YSQ== Received: from fifthhorseman.net (lair.fifthhorseman.net [108.58.6.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 6C6D0F9A6; Sat, 6 Feb 2021 12:08:33 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id E9064205A5; Sat, 6 Feb 2021 12:07:54 -0500 (EST) From: Daniel Kahn Gillmor To: Derek Atkins , Michael Richardson Cc: Paul Wouters , openpgp@ietf.org In-Reply-To: References: <161193808437.14457.1252111225434038573@ietfa.amsl.com> <629addad-3dc3-a490-46db-5fafab95c7d5@nohats.ca> <87o8h7cgrq.fsf@fifthhorseman.net> <24870.1612559269@localhost> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEX+i03xYJKwYBBAHaRw8BAQdACA4xvL/xI5dHedcnkfViyq84doe8zFRid9jW7CC9XBiI0QQf FgoAgwWCX+i03wWJBZ+mAAMLCQcJEOCS6zpcoQ26RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNl cXVvaWEtcGdwLm9yZ/tr8E9NA10HvcAVlSxnox6z62KXCInWjZaiBIlgX6O5AxUKCAKbAQIeARYh BMKfigwB81402BaqXOCS6zpcoQ26AADZHQD/Zx9nc3N2kj13AUsKMr/7zekBtgfSIGB3hRCU74Su G44A/34Yp6IAkndewLxb1WdRSokycnaCVyrk0nb4imeAYyoPtBc8ZGtnQGZpZnRoaG9yc2VtYW4u bmV0PojRBBMWCgCDBYJf6LTfBYkFn6YAAwsJBwkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3Rh dGlvbnMuc2VxdW9pYS1wZ3Aub3JnL0Gwxvypz2tu1IPG+yu1zPjkiZwpscsitwrVvzN3bbADFQoI ApsBAh4BFiEEwp+KDAHzXjTYFqpc4JLrOlyhDboAAPkXAP0Z29z7jW+YzLzPTQML4EQLMbkHOfU4 +s+ki81Czt0WqgD/SJ8RyrqDCtEP8+E4ZSR01ysKqh+MUAsTaJlzZjehiQ24MwRf6LTfFgkrBgEE AdpHDwEBB0DkKHOW2kmqfAK461+acQ49gc2Z6VoXMChRqobGP0ubb4kBiAQYFgoBOgWCX+i03wWJ BZ+mAAkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3Jnfvo+ nHoxDwaLaJD8XZuXiaqBNZtIGXIypF1udBBRoc0CmwICHgG+oAQZFgoAbwWCX+i03wkQPp1xc3He VlxHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnaheiqE7Pfi3Atb3GGTw+ jFcBGOaobgzEJrhEuFpXREEWIQQttUkcnfDcj0MoY88+nXFzcd5WXAAAvrsBAIJ5sBg8Udocv25N stN/zWOiYpnjjvOjVMLH4fV3pWE1AP9T6hzHz7hRnAA8d01vqoxOlQ3O6cb/kFYAjqx3oMXSBhYh BMKfigwB81402BaqXOCS6zpcoQ26AADX7gD/b83VObe14xrNP8xcltRrBZF5OE1rQSPkMNy+eWpk eCwA/1hxiS8ZxL5/elNjXiWuHXEvUGnRoVj745Vl48sZPVYMuDgEX+i03xIKKwYBBAGXVQEFAQEH QIGex1WZbH6xhUBve5mblScGYU+Y8QJOomXH+rr5tMsMAwEICYjJBBgWCgB7BYJf6LTfBYkFn6YA CRDgkus6XKENukcUAAAAAAAeACBzYWx0QG5vdGF0aW9ucy5zZXF1b2lhLXBncC5vcmcEAx9vTD3b J0SXkhvcRcCr6uIDJwic3KFKxkH1m4QW0QKbDAIeARYhBMKfigwB81402BaqXOCS6zpcoQ26AAAX mwD8CWmukxwskU82RZLMk5fm1wCgMB5z8dA50KLw3rgsCykBAKg1w/Y7XpBS3SlXEegIg1K1e6dR fRxL7Z37WZXoH8AH Date: Sat, 06 Feb 2021 12:07:52 -0500 Message-ID: <87zh0hnmzb.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] I-D Action: draft-ietf-openpgp-crypto-refresh-00.txt 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 Feb 2021 17:08:39 -0000 --=-=-= Content-Type: text/plain On Fri 2021-02-05 16:17:56 -0500, Derek Atkins wrote: > The ToC doesn't include anything beyond x.y.z, Does anyone have a strong preference about the level of depth of the sub-sub-sections included in the ToC? I think limiting to x.y.z is just an artifact of the current toolchain we're using, though i can see how comparing the ToC directly between this and RFC 4880 might be a nice-to-have convenience. I've asked Carsten on github if there's a way to adjust the depth of the ToC from markdown: https://github.com/cabo/kramdown-rfc2629/issues/99 I don't think we should block on this, but if Carsten (or anyone else) points to a straightforward way to change tocDepth to 4, i wouldn't object to applying it to the crypto-refresh draft. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQttUkcnfDcj0MoY88+nXFzcd5WXAUCYB7M6gAKCRA+nXFzcd5W XKRzAP4zBnuqpsbVaoC5M+UZ7Fp3CYeA1UoSruZu139m82lVPAD+Ps5HdWzbbv+P YahbCeGjcObhg5xdGbBWd7uV+/UzVwY= =1Rwi -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Feb 6 09:08:46 2021 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 C6D1D3A1308 for ; Sat, 6 Feb 2021 09:08:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.306 X-Spam-Level: X-Spam-Status: No, score=-1.306 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=bgUWQhYP; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=TysSPYxp 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 9Ny3DOYOilK9 for ; Sat, 6 Feb 2021 09:08:38 -0800 (PST) Received: from che.mayfirst.org (unknown [162.247.75.117]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 109413A147D for ; Sat, 6 Feb 2021 09:08:37 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1612631313; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=7B9aSf4g+/HOQUdXyGlLUfkTJJTJdfSgOJHM+3oDnrc=; b=bgUWQhYPR7tCUlVb7Im8/Y+TcQk9TpcqcRSylVcBxzrhlEoiK+J68tvHuYYXRPXec62mL LKWxI68QtXU3SCLCg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1612631313; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=7B9aSf4g+/HOQUdXyGlLUfkTJJTJdfSgOJHM+3oDnrc=; b=TysSPYxpCC/eCavapK71HyY6N2M/X2SzMIL/l13n3G6Mt2FNQ/wrLtsNdUp1ro5eIwoNt 9Kcofezt7DApEpmWApWAPuNAozM8A6EbbgwBBwcKKLFx+Ta0JKEAW9GJNVsn4Vmd2UQi0Wl hI7eA7z0wiuQtEOurvryNAT7KEG9cPdoXOT+9USZvLq3/RuF4Y5bEbYSviKXKuv+9Z6QSqn Lvlesn2qSYXeOLZLqGAk1weUUQbQnFM4QeZzyWgrX+Mbc/oq4TU/M4LNXQHWbjyAp2ZHSIe RJ1wMIWSo5tOmR0i+ss3Yyw/OmtLWVkgXRgLAAGXqOAnfQHf1BCQArSREMxg== Received: from fifthhorseman.net (lair.fifthhorseman.net [108.58.6.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 6DD12F9A7; Sat, 6 Feb 2021 12:08:33 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 12E922045A; Sat, 6 Feb 2021 11:44:19 -0500 (EST) From: Daniel Kahn Gillmor To: Vincent Breitmoser , Paul Wouters Cc: openpgp@ietf.org In-Reply-To: <2L2KDX15YBZ7W.3AUG9OZLSN823@my.amazin.horse> References: <629addad-3dc3-a490-46db-5fafab95c7d5@nohats.ca> <161193808437.14457.1252111225434038573@ietfa.amsl.com> <2L2KDX15YBZ7W.3AUG9OZLSN823@my.amazin.horse> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEX+i03xYJKwYBBAHaRw8BAQdACA4xvL/xI5dHedcnkfViyq84doe8zFRid9jW7CC9XBiI0QQf FgoAgwWCX+i03wWJBZ+mAAMLCQcJEOCS6zpcoQ26RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNl cXVvaWEtcGdwLm9yZ/tr8E9NA10HvcAVlSxnox6z62KXCInWjZaiBIlgX6O5AxUKCAKbAQIeARYh BMKfigwB81402BaqXOCS6zpcoQ26AADZHQD/Zx9nc3N2kj13AUsKMr/7zekBtgfSIGB3hRCU74Su G44A/34Yp6IAkndewLxb1WdRSokycnaCVyrk0nb4imeAYyoPtBc8ZGtnQGZpZnRoaG9yc2VtYW4u bmV0PojRBBMWCgCDBYJf6LTfBYkFn6YAAwsJBwkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3Rh dGlvbnMuc2VxdW9pYS1wZ3Aub3JnL0Gwxvypz2tu1IPG+yu1zPjkiZwpscsitwrVvzN3bbADFQoI ApsBAh4BFiEEwp+KDAHzXjTYFqpc4JLrOlyhDboAAPkXAP0Z29z7jW+YzLzPTQML4EQLMbkHOfU4 +s+ki81Czt0WqgD/SJ8RyrqDCtEP8+E4ZSR01ysKqh+MUAsTaJlzZjehiQ24MwRf6LTfFgkrBgEE AdpHDwEBB0DkKHOW2kmqfAK461+acQ49gc2Z6VoXMChRqobGP0ubb4kBiAQYFgoBOgWCX+i03wWJ BZ+mAAkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3Jnfvo+ nHoxDwaLaJD8XZuXiaqBNZtIGXIypF1udBBRoc0CmwICHgG+oAQZFgoAbwWCX+i03wkQPp1xc3He VlxHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnaheiqE7Pfi3Atb3GGTw+ jFcBGOaobgzEJrhEuFpXREEWIQQttUkcnfDcj0MoY88+nXFzcd5WXAAAvrsBAIJ5sBg8Udocv25N stN/zWOiYpnjjvOjVMLH4fV3pWE1AP9T6hzHz7hRnAA8d01vqoxOlQ3O6cb/kFYAjqx3oMXSBhYh BMKfigwB81402BaqXOCS6zpcoQ26AADX7gD/b83VObe14xrNP8xcltRrBZF5OE1rQSPkMNy+eWpk eCwA/1hxiS8ZxL5/elNjXiWuHXEvUGnRoVj745Vl48sZPVYMuDgEX+i03xIKKwYBBAGXVQEFAQEH QIGex1WZbH6xhUBve5mblScGYU+Y8QJOomXH+rr5tMsMAwEICYjJBBgWCgB7BYJf6LTfBYkFn6YA CRDgkus6XKENukcUAAAAAAAeACBzYWx0QG5vdGF0aW9ucy5zZXF1b2lhLXBncC5vcmcEAx9vTD3b J0SXkhvcRcCr6uIDJwic3KFKxkH1m4QW0QKbDAIeARYhBMKfigwB81402BaqXOCS6zpcoQ26AAAX mwD8CWmukxwskU82RZLMk5fm1wCgMB5z8dA50KLw3rgsCykBAKg1w/Y7XpBS3SlXEegIg1K1e6dR fRxL7Z37WZXoH8AH Date: Sat, 06 Feb 2021 11:44:17 -0500 Message-ID: <8735y9p2n2.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] I-D Action: draft-ietf-openpgp-crypto-refresh-00.txt 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 Feb 2021 17:08:41 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Sat 2021-02-06 13:43:51 +0100, Vincent Breitmoser wrote: > The whitespace of the listing here looks slightly funky, not sure if it's > intended like that?: > > https://tools.ietf.org//rfcdiff?url1=3Dhttps://tools.ietf.org/rfc/rfc4880= .txt&url2=3Dhttps://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refre= sh-00.txt#part-21 Thanks for noticing that, Vincent. This looks like an rfcdiff artifact due to how it tries to elide pagination issues between text/plain versions. This is in section 5.12, and you can see that section in the published document in text-ish form (html-wrapped plaintext): https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-crypto-refresh-= 00#section-5.12 or in "native" html: https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-01.htm= l#name-user-attribute-packet-tag-1 both of those seem to have the whitespace and the bulleted list looking reasonable. > Otherwise, I found no issues =F0=9F=91=8D=EF=B8=8F great! --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQttUkcnfDcj0MoY88+nXFzcd5WXAUCYB7HYwAKCRA+nXFzcd5W XIIUAP9ndp/w6vx9x26UT6fykinhm0TROUaAYFQrtLp9dztfGwEA2TMJT668xAwq hdmiUccOdR8/pExZV1zeCaREgotG/Q0= =F5Yz -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Feb 6 11:20:14 2021 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 623223A8B53 for ; Sat, 6 Feb 2021 11:20:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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=pass (1024-bit key) header.d=gnupg.org 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 Dhwq2S3NhiD6 for ; Sat, 6 Feb 2021 11:20:11 -0800 (PST) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (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 B2AB53A8B1A for ; Sat, 6 Feb 2021 11:20:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnupg.org; s=20181017; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=HHUkA8MSY6zPkwD1BQdfmt5sQc4IkvOPwOi3W2YxUs4=; b=UaorRBPyis6iH0Zv9ZyhMpkxwB cl1L/ejcQUM+9xmuNlM9u/eZCgtZNjhry3ADC9yzdz+Mhn/YRtAYdGaFvta5iwVHLXtCvKu/TwNDG RmMISNDb9omCaPx4L16rPMSBYc3BRcKbBywazYsrZ0fEHqQ3AEwK2pO3acBtFDYRr5qs=; Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1l8T7p-00039p-0T for ; Sat, 06 Feb 2021 20:20:09 +0100 Received: from wk by wheatstone.g10code.de with local (Exim 4.92 #5 (Debian)) id 1l8T4X-0001jC-H9; Sat, 06 Feb 2021 20:16:45 +0100 From: Werner Koch To: Daniel Kahn Gillmor Cc: Derek Atkins , Michael Richardson , Paul Wouters , openpgp@ietf.org References: <161193808437.14457.1252111225434038573@ietfa.amsl.com> <629addad-3dc3-a490-46db-5fafab95c7d5@nohats.ca> <87o8h7cgrq.fsf@fifthhorseman.net> <24870.1612559269@localhost> <87zh0hnmzb.fsf@fifthhorseman.net> Organisation: GnuPG e.V. X-message-flag: Mails containing HTML will not be read! Please send only plain text. Mail-Followup-To: Daniel Kahn Gillmor , Derek Atkins , Michael Richardson , Paul Wouters , openpgp@ietf.org Date: Sat, 06 Feb 2021 20:16:45 +0100 In-Reply-To: <87zh0hnmzb.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Sat, 06 Feb 2021 12:07:52 -0500") Message-ID: <874kipqa5e.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=Collapse_Sleet_Computer_infrastructure_Cypherpunks_Waco,_Texas=Traff"; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] I-D Action: draft-ietf-openpgp-crypto-refresh-00.txt 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 Feb 2021 19:20:13 -0000 --=Collapse_Sleet_Computer_infrastructure_Cypherpunks_Waco,_Texas=Traff Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 6 Feb 2021 12:07, Daniel Kahn Gillmor said: > an artifact of the current toolchain we're using, though i can see how > comparing the ToC directly between this and RFC 4880 might be a > nice-to-have convenience. We can also fix such problems in the final I-D and don't need to care about such editoral changes right now. As co-editor I obviously agree to -00 and -01. Salam-Shalom, Werner =2D-=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=Collapse_Sleet_Computer_infrastructure_Cypherpunks_Waco,_Texas=Traff Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQSHd0YfKgdOvEgNNZQZzByeCFsQegUCYB7rHQAKCRAZzByeCFsQ evfzAQCmorcglJFAnItIOOuvOP5n7YkIpQYhDQR4US+BmVjtEwD9GakVk9Qolwe2 DuhEGVSSFmWnTdDJbFJGy2J0qDWnNgw= =d76a -----END PGP SIGNATURE----- --=Collapse_Sleet_Computer_infrastructure_Cypherpunks_Waco,_Texas=Traff-- From nobody Sat Feb 6 12:16:46 2021 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 66C103A1562 for ; Sat, 6 Feb 2021 12:16:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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 rzAVsTSPnYbZ for ; Sat, 6 Feb 2021 12:16:43 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 077B83A152E for ; Sat, 6 Feb 2021 12:16:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1612642600; bh=mAQOqfmL5y1aoaDfpEuWDUEcajeZkkRIP/qSgYe9i7M=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=Im4UJ3Aw21Wya8F3di/jxoCdIPu1E07sWhOjLYWHF02s6ZRKcW0UE/SQIMTPTIfc0 0ZUSsR7OG/P0566gUh1pGR69idAogcFs2au+Z8JGr+Au7uST0MaXtWKh7t4kSeK+ak ya0uOs0V6NMYMGIJEDdV6WJqfeWKkHLUw0O5oum0= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.35] ([79.244.52.98]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MrQJ5-1lkWRr29dn-00oYlE for ; Sat, 06 Feb 2021 21:16:40 +0100 To: openpgp@ietf.org References: <161254580617.29620.7114088127291075805@ietfa.amsl.com> From: Heiko Stamer Message-ID: <76fe41fc-f14e-fe3c-db02-7e5b7629dc8a@gmx.net> Date: Sat, 6 Feb 2021 21:14:52 +0100 MIME-Version: 1.0 In-Reply-To: <161254580617.29620.7114088127291075805@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:rURJxGiQFKNxSfBDFZH4PJVmTfdQaplVm8xOE0kBymLQOjf9jZ2 BwmZC1YIqjnQ4beurozv5IQ/nHporNJ3mrY6M//NeMzoHlQcSFKU6cgmfswtk7j3+KeiRyU FTrdkPF+/DwKQvbEaFovbREsFEN/PDtlxKbCzG3r2+8oOPzfX3VkdT7HFrA1D2TWZdtTf/Y AgFl0F+KoYoYQ6a2BVh6Q== X-UI-Out-Filterresults: notjunk:1;V03:K0:CvJwvCZ+A9s=:ZL2G1/83h7r8D7zuGFG5PC k/SEmnzoWaZK/yMLN5MCraQGsc8pMa4XYjbjP7DndhTMZrwLJrgux5KaTyIbbv9eSx9nrhTn+ 6iz1U50Jh0Em996gnzmfBSSCJRJ5P3KZ3QJNcg/otbYlQjkWcTLGMh7OM+kAhStKvrumg9dQG mZudQCh16xxJhZLvrVKgBvoCLTwRMaXuSMYldvQb2R7OJvBkBM3dZy2BDhIdfNwZUqv0qEmDU 4JtB65lznUKt+Qg52DxeG0KnUnyO4gnWeqfsZG+PI7TUvL5nho6w99LnWq71P2a6srOfRBhY2 6kJlWTtjOB1LUIRgCvgLHQ2p6SzrjTrVu1m2LOothTbWV90K3TcebDyu/HuUSiCKr3IdR3QG4 p/pIZ8eHpNXPYmJ++Q2b+Z4rvdnFZLa2mXPVrLzJskoAk3iP/uZHABAoNGsfeokRuWpHkp77W m+joEghn4VsOK7M12Ed7ob4EyK3Nt5x9+dkBwA4C6affbwByeOAeBKUy9TTuUWAfjqGsGwqsP PyVslC8HMOaUFvaUGkQ9kIKF4zK0ooj8BS0dBJ6FUbRTAbDMDksD34BwG+J03GUYmkrtz24rt uc2BoqSVB0aq4DoTv3jLY20x/DYBWjRq4kFATW5I8qHJWyH59kqjqn6rCoQ31SINLWdQL7ikf IygK207amdFhHPOKvd8JB+JRWrxnEMWWy4TYnGyHtE8rnySmUgP3wJVPBKaG/vx7P5K+4R75L x9mO0TaENawRNjRO1AbKAil0Ob5zauNE2A89QrrjaquMJS80sJcr71jzF7tarAc6vwFRtBnzf M4MVlKIMvUk9zIbcozAsSmRTyzj1VJ6A3pI4rDFF02yv34nj53nuB7mdbUZV8MWi8eQDl2mOn KOBerV6Is2b+2oFuWGhQ== Archived-At: Subject: Re: [openpgp] I-D Action: draft-ietf-openpgp-crypto-refresh-01.txt 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 Feb 2021 20:16:44 -0000 Hey, I have a question regarding the change at page 59, line 28: "The blank line can either be zero-length or contain only whitespace, that is spaces (0x20), tabs (0x09) or carriage returns (0x0d)." For spaces and tabs the intention is clear for me, however, I am not sure about carriage returns in general. According to Unicode Character Database there are some other whitespace characters, e.g., form feed (0x0c). Should such characters be included, too? I am fine with this change, however, at least for DKGPG we have to adjust some lines of source code. Best regards, Heiko. From nobody Sat Feb 6 14:31:44 2021 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 341B83A2CB3 for ; Sat, 6 Feb 2021 14:31:43 -0800 (PST) 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_HELO_NONE=0.001, SPF_PASS=-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 lUnXYtU4uWHs for ; Sat, 6 Feb 2021 14:31:40 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B99203A2CB1 for ; Sat, 6 Feb 2021 14:31:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 182BC389A7 for ; Sat, 6 Feb 2021 17:34:43 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id hsPr-WTHxobd for ; Sat, 6 Feb 2021 17:34:41 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 981673899C for ; Sat, 6 Feb 2021 17:34:41 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 3BF85585 for ; Sat, 6 Feb 2021 17:31:37 -0500 (EST) From: Michael Richardson To: openpgp@ietf.org In-Reply-To: <44a9245e-d6af-8919-6d35-3c7672bfa54b@nohats.ca> References: <161254580617.29620.7114088127291075805@ietfa.amsl.com> <44a9245e-d6af-8919-6d35-3c7672bfa54b@nohats.ca> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [openpgp] I-D Action: draft-ietf-openpgp-crypto-refresh-01.txt 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 Feb 2021 22:31:43 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable looks good to me. Paul Wouters wrote: > On Fri, 5 Feb 2021, internet-drafts@ietf.org wrote: >> Subject: [openpgp] I-D Action: >> draft-ietf-openpgp-crypto-refresh-01.txt > We just submitted -01 version. You can see the diff here: >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-openpgp-crypto-refres= h-01 SHA224 | 0x30, 0x31, =2D> SHA224 | 0x30, 0x2D looks like an errata fix? (Table 5) I looked in gitlab briefly, but I didn= 't see this change quickly. Otherwise SHA224 is identical to SHA2-256, I think. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmAfGMgACgkQgItw+93Q 3WWYuAf9FA2hf1gF5GpRglN14koVzR4axVu//+sG3LnMVZfv6ja6F4W4ptITFybI K60xiTKao9gnroseqIvA1aqyza0trN8VyOF9VlkVPUOoK9PKCgDanl7a/rRlxoPC 69s3o8mE2BkKMSoTPPWGZFO63Pj+LancP3MhdL9jP8+wpdox3E2oKxGg1hf0NWXd kfebDakYluc0a+CNcqAvMR0ZxKCK7KJnAWVfRYe+HyzDskOozr7b6nbVqb+kacc8 VdJkA1l8lYRZvtI8Jm2qde3S/3ORLMbOLF4JKoVV+4Ccf2gLPLLqf/WD3ct8Q+dj vp9k4xs/SWPDEzW41f8qkHc2As/psw== =girn -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Feb 6 14:39:01 2021 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 E37423A2CC4 for ; Sat, 6 Feb 2021 14:38:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 (2048-bit key) header.d=posteo.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 8OBCdyC-wDMZ for ; Sat, 6 Feb 2021 14:38:57 -0800 (PST) Received: from mout02.posteo.de (mout02.posteo.de [185.67.36.66]) (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 C18A83A2CC3 for ; Sat, 6 Feb 2021 14:38:56 -0800 (PST) Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id 81EA02400FC for ; Sat, 6 Feb 2021 23:38:53 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1612651134; bh=owXyzK10thcQhlzn13qJuGHDeQhIUrDoCHHdHm4cC28=; h=To:From:Subject:Date:From; b=A8Rakb7BffwMJjgVyjN8GwgQYTIgwDY6Y5EWbbrcheWJqJbVSnEeo6ii0zbE2f/HQ SSVoTEJ3pElO6TP1McdN1qPVJkjy0Pl/uUQ7LrI8CMlfwxzJDk8vDOVNtVY88oZjjX E09QrfUWhZ/sFaKVnCEFjC40lNV6OTWGNtkeK6b0mKcgoLhzZ7Xl2X32A4eWglW6ER Khm/PfUs/Ia7PgxgN7MLzdZlsqBCSCuw8F4QRywnZsxPOrL29fwqSnU1yCZQ852YbW 7LdZf3lDtJ5MN/L9Fg37/Ra4Q/M4OmBz3Ok/dxHXeCV6VSYYWm0Ym+Y+PONAWEufgp ZzAR3eG/RujvQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4DY6dn17lNz6tmJ for ; Sat, 6 Feb 2021 23:38:50 +0100 (CET) Received: from [IPv6:::1] (daneel.foundation.hs [192.168.20.2]) by mail.foundation.hs (Postfix) with ESMTP id E752773C2F for ; Sat, 6 Feb 2021 23:38:49 +0100 (CET) To: openpgp@ietf.org References: <161254580617.29620.7114088127291075805@ietfa.amsl.com> <44a9245e-d6af-8919-6d35-3c7672bfa54b@nohats.ca> <31231.1612650697@localhost> From: Heiko Schaefer Message-ID: <6d97ee4b-21d5-e558-2bd9-3b33dfc4ae84@posteo.de> Date: Sat, 6 Feb 2021 23:38:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: <31231.1612650697@localhost> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [openpgp] I-D Action: draft-ietf-openpgp-crypto-refresh-01.txt 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 Feb 2021 22:39:00 -0000 On 2/6/21 11:31 PM, Michael Richardson wrote: > looks good to me. > > Paul Wouters wrote: > > On Fri, 5 Feb 2021, internet-drafts@ietf.org wrote: > > >> Subject: [openpgp] I-D Action: > >> draft-ietf-openpgp-crypto-refresh-01.txt > > > We just submitted -01 version. You can see the diff here: > > >> A diff from the previous version is available at: > >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-openpgp-crypto-re= fresh-01 > > SHA224 | 0x30, 0x31, > -> > SHA224 | 0x30, 0x2D > > looks like an errata fix? (Table 5) I looked in gitlab briefly, but I = didn't see this > change quickly. Otherwise SHA224 is identical to SHA2-256, I think. I had also wondered about that. The changes seems to be from https://www.rfc-editor.org/errata/eid2270 From nobody Sun Feb 7 02:25:58 2021 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 AA9BC3AFB99 for ; Sun, 7 Feb 2021 02:25:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 FDCEIIQpBNL4 for ; Sun, 7 Feb 2021 02:25:54 -0800 (PST) Received: from au-smtp-delivery-117.mimecast.com (au-smtp-delivery-117.mimecast.com [124.47.189.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E7DD3AFB0C for ; Sun, 7 Feb 2021 02:25:53 -0800 (PST) Received: from AUS01-SY4-obe.outbound.protection.outlook.com (mail-sy4aus01lp2174.outbound.protection.outlook.com [104.47.71.174]) (Using TLS) by relay.mimecast.com with ESMTP id au-mta-90-08GkU0f7MiC96vhjEkc4_Q-1; Sun, 07 Feb 2021 21:25:48 +1100 X-MC-Unique: 08GkU0f7MiC96vhjEkc4_Q-1 Received: from PS1P15301CA0020.APCP153.PROD.OUTLOOK.COM (2603:1096:803:2::30) by SY3PR01MB1994.ausprd01.prod.outlook.com (2603:10c6:0:21::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3825.17; Sun, 7 Feb 2021 10:25:44 +0000 Received: from PU1APC01FT022.eop-APC01.prod.protection.outlook.com (2603:1096:803:2:cafe::4f) by PS1P15301CA0020.outlook.office365.com (2603:1096:803:2::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3868.0 via Frontend Transport; Sun, 7 Feb 2021 10:25:43 +0000 X-MS-Exchange-Authentication-Results: spf=none (sender IP is 130.216.95.208) smtp.mailfrom=cs.auckland.ac.nz; gmx.net; dkim=none (message not signed) header.d=none;gmx.net; dmarc=none action=none header.from=cs.auckland.ac.nz Received: from uxcn13-ogg-c.UoA.auckland.ac.nz (130.216.95.208) by PU1APC01FT022.mail.protection.outlook.com (10.152.253.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.3784.11 via Frontend Transport; Sun, 7 Feb 2021 10:25:42 +0000 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) by uxcn13-ogg-c.UoA.auckland.ac.nz (10.6.2.4) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 7 Feb 2021 23:25:41 +1300 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::c123:782b:aed6:3e56]) by uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::c123:782b:aed6:3e56%14]) with mapi id 15.00.1497.010; Sun, 7 Feb 2021 23:25:40 +1300 From: Peter Gutmann To: Heiko Stamer , "openpgp@ietf.org" Thread-Topic: [openpgp] I-D Action: draft-ietf-openpgp-crypto-refresh-01.txt Thread-Index: AQHW++PL3wEJDkPwh0mOwQbphLkiWqpKt74AgAHHgKI= Date: Sun, 7 Feb 2021 10:25:40 +0000 Message-ID: <1612693541055.92697@cs.auckland.ac.nz> References: <161254580617.29620.7114088127291075805@ietfa.amsl.com>, <76fe41fc-f14e-fe3c-db02-7e5b7629dc8a@gmx.net> In-Reply-To: <76fe41fc-f14e-fe3c-db02-7e5b7629dc8a@gmx.net> Accept-Language: en-NZ, en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 9483ad46-9e9c-4b07-9356-08d8cb52b963 X-MS-TrafficTypeDiagnostic: SY3PR01MB1994: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8882 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0 X-Microsoft-Antispam-Message-Info: 1jj54zKLbjwpZWdUpOFHmhnG2FQNcSvDJpQdPSSDTGKsH5nSyTox8XH+45Zng81/+n/u0YhVBi843yWu1677zdgWqZtzAPda4jYUUEIklj7QPzKhMSaqWeDssegeSlwxG6+6t3IXM4KMM05rQjgDvQgIUHF2210V3VAFnHXCjYMUuVHn/41Yh/EFokQfnkEAio7eTjaGojYgsHme7o19xp4rqpYzw8kgdcm1ycPFAT8ca2WGQ5LgYvNmErySTd8ny+vRUc5XsJSft3CYXYRHM2dAgTEcePiWtsXrn5Jb+uBw4BX0dHKqaPxx/Gwx72ZAd2ovyFh3aK5i13FG/SxqgQuwKzzmrQ4BEUvNdkkEWkL/gi/0TTyDwLstVKUHfQQFVUKDkVRlD0SJSMb5RN+Nv0ZIwW+w13uKY2FSC8i2FXLVb8Wo1KIC40yfVlcVNk4T390GJpoGtGLMek224UJ+KHAU6FPyi3lA02sDNqR4mi3W+vrh4q9Oo3+UJs6ah9cKfyUIycztXRNeAnN+cf1UPW3XaAHWsP4iKT94dKrbLx0dJLvCouf/JsGoAmW5XaoF7SdagHxj50FVa00vboNi0isgqASYVqYGObntItWotVipCK5xGQiTkMg9mTCfn0z/t6Qg2Ayp2tuzI0tGAP9ftg== X-Forefront-Antispam-Report: CIP:130.216.95.208; CTRY:NZ; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:uxcn13-ogg-c.UoA.auckland.ac.nz; PTR:natgate1-1.auckland.ac.nz; CAT:NONE; SFS:(4636009)(376002)(346002)(396003)(136003)(39860400002)(46966006)(36840700001)(83380400001)(356005)(7636003)(86362001)(8936002)(36906005)(82740400003)(70586007)(70206006)(8676002)(316002)(786003)(2616005)(47076005)(478600001)(336012)(186003)(4744005)(110136005)(36860700001)(5660300002)(2906002)(82310400003)(26005); DIR:OUT; SFP:1101 X-OriginatorOrg: cs.auckland.ac.nz X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Feb 2021 10:25:42.6934 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 9483ad46-9e9c-4b07-9356-08d8cb52b963 X-MS-Exchange-CrossTenant-Id: d1b36e95-0d50-42e9-958f-b63fa906beaa X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=d1b36e95-0d50-42e9-958f-b63fa906beaa; Ip=[130.216.95.208]; Helo=[uxcn13-ogg-c.UoA.auckland.ac.nz] X-MS-Exchange-CrossTenant-AuthSource: PU1APC01FT022.eop-APC01.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SY3PR01MB1994 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: cs.auckland.ac.nz Content-Language: en-NZ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [openpgp] I-D Action: draft-ietf-openpgp-crypto-refresh-01.txt 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 Feb 2021 10:25:57 -0000 Heiko Stamer writes:=0A=0A>For spaces and tabs the in= tention is clear for me, however, I am not sure=0A>about carriage returns i= n general. According to Unicode Character Database=0A>there are some other = whitespace characters, e.g., form feed (0x0c). Should=0A>such characters be= included, too?=0A=0AThat also just seems wrong in general, the last major = OS type I know of that=0Aused CR delimiters was Mac OS from 1984. Shouldn'= t this be LF or CRLF?=0AWherever this came from, it's not in 4880, or any o= ther common RFC that=0Adefines a format for blank lines.=0A=0APeter.=0A From nobody Sun Feb 7 14:41:18 2021 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 F2E2E3A13FF for ; Sun, 7 Feb 2021 14:41:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=nohats.ca 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 FiV6K4ejKtxc for ; Sun, 7 Feb 2021 14:41:14 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 0CB563A13C5 for ; Sun, 7 Feb 2021 14:41:12 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4DYkdy2pQNzCvg; Sun, 7 Feb 2021 23:41:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1612737670; bh=CdaOVUH4xDt6v6iEsJh/6YrKleeFhjj80et/9KGTvow=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=ZIdY/fLpO2LJX1VfxkjmxGVcbewNqWvl0VN9fkEAoESeR10ET9jfUUigqXMmpbq/9 7TLyx48Zm424DZg0PLgqM4cdmI7Pa5cpeC7rj1z+Fs6z9XzowdFgJHAMRa8xvDJGnc Sw+wLCsFzvczkafmiVuF3OzGmELqjseOOYo7wlIA= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id upR_lZ-_HiLD; Sun, 7 Feb 2021 23:41:09 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sun, 7 Feb 2021 23:41:09 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id C757F6029B62; Sun, 7 Feb 2021 17:41:07 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id BEA8566B1E; Sun, 7 Feb 2021 17:41:07 -0500 (EST) Date: Sun, 7 Feb 2021 17:41:07 -0500 (EST) From: Paul Wouters To: Peter Gutmann cc: Heiko Stamer , "openpgp@ietf.org" In-Reply-To: <1612693541055.92697@cs.auckland.ac.nz> Message-ID: <6f1c429e-7a8d-1ce6-fda5-30ba2b326477@nohats.ca> References: <161254580617.29620.7114088127291075805@ietfa.amsl.com>, <76fe41fc-f14e-fe3c-db02-7e5b7629dc8a@gmx.net> <1612693541055.92697@cs.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [openpgp] I-D Action: draft-ietf-openpgp-crypto-refresh-01.txt 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 Feb 2021 22:41:17 -0000 On Sun, 7 Feb 2021, Peter Gutmann wrote: >> For spaces and tabs the intention is clear for me, however, I am not sure >> about carriage returns in general. According to Unicode Character Database >> there are some other whitespace characters, e.g., form feed (0x0c). Should >> such characters be included, too? > > That also just seems wrong in general, the last major OS type I know of that > used CR delimiters was Mac OS from 1984. Shouldn't this be LF or CRLF? > Wherever this came from, it's not in 4880, or any other common RFC that > defines a format for blank lines. Question for the WG. Should we change the text to make the entries "examples" of white space, or should we add a definition of white space? If the latter, what do the current openpgp implementations define as white space characters right now? Paul From nobody Sun Feb 7 21:09:32 2021 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 1F3E23A10DF for ; Sun, 7 Feb 2021 21:09:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 5ZwwgR319xFB for ; Sun, 7 Feb 2021 21:09:28 -0800 (PST) Received: from au-smtp-delivery-117.mimecast.com (au-smtp-delivery-117.mimecast.com [180.189.28.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00B3F3A10D8 for ; Sun, 7 Feb 2021 21:09:27 -0800 (PST) Received: from AUS01-ME3-obe.outbound.protection.outlook.com (mail-me3aus01lp2241.outbound.protection.outlook.com [104.47.71.241]) (Using TLS) by relay.mimecast.com with ESMTP id au-mta-101-AUNWuLTzMk-Evxe5XmSa8A-1; Mon, 08 Feb 2021 16:09:21 +1100 X-MC-Unique: AUNWuLTzMk-Evxe5XmSa8A-1 Received: from SG2PR01CA0102.apcprd01.prod.exchangelabs.com (2603:1096:3:15::28) by SY3PR01MB1227.ausprd01.prod.outlook.com (2603:10c6:0:12::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3825.30; Mon, 8 Feb 2021 05:09:19 +0000 Received: from SG2APC01FT015.eop-APC01.prod.protection.outlook.com (2603:1096:3:15:cafe::c) by SG2PR01CA0102.outlook.office365.com (2603:1096:3:15::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3825.19 via Frontend Transport; Mon, 8 Feb 2021 05:09:18 +0000 X-MS-Exchange-Authentication-Results: spf=none (sender IP is 130.216.95.208) smtp.mailfrom=cs.auckland.ac.nz; gmx.net; dkim=none (message not signed) header.d=none;gmx.net; dmarc=none action=none header.from=cs.auckland.ac.nz Received: from uxcn13-tdc-c.UoA.auckland.ac.nz (130.216.95.208) by SG2APC01FT015.mail.protection.outlook.com (10.152.250.181) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.3784.11 via Frontend Transport; Mon, 8 Feb 2021 05:09:17 +0000 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) by uxcn13-tdc-c.UoA.auckland.ac.nz (10.6.3.4) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 8 Feb 2021 18:09:16 +1300 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::c123:782b:aed6:3e56]) by uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::c123:782b:aed6:3e56%14]) with mapi id 15.00.1497.010; Mon, 8 Feb 2021 18:09:16 +1300 From: Peter Gutmann To: Paul Wouters CC: Heiko Stamer , "openpgp@ietf.org" Thread-Topic: [openpgp] I-D Action: draft-ietf-openpgp-crypto-refresh-01.txt Thread-Index: AQHW++PL3wEJDkPwh0mOwQbphLkiWqpKt74AgAHHgKL///OygIABRkbP Date: Mon, 8 Feb 2021 05:09:15 +0000 Message-ID: <1612760957080.38788@cs.auckland.ac.nz> References: <161254580617.29620.7114088127291075805@ietfa.amsl.com>, <76fe41fc-f14e-fe3c-db02-7e5b7629dc8a@gmx.net> <1612693541055.92697@cs.auckland.ac.nz>, <6f1c429e-7a8d-1ce6-fda5-30ba2b326477@nohats.ca> In-Reply-To: <6f1c429e-7a8d-1ce6-fda5-30ba2b326477@nohats.ca> Accept-Language: en-NZ, en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 3b5fd0f4-3eec-4138-50c4-08d8cbefaf95 X-MS-TrafficTypeDiagnostic: SY3PR01MB1227: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0 X-Microsoft-Antispam-Message-Info: r7IS6U+pJ5TTgBPqMBPtCOtBq/yGo+N2Rw4yxdKSfa22PSjMJ5aO5smtU49bno5vTiGN7Wk5ZCkF3YmtFK1bf/nWqvyREAOEJY5ufctX/yQHuaqkaf9DxLmcssOpelDnMDfPnyrefisJO2V44EwqXdicEc66Fe8xNyAMrGEjXq9UuRAl6aOkhGQC5nDWfLcl06UTbAgBMVQP/4bTtoZ+pAgBhBh1qRNZSzPt8Y04iqu3rRqkX+x9Kmogjyk98CKaqXQ2Y407CC6gWXcsDkr6V+UdzSun6gbbJOZZFTuLxT2CYLX3HdjKTvKsy5+NPt6fuKL14M5LTrRrrMSwqq06pb07M6iHixVf92DqJLr+SXGpB356IRIpYo//1v1SdIWs/4dkdc/a/7QUES0N7SrzoCHWAWg2WuC4Z4oafiyzoWtaVUC0Asul5xiWU8t1E9WDEZt0KypvVg83txA++i0970Ut0oIbgP/McOdKTjOU7eAeDoHLNTPA7CIxQBBO4dN8BLRa6mea9l1FtCQhechLAKnOrH83+oaE1RgVrUBsrpkqtduLyhLFJm5Dviz9LxUMJuQLJZhQDYOFjt+96Eoo4Ql6TcHii7rsj4Boi/RGH8uxlRov3lFhYyXWbq0KIdVpT8ipAm+icnJuZB9lgXMKD4I7XYc1CdfRD7Ca0WF5fb8= X-Forefront-Antispam-Report: CIP:130.216.95.208; CTRY:NZ; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:uxcn13-tdc-c.UoA.auckland.ac.nz; PTR:natgate1-1.auckland.ac.nz; CAT:NONE; SFS:(4636009)(46966006)(36840700001)(36906005)(54906003)(4326008)(336012)(70586007)(70206006)(5660300002)(2616005)(186003)(8936002)(36860700001)(4744005)(6916009)(83380400001)(356005)(86362001)(8676002)(82310400003)(2906002)(498600001)(26005)(47076005)(7636003); DIR:OUT; SFP:1101 X-OriginatorOrg: cs.auckland.ac.nz X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Feb 2021 05:09:17.3427 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 3b5fd0f4-3eec-4138-50c4-08d8cbefaf95 X-MS-Exchange-CrossTenant-Id: d1b36e95-0d50-42e9-958f-b63fa906beaa X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=d1b36e95-0d50-42e9-958f-b63fa906beaa; Ip=[130.216.95.208]; Helo=[uxcn13-tdc-c.UoA.auckland.ac.nz] X-MS-Exchange-CrossTenant-AuthSource: SG2APC01FT015.eop-APC01.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SY3PR01MB1227 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CAU17A13 smtp.mailfrom=pgut001@cs.auckland.ac.nz X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: cs.auckland.ac.nz Content-Language: en-NZ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [openpgp] I-D Action: draft-ietf-openpgp-crypto-refresh-01.txt 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 Feb 2021 05:09:30 -0000 Paul Wouters writes:=0A=0A>Question for the WG. Should we = change the text to make the entries "examples"=0A>of white space, or should= we add a definition of white space?=0A>=0A>If the latter, what do the curr= ent openpgp implementations define as white=0A>space characters right now?= =0A=0AI think the better option is to not reinvent any definition and possi= bly get=0Ait wrong but to refer to relevant RFCs that have been around fore= ver and are=0Awidely accepted. In this case it'd be something PEM-related,= for classic PEM=0Athere's RFC 1421, but I think more relevant, and recent = one is 7468, all you'd=0Aneed to do there is add new definitions for the PG= P messages.=0A=0APeter.=0A From nobody Mon Feb 8 02:50:09 2021 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 73A943A15F7 for ; Mon, 8 Feb 2021 02:50:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=andrewg.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSl6k3cNPAIg for ; Mon, 8 Feb 2021 02:50:06 -0800 (PST) Received: from xen.andrewg.com (andrewg.com [178.79.140.242]) (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 BC1EE3A15E8 for ; Mon, 8 Feb 2021 02:50:06 -0800 (PST) Received: from [IPv6:fc93:5820:7375:ee79:1300::1] (fred [IPv6:fc93:5820:7375:ee79:1300::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits)) (Client did not present a certificate) by xen.andrewg.com (Postfix) with ESMTPSA id 909065C635 for ; Mon, 8 Feb 2021 10:50:03 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=andrewg.com; s=andrewg-com; t=1612781403; bh=Dy3FKKnWqw+5DKacKfqnvbQrQizOSNLwDroK/uVbmWQ=; h=To:References:From:Subject:Date:In-Reply-To:From; b=R67pPZ4BqVvSx0ce94OqD8DiipmBrzj1gj8wHAyLL8pfueyeCydKwDiVVElaDKmEF oXHqTksfsFTe36+9KZonHGhqIPd0AbyzcAXZdR/VaJPZQ0pZ4pv4k5TxugoUwBcBTl tPonT9Slh9hNBUl5ru8spg2a48GcJ3PKjqZvAHrfWi/QPrJ52Xx9Zo5AZh8LlGVwA8 DYHZSrLBJBf6o+plKkVBoudifPm7DRYKao7+qRnSyWgZWjFN52PreSMnMZAWY+3K1E HeSe/TZBboKgh+h21KkzoZITVoq+JANdddIPDDq0BxcbdQ+D/CW+QQneKgSvswZDQ6 2E/WoTLXgpG/Q== To: openpgp@ietf.org References: <161254580617.29620.7114088127291075805@ietfa.amsl.com> <76fe41fc-f14e-fe3c-db02-7e5b7629dc8a@gmx.net> <1612693541055.92697@cs.auckland.ac.nz> From: Andrew Gallagher Message-ID: Date: Mon, 8 Feb 2021 10:50:02 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <1612693541055.92697@cs.auckland.ac.nz> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="olYYHyq09kmsnW547ZQxx2WBJY5bohptY" Archived-At: Subject: Re: [openpgp] I-D Action: draft-ietf-openpgp-crypto-refresh-01.txt 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 Feb 2021 10:50:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --olYYHyq09kmsnW547ZQxx2WBJY5bohptY Content-Type: multipart/mixed; boundary="cdTURkhQ7FPeIlBno97BbOJ7pN9uASrHc"; protected-headers="v1" From: Andrew Gallagher To: openpgp@ietf.org Message-ID: Subject: Re: [openpgp] I-D Action: draft-ietf-openpgp-crypto-refresh-01.txt References: <161254580617.29620.7114088127291075805@ietfa.amsl.com> <76fe41fc-f14e-fe3c-db02-7e5b7629dc8a@gmx.net> <1612693541055.92697@cs.auckland.ac.nz> In-Reply-To: <1612693541055.92697@cs.auckland.ac.nz> --cdTURkhQ7FPeIlBno97BbOJ7pN9uASrHc Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 07/02/2021 10:25, Peter Gutmann wrote: > Heiko Stamer writes: >=20 >> For spaces and tabs the intention is clear for me, however, I am not s= ure >> about carriage returns in general. According to Unicode Character Data= base >> there are some other whitespace characters, e.g., form feed (0x0c). Sh= ould >> such characters be included, too? >=20 > That also just seems wrong in general, the last major OS type I know of= that > used CR delimiters was Mac OS from 1984. Shouldn't this be LF or CRLF?= > Wherever this came from, it's not in 4880, or any other common RFC that= > defines a format for blank lines. It reads to me like this change is intended to cover a "blank line" of=20 assorted spaces and tabs, with an optional trailing carriage return=20 before the line feed delimiter. The admission of carriage returns=20 elsewhere in the whitespace sequence is surely unintentional. Note that the similar definition of "trailing white space" on line 69=20 should be kept consistent with that of "blank line". --=20 Andrew Gallagher --cdTURkhQ7FPeIlBno97BbOJ7pN9uASrHc-- --olYYHyq09kmsnW547ZQxx2WBJY5bohptY Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEKR55odxVrielLu+DXB7EBNWQZikFAmAhF1oACgkQXB7EBNWQ ZinvwA/+LH3XvexiZjjVtP9kRfzL0m8xMmbNWXga1W4XN64vxxREFSNXX+aJaOeW uTd2OuN4N/JtTYutsj6vLz4oLpujZBSD3Jpitiqxc0ZAzPKaVZQjdv67yBuUUQTA Sk12yHScefJ7znOgnD61WQYG1mHscsvDE/bWdwPI5LzDsNawWQZ7BjmsJi7tBF6/ tTz9OdwYF9+UCteDPdik2ktYhQdi8xRVgsf6XOaXlkSG2WSfvdrOeWZ4UrrqvFsW xLsZtju8KXgYWDwzREk1kRSZN+U+xSiPfpiUQwjbFxd1AjOy05wUq1C3wpnLfLru hpyDVCZiWkC/8FESM0srtC9Le+qwsA4HRFYRVJRFEaLy/XG3yxKEKKRjFObhK9eT 4HlVXiF94lQwKKBeefvq13/ZBuo9MC9aUHgcxs2ya0OzGiahrWXieNZAzpeebP7I ja2IhiPyQYlSKVlvJ70ObMQczihskSSD61kjyV8sh47IRHqZpcDvIspdr4nxJxf2 naSL4x0nHbfgkRb1PE6cTlu6daqb5GKz/WFIri+TgxaJeNnnJr7vDu4TQOznFHGF 2pk+SMl6v+yXdokHYjpybRMMObNyf9xjmwGzaWiP9AUE4tD+6zsq/F7gJU9HySDy 8MgX6Nqo0r5D2tQCSWltuVhf1dJfHRUjcUA/gcUa8MZ70hFaYTY= =2QgW -----END PGP SIGNATURE----- --olYYHyq09kmsnW547ZQxx2WBJY5bohptY-- From nobody Mon Feb 8 02:55:42 2021 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 F25C23A15D6 for ; Mon, 8 Feb 2021 02:55:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=andrewg.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFuP21VPcCKi for ; Mon, 8 Feb 2021 02:55:39 -0800 (PST) Received: from xen.andrewg.com (andrewg.com [178.79.140.242]) (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 CB5753A15D5 for ; Mon, 8 Feb 2021 02:55:39 -0800 (PST) Received: from [IPv6:fc93:5820:7375:ee79:1300::1] (fred [IPv6:fc93:5820:7375:ee79:1300::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits)) (Client did not present a certificate) by xen.andrewg.com (Postfix) with ESMTPSA id 6B67E5C635 for ; Mon, 8 Feb 2021 10:55:38 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=andrewg.com; s=andrewg-com; t=1612781738; bh=+eQOpuEE+5c2z9IDTfowSaPDsQGld1iDoPLwWzzKl2Y=; h=Subject:To:References:From:Date:In-Reply-To:From; b=VdiXNAGDyBViNgL4B5+JiAWwl6KIj3S6yiqdR/x7mJNjp7IPvQJZrZ53kUizPYZqz EnF+tIk0P4f6ULZ5k2x3Loi4iTzTwJv5RK/3lYLQ8L28lEYWHM/2fRramVe17bQVlw /+wDW2RqhRCh9uux9d9U+VqhEEuPs02mP1fBdy6RVJ8MWgunykaZHWohAoDbRfdFJZ h8Ce580yH4WSs7DTG1+O84VDruLlEk9Xa0smuW2nTCLvR5nBypDte1oFSs/diM3Gcs SNJDqprwO5innSy8llYYswYQ9fnAXGpmP7bVrNIF9F8xhFIrVy8YI1iwjpUkXgEgjK Y0ZjmIZTrn7Pw== To: openpgp@ietf.org References: <161254580617.29620.7114088127291075805@ietfa.amsl.com> <76fe41fc-f14e-fe3c-db02-7e5b7629dc8a@gmx.net> <1612693541055.92697@cs.auckland.ac.nz> From: Andrew Gallagher Message-ID: <503d2d13-0c2d-3b7c-1779-09b4fb03c1ea@andrewg.com> Date: Mon, 8 Feb 2021 10:55:36 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="uHy3bK3oeJeOs7t1bTXxZjPPicGwDGsh4" Archived-At: Subject: Re: [openpgp] I-D Action: draft-ietf-openpgp-crypto-refresh-01.txt 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 Feb 2021 10:55:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uHy3bK3oeJeOs7t1bTXxZjPPicGwDGsh4 Content-Type: multipart/mixed; boundary="4hUqL0VAHYNPiQWsFUkXgFi04SqCJobRF"; protected-headers="v1" From: Andrew Gallagher To: openpgp@ietf.org Message-ID: <503d2d13-0c2d-3b7c-1779-09b4fb03c1ea@andrewg.com> Subject: Re: [openpgp] I-D Action: draft-ietf-openpgp-crypto-refresh-01.txt References: <161254580617.29620.7114088127291075805@ietfa.amsl.com> <76fe41fc-f14e-fe3c-db02-7e5b7629dc8a@gmx.net> <1612693541055.92697@cs.auckland.ac.nz> In-Reply-To: --4hUqL0VAHYNPiQWsFUkXgFi04SqCJobRF Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 08/02/2021 10:50, Andrew Gallagher wrote: > Note that the similar definition of "trailing white space" on line 69=20 > should be kept consistent with that of "blank line". Page 69, sorry. :-( --=20 Andrew Gallagher --4hUqL0VAHYNPiQWsFUkXgFi04SqCJobRF-- --uHy3bK3oeJeOs7t1bTXxZjPPicGwDGsh4 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEKR55odxVrielLu+DXB7EBNWQZikFAmAhGKgACgkQXB7EBNWQ ZilwSBAAmpyaXq4TEkWfTmW6oIk6R52nduchE9S65BN+0rZD9DQx3jPUtZ4DwBv+ rpeVJSiPDF7lXx2XN4E1RkTvHKMyzvmgGAfpLyKC7p0UZLKw0c6lt12zs6Sy6Rn7 B/4dTc/SuEow8VJyY7id4R3DJ61XNzL1rPQhxLkMBV/2imB0DIn1DM/aGglmVcpD Yt/t6rHBUIu1hXmscZSqh09EDJ/iLqKyMT6jlN7LWMYuPBxEG3JbENPZLpNPSuND VQPNTFWznovfzQ0feK8a/lvF3ZXPpELnBr3DgjYDtmcqpUcozVclEeakYmyAm8pA IjVOOa+mHl1vBiS/vofX4qnHvby+j/fP2iPrA79PXxsLMUBFfyagQIZpQpwnhzPp Leuq6JY57yuCP5Jwb0buLiTwRP3DVvKI/OxJiqAtOMqJaHBbEtKZyq7fGv29Zbxp 4MCQ4D0RBAUhrI+hGCwUw7QV+kNi0tHOrHV/4XNwhch/Fs8FH51TfHmobQ15Gabk OCOKokbjB5f7KPI+5YWAqj334Ba6lSZI139T8VhDx7kAmLqEVL1XB4bNtTRIKpIG /fikJ0Fbw9TMfRx7j7wWl9kEjlfp70Q5hf2/132c0HfueD5FMa0A0V7iMcLuiPOI 9QwWUETKT/+k8ts6fDarbKNdRYcwuaFEjYGDilH0h9hCvNgeNbY= =uNEw -----END PGP SIGNATURE----- --uHy3bK3oeJeOs7t1bTXxZjPPicGwDGsh4-- From nobody Thu Feb 11 07:51:18 2021 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 E61A93A16D8 for ; Thu, 11 Feb 2021 07:51:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.116 X-Spam-Level: X-Spam-Status: No, score=-1.116 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, PDS_RDNS_DYNAMIC_FP=0.001, RCVD_IN_SORBS_DUL=0.001, RDNS_DYNAMIC=0.982, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hadrons.org 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 zv2v6d1PwRqL for ; Thu, 11 Feb 2021 07:51:14 -0800 (PST) Received: from pulsar.hadrons.org (2.152.178.181.dyn.user.ono.com [2.152.178.181]) (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 8190F3A16D7 for ; Thu, 11 Feb 2021 07:51:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=hadrons.org ; s=201908; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:From:Reply-To:Subject:Content-Transfer-Encoding: Content-ID:Content-Description:X-Debbugs-Cc; bh=fgfPSRenZWQGlBoCIRz+3Y5a8dbr0/V2J8KzMOM4Bqo=; b=AdXfi2+tKWdLQY368tPLqi7Qti 4h8l3MBtza31pbRX9nKND7WHcj1cdwp7iIbknU5M92n0mAWlxVVuxEc/qTAPV5QU2nshV/pOrvS+R EJEJhAFzXPsRrU7cbXBCqHCpjf+xllKIHCMqbvveeisot/dop3paRoTwQXG8wnSgACc6P/Ylq9Ml3 ZydAzjyZUDsAeM0QUkLSP9hNddWbERPLI+GKw15NIOmfSlOEOYihSz4+J5cFNSxzN05dp+fUgwaEy I1D/HjyVVB0qGlW+vo67ysu76TScDaYXbmW1rylw6IF0Gw2oLea1QtTvGwoaX7xjO9xRxClpq78tn jiSxNjDw==; Received: from guillem by pulsar.hadrons.org with local (Exim 4.92) (envelope-from ) id 1lAEFI-00076U-8h; Thu, 11 Feb 2021 16:51:08 +0100 Date: Thu, 11 Feb 2021 16:51:07 +0100 From: Guillem Jover To: Andrew Gallagher Cc: openpgp@ietf.org Message-ID: References: <161254580617.29620.7114088127291075805@ietfa.amsl.com> <76fe41fc-f14e-fe3c-db02-7e5b7629dc8a@gmx.net> <1612693541055.92697@cs.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [openpgp] I-D Action: draft-ietf-openpgp-crypto-refresh-01.txt 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: Thu, 11 Feb 2021 15:51:17 -0000 On Mon, 2021-02-08 at 10:50:02 +0000, Andrew Gallagher wrote: > On 07/02/2021 10:25, Peter Gutmann wrote: > > Heiko Stamer writes: > > > > > For spaces and tabs the intention is clear for me, however, I am not sure > > > about carriage returns in general. According to Unicode Character Database > > > there are some other whitespace characters, e.g., form feed (0x0c). Should > > > such characters be included, too? > > > > That also just seems wrong in general, the last major OS type I know of that > > used CR delimiters was Mac OS from 1984. Shouldn't this be LF or CRLF? > > Wherever this came from, it's not in 4880, or any other common RFC that > > defines a format for blank lines. > > It reads to me like this change is intended to cover a "blank line" of > assorted spaces and tabs, with an optional trailing carriage return before > the line feed delimiter. The admission of carriage returns elsewhere in the > whitespace sequence is surely unintentional. Yes this was the intention, as prompted by: The original MR: > Note that the similar definition of "trailing white space" on line 69 should > be kept consistent with that of "blank line". Ah probably missed that one. Thanks, Guillem From nobody Fri Feb 12 16:38:34 2021 Return-Path: X-Original-To: openpgp@ietf.org Delivered-To: openpgp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0663A121C; Fri, 12 Feb 2021 16:33:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: kaduk@mit.edu, openpgp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161317641430.31337.11974967089852200791@ietfa.amsl.com> Date: Fri, 12 Feb 2021 16:33:34 -0800 Archived-At: Subject: [openpgp] openpgp - Requested session has been scheduled for IETF 110 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2021 00:33:43 -0000 Dear Daniel Gillmor, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. openpgp Session 1 (1:00 requested) Thursday, 11 March 2021, Session II 1530-1630 Room Name: Room 7 size: 507 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/110/sessions/openpgp.ics Request Information: --------------------------------------------------------- Working Group Name: Open Specification for Pretty Good Privacy Area Name: Security Area Session Requester: Daniel Gillmor Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 20 Conflicts to Avoid: Chair Conflict: tls saag dprive People who must be present: Benjamin Kaduk Daniel Kahn Gillmor Stephen Farrell Resources Requested: Special Requests: --------------------------------------------------------- From nobody Mon Feb 15 15:56:55 2021 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 D56343A09ED for ; Mon, 15 Feb 2021 15:56:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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=a0lMYJPp; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=FCIg7nri 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 TE8Qi4jnXhJ9 for ; Mon, 15 Feb 2021 15:56:50 -0800 (PST) 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 E3AB33A0A5E for ; Mon, 15 Feb 2021 15:56:45 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1613433403; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=7AFXL1LU3fee/GUqT4yhDYmmzZ94CSYDlhTOVnYJSn4=; b=a0lMYJPpP7utof5+mr7vWblx9kVqi3IT/D3mf4YIfCyvsxPuKlcRZzn3pmSqLDhpsHu2j zLFPZqEr5bjg+hTDQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1613433403; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=7AFXL1LU3fee/GUqT4yhDYmmzZ94CSYDlhTOVnYJSn4=; b=FCIg7nri4rArhEZNdEMD/kujFjnIJiOKTp9La0YcJG8CKV1eQg8EmRSdzdYkQwuh6kFL4 LAr38znFdJMYI+LFTDR+yuFfeuFS5Zc1U4/n3ut8QS/lb4EY3Xiq6hWkXyNU511oxEVaGXH 9C53ZRRwytWU7vbKRnd/WtOYO//iZmoCq8PnsGuaZQNdo4n94PwJXzKw9g7xcUe/KYZzvHQ xbNJ0CVvcSZWM4+/iyKBgRqsaLsVl6/GS/1SvBKpY8qrnHsSK1LnyoJtk8nXVs3ct0bNCLv 6AGE4LOymbkikxUzRaJZYTHi8GbzdopXLH1D7hfH3Tin0ZKHn4ZQ4uIhDTow== Received: from fifthhorseman.net (lair.fifthhorseman.net [108.58.6.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 734AAF9A6; Mon, 15 Feb 2021 18:56:43 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 08079204FD; Mon, 15 Feb 2021 18:56:35 -0500 (EST) From: Daniel Kahn Gillmor To: Guillem Jover , Andrew Gallagher Cc: openpgp@ietf.org In-Reply-To: References: <161254580617.29620.7114088127291075805@ietfa.amsl.com> <76fe41fc-f14e-fe3c-db02-7e5b7629dc8a@gmx.net> <1612693541055.92697@cs.auckland.ac.nz> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEX+i03xYJKwYBBAHaRw8BAQdACA4xvL/xI5dHedcnkfViyq84doe8zFRid9jW7CC9XBiI0QQf FgoAgwWCX+i03wWJBZ+mAAMLCQcJEOCS6zpcoQ26RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNl cXVvaWEtcGdwLm9yZ/tr8E9NA10HvcAVlSxnox6z62KXCInWjZaiBIlgX6O5AxUKCAKbAQIeARYh BMKfigwB81402BaqXOCS6zpcoQ26AADZHQD/Zx9nc3N2kj13AUsKMr/7zekBtgfSIGB3hRCU74Su G44A/34Yp6IAkndewLxb1WdRSokycnaCVyrk0nb4imeAYyoPtBc8ZGtnQGZpZnRoaG9yc2VtYW4u bmV0PojRBBMWCgCDBYJf6LTfBYkFn6YAAwsJBwkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3Rh dGlvbnMuc2VxdW9pYS1wZ3Aub3JnL0Gwxvypz2tu1IPG+yu1zPjkiZwpscsitwrVvzN3bbADFQoI ApsBAh4BFiEEwp+KDAHzXjTYFqpc4JLrOlyhDboAAPkXAP0Z29z7jW+YzLzPTQML4EQLMbkHOfU4 +s+ki81Czt0WqgD/SJ8RyrqDCtEP8+E4ZSR01ysKqh+MUAsTaJlzZjehiQ24MwRf6LTfFgkrBgEE AdpHDwEBB0DkKHOW2kmqfAK461+acQ49gc2Z6VoXMChRqobGP0ubb4kBiAQYFgoBOgWCX+i03wWJ BZ+mAAkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3Jnfvo+ nHoxDwaLaJD8XZuXiaqBNZtIGXIypF1udBBRoc0CmwICHgG+oAQZFgoAbwWCX+i03wkQPp1xc3He VlxHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnaheiqE7Pfi3Atb3GGTw+ jFcBGOaobgzEJrhEuFpXREEWIQQttUkcnfDcj0MoY88+nXFzcd5WXAAAvrsBAIJ5sBg8Udocv25N stN/zWOiYpnjjvOjVMLH4fV3pWE1AP9T6hzHz7hRnAA8d01vqoxOlQ3O6cb/kFYAjqx3oMXSBhYh BMKfigwB81402BaqXOCS6zpcoQ26AADX7gD/b83VObe14xrNP8xcltRrBZF5OE1rQSPkMNy+eWpk eCwA/1hxiS8ZxL5/elNjXiWuHXEvUGnRoVj745Vl48sZPVYMuDgEX+i03xIKKwYBBAGXVQEFAQEH QIGex1WZbH6xhUBve5mblScGYU+Y8QJOomXH+rr5tMsMAwEICYjJBBgWCgB7BYJf6LTfBYkFn6YA CRDgkus6XKENukcUAAAAAAAeACBzYWx0QG5vdGF0aW9ucy5zZXF1b2lhLXBncC5vcmcEAx9vTD3b J0SXkhvcRcCr6uIDJwic3KFKxkH1m4QW0QKbDAIeARYhBMKfigwB81402BaqXOCS6zpcoQ26AAAX mwD8CWmukxwskU82RZLMk5fm1wCgMB5z8dA50KLw3rgsCykBAKg1w/Y7XpBS3SlXEegIg1K1e6dR fRxL7Z37WZXoH8AH Date: Mon, 15 Feb 2021 18:56:34 -0500 Message-ID: <87blckvqa5.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="==-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: [openpgp] whitespace definitions in OpenPGP [was: Re: I-D Action: draft-ietf-openpgp-crypto-refresh-01.txt] 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, 15 Feb 2021 23:56:54 -0000 --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu 2021-02-11 16:51:07 +0100, Guillem Jover wrote: > On Mon, 2021-02-08 at 10:50:02 +0000, Andrew Gallagher wrote: >> On 07/02/2021 10:25, Peter Gutmann wrote: >> > Heiko Stamer writes: >> >=20 >> > > For spaces and tabs the intention is clear for me, however, I am not= sure >> > > about carriage returns in general. According to Unicode Character Da= tabase >> > > there are some other whitespace characters, e.g., form feed (0x0c). = Should >> > > such characters be included, too? >> >=20 >> > That also just seems wrong in general, the last major OS type I know o= f that >> > used CR delimiters was Mac OS from 1984. Shouldn't this be LF or CRLF? >> > Wherever this came from, it's not in 4880, or any other common RFC that >> > defines a format for blank lines. >>=20 >> It reads to me like this change is intended to cover a "blank line" of >> assorted spaces and tabs, with an optional trailing carriage return befo= re >> the line feed delimiter. The admission of carriage returns elsewhere in = the >> whitespace sequence is surely unintentional. > > Yes this was the intention, as prompted by: > > > > The original MR: > > > >> Note that the similar definition of "trailing white space" on line 69 sh= ould >> be kept consistent with that of "blank line". > > Ah probably missed that one. Thanks for this discussion, all. It seems clear to me that the text about whitespace that was merged into =2D01 doesn't have WG consensus at the moment -- iiuc, it may address the original concern raised by Guillem, but is unintentionally overbroad, and might introduce further incompatibilities between implementations if they try to follow the spec as written. I propose the way forward for this is for now, we revert those changes, and the next revision (-02) could retain the language about whitsepace from RFC4880. I've proposed that here: https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/33 (see also the attached diff) In the meantime, so we don't lose sight of the legitimate problem that Guillem wants addressed, I've opened https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/11 If someone from the group wants to propose alternate text that addresses the issue but doesn't introduce the inconsistencies identified by Andrew and others, then please propose that text on-list here (in a different thread?) -- and if you can also make it as a merge request on gitlab that'd be a bonus. Regards, --dkg --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0001-Revert-clarify-blank-lines-and-whitespace.patch Content-Transfer-Encoding: quoted-printable From=200bf360cfc448211a85b287e2728b0a5792ba851d Mon Sep 17 00:00:00 2001 From: Daniel Kahn Gillmor Date: Mon, 15 Feb 2021 18:33:30 -0500 Subject: [RFC4880bis PATCH] Revert "clarify blank lines and whitespace" This reverts commit d343098838f7ef22df16dc187163417a7d0733e4. [Discussion on the mailing list](https://mailarchive.ietf.org/arch/msg/openpgp/AvsVX6SREEstygUHzHNjps4= 0vq0/) suggest that the changes in that commit don't have full consensus, and indeed even the original author of the changes appears to acknowledge that the definition doesn't cover the specific ground it intends to cover. =2D-- crypto-refresh.md | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/crypto-refresh.md b/crypto-refresh.md index 7e17b6f..3616585 100644 =2D-- a/crypto-refresh.md +++ b/crypto-refresh.md @@ -1989,7 +1989,7 @@ Concatenating the following data creates ASCII Armor: =20 - Armor Headers =20 =2D- A blank line +- A blank (zero-length, or containing only whitespace) line =20 - The ASCII-Armored data =20 @@ -2024,7 +2024,7 @@ BEGIN PGP SIGNATURE =20 Note that all these Armor Header Lines are to consist of a complete line. That is to say, there is always a line ending preceding the starting five = dashes, and following the ending five dashes. =2DThe header lines, therefore, MUST start at the beginning of a line, and = MUST NOT have text other than whitespace --- space (0x20), tab (0x09) or ca= rriage return (0x0d) --- following them on the same line. +The header lines, therefore, MUST start at the beginning of a line, and MU= ST NOT have text other than whitespace following them on the same line. These line endings are considered a part of the Armor Header Line for the = purposes of determining the content they delimit. This is particularly important when computing a cleartext signature (see b= elow). =20 @@ -2071,8 +2071,6 @@ Currently defined Armor Header Keys are as follows: In such instances, an implementation MAY override the UTF-8 default by u= sing this header key. An implementation MAY implement this key and any translations it cares t= o; an implementation MAY ignore it and assume all text is UTF-8. =20 =2DThe blank line can either be zero-length or contain only whitespace, tha= t is spaces (0x20), tabs (0x09) or carriage returns (0x0d). =2D The Armor Tail Line is composed in the same manner as the Armor Header Lin= e, except the string "BEGIN" is replaced by the string "END". =20 ## Encoding Binary in Radix-64 {#encoding-binary-radix64} @@ -2189,7 +2187,7 @@ The cleartext signed message consists of: =20 - One or more "Hash" Armor Headers, =20 =2D- Exactly one blank line not included into the message digest, +- Exactly one empty line not included into the message digest, =20 - The dash-escaped cleartext that is included into the message digest, =20 @@ -2219,7 +2217,7 @@ The line ending (i.e., the \\) before the `--= ---BEGIN PGP SIGNATURE----- =20 When reversing dash-escaping, an implementation MUST strip the string `- `= if it occurs at the beginning of a line, and SHOULD warn on `-` and any ch= aracter other than a space at the beginning of a line. =20 =2DAlso, any trailing whitespace --- spaces (0x20), tabs (0x09) or carriage= returns (0x0d) --- at the end of any line is removed when the cleartext si= gnature is generated and verified. +Also, any trailing whitespace --- spaces (0x20) and tabs (0x09) --- at the= end of any line is removed when the cleartext signature is generated. =20 # Regular Expressions {#regular-expressions} =20 =2D-=20 2.30.0 --=-=-=-- --==-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQttUkcnfDcj0MoY88+nXFzcd5WXAUCYCsKMgAKCRA+nXFzcd5W XE2kAP47CA8Z4wuSzVl+NOb5uA8xCotfDVjDHepiFHBO3+fnxgD+KYR11W+ZFEWH KbnqQTGa3wODfRuMWHm1k6DyCwwH2w4= =8mL8 -----END PGP SIGNATURE----- --==-=-=-- From nobody Mon Feb 15 15:57:05 2021 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 065E33A0A79 for ; Mon, 15 Feb 2021 15:56:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.306 X-Spam-Level: X-Spam-Status: No, score=-1.306 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=lvharCRE; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=ZlRw+KDA 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 SXgFPZ17wO1v for ; Mon, 15 Feb 2021 15:56:56 -0800 (PST) Received: from che.mayfirst.org (unknown [162.247.75.117]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51A7E3A0ADE for ; Mon, 15 Feb 2021 15:56:49 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1613433408; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=Gl+Jrxnc/LnuII23cA3gaMRI0CuyHfVFA15nRY3E76g=; b=lvharCREhw/s+J+UO04eTMjObwmeauBDHyFN4gTb79jDkCt9DIqwhgssarY5nGpcw9G2L FLvfQGpEpXzK8nSCw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1613433408; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=Gl+Jrxnc/LnuII23cA3gaMRI0CuyHfVFA15nRY3E76g=; b=ZlRw+KDAuGVZww0BKSbhcCyNEXbn5s+qLTLlQ8j+4NYspouxhMWco2JYdTgBnzjAxqULQ TDvoB9F/gboPRonD9QcQ25wpti0PLltEOQPTzIXvrofc7GKD9YhOzrnx1Bp9jKpJikrGSVB J5zHo1uXNSvcAnOL848OxMTmo3fZPqVDdAF1BXd44QE/fDKh5KV1enf/N1ueoBDuGEdP96U ltj0HccEvKSXb+7D4CJfzcRTPNdUzgBm8QM1uET3Vj8x4BAsVnZTBYwT+mFG48kP0jUxHPA OGN/tRq0fJZrIywOj4zd0L8poq0Tr6K2FUXL1tEeB9yF98LAnLKXzc11Jhug== Received: from fifthhorseman.net (lair.fifthhorseman.net [108.58.6.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 6B471F9A5; Mon, 15 Feb 2021 18:56:43 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id D336420456; Mon, 15 Feb 2021 18:24:52 -0500 (EST) From: Daniel Kahn Gillmor To: Derek Atkins , Michael Richardson Cc: Paul Wouters , openpgp@ietf.org In-Reply-To: <87zh0hnmzb.fsf@fifthhorseman.net> References: <161193808437.14457.1252111225434038573@ietfa.amsl.com> <629addad-3dc3-a490-46db-5fafab95c7d5@nohats.ca> <87o8h7cgrq.fsf@fifthhorseman.net> <24870.1612559269@localhost> <87zh0hnmzb.fsf@fifthhorseman.net> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEX+i03xYJKwYBBAHaRw8BAQdACA4xvL/xI5dHedcnkfViyq84doe8zFRid9jW7CC9XBiI0QQf FgoAgwWCX+i03wWJBZ+mAAMLCQcJEOCS6zpcoQ26RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNl cXVvaWEtcGdwLm9yZ/tr8E9NA10HvcAVlSxnox6z62KXCInWjZaiBIlgX6O5AxUKCAKbAQIeARYh BMKfigwB81402BaqXOCS6zpcoQ26AADZHQD/Zx9nc3N2kj13AUsKMr/7zekBtgfSIGB3hRCU74Su G44A/34Yp6IAkndewLxb1WdRSokycnaCVyrk0nb4imeAYyoPtBc8ZGtnQGZpZnRoaG9yc2VtYW4u bmV0PojRBBMWCgCDBYJf6LTfBYkFn6YAAwsJBwkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3Rh dGlvbnMuc2VxdW9pYS1wZ3Aub3JnL0Gwxvypz2tu1IPG+yu1zPjkiZwpscsitwrVvzN3bbADFQoI ApsBAh4BFiEEwp+KDAHzXjTYFqpc4JLrOlyhDboAAPkXAP0Z29z7jW+YzLzPTQML4EQLMbkHOfU4 +s+ki81Czt0WqgD/SJ8RyrqDCtEP8+E4ZSR01ysKqh+MUAsTaJlzZjehiQ24MwRf6LTfFgkrBgEE AdpHDwEBB0DkKHOW2kmqfAK461+acQ49gc2Z6VoXMChRqobGP0ubb4kBiAQYFgoBOgWCX+i03wWJ BZ+mAAkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3Jnfvo+ nHoxDwaLaJD8XZuXiaqBNZtIGXIypF1udBBRoc0CmwICHgG+oAQZFgoAbwWCX+i03wkQPp1xc3He VlxHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnaheiqE7Pfi3Atb3GGTw+ jFcBGOaobgzEJrhEuFpXREEWIQQttUkcnfDcj0MoY88+nXFzcd5WXAAAvrsBAIJ5sBg8Udocv25N stN/zWOiYpnjjvOjVMLH4fV3pWE1AP9T6hzHz7hRnAA8d01vqoxOlQ3O6cb/kFYAjqx3oMXSBhYh BMKfigwB81402BaqXOCS6zpcoQ26AADX7gD/b83VObe14xrNP8xcltRrBZF5OE1rQSPkMNy+eWpk eCwA/1hxiS8ZxL5/elNjXiWuHXEvUGnRoVj745Vl48sZPVYMuDgEX+i03xIKKwYBBAGXVQEFAQEH QIGex1WZbH6xhUBve5mblScGYU+Y8QJOomXH+rr5tMsMAwEICYjJBBgWCgB7BYJf6LTfBYkFn6YA CRDgkus6XKENukcUAAAAAAAeACBzYWx0QG5vdGF0aW9ucy5zZXF1b2lhLXBncC5vcmcEAx9vTD3b J0SXkhvcRcCr6uIDJwic3KFKxkH1m4QW0QKbDAIeARYhBMKfigwB81402BaqXOCS6zpcoQ26AAAX mwD8CWmukxwskU82RZLMk5fm1wCgMB5z8dA50KLw3rgsCykBAKg1w/Y7XpBS3SlXEegIg1K1e6dR fRxL7Z37WZXoH8AH Date: Mon, 15 Feb 2021 18:24:51 -0500 Message-ID: <87eehgvrr0.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] I-D Action: draft-ietf-openpgp-crypto-refresh-00.txt 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, 15 Feb 2021 23:57:04 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Sat 2021-02-06 12:07:52 -0500, Daniel Kahn Gillmor wrote: > On Fri 2021-02-05 16:17:56 -0500, Derek Atkins wrote: >> The ToC doesn't include anything beyond x.y.z, [=E2=80=A6] > I've asked Carsten on github if there's a way to adjust the depth of the > ToC from markdown: > > https://github.com/cabo/kramdown-rfc2629/issues/99 Thanks to Carsten's suggestions, i've made this merge request to restore RFC 4880's four levels deep table of contents: https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/32 This is a minor structural tweak, not a substantive change. hopefully it helps us avoid a distracting difference from RFC 4880. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQttUkcnfDcj0MoY88+nXFzcd5WXAUCYCsCxAAKCRA+nXFzcd5W XPhIAPwKjdw9mm0xOXifRsUOW0iRVU9MGHHK6x7e5jDRH7AldwD/cM3eWjPItjQy n1GzrjyWy5knWjLfMQwLzhGNvr5ykgE= =8FkY -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Feb 15 16:11:06 2021 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 E03053A08A5 for ; Mon, 15 Feb 2021 16:11:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.306 X-Spam-Level: X-Spam-Status: No, score=-1.306 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=h0QkrhPW; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=caQc1cC8 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 5VD528_gbn6z for ; Mon, 15 Feb 2021 16:11:03 -0800 (PST) Received: from che.mayfirst.org (unknown [162.247.75.117]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88C873A089C for ; Mon, 15 Feb 2021 16:11:03 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1613434262; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=BrCM/4IHF1Ad33MdHNCeKy3TG0xJGdJVMcF1VKyXSdM=; b=h0QkrhPWXy6pNdf1emElJxMLyQpTTo+ndwR7Y/1+5jdBOHAclpYE0XdQ70lb5DU6FPn1h qqAH3jPriGmbHPUAg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1613434262; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=BrCM/4IHF1Ad33MdHNCeKy3TG0xJGdJVMcF1VKyXSdM=; b=caQc1cC8SzZT3+fv47eMVpL2azDb0+J2oUW1cnHB6V9+mgABF6TJkeah82QXjvIezpCKj P1sEtuXtvFcidqP5btHW4rP5qBVbCUtSHrrdPK66pdemZ74xq6Jx24SEqqxLg/USoHSOZbw 8EJECQfyNE7YxI15WghtNMpOCVt3OMCHmUvPI2jI3sdNc186/3NiZTOouQCoxPXA49olK38 2g2blqJQ6bWpXcjoc2HLCb4LYAN7Y6AqGuwX5E+LlSe+Dx1TTUgjxcYZlS1uyPclv+51qAN Mj5FUBp4rF8SiDOWcNufDsg+uGFLmr6Y5zns4N+Tl/+iyo1g3yS0QnJzz08w== Received: from fifthhorseman.net (lair.fifthhorseman.net [108.58.6.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id A4B82F9A5; Mon, 15 Feb 2021 19:11:02 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 0C3D220456; Mon, 15 Feb 2021 19:11:00 -0500 (EST) From: Daniel Kahn Gillmor To: Stephen Farrell , Paul Wouters , openpgp@ietf.org In-Reply-To: <42567509-8e46-701d-e435-a8cf2b6cab64@cs.tcd.ie> References: <161254580617.29620.7114088127291075805@ietfa.amsl.com> <44a9245e-d6af-8919-6d35-3c7672bfa54b@nohats.ca> <42567509-8e46-701d-e435-a8cf2b6cab64@cs.tcd.ie> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEX+i03xYJKwYBBAHaRw8BAQdACA4xvL/xI5dHedcnkfViyq84doe8zFRid9jW7CC9XBiI0QQf FgoAgwWCX+i03wWJBZ+mAAMLCQcJEOCS6zpcoQ26RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNl cXVvaWEtcGdwLm9yZ/tr8E9NA10HvcAVlSxnox6z62KXCInWjZaiBIlgX6O5AxUKCAKbAQIeARYh BMKfigwB81402BaqXOCS6zpcoQ26AADZHQD/Zx9nc3N2kj13AUsKMr/7zekBtgfSIGB3hRCU74Su G44A/34Yp6IAkndewLxb1WdRSokycnaCVyrk0nb4imeAYyoPtBc8ZGtnQGZpZnRoaG9yc2VtYW4u bmV0PojRBBMWCgCDBYJf6LTfBYkFn6YAAwsJBwkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3Rh dGlvbnMuc2VxdW9pYS1wZ3Aub3JnL0Gwxvypz2tu1IPG+yu1zPjkiZwpscsitwrVvzN3bbADFQoI ApsBAh4BFiEEwp+KDAHzXjTYFqpc4JLrOlyhDboAAPkXAP0Z29z7jW+YzLzPTQML4EQLMbkHOfU4 +s+ki81Czt0WqgD/SJ8RyrqDCtEP8+E4ZSR01ysKqh+MUAsTaJlzZjehiQ24MwRf6LTfFgkrBgEE AdpHDwEBB0DkKHOW2kmqfAK461+acQ49gc2Z6VoXMChRqobGP0ubb4kBiAQYFgoBOgWCX+i03wWJ BZ+mAAkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3Jnfvo+ nHoxDwaLaJD8XZuXiaqBNZtIGXIypF1udBBRoc0CmwICHgG+oAQZFgoAbwWCX+i03wkQPp1xc3He VlxHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnaheiqE7Pfi3Atb3GGTw+ jFcBGOaobgzEJrhEuFpXREEWIQQttUkcnfDcj0MoY88+nXFzcd5WXAAAvrsBAIJ5sBg8Udocv25N stN/zWOiYpnjjvOjVMLH4fV3pWE1AP9T6hzHz7hRnAA8d01vqoxOlQ3O6cb/kFYAjqx3oMXSBhYh BMKfigwB81402BaqXOCS6zpcoQ26AADX7gD/b83VObe14xrNP8xcltRrBZF5OE1rQSPkMNy+eWpk eCwA/1hxiS8ZxL5/elNjXiWuHXEvUGnRoVj745Vl48sZPVYMuDgEX+i03xIKKwYBBAGXVQEFAQEH QIGex1WZbH6xhUBve5mblScGYU+Y8QJOomXH+rr5tMsMAwEICYjJBBgWCgB7BYJf6LTfBYkFn6YA CRDgkus6XKENukcUAAAAAAAeACBzYWx0QG5vdGF0aW9ucy5zZXF1b2lhLXBncC5vcmcEAx9vTD3b J0SXkhvcRcCr6uIDJwic3KFKxkH1m4QW0QKbDAIeARYhBMKfigwB81402BaqXOCS6zpcoQ26AAAX mwD8CWmukxwskU82RZLMk5fm1wCgMB5z8dA50KLw3rgsCykBAKg1w/Y7XpBS3SlXEegIg1K1e6dR fRxL7Z37WZXoH8AH Date: Mon, 15 Feb 2021 19:10:59 -0500 Message-ID: <878s7ovpm4.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] I-D Action: draft-ietf-openpgp-crypto-refresh-01.txt 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: Tue, 16 Feb 2021 00:11:05 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri 2021-02-05 19:14:35 +0000, Stephen Farrell wrote: > On 05/02/2021 17:55, Paul Wouters wrote: >=20 >> If you have read the -01 (and -00) version and it all looks good, >> feel free to also let us know here on the list. > > Yes please - it'd be good to get a few such mails, so > we know people are checking and all seems well. About > 4 or 5 acks should be plenty if nobody finds problems. I'm glad to see that several people in the WG appear to have reviewed the diffs with reasonable attention to detail. From=20what i can see, the only concerns raised were about subtle (and potentially problematic) changes about the definition of whitespace for ASCII-armored text, which probably shouldn't have made it into -01 . The initial inclusion was my mistake -- in trying to help formulate a set of changes that were minor textual changes, i shouldn't have included it. I've proposed dropping that set of changes from the draft for now (hopefully someone can provide a cleaner fix). Just a reminder here to please ack if you've read the changes -- and to raise concerns if you've got them. I'm grateful for the participation, and think we should keep it going! --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQttUkcnfDcj0MoY88+nXFzcd5WXAUCYCsNkwAKCRA+nXFzcd5W XKUqAQCW2YUNkDRcCEBadxFOhQcEAa5oylPA/o5F8cAwp1yfyAD9E1S/TVNDlmlG rcAUhHYvX7y/KPNmV3oyoC6NtyQiQwM= =rnjo -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Feb 16 01:15:15 2021 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 361983A1109 for ; Tue, 16 Feb 2021 01:15:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, 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=gnupg.org 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 5li4_M4nphUy for ; Tue, 16 Feb 2021 01:15:11 -0800 (PST) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (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 88D933A1106 for ; Tue, 16 Feb 2021 01:15:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnupg.org; s=20181017; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=UonKEhD5x9WfW0u1GXSZdnWJzObFBRaypSsGJ9Ssd08=; b=Dmuk7PG7x3l6jQHaju1+QpL59B 2cfotbWHJRoreUB9QPSNdnHFpVWOh1+StzZ3MgB/mV8/owNy3qfjD/HuAwuTV1lrWxwJly8d3KvG0 TDyoUsqKc+3he8DHycSvd01jp5XyNb1DNOxYIfDsgkTlq87zqMx4smTzRrsMXylzazns=; Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1lBwRp-0007jw-8E for ; Tue, 16 Feb 2021 10:15:09 +0100 Received: from wk by wheatstone.g10code.de with local (Exim 4.92 #5 (Debian)) id 1lBwNr-0005fV-1j; Tue, 16 Feb 2021 10:11:03 +0100 From: Werner Koch To: Daniel Kahn Gillmor Cc: Guillem Jover , Andrew Gallagher , openpgp@ietf.org References: <161254580617.29620.7114088127291075805@ietfa.amsl.com> <76fe41fc-f14e-fe3c-db02-7e5b7629dc8a@gmx.net> <1612693541055.92697@cs.auckland.ac.nz> <87blckvqa5.fsf@fifthhorseman.net> Organisation: GnuPG e.V. X-message-flag: Mails containing HTML will not be read! Please send only plain text. Mail-Followup-To: Daniel Kahn Gillmor , Guillem Jover , Andrew Gallagher , openpgp@ietf.org Date: Tue, 16 Feb 2021 10:11:02 +0100 In-Reply-To: <87blckvqa5.fsf@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Mon, 15 Feb 2021 18:56:34 -0500") Message-ID: <87h7mcl6mx.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=Iraq_S_Key_Prevention_Macintosh_Internet_Violence_Lacrosse_Montenegr"; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] whitespace definitions in OpenPGP [was: Re: I-D Action: draft-ietf-openpgp-crypto-refresh-01.txt] 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: Tue, 16 Feb 2021 09:15:13 -0000 --=Iraq_S_Key_Prevention_Macintosh_Internet_Violence_Lacrosse_Montenegr Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 15 Feb 2021 18:56, Daniel Kahn Gillmor said: > It seems clear to me that the text about whitespace that was merged into > -01 doesn't have WG consensus at the moment -- iiuc, it may address the The problem with such minor changes is that they require extensive interop tests. Back when we started with OpenPGP we had to tweak these things a lot until all 3 implementations were interoperable. If we really want to make the definition more strict, lets do this after all chartered changes have been done. Shalom-Salam, Werner =2D-=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=Iraq_S_Key_Prevention_Macintosh_Internet_Violence_Lacrosse_Montenegr Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQSHd0YfKgdOvEgNNZQZzByeCFsQegUCYCuMJgAKCRAZzByeCFsQ eoqEAQDS6ZrZF1fkCJ3Io03WTVDq/qjmBGBv6f3xpNnAWORUJQEA440H7SBl8lC1 pI54+6RKuScP91gJaQvR7SFBMJd0jA4= =8q6Y -----END PGP SIGNATURE----- --=Iraq_S_Key_Prevention_Macintosh_Internet_Violence_Lacrosse_Montenegr-- From nobody Tue Feb 16 09:08:16 2021 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 E1D083A0BDB for ; Tue, 16 Feb 2021 09:08:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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=U9KOC+z+; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=j8OpAZ8+ 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 LB5stTxZU6mV for ; Tue, 16 Feb 2021 09:08:12 -0800 (PST) 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 01FAD3A0BFC for ; Tue, 16 Feb 2021 09:08:11 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1613495287; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=DKsa95x5A6ShlHZMzZfSwKZuQRojj4nHSFICobjlZ/M=; b=U9KOC+z+poDPpu+4hHH+Yow3jTO52l/JYbgvYn4TUSKztcE1IyHEmvqJroXO0jdwTmzaa TnexWtC5Vz4P6gRCg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1613495287; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=DKsa95x5A6ShlHZMzZfSwKZuQRojj4nHSFICobjlZ/M=; b=j8OpAZ8+FuMhYlTmY8GPFbpNScQXrZSg/H/FiwraL9ANxsvwzrKHUJSwvz/HDY8U48l/l rzHoshG7TMoWcJuwu1OFOLyflG3O0MDaZdjeQeZka1PTCN6y3hrW02STYN6bN2k4PISR7xW JTrZzlOflzc2PJ4U5gSEyndj3QGWQKngvTGBLLeEg3EZCXb8d1+H8Pl8gdVm7CllAzL36cF j6+Z1cAbhqKKsnyF7gNzLkNys4AmNRs4BVyFJrubxq5Oqo6ZHdFMauETV09drb4mF4l1ai6 RrEy2KS/GmBO74cI9l00m2vVlBJjy39JJPcr/kZks2sG7N3E9rxk1WkCXyhw== Received: from fifthhorseman.net (lair.fifthhorseman.net [108.58.6.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id D2AA2F9A6; Tue, 16 Feb 2021 12:08:06 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 3943A2053E; Tue, 16 Feb 2021 12:08:02 -0500 (EST) From: Daniel Kahn Gillmor To: Werner Koch Cc: Guillem Jover , Andrew Gallagher , openpgp@ietf.org In-Reply-To: <87h7mcl6mx.fsf@wheatstone.g10code.de> References: <161254580617.29620.7114088127291075805@ietfa.amsl.com> <76fe41fc-f14e-fe3c-db02-7e5b7629dc8a@gmx.net> <1612693541055.92697@cs.auckland.ac.nz> <87blckvqa5.fsf@fifthhorseman.net> <87h7mcl6mx.fsf@wheatstone.g10code.de> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEX+i03xYJKwYBBAHaRw8BAQdACA4xvL/xI5dHedcnkfViyq84doe8zFRid9jW7CC9XBiI0QQf FgoAgwWCX+i03wWJBZ+mAAMLCQcJEOCS6zpcoQ26RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNl cXVvaWEtcGdwLm9yZ/tr8E9NA10HvcAVlSxnox6z62KXCInWjZaiBIlgX6O5AxUKCAKbAQIeARYh BMKfigwB81402BaqXOCS6zpcoQ26AADZHQD/Zx9nc3N2kj13AUsKMr/7zekBtgfSIGB3hRCU74Su G44A/34Yp6IAkndewLxb1WdRSokycnaCVyrk0nb4imeAYyoPtBc8ZGtnQGZpZnRoaG9yc2VtYW4u bmV0PojRBBMWCgCDBYJf6LTfBYkFn6YAAwsJBwkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3Rh dGlvbnMuc2VxdW9pYS1wZ3Aub3JnL0Gwxvypz2tu1IPG+yu1zPjkiZwpscsitwrVvzN3bbADFQoI ApsBAh4BFiEEwp+KDAHzXjTYFqpc4JLrOlyhDboAAPkXAP0Z29z7jW+YzLzPTQML4EQLMbkHOfU4 +s+ki81Czt0WqgD/SJ8RyrqDCtEP8+E4ZSR01ysKqh+MUAsTaJlzZjehiQ24MwRf6LTfFgkrBgEE AdpHDwEBB0DkKHOW2kmqfAK461+acQ49gc2Z6VoXMChRqobGP0ubb4kBiAQYFgoBOgWCX+i03wWJ BZ+mAAkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3Jnfvo+ nHoxDwaLaJD8XZuXiaqBNZtIGXIypF1udBBRoc0CmwICHgG+oAQZFgoAbwWCX+i03wkQPp1xc3He VlxHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnaheiqE7Pfi3Atb3GGTw+ jFcBGOaobgzEJrhEuFpXREEWIQQttUkcnfDcj0MoY88+nXFzcd5WXAAAvrsBAIJ5sBg8Udocv25N stN/zWOiYpnjjvOjVMLH4fV3pWE1AP9T6hzHz7hRnAA8d01vqoxOlQ3O6cb/kFYAjqx3oMXSBhYh BMKfigwB81402BaqXOCS6zpcoQ26AADX7gD/b83VObe14xrNP8xcltRrBZF5OE1rQSPkMNy+eWpk eCwA/1hxiS8ZxL5/elNjXiWuHXEvUGnRoVj745Vl48sZPVYMuDgEX+i03xIKKwYBBAGXVQEFAQEH QIGex1WZbH6xhUBve5mblScGYU+Y8QJOomXH+rr5tMsMAwEICYjJBBgWCgB7BYJf6LTfBYkFn6YA CRDgkus6XKENukcUAAAAAAAeACBzYWx0QG5vdGF0aW9ucy5zZXF1b2lhLXBncC5vcmcEAx9vTD3b J0SXkhvcRcCr6uIDJwic3KFKxkH1m4QW0QKbDAIeARYhBMKfigwB81402BaqXOCS6zpcoQ26AAAX mwD8CWmukxwskU82RZLMk5fm1wCgMB5z8dA50KLw3rgsCykBAKg1w/Y7XpBS3SlXEegIg1K1e6dR fRxL7Z37WZXoH8AH Date: Tue, 16 Feb 2021 12:08:01 -0500 Message-ID: <871rdguej2.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] whitespace definitions in OpenPGP [was: Re: I-D Action: draft-ietf-openpgp-crypto-refresh-01.txt] 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: Tue, 16 Feb 2021 17:08:15 -0000 --=-=-= Content-Type: text/plain On Tue 2021-02-16 10:11:02 +0100, Werner Koch wrote: > On Mon, 15 Feb 2021 18:56, Daniel Kahn Gillmor said: > >> It seems clear to me that the text about whitespace that was merged into >> -01 doesn't have WG consensus at the moment -- iiuc, it may address the > > The problem with such minor changes is that they require extensive > interop tests. Back when we started with OpenPGP we had to tweak these > things a lot until all 3 implementations were interoperable. yep -- this is a great place to apply an interop test. I note that there are some "linebreak normalization tests" at the tests that use SOP: https://tests.sequoia-pgp.org/#Detached_signatures__Linebreak_normalization this contains some un-colored rows where you can see incompatibility between implementations, and where neither proposed text offers guidance as to which should be preferred. Anyone proposing a future textual change to try to improve the situation should take a look at that list. Proposals for additional cases to test would also be useful. > If we really want to make the definition more strict, lets do this after > all chartered changes have been done. I agree that solving this problem isn't higher urgency than the chartered text, which is why i've proposed reverting to the text from RFC 4880 and opened https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/11 to track it in our backlog. (i've tagged it with the "unchartered" label as a reminder) --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQttUkcnfDcj0MoY88+nXFzcd5WXAUCYCv78QAKCRA+nXFzcd5W XCFaAQCv4JM+gD8r5I9VB2vdb3aZs+pWryl7ZA1oBlI/pBWWMgD+MqTEtsjPUUyu 93MZtIetj0IpaWaLhGlkjPUFvcTS1AM= =0LEx -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Feb 16 11:29:27 2021 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 2DEBD3A0FC7 for ; Tue, 16 Feb 2021 11:29:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 (2048-bit key) header.d=hush.ai 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 RUcgSDfDe_me for ; Tue, 16 Feb 2021 11:29:23 -0800 (PST) Received: from smtp2.hushmail.com (smtp2.hushmail.com [65.39.178.134]) (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 1ECF53A0FC5 for ; Tue, 16 Feb 2021 11:29:21 -0800 (PST) Received: from smtp2.hushmail.com (localhost [127.0.0.1]) by smtp2.hushmail.com (Postfix) with SMTP id A097FA01F6 for ; Tue, 16 Feb 2021 19:29:20 +0000 (UTC) X-hush-tls-connected: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=hush.ai; h=date:to:subject:from; s=hush; bh=ZLsMUU+y/5teswcAFVqcczze67toichkHnckc8JMjGs=; b=O85HWhOVVTjTHenI8GOGsjsPGBZvT0SNwDRVTgK2u2Z2jtCH2/cfwjlRpZvvjLMkoirpgrBU2TCPxuK9/3pD1bdUOsu7x1RLpMsfLCXwaQcUL3fmwpqsL5EI5kEl1820taGcIRDSW3Q8lA3qFltrXmJGcVu1CdY/gMYp6GrpBTPocQSefK3KDNVyLpuouDq+F//PHY7QhIJPvoWNMJmLwl7LqmOCNgon94TYr2G8bSfginC6ZUQ5UO3K0e1ra5na3XW18eWsdxuqrNC+vH7UADvJvBzx+9RSakhZJwLR9kff+paJDEuCE0VVRmFfVJP2GhwQZRzSeJBNzP2UJH89jA== Received: from smtp.hushmail.com (w6.hushmail.com [65.39.178.92]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp2.hushmail.com (Postfix) with ESMTPS; Tue, 16 Feb 2021 19:29:20 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 48) id 0D38B827BB0; Tue, 16 Feb 2021 19:29:20 +0000 (UTC) MIME-Version: 1.0 Date: Tue, 16 Feb 2021 14:29:19 -0500 To: "Daniel Kahn Gillmor" , "openpgp" From: vedaal@nym.hush.com In-Reply-To: <871rdguej2.fsf@fifthhorseman.net> References: <161254580617.29620.7114088127291075805@ietfa.amsl.com> <76fe41fc-f14e-fe3c-db02-7e5b7629dc8a@gmx.net> <1612693541055.92697@cs.auckland.ac.nz> <87blckvqa5.fsf@fifthhorseman.net> <87h7mcl6mx.fsf@wheatstone.g10code.de> <871rdguej2.fsf@fifthhorseman.net> X-hush-end-of-body-position: 39 Content-Type: multipart/alternative; boundary="=_37900dcc8f47a48544e43d2b3e04fd1e" Message-Id: <20210216192920.0D38B827BB0@smtp.hushmail.com> Archived-At: Subject: Re: [openpgp] whitespace definitions in OpenPGP [was: Re: I-D Action: draft-ietf-openpgp-crypto-refresh-01.txt] 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: Tue, 16 Feb 2021 19:29:25 -0000 --=_37900dcc8f47a48544e43d2b3e04fd1e Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" On 2/16/2021 at 12:08 PM, "Daniel Kahn Gillmor" wrote: Proposals for additional cases to test would also be useful. ===== PDF renders an empty line as whitespace, even if there is a line return. This functionally means that the empty line after the PGP header and the Cyphertext will be interpreted as being omitted, even if copied from the PDF. If it is possible, I would suggest that both cases be accepted, i.e. with a LR/empty line after the header and the cyphertext, and if no such empty line exists. vedaal --=_37900dcc8f47a48544e43d2b3e04fd1e Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8"
On 2/16/2021 at 12:08 PM, "Daniel Kahn Gillmor" <dkg@fifthhorseman.= net> wrote:

Proposals for additional= cases to test
would also be useful.

=3D=3D=3D=3D=3D
PDF rende= rs an empty line as whitespace, even if there is a line return.

This= functionally means that the empty line after the PGP header and the Cypher= text
will be interpreted as being omitted, even if copied from the PDF.<= br>
If it is possible, I would suggest that both cases be accepted, = ;
i.e.  with a LR/empty line after the header and the cyphertext,and if no such empty line exists.


vedaal
 --=_37900dcc8f47a48544e43d2b3e04fd1e-- From nobody Wed Feb 17 05:19:03 2021 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 BC1603A1A06 for ; Wed, 17 Feb 2021 05:19:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.306 X-Spam-Level: X-Spam-Status: No, score=-1.306 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=zswtLvqI; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=lS8gyj23 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 t4zmb8KjVTO1 for ; Wed, 17 Feb 2021 05:18:59 -0800 (PST) Received: from che.mayfirst.org (unknown [162.247.75.117]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACA003A1A03 for ; Wed, 17 Feb 2021 05:18:59 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1613567938; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=2eZReYZfZgL57GQK3yjA9CJYfkHjr4wCrTKSkG63m/c=; b=zswtLvqIg63G/2I5rNH0tYNbG+XXXQysJ2+Jgn2yTYITtafwYhLMd9LyXOkJbI+2j7RgX oFPvjzBaio2KFKDBA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1613567938; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=2eZReYZfZgL57GQK3yjA9CJYfkHjr4wCrTKSkG63m/c=; b=lS8gyj23W8Yi765xk554Xq4o7hdixV4AYZC1Jml9gkrw7pcY8kByaNlz8C7iP78i1NKB9 Kp2pMwBXQM0PL/YdpCU6FogPNFj3ht92x1m+nJy09BgaULW0eUUJ9SrJ+nCeTLSixWuXVaa X94g+AtX4SdL53iZXHxeE+5GJSelbniu/3Ao6ou3ahefKqh5cFojFP/Zqo24gFa84Zg22hM AnMn/I+3+zhFweJofMkMj2s9rN5GLoM+M1/bMPNeZP8eukIgGvlxxbgGSvYefhwEGlgE5eu reiQI/o9+bKvdeDW76Adm70IzkmGCfK6xXuQj9nH9piENwp1l/+HoKucOiMA== Received: from fifthhorseman.net (lair.fifthhorseman.net [108.58.6.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 720ACF9A7; Wed, 17 Feb 2021 08:18:57 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 5704520458; Tue, 16 Feb 2021 18:52:49 -0500 (EST) From: Daniel Kahn Gillmor To: vedaal@nym.hush.com, openpgp@ietf.org In-Reply-To: <20210216192920.0D38B827BB0@smtp.hushmail.com> References: <161254580617.29620.7114088127291075805@ietfa.amsl.com> <76fe41fc-f14e-fe3c-db02-7e5b7629dc8a@gmx.net> <1612693541055.92697@cs.auckland.ac.nz> <87blckvqa5.fsf@fifthhorseman.net> <87h7mcl6mx.fsf@wheatstone.g10code.de> <871rdguej2.fsf@fifthhorseman.net> <20210216192920.0D38B827BB0@smtp.hushmail.com> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEX+i03xYJKwYBBAHaRw8BAQdACA4xvL/xI5dHedcnkfViyq84doe8zFRid9jW7CC9XBiI0QQf FgoAgwWCX+i03wWJBZ+mAAMLCQcJEOCS6zpcoQ26RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNl cXVvaWEtcGdwLm9yZ/tr8E9NA10HvcAVlSxnox6z62KXCInWjZaiBIlgX6O5AxUKCAKbAQIeARYh BMKfigwB81402BaqXOCS6zpcoQ26AADZHQD/Zx9nc3N2kj13AUsKMr/7zekBtgfSIGB3hRCU74Su G44A/34Yp6IAkndewLxb1WdRSokycnaCVyrk0nb4imeAYyoPtBc8ZGtnQGZpZnRoaG9yc2VtYW4u bmV0PojRBBMWCgCDBYJf6LTfBYkFn6YAAwsJBwkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3Rh dGlvbnMuc2VxdW9pYS1wZ3Aub3JnL0Gwxvypz2tu1IPG+yu1zPjkiZwpscsitwrVvzN3bbADFQoI ApsBAh4BFiEEwp+KDAHzXjTYFqpc4JLrOlyhDboAAPkXAP0Z29z7jW+YzLzPTQML4EQLMbkHOfU4 +s+ki81Czt0WqgD/SJ8RyrqDCtEP8+E4ZSR01ysKqh+MUAsTaJlzZjehiQ24MwRf6LTfFgkrBgEE AdpHDwEBB0DkKHOW2kmqfAK461+acQ49gc2Z6VoXMChRqobGP0ubb4kBiAQYFgoBOgWCX+i03wWJ BZ+mAAkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3Jnfvo+ nHoxDwaLaJD8XZuXiaqBNZtIGXIypF1udBBRoc0CmwICHgG+oAQZFgoAbwWCX+i03wkQPp1xc3He VlxHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnaheiqE7Pfi3Atb3GGTw+ jFcBGOaobgzEJrhEuFpXREEWIQQttUkcnfDcj0MoY88+nXFzcd5WXAAAvrsBAIJ5sBg8Udocv25N stN/zWOiYpnjjvOjVMLH4fV3pWE1AP9T6hzHz7hRnAA8d01vqoxOlQ3O6cb/kFYAjqx3oMXSBhYh BMKfigwB81402BaqXOCS6zpcoQ26AADX7gD/b83VObe14xrNP8xcltRrBZF5OE1rQSPkMNy+eWpk eCwA/1hxiS8ZxL5/elNjXiWuHXEvUGnRoVj745Vl48sZPVYMuDgEX+i03xIKKwYBBAGXVQEFAQEH QIGex1WZbH6xhUBve5mblScGYU+Y8QJOomXH+rr5tMsMAwEICYjJBBgWCgB7BYJf6LTfBYkFn6YA CRDgkus6XKENukcUAAAAAAAeACBzYWx0QG5vdGF0aW9ucy5zZXF1b2lhLXBncC5vcmcEAx9vTD3b J0SXkhvcRcCr6uIDJwic3KFKxkH1m4QW0QKbDAIeARYhBMKfigwB81402BaqXOCS6zpcoQ26AAAX mwD8CWmukxwskU82RZLMk5fm1wCgMB5z8dA50KLw3rgsCykBAKg1w/Y7XpBS3SlXEegIg1K1e6dR fRxL7Z37WZXoH8AH Date: Tue, 16 Feb 2021 18:52:48 -0500 Message-ID: <87v9artvsf.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] whitespace definitions in OpenPGP 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, 17 Feb 2021 13:19:02 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi vedaal-- On Tue 2021-02-16 14:29:19 -0500, vedaal@nym.hush.com wrote: > On 2/16/2021 at 12:08 PM, "Daniel Kahn Gillmor" wrote: > Proposals for additional cases to test would also be useful. > > =3D=3D=3D=3D=3D > PDF renders an empty line as whitespace, even if there is a line > return. > > This functionally means that the empty line after the PGP header and > the Cyphertext > will be interpreted as being omitted, even if copied from the PDF. I don't know what PDF you're talking about. Are you referring to a specific example PDF? to a (common?) form of translation between ASCII text streams and PDFs? to something else? > If it is possible, I would suggest that both cases be accepted,=20 > i.e. with a LR/empty line after the header and the cyphertext, > and if no such empty line exists. The goal of the whitespace canonicalization as i understand it is *exactly* this -- that regardless of how the unprintable characters show up (or don't), a valid signature will be seen as valid. However, the thing that is validated is the canonicalized version, not any of the potential whitespace variants. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQttUkcnfDcj0MoY88+nXFzcd5WXAUCYCxa0QAKCRA+nXFzcd5W XLcnAP9nMJ/2/rH5Z1JQll+6nqPWh03zRMr5LiWTJmuRmppw4wD/ch8TnUOZIcl0 M0WvcPveePQk5mLyojWVdyxEdwu2zA0= =5nm3 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Feb 19 09:08:14 2021 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 DE5883A11DE; Fri, 19 Feb 2021 09:08:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, PDS_RDNS_DYNAMIC_FP=0.01, RCVD_IN_SORBS_DUL=0.001, RDNS_DYNAMIC=0.982, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hadrons.org 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 D7ugWx7cMdgu; Fri, 19 Feb 2021 09:08:10 -0800 (PST) Received: from pulsar.hadrons.org (2.152.178.181.dyn.user.ono.com [2.152.178.181]) (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 DE6993A11E0; Fri, 19 Feb 2021 09:08:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=hadrons.org ; s=201908; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:From:Reply-To:Subject:Content-Transfer-Encoding: Content-ID:Content-Description:X-Debbugs-Cc; bh=/LnYSaIO6ynX4Xmj2J6eXN5m/eOK40jHkV6CnqMBqpc=; b=Y984C6e9O2jjsEHp0HLZasAp24 DyYcrRBZQ01MROWTntu8wbWllyEkpzrz8hBTusRJZyNWpt4lIYT0vV+6SMeUOvb39Ing/O4fF7LaE 4JSRLO3Ah4BubmbNvrPBsQ2sMfXC34mjiuasngQTpb7HyKTs31cmBu8evGMjfeaF88hSgCdkK+L/z 1Wkld8Ez4UN8AsNMwJP0gWwIXWHdwQ5bGc4uSI/pgK7k5YUxP1/fFJ/dpNeyAVMpViqc85NK959L1 6vegoRYgUJ05nDWOGcfdTk4YaX22XnIIcFhlaQC9Q3bYf4WEWwRj5VIXbMIUvNuXngLlBO2MVp5Lw B//rVXcg==; Received: from guillem by pulsar.hadrons.org with local (Exim 4.92) (envelope-from ) id 1lD9G5-0001y5-J2; Fri, 19 Feb 2021 18:08:01 +0100 Date: Fri, 19 Feb 2021 18:08:01 +0100 From: Guillem Jover To: Daniel Kahn Gillmor Cc: Guillem Jover , Andrew Gallagher , openpgp@ietf.org Message-ID: References: <161254580617.29620.7114088127291075805@ietfa.amsl.com> <76fe41fc-f14e-fe3c-db02-7e5b7629dc8a@gmx.net> <1612693541055.92697@cs.auckland.ac.nz> <87blckvqa5.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87blckvqa5.fsf@fifthhorseman.net> Archived-At: Subject: Re: [openpgp] whitespace definitions in OpenPGP [was: Re: I-D Action: draft-ietf-openpgp-crypto-refresh-01.txt] 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: Fri, 19 Feb 2021 17:08:13 -0000 On Mon, 2021-02-15 at 18:56:34 -0500, Daniel Kahn Gillmor wrote: > It seems clear to me that the text about whitespace that was merged into > -01 doesn't have WG consensus at the moment -- iiuc, it may address the > original concern raised by Guillem, but is unintentionally overbroad, > and might introduce further incompatibilities between implementations if > they try to follow the spec as written. Ack. > In the meantime, so we don't lose sight of the legitimate problem that > Guillem wants addressed, I've opened > https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/11 Thanks. I think there are three related issues here: * Non-uniform definition and usage of "whitespace/blank" in the RFC. This makes it difficult to understand and interpret what's intended, and affects how people implement. (Clarifying this was my main intent.) * Consideration on what set of whitespace should be accepted as valid, even reducing or augmenting. This is going to create a potential tension between interop, backwards compatibility and security concerns when chaining various implementations. (I don't mind greatly about this one, as for dpkg I'd need to decide based on the least common denominator from the implementations supported anyway.) * Documenting that regardless of the set of characters defined as valid whitespace, accepting a non-reduced set of characters can have security implications when chaining various implementations with different acceptance checks. (I think this would also be useful for glue implementations and "users", such as dpkg.) > If someone from the group wants to propose alternate text that addresses > the issue but doesn't introduce the inconsistencies identified by Andrew > and others, then please propose that text on-list here (in a different > thread?) -- and if you can also make it as a merge request on gitlab > that'd be a bonus. I might try, but I'm not sure I'll have the immediate time for this. Thanks, Guillem From nobody Mon Feb 22 14:40:44 2021 Return-Path: X-Original-To: openpgp@ietf.org Delivered-To: openpgp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CC2753A2116; Mon, 22 Feb 2021 14:40:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: openpgp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.26.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: openpgp@ietf.org Message-ID: <161403364280.6110.15547010093728410699@ietfa.amsl.com> Date: Mon, 22 Feb 2021 14:40:42 -0800 Archived-At: Subject: [openpgp] I-D Action: draft-ietf-openpgp-crypto-refresh-02.txt X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2021 22:40:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Specification for Pretty Good Privacy WG of the IETF. Title : OpenPGP Message Format Authors : Werner Koch Paul Wouters Filename : draft-ietf-openpgp-crypto-refresh-02.txt Pages : 113 Date : 2021-02-22 Abstract: { Work in progress to update the OpenPGP specification from RFC4880 } This document specifies the message formats used in OpenPGP. OpenPGP provides encryption with public-key or symmetric cryptographic algorithms, digital signatures, compression and key management. This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-openpgp-crypto-refresh/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-02.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-openpgp-crypto-refresh-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Feb 22 18:19:12 2021 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 B13B53A2424 for ; Mon, 22 Feb 2021 18:19:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=nohats.ca 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 9y5bjW7ylf56 for ; Mon, 22 Feb 2021 18:19:08 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 2D82E3A2426 for ; Mon, 22 Feb 2021 18:19:07 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4Dl2mV1pkFz319 for ; Tue, 23 Feb 2021 03:19:06 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1614046746; bh=pFZVsqy4YFR20j0iJGIegrrp7OfYI+us8zWaZci/yNs=; h=Date:From:To:Subject; b=b5bWHy7kMekxAraMIx/z99w9N0pB2uLC4m3r4esnkWUUW2od/29dk/I0wmlwliALC jgIgVhFrSaPirnmhgV4E9q6ULAFd1k2qoa2BicyOeaYnxOhdD0hacFx03YfLkgT4zm Y9gEaivdwO/4mH/h5tMEHYV5DkyVjtuUMnkwz5tw= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id L-BPWKzjlAnx for ; Tue, 23 Feb 2021 03:19:04 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Tue, 23 Feb 2021 03:19:04 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 7580B6029BA0; Mon, 22 Feb 2021 21:19:03 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6CFDE66B1E for ; Mon, 22 Feb 2021 21:19:03 -0500 (EST) Date: Mon, 22 Feb 2021 21:19:03 -0500 (EST) From: Paul Wouters To: openpgp@ietf.org Message-ID: <7d8bdda1-4e5c-6c10-f3cd-1d191fad595c@nohats.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [openpgp] I-D Action: draft-ietf-openpgp-crypto-refresh-02.txt (fwd) 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: Tue, 23 Feb 2021 02:19:11 -0000 Hi, I pushed an updated version of the crypto refresh document: https://www.ietf.org/rfcdiff?url2=draft-ietf-openpgp-crypto-refresh-02 I've also pushed the git changes to https://gitlab.com/openpgp-wg/rfc4880bis The commit on white space changes was reverted, as the WG will be re-opening that discussion later once we have all the consensus items from the previous 4880bis discussion re-published in this document. The following items were merged in: - Produce 4-level-deep ToC - Reserve codepoints in the registries - reorganize signature and asymmetric key value fields - Re-flow the v3 and v4 signature descriptions - Incorporated RFC 6637 (ECDSA and ECDH, using NIST curves) - textual cleanup (no substantive changes) - Update most registries to be SPECIFICATION REQUIRED - Deprecate v3 signatures - Deprecate non-integrity-protected encryption - Include SHA3 - Incorporate Curve25519 for ECDH - Add ECC Point compression flag bytes appendix section - update reference RFC2434 to RFC8126 Please review the changes and let the WG know of any issues you see. This includes if you think something was merged that did not have WG consensus. Paul From nobody Tue Feb 23 05:15:38 2021 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 CD10E3A2B2F for ; Tue, 23 Feb 2021 05:15:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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=pass (1024-bit key) header.d=ihtfp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPth30oKkibl for ; Tue, 23 Feb 2021 05:15:34 -0800 (PST) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E4F73A2B97 for ; Tue, 23 Feb 2021 05:15:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id D0376E2040; Tue, 23 Feb 2021 08:15:07 -0500 (EST) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 10851-10; Tue, 23 Feb 2021 08:15:06 -0500 (EST) Received: by mail2.ihtfp.org (Postfix, from userid 48) id 73B2EE2042; Tue, 23 Feb 2021 08:15:06 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1614086106; bh=8od0f9SAmnQeCdQ4+rEm9bLHfOWFeiK9ymDxnJj0Rus=; h=In-Reply-To:References:Date:Subject:From:To:Cc; b=PJvcFdjrCLaUifYWuAi+9v9slmuo26X3gh9zrMcguaSOeg728m4z1irt1yur5wnWt 21R1RiR97A1IIweixJIViFs1QDNLWYiwRya/7t6jh91An3PGdUCZFHbb0HHefqGEcO WpF8ocH3w00OG2UCTP7kOVOgvi6BV48nKDXB8aCc= Received: from 192.168.248.239 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Tue, 23 Feb 2021 08:15:06 -0500 Message-ID: <4f3d66b74b46b5b8bf27b5e1589bf80e.squirrel@mail2.ihtfp.org> In-Reply-To: <7d8bdda1-4e5c-6c10-f3cd-1d191fad595c@nohats.ca> References: <7d8bdda1-4e5c-6c10-f3cd-1d191fad595c@nohats.ca> Date: Tue, 23 Feb 2021 08:15:06 -0500 From: "Derek Atkins" To: "Paul Wouters" Cc: openpgp@ietf.org User-Agent: SquirrelMail/1.4.22-14.fc20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Subject: Re: [openpgp] I-D Action: draft-ietf-openpgp-crypto-refresh-02.txt (fwd) 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: Tue, 23 Feb 2021 13:15:37 -0000 Hi, Current text says: Implementations SHOULD generate V4 signatures. Implementations MUST NOT create version 3 signatures; they MAY accept version 3 signatures. There is no MUST create version. Is this intended to change? Later (5.8): This packet is obsolete. An implementation MUST NOT create this packet. An implementation MAY process such a packet but it MUST return a clear diagnostic that a non-integrity protected packet has been processed. The implementation SHOULD also return an error in this case and stop processing. I'm confused by this text. If an implementation chooses to process this packet type (e.g. I have 20-year-old PGP-encrypted messages that I'd still like to be able to read without re-encrypting them), why are you saying that it should return an error and stop processing? So it MAY process but SHOULD stop processing? I'm confused. Those were the only issues I noticed reading through this version. Thank you for your hard work! -derek On Mon, February 22, 2021 9:19 pm, Paul Wouters wrote: > > Hi, > > I pushed an updated version of the crypto refresh document: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-openpgp-crypto-refresh-02 > > I've also pushed the git changes to > https://gitlab.com/openpgp-wg/rfc4880bis > > > The commit on white space changes was reverted, as the WG will be > re-opening that discussion later once we have all the consensus > items from the previous 4880bis discussion re-published in this > document. > > The following items were merged in: > > - Produce 4-level-deep ToC > - Reserve codepoints in the registries > - reorganize signature and asymmetric key value fields > - Re-flow the v3 and v4 signature descriptions > - Incorporated RFC 6637 (ECDSA and ECDH, using NIST curves) > - textual cleanup (no substantive changes) > - Update most registries to be SPECIFICATION REQUIRED > - Deprecate v3 signatures > - Deprecate non-integrity-protected encryption > - Include SHA3 > - Incorporate Curve25519 for ECDH > - Add ECC Point compression flag bytes appendix section > - update reference RFC2434 to RFC8126 > > Please review the changes and let the WG know of any issues you see. > This includes if you think something was merged that did not have WG > consensus. > > Paul > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Tue Feb 23 08:10:45 2021 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 E8D1D3A2D26 for ; Tue, 23 Feb 2021 08:10:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 glnSveCJ1X8p for ; Tue, 23 Feb 2021 08:10:41 -0800 (PST) Received: from mail.monkeyblade.net (shards.monkeyblade.net [23.128.96.9]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 333C03A1D5B for ; Tue, 23 Feb 2021 08:10:38 -0800 (PST) Received: from [IPv6:2600:8806:404:9100::9baa] (unknown [IPv6:2600:8806:404:9100::9baa]) by mail.monkeyblade.net (Postfix) with ESMTPSA id 3644C4D0C5DC0 for ; Tue, 23 Feb 2021 08:10:37 -0800 (PST) To: openpgp@ietf.org References: <7d8bdda1-4e5c-6c10-f3cd-1d191fad595c@nohats.ca> <4f3d66b74b46b5b8bf27b5e1589bf80e.squirrel@mail2.ihtfp.org> From: "Robert J. Hansen" Message-ID: Date: Tue, 23 Feb 2021 11:10:35 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: <4f3d66b74b46b5b8bf27b5e1589bf80e.squirrel@mail2.ihtfp.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (mail.monkeyblade.net [0.0.0.0]); Tue, 23 Feb 2021 08:10:37 -0800 (PST) Archived-At: Subject: Re: [openpgp] I-D Action: draft-ietf-openpgp-crypto-refresh-02.txt (fwd) 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: Tue, 23 Feb 2021 16:10:44 -0000 > I'm confused by this text. If an implementation chooses to process > this packet type (e.g. I have 20-year-old PGP-encrypted messages > that I'd still like to be able to read without re-encrypting them), > why are you saying that it should return an error and stop > processing? So it MAY process but SHOULD stop processing? I'm > confused. "MAY process but SHOULD stop" is the way I'd read that guidance: although a conforming implementation technically may process the packet, it should not do so absent a compelling reason. Perhaps this text instead? "This packet is obsolete. An implementation MUST NOT create this packet. An implementation MAY process such a packet but it MUST return a clear diagnostic that a non-integrity protected packet has been processed. Unless the user explicitly directs otherwise, the implementation SHOULD also return an error in this case and stop processing." From nobody Tue Feb 23 09:20:14 2021 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 A5FFB3A0BDE for ; Tue, 23 Feb 2021 09:20:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.099 X-Spam-Level: X-Spam-Status: No, score=-7.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, 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=gnupg.org 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 eD5ErQGKf2xD for ; Tue, 23 Feb 2021 09:20:11 -0800 (PST) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (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 C7CCE3A0BDC for ; Tue, 23 Feb 2021 09:20:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnupg.org; s=20181017; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=asInD0YABL55oLMdqD80WdsWCg1RmhAUZGvGDzNEIH0=; b=g/NP//cCsadTwITCzAFYdltAMo qUN/193fb0Y38SL+68jplZLa+kOZfQcOByHZoi3aG6Zo5StQZft9izpNyYx69ExQXUYkIwVN+/3zI En81rOalAnYhBR4zNmqmCuR+WUIEyJdTRl+j3vKA0hA6QDS3Uns+poD4PJRsh2fhY8Pg=; Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1lEbM0-0005GI-Pm for ; Tue, 23 Feb 2021 18:20:08 +0100 Received: from wk by wheatstone.g10code.de with local (Exim 4.92 #5 (Debian)) id 1lEbI7-0008JS-Ny; Tue, 23 Feb 2021 18:16:07 +0100 From: Werner Koch To: "Derek Atkins" Cc: "Paul Wouters" , openpgp@ietf.org References: <7d8bdda1-4e5c-6c10-f3cd-1d191fad595c@nohats.ca> <4f3d66b74b46b5b8bf27b5e1589bf80e.squirrel@mail2.ihtfp.org> Organisation: GnuPG e.V. X-message-flag: Mails containing HTML will not be read! Please send only plain text. Mail-Followup-To: "Derek Atkins" , "Paul Wouters" , openpgp@ietf.org Date: Tue, 23 Feb 2021 18:16:06 +0100 In-Reply-To: <4f3d66b74b46b5b8bf27b5e1589bf80e.squirrel@mail2.ihtfp.org> (Derek Atkins's message of "Tue, 23 Feb 2021 08:15:06 -0500") Message-ID: <87a6rug0x5.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=GOE_eavesdropping_NATO_doctrine_Internet_defense_information_warfare"; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] I-D Action: draft-ietf-openpgp-crypto-refresh-02.txt (fwd) 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: Tue, 23 Feb 2021 17:20:14 -0000 --=GOE_eavesdropping_NATO_doctrine_Internet_defense_information_warfare Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 23 Feb 2021 08:15, Derek Atkins said: > Implementations SHOULD generate V4 signatures. Implementations MUST > NOT create version 3 signatures; they MAY accept version 3 > signatures. > > There is no MUST create version. Is this intended to change? This is is an editorial problem due to our step by step re-iteration process. The dropped draft-ietf-openpgp-rfc4880bis-10.txt had this text: Implementations MUST generate version 5 signatures when using a version 5 key. Implementations SHOULD generate V4 signatures with version 4 keys. Implementations MUST NOT create version 3 signatures; they MAY accept version 3 signatures. which should explain above. But right in the course of re-iteration Paul and me should have noticed that and adjusted it accordingly. Shalom-Salam, Werner =2D-=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=GOE_eavesdropping_NATO_doctrine_Internet_defense_information_warfare Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQSHd0YfKgdOvEgNNZQZzByeCFsQegUCYDU4VwAKCRAZzByeCFsQ er1dAQCjS5uFthzYK+mL/E/Z2/D0FFFvVKuYsuHUSwRW/7Ow1QD/Xfp/4DCFtVA7 W61pwpY1X8sBTt/V4pKret8YvWxwFQI= =5Pbe -----END PGP SIGNATURE----- --=GOE_eavesdropping_NATO_doctrine_Internet_defense_information_warfare-- From nobody Tue Feb 23 09:24:37 2021 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 3A6183A0C1C for ; Tue, 23 Feb 2021 09:24:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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=pass (1024-bit key) header.d=ihtfp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RDDpXhpbO0nV for ; Tue, 23 Feb 2021 09:24:35 -0800 (PST) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB48B3A0C18 for ; Tue, 23 Feb 2021 09:24:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 8C137E2040; Tue, 23 Feb 2021 12:24:33 -0500 (EST) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 17959-01; Tue, 23 Feb 2021 12:24:32 -0500 (EST) Received: by mail2.ihtfp.org (Postfix, from userid 48) id 583E4E2044; Tue, 23 Feb 2021 12:24:32 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1614101072; bh=IO/P9HZfAEyHeQELHJK8Dz7v/I7qM0yfvOAp2fwlkME=; h=In-Reply-To:References:Date:Subject:From:To; b=lKyxsZBzHjCmdRNkVoUAzrS7amQoeyDy50cZi49qcvQG7kdcuyWXmTJUFDOrehUPP KDFiQhoCn34+lodvRsBermyRq7bu97hTysBCb7Vykb8K5A4tIQysiMqIaO35NDmzos SUKaYY0MwaN+h0zgrp07JxyxUlGlxQ5T7j/gg5N4= Received: from 192.168.248.239 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Tue, 23 Feb 2021 12:24:32 -0500 Message-ID: <8473b015f635c0f88f9bceed8acda0f8.squirrel@mail2.ihtfp.org> In-Reply-To: <87a6rug0x5.fsf@wheatstone.g10code.de> References: <7d8bdda1-4e5c-6c10-f3cd-1d191fad595c@nohats.ca> <4f3d66b74b46b5b8bf27b5e1589bf80e.squirrel@mail2.ihtfp.org> <87a6rug0x5.fsf@wheatstone.g10code.de> Date: Tue, 23 Feb 2021 12:24:32 -0500 From: "Derek Atkins" To: "Derek Atkins" , "Paul Wouters" , openpgp@ietf.org User-Agent: SquirrelMail/1.4.22-14.fc20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Subject: Re: [openpgp] I-D Action: draft-ietf-openpgp-crypto-refresh-02.txt (fwd) 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: Tue, 23 Feb 2021 17:24:36 -0000 HI, On Tue, February 23, 2021 12:16 pm, Werner Koch wrote: > On Tue, 23 Feb 2021 08:15, Derek Atkins said: >> Implementations SHOULD generate V4 signatures. Implementations MUST >> NOT create version 3 signatures; they MAY accept version 3 >> signatures. >> >> There is no MUST create version. Is this intended to change? > > This is is an editorial problem due to our step by step re-iteration > process. The dropped draft-ietf-openpgp-rfc4880bis-10.txt had this text: > > Implementations MUST generate version 5 signatures when using a > version 5 key. Implementations SHOULD generate V4 signatures with > version 4 keys. Implementations MUST NOT create version 3 > signatures; they MAY accept version 3 signatures. > > which should explain above. But right in the course of re-iteration > Paul and me should have noticed that and adjusted it accordingly. Okay, so this is "intended to change" are more edits are done. Gotcha. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Thu Feb 25 10:23:15 2021 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 F18753A1EC3 for ; Thu, 25 Feb 2021 10:23:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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=741X8Irz; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=l97BmFJX 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 6dIbkQYFG9sU for ; Thu, 25 Feb 2021 10:23:05 -0800 (PST) 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 88BBF3A1E60 for ; Thu, 25 Feb 2021 10:23:02 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1614277380; h=from : to : subject : date : message-id : mime-version : content-type : from; bh=DhtQ8Fp1Qm+15rZ1fTPEp9taWX8EM8pQEo2zUzuBnM4=; b=741X8Irz+iHQBF9C2QK+on1/GJadMcumge4IJx79efkEdOY64YVFUrqXPR2+pylH7OWxV TloQ0cy/ixY9xW3AA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1614277380; h=from : to : subject : date : message-id : mime-version : content-type : from; bh=DhtQ8Fp1Qm+15rZ1fTPEp9taWX8EM8pQEo2zUzuBnM4=; b=l97BmFJX/7xZSIHrti/7SELEiTvDig78RlKY3QSWEP1fT3h13YMQul6SJrHBy5eCrIKfg 5qxybEEn6vwHokFXmbk7gK9LLMsYRb0UVDEbJ5yz1L17tY7jEbPcrpjaaGiWWEVjXnvnID8 kUKm5ceDw4QKeVKs3oisp/hEfoPL2ZHYOEo+TW2smpmvvMISsT4qkadjHwho3D6hEE5B8KN s4PSKYgwN7jJee4yUKjRixYGOvvplah7ZjWJ4fzFAX3LxOk98M+Epvo4KS+tP8Q7zeZvyxE 91e2qgpeVCaTqj0//+DuEthStO7oDr9YTuO2K4HciYX+mrVCW5yYAh+4B84Q== Received: from fifthhorseman.net (lair.fifthhorseman.net [108.58.6.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id D2FD4F9A6 for ; Thu, 25 Feb 2021 13:23:00 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id DDFFC204B3; Thu, 25 Feb 2021 13:16:58 -0500 (EST) From: Daniel Kahn Gillmor To: openpgp@ietf.org Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEX+i03xYJKwYBBAHaRw8BAQdACA4xvL/xI5dHedcnkfViyq84doe8zFRid9jW7CC9XBiI0QQf FgoAgwWCX+i03wWJBZ+mAAMLCQcJEOCS6zpcoQ26RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNl cXVvaWEtcGdwLm9yZ/tr8E9NA10HvcAVlSxnox6z62KXCInWjZaiBIlgX6O5AxUKCAKbAQIeARYh BMKfigwB81402BaqXOCS6zpcoQ26AADZHQD/Zx9nc3N2kj13AUsKMr/7zekBtgfSIGB3hRCU74Su G44A/34Yp6IAkndewLxb1WdRSokycnaCVyrk0nb4imeAYyoPtBc8ZGtnQGZpZnRoaG9yc2VtYW4u bmV0PojRBBMWCgCDBYJf6LTfBYkFn6YAAwsJBwkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3Rh dGlvbnMuc2VxdW9pYS1wZ3Aub3JnL0Gwxvypz2tu1IPG+yu1zPjkiZwpscsitwrVvzN3bbADFQoI ApsBAh4BFiEEwp+KDAHzXjTYFqpc4JLrOlyhDboAAPkXAP0Z29z7jW+YzLzPTQML4EQLMbkHOfU4 +s+ki81Czt0WqgD/SJ8RyrqDCtEP8+E4ZSR01ysKqh+MUAsTaJlzZjehiQ24MwRf6LTfFgkrBgEE AdpHDwEBB0DkKHOW2kmqfAK461+acQ49gc2Z6VoXMChRqobGP0ubb4kBiAQYFgoBOgWCX+i03wWJ BZ+mAAkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3Jnfvo+ nHoxDwaLaJD8XZuXiaqBNZtIGXIypF1udBBRoc0CmwICHgG+oAQZFgoAbwWCX+i03wkQPp1xc3He VlxHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnaheiqE7Pfi3Atb3GGTw+ jFcBGOaobgzEJrhEuFpXREEWIQQttUkcnfDcj0MoY88+nXFzcd5WXAAAvrsBAIJ5sBg8Udocv25N stN/zWOiYpnjjvOjVMLH4fV3pWE1AP9T6hzHz7hRnAA8d01vqoxOlQ3O6cb/kFYAjqx3oMXSBhYh BMKfigwB81402BaqXOCS6zpcoQ26AADX7gD/b83VObe14xrNP8xcltRrBZF5OE1rQSPkMNy+eWpk eCwA/1hxiS8ZxL5/elNjXiWuHXEvUGnRoVj745Vl48sZPVYMuDgEX+i03xIKKwYBBAGXVQEFAQEH QIGex1WZbH6xhUBve5mblScGYU+Y8QJOomXH+rr5tMsMAwEICYjJBBgWCgB7BYJf6LTfBYkFn6YA CRDgkus6XKENukcUAAAAAAAeACBzYWx0QG5vdGF0aW9ucy5zZXF1b2lhLXBncC5vcmcEAx9vTD3b J0SXkhvcRcCr6uIDJwic3KFKxkH1m4QW0QKbDAIeARYhBMKfigwB81402BaqXOCS6zpcoQ26AAAX mwD8CWmukxwskU82RZLMk5fm1wCgMB5z8dA50KLw3rgsCykBAKg1w/Y7XpBS3SlXEegIg1K1e6dR fRxL7Z37WZXoH8AH Date: Thu, 25 Feb 2021 13:16:58 -0500 Message-ID: <87y2fcdnc5.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: [openpgp] OpenPGP interim meeting tomorrow (2021-02-26 15:00Z) 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: Thu, 25 Feb 2021 18:23:13 -0000 --=-=-= Content-Type: text/plain Hi folks-- The IETF OpenPGP working group has an interim meeting scheduled for tomorrow (Friday Feb 26th) at 15:00 UTC. That's in a little less than 21 hours from now. Please join us! The meeting will use a WebEx WebRTC channel, hosted here: https://ietf.webex.com/ietf/j.php?MTID=m1b3bb4269a2ef10b9995442e09426b84 We expect the meeting to last about an hour, but we have the channel space reserved for two hours in case things run long or there are hiccups getting started. The plan for the interim is to collaboratively map out the remaining steps we need to get the crypto-refresh draft out the door. We'll start with a proposed list of topics that need to make it into the draft, cross-refereced to the charter, and hopefully come away with a reasonable consensus and path forward. Talk to you soon, --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQttUkcnfDcj0MoY88+nXFzcd5WXAUCYDfpmgAKCRA+nXFzcd5W XBIXAP9QlD9lGhKrQWOxNHSd+i2pXuk3Sl9H3lRSpmuiXc9D4wD/VTP3YhI5OJBG vN2QgKn10vtgPSOmg2AjTrCnudnOnwU= =m3gj -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Feb 25 17:20:04 2021 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 7C7953A1482 for ; Thu, 25 Feb 2021 17:19:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 EsEzyxJDQqWR for ; Thu, 25 Feb 2021 17:19:53 -0800 (PST) Received: from mail.direccionemail.com (mail.direccionemail.com [199.195.249.9]) (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 0F30A3A145E for ; Thu, 25 Feb 2021 17:19:49 -0800 (PST) Message-ID: <442e06bef7798e1d6b319cb63279473feeea6989.camel@16bits.net> From: =?ISO-8859-1?Q?=C1ngel?= To: openpgp@ietf.org Date: Fri, 26 Feb 2021 02:19:47 +0100 In-Reply-To: <8473b015f635c0f88f9bceed8acda0f8.squirrel@mail2.ihtfp.org> References: <7d8bdda1-4e5c-6c10-f3cd-1d191fad595c@nohats.ca> <4f3d66b74b46b5b8bf27b5e1589bf80e.squirrel@mail2.ihtfp.org> <87a6rug0x5.fsf@wheatstone.g10code.de> <8473b015f635c0f88f9bceed8acda0f8.squirrel@mail2.ihtfp.org> Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [openpgp] I-D Action: draft-ietf-openpgp-crypto-refresh-02.txt (fwd) 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: Fri, 26 Feb 2021 01:20:02 -0000 Hello all After reviewing these two drafts, I agree there are no substantial changes in draft-ietf-openpgp-crypto-refresh-00.txt from rfc4880, and consider draft-ietf-openpgp-crypto-refresh-02.txt good to iterate from. Some specific comments are provided below. Looking forward to seeing you all at the meeting. - =C1ngel crypto-refresh-00 nitpicks =3D=3D=3D=3D=3D I would prefer to keep single quotes for values referring to single bytes standing by themselves, as rfc4880 did. -00 changed them to double quotes but using single quotes as in C seems better. This happens in * 5.9. Literal Data Packet (Tag 11) ('b', 't', 'u', 'l', '1') vs ("b", "t", "u", "l", "1") * 6.2. Forming ASCII Armor with '-' and ':' * 7.1. Dash-Escaped Text with '-' but does *not* apply to the characters in 8. Regular Expressions Additionally, in 7.1 a single-quoted space (' ') was converted to use backticks (` `), which seems like an error when converting the document. It makes sense in some markdown conversions, but not in the rfc results. In appendix A, an extra space was inserted between "Philip R."=20 and "Zimmermann" (Appendix C in -02) crypto-refresh-01/02 nitpicks =3D=3D=3D=3D=3D At 1. Introduction, change "RFC 5581 (Camellia cipher)" to "RFC 5581 (The Camellia Cipher in OpenPGP)" or "RFC 5581 (Camellia Cipher in OpenPGP)", since just "Camellia cipher" could be confused with the description itself of Camellia (rfc3713). "ECC for OpenPGP" should perhaps be changed to "ECC in OpenPGP" which is th= e preposition used in that rfc title. Full name of RFC 6637 is "Elliptic Curve Cryptography (ECC) in OpenPGP" and would be the proper one if we wanted to use the complete names of the rfc, albeit I don't think that would matter either way. I would prefer to see the new section "ECC Curve OID" as 9.5 instead of 9.2= From nobody Thu Feb 25 17:25:55 2021 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 AD4F33A13FF for ; Thu, 25 Feb 2021 17:25:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 Pl4gzLlGbHnf for ; Thu, 25 Feb 2021 17:25:52 -0800 (PST) Received: from mail.direccionemail.com (mail.direccionemail.com [199.195.249.9]) (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 EFAAE3A13FA for ; Thu, 25 Feb 2021 17:25:51 -0800 (PST) Message-ID: <239af1473534565304e2ecfeca630219417ebc0e.camel@16bits.net> From: =?ISO-8859-1?Q?=C1ngel?= To: openpgp@ietf.org Date: Fri, 26 Feb 2021 02:25:49 +0100 In-Reply-To: <8473b015f635c0f88f9bceed8acda0f8.squirrel@mail2.ihtfp.org> References: <7d8bdda1-4e5c-6c10-f3cd-1d191fad595c@nohats.ca> <4f3d66b74b46b5b8bf27b5e1589bf80e.squirrel@mail2.ihtfp.org> <87a6rug0x5.fsf@wheatstone.g10code.de> <8473b015f635c0f88f9bceed8acda0f8.squirrel@mail2.ihtfp.org> Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [openpgp] I-D Action: draft-ietf-openpgp-crypto-refresh-02.txt (fwd) 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: Fri, 26 Feb 2021 01:25:54 -0000 Hello all After reviewing these two drafts, I agree there are no substantial changes in draft-ietf-openpgp-crypto-refresh-00.txt from rfc4880, and consider draft-ietf-openpgp-crypto-refresh-02.txt good to iterate from. Some specific comments are provided below. Looking forward to seeing you all at the meeting. - =C1ngel crypto-refresh-00 nitpicks =3D=3D=3D=3D=3D I would prefer to keep single quotes for values referring to single bytes standing by themselves, as rfc4880 did. -00 changed them to double quotes but using single quotes as in C seems better. This happens in * 5.9. Literal Data Packet (Tag 11) ('b', 't', 'u', 'l', '1') vs ("b", "t", "u", "l", "1") * 6.2. Forming ASCII Armor with '-' and ':' * 7.1. Dash-Escaped Text with '-' but does *not* apply to the characters in 8. Regular Expressions Additionally, in 7.1 a single-quoted space (' ') was converted to use backticks (` `), which seems like an error when converting the document. It makes sense in some markdown conversions, but not in the rfc results. In appendix A, an extra space was inserted between "Philip R."=20 and "Zimmermann" (Appendix C in -02) crypto-refresh-01/02 nitpicks =3D=3D=3D=3D=3D At 1. Introduction, change "RFC 5581 (Camellia cipher)" to "RFC 5581 (The Camellia Cipher in OpenPGP)" or "RFC 5581 (Camellia Cipher in OpenPGP)", since just "Camellia cipher" could be confused with the description itself of Camellia (rfc3713). "ECC for OpenPGP" should perhaps be changed to "ECC in OpenPGP" which is th= e preposition used in that rfc title. Full name of RFC 6637 is "Elliptic Curve Cryptography (ECC) in OpenPGP" and would be the proper one if we wanted to use the complete names of the rfc, albeit I don't think that would matter either way. I would prefer to see the new section "ECC Curve OID" as 9.5 instead of 9.2 The other blocks are clear registries used directly. "ECC Curve OID" are a different case since they are actually parameter inside Public key wi= th certain ids. It's probably as 9.2 because a former draft likely referred to= it from 9.1, but that doesn't seem to be the case, and is only referred from o= ther completely separate sections. I'm not too keen on the way this section is introduced. I may provide a MR = if I can come up with something. 10.2.2.2. Signature Notation Data Subpacket Notation Flags creates a new r= egistry but it doesn't point to a section with initial values.=20 It should probably link to table 7 of section 5.2.3.16, although that would= need additional columns. Procedural question: is it the right thing for a RFC to state that it "crea= tes a new registry" for those registries which were actually created by an older = RFC it is obsoleting? I feel the text added at 15. Security Considerations still needs some revi= sion.=20 Maybe split part of it to a different section. There are too many things th= ere, and it seems hard to grasp everything it mixes. As a concrete suggestion, I would recommend adding Compatibility Profiles as section 15 instead of 16. Security Considerations (SC) refers to Compatibility Profiles (CP) and Compatibility Profiles refers to Security Considerations, but it seems it would be easier to read Compatibility Profiles first (assuming a linear reading of the rfc). Reference to (SC) is easier to skip (there will be some algorithm choices at that section), whereas the reference to CP is murkier:=20 > Requirement levels indicated elsewhere in this document lead to=09 > the following combinations of algorithms in the OpenPGP profile: > MUST implement P-256 / SHA2-256 / AES-128 / SHOULD implement ... when the reader hasn't been told about OpenPGP profiles and, in fact, some of those algorithms it shows as a MUST are optional at 9.1 / 9.3 An introduction should be added after "16. Compatibility Profiles" and before "16.1" explaining what are Compatibility Profiles and why would they be interesting / needed. You may want to put the temporary Document Workflow appendix as C, so that the other two won't need renumbering on publication. From nobody Fri Feb 26 03:46:51 2021 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 B8C323A13BD for ; Fri, 26 Feb 2021 03:46:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 n1k6tMNBv0Rk for ; Fri, 26 Feb 2021 03:46:49 -0800 (PST) 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 10FF13A13B5 for ; Fri, 26 Feb 2021 03:46:48 -0800 (PST) Received: from p5de92c26.dip0.t-ipconnect.de ([93.233.44.38] 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 1lFba2-0003Ww-Cn; Fri, 26 Feb 2021 11:46:46 +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 1lFba1-000695-P6; Fri, 26 Feb 2021 12:46:46 +0100 Date: Fri, 26 Feb 2021 12:46:45 +0100 Message-ID: <87k0qvaw62.wl-neal@walfield.org> From: "Neal H. Walfield" To: Paul Wouters Cc: openpgp@ietf.org In-Reply-To: <7d8bdda1-4e5c-6c10-f3cd-1d191fad595c@nohats.ca> References: <7d8bdda1-4e5c-6c10-f3cd-1d191fad595c@nohats.ca> 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: [openpgp] Incorporated RFC 6637: SHA2-384 recommendation 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: Fri, 26 Feb 2021 11:46:51 -0000 On Tue, 23 Feb 2021 03:19:03 +0100, Paul Wouters wrote: > - Incorporated RFC 6637 (ECDSA and ECDH, using NIST curves) In the OpenPGP ECC Profile section, SHA2-384 is listed as a SHOULD algorithm: ## OpenPGP ECC Profile A compliant application MUST implement SHA2-256 and SHOULD implement SHA2-384 and SHA2-512. But, in the 'Hash Algorithms' section, it is a MAY algorithm. ## Hash Algorithms Implementations MUST implement SHA-1. Implementations MAY implement other algorithms. MD5 is deprecated. In the 'Security Considerations' section there are two relevant points: # Security Considerations - Requirement levels indicated elsewhere in this document lead to the following combinations of algorithms in the OpenPGP profile: MUST implement NIST curve P-256 / SHA2-256 / AES-128, SHOULD implement NIST curve P-521 / SHA2-512 / AES-256, MAY implement NIST curve P-384 / SHA2-384 / AES-256, among other allowed combinations. - SHA2-224 and SHA2-384 require the same work as SHA2-256 and SHA2-512, respectively. In general, there are few reasons to use them outside of DSS compatibility. So, ECC that uses SHA2-384 is a MAY and SHA2-384 is discouraged. In the past, we've talked about algorithm agility on this mailing list: http://mailarchive.ietf.org/arch/msg/openpgp/2C5jQNKcnUZZUzh84s0Di-GYKV0 And the last version of 4880bis only included SHA3-256 and SHA3-512. https://gitlab.com/openpgp-wg/rfc4880bis/-/blob/main/draft-ietf-openpgp-rfc4880bis-09.txt#L3801 My suggestion is to change the following text: A compliant application MUST implement SHA2-256 and SHOULD implement SHA2-384 and SHA2-512. to A compliant application MUST implement SHA2-256 and SHOULD implement SHA2-512. It MAY implement SHA2-384. Neal From nobody Fri Feb 26 03:50:25 2021 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 88F0D3A13D1 for ; Fri, 26 Feb 2021 03:50:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 VOhd3Lq-2hC6 for ; Fri, 26 Feb 2021 03:50:20 -0800 (PST) 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 792973A13AE for ; Fri, 26 Feb 2021 03:50:20 -0800 (PST) Received: from p5de92c26.dip0.t-ipconnect.de ([93.233.44.38] 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 1lFbdS-0003ad-Ey; Fri, 26 Feb 2021 11:50:18 +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 1lFbdR-0006fr-VY; Fri, 26 Feb 2021 12:50:18 +0100 Date: Fri, 26 Feb 2021 12:50:17 +0100 Message-ID: <87im6faw06.wl-neal@walfield.org> From: "Neal H. Walfield" To: Paul Wouters Cc: openpgp@ietf.org In-Reply-To: <7d8bdda1-4e5c-6c10-f3cd-1d191fad595c@nohats.ca> References: <7d8bdda1-4e5c-6c10-f3cd-1d191fad595c@nohats.ca> 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=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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] I-D Action: draft-ietf-openpgp-crypto-refresh-02.txt (fwd) 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: Fri, 26 Feb 2021 11:50:24 -0000 On Tue, 23 Feb 2021 03:19:03 +0100, Paul Wouters wrote: > - Incorporated RFC 6637 (ECDSA and ECDH, using NIST curves) While reading this change, I encountered some unfortunate wordings and inconsistent formatting. This patch, which is hopefully uncontroversial, fixes those issues. :) Neal =46rom 54faf5c3f184b3470ccda5938688f482a68838fc Mon Sep 17 00:00:00 2001 From: "Neal H. Walfield" Date: Thu, 25 Feb 2021 14:17:22 +0100 Subject: [PATCH] Copy edit 3f09f3c56e14be92007c12622eac889d7f58a8e0 (ECC). - Correct use of comma. - Use capital hex. - Mimic list structure in the rest of the document. - Improve a few awkward sentences. --- crypto-refresh.md | 108 +++++++++++++++++++++++----------------------- 1 file changed, 54 insertions(+), 54 deletions(-) diff --git a/crypto-refresh.md b/crypto-refresh.md index 32e7927..2a9e166 100644 --- a/crypto-refresh.md +++ b/crypto-refresh.md @@ -757,7 +757,7 @@ The body of this packet consists of: =20 - MPI of an EC point representing an ephemeral public key. =20 - - a one-octet size, followed by a symmetric key encoded using the method= described in {{ec-dh-algorithm-ecdh}}. + - A one-octet size, followed by a symmetric key encoded using the method= described in {{ec-dh-algorithm-ecdh}}. =20 The value "m" in the above formulas is derived from the session key as fol= lows. First, the session key is prefixed with a one-octet algorithm identifier t= hat specifies the symmetric encryption algorithm used to encrypt the follow= ing Symmetrically Encrypted Data Packet. @@ -1760,13 +1760,13 @@ The secret key is this single multiprecision intege= r: =20 The public key is this series of values: =20 -- a variable-length field containing a curve OID, formatted as follows: +- A variable-length field containing a curve OID, which is formatted as fo= llows: =20 - - a one-octet size of the following field; values 0 and 0xFF are reserve= d for future extensions, + - A one-octet size of the following field; values 0 and 0xFF are reserve= d for future extensions, =20 - - the octets representing a curve OID, defined in {{ecc-curve-oid}}; + - The octets representing a curve OID (defined in {{ecc-curve-oid}}); =20 -- a MPI of an EC point representing a public key. +- MPI of an EC point representing a public key. =20 The secret key is this single multiprecision integer: =20 @@ -1776,25 +1776,25 @@ The secret key is this single multiprecision intege= r: =20 The public key is this series of values: =20 -- a variable-length field containing a curve OID, formatted as follows: +- A variable-length field containing a curve OID, which is formatted as fo= llows: =20 - - a one-octet size of the following field; values 0 and 0xFF are reserve= d for future extensions, + - A one-octet size of the following field; values 0 and 0xFF are reserve= d for future extensions, =20 - - the octets representing a curve OID, defined in {{ecc-curve-oid}}; + - Octets representing a curve OID, defined in {{ecc-curve-oid}}; =20 -- a MPI of an EC point representing a public key; +- MPI of an EC point representing a public key; =20 -- a variable-length field containing KDF parameters, formatted as follows: +- A variable-length field containing KDF parameters, which is formatted as= follows: =20 - - a one-octet size of the following fields; values 0 and 0xff are reserv= ed for future extensions; + - A one-octet size of the following fields; values 0 and 0xFF are reserv= ed for future extensions, =20 - - a one-octet value 1, reserved for future extensions; + - A one-octet value 1, reserved for future extensions, =20 - - a one-octet hash function ID used with a KDF; + - A one-octet hash function ID used with a KDF, =20 - - a one-octet algorithm ID for the symmetric algorithm used to wrap the = symmetric key used for the message encryption; see {{ec-dh-algorithm-ecdh}}= for details. + - A one-octet algorithm ID for the symmetric algorithm used to wrap the = symmetric key used for the message encryption; see {{ec-dh-algorithm-ecdh}}= for details. =20 -Observe that an ECDH public key is composed of the same sequence of fields= that define an ECDSA key, plus the KDF parameters field. +Observe that an ECDH public key is composed of the same sequence of fields= that define an ECDSA key plus the KDF parameters field. =20 The secret key is this single multiprecision integer: =20 @@ -2433,7 +2433,7 @@ See {{reserved-notes}} for notes on Elgamal Encrypt o= r Sign (20), and X9.42 (21) Implementations MAY implement any other algorithm. =20 =20 -A compatible specification of ECDSA is given in {{RFC6090}} as "KT-I Signa= tures" and in {{SEC1}}; ECDH is defined in {{ec-dh-algorithm-ecdh}} this do= cument. +A compatible specification of ECDSA is given in {{RFC6090}} as "KT-I Signa= tures" and in {{SEC1}}; ECDH is defined in {{ec-dh-algorithm-ecdh}} of this= document. =20 ## ECC Curve OID =20 @@ -2867,7 +2867,7 @@ A thorough introduction to ECC can be found in {{KOBL= ITZ}}. =20 ## Supported ECC Curves =20 -This document references three named prime field curves, defined in {{FIPS= 186}} as "Curve P-256", "Curve P-384", and "Curve P-521". +This document references three named prime field curves defined in {{FIPS1= 86}} as "Curve P-256", "Curve P-384", and "Curve P-521". Further curve "Curve25519", defined in {{RFC7748}} is referenced for use w= ith X25519 (ECDH encryption). =20 The named curves are referenced as a sequence of bytes in this document, c= alled throughout, curve OID. @@ -2882,15 +2882,15 @@ For an uncompressed point the content of the MPI is: =20 B =3D 04 || x || y =20 -where x and y are coordinates of the point P =3D (x, y), each encoded in t= he big-endian format and zero-padded to the adjusted underlying field size. -The adjusted underlying field size is the underlying field size that is ro= unded up to the nearest 8-bit boundary. +where x and y are coordinates of the point P =3D (x, y), and each is encod= ed in the big-endian format and zero-padded to the adjusted underlying fiel= d size. +The adjusted underlying field size is the underlying field size rounded up= to the nearest 8-bit boundary. This encoding is compatible with the definition given in {{SEC1}}. =20 For a custom compressed point the content of the MPI is: =20 B =3D 40 || x =20 -where x is the x coordinate of the point P encoded to the rules defined fo= r the specified curve. +where x is the x coordinate of the point P encoded using the rules defined= for the specified curve. This format is used for ECDH keys based on curves expressed in Montgomery = form. =20 Therefore, the exact size of the MPI payload is 515 bits for "Curve P-256"= , 771 for "Curve P-384", 1059 for "Curve P-521", and 263 for Curve25519. @@ -2902,7 +2902,7 @@ Consider, for example, that while both the public key= and the per-recipient ECDH =20 ## Key Derivation Function =20 -A key derivation function (KDF) is necessary to implement the EC encryptio= n. +A key derivation function (KDF) is necessary to implement EC encryption. The Concatenation Key Derivation Function (Approved Alternative 1) {{SP800= -56A}} with the KDF hash function that is SHA2-256 {{FIPS180}} or stronger = is REQUIRED. See {{compatibility-profiles}} for the details regarding the choice of the= hash function. =20 @@ -2922,65 +2922,65 @@ However, {{SP800-56A}} is the normative source of t= he definition. MB =3D Hash ( 00 || 00 || 00 || 01 || ZB || Param ); return oBits leftmost bits of MB. =20 -Note that ZB in the KDF description above is the compact representation of= X, defined in Section 4.2 of {{RFC6090}}. +Note that ZB in the KDF description above is the compact representation of= X as defined in Section 4.2 of {{RFC6090}}. =20 ## EC DH Algorithm (ECDH) =20 The method is a combination of an ECC Diffie-Hellman method to establish a= shared secret, a key derivation method to process the shared secret into a= derived key, and a key wrapping method that uses the derived key to protec= t a session key used to encrypt a message. =20 -The One-Pass Diffie-Hellman method C(1, 1, ECC CDH) {{SP800-56A}} MUST be = implemented with the following restrictions: the ECC CDH primitive employed= by this method is modified to always assume the cofactor as 1, the KDF spe= cified in {{key-derivation-function}} is used, and the KDF parameters speci= fied below are used. +The One-Pass Diffie-Hellman method C(1, 1, ECC CDH) {{SP800-56A}} MUST be = implemented with the following restrictions: the ECC CDH primitive employed= by this method is modified to always assume the cofactor is 1, the KDF spe= cified in {{key-derivation-function}} is used, and the KDF parameters speci= fied below are used. =20 -The KDF parameters are encoded as a concatenation of the following 5 varia= ble-length and fixed-length fields, compatible with the definition of the O= therInfo bitstring {{SP800-56A}}: +The KDF parameters are encoded as a concatenation of the following 5 varia= ble-length and fixed-length fields, which are compatible with the definitio= n of the OtherInfo bitstring {{SP800-56A}}: =20 -- a variable-length field containing a curve OID, formatted as follows: +- A variable-length field containing a curve OID, which is formatted as fo= llows: =20 - - a one-octet size of the following field + - A one-octet size of the following field, =20 - - the octets representing a curve OID, defined in {{ecc-curve-oid}} + - The octets representing a curve OID defined in {{ecc-curve-oid}}; =20 -- a one-octet public key algorithm ID defined in {{pubkey-algos}} +- A one-octet public key algorithm ID defined in {{pubkey-algos}}; =20 -- a variable-length field containing KDF parameters, identical to the corr= esponding field in the ECDH public key, formatted as follows: +- A variable-length field containing KDF parameters, which are identical t= o the corresponding field in the ECDH public key, and are formatted as foll= ows: =20 - - a one-octet size of the following fields; values 0 and 0xff are reserv= ed for future extensions + - A one-octet size of the following fields; values 0 and 0xFF are reserv= ed for future extensions, =20 - - a one-octet value 01, reserved for future extensions + - A one-octet value 0x01, reserved for future extensions, =20 - - a one-octet hash function ID used with the KDF + - A one-octet hash function ID used with the KDF, =20 - - a one-octet algorithm ID for the symmetric algorithm used to wrap the = symmetric key for message encryption; see {{ec-dh-algorithm-ecdh}} for deta= ils + - A one-octet algorithm ID for the symmetric algorithm used to wrap the = symmetric key for message encryption; see {{ec-dh-algorithm-ecdh}} for deta= ils; =20 -- 20 octets representing the UTF-8 encoding of the string `Anonymous Sende= r=A0=A0=A0=A0`, which is the octet sequence 41 6E 6F 6E 79 6D 6F 75 73 20 5= 3 65 6E 64 65 72 20 20 20 20 +- 20 octets representing the UTF-8 encoding of the string `Anonymous Sende= r=A0=A0=A0=A0`, which is the octet sequence 41 6E 6F 6E 79 6D 6F 75 73 20 5= 3 65 6E 64 65 72 20 20 20 20; =20 -- 20 octets representing a recipient encryption subkey or a master key fin= gerprint, identifying the key material that is needed for the decryption. - For version 5 keys the 20 leftmost octets of the fingerprint are used. +- [ ] 20 octets representing a recipient encryption subkey or a primary ke= y fingerprint identifying the key material that is needed for decryption + (for version 5 keys the 20 leftmost octets of the fingerprint are used). =20 The size of the KDF parameters sequence, defined above, is either 54 for t= he NIST curve P-256, 51 for the curves P-384 and P-521, or 56 for Curve2551= 9. =20 The key wrapping method is described in {{RFC3394}}. -KDF produces a symmetric key that is used as a key-encryption key (KEK) as= specified in {{RFC3394}}. +The KDF produces a symmetric key that is used as a key-encryption key (KEK= ) as specified in {{RFC3394}}. Refer to {{security-considerations}} for the details regarding the choice = of the KEK algorithm, which SHOULD be one of three AES algorithms. Key wrapping and unwrapping is performed with the default initial value of= {{RFC3394}}. =20 The input to the key wrapping method is the value "m" derived from the ses= sion key, as described in {{public-key-encrypted-session-key-packets-tag-1}= }, "Public-Key Encrypted Session Key Packets (Tag 1)", except that the PKCS= #1.5 padding step is omitted. -The result is padded using the method described in {{PKCS5}} to the 8-byte= granularity. +The result is padded using the method described in {{PKCS5}} to an 8-byte = granularity. For example, the following AES-256 session key, in which 32 octets are den= oted from k0 to k31, is composed to form the following 40 octet sequence: =20 - 09 k0 k1 ... k31 c0 c1 05 05 05 05 05 + 09 k0 k1 ... k31 C0 C1 05 05 05 05 05 =20 -The octets c0 and c1 above denote the checksum. +The octets C0 and C1 above denote the checksum. This encoding allows the sender to obfuscate the size of the symmetric enc= ryption key used to encrypt the data. For example, assuming that an AES algorithm is used for the session key, t= he sender MAY use 21, 13, and 5 bytes of padding for AES-128, AES-192, and = AES-256, respectively, to provide the same number of octets, 40 total, as a= n input to the key wrapping method. =20 The output of the method consists of two fields. The first field is the MPI containing the ephemeral key used to establish = the shared secret. -The second field is composed of the following two fields: +The second field is composed of the following two subfields: =20 -- a one-octet encoding the size in octets of the result of the key wrappin= g method; the value 255 is reserved for future extensions; +- One octet encoding the size in octets of the result of the key wrapping = method; the value 255 is reserved for future extensions; =20 -- up to 254 octets representing the result of the key wrapping method, app= lied to the 8-byte padded session key, as described above. +- Up to 254 octets representing the result of the key wrapping method, app= lied to the 8-byte padded session key, as described above. =20 -Note that for session key sizes 128, 192, and 256 bits, the size of the re= sult of the key wrapping method is, respectively, 32, 40, and 48 octets, un= less the size obfuscation is used. +Note that for session key sizes 128, 192, and 256 bits, the size of the re= sult of the key wrapping method is, respectively, 32, 40, and 48 octets, un= less size obfuscation is used. =20 For convenience, the synopsis of the encoding method is given below; howev= er, this section, {{SP800-56A}}, and {{RFC3394}} are the normative sources = of the definition. =20 @@ -3011,7 +3011,7 @@ Note that the recipient obtains the shared secret by = calculating =20 S =3D rV =3D rvG, where (r,R) is the recipient's key pair. =20 -Consistent with {{seipd}}, Modification Detection Code (MDC) MUST be used = anytime the symmetric key is protected by ECDH. +Consistent with {{seipd}}, a Modification Detection Code (MDC) MUST be use= d anytime the symmetric key is protected by ECDH. =20 # Notes on Algorithms {#notes-on-algorithms} =20 @@ -3448,16 +3448,16 @@ NIST P-521 | SHA2-512 | AES-256 =20 Note that the symmetric algorithm preference list may make it impossible= to use the balanced strength of symmetric key algorithms for a correspondi= ng public key. For example, the presence of the symmetric key algorithm IDs and their o= rder in the key preference list affects the algorithm choices available to = the encoding side, which in turn may make the adherence to the table above = infeasible. - Therefore, compliance with this specification is a concern throughout th= e life of the key, starting immediately after the key generation when the k= ey preferences are first added to a key. + Therefore, compliance with this specification is a concern throughout th= e life of the key starting immediately after the key generation when the ke= y preferences are first added to a key. It is generally advisable to position a symmetric algorithm ID of streng= th matching the public key at the head of the key preference list. =20 Encryption to multiple recipients often results in an unordered intersec= tion subset. For example, if the first recipient's set is {A, B} and the second's is = {B, A}, the intersection is an unordered set of two algorithms, A and B. In this case, a compliant application SHOULD choose the stronger encrypt= ion algorithm. =20 - Resource constraints, such as limited computational power, is a likely r= eason why an application might prefer to use the weakest algorithm. + Resource constraints, such as limited computational power, are a reason = why an application might prefer to use the weakest algorithm. On the other side of the spectrum are applications that can implement ev= ery algorithm defined in this document. - Most applications are expected to fall into either of two categories. + Most applications are expected to fall into either of these two categori= es. A compliant application in the second, or strongest, category SHOULD pre= fer AES-256 to AES-192. =20 SHA-1 MUST NOT be used with the ECDSA or the KDF in the ECDH method. @@ -3466,7 +3466,7 @@ NIST P-521 | SHA2-512 | AES-256 None of the ECC methods described in this document are allowed with depr= ecated V3 keys. A compliant application MUST only use iterated and salted S2K to protect= private keys, as defined in {{iterated-and-salted-s2k}}, "Iterated and Sal= ted S2K". =20 - Side channel attacks are a concern when a compliant application's use of= the OpenPGP format can be modeled by a decryption or signing oracle model,= for example, when an application is a network service performing decryptio= n to unauthenticated remote users. + Side channel attacks are a concern when a compliant application's use of= the OpenPGP format can be modeled by a decryption or signing oracle, for e= xample, when an application is a network service performing decryption to u= nauthenticated remote users. ECC scalar multiplication operations used in ECDSA and ECDH are vulnerab= le to side channel attacks. Countermeasures can often be taken at the higher protocol level, such as= limiting the number of allowed failures or time-blinding of the operations= associated with each network interface. Mitigations at the scalar multiplication level seek to eliminate any mea= surable distinction between the ECC point addition and doubling operations. @@ -3481,13 +3481,13 @@ A compliant application MUST implement AES-128 and = SHOULD implement AES-256. =20 A compliant application SHOULD follow {{security-considerations}} regardin= g the choice of the following algorithms for each curve: =20 -- the KDF hash algorithm, +- The KDF hash algorithm, =20 -- the KEK algorithm, +- The KEK algorithm, =20 -- the message digest algorithm and the hash algorithm used in the key cert= ifications, +- The message digest algorithm and the hash algorithm used in the key cert= ifications, =20 -- the symmetric algorithm used for message encryption. +- The symmetric algorithm used for message encryption. =20 It is recommended that the chosen symmetric algorithm for message encrypti= on be no less secure than the KEK algorithm. =20 @@ -3495,7 +3495,7 @@ It is recommended that the chosen symmetric algorithm= for message encryption be =20 A subset of algorithms allowed by this document can be used to achieve {{S= uiteB}} compatibility. The references to {{SuiteB}} in this document are informative. -This document is primarily concerned with format specification, leaving ad= ditional security restrictions unspecified, such as matching the assigned s= ecurity level of information to authorized recipients or interoperability c= oncerns arising from fewer allowed algorithms in {{SuiteB}} than allowed by= this document. +This document is primarily concerned with format specification and leaves = additional security restrictions unspecified, such as matching the assigned= security level of information to authorized recipients or interoperability= concerns arising from fewer allowed algorithms in {{SuiteB}} than allowed = by this document. =20 ### Security Strength at 192 Bits =20 --=20 2.20.1 From nobody Fri Feb 26 03:53:17 2021 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 8614B3A13EB for ; Fri, 26 Feb 2021 03:53:15 -0800 (PST) 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, RCVD_IN_DNSWL_BLOCKED=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 mfN33VyDbSlg for ; Fri, 26 Feb 2021 03:53:13 -0800 (PST) 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 B3EF23A13E7 for ; Fri, 26 Feb 2021 03:53:13 -0800 (PST) Received: from p5de92c26.dip0.t-ipconnect.de ([93.233.44.38] 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 1lFbgG-0003cy-1w; Fri, 26 Feb 2021 11:53:12 +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 1lFbgF-00071W-Gq; Fri, 26 Feb 2021 12:53:11 +0100 Date: Fri, 26 Feb 2021 12:53:11 +0100 Message-ID: <87h7lzavvc.wl-neal@walfield.org> From: "Neal H. Walfield" To: Paul Wouters Cc: openpgp@ietf.org In-Reply-To: <7d8bdda1-4e5c-6c10-f3cd-1d191fad595c@nohats.ca> References: <7d8bdda1-4e5c-6c10-f3cd-1d191fad595c@nohats.ca> 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] I-D Action: draft-ietf-openpgp-crypto-refresh-02.txt (fwd) 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: Fri, 26 Feb 2021 11:53:16 -0000 Hi, > - Incorporated RFC 6637 (ECDSA and ECDH, using NIST curves) # Security Considerations A compliant application MUST only use iterated and salted S2K to protect private keys, as defined in {{iterated-and-salted-s2k}}, "Iterated and Salted S2K". This precludes the use of private S2K algorithms (algos 100 to 110). https://tools.ietf.org/html/rfc4880#section-3.7 Would a MUST NOT use Simple S2K and MUST NOT use Salted S2K be better? :) Neal From nobody Fri Feb 26 04:01:06 2021 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 E9AAB3A1404 for ; Fri, 26 Feb 2021 04:01:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, 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 n49iLSqarnsD for ; Fri, 26 Feb 2021 04:01:03 -0800 (PST) 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 9EE9A3A13FF for ; Fri, 26 Feb 2021 04:01:03 -0800 (PST) Received: from p5de92c26.dip0.t-ipconnect.de ([93.233.44.38] 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 1lFbnp-0003hg-MF; Fri, 26 Feb 2021 12:01:01 +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 1lFbnp-0000vY-6v; Fri, 26 Feb 2021 13:01:01 +0100 Date: Fri, 26 Feb 2021 13:01:01 +0100 Message-ID: <87ft1javia.wl-neal@walfield.org> From: "Neal H. Walfield" To: Paul Wouters Cc: openpgp@ietf.org In-Reply-To: <7d8bdda1-4e5c-6c10-f3cd-1d191fad595c@nohats.ca> References: <7d8bdda1-4e5c-6c10-f3cd-1d191fad595c@nohats.ca> 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: [openpgp] textual cleanup (no substantive changes) 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: Fri, 26 Feb 2021 12:01:05 -0000 -a.2) high-order length octet of (b)-(e) (1 octet) - -a.3) low-order length octet of (b)-(e) (1 octet) +a.2) two-octet scalar octet count of (b)-(e) It is less clear that the count is big endian. Perhaps: a.2) two-octet, big endian scalar octet count of (b)-(e) From nobody Fri Feb 26 04:08:58 2021 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 2BB213A1420 for ; Fri, 26 Feb 2021 04:08:57 -0800 (PST) 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 a5WJswhaUf0I for ; Fri, 26 Feb 2021 04:08:55 -0800 (PST) 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 501103A141E for ; Fri, 26 Feb 2021 04:08:55 -0800 (PST) Received: from p5de92c26.dip0.t-ipconnect.de ([93.233.44.38] 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 1lFbvR-0003m5-RX; Fri, 26 Feb 2021 12:08:53 +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 1lFbvR-00021O-BY; Fri, 26 Feb 2021 13:08:53 +0100 Date: Fri, 26 Feb 2021 13:08:53 +0100 Message-ID: <87eeh3av56.wl-neal@walfield.org> From: "Neal H. Walfield" To: Paul Wouters Cc: openpgp@ietf.org In-Reply-To: <7d8bdda1-4e5c-6c10-f3cd-1d191fad595c@nohats.ca> References: <7d8bdda1-4e5c-6c10-f3cd-1d191fad595c@nohats.ca> 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: [openpgp] Deprecate non-integrity-protected encryption 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: Fri, 26 Feb 2021 12:08:57 -0000 On Tue, 23 Feb 2021 03:19:03 +0100, Paul Wouters wrote: > - Deprecate non-integrity-protected encryption +This packet is obsolete. +An implementation MUST NOT create this packet. +An implementation MAY process such a packet but it MUST return a clear diagnostic that a non-integrity protected packet has been processed. +The implementation SHOULD also return an error in this case and stop processing. It's not clear to me how a library should warn the user. In Sequoia, an application has to opt-in to deprecated algorithms. Is that enough? I'm also confused about the interplay between the last two sentences: in the second-to-last sentence, an implementation "MAY process such a packet" and in the last it "SHOULD *also* ... stop processing" (stars mine). Aren't these in conflict? :) Neal From nobody Fri Feb 26 04:14:32 2021 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 BBABE3A1444 for ; Fri, 26 Feb 2021 04:14:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, 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 ZdVjooNH44oJ for ; Fri, 26 Feb 2021 04:14:30 -0800 (PST) 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 3A57D3A1443 for ; Fri, 26 Feb 2021 04:14:30 -0800 (PST) Received: from p5de92c26.dip0.t-ipconnect.de ([93.233.44.38] 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 1lFc0q-0003rv-N6; Fri, 26 Feb 2021 12:14:28 +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 1lFc0q-0002eR-FS; Fri, 26 Feb 2021 13:14:28 +0100 Date: Fri, 26 Feb 2021 13:14:28 +0100 Message-ID: <87czwnauvv.wl-neal@walfield.org> From: "Neal H. Walfield" To: Paul Wouters Cc: openpgp@ietf.org In-Reply-To: <7d8bdda1-4e5c-6c10-f3cd-1d191fad595c@nohats.ca> References: <7d8bdda1-4e5c-6c10-f3cd-1d191fad595c@nohats.ca> 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] I-D Action: draft-ietf-openpgp-crypto-refresh-02.txt (fwd) 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: Fri, 26 Feb 2021 12:14:32 -0000 On Tue, 23 Feb 2021 03:19:03 +0100, Paul Wouters wrote: > The following items were merged in: > > - Produce 4-level-deep ToC > - Reserve codepoints in the registries > - reorganize signature and asymmetric key value fields > - Re-flow the v3 and v4 signature descriptions > - Incorporated RFC 6637 (ECDSA and ECDH, using NIST curves) > - textual cleanup (no substantive changes) > - Update most registries to be SPECIFICATION REQUIRED > - Deprecate v3 signatures > - Deprecate non-integrity-protected encryption > - Include SHA3 > - Incorporate Curve25519 for ECDH > - Add ECC Point compression flag bytes appendix section > - update reference RFC2434 to RFC8126 > > Please review the changes and let the WG know of any issues you see. > This includes if you think something was merged that did not have WG > consensus. I've reviewed the changes between -01 and -02 with exception of the ECC changes, which I'm not qualified to evaluate. Other than the minor points I raised, I don't have any objections. Thanks everyone. :) Neal From nobody Fri Feb 26 04:22:20 2021 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 315773A1463 for ; Fri, 26 Feb 2021 04:22:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 0U_aogWfHrmg for ; Fri, 26 Feb 2021 04:22:17 -0800 (PST) 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 4A8F63A1462 for ; Fri, 26 Feb 2021 04:22:17 -0800 (PST) Received: from p5de92c26.dip0.t-ipconnect.de ([93.233.44.38] 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 1lFc8M-0003xR-Q5; Fri, 26 Feb 2021 12:22:14 +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 1lFc8M-0004Fh-Am; Fri, 26 Feb 2021 13:22:14 +0100 Date: Fri, 26 Feb 2021 13:22:14 +0100 Message-ID: <87blc7auix.wl-neal@walfield.org> From: "Neal H. Walfield" To: Paul Wouters Cc: openpgp@ietf.org In-Reply-To: <87eeh3av56.wl-neal@walfield.org> References: <7d8bdda1-4e5c-6c10-f3cd-1d191fad595c@nohats.ca> <87eeh3av56.wl-neal@walfield.org> 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] Deprecate non-integrity-protected encryption 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: Fri, 26 Feb 2021 12:22:19 -0000 Derek raised this issue here: https://mailarchive.ietf.org/arch/msg/openpgp/6KrTJw1U-u9N8MJ5LIcCbSc-PVY I apologize for the duplicate. :) Neal On Fri, 26 Feb 2021 13:08:53 +0100, Neal H. Walfield wrote: > > On Tue, 23 Feb 2021 03:19:03 +0100, > Paul Wouters wrote: > > - Deprecate non-integrity-protected encryption > > +This packet is obsolete. > +An implementation MUST NOT create this packet. > +An implementation MAY process such a packet but it MUST return a clear diagnostic that a non-integrity protected packet has been processed. > +The implementation SHOULD also return an error in this case and stop processing. > > It's not clear to me how a library should warn the user. In Sequoia, > an application has to opt-in to deprecated algorithms. Is that > enough? > > > I'm also confused about the interplay between the last two sentences: > in the second-to-last sentence, an implementation "MAY process such a > packet" and in the last it "SHOULD *also* ... stop processing" (stars > mine). Aren't these in conflict? > > :) Neal From nobody Fri Feb 26 18:44:24 2021 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 12FD23A00E4 for ; Fri, 26 Feb 2021 18:44:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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=+Nh9AUFG; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=J6acQyO3 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 dLL9pU_gCNLF for ; Fri, 26 Feb 2021 18:44:17 -0800 (PST) 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 186E93A0121 for ; Fri, 26 Feb 2021 18:44:16 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1614393855; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=N6OksRaidhPNqT5alOxVOWXMEYIjGCFoAVTZViJ678c=; b=+Nh9AUFGg7DvOl5cbeJGamXS30Dt0KvSj9OxQf1YShFVfVUYo+OXVC4sWhACm/DrSuO84 0EpeX27BRiffiHwCw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1614393854; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=N6OksRaidhPNqT5alOxVOWXMEYIjGCFoAVTZViJ678c=; b=J6acQyO32za5ptzltb/fE2PQN+J9KLHydaa87bjz0xhxmvCbwnJSajSBc8Ea/1DOx24zi uoi2ryQrfew7nsma/If6iio2z4sXAmqm8W2Hku4xzUxhBYSeH6DwRs8Z/qG9i24w7v4V2GD O/vUOrlt8eKXOWiSehCxNj1QHEBqe3LkIIZW1sxQRf7rnHCI16CLC7QvUqmvOsqNk3Qrqnj oDbDNvq6upGdDpoBwpptTJo8bCjyHTPfvxRThFR8HHWuv9w/ragDeFUIYqfY63nnPIpIXGn VaMj54Cp41aBmbBukQIHn4TxpXoPqSixIWrSeh7PSiJK8moAjFG2BjlxPb4A== Received: from fifthhorseman.net (lair.fifthhorseman.net [108.58.6.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 70637F9A6; Fri, 26 Feb 2021 21:44:13 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 590D920458; Fri, 26 Feb 2021 20:42:28 -0500 (EST) From: Daniel Kahn Gillmor To: Derek Atkins , Paul Wouters Cc: openpgp@ietf.org In-Reply-To: <4f3d66b74b46b5b8bf27b5e1589bf80e.squirrel@mail2.ihtfp.org> References: <7d8bdda1-4e5c-6c10-f3cd-1d191fad595c@nohats.ca> <4f3d66b74b46b5b8bf27b5e1589bf80e.squirrel@mail2.ihtfp.org> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEX+i03xYJKwYBBAHaRw8BAQdACA4xvL/xI5dHedcnkfViyq84doe8zFRid9jW7CC9XBiI0QQf FgoAgwWCX+i03wWJBZ+mAAMLCQcJEOCS6zpcoQ26RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNl cXVvaWEtcGdwLm9yZ/tr8E9NA10HvcAVlSxnox6z62KXCInWjZaiBIlgX6O5AxUKCAKbAQIeARYh BMKfigwB81402BaqXOCS6zpcoQ26AADZHQD/Zx9nc3N2kj13AUsKMr/7zekBtgfSIGB3hRCU74Su G44A/34Yp6IAkndewLxb1WdRSokycnaCVyrk0nb4imeAYyoPtBc8ZGtnQGZpZnRoaG9yc2VtYW4u bmV0PojRBBMWCgCDBYJf6LTfBYkFn6YAAwsJBwkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3Rh dGlvbnMuc2VxdW9pYS1wZ3Aub3JnL0Gwxvypz2tu1IPG+yu1zPjkiZwpscsitwrVvzN3bbADFQoI ApsBAh4BFiEEwp+KDAHzXjTYFqpc4JLrOlyhDboAAPkXAP0Z29z7jW+YzLzPTQML4EQLMbkHOfU4 +s+ki81Czt0WqgD/SJ8RyrqDCtEP8+E4ZSR01ysKqh+MUAsTaJlzZjehiQ24MwRf6LTfFgkrBgEE AdpHDwEBB0DkKHOW2kmqfAK461+acQ49gc2Z6VoXMChRqobGP0ubb4kBiAQYFgoBOgWCX+i03wWJ BZ+mAAkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3Jnfvo+ nHoxDwaLaJD8XZuXiaqBNZtIGXIypF1udBBRoc0CmwICHgG+oAQZFgoAbwWCX+i03wkQPp1xc3He VlxHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnaheiqE7Pfi3Atb3GGTw+ jFcBGOaobgzEJrhEuFpXREEWIQQttUkcnfDcj0MoY88+nXFzcd5WXAAAvrsBAIJ5sBg8Udocv25N stN/zWOiYpnjjvOjVMLH4fV3pWE1AP9T6hzHz7hRnAA8d01vqoxOlQ3O6cb/kFYAjqx3oMXSBhYh BMKfigwB81402BaqXOCS6zpcoQ26AADX7gD/b83VObe14xrNP8xcltRrBZF5OE1rQSPkMNy+eWpk eCwA/1hxiS8ZxL5/elNjXiWuHXEvUGnRoVj745Vl48sZPVYMuDgEX+i03xIKKwYBBAGXVQEFAQEH QIGex1WZbH6xhUBve5mblScGYU+Y8QJOomXH+rr5tMsMAwEICYjJBBgWCgB7BYJf6LTfBYkFn6YA CRDgkus6XKENukcUAAAAAAAeACBzYWx0QG5vdGF0aW9ucy5zZXF1b2lhLXBncC5vcmcEAx9vTD3b J0SXkhvcRcCr6uIDJwic3KFKxkH1m4QW0QKbDAIeARYhBMKfigwB81402BaqXOCS6zpcoQ26AAAX mwD8CWmukxwskU82RZLMk5fm1wCgMB5z8dA50KLw3rgsCykBAKg1w/Y7XpBS3SlXEegIg1K1e6dR fRxL7Z37WZXoH8AH Date: Fri, 26 Feb 2021 20:42:27 -0500 Message-ID: <871rd2e16k.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] I-D Action: draft-ietf-openpgp-crypto-refresh-02.txt (fwd) 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, 27 Feb 2021 02:44:19 -0000 --=-=-= Content-Type: text/plain On Tue 2021-02-23 08:15:06 -0500, Derek Atkins wrote: > Implementations SHOULD generate V4 signatures. Implementations MUST > NOT create version 3 signatures; they MAY accept version 3 > signatures. As Paul and Werner both noted, this is a hiccup in the transitional nature of the document. I've flagged it as https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/15 so that we don't lose track of it. > There is no MUST create version. Is this intended to change? fwiw, (no hats on) i'm not sure that "MUST create" is the right wording ultimately. We want "MUST be able to create" or "MUST create [in some specific context]" but i can't see requiring creation of a signature type without one of those caveats. > Later (5.8): > > This packet is obsolete. An implementation MUST NOT create this > packet. An implementation MAY process such a packet but it MUST > return a clear diagnostic that a non-integrity protected packet has > been processed. The implementation SHOULD also return an error in > this case and stop processing. > > I'm confused by this text. If an implementation chooses to process this > packet type (e.g. I have 20-year-old PGP-encrypted messages that I'd still > like to be able to read without re-encrypting them), why are you saying > that it should return an error and stop processing? So it MAY process but > SHOULD stop processing? I'm confused. I've recorded this as https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/16 and mentioned Robert's suggestion of how it could be re-phrased. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQttUkcnfDcj0MoY88+nXFzcd5WXAUCYDmjhAAKCRA+nXFzcd5W XOEdAP9+ryzyRSIdm+E8lIVtYWV0xJC3sVrlMTLsY7nH8uW/mwD/ciujuR8J3MVr rlO6BWoIc/QxMdh4F4d4prkmcdfapAs= =cSEj -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Feb 27 09:47:00 2021 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 2DAFE3A1051 for ; Sat, 27 Feb 2021 09:46:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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=LR/2rfwp; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=MsgZ5Ydx 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 HSZq3lT2A8yf for ; Sat, 27 Feb 2021 09:46:57 -0800 (PST) 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 28A693A1041 for ; Sat, 27 Feb 2021 09:46:56 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1614448016; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=yWZjJ0KIttuJ6mXUMOuJPw9rTCgIOsQnZwdCY3dm3WI=; b=LR/2rfwpYJ/nFogUimBrQqrKrova6N8KB9wiqDXz0Gphm8kdIMBhe65A6/fA+0ENzlpIi /d2HW6NxDNi/ns5Bg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1614448016; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=yWZjJ0KIttuJ6mXUMOuJPw9rTCgIOsQnZwdCY3dm3WI=; b=MsgZ5YdxA0DjvpGK6Dmv4UvGG3ueDxIJi7q8EBu9Bv/uqCl8t9JrgbfCkelkWf8qmXwfe AjNQoDUgkuBBkIYGIWZwvSeXDNv/gdkHW3rpD96PnffOmFHL9dUPzAUcRGRSfa9TyvyCUly UHXw1YstPoy3DeGgoEB0lZD2Uibd/JTTH4x/cF5bMyR6NT1Wy7n2MjuhrQo63Effn8bE4ME mzcJrWYdo6KmqgnnHRXZIrTzc4l462GAtXSk8ACYNSbR43JA/XDXBNELQymkaIaUoG6xYgJ gunp69Bt31ZjApzK8HEW53ADKXIpex9kOZlvl66Kuro5cFkI6o6+S9S9UQcQ== Received: from fifthhorseman.net (lair.fifthhorseman.net [108.58.6.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 30D71F9A5 for ; Sat, 27 Feb 2021 12:46:55 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 0729C207C6; Sat, 27 Feb 2021 00:01:19 -0500 (EST) From: Daniel Kahn Gillmor To: openpgp@ietf.org In-Reply-To: <87y2fcdnc5.fsf@fifthhorseman.net> References: <87y2fcdnc5.fsf@fifthhorseman.net> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEX+i03xYJKwYBBAHaRw8BAQdACA4xvL/xI5dHedcnkfViyq84doe8zFRid9jW7CC9XBiI0QQf FgoAgwWCX+i03wWJBZ+mAAMLCQcJEOCS6zpcoQ26RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNl cXVvaWEtcGdwLm9yZ/tr8E9NA10HvcAVlSxnox6z62KXCInWjZaiBIlgX6O5AxUKCAKbAQIeARYh BMKfigwB81402BaqXOCS6zpcoQ26AADZHQD/Zx9nc3N2kj13AUsKMr/7zekBtgfSIGB3hRCU74Su G44A/34Yp6IAkndewLxb1WdRSokycnaCVyrk0nb4imeAYyoPtBc8ZGtnQGZpZnRoaG9yc2VtYW4u bmV0PojRBBMWCgCDBYJf6LTfBYkFn6YAAwsJBwkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3Rh dGlvbnMuc2VxdW9pYS1wZ3Aub3JnL0Gwxvypz2tu1IPG+yu1zPjkiZwpscsitwrVvzN3bbADFQoI ApsBAh4BFiEEwp+KDAHzXjTYFqpc4JLrOlyhDboAAPkXAP0Z29z7jW+YzLzPTQML4EQLMbkHOfU4 +s+ki81Czt0WqgD/SJ8RyrqDCtEP8+E4ZSR01ysKqh+MUAsTaJlzZjehiQ24MwRf6LTfFgkrBgEE AdpHDwEBB0DkKHOW2kmqfAK461+acQ49gc2Z6VoXMChRqobGP0ubb4kBiAQYFgoBOgWCX+i03wWJ BZ+mAAkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3Jnfvo+ nHoxDwaLaJD8XZuXiaqBNZtIGXIypF1udBBRoc0CmwICHgG+oAQZFgoAbwWCX+i03wkQPp1xc3He VlxHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnaheiqE7Pfi3Atb3GGTw+ jFcBGOaobgzEJrhEuFpXREEWIQQttUkcnfDcj0MoY88+nXFzcd5WXAAAvrsBAIJ5sBg8Udocv25N stN/zWOiYpnjjvOjVMLH4fV3pWE1AP9T6hzHz7hRnAA8d01vqoxOlQ3O6cb/kFYAjqx3oMXSBhYh BMKfigwB81402BaqXOCS6zpcoQ26AADX7gD/b83VObe14xrNP8xcltRrBZF5OE1rQSPkMNy+eWpk eCwA/1hxiS8ZxL5/elNjXiWuHXEvUGnRoVj745Vl48sZPVYMuDgEX+i03xIKKwYBBAGXVQEFAQEH QIGex1WZbH6xhUBve5mblScGYU+Y8QJOomXH+rr5tMsMAwEICYjJBBgWCgB7BYJf6LTfBYkFn6YA CRDgkus6XKENukcUAAAAAAAeACBzYWx0QG5vdGF0aW9ucy5zZXF1b2lhLXBncC5vcmcEAx9vTD3b J0SXkhvcRcCr6uIDJwic3KFKxkH1m4QW0QKbDAIeARYhBMKfigwB81402BaqXOCS6zpcoQ26AAAX mwD8CWmukxwskU82RZLMk5fm1wCgMB5z8dA50KLw3rgsCykBAKg1w/Y7XpBS3SlXEegIg1K1e6dR fRxL7Z37WZXoH8AH Date: Sat, 27 Feb 2021 00:01:18 -0500 Message-ID: <87k0qucdep.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] OpenPGP interim meeting tomorrow (2021-02-26 15:00Z) 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, 27 Feb 2021 17:46:59 -0000 --=-=-= Content-Type: text/plain On Thu 2021-02-25 13:16:58 -0500, Daniel Kahn Gillmor wrote: > The IETF OpenPGP working group has an interim meeting scheduled for > tomorrow (Friday Feb 26th) at 15:00 UTC. That's in a little less than > 21 hours from now. Please join us! Thanks everyone for coming! We had 20 people in attendance, from several different implementation teams. There was fruitful discussion, and i think we're moving forward well. Special thanks to Vincent, who took the bulk of the notes. I've cleaned and uploaded the notes here: https://datatracker.ietf.org/meeting/interim-2021-openpgp-01/materials/minutes-interim-2021-openpgp-01-202102261500-00 And i opened two issues in gitlab to track two main points that came up without resolution: S2K update: https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/13 UID-less certs: https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/14 Regards, --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQttUkcnfDcj0MoY88+nXFzcd5WXAUCYDnSHgAKCRA+nXFzcd5W XFTlAP9XCqNiM0pg6lT3YT2bRMcerR3rX5u5TOLsl9bYMYRCcwD9EfQKRSylvRMx n05bSMpCO8l8jh/u/0+YPD6SBkW4cQE= =LAJ/ -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Feb 27 09:47:04 2021 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 6D96E3A1041 for ; Sat, 27 Feb 2021 09:46:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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=qB3E3Mej; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=dzJ4YCK3 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 7eapQf5bhncC for ; Sat, 27 Feb 2021 09:46:57 -0800 (PST) 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 ABB163A1048 for ; Sat, 27 Feb 2021 09:46:57 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1614448016; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=KTCiz6hDKb1P5r7lY6v7HjShGxem+xv6+nOrilkuJJM=; b=qB3E3MejbxKwaW1JW2PSgCdkAvdJPtQkEoHJHHBMIvX5wFIF8uERmlKDGM2R81oJdILT2 RGfRUL0TsHTxc5SAg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1614448016; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=KTCiz6hDKb1P5r7lY6v7HjShGxem+xv6+nOrilkuJJM=; b=dzJ4YCK3emien4lv2ny5S7hXNvU2jM4uU8uplHYqr73LTTq5QmOnogudlZ+Vqi4AfJYtT DFoi9w3TUS3GVGepXCbbpnkAvYLlOCUMjeLW8qqlzoQ1I2hYwaWZ7Lwj2v3V09FPWo8V2fz NF2YeLOFiJMW4FnARWoiXoWYBTU5YQ/Zwvr7P8GxqskYmi62wgvidgj6P5zKcWY/K/mBR9c ArM7SQBy+e6cnavKf25VOlviajbFLlg9TwxKw4XpR7bL1xghYr2Yild7FzgoCWmbSFSU7zD /NiSeIreWguYnT0cVWnfKRp91WUqbUvfQVEutiGegb+P9fmOL1NkJMCBhQig== Received: from fifthhorseman.net (lair.fifthhorseman.net [108.58.6.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 41DB3F9A8; Sat, 27 Feb 2021 12:46:55 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 253A9204C1; Fri, 26 Feb 2021 23:41:05 -0500 (EST) From: Daniel Kahn Gillmor To: "Neal H. Walfield" , Paul Wouters Cc: openpgp@ietf.org In-Reply-To: <87im6faw06.wl-neal@walfield.org> References: <7d8bdda1-4e5c-6c10-f3cd-1d191fad595c@nohats.ca> <87im6faw06.wl-neal@walfield.org> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEX+i03xYJKwYBBAHaRw8BAQdACA4xvL/xI5dHedcnkfViyq84doe8zFRid9jW7CC9XBiI0QQf FgoAgwWCX+i03wWJBZ+mAAMLCQcJEOCS6zpcoQ26RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNl cXVvaWEtcGdwLm9yZ/tr8E9NA10HvcAVlSxnox6z62KXCInWjZaiBIlgX6O5AxUKCAKbAQIeARYh BMKfigwB81402BaqXOCS6zpcoQ26AADZHQD/Zx9nc3N2kj13AUsKMr/7zekBtgfSIGB3hRCU74Su G44A/34Yp6IAkndewLxb1WdRSokycnaCVyrk0nb4imeAYyoPtBc8ZGtnQGZpZnRoaG9yc2VtYW4u bmV0PojRBBMWCgCDBYJf6LTfBYkFn6YAAwsJBwkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3Rh dGlvbnMuc2VxdW9pYS1wZ3Aub3JnL0Gwxvypz2tu1IPG+yu1zPjkiZwpscsitwrVvzN3bbADFQoI ApsBAh4BFiEEwp+KDAHzXjTYFqpc4JLrOlyhDboAAPkXAP0Z29z7jW+YzLzPTQML4EQLMbkHOfU4 +s+ki81Czt0WqgD/SJ8RyrqDCtEP8+E4ZSR01ysKqh+MUAsTaJlzZjehiQ24MwRf6LTfFgkrBgEE AdpHDwEBB0DkKHOW2kmqfAK461+acQ49gc2Z6VoXMChRqobGP0ubb4kBiAQYFgoBOgWCX+i03wWJ BZ+mAAkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3Jnfvo+ nHoxDwaLaJD8XZuXiaqBNZtIGXIypF1udBBRoc0CmwICHgG+oAQZFgoAbwWCX+i03wkQPp1xc3He VlxHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnaheiqE7Pfi3Atb3GGTw+ jFcBGOaobgzEJrhEuFpXREEWIQQttUkcnfDcj0MoY88+nXFzcd5WXAAAvrsBAIJ5sBg8Udocv25N stN/zWOiYpnjjvOjVMLH4fV3pWE1AP9T6hzHz7hRnAA8d01vqoxOlQ3O6cb/kFYAjqx3oMXSBhYh BMKfigwB81402BaqXOCS6zpcoQ26AADX7gD/b83VObe14xrNP8xcltRrBZF5OE1rQSPkMNy+eWpk eCwA/1hxiS8ZxL5/elNjXiWuHXEvUGnRoVj745Vl48sZPVYMuDgEX+i03xIKKwYBBAGXVQEFAQEH QIGex1WZbH6xhUBve5mblScGYU+Y8QJOomXH+rr5tMsMAwEICYjJBBgWCgB7BYJf6LTfBYkFn6YA CRDgkus6XKENukcUAAAAAAAeACBzYWx0QG5vdGF0aW9ucy5zZXF1b2lhLXBncC5vcmcEAx9vTD3b J0SXkhvcRcCr6uIDJwic3KFKxkH1m4QW0QKbDAIeARYhBMKfigwB81402BaqXOCS6zpcoQ26AAAX mwD8CWmukxwskU82RZLMk5fm1wCgMB5z8dA50KLw3rgsCykBAKg1w/Y7XpBS3SlXEegIg1K1e6dR fRxL7Z37WZXoH8AH Date: Fri, 26 Feb 2021 23:41:04 -0500 Message-ID: <87pn0mcecf.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] I-D Action: draft-ietf-openpgp-crypto-refresh-02.txt (fwd) 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, 27 Feb 2021 17:46:59 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi Neal-- Thanks for the nit-picks. Two concerns: On Fri 2021-02-26 12:50:17 +0100, Neal H. Walfield wrote: > -- 20 octets representing a recipient encryption subkey or a master key f= ingerprint, identifying the key material that is needed for the decryption. > - For version 5 keys the 20 leftmost octets of the fingerprint are used. > +- [ ] 20 octets representing a recipient encryption subkey or a primary = key fingerprint identifying the key material that is needed for decryption > + (for version 5 keys the 20 leftmost octets of the fingerprint are used= ). what does the [ ] you've inserted here mean? It looks like a markdown todo-list "checkbox", maybe it was inserted by mistake? > - 09 k0 k1 ... k31 c0 c1 05 05 05 05 05 > + 09 k0 k1 ... k31 C0 C1 05 05 05 05 05 >=20=20 > -The octets c0 and c1 above denote the checksum. > +The octets C0 and C1 above denote the checksum. This seems like a mistake. C0 and C1 could be specific hexadecimal octets (decimal 12), whereas "c0" and "c1" here are intended to be placeholders for the checksum. This is a bit confusing, maybe it would be better to use s0 and s1 (s for "sum") so that it's clear that it isn't hex? At any rate, i think this was the only "capital hex" part of the diff, so we probably don't need that mention in the commit message either, right? I've included this proposal (without the two changes above that i think are mistaken) and your other remark about the big-endianness of the two-octet scalar in a merge request: https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/38 I encourage people to make merge requests directly in gitlab in addition to posting patches to the mailing list, especially for non-substantive/editorial changes like this. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQttUkcnfDcj0MoY88+nXFzcd5WXAUCYDnNYAAKCRA+nXFzcd5W XJeNAQCFGsEkwHsZFEsV2CrxN+3CgKYCBEw7pHGI6G/Nwc3pzQD+JyNdbGIKL0jy gSqZySK7aTSJzBYsW0WTNUq0h6TOVw8= =UQcF -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Feb 27 09:47:09 2021 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 72BD03A1051 for ; Sat, 27 Feb 2021 09:47:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.306 X-Spam-Level: X-Spam-Status: No, score=-1.306 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=gG5soR1n; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=PLLZJYZp 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 ZtEz4MKXL8XB for ; Sat, 27 Feb 2021 09:46:59 -0800 (PST) Received: from che.mayfirst.org (unknown [162.247.75.117]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31A3D3A105A for ; Sat, 27 Feb 2021 09:46:59 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1614448017; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=tfrYPKZIIG7Hke1Ftn6ggYcy5Tz+cXsMDDtir8z8bP0=; b=gG5soR1nnXGqlMJAGxW525M3+kIKhQpZ6d1fxRzUQwc9pYtRPsL3IxfkpAv0Uc5vCcTvC wvXG5Yz22f8K1JSBg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1614448017; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=tfrYPKZIIG7Hke1Ftn6ggYcy5Tz+cXsMDDtir8z8bP0=; b=PLLZJYZpZgqr6HAAKI2B9i75qUP1TX131M2HwzainKcVdho7cQmdSoItj2cbZ/1JokinY GE+UqfKUBa4uK8Umjk8gqzibHBq6DSzwq70xpjI96a/MVdKSlUvEJ2FrPu2wk0nWro+MnDE +97cffnPnA8Rvh5Pn+3PQXqavrk7degsJQj6nQ1cIVbNl5mBbcjpgNUPtTck2fYPpRJw/wM 0Y6mH0RsN5cW1JYXkmkB+MRM2CxqesG/otmm6RAkXDwNZ3uHLA01Pl4p5aU8b8Dd9K3t6uS 4xq6xQdigGOVYnm4qOComwtgkjIPKlqEU0DjHhy4fqmHk8Me3HVsB4+9K8pw== Received: from fifthhorseman.net (lair.fifthhorseman.net [108.58.6.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 471AAF9A9; Sat, 27 Feb 2021 12:46:55 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 9D33E20458; Fri, 26 Feb 2021 23:00:50 -0500 (EST) From: Daniel Kahn Gillmor To: =?utf-8?Q?=C3=81ngel?= , openpgp@ietf.org In-Reply-To: <239af1473534565304e2ecfeca630219417ebc0e.camel@16bits.net> References: <7d8bdda1-4e5c-6c10-f3cd-1d191fad595c@nohats.ca> <4f3d66b74b46b5b8bf27b5e1589bf80e.squirrel@mail2.ihtfp.org> <87a6rug0x5.fsf@wheatstone.g10code.de> <8473b015f635c0f88f9bceed8acda0f8.squirrel@mail2.ihtfp.org> <239af1473534565304e2ecfeca630219417ebc0e.camel@16bits.net> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEX+i03xYJKwYBBAHaRw8BAQdACA4xvL/xI5dHedcnkfViyq84doe8zFRid9jW7CC9XBiI0QQf FgoAgwWCX+i03wWJBZ+mAAMLCQcJEOCS6zpcoQ26RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNl cXVvaWEtcGdwLm9yZ/tr8E9NA10HvcAVlSxnox6z62KXCInWjZaiBIlgX6O5AxUKCAKbAQIeARYh BMKfigwB81402BaqXOCS6zpcoQ26AADZHQD/Zx9nc3N2kj13AUsKMr/7zekBtgfSIGB3hRCU74Su G44A/34Yp6IAkndewLxb1WdRSokycnaCVyrk0nb4imeAYyoPtBc8ZGtnQGZpZnRoaG9yc2VtYW4u bmV0PojRBBMWCgCDBYJf6LTfBYkFn6YAAwsJBwkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3Rh dGlvbnMuc2VxdW9pYS1wZ3Aub3JnL0Gwxvypz2tu1IPG+yu1zPjkiZwpscsitwrVvzN3bbADFQoI ApsBAh4BFiEEwp+KDAHzXjTYFqpc4JLrOlyhDboAAPkXAP0Z29z7jW+YzLzPTQML4EQLMbkHOfU4 +s+ki81Czt0WqgD/SJ8RyrqDCtEP8+E4ZSR01ysKqh+MUAsTaJlzZjehiQ24MwRf6LTfFgkrBgEE AdpHDwEBB0DkKHOW2kmqfAK461+acQ49gc2Z6VoXMChRqobGP0ubb4kBiAQYFgoBOgWCX+i03wWJ BZ+mAAkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3Jnfvo+ nHoxDwaLaJD8XZuXiaqBNZtIGXIypF1udBBRoc0CmwICHgG+oAQZFgoAbwWCX+i03wkQPp1xc3He VlxHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnaheiqE7Pfi3Atb3GGTw+ jFcBGOaobgzEJrhEuFpXREEWIQQttUkcnfDcj0MoY88+nXFzcd5WXAAAvrsBAIJ5sBg8Udocv25N stN/zWOiYpnjjvOjVMLH4fV3pWE1AP9T6hzHz7hRnAA8d01vqoxOlQ3O6cb/kFYAjqx3oMXSBhYh BMKfigwB81402BaqXOCS6zpcoQ26AADX7gD/b83VObe14xrNP8xcltRrBZF5OE1rQSPkMNy+eWpk eCwA/1hxiS8ZxL5/elNjXiWuHXEvUGnRoVj745Vl48sZPVYMuDgEX+i03xIKKwYBBAGXVQEFAQEH QIGex1WZbH6xhUBve5mblScGYU+Y8QJOomXH+rr5tMsMAwEICYjJBBgWCgB7BYJf6LTfBYkFn6YA CRDgkus6XKENukcUAAAAAAAeACBzYWx0QG5vdGF0aW9ucy5zZXF1b2lhLXBncC5vcmcEAx9vTD3b J0SXkhvcRcCr6uIDJwic3KFKxkH1m4QW0QKbDAIeARYhBMKfigwB81402BaqXOCS6zpcoQ26AAAX mwD8CWmukxwskU82RZLMk5fm1wCgMB5z8dA50KLw3rgsCykBAKg1w/Y7XpBS3SlXEegIg1K1e6dR fRxL7Z37WZXoH8AH Date: Fri, 26 Feb 2021 23:00:49 -0500 Message-ID: <87v9aecg7i.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] I-D Action: draft-ietf-openpgp-crypto-refresh-02.txt (fwd) 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, 27 Feb 2021 17:47:02 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks for this close read, =C3=81ngel. You raised so many points in one message that i'm afraid some of them might get lost. I'm trying to address all of your concerns, either with a merge request (MR) with a simple editorial patch, a call for further discussion, or a new issue in gitlab. If you want to follow up on one or the other, i recommend referring to the specific issue or merge request in the subject of the mailing list thread, if one exists. I encourage folks to do this kind of tracking/triage on the issues they raise on-list directly, it's quite a bit of work to make sure that all the points get tracked so they can be handled. On Fri 2021-02-26 02:25:49 +0100, =C3=81ngel wrote: > I would prefer to keep single quotes for values referring to single > bytes standing by themselves, as rfc4880 did. -00 changed them to > double quotes but using single quotes as in C seems better. > > This happens in > * 5.9. Literal Data Packet (Tag 11) > ('b', 't', 'u', 'l', '1') vs ("b", "t", "u", "l", "1") > > * 6.2. Forming ASCII Armor with '-' and ':' > * 7.1. Dash-Escaped Text with '-' > > but does *not* apply to the characters in 8. Regular Expressions I'm not sure how to address this request without doing some heavy lifting in the toolchain, espcially since it looks like you want the tooling to behave differently for characters in the two different places. Please take a look at the HTML rendering (https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-02.html) which sets off these literal string representations in a clearly different style. I think that's an improvement worth keeping. I'm also not sure how much single vs double quotes matters here. If you want to propose a fix we can discuss it though :) > Additionally, in 7.1 a single-quoted space (' ') was > converted to use backticks (` `), which seems like an > error when converting the document. It makes sense > in some markdown conversions, but not in the rfc results. hm, yes, this looks like a bug in kramdown-rfc2629 which i've reported here: https://github.com/cabo/kramdown-rfc2629/issues/108 I've proposed a formatting workaround: https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/34 =2DDash-escaped cleartext is the ordinary cleartext where every line starti= ng with a dash `-` (0x2D) is prefixed by the sequence dash `-` (0x2D) and s= pace ` ` (0x20). +Dash-escaped cleartext is the ordinary cleartext where every line starting= with a - is prefixed by the sequence - and . This results in the following change in the .txt version: [=E2=80=A6] Dash-escaped cleartext is the ordinary cleartext where every line =2D starting with a dash "-" (0x2D) is prefixed by the sequence dash "-" =2D (0x2D) and space ` ` (0x20).=20=20 + starting with a "-" (HYPHEN-MINUS, U+002D) is prefixed by the + sequence "-" (HYPHEN-MINUS, U+002D) and " " (SPACE, U+0020). [=E2=80=A6] Hopefully that is no less clear than before, and the rendering is more normalized without the backticks. > In appendix A, an extra space was inserted between "Philip R."=20 > and "Zimmermann" (Appendix C in -02) I initially thought this was an artifact of the ./reflow script. I've added a special case to avoid it while still being able to use ./reflow, and suggested the fix here: https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/35 However, it looks like this is actually a bug in xml2rfc, which wants to put two spaces between a period and the next sentence. I've reported this here: https://mailarchive.ietf.org/arch/msg/xml2rfc/6V7C7l-zxg97jRqvuaq8r1QBQq= w/ > crypto-refresh-01/02 nitpicks > =3D=3D=3D=3D=3D > At 1. Introduction, change "RFC 5581 (Camellia cipher)" to "RFC 5581 > (The Camellia Cipher in OpenPGP)" or "RFC 5581 (Camellia Cipher in > OpenPGP)", since just "Camellia cipher" could be confused with the > description itself of Camellia (rfc3713). > "ECC for OpenPGP" should perhaps be changed to "ECC in OpenPGP" which is = the > preposition used in that rfc title. > Full name of RFC 6637 is "Elliptic Curve Cryptography (ECC) in OpenPGP" a= nd > would be the proper one if we wanted to use the complete names of the rfc, > albeit I don't think that would matter either way. These aren't the full RFC names (4880 itself is not "OpenPGP"), they're shorthand labels, but i agree that they should be normalized to be more readable. I submitted the editorial suggestion https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/36 to make them "Camellia in OpenPGP" and "Elliptic Curves in OpenPGP". > I would prefer to see the new section "ECC Curve OID" as 9.5 instead of 9= .2 > The other blocks are clear registries used directly. "ECC Curve OID" > are a different case since they are actually parameter inside Public key = with > certain ids. It's probably as 9.2 because a former draft likely referred = to it > from 9.1, but that doesn't seem to be the case, and is only referred from= other > completely separate sections. There is a sense that an ECC Curve OID is a subtype of public-key algorithms, so putting it closer to public-key algorithms is appealing. But i think this argues not for leaving it as 9.2, but rather as a subsection of the "Public-key Algorithms" section of the top-level "Constants" header (i.e. 9.1.1). fwiw, while we're nit-picking, this section ought to be named "ECC Curve OIDs" (in the plural) Seems like there are three choices: a) leave "ECC Curve OIDs" as =C2=A79.2 b) make "ECC Curve OIDs" a subsection of "=C2=A79.1 Public-key Algorithms", i.e., =C2=A79.1.1 c) move "ECC Curve OIDs" to the end of the "=C2=A79 Constants", i.e., =C2= =A79.5 What do other folks think? > I'm not too keen on the way this section is introduced. I may provide a M= R if > I can come up with something. Please do propose an MR. > 10.2.2.2. Signature Notation Data Subpacket Notation Flags creates a new= registry > but it doesn't point to a section with initial values.=20 > It should probably link to table 7 of section 5.2.3.16, although that wou= ld need > additional columns. Good catch! I'm not even sure what the "Security Recommended" or "Interoperability Recommended" columns would mean, or what data they could contain (booleans? textual recommendations?), let alone how we should populate them for the initial row. I've opened a ticket to track this as: https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/17 > Procedural question: is it the right thing for a RFC to state that it "cr= eates a > new registry" for those registries which were actually created by an olde= r RFC > it is obsoleting? If you're talking about the Notation Flags registry, it doesn't currently exist at IANA: https://www.iana.org/assignments/pgp-parameters/pgp-parameters.xhtml So yes, while the initial values that populate it came from the older, obsoleted RFC, this RFC *is* the one that is creating the registry. > I feel the text added at 15. Security Considerations still needs some re= vision.=20 > Maybe split part of it to a different section. There are too many things = there, > and it seems hard to grasp everything it mixes. > > As a concrete suggestion, I would recommend adding Compatibility > Profiles as section 15 instead of 16. Security Considerations (SC) > refers to Compatibility Profiles (CP) and Compatibility > Profiles refers to Security Considerations, but it seems it would be > easier to read Compatibility Profiles first (assuming a linear reading > of the rfc). Reference to (SC) is easier to skip (there will be some > algorithm choices at that section), whereas the reference > to CP is murkier:=20 >> Requirement levels indicated elsewhere in this document lead to=09 >> the following combinations of algorithms in the OpenPGP profile: >> MUST implement P-256 / SHA2-256 / AES-128 / SHOULD implement ... > > when the reader hasn't been told about OpenPGP profiles and, in fact, > some of those algorithms it shows as a MUST are optional at 9.1 / 9.3 Urgh, right, no matter what "elsewhere in this document" isn't helpful. If there are particular sections, we should be referencing them directly. And the interactions between the profiles and whatever MTI directives we land on seem unclear. I've opened https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/19 to try to keep track of this. > An introduction should be added after "16. Compatibility Profiles" > and before "16.1" explaining what are Compatibility Profiles and why > would they be interesting / needed. Agreed, this is confusing in its new context. I've opened https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/18 to make sure we resolve that. > You may want to put the temporary Document Workflow appendix as C, > so that the other two won't need renumbering on publication. Good call, this is now: https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/37 --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQttUkcnfDcj0MoY88+nXFzcd5WXAUCYDnD8gAKCRA+nXFzcd5W XNfaAQDGx5nyX72AnIsjwGuRmvoSq2IRbV0fKL20d2whwzAwZwEAlyGLSor/nsxI fEs/GyTXusZVTfc4EfWF/G9+Dy5zCw8= =CkB0 -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Feb 27 09:47:13 2021 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 544A13A10A7 for ; Sat, 27 Feb 2021 09:47:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.295 X-Spam-Level: X-Spam-Status: No, score=-1.295 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=4SjaySIk; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=KQnJebs2 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 ay2WIOb6rBpR for ; Sat, 27 Feb 2021 09:46:58 -0800 (PST) Received: from che.mayfirst.org (unknown [162.247.75.117]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED9CF3A104E for ; Sat, 27 Feb 2021 09:46:57 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1614448016; h=from : to : subject : date : message-id : mime-version : content-type : from; bh=mQ3kh1tfsXeCG2zTaC8BSHCAcNXhzTKmyorRsOVaUXE=; b=4SjaySIktAHRyKBerVz1pl7XG/JorwHP4qZaU9wkJ2L53DMTKfi1g13A9xSt9tGN7qc/B 6tN/hH3w5e+7p2tAg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1614448016; h=from : to : subject : date : message-id : mime-version : content-type : from; bh=mQ3kh1tfsXeCG2zTaC8BSHCAcNXhzTKmyorRsOVaUXE=; b=KQnJebs2f8L/EmWj/yhcPhyIAcaWiTQTMIh8Y15pA/Qs/aa5bZMZuoeI94yd4/XKyhyj6 iqWFDvfOGDhtgrgkjiR1oYKA5zahLFN+A/JUfmFLNU7N7hzW9Jb6h3JphvGQb36OmoPdFzs o7q7xW6IBf131QLoTQkQfAcRdYvdJDR1TnKUowXfbQxTWbl0jEMYzpk9KYTepvsiDvc9mRu M14X9IAnS7v1sUatqpe8N0vOLv4gWsxoyov3FS/R3Tr+3GCI1BJ7ESqWLGyKXvD8KYZYqsR SZUJZwQg6LBR//PisZ3I4FJRNk48gUx1zxSRzS4jg99PwOi0q/8yEi8epaJQ== Received: from fifthhorseman.net (lair.fifthhorseman.net [108.58.6.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 3C614F9A7 for ; Sat, 27 Feb 2021 12:46:55 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 7BB4C20BA1; Sat, 27 Feb 2021 00:17:28 -0500 (EST) From: Daniel Kahn Gillmor To: openpgp@ietf.org Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEX+i03xYJKwYBBAHaRw8BAQdACA4xvL/xI5dHedcnkfViyq84doe8zFRid9jW7CC9XBiI0QQf FgoAgwWCX+i03wWJBZ+mAAMLCQcJEOCS6zpcoQ26RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNl cXVvaWEtcGdwLm9yZ/tr8E9NA10HvcAVlSxnox6z62KXCInWjZaiBIlgX6O5AxUKCAKbAQIeARYh BMKfigwB81402BaqXOCS6zpcoQ26AADZHQD/Zx9nc3N2kj13AUsKMr/7zekBtgfSIGB3hRCU74Su G44A/34Yp6IAkndewLxb1WdRSokycnaCVyrk0nb4imeAYyoPtBc8ZGtnQGZpZnRoaG9yc2VtYW4u bmV0PojRBBMWCgCDBYJf6LTfBYkFn6YAAwsJBwkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3Rh dGlvbnMuc2VxdW9pYS1wZ3Aub3JnL0Gwxvypz2tu1IPG+yu1zPjkiZwpscsitwrVvzN3bbADFQoI ApsBAh4BFiEEwp+KDAHzXjTYFqpc4JLrOlyhDboAAPkXAP0Z29z7jW+YzLzPTQML4EQLMbkHOfU4 +s+ki81Czt0WqgD/SJ8RyrqDCtEP8+E4ZSR01ysKqh+MUAsTaJlzZjehiQ24MwRf6LTfFgkrBgEE AdpHDwEBB0DkKHOW2kmqfAK461+acQ49gc2Z6VoXMChRqobGP0ubb4kBiAQYFgoBOgWCX+i03wWJ BZ+mAAkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3Jnfvo+ nHoxDwaLaJD8XZuXiaqBNZtIGXIypF1udBBRoc0CmwICHgG+oAQZFgoAbwWCX+i03wkQPp1xc3He VlxHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnaheiqE7Pfi3Atb3GGTw+ jFcBGOaobgzEJrhEuFpXREEWIQQttUkcnfDcj0MoY88+nXFzcd5WXAAAvrsBAIJ5sBg8Udocv25N stN/zWOiYpnjjvOjVMLH4fV3pWE1AP9T6hzHz7hRnAA8d01vqoxOlQ3O6cb/kFYAjqx3oMXSBhYh BMKfigwB81402BaqXOCS6zpcoQ26AADX7gD/b83VObe14xrNP8xcltRrBZF5OE1rQSPkMNy+eWpk eCwA/1hxiS8ZxL5/elNjXiWuHXEvUGnRoVj745Vl48sZPVYMuDgEX+i03xIKKwYBBAGXVQEFAQEH QIGex1WZbH6xhUBve5mblScGYU+Y8QJOomXH+rr5tMsMAwEICYjJBBgWCgB7BYJf6LTfBYkFn6YA CRDgkus6XKENukcUAAAAAAAeACBzYWx0QG5vdGF0aW9ucy5zZXF1b2lhLXBncC5vcmcEAx9vTD3b J0SXkhvcRcCr6uIDJwic3KFKxkH1m4QW0QKbDAIeARYhBMKfigwB81402BaqXOCS6zpcoQ26AAAX mwD8CWmukxwskU82RZLMk5fm1wCgMB5z8dA50KLw3rgsCykBAKg1w/Y7XpBS3SlXEegIg1K1e6dR fRxL7Z37WZXoH8AH Date: Sat, 27 Feb 2021 00:17:27 -0500 Message-ID: <87h7lyccns.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: [openpgp] ECC point encoding and "flag byte" 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, 27 Feb 2021 17:47:05 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi folks-- (no hats on, this message is as an implementer, a tester, and a WG participant) The ECC point encoding rules introduced in crypto-refresh-02 (taken from RFC 6637) seem fragile and easy to get wrong, especially as expanded from the introduction of Curve25519's representation. I think it would be worthwhile to try to write down the rules for point encoding clearly and deliberately, and to treat the ECC point compression "flag byte" as its own registry, rather than throwing it in as an aside in the appendix. By asking IANA to register a table of these "flag bytes", we'll probably help clarify our own thinking about what belongs in that table (e.g. are there specific things that need to be known about each flag, how can it be used), and maybe some of the other tables as well (e.g. in the ECC Curve OIDs table, maybe we want to refer to the preferred representation for each curve?) The initial values of the "flag byte" registry should probably just include 0x04 and 0x40 (the only two directly contemplated by the draft), and leave speculative uses like 0x41 and 0x42 for later definitions. The draft suggests that applications should only use special encodings ("conversion formats") if they are not "in doubt that any recipient can support it", but offers no mechanism for signalling or detecting that support, which itself is a bit problematic. I've noted this as https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/21 and i'm willing to try to draft some text to try to address it, but haven't done so yet. Please let me know if you think this seems off-base. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQttUkcnfDcj0MoY88+nXFzcd5WXAUCYDnV6AAKCRA+nXFzcd5W XClvAP0VAkxzxkk3+hAmLTmgFeaJXl2B5WtOI8UL9qLirfgWOwEA+conZuvnBVLw wbL8IHv09UvNBFCL6KWTUemkzNNJ7go= =+eiw -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Feb 27 09:52:31 2021 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 7393E3A1093 for ; Sat, 27 Feb 2021 09:52:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.306 X-Spam-Level: X-Spam-Status: No, score=-1.306 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=H+/vS4Lf; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=fbWAjn9/ 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 G5duMYOOiL4M for ; Sat, 27 Feb 2021 09:52:28 -0800 (PST) Received: from che.mayfirst.org (unknown [162.247.75.117]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1D8B3A1086 for ; Sat, 27 Feb 2021 09:52:27 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1614448017; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=FUXGkIlQHXXbXG6Kf4RWrD03wfWgJCuapKF6UYWs0gk=; b=H+/vS4LfFU19pjPkBFxutULxMqSm7PirCrpEja8OG5F6McPjK4lHCUnEaaDaL53s9tlxc Gobejo66Z7OtQClBw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1614448017; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=FUXGkIlQHXXbXG6Kf4RWrD03wfWgJCuapKF6UYWs0gk=; b=fbWAjn9/HML6c2LVO19UlvS1Ek5ZmoADV3nMHMwR1G01PwgHgiy/88ekeGcRMZbRo/pii 7/0dn8cTNnw7yeS2h1s/TE0AZQ1OvJ1NMufMFXU+1NrvTdHFGC0X9ivFByaGF1qRPmiWS8g n+PZcI95eRxGlWBFdK5wsWcFz6R8UJWSN87vWB5DZ4xfz1Hx33nc9MilXN9EOM38sUrVuKR j8sGtT2itk+OhBofxvEDkAy5pb2yqZVxLtotqUqXv5VZvrp1A/mJsT9EX2w6Cdruyak+jyg P+OBh62xPJ8Varm6U7YW9cGIDe1rD4JkA4bgn8UTIWLDQHpamstzZxRPv6VA== Received: from fifthhorseman.net (lair.fifthhorseman.net [108.58.6.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 36D09F9A6; Sat, 27 Feb 2021 12:46:55 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 054AB2065F; Fri, 26 Feb 2021 23:52:24 -0500 (EST) From: Daniel Kahn Gillmor To: "Neal H. Walfield" , Paul Wouters Cc: openpgp@ietf.org In-Reply-To: <87h7lzavvc.wl-neal@walfield.org> References: <7d8bdda1-4e5c-6c10-f3cd-1d191fad595c@nohats.ca> <87h7lzavvc.wl-neal@walfield.org> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEX+i03xYJKwYBBAHaRw8BAQdACA4xvL/xI5dHedcnkfViyq84doe8zFRid9jW7CC9XBiI0QQf FgoAgwWCX+i03wWJBZ+mAAMLCQcJEOCS6zpcoQ26RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNl cXVvaWEtcGdwLm9yZ/tr8E9NA10HvcAVlSxnox6z62KXCInWjZaiBIlgX6O5AxUKCAKbAQIeARYh BMKfigwB81402BaqXOCS6zpcoQ26AADZHQD/Zx9nc3N2kj13AUsKMr/7zekBtgfSIGB3hRCU74Su G44A/34Yp6IAkndewLxb1WdRSokycnaCVyrk0nb4imeAYyoPtBc8ZGtnQGZpZnRoaG9yc2VtYW4u bmV0PojRBBMWCgCDBYJf6LTfBYkFn6YAAwsJBwkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3Rh dGlvbnMuc2VxdW9pYS1wZ3Aub3JnL0Gwxvypz2tu1IPG+yu1zPjkiZwpscsitwrVvzN3bbADFQoI ApsBAh4BFiEEwp+KDAHzXjTYFqpc4JLrOlyhDboAAPkXAP0Z29z7jW+YzLzPTQML4EQLMbkHOfU4 +s+ki81Czt0WqgD/SJ8RyrqDCtEP8+E4ZSR01ysKqh+MUAsTaJlzZjehiQ24MwRf6LTfFgkrBgEE AdpHDwEBB0DkKHOW2kmqfAK461+acQ49gc2Z6VoXMChRqobGP0ubb4kBiAQYFgoBOgWCX+i03wWJ BZ+mAAkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3Jnfvo+ nHoxDwaLaJD8XZuXiaqBNZtIGXIypF1udBBRoc0CmwICHgG+oAQZFgoAbwWCX+i03wkQPp1xc3He VlxHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnaheiqE7Pfi3Atb3GGTw+ jFcBGOaobgzEJrhEuFpXREEWIQQttUkcnfDcj0MoY88+nXFzcd5WXAAAvrsBAIJ5sBg8Udocv25N stN/zWOiYpnjjvOjVMLH4fV3pWE1AP9T6hzHz7hRnAA8d01vqoxOlQ3O6cb/kFYAjqx3oMXSBhYh BMKfigwB81402BaqXOCS6zpcoQ26AADX7gD/b83VObe14xrNP8xcltRrBZF5OE1rQSPkMNy+eWpk eCwA/1hxiS8ZxL5/elNjXiWuHXEvUGnRoVj745Vl48sZPVYMuDgEX+i03xIKKwYBBAGXVQEFAQEH QIGex1WZbH6xhUBve5mblScGYU+Y8QJOomXH+rr5tMsMAwEICYjJBBgWCgB7BYJf6LTfBYkFn6YA CRDgkus6XKENukcUAAAAAAAeACBzYWx0QG5vdGF0aW9ucy5zZXF1b2lhLXBncC5vcmcEAx9vTD3b J0SXkhvcRcCr6uIDJwic3KFKxkH1m4QW0QKbDAIeARYhBMKfigwB81402BaqXOCS6zpcoQ26AAAX mwD8CWmukxwskU82RZLMk5fm1wCgMB5z8dA50KLw3rgsCykBAKg1w/Y7XpBS3SlXEegIg1K1e6dR fRxL7Z37WZXoH8AH Date: Fri, 26 Feb 2021 23:52:23 -0500 Message-ID: <87mtvqcdtk.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: [openpgp] Sec. Considerations MUST about S2K [was: Re: I-D Action: draft-ietf-openpgp-crypto-refresh-02.txt] 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, 27 Feb 2021 17:52:29 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Fri 2021-02-26 12:53:11 +0100, Neal H. Walfield wrote: > Hi, > >> - Incorporated RFC 6637 (ECDSA and ECDH, using NIST curves) > > # Security Considerations > > A compliant application MUST only use iterated and salted S2K to > protect private keys, as defined in {{iterated-and-salted-s2k}}, > "Iterated and Salted S2K". > > This precludes the use of private S2K algorithms (algos 100 to 110). > > https://tools.ietf.org/html/rfc4880#section-3.7 > > Would a MUST NOT use Simple S2K and MUST NOT use Salted S2K be better? I'm not sure about this at all. For example, consider a system that knows that the string is high-entropy ("good key equivalent") -- should they be prohibited from using Simple or Salted S2K? Is this MUST really an interoperability concern as =C2=A76 of RFC 2119 suggests? Furthermore, if this guidance is applicable to private key storage and S2K, shouldn't it show up in those sections as well, not just in the Security Considerations section? I've opened a ticket to track this: https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/20 I welcome proposals for how to fix it. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQttUkcnfDcj0MoY88+nXFzcd5WXAUCYDnQBwAKCRA+nXFzcd5W XIwTAP42Q9S7jJj0ZapNZ5ZA6yShYBhmy57x/6vS45EFxVfh1gD+LrLN0rY8Iine 1Nd9ba8j7joHis0fLLc3pHl1pfyyXA4= =Z8cM -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Feb 27 11:47:49 2021 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 5B8FA3A131C for ; Sat, 27 Feb 2021 11:47:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 SZe5E_yd4lvk for ; Sat, 27 Feb 2021 11:47:45 -0800 (PST) Received: from mail-lj1-f180.google.com (mail-lj1-f180.google.com [209.85.208.180]) (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 24B803A131B for ; Sat, 27 Feb 2021 11:47:44 -0800 (PST) Received: by mail-lj1-f180.google.com with SMTP id u4so14635435ljh.6 for ; Sat, 27 Feb 2021 11:47:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9KmWNQvzbHRgHbBdbKmsRwDjb0wa2Y8Nm3FwiGuY8jA=; b=PlPaBQZh+y5BEW49cxWZEPVBRg1kc5RJTYQxpY+aL1TuZRpBMA4PrxppTzxu8YYUaz EkGn6OnSwoUKdQsBGptVFzHcUGGDva7pCYLu7Cefh89FTFeImaZesOYhBNYzOopFjXWk GoFUBZopAuftyisaHw62mnI4GVDYdC9DmaWBg5cr+v0NAaWztjAS4xQSHQeyN+MFCgUp wCUrhi2FhDFEfpHiN52/b8JoDPSvySRi64SWt6do4eGlNJ3Sb+aOOFN4Xu5jZoXNqM1p xvshsl+w0yURYWXZCYdPewxbddtVFW63ZYI/JBW5ybigtXRwPpZ7S6BmXHtyDtQJDdZv gjjg== X-Gm-Message-State: AOAM532kXSbytzeiyznqdCfu9xskpFGLk1ICa7daXTdbKhv+Fh0F432C itzkJ/oh5/+u3AFPM0fxwvwzP5Kkkkfhd9Gc7ZI10g== X-Google-Smtp-Source: ABdhPJxUKb4BBIzDi1OPCyolrqHZME/wT6Q9c6NkVxygXVDxiZxWXZwQgkWFWvgy5bw4pui3lDkaEY2acXt29jiGslk= X-Received: by 2002:a2e:9148:: with SMTP id q8mr1554961ljg.356.1614455262379; Sat, 27 Feb 2021 11:47:42 -0800 (PST) MIME-Version: 1.0 References: <87h7lyccns.fsf@fifthhorseman.net> In-Reply-To: <87h7lyccns.fsf@fifthhorseman.net> From: Andrey Jivsov Date: Sat, 27 Feb 2021 11:47:30 -0800 Message-ID: To: Daniel Kahn Gillmor Cc: openpgp@ietf.org Content-Type: multipart/alternative; boundary="0000000000006b971105bc56a81a" Archived-At: Subject: Re: [openpgp] ECC point encoding and "flag byte" 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, 27 Feb 2021 19:47:48 -0000 --0000000000006b971105bc56a81a Content-Type: text/plain; charset="UTF-8" I think OpenPGP should adopt https://tools.ietf.org/html/draft-jivsov-ecc-compact-05. I wish I thought about this earlier. This entirely avoid the issue of flag byte, because there is none, makes all point encodings uniform, and the encoding then is an MPI. I don't know if this is in the charter... On Sat, Feb 27, 2021, 9:48 AM Daniel Kahn Gillmor wrote: > Hi folks-- > > (no hats on, this message is as an implementer, a tester, and a WG > participant) > > The ECC point encoding rules introduced in crypto-refresh-02 (taken from > RFC 6637) seem fragile and easy to get wrong, especially as expanded > from the introduction of Curve25519's representation. > > I think it would be worthwhile to try to write down the rules for point > encoding clearly and deliberately, and to treat the ECC point > compression "flag byte" as its own registry, rather than throwing it in > as an aside in the appendix. By asking IANA to register a table of > these "flag bytes", we'll probably help clarify our own thinking about > what belongs in that table (e.g. are there specific things that need to > be known about each flag, how can it be used), and maybe some of the > other tables as well (e.g. in the ECC Curve OIDs table, maybe we want to > refer to the preferred representation for each curve?) > > The initial values of the "flag byte" registry should probably just > include 0x04 and 0x40 (the only two directly contemplated by the draft), > and leave speculative uses like 0x41 and 0x42 for later definitions. > > The draft suggests that applications should only use special encodings > ("conversion formats") if they are not "in doubt that any recipient can > support it", but offers no mechanism for signalling or detecting that > support, which itself is a bit problematic. > > I've noted this as https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/21 > and i'm willing to try to draft some text to try to address it, but > haven't done so yet. > > Please let me know if you think this seems off-base. > > --dkg > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > --0000000000006b971105bc56a81a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think OpenPGP should adopt=C2=A0https://tools.ietf.org/html/dr= aft-jivsov-ecc-compact-05. I wish I thought about this earlier.=C2=A0
This entirely avoid the issue o= f flag byte, because there is none, makes all point encodings uniform, and = the encoding then is an MPI.=C2=A0

I don't know if this is in the charter...

On Sat, Feb 2= 7, 2021, 9:48 AM Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
Hi folks--

(no hats on, this message is as an implementer, a tester, and a WG
participant)

The ECC point encoding rules introduced in crypto-refresh-02 (taken from RFC 6637) seem fragile and easy to get wrong, especially as expanded
from the introduction of Curve25519's representation.

I think it would be worthwhile to try to write down the rules for point
encoding clearly and deliberately, and to treat the ECC point
compression "flag byte" as its own registry, rather than throwing= it in
as an aside in the appendix.=C2=A0 By asking IANA to register a table of these "flag bytes", we'll probably help clarify our own think= ing about
what belongs in that table (e.g. are there specific things that need to
be known about each flag, how can it be used), and maybe some of the
other tables as well (e.g. in the ECC Curve OIDs table, maybe we want to refer to the preferred representation for each curve?)

The initial values of the "flag byte" registry should probably ju= st
include 0x04 and 0x40 (the only two directly contemplated by the draft), and leave speculative uses like 0x41 and 0x42 for later definitions.

The draft suggests that applications should only use special encodings
("conversion formats") if they are not "in doubt that any re= cipient can
support it", but offers no mechanism for signalling or detecting that<= br> support, which itself is a bit problematic.

I've noted this as https://gitlab= .com/openpgp-wg/rfc4880bis/-/issues/21
and i'm willing to try to draft some text to try to address it, but
haven't done so yet.

Please let me know if you think this seems off-base.

=C2=A0 =C2=A0 =C2=A0 =C2=A0--dkg
_______________________________________________
openpgp mailing list
op= enpgp@ietf.org
https://www.ietf.org/mailman/listinfo/openpg= p
--0000000000006b971105bc56a81a-- From nobody Sat Feb 27 15:14:39 2021 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 47B2C3A15C7 for ; Sat, 27 Feb 2021 15:14:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, 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 (3072-bit key) header.d=crustytoothpaste.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 FkX0yIwuUy5P for ; Sat, 27 Feb 2021 15:14:35 -0800 (PST) Received: from injection.crustytoothpaste.net (injection.crustytoothpaste.net [192.241.140.119]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B39893A15C5 for ; Sat, 27 Feb 2021 15:14:35 -0800 (PST) Received: from camp.crustytoothpaste.net (unknown [IPv6:2001:470:b978:101:7d4e:cde:7c41:71c2]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by injection.crustytoothpaste.net (Postfix) with ESMTPSA id 4796460DF4 for ; Sat, 27 Feb 2021 23:14:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crustytoothpaste.net; s=default; t=1614467671; bh=MbYG2A+u8auSs50psHPRuDsTj+KlebUYh1bl1RmxQvU=; h=Date:From:To:Subject:References:Content-Type:Content-Disposition: In-Reply-To:From:Reply-To:Subject:Date:To:CC:Resent-Date: Resent-From:Resent-To:Resent-Cc:In-Reply-To:References: Content-Type:Content-Disposition; b=Sd1AimcBEi+eb3iyQutiwzZNX3VzdLI/tzZ11hZENYh5fMrnYRD7nhPOmDCIr/Uw2 IJADRBKnh3x8XNha3p99veTPqc8kstdA4IEzqVfLs76jSQmqKNXRR7noIodeel3/fD L7KlmdJhR3AyHlSvFRiACT/PHZ/g0jtkAKODR5E30m70g5aPjDvZvA85aIldALIgl0 XMyhVLBWiO76cGF/KfkFBT6WfEiFSc6cLCp/5zcGQ74f0TN55PkpMYsFhPcmKk6jOY wqam+hwBPbiR9gyK9TDrWEOwF2YFCDPd6X/MALMArhnTRy8OUK8wzDuROhOcnpH4t4 2sJ5J8UPIr8BALq79SCc2PKLjc/BK3YkJ5G9BD8pGN/if+BiRtLtwkJapBQi5I28aA xGGjBpTMDOkQ6ZPfDNlgdlH1PduvOAlkfA/2PTxnCwZ80hqEPCNCexP4RPwY48H9qQ 4VCPkP+8V++/tIJ2c8y9j9IE/AAkAl6i2lA3BjmNNB/MgEsO1f9 Date: Sat, 27 Feb 2021 23:14:25 +0000 From: "brian m. carlson" To: openpgp@ietf.org Message-ID: References: <7d8bdda1-4e5c-6c10-f3cd-1d191fad595c@nohats.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="A7Tze74Dsf4tJn9S" Content-Disposition: inline In-Reply-To: <7d8bdda1-4e5c-6c10-f3cd-1d191fad595c@nohats.ca> User-Agent: Mutt/2.0.5 (2021-01-21) Archived-At: Subject: [openpgp] v5 fingerprints in ECDH 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, 27 Feb 2021 23:14:37 -0000 --A7Tze74Dsf4tJn9S Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2021-02-23 at 02:19:03, Paul Wouters wrote: >=20 > Hi, >=20 > I pushed an updated version of the crypto refresh document: >=20 > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-openpgp-crypto-refresh-02 >=20 > I've also pushed the git changes to https://gitlab.com/openpgp-wg/rfc4880= bis >=20 >=20 > The commit on white space changes was reverted, as the WG will be > re-opening that discussion later once we have all the consensus > items from the previous 4880bis discussion re-published in this > document. >=20 > The following items were merged in: >=20 > - Produce 4-level-deep ToC > - Reserve codepoints in the registries > - reorganize signature and asymmetric key value fields > - Re-flow the v3 and v4 signature descriptions > - Incorporated RFC 6637 (ECDSA and ECDH, using NIST curves) I noticed for v5 fingerprints we hash only the left 20 octets in the ECDH KDF: 20 octets representing a recipient encryption subkey or a master key fingerprint, identifying the key material that is needed for the decryption. For version 5 keys the 20 leftmost octets of the fingerprint are used. Absent a compelling reason, I'd prefer to see the entire fingerprint used. It doesn't make sense to define a fingerprint that's 32 octets and then truncate it to 20 octets in some cases. At that point, we're relying on the collision resistance of a different algorithm, not SHA-256, and decreasing the security level to below 128 bits. Note that if we do this, we'll need to update the text above and below to reflect that the sizes are not invariant. --=20 brian m. carlson (he/him or they/them) Houston, Texas, US --A7Tze74Dsf4tJn9S Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.2.27 (GNU/Linux) iHUEABYKAB0WIQQILOaKnbxl+4PRw5F8DEliiIeigQUCYDrSTwAKCRB8DEliiIei gdTtAP98DVnHds7+b/IiLhJeF4SXfN3bUqyMKxi6Mcnc5oDcxgEAixeCnVym45jb csVP1yV09E19yHE9UKaXAlU2Su7mgwc= =VkXL -----END PGP SIGNATURE----- --A7Tze74Dsf4tJn9S-- From nobody Sat Feb 27 15:38:49 2021 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 D503E3A161D for ; Sat, 27 Feb 2021 15:38:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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=pass (3072-bit key) header.d=crustytoothpaste.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 9gE6O9ih4qOC for ; Sat, 27 Feb 2021 15:38:46 -0800 (PST) Received: from injection.crustytoothpaste.net (injection.crustytoothpaste.net [192.241.140.119]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32DA43A161C for ; Sat, 27 Feb 2021 15:38:45 -0800 (PST) Received: from camp.crustytoothpaste.net (unknown [IPv6:2001:470:b978:101:7d4e:cde:7c41:71c2]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by injection.crustytoothpaste.net (Postfix) with ESMTPSA id 2BD2960DF4 for ; Sat, 27 Feb 2021 23:38:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crustytoothpaste.net; s=default; t=1614469093; bh=tlu6xIQHRx0j6Qq6fPGEcWOcRb0+pyCg85Q/rQDIQv4=; h=Date:From:To:Subject:References:Content-Type:Content-Disposition: In-Reply-To:From:Reply-To:Subject:Date:To:CC:Resent-Date: Resent-From:Resent-To:Resent-Cc:In-Reply-To:References: Content-Type:Content-Disposition; b=a/Ron1wa4F3a383nwHzwGOlsbHnQe20ts/ze0WhWe8bMcE8ptoVJqWxKUtGV44PlG jMgULAgjcx2C210Hj7gSp8FcjYgEtldNsjbonGK+1pkzTWosc3jNH8GkCiiaUHy8Xt tyEWE8GcDePI9KqofskMXjZrZ+GLhwRcUrxBYcGXBmhnirBrhCx937s+yEAHEodTFF TAWjqMNOSYKhYV0Tma0TRp7/GIYgo5q9IttpY3I7144BGX6+xa8M3wDpmmU7m0j1Io 44/S0xYjhLeBiTp87X79oiT4DZP1JFKRNaGLJ/cObYvsDWWbsN+XCXkZu7N2JCXYeg h8JBUrE8Kpda3r3zrHJlValQ2sswA1H3MFSb6paW8QVGTgRCYeDDfYZC/upiS/uKXL q8rFjEyEZ1YrWUllhZIYzmu4K3ytMRCtZ9gzu+IsnaEeqfncKakyMmV8m8UiHn4jvL YiO/FtESfVaPfqMNIs1BoPU2FlQcgdANdLqZw2XqOmmiVC8RcvV Date: Sat, 27 Feb 2021 23:38:08 +0000 From: "brian m. carlson" To: openpgp@ietf.org Message-ID: References: <7d8bdda1-4e5c-6c10-f3cd-1d191fad595c@nohats.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="+WdxAB6L+rfxqE7p" Content-Disposition: inline In-Reply-To: <7d8bdda1-4e5c-6c10-f3cd-1d191fad595c@nohats.ca> User-Agent: Mutt/2.0.5 (2021-01-21) Archived-At: Subject: [openpgp] Curve448 in ECDH 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, 27 Feb 2021 23:38:48 -0000 --+WdxAB6L+rfxqE7p Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2021-02-23 at 02:19:03, Paul Wouters wrote: >=20 > - Incorporated RFC 6637 (ECDSA and ECDH, using NIST curves) > - Incorporate Curve25519 for ECDH Most of what's there looks fine (excepting the v5 fingerprint thing I mentioned elsewhere). I'm wondering, however, if there's consensus for adding Curve448 as well for ECDH. (I would be in favor of it.) I don't have an OID for it, but I believe RFC 8410 defines one, although that RFC defines a different OID for Curve25519 than I see here in the spec. The reason I ask is that in many implementations, of the NIST curves, only P-256 is implemented in a constant-time manner, whereas Curve25519 and Curve448 are almost always implemented in a constant-time manner. For example, Go has this problem. That's in addition to the pervasive questions about the selection of the parameters, which I want to acknowledge as a concern many people have but don't want to debate extensively. It therefore makes sense to provide a curve that doesn't have those limitations for those cases where users or specifications require a security level of 192 bits or greater. --=20 brian m. carlson (he/him or they/them) Houston, Texas, US --+WdxAB6L+rfxqE7p Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.2.27 (GNU/Linux) iHUEABYKAB0WIQQILOaKnbxl+4PRw5F8DEliiIeigQUCYDrX4AAKCRB8DEliiIei gRvzAP45dLYvIx4CimN8uG97TvF+9ScYOPO0OWLXyuLt/YB5/AD+JXVspbfF3r9W nXcc8VnzlzLNBVuPrkJQcUkGtM0uXwg= =tDgq -----END PGP SIGNATURE----- --+WdxAB6L+rfxqE7p-- From nobody Sat Feb 27 15:53:54 2021 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 5700A3A13F5 for ; Sat, 27 Feb 2021 15:53:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, 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 (3072-bit key) header.d=crustytoothpaste.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 TQEiRxTaa9yq for ; Sat, 27 Feb 2021 15:53:50 -0800 (PST) Received: from injection.crustytoothpaste.net (injection.crustytoothpaste.net [192.241.140.119]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AA3C3A163E for ; Sat, 27 Feb 2021 15:53:49 -0800 (PST) Received: from camp.crustytoothpaste.net (unknown [IPv6:2001:470:b978:101:7d4e:cde:7c41:71c2]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by injection.crustytoothpaste.net (Postfix) with ESMTPSA id A77EF60DF4 for ; Sat, 27 Feb 2021 23:53:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crustytoothpaste.net; s=default; t=1614469998; bh=48GlTNtYdKcZpi7GrZeTNN/gt7x4E2DAtfwqRAXhrGo=; h=Date:From:To:Subject:Content-Type:Content-Disposition:From: Reply-To:Subject:Date:To:CC:Resent-Date:Resent-From:Resent-To: Resent-Cc:In-Reply-To:References:Content-Type:Content-Disposition; b=YPiS4ngzvcHe8QIRtzZMl54a7tZMVOIqdi2INUGy78v9JG4vy7+DgSH2K9BZTti6+ 6/J+Xgx2Pms7mHFn4W+FtGcAvco+VVaxbHHi391fMRiGtg9rZVgUVeNkBLq/O6IBse R4kAYr9r3sCJiC5bSyhkFgxbCXBSfS8Xpp3Ruv1i0vqcbVSa1rxZaDT4r18QnvCJiU obKtv06KxXEBGhthIPRjuj3W9LrvjLZs5dLUVHXCbUe5O/Tb39Vf9pbW6yTVWr3+Md s7FDBBiWbuuodi+jskuY1ngHHGRTnzm2bbX0ErT+pJEJkE9L0AzIk1hxwo00ssPyio o3KOlYlf7ByJ/I80KcRU2yGcDXQ820lNfPmNsfhs/w33TjiMYsrMmOGJqMIpAuBEWW tlfY64cd7xVMAJGPoKDN5fpW/zxbte0NCgxyazgP9XtKhR4wLfGe5kPYmbIwf+8SY4 GX1KnsrcXCGgqu5h5a1EYSLwExnjx1JAbQ08wXdm46fchrESPjE Date: Sat, 27 Feb 2021 23:53:13 +0000 From: "brian m. carlson" To: openpgp@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="SA+EAYHmFm18rgmo" Content-Disposition: inline User-Agent: Mutt/2.0.5 (2021-01-21) Archived-At: Subject: [openpgp] RSA-PSS and RSA-OAEP for v5 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, 27 Feb 2021 23:53:53 -0000 --SA+EAYHmFm18rgmo Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable One of the persistent pieces of feedback about OpenPGP I've received =66rom folks involved in the security and cryptography fields is that the PKCS v1.5 algorithms are obsolete. It is well known that many cryptographic libraries have suffered (and will likely continue, despite their best efforts, to suffer) from padding vulnerabilities. TLS has recently added support for RSA-PSS and it's widely preferred over PKCS1-v1.5. I'm interested in seeing if we can require v5 SKESK packets with RSA use RSA-OAEP with SHA-256 and MGF1-SHA-256 and require that v5 signatures with RSA use RSA-PSS, with the MGF using the same digest as the signature. Hard-coding SHA-256 as the algorithm for RSA-OAEP means we don't need to specify it as a parameter, and since it's the must-implement algorithm, there's no reason an implementation won't support it. Folks that wish to provide a better than 128-bit security level will use ECDH instead, since RSA at the 192-bit level (7680 bit keys) is much slower and such keys are not practically used. I realize this requires implementers to add additional code, but I think the increase in security is worth it given the number of CVEs we've seen for padding vulnerabilities. We can tell implementers to avoid this vulnerability until we're blue in the face, but considering that both OpenSSL and NSS had this problem, that doesn't seem prudent. --=20 brian m. carlson (he/him or they/them) Houston, Texas, US --SA+EAYHmFm18rgmo Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.2.27 (GNU/Linux) iHUEABYKAB0WIQQILOaKnbxl+4PRw5F8DEliiIeigQUCYDrbZwAKCRB8DEliiIei ge1DAP9oqJjjPG65relD+VLB7fsirQ4o7Ut9wHqQYGuyuy6ongD/RzIqPy/Qa94+ Szz9RynEiwvk3Du8/zXBw2CdInWJsgo= =JUAl -----END PGP SIGNATURE----- --SA+EAYHmFm18rgmo-- From nobody Sat Feb 27 19:46:22 2021 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 02D323A08F4 for ; Sat, 27 Feb 2021 19:46:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 TfeBV6Ovrv6o for ; Sat, 27 Feb 2021 19:46:19 -0800 (PST) Received: from au-smtp-delivery-117.mimecast.com (au-smtp-delivery-117.mimecast.com [180.189.28.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 478823A08ED for ; Sat, 27 Feb 2021 19:46:18 -0800 (PST) Received: from AUS01-SY4-obe.outbound.protection.outlook.com (mail-sy4aus01lp2175.outbound.protection.outlook.com [104.47.71.175]) (Using TLS) by relay.mimecast.com with ESMTP id au-mta-87-Uh6eflUpNpWdDrmcGjs5eg-1; Sun, 28 Feb 2021 14:46:14 +1100 X-MC-Unique: Uh6eflUpNpWdDrmcGjs5eg-1 Received: from PS2PR01CA0023.apcprd01.prod.exchangelabs.com (2603:1096:300:2d::35) by SYCPR01MB5293.ausprd01.prod.outlook.com (2603:10c6:10:8a::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3805.24; Sun, 28 Feb 2021 03:46:12 +0000 Received: from PU1APC01FT058.eop-APC01.prod.protection.outlook.com (2603:1096:300:2d:cafe::ae) by PS2PR01CA0023.outlook.office365.com (2603:1096:300:2d::35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3890.19 via Frontend Transport; Sun, 28 Feb 2021 03:46:10 +0000 X-MS-Exchange-Authentication-Results: spf=none (sender IP is 130.216.95.208) smtp.mailfrom=cs.auckland.ac.nz; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cs.auckland.ac.nz Received: from uxcn13-tdc-e.UoA.auckland.ac.nz (130.216.95.208) by PU1APC01FT058.mail.protection.outlook.com (10.152.253.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.3890.19 via Frontend Transport; Sun, 28 Feb 2021 03:46:08 +0000 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-e.UoA.auckland.ac.nz (10.6.3.9) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 28 Feb 2021 16:46:06 +1300 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.1497.010; Sun, 28 Feb 2021 16:46:06 +1300 From: Peter Gutmann To: Daniel Kahn Gillmor , "Neal H. Walfield" , Paul Wouters CC: "openpgp@ietf.org" Thread-Topic: [openpgp] Sec. Considerations MUST about S2K [was: Re: I-D Action: draft-ietf-openpgp-crypto-refresh-02.txt] Thread-Index: AQHXDTFlY4pd4EeWd0uFVZo/0u7MRqps7dgf Date: Sun, 28 Feb 2021 03:46:06 +0000 Message-ID: <1614483966879.85613@cs.auckland.ac.nz> References: <7d8bdda1-4e5c-6c10-f3cd-1d191fad595c@nohats.ca> <87h7lzavvc.wl-neal@walfield.org>,<87mtvqcdtk.fsf@fifthhorseman.net> In-Reply-To: <87mtvqcdtk.fsf@fifthhorseman.net> Accept-Language: en-NZ, en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 28ed30b2-b4b0-4c47-9cfd-08d8db9b6247 X-MS-TrafficTypeDiagnostic: SYCPR01MB5293: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:7219 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0 X-Microsoft-Antispam-Message-Info: 2HACXxRHoTx86r2IIpAFuHM0IF7ms2wa7ezm6Scc8AM9kSFtQifGVpiC/1k7e36ekZGI1bMT+Y1is/mfkALmPlnEhdpi/Gy0LXSMzsDOPMTSSe9rBr3rvNzskBwkTH4sn/EvFUYds37QERWa7dr21pY3Gt4kRyiV7Q8q7RhTYyai6yl8gL9jIDnebpQDrlr9aXg+rpl1mGgcCBM9OhYu8FQgpB86PG07y+tCHPTxptekixmQu5p0ftQ0/iUqsuX+SfpGfEF970TfWnYZa+28Qchyj+S1yL3uo3HVH8HhWPYceLHJ+Rd6qsUQmTlXLieQrJPsZ9VCkAeS/XUtNgZ02JqWQAP69fKovtn+KriMafoqgYk/+VCOm+7zQ3SdDm2p9Y2myJIVeBQz+3F8m1MrBLAfDPIDWt86w+gM96TsDwsh/mc590TBMwp4wtlyZSrQm/nkrsWxO+nsn/q2hcwnUOG3KrqBoI3CzBdLrPQG0SM9QGU38qwY0f7b+uG50URZbgSD9FFe7qQ4jimd6IEEKCNES7EhjVa09ZJtS3NPNkeGnbRLpqGXMLl63lBi5hrOGuFxJ82YQuo21Y3XnFhZ0yqj0haxxRQur3cmw6ihypNZ/KuEGZUQRAOIpNZI+x1NKYp2zkRVA1pM2i6fbw3RwDmnEaJ9kTkh2SeeCb85gCc= X-Forefront-Antispam-Report: CIP:130.216.95.208; CTRY:NZ; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:uxcn13-tdc-e.UoA.auckland.ac.nz; PTR:natgate1-1.auckland.ac.nz; CAT:NONE; SFS:(4636009)(136003)(396003)(346002)(376002)(39860400002)(36840700001)(46966006)(478600001)(8936002)(2906002)(86362001)(4744005)(82310400003)(47076005)(36860700001)(26005)(2616005)(70206006)(36906005)(70586007)(786003)(110136005)(7636003)(82740400003)(5660300002)(4326008)(316002)(336012)(356005)(8676002)(186003); DIR:OUT; SFP:1101 X-OriginatorOrg: cs.auckland.ac.nz X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Feb 2021 03:46:08.4281 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 28ed30b2-b4b0-4c47-9cfd-08d8db9b6247 X-MS-Exchange-CrossTenant-Id: d1b36e95-0d50-42e9-958f-b63fa906beaa X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=d1b36e95-0d50-42e9-958f-b63fa906beaa; Ip=[130.216.95.208]; Helo=[uxcn13-tdc-e.UoA.auckland.ac.nz] X-MS-Exchange-CrossTenant-AuthSource: PU1APC01FT058.eop-APC01.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SYCPR01MB5293 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CAU17A13 smtp.mailfrom=pgut001@cs.auckland.ac.nz X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: cs.auckland.ac.nz Content-Language: en-NZ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [openpgp] Sec. Considerations MUST about S2K [was: Re: I-D Action: draft-ietf-openpgp-crypto-refresh-02.txt] 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, 28 Feb 2021 03:46:21 -0000 Daniel Kahn Gillmor writes:=0A=0A>I'm not sure abou= t this at all. For example, consider a system that knows=0A>that the strin= g is high-entropy ("good key equivalent") -- should they be=0A>prohibited f= rom using Simple or Salted S2K? Is this MUST really an=0A>interoperability= concern as =A76 of RFC 2119 suggests?=0A=0AAgreed, but it's a pretty simpl= e fix:=0A=0A Where it's likely that a low-entropy secret is being employed= , a compliant=0A application SHOULD use [...]=0A=0APeter.=0A From nobody Sat Feb 27 19:50:04 2021 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 6DF923A099F for ; Sat, 27 Feb 2021 19:50:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 cKnBzWkepvjn for ; Sat, 27 Feb 2021 19:50:00 -0800 (PST) Received: from au-smtp-delivery-117.mimecast.com (au-smtp-delivery-117.mimecast.com [124.47.189.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 692183A0930 for ; Sat, 27 Feb 2021 19:49:59 -0800 (PST) Received: from AUS01-SY4-obe.outbound.protection.outlook.com (mail-sy4aus01lp2168.outbound.protection.outlook.com [104.47.71.168]) (Using TLS) by relay.mimecast.com with ESMTP id au-mta-58-t6jNQPi1NFuz3Jd1iH6Fvw-1; Sun, 28 Feb 2021 14:49:56 +1100 X-MC-Unique: t6jNQPi1NFuz3Jd1iH6Fvw-1 Received: from SG2PR06CA0190.apcprd06.prod.outlook.com (2603:1096:4:1::22) by MEAPR01MB5174.ausprd01.prod.outlook.com (2603:10c6:220:6d::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3846.31; Sun, 28 Feb 2021 03:49:53 +0000 Received: from SG2APC01FT040.eop-APC01.prod.protection.outlook.com (2603:1096:4:1:cafe::b1) by SG2PR06CA0190.outlook.office365.com (2603:1096:4:1::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3890.20 via Frontend Transport; Sun, 28 Feb 2021 03:49:52 +0000 X-MS-Exchange-Authentication-Results: spf=none (sender IP is 130.216.95.208) smtp.mailfrom=cs.auckland.ac.nz; crustytoothpaste.net; dkim=none (message not signed) header.d=none;crustytoothpaste.net; dmarc=none action=none header.from=cs.auckland.ac.nz Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (130.216.95.208) by SG2APC01FT040.mail.protection.outlook.com (10.152.250.243) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.3890.19 via Frontend Transport; Sun, 28 Feb 2021 03:49:46 +0000 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.1497.2; Sun, 28 Feb 2021 16:49:45 +1300 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.1497.010; Sun, 28 Feb 2021 16:49:45 +1300 From: Peter Gutmann To: "brian m. carlson" , "openpgp@ietf.org" Thread-Topic: [openpgp] RSA-PSS and RSA-OAEP for v5 Thread-Index: AQHXDWPcH6D7hziraEeY3WgYIFAhT6ps7lom Date: Sun, 28 Feb 2021 03:49:45 +0000 Message-ID: <1614484185733.72813@cs.auckland.ac.nz> References: In-Reply-To: Accept-Language: en-NZ, en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: a5201b89-3058-438f-173b-08d8db9be46d X-MS-TrafficTypeDiagnostic: MEAPR01MB5174: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8882 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0 X-Microsoft-Antispam-Message-Info: DM2f1d8pSs08y6dUsv8F9pshxOqsPvSJiR7zrIyZe3nXWFkYAuMyDl68YaXZ4akHIhchZT80/7im2B+vTY9ADzTac9fdDthIiRRCrKWykCoDMKak49p8210Jd2OK8tHOndqjqTN78gMk91SBhVUHDbvkqiaL99SRnSA34cG6JmY/Fu8lWw6ixG2cVzGFT9+vMyu4Ji0hl0mO2EV3iNn+yTKAqOKRdI4YWln81pYDqFuJUiAM2TXGNx06ovFMHbisjxBAKHMcSjnqmwP8g1Nv0sa6KwWhCaRteUccJvq+99N5T6NJ6ttLQGcO3tPZs5T7QB68LNpmLf7Zx0lREd1FSOsEWnteJuAftu1IokhUl6TZLyfC+oJk5WemsV8R7ilyfwy4LjlVUKzNBC/1VpSf2jhTy2jMcr52xoIUegIZevCRXLSyFGc33SSsx6LHoztKaSoXKlPWxmP+LXsI/Q/+0mBOiCD08JcwU65VkhGrL1Cv1cS4pHtIxKdQNnk8KMkEApIvkglZ/fsuj18e0UvyEhK+tcDeBBl34rxQ4ZilXlC+52KOwTkREnRxTBzK18u7qxDu9S0/f0n4+jVG8T9711JQx9ebQcT/kDvuOsCxskKoKPEvg6U5Xm2qkKL+L8ZRhqUB1lVQquDQtYQDIrhsYQ== X-Forefront-Antispam-Report: CIP:130.216.95.208; CTRY:NZ; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:uxcn13-tdc-d.UoA.auckland.ac.nz; PTR:natgate1-1.auckland.ac.nz; CAT:NONE; SFS:(4636009)(39860400002)(376002)(346002)(136003)(396003)(36840700001)(46966006)(70206006)(8676002)(86362001)(336012)(7636003)(2616005)(83380400001)(356005)(478600001)(26005)(82740400003)(186003)(8936002)(36860700001)(786003)(316002)(82310400003)(36906005)(47076005)(110136005)(70586007)(2906002)(4744005)(5660300002); DIR:OUT; SFP:1101 X-OriginatorOrg: cs.auckland.ac.nz X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Feb 2021 03:49:46.8805 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: a5201b89-3058-438f-173b-08d8db9be46d X-MS-Exchange-CrossTenant-Id: d1b36e95-0d50-42e9-958f-b63fa906beaa X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=d1b36e95-0d50-42e9-958f-b63fa906beaa; Ip=[130.216.95.208]; Helo=[uxcn13-tdc-d.UoA.auckland.ac.nz] X-MS-Exchange-CrossTenant-AuthSource: SG2APC01FT040.eop-APC01.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MEAPR01MB5174 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CAU17A13 smtp.mailfrom=pgut001@cs.auckland.ac.nz X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: cs.auckland.ac.nz Content-Language: en-NZ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [openpgp] RSA-PSS and RSA-OAEP for v5 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, 28 Feb 2021 03:50:02 -0000 brian m. carlson writes:=0A=0A>I'm intereste= d in seeing if we can require v5 SKESK packets with RSA use RSA-=0A>OAEP wi= th SHA-256 and MGF1-SHA-256 and require that v5 signatures with RSA=0A>use = RSA-PSS, with the MGF using the same digest as the signature.=0A=0AApart fr= om adding a huge amount of complexity and potential interop problems,=0Ayou= 're not really gaining anything by this that isn't already addressed by=0A"= MUST use encode-them-memcmp() for signatures". PKCS #1 signing is perfectl= y=0Asecure if you do that, and PKCS #1 encryption doesn't matter much becau= se PGP=0Aisn't likely to be used in situations where it acts as an online m= illion-=0Amessage oracle.=0A=0ASee also my post to the cryptography list la= st year about all the games an=0Aattacker can play with OAEP because the pa= rameters aren't authenticated and=0Atherefore attacker-controlled.=0A=0APet= er.=0A From nobody Sun Feb 28 09:09:37 2021 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 661D23A1966 for ; Sun, 28 Feb 2021 09:09:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=nohats.ca 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 x9picWpFy2-G for ; Sun, 28 Feb 2021 09:09:33 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 9F9403A1967 for ; Sun, 28 Feb 2021 09:09:33 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4DpVHZ5SgqzCQf; Sun, 28 Feb 2021 18:09:30 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1614532170; bh=fwLZCsOwcvjOSZMe1KNg7oMDfKyh7t25PJAzPjQ4mcM=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=g7ViKO+FFXP6BMbnMK8f91SvjIH4leSfyUwQnCZ72fa+jHyn0IIEivI9uZvH1MUSp cdX/MPCveQCgucL97G2IePLD34GVYqxcVhufdE20+VitnqOVs945JSWc/U696InZcb VK5jgJCMgf2smrjaxU4lAA94lbwTkOrCiEM0dRpQ= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id ps4ZuIfV799V; Sun, 28 Feb 2021 18:09:29 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sun, 28 Feb 2021 18:09:29 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 49C6E6029B62; Sun, 28 Feb 2021 12:09:28 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 4109966B1E; Sun, 28 Feb 2021 12:09:28 -0500 (EST) Date: Sun, 28 Feb 2021 12:09:28 -0500 (EST) From: Paul Wouters To: "brian m. carlson" cc: openpgp@ietf.org In-Reply-To: Message-ID: References: <7d8bdda1-4e5c-6c10-f3cd-1d191fad595c@nohats.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [openpgp] Curve448 in ECDH 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, 28 Feb 2021 17:09:35 -0000 On Sat, 27 Feb 2021, brian m. carlson wrote: > I'm wondering, however, if there's consensus for adding Curve448 as well That is being tracked by the WG chairs. > The reason I ask is that in many implementations, of the NIST curves, > only P-256 is implemented in a constant-time manner, whereas Curve25519 > and Curve448 are almost always implemented in a constant-time manner. Is that a concern for openpgp ? openpgp is not an interactive protocol where there is a server-client with possible MITM observing time spent? Paul From nobody Sun Feb 28 09:15:22 2021 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 AA11D3A1970 for ; Sun, 28 Feb 2021 09:15:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=nohats.ca 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 RltrH2VJKco5 for ; Sun, 28 Feb 2021 09:15:19 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 E841B3A196D for ; Sun, 28 Feb 2021 09:15:18 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4DpVQD4k0Fz36p; Sun, 28 Feb 2021 18:15:16 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1614532516; bh=zk2gI1bgAfafVtd2qyP+LKLW/X3uTwIM7aUws5LBEZw=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=aWcn61gb7/l1LHh5MXwXMCGStic2sofoq+Mxx9OYY9s91Ext5Dyrt4jih6dg9V0N+ jgJPQjpHKQH3ZSyCajHkPme/Y7rIwE5DkurfbRfmzDp29kDH19fb4kQ5+Y7vaBpeqE +6d/SZIaBsq7ZvEbZO9b2NwgL0DLgMmBFibyTLNo= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id Hn0LCpjXKIF4; Sun, 28 Feb 2021 18:15:15 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sun, 28 Feb 2021 18:15:14 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id C164A6029B62; Sun, 28 Feb 2021 12:15:13 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B8CC266B1E; Sun, 28 Feb 2021 12:15:13 -0500 (EST) Date: Sun, 28 Feb 2021 12:15:13 -0500 (EST) From: Paul Wouters To: "brian m. carlson" cc: openpgp@ietf.org In-Reply-To: Message-ID: <9a245468-60f4-df3b-c0e6-5ffc93c1a630@nohats.ca> References: <7d8bdda1-4e5c-6c10-f3cd-1d191fad595c@nohats.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [openpgp] v5 fingerprints in ECDH 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, 28 Feb 2021 17:15:21 -0000 On Sat, 27 Feb 2021, brian m. carlson wrote: > I noticed for v5 fingerprints we hash only the left 20 octets in the > ECDH KDF: > > 20 octets representing a recipient encryption subkey or a master > key fingerprint, identifying the key material that is needed for > the decryption. For version 5 keys the 20 leftmost octets of the > fingerprint are used. > > Absent a compelling reason, I'd prefer to see the entire fingerprint > used. It doesn't make sense to define a fingerprint that's 32 octets > and then truncate it to 20 octets in some cases. At that point, we're > relying on the collision resistance of a different algorithm, not > SHA-256, and decreasing the security level to below 128 bits. > > Note that if we do this, we'll need to update the text above and below > to reflect that the sizes are not invariant. I think whether or not this change can still be made depends on what has already been implemented. That is, are we describing what is already out there, or is this something new. If it is new, than this issue is worth getting consensus on. Can implementors share some light on this? Does anyone remember the origin of only using 20 octets and not all octets? Paul From nobody Sun Feb 28 09:17:29 2021 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 815C63A197A for ; Sun, 28 Feb 2021 09:17:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, 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 (3072-bit key) header.d=crustytoothpaste.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 P5emYu_sHuhs for ; Sun, 28 Feb 2021 09:17:27 -0800 (PST) Received: from injection.crustytoothpaste.net (injection.crustytoothpaste.net [192.241.140.119]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA6943A1979 for ; Sun, 28 Feb 2021 09:17:26 -0800 (PST) Received: from camp.crustytoothpaste.net (unknown [IPv6:2001:470:b978:101:7d4e:cde:7c41:71c2]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by injection.crustytoothpaste.net (Postfix) with ESMTPSA id 1619860DF4; Sun, 28 Feb 2021 17:17:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crustytoothpaste.net; s=default; t=1614532641; bh=aYhYu8hFV7wRsTqN9guVVZLw7HV8hpcIcV4cquWuxAY=; h=Date:From:To:Cc:Subject:References:Content-Type: Content-Disposition:In-Reply-To:From:Reply-To:Subject:Date:To:CC: Resent-Date:Resent-From:Resent-To:Resent-Cc:In-Reply-To:References: Content-Type:Content-Disposition; b=GTzL8b4ko98bs4UEsckBKkTCc/8yZZ/D6RE7ukCLn3/eZTcA2Jq35CYLDZf6WSJAn ceeGnZEAU7/1NgCWf5UrEJmkF4XCwfqEZ98GHFrstayYOY6Ap+q4O/IQeHmrzRPqUZ E+pSmvMu3EifmP3bN+z34ukRK4EnQCbdxsf8kvwvFJE0dLBBRYmTXy1YdGyyXEAlOe PcpPPHyyjYN5pSL6KZthvkxFcPYg46i063B3tnVKCQZE8THtPMNb/MResKB1TaawCB htiTiVxAmRWq7H1y9dZe2647TIo1X+XjN4BR4g8ASK/zaNwdAeSoZPuUuHKPv45iYT nNK9i92tho3xbxH21PIiqvcKPcvHS3MQj+XU9ZXsxlKjjDDVSam9CVf+hSlMuGxHt6 vWAZajEveEbyjInPZpU2FUbPaAlpvKrNPikhohIZ5fvZXZXvm1lrIhnMVdVaiTbgRp gVWCnThrUrJ+XN2JpnGlod/u+xFPdmayOlGv/ozaaEF/KbQOkeB Date: Sun, 28 Feb 2021 17:17:15 +0000 From: "brian m. carlson" To: Paul Wouters Cc: openpgp@ietf.org Message-ID: References: <7d8bdda1-4e5c-6c10-f3cd-1d191fad595c@nohats.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Sr/WbtbDCFZaeFA/" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/2.0.5 (2021-01-21) Archived-At: Subject: Re: [openpgp] Curve448 in ECDH 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, 28 Feb 2021 17:17:28 -0000 --Sr/WbtbDCFZaeFA/ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2021-02-28 at 17:09:28, Paul Wouters wrote: > On Sat, 27 Feb 2021, brian m. carlson wrote: >=20 > > I'm wondering, however, if there's consensus for adding Curve448 as well >=20 > That is being tracked by the WG chairs. Great. > > The reason I ask is that in many implementations, of the NIST curves, > > only P-256 is implemented in a constant-time manner, whereas Curve25519 > > and Curve448 are almost always implemented in a constant-time manner. >=20 > Is that a concern for openpgp ? openpgp is not an interactive protocol > where there is a server-client with possible MITM observing time spent? People definitely do use OpenPGP for interactive uses where constant time operations are relevant. For example, when you create a commit by editing a file on GitHub, that commit will be signed by GitHub's private key, which is an online use. This is hardly the only case where people sign online. We've also seen cases where people do encryption and decryption online, such as by sending an encrypted message to an API and getting back an error or not depending on whether the message could be successfully decrypted. I agree that these are not the typical uses of OpenPGP, but people definitely do use it for online operations, and therefore, we need to properly consider them when we secure the protocol. --=20 brian m. carlson (he/him or they/them) Houston, Texas, US --Sr/WbtbDCFZaeFA/ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.2.27 (GNU/Linux) iHUEABYKAB0WIQQILOaKnbxl+4PRw5F8DEliiIeigQUCYDvQGgAKCRB8DEliiIei gdYJAP9U7IdTilr10ON81+/CpOxqKKil7fYlGhn/IvQVrJUxCAD/dx+OEN80kkd8 f0og5x2p7/k+rpQQmEciEfEtb0FHcQ8= =O+e2 -----END PGP SIGNATURE----- --Sr/WbtbDCFZaeFA/-- From nobody Sun Feb 28 09:59:25 2021 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 BD1993A1A07 for ; Sun, 28 Feb 2021 09:59:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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=pass (3072-bit key) header.d=crustytoothpaste.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 ly723g1lAh84 for ; Sun, 28 Feb 2021 09:59:22 -0800 (PST) Received: from injection.crustytoothpaste.net (injection.crustytoothpaste.net [192.241.140.119]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EE073A1A06 for ; Sun, 28 Feb 2021 09:59:21 -0800 (PST) Received: from camp.crustytoothpaste.net (unknown [IPv6:2001:470:b978:101:7d4e:cde:7c41:71c2]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by injection.crustytoothpaste.net (Postfix) with ESMTPSA id 715E860DF4 for ; Sun, 28 Feb 2021 17:58:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crustytoothpaste.net; s=default; t=1614535130; bh=90Or0KW+DngTo/H83HomakTo7nH7HcL0r+kraCSKWnA=; h=Date:From:To:Subject:References:Content-Type:Content-Disposition: In-Reply-To:From:Reply-To:Subject:Date:To:CC:Resent-Date: Resent-From:Resent-To:Resent-Cc:In-Reply-To:References: Content-Type:Content-Disposition; b=QtGwMy+mUWVfuK7XHqZXfTKvUB0fU1ML2IBLdaBLsbVYb7eBJJfrPFILmrhHGhPCS PvJafbee/LoUF1v0eVnCTBMdxpYT8YosNn3vB7aJT5/cDZhpg7ph+VU/99G8bMbmAM vULbNRUjk8zNbjN24tXtky1PpPJuVVi1ZecO+QT6D8RJBAYSMaa6jKBT26DwhpNFdS 7MPd1OADP4BixJsxFSA3RMOw+DL0AldNv6LievFEbvZAAdi4iJb0ow8Z8kKsaWNfxy 204Kg1s0wKy+mhSNhhsjGdC+CQsgK3qW7FgiaORAZxTTW6HMHyeg2tAaz+IMah5Yg+ 0VqmolSriGxzcu6xGRq9RgsBS176oW7O2NSQjBfgkBzRFm4yCLMbjYFzRLafmUfmdm Rn/qtMV1nyyF+3L/57k5JYs6UQE94+zJt2zxVf4Xbd4svp1MfzDezenmK3DY8TBTKT sHRabTDjZ//6Te7mbRtI9WKcryheT6D3BBohloYUd94nFl+7Ytf Date: Sun, 28 Feb 2021 17:58:45 +0000 From: "brian m. carlson" To: "openpgp@ietf.org" Message-ID: References: <1614484185733.72813@cs.auckland.ac.nz> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="fsRx2bvL8iMewF9r" Content-Disposition: inline In-Reply-To: <1614484185733.72813@cs.auckland.ac.nz> User-Agent: Mutt/2.0.5 (2021-01-21) Archived-At: Subject: Re: [openpgp] RSA-PSS and RSA-OAEP for v5 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, 28 Feb 2021 17:59:24 -0000 --fsRx2bvL8iMewF9r Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2021-02-28 at 03:49:45, Peter Gutmann wrote: > brian m. carlson writes: >=20 > >I'm interested in seeing if we can require v5 SKESK packets with RSA use= RSA- > >OAEP with SHA-256 and MGF1-SHA-256 and require that v5 signatures with R= SA > >use RSA-PSS, with the MGF using the same digest as the signature. >=20 > Apart from adding a huge amount of complexity and potential interop probl= ems, > you're not really gaining anything by this that isn't already addressed by > "MUST use encode-them-memcmp() for signatures". PKCS #1 signing is perfe= ctly > secure if you do that, and PKCS #1 encryption doesn't matter much because= PGP > isn't likely to be used in situations where it acts as an online million- > message oracle. I've already outlined that people definitely do use OpenPGP in online situations in . IIRC, we've seen people report online usages to the list, and I provided examples where users do indeed sign online. And despite the fact that we clearly issue CVEs against people who people who create Bleichenbacher oracles, people still write them. These attacks have been known for years and previously fixed and yet in 2018, we had another round of them in TLS. PKCS #1 is very hard to get right. We've seen many implementations have problems with it, some multiple times. The fact that people continue to get it wrong means that it's easy to misuse. We specifically use techniques such as AEADs because they are _harder_ to misuse than techniques which are equally secure in the theoretic sense, such as encrypt-then-MAC with CTR and HMAC. Using RSA-PSS and RSA-OAEP doesn't mean that implementers don't have to be careful and prudent, but it does mean that if they make a mistake that the consequences are less terrible. I agree that this requires additional code and adds additional complexity, but we're also adding support for entirely new cipher modes and other security improvements which do as well. Most cryptographic libraries already support RSA-PSS and RSA-OAEP, so there's little code to add. OpenSSL, libgcrypt, RustCrypto, and Go's standard library all already support this. It's pretty much a matter of substituting a handful of lines of code based on a branch on the version number. > See also my post to the cryptography list last year about all the games an > attacker can play with OAEP because the parameters aren't authenticated a= nd > therefore attacker-controlled. I was unable to find anything that looked like a relevant thread in the archives for 2020. Could you provide a citation? --=20 brian m. carlson (he/him or they/them) Houston, Texas, US --fsRx2bvL8iMewF9r Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.2.27 (GNU/Linux) iHUEABYKAB0WIQQILOaKnbxl+4PRw5F8DEliiIeigQUCYDvZ1QAKCRB8DEliiIei ge8eAQC5nL2vnbmytgb4coW3nvaA/YZLBHiSLjL54UzAJHH08QD+KsGiawq8O/cG 3ei12CPeY62rYNlnU6c7jEx2wBI3gAY= =6C/Q -----END PGP SIGNATURE----- --fsRx2bvL8iMewF9r-- From nobody Sun Feb 28 10:08:10 2021 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 DF1DA3A1A24 for ; Sun, 28 Feb 2021 10:08:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=nohats.ca 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 0bogQtxXMhfv for ; Sun, 28 Feb 2021 10:08:06 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 199703A1A22 for ; Sun, 28 Feb 2021 10:08:06 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4DpWb82kh7zCZC; Sun, 28 Feb 2021 19:08:04 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1614535684; bh=CTEP67AWa92BxLKePQPg7/Jwyysw9x0xxsNXidFcZD0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=f2wGDJD4YU+VtgggPAeLdWFmstVkDmIYq/xJztESioAalzo0r7IXfNpIWrlzIDNan FQ2E8Skps9Di6y2i2o0yzqa8UYnYChahNSQKYlfwvgKh0W3B/jF1FSoGMoYZM5GKvu OBHfHd6P8cuNdAhEjT8jlRrM98pQiNoiMcL8Fsm0= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id SrIxaWHACANT; Sun, 28 Feb 2021 19:08:03 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sun, 28 Feb 2021 19:08:02 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 96AFB6029B62; Sun, 28 Feb 2021 13:08:01 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 8E25E66B1E; Sun, 28 Feb 2021 13:08:01 -0500 (EST) Date: Sun, 28 Feb 2021 13:08:01 -0500 (EST) From: Paul Wouters To: Daniel Kahn Gillmor cc: =?ISO-8859-15?Q?=C1ngel?= , openpgp@ietf.org In-Reply-To: <87v9aecg7i.fsf@fifthhorseman.net> Message-ID: <2f3ac8e-7588-f4d5-8588-962bb88d6171@nohats.ca> References: <7d8bdda1-4e5c-6c10-f3cd-1d191fad595c@nohats.ca> <4f3d66b74b46b5b8bf27b5e1589bf80e.squirrel@mail2.ihtfp.org> <87a6rug0x5.fsf@wheatstone.g10code.de> <8473b015f635c0f88f9bceed8acda0f8.squirrel@mail2.ihtfp.org> <239af1473534565304e2ecfeca630219417ebc0e.camel@16bits.net> <87v9aecg7i.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [openpgp] I-D Action: draft-ietf-openpgp-crypto-refresh-02.txt (fwd) 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, 28 Feb 2021 18:08:09 -0000 On Fri, 26 Feb 2021, Daniel Kahn Gillmor wrote: >> I would prefer to keep single quotes for values referring to single >> bytes standing by themselves, as rfc4880 did. -00 changed them to >> double quotes but using single quotes as in C seems better. I agree with this. It would be better. > I'm not sure how to address this request without doing some heavy > lifting in the toolchain, espcially since it looks like you want the > tooling to behave differently for characters in the two different > places. If the single quotes are part of the regular text, wouldn't it just work? > However, it looks like this is actually a bug in xml2rfc, which wants to > put two spaces between a period and the next sentence. Which in itself is pretty archaic and shouldn't be done by default :) (Althouh the unit fmt command also still defaults to this) >> crypto-refresh-01/02 nitpicks >> ===== >> At 1. Introduction, change "RFC 5581 (Camellia cipher)" to "RFC 5581 >> (The Camellia Cipher in OpenPGP)" or "RFC 5581 (Camellia Cipher in >> OpenPGP)", since just "Camellia cipher" could be confused with the >> description itself of Camellia (rfc3713). >> "ECC for OpenPGP" should perhaps be changed to "ECC in OpenPGP" which is the >> preposition used in that rfc title. >> Full name of RFC 6637 is "Elliptic Curve Cryptography (ECC) in OpenPGP" and >> would be the proper one if we wanted to use the complete names of the rfc, >> albeit I don't think that would matter either way. > > These aren't the full RFC names (4880 itself is not "OpenPGP"), they're > shorthand labels, but i agree that they should be normalized to be more > readable. I submitted the editorial suggestion > https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/36 to make > them "Camellia in OpenPGP" and "Elliptic Curves in OpenPGP". Seems reasonable. If no one objects over the next few days we will merge it in. >> I'm not too keen on the way this section is introduced. I may provide a MR if >> I can come up with something. > > Please do propose an MR. Indeed, please do. Thanks for the review, and thanks to dkg for filing the issues raised to discuss later in the WG. Paul From nobody Sun Feb 28 10:12:15 2021 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 994693A1A2B for ; Sun, 28 Feb 2021 10:12:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=nohats.ca 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 zbQbDIiupZP8 for ; Sun, 28 Feb 2021 10:12:13 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 2390A3A1A2A for ; Sun, 28 Feb 2021 10:12:13 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4DpWgv6JVlzCZC; Sun, 28 Feb 2021 19:12:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1614535931; bh=rLy8/HKLh8v8YnPhOO352snsEW7PfWNxUNkRT818iwY=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=uuSUdYX1trKAh7bK3DPyQTdZaY/Pr5rIOD/X3XqiLY35NzbiV4pJSw8ARL5XQOqIr GQOvU7srAuDVH57NlOKiMzQfoEDFOuECJVUVNlEoknOJsoZfo9snfZiusIN2ZCzHfY BSnD5WLtUUYc6mXEkdC+LN44HVoSg2ST9BOZiD20= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id sk5SlAT6jBum; Sun, 28 Feb 2021 19:12:10 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sun, 28 Feb 2021 19:12:10 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 75EC26029B62; Sun, 28 Feb 2021 13:12:09 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 74AD566B1E; Sun, 28 Feb 2021 13:12:09 -0500 (EST) Date: Sun, 28 Feb 2021 13:12:09 -0500 (EST) From: Paul Wouters To: Daniel Kahn Gillmor cc: "Neal H. Walfield" , openpgp@ietf.org In-Reply-To: <87pn0mcecf.fsf@fifthhorseman.net> Message-ID: <33a8ecf7-c845-919b-7247-1b3922ef695c@nohats.ca> References: <7d8bdda1-4e5c-6c10-f3cd-1d191fad595c@nohats.ca> <87im6faw06.wl-neal@walfield.org> <87pn0mcecf.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [openpgp] I-D Action: draft-ietf-openpgp-crypto-refresh-02.txt (fwd) 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, 28 Feb 2021 18:12:15 -0000 On Fri, 26 Feb 2021, Daniel Kahn Gillmor wrote: >> - 09 k0 k1 ... k31 c0 c1 05 05 05 05 05 >> + 09 k0 k1 ... k31 C0 C1 05 05 05 05 05 >> >> -The octets c0 and c1 above denote the checksum. >> +The octets C0 and C1 above denote the checksum. > > This seems like a mistake. C0 and C1 could be specific hexadecimal > octets (decimal 12), whereas "c0" and "c1" here are intended to be > placeholders for the checksum. This is a bit confusing, maybe it would > be better to use s0 and s1 (s for "sum") so that it's clear that it > isn't hex? I like the idea of using s0 and s1. > I've included this proposal (without the two changes above that i think > are mistaken) and your other remark about the big-endianness of the > two-octet scalar in a merge request: > > https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/38 > > I encourage people to make merge requests directly in gitlab in addition > to posting patches to the mailing list, especially for > non-substantive/editorial changes like this. Although please also comment on the list, so the editors can use that to determine consensus, and importantly, any AD later on can read the mail archive to verify any contentious consensus claim. Paul From nobody Sun Feb 28 10:19:42 2021 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 2943B3A1A47 for ; Sun, 28 Feb 2021 10:19:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=nohats.ca 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 7kfpgipG8lh6 for ; Sun, 28 Feb 2021 10:19:38 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 B00A23A1A46 for ; Sun, 28 Feb 2021 10:19:38 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4DpWrT3Cz3zCZC; Sun, 28 Feb 2021 19:19:37 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1614536377; bh=RbKhSxxyc68XbIbW1YTo+iDYiQTJHzm/Ps3q/a5bjXg=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=idXzpVkuy98oFme+vc17iS7p/qKSJUNgNJdFyTXJ1e8Ymt/OheU62ZSASUP+oJVjb maStITVbYwNSRIOyFTdake1XIgrpMeP7y7OokbKAllJ/EqinOdhYIybTcI31Ur7TXg VRPOtva1GUhcZpZVbMD9TULwYJUhFiySiTY+x4ZQ= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id esziANpucjW1; Sun, 28 Feb 2021 19:19:36 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sun, 28 Feb 2021 19:19:36 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 401086029B62; Sun, 28 Feb 2021 13:19:35 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 37BCF66B1E; Sun, 28 Feb 2021 13:19:35 -0500 (EST) Date: Sun, 28 Feb 2021 13:19:35 -0500 (EST) From: Paul Wouters To: "brian m. carlson" cc: openpgp@ietf.org In-Reply-To: Message-ID: <77d23f6c-a7c4-f43d-f0ac-cb511dd284c5@nohats.ca> References: <7d8bdda1-4e5c-6c10-f3cd-1d191fad595c@nohats.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [openpgp] Curve448 in ECDH 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, 28 Feb 2021 18:19:41 -0000 On Sun, 28 Feb 2021, brian m. carlson wrote: >> Is that a concern for openpgp ? openpgp is not an interactive protocol >> where there is a server-client with possible MITM observing time spent? > > People definitely do use OpenPGP for interactive uses where constant > time operations are relevant. For example, when you create a commit by > editing a file on GitHub, that commit will be signed by GitHub's private > key, which is an online use. This is hardly the only case where people > sign online. While this is online, there is no negotiation to monitor where you can learn anything based on timing, as you don't get errors back to do timing on? > We've also seen cases where people do encryption and decryption online, > such as by sending an encrypted message to an API and getting back an > error or not depending on whether the message could be successfully > decrypted. This does seem to be a case where constant time matters. I was not aware that openpgp was used in such ways. > I agree that these are not the typical uses of OpenPGP, but people > definitely do use it for online operations, and therefore, we need to > properly consider them when we secure the protocol. Sure, although if Curve448 has passed CFRG review, and other IETF protocols are using it as well, I would think the algorithm would be safe to use? And that constant time implementations will happen? Especially since those other protocols like TLS or IKE would be much more sensitive to this? Paul From nobody Sun Feb 28 10:44:43 2021 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 B0A4E3A1A91 for ; Sun, 28 Feb 2021 10:44:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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=pass (3072-bit key) header.d=crustytoothpaste.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 Ii1wUYhZMQfM for ; Sun, 28 Feb 2021 10:44:40 -0800 (PST) Received: from injection.crustytoothpaste.net (injection.crustytoothpaste.net [192.241.140.119]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A54C3A1A90 for ; Sun, 28 Feb 2021 10:44:39 -0800 (PST) Received: from camp.crustytoothpaste.net (unknown [IPv6:2001:470:b978:101:7d4e:cde:7c41:71c2]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by injection.crustytoothpaste.net (Postfix) with ESMTPSA id CA32760DF4 for ; Sun, 28 Feb 2021 18:44:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crustytoothpaste.net; s=default; t=1614537847; bh=DJeFktlfA4ywQFiqs3H3fikl2gspa+6yTkBD5txnBuM=; h=Date:From:To:Subject:References:Content-Type:Content-Disposition: In-Reply-To:From:Reply-To:Subject:Date:To:CC:Resent-Date: Resent-From:Resent-To:Resent-Cc:In-Reply-To:References: Content-Type:Content-Disposition; b=ISWNy0WmVirQ/ZeGZRfx9PJrriNDa5BIDGtbEzESkRHGzf7YziZnc9CJ0bYLxx9ak VkYZOJq2Bj5o8gJq6fqH3BwG1Cypi2v465zvetWY8LQ4+pATkaL6Tc1QE49Cs6JR74 NCPsI1eBZzVnnHJqV904kaXcgrh//TRL0PJ6bEIVO/79jvZ3tdPY+yk1w6bh+uGUy/ glOv60LRRgy7Mx5VklAwjcNXpxTVceascoVYLQKuQ+xrJhi+fxzPsinjPoD6jvdZNY oUa4qFcXknhHPOtmuz1mwSqaUsZ968mB35drbjRWJr/wYk5xFd7L5zX/sWrEN4ZN7w VMfMJfQoV7DvLgJfOWJh5mKNp+KKbclLg3+GyBYR2kTikrGFHCYgBy0TU2vV1mksOA 0Fi6ePfgMEcJzb8DzJ2fwNzQRk9YH4DP/deLZJVg+LVBw82UnC92a4BJl1Y9tMh+et 3UVU0IGflooVvNdoH13mIhJkrXuoKCtE2K3CdjEFU7TzyuiLm4T Date: Sun, 28 Feb 2021 18:44:01 +0000 From: "brian m. carlson" To: openpgp@ietf.org Message-ID: References: <7d8bdda1-4e5c-6c10-f3cd-1d191fad595c@nohats.ca> <77d23f6c-a7c4-f43d-f0ac-cb511dd284c5@nohats.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="lv5qLzqgEmJUJW5g" Content-Disposition: inline In-Reply-To: <77d23f6c-a7c4-f43d-f0ac-cb511dd284c5@nohats.ca> User-Agent: Mutt/2.0.5 (2021-01-21) Archived-At: Subject: Re: [openpgp] Curve448 in ECDH 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, 28 Feb 2021 18:44:42 -0000 --lv5qLzqgEmJUJW5g Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2021-02-28 at 18:19:35, Paul Wouters wrote: > On Sun, 28 Feb 2021, brian m. carlson wrote: >=20 > > > Is that a concern for openpgp ? openpgp is not an interactive protocol > > > where there is a server-client with possible MITM observing time spen= t? > >=20 > > People definitely do use OpenPGP for interactive uses where constant > > time operations are relevant. For example, when you create a commit by > > editing a file on GitHub, that commit will be signed by GitHub's private > > key, which is an online use. This is hardly the only case where people > > sign online. >=20 > While this is online, there is no negotiation to monitor where you can > learn anything based on timing, as you don't get errors back to do > timing on? True, but you can create arbitrary content to sign, so you can influence the data used in the signature. If, for example, signing a message where some hash bits have value A consistently takes more or less time than a message where some bits have value B, then that could probably be easily leveraged to learn something about the private key. So I think this is a case where we'd see a timing oracle based on time to complete versus a timing oracle based on success or failure. > > I agree that these are not the typical uses of OpenPGP, but people > > definitely do use it for online operations, and therefore, we need to > > properly consider them when we secure the protocol. >=20 > Sure, although if Curve448 has passed CFRG review, and other IETF > protocols are using it as well, I would think the algorithm would > be safe to use? And that constant time implementations will happen? > Especially since those other protocols like TLS or IKE would be much > more sensitive to this? I believe Curve448 is presently considered secure and is expected to be so for as long as quantum computers are not a threat, which is why CFRG standardized it. All implementations of Curve25519 and Curve448 that I'm aware of are specifically designed to be constant time. I agree that protocols which are always online like TLS are more likely to be vulnerable to these attacks, but since most implementations of OpenPGP are general purpose, it's hard to exclude them from online usage. --=20 brian m. carlson (he/him or they/them) Houston, Texas, US --lv5qLzqgEmJUJW5g Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.2.27 (GNU/Linux) iHUEABYKAB0WIQQILOaKnbxl+4PRw5F8DEliiIeigQUCYDvkcQAKCRB8DEliiIei gfOoAQCKKr5Z24SVGFHA0usQ8XuTokix78Cge7IETQD3Xq/UTQEApiGotTC/n19z zxFtEOvZWowFX7wZyG9wfvm9qx13Kg4= =+7ks -----END PGP SIGNATURE----- --lv5qLzqgEmJUJW5g-- From nobody Sun Feb 28 10:44:54 2021 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 7BBF73A1AB6 for ; Sun, 28 Feb 2021 10:44:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-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 DjyuXSeNgI2Z for ; Sun, 28 Feb 2021 10:44:46 -0800 (PST) Received: from zucker2.schokokeks.org (zucker2.schokokeks.org [178.63.68.90]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B9FD3A1AC7 for ; Sun, 28 Feb 2021 10:44:45 -0800 (PST) Date: Sun, 28 Feb 2021 19:44:40 +0100 From: Hanno =?iso-8859-1?q?B=F6ck?= To: openpgp@ietf.org Message-ID: <20210228194440.63932c1b@computer> In-Reply-To: <1614484185733.72813@cs.auckland.ac.nz> References: <1614484185733.72813@cs.auckland.ac.nz> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [openpgp] RSA-PSS and RSA-OAEP for v5 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, 28 Feb 2021 18:44:53 -0000 On Sun, 28 Feb 2021 03:49:45 +0000 Peter Gutmann wrote: > See also my post to the cryptography list last year about all the > games an attacker can play with OAEP because the parameters aren't > authenticated and therefore attacker-controlled. This is a valid concern, but it can be completely eliminated by fixing all parameters in the standard. --=20 Hanno B=C3=B6ck https://hboeck.de/ From nobody Sun Feb 28 10:45:21 2021 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 0694F3A1A91 for ; Sun, 28 Feb 2021 10:45:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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=pass (1024-bit key) header.d=gnupg.org 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 KNB0LSEhGvw3 for ; Sun, 28 Feb 2021 10:45:18 -0800 (PST) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (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 234473A1A90 for ; Sun, 28 Feb 2021 10:45:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnupg.org; s=20181017; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=j5pQ9pR15HwraOnX825ZvPGuL8dpTbKR/kjatxmawy4=; b=Rr/kyjbVKhsPADd4XcTAK0neYK iyuMDJE+PvYVk9iutdaMDp/RD9SmjLw5ypKKxMlAtP88sPMq7KUQBjZ4o8MsCLFOtu0ut9tlwMq0+ flB6fuP8qpeV5Z4YCK6/ijedfDH+paYCTalQ/i0S0D/PvpVL2BZlD8njPfCsXHNwZS/Q=; Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1lGR40-0003qB-2u for ; Sun, 28 Feb 2021 19:45:08 +0100 Received: from wk by wheatstone.g10code.de with local (Exim 4.92 #5 (Debian)) id 1lGR2M-0007Lu-3q; Sun, 28 Feb 2021 19:43:26 +0100 From: Werner Koch To: "brian m. carlson" Cc: openpgp@ietf.org References: Organisation: GnuPG e.V. X-message-flag: Mails containing HTML will not be read! Please send only plain text. Mail-Followup-To: "brian m. carlson" , openpgp@ietf.org Date: Sun, 28 Feb 2021 19:43:19 +0100 In-Reply-To: (brian m. carlson's message of "Sat, 27 Feb 2021 23:53:13 +0000") Message-ID: <87ft1g9goo.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=passwd_Ebola_TIE_Shell_virtual_Listeria_NBIC_bemd_LUK_LLNL=Shelter-i"; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] RSA-PSS and RSA-OAEP for v5 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, 28 Feb 2021 18:45:20 -0000 --=passwd_Ebola_TIE_Shell_virtual_Listeria_NBIC_bemd_LUK_LLNL=Shelter-i Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 27 Feb 2021 23:53, brian m. carlson said: > I'm interested in seeing if we can require v5 SKESK packets with RSA use > RSA-OAEP with SHA-256 and MGF1-SHA-256 and require that v5 signatures That would add a lot of additional complexity for no good reason because RSA will over short or long anyway be replaces by 25519 and 448. > I realize this requires implementers to add additional code, but I think > the increase in security is worth it given the number of CVEs we've seen > for padding vulnerabilities. We can tell implementers to avoid this and replace them with bugs in the way more complext PSS and OAEP. I see no reason for it and doubt that this can be viewed as part of the WG's old and new charter. Shalom-Salam, Werner =2D-=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=passwd_Ebola_TIE_Shell_virtual_Listeria_NBIC_bemd_LUK_LLNL=Shelter-i Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQSHd0YfKgdOvEgNNZQZzByeCFsQegUCYDvkRwAKCRAZzByeCFsQ enMaAP0R944tazZnvPO0DNuw/NSw+4Tv+oWhzKwN5yfy1UN5pgEAsQ6WZAt3Yux4 eXsr0VXujlxWXyBAPIynJobltVBPeQM= =fzXq -----END PGP SIGNATURE----- --=passwd_Ebola_TIE_Shell_virtual_Listeria_NBIC_bemd_LUK_LLNL=Shelter-i-- From nobody Sun Feb 28 11:25:20 2021 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 9BA313A1B2B for ; Sun, 28 Feb 2021 11:25:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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=gnupg.org 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 GvxytYtDMTmO for ; Sun, 28 Feb 2021 11:25:15 -0800 (PST) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (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 C99873A1B29 for ; Sun, 28 Feb 2021 11:25:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnupg.org; s=20181017; h=Content-Type:MIME-Version:Message-ID:Date:Subject:To:From: Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=drDYprzok2A7IspULN/ZrJn7CnAta71+vjZ/C1fbfoU=; b=GhdbPYu/ZMrzMsn3YeENQdk41T Aj4wfZUZfcN1WtfOfq39PcAPRBewnJrDqn9q7gS7iwQHIKAi2qWb4ZpPhxexXyVcBQ38YOFv/7pkr 7QawI1aacHWJM11O1OL0KPNPebSsnHmtVOSffkkzPHwdTFgGHCY7Z2xpZHfrNJz2IuGM=; Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1lGRgh-00044F-OB for ; Sun, 28 Feb 2021 20:25:07 +0100 Received: from wk by wheatstone.g10code.de with local (Exim 4.92 #5 (Debian)) id 1lGRf1-00084C-73 for ; Sun, 28 Feb 2021 20:23:23 +0100 From: Werner Koch To: openpgp@ietf.org Organisation: GnuPG e.V. X-message-flag: Mails containing HTML will not be read! Please send only plain text. Mail-Followup-To: openpgp@ietf.org Date: Sun, 28 Feb 2021 20:23:16 +0100 Message-ID: <877dms9eu3.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=Planet-1_MP5K-SD_Artistic_Assassins_Stuck_keyhole_sweeping_brigand=H"; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: [openpgp] OCB statement from Rogaway 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, 28 Feb 2021 19:25:18 -0000 --=Planet-1_MP5K-SD_Artistic_Assassins_Stuck_keyhole_sweeping_brigand=H Content-Type: multipart/mixed; boundary="=UHF_quiche_CATO_Irish_Republican_Army_NSG_CIO_National_preparedness=" --=UHF_quiche_CATO_Irish_Republican_Army_NSG_CIO_National_preparedness= Content-Type: text/plain Hi! I think this is important for us. The statement from Phil Rogaway may allow us to have OCB as a MUST implement mode and degrade EAX to a MAY implement mode. Salam-Shalom, Werner --=UHF_quiche_CATO_Irish_Republican_Army_NSG_CIO_National_preparedness= Content-Type: message/rfc822 Content-Disposition: inline Return-path: Envelope-to: wk@wheatstone.g10code.de Delivery-date: Sun, 28 Feb 2021 03:35:06 +0100 Received: from uucp by wheatstone.g10code.de with local-rmail (Exim 4.92 #5 (Debian)) id 1lGBvG-0006zK-LC for ; Sun, 28 Feb 2021 03:35:06 +0100 Received: from green.metzdowd.com ([2001:470:30:84:e276:63ff:fe62:3500]) by kerckhoffs.g10code.com with esmtps (Exim 4.89 #1 (Debian)) id 1lGBuj-0006mP-Hf for ; Sun, 28 Feb 2021 03:34:33 +0100 Received: from green.metzdowd.com (localhost [IPv6:::1]) by green.metzdowd.com (Postfix) with ESMTP id 9D6FE1F6A for ; Sat, 27 Feb 2021 21:34:31 -0500 (EST) X-Original-To: cryptography@metzdowd.com Delivered-To: cryptography@metzdowd.com Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) by green.metzdowd.com (Postfix) with ESMTPS id 26C831A2 for ; Sat, 27 Feb 2021 14:37:41 -0500 (EST) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.43/8.16.0.43) with SMTP id 11RJXuNh012990 for ; Sat, 27 Feb 2021 19:37:33 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=RcYb3nKE0myJvyyWKMs/nrnLDl3npVHSck0t+8J6hgU=; b=UEC218cWijDeC37whWLyVstGomLV7Wmrir3+eLu5WuPL4y/j+Efm/dHlMIeJy4PlfyRs 52JryNnOEIMfVw1dupHV1BPd9jGnvD12gm2IVquGPqeWDAxStjbiIfoLt+fbfQCer0zb ZxGi1CNUp/uuYrz91TZC3z+B21jODJPnzFD5ol+cCgApegza62GpJmA4VQoMsUCTFoTo RxDhnNYKzSq43DuY3kL9Y4lu4/IJ/gPF4DIa5iourFdwNHBsndPlvACo+oGzoET6/uvb 3nVc4cO5/jYI2/lPQehNb9vdcS1h+bAZ4YmirmnKyrKpPSIp5YV+axcCrpGdsZnP6Qsh gQ== Received: from prod-mail-ppoint4 (a72-247-45-32.deploy.static.akamaitechnologies.com [72.247.45.32] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 36yfcca0hg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Sat, 27 Feb 2021 19:37:33 +0000 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.43/8.16.0.43) with SMTP id 11RJZ2YQ028141 for ; Sat, 27 Feb 2021 14:37:32 -0500 Received: from email.msg.corp.akamai.com ([172.27.165.116]) by prod-mail-ppoint4.akamai.com with ESMTP id 36yja34hpr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Sat, 27 Feb 2021 14:37:32 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.165.119) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.165.122) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sat, 27 Feb 2021 13:37:31 -0600 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.165.119]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.165.119]) with mapi id 15.00.1497.010; Sat, 27 Feb 2021 13:37:31 -0600 To: "cryptography\@metzdowd.com" Thread-Topic: Direct public confirmation from Dr. Rogaway Thread-Index: AQHXDT/8kDPUFyEVRka2IUQU2inQpg== Date: Sat, 27 Feb 2021 19:37:30 +0000 Message-ID: <2B8D58F3-0565-48CE-AB7D-7A293050F017@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.46.21021202 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.118.139] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-02-27_13:2021-02-26, 2021-02-27 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 spamscore=0 phishscore=0 bulkscore=0 adultscore=0 mlxscore=0 mlxlogscore=739 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2102270166 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-02-27_13:2021-02-26, 2021-02-27 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 clxscore=1015 priorityscore=1501 adultscore=0 mlxlogscore=662 impostorscore=0 malwarescore=0 suspectscore=0 bulkscore=0 spamscore=0 mlxscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2102270166 X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 72.247.45.32) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint4 X-Mailman-Approved-At: Sat, 27 Feb 2021 21:32:25 -0500 Subject: [Cryptography] Direct public confirmation from Dr. Rogaway X-BeenThere: cryptography@metzdowd.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: The Cryptography and Cryptography Policy Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: "Salz\, Rich via cryptography" Reply-To: "Salz\, Rich" Errors-To: cryptography-bounces+wk=gnupg.org@metzdowd.com Sender: "cryptography" X-Sender-Host: green.metzdowd.com MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=NBIC_SSL_Attorney_General_strategic_Croatian_al-Qaida_Mitigation=Cen" --=NBIC_SSL_Attorney_General_strategic_Croatian_al-Qaida_Mitigation=Cen Content-Type: multipart/alternative; boundary="=Skipjack_Listeria_Gangs_UHF_Scammers_IB_Extremism_M-14_UNSCOM_TDYC=M" --=Skipjack_Listeria_Gangs_UHF_Scammers_IB_Extremism_M-14_UNSCOM_TDYC=M Content-Type: text/plain; charset=utf-8 Content-Disposition: inline https://mailarchive.ietf.org/arch/msg/cfrg/qLTveWOdTJcLn4HP3ev-vrj05Vg/ : I can confirm that I have abandoned all OCB patents and placed into the public domain all OCB-related IP of mine. While I have been telling people this for quite some time, I don't think I ever made a proper announcement to the CFRG or on the OCB webpage. Consider that done. I hope people will use the scheme to do positive things. phil --=Skipjack_Listeria_Gangs_UHF_Scammers_IB_Extremism_M-14_UNSCOM_TDYC=M Content-Type: text/html; charset=utf-8 Content-ID: <32E9C672BA24E54789FBE9839950476C@akamai.com>

https://mailarchive.ietf.org/arch/msg/cfrg/qLTveWOdTJcLn4HP3ev-vrj05Vg/ :

 

I can confirm that I have abandoned all OCB patents

and placed into the public domain all OCB-related IP of mine.

While I have been telling people this for quite some time, I don't

think I ever made a proper announcement to the CFRG or on the

OCB webpage. Consider that done.

 

I hope people will use the scheme to do positive things.

 

phil

--=Skipjack_Listeria_Gangs_UHF_Scammers_IB_Extremism_M-14_UNSCOM_TDYC=M-- --=NBIC_SSL_Attorney_General_strategic_Croatian_al-Qaida_Mitigation=Cen Content-Type: text/plain Content-Disposition: inline _______________________________________________ The cryptography mailing list cryptography@metzdowd.com https://www.metzdowd.com/mailman/listinfo/cryptography --=NBIC_SSL_Attorney_General_strategic_Croatian_al-Qaida_Mitigation=Cen-- --=UHF_quiche_CATO_Irish_Republican_Army_NSG_CIO_National_preparedness= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable =2D-=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=UHF_quiche_CATO_Irish_Republican_Army_NSG_CIO_National_preparedness=-- --=Planet-1_MP5K-SD_Artistic_Assassins_Stuck_keyhole_sweeping_brigand=H Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQSHd0YfKgdOvEgNNZQZzByeCFsQegUCYDvtpAAKCRAZzByeCFsQ eieHAQDlVgWGvpXuwx5nlkxZW91D4y3c2yBaoxlsiqqev8DTbAD/ZcxWQ0QNttuy wAXYyN+9jIxjvMh6dtYvlvuZpE3Kxws= =ZCgI -----END PGP SIGNATURE----- --=Planet-1_MP5K-SD_Artistic_Assassins_Stuck_keyhole_sweeping_brigand=H-- From nobody Sun Feb 28 11:26:40 2021 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 70ADC3A1B30 for ; Sun, 28 Feb 2021 11:26:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, 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 (3072-bit key) header.d=crustytoothpaste.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 e_ROBaxPuxhL for ; Sun, 28 Feb 2021 11:26:38 -0800 (PST) Received: from injection.crustytoothpaste.net (injection.crustytoothpaste.net [192.241.140.119]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC6AB3A1B2F for ; Sun, 28 Feb 2021 11:26:37 -0800 (PST) Received: from camp.crustytoothpaste.net (unknown [IPv6:2001:470:b978:101:7d4e:cde:7c41:71c2]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by injection.crustytoothpaste.net (Postfix) with ESMTPSA id 8A39D60DF4 for ; Sun, 28 Feb 2021 19:26:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crustytoothpaste.net; s=default; t=1614540396; bh=2XXsHJAMtRAdM0pXDqGSL+83aI3+AYxjIgPP67m1Rf4=; h=Date:From:To:Subject:References:Content-Type:Content-Disposition: In-Reply-To:From:Reply-To:Subject:Date:To:CC:Resent-Date: Resent-From:Resent-To:Resent-Cc:In-Reply-To:References: Content-Type:Content-Disposition; b=kZQrB4WKApBcb4lM6cDQNS8hT6EBtOh5a+bxYc9sFgI8o0YAb36I+bbgq1B8EZ9dh iQ9pPJeVkd2zSNfrjLwDOjWXpOV7waHA+DQIX3Ooc0OPedw+T9RbuzqrCfXCREQZK1 oZIj9ywaJ2N7seG2PeNL2wt4sLRM5SY9O9fBoibQaKgSe+M3ar7yV9ebXOoi5u84ha 2IbFCVkv5arGjQZnXhKY2uKlMakebrgyrGOTTh0r4aBtTG/20iGG06czfyDevFpWkl J8gUIB0xHWoUK+tX/Z50/tbFbBcPczXvY5R0OqzAhBXO+kc90vk0KIhkSPfzZ7NQUO 9SfRSip5Sv33vHH6CCGBFoXqXNZbYz+0XDUykekS5LYW9G9cS1r/n9OekthBj690ET SndKglpmfv23YwGoGZLIlS4ZIFzcqtLM+yMx0W1G/5rGGvSiBOznv8hycSi2NdNgva S6AUhjliSVqD/S+0XHpR4ZgSCurGaG71vEy6d0GIWZe4plSX869 Date: Sun, 28 Feb 2021 19:26:32 +0000 From: "brian m. carlson" To: openpgp@ietf.org Message-ID: References: <87ft1g9goo.fsf@wheatstone.g10code.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="XG0ThXIv5p7QDXhD" Content-Disposition: inline In-Reply-To: <87ft1g9goo.fsf@wheatstone.g10code.de> User-Agent: Mutt/2.0.5 (2021-01-21) Archived-At: Subject: Re: [openpgp] RSA-PSS and RSA-OAEP for v5 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, 28 Feb 2021 19:26:39 -0000 --XG0ThXIv5p7QDXhD Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2021-02-28 at 18:43:19, Werner Koch wrote: > On Sat, 27 Feb 2021 23:53, brian m. carlson said: >=20 > > I'm interested in seeing if we can require v5 SKESK packets with RSA use > > RSA-OAEP with SHA-256 and MGF1-SHA-256 and require that v5 signatures >=20 > That would add a lot of additional complexity for no good reason because > RSA will over short or long anyway be replaces by 25519 and 448. I believe that the current plan was to make RSA must-implement, but maybe I'm misremembering. If we instead made EdDSA, ECDH, and Curve25519 must-implement and RSA optional, then this becomes clearly less important. If we continue to suggest in any way that people use RSA keys, then we need to consider this. If we make RSA keys completely optional, then it's probably fine to just omit this. > > I realize this requires implementers to add additional code, but I think > > the increase in security is worth it given the number of CVEs we've seen > > for padding vulnerabilities. We can tell implementers to avoid this >=20 > and replace them with bugs in the way more complext PSS and OAEP. I'm not sure how these wouldn't be a problem anyway given crypto libraries already implement them. Presumably such bugs would have already surfaced in their existing usage and interoperability. For example, any crypto library used by TLS 1.3 almost certainly implements RSA-PSS correctly because otherwise it wouldn't interoperate, since all RSA signatures in CertificateVerify use PSS. S/MIME already supports RSA-OAEP, so presumably that's already correctly implemented as well. Are you suggesting that existing implementations have other latent interoperability bugs that aren't exercised by TLS and S/MIME? Or that there's something special about OpenPGP that makes it more likely to be a problem here? Or that implementers are likely to avoid using well-known existing cryptographic implementations in favor of their own? > I see no reason for it and doubt that this can be viewed as part of the > WG's old and new charter. The charter specifies this: - Revision of mandatory-to-implement algorithm selection and deprecation of weak algorithms I think it's very clear, based on a history of CVEs, that as practically implemented, PKCS #1 padding is weak compared to PSS and OAEP. We should specify padding algorithms that are not weak as part of MUST and SHOULD algorithms. --=20 brian m. carlson (he/him or they/them) Houston, Texas, US --XG0ThXIv5p7QDXhD Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.2.27 (GNU/Linux) iHUEABYKAB0WIQQILOaKnbxl+4PRw5F8DEliiIeigQUCYDvuZwAKCRB8DEliiIei gXIHAP95+2vxxrrAirArhyIGR0GDaRafkI+HTW/pDbBkXSRpsgD9EPZssAUtbANu ruaseeMGql0/4tKUDD1qzngZORqpjQw= =5aOJ -----END PGP SIGNATURE----- --XG0ThXIv5p7QDXhD-- From nobody Sun Feb 28 11:31:43 2021 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 1AEAF3A1B44 for ; Sun, 28 Feb 2021 11:31:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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=pass (3072-bit key) header.d=crustytoothpaste.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 LmHQYBzD2PWd for ; Sun, 28 Feb 2021 11:31:40 -0800 (PST) Received: from injection.crustytoothpaste.net (injection.crustytoothpaste.net [192.241.140.119]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE2733A1B42 for ; Sun, 28 Feb 2021 11:31:40 -0800 (PST) Received: from camp.crustytoothpaste.net (unknown [IPv6:2001:470:b978:101:7d4e:cde:7c41:71c2]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by injection.crustytoothpaste.net (Postfix) with ESMTPSA id CD8C360DF4 for ; Sun, 28 Feb 2021 19:31:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crustytoothpaste.net; s=default; t=1614540700; bh=p5Fa0Y4PU+C0HXXuBqu0o7G8jSMGd9am3jVfUkCJMxQ=; h=Date:From:To:Subject:References:Content-Type:Content-Disposition: In-Reply-To:From:Reply-To:Subject:Date:To:CC:Resent-Date: Resent-From:Resent-To:Resent-Cc:In-Reply-To:References: Content-Type:Content-Disposition; b=E1sw5uk+nEhntePV5feHzk8xGzWSFv2VYDAfLicxBJftiu8V3CtjjADdynAHBjjAa QLTrzJKbuvR43Yc9EhOT67vo9xAV0xFhql+26xOI4yeBpxmj0KW/AtqR72EMSJx//s y+hBwweSnvRnptQ8NJ8V9if5qw7bqgHaXzjG3tay40lwtZBOOOpykJC9vbFYuA0rdp 9Wm2ZMsIVlgIOEZqUlyDJElgCUve/9L0KLvlVE5yBioV0fgQNFyvHDBiMO21MKrM4W PG+JNnDFvRfihU/Fv0N7Xoeg3FOie8aB4NSlPidssjR2A549UBxp1m8NV0qkbtcrcy ifkutc9cF2xJPNFBMsjuw0pBsrWPbRpyM3jRmRyq1hcR2E1fDB6VAPvTiNbnXQdKgP qhxjbKRnjfFDGdxBStyQqrEFITbH+y6JE60gA2d9TV/G1eRpUe5XdJVY3Sk6KRCDci gXOYBADmVbUhltazip19UbIlULkxy/ZWomUj8hkHIPTWC37qfCe Date: Sun, 28 Feb 2021 19:31:34 +0000 From: "brian m. carlson" To: openpgp@ietf.org Message-ID: References: <877dms9eu3.fsf@wheatstone.g10code.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="XMCEgAxU4tXGeFVQ" Content-Disposition: inline In-Reply-To: <877dms9eu3.fsf@wheatstone.g10code.de> User-Agent: Mutt/2.0.5 (2021-01-21) Archived-At: Subject: Re: [openpgp] OCB statement from Rogaway 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, 28 Feb 2021 19:31:42 -0000 --XMCEgAxU4tXGeFVQ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2021-02-28 at 19:23:16, Werner Koch wrote: > Hi! >=20 > I think this is important for us. >=20 > The statement from Phil Rogaway may allow us to have OCB as a MUST > implement mode and degrade EAX to a MAY implement mode. Yes, I saw that as well. I'm happy to even drop EAX in favor of OCB now that we don't have the patent concerns. --=20 brian m. carlson (he/him or they/them) Houston, Texas, US --XMCEgAxU4tXGeFVQ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.2.27 (GNU/Linux) iHUEABYKAB0WIQQILOaKnbxl+4PRw5F8DEliiIeigQUCYDvvlgAKCRB8DEliiIei gdPSAP9TPi2JM5ctm3HOFgeJ0rqrdobjUQm8FBsmIJ2QM7Y9qQEA7VqVihVtAD8O WLR9QmuZVH5fzDiL9I7ow90MJnK+Cww= =oUDO -----END PGP SIGNATURE----- --XMCEgAxU4tXGeFVQ-- From nobody Sun Feb 28 11:47:25 2021 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 904A53A1B73 for ; Sun, 28 Feb 2021 11:47:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, 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=cs.tcd.ie 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 j41tNWHRQ-bW for ; Sun, 28 Feb 2021 11:47:21 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2E273A1B71 for ; Sun, 28 Feb 2021 11:47:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2E894BE3E; Sun, 28 Feb 2021 19:47:18 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6O5MXSYVuOz3; Sun, 28 Feb 2021 19:47:16 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 92C54BE2F; Sun, 28 Feb 2021 19:47:16 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1614541636; bh=5RHZl1FyETK9OkSm2BrCOAO4oJ7n7Y8yZb4RHh6jWDo=; h=Subject:To:References:From:Date:In-Reply-To:From; b=lXmLf5clA56BQxuHsnzhFBY0d7C/9GX5uq7H1FGf0M1gZ/F2DW0CLIkB9SPXETPzD skFW0uNhpy9Cba4PnUj/d1oTEDPwlYBgmafO/Np8wrzq2YXX197k+4iyi9fGYFuD/b cMjuzA9vP+b/rNRWQ7e/MMSoy2droATWZo+taoe4= To: "brian m. carlson" , openpgp@ietf.org References: <87ft1g9goo.fsf@wheatstone.g10code.de> From: Stephen Farrell Message-ID: <6a1649f1-1b64-0a44-7a7d-07dae7b0dc20@cs.tcd.ie> Date: Sun, 28 Feb 2021 19:47:15 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="OKuKaaXt8DsqH3Oxfu0QTXs2BuYtsYgDv" Archived-At: Subject: Re: [openpgp] RSA-PSS and RSA-OAEP for v5 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, 28 Feb 2021 19:47:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OKuKaaXt8DsqH3Oxfu0QTXs2BuYtsYgDv Content-Type: multipart/mixed; boundary="50iqTJcy566ptwZuam0RiobjVo9gWAgA4"; protected-headers="v1" From: Stephen Farrell To: "brian m. carlson" , openpgp@ietf.org Message-ID: <6a1649f1-1b64-0a44-7a7d-07dae7b0dc20@cs.tcd.ie> Subject: Re: [openpgp] RSA-PSS and RSA-OAEP for v5 References: <87ft1g9goo.fsf@wheatstone.g10code.de> In-Reply-To: --50iqTJcy566ptwZuam0RiobjVo9gWAgA4 Content-Type: multipart/mixed; boundary="------------505126075C72E0537FCAF305" Content-Language: en-US This is a multi-part message in MIME format. --------------505126075C72E0537FCAF305 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hiya, On 28/02/2021 19:26, brian m. carlson wrote: >=20 > I think it's very clear, based on a history of CVEs, that as practicall= y > implemented, PKCS #1 padding is weak compared to PSS and OAEP. FWIW, my impression is that that is not clear. Quite a few people do have that position for sure, but equally, the views expressed by e.g. Werner and Peter Gutmann also seem fairly commonly held afaics. (As chair) would it be worthwhile pushing this question off for a while? It may become easier to handle later on - or even if it's no easier later, it still might be better to postpone the bun fight for a bit:-) If pushing this to later made sense, I guess creating an issue in gitlab would be the thing to do so's we don't lose track of it. (Apologies if someone did that already, I didn't go check just now.) S. --------------505126075C72E0537FCAF305 Content-Type: application/pgp-keys; name="OpenPGP_0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="OpenPGP_0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh5= Cg8 gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+QtaFq= 978 CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGu= D/Q 9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4= tNn cejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqB= wV+ 4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghVB5Uir= 1GC YChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5FmBKjG7cGcpBGmWav= ACY Ea7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK7uB7E7HlVE1IM1zNkVTYYGkKreU8D= VQu 8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER= 8la 5lsEEPbU/cDTcwARAQABzSFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT7CwX0EE= wEI ACcFAlo9UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qGC= xAA pYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKkrRl8beJ7j1CWX= Az9 +VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBrsjC+1uULaTU8zYEyET//GOGPL= F+X +degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZsdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4= g1U QAcCA4xlucY8QkJEyCrSNGpGnvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advre= k3U P71CKxpgtPmkd3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2= niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBGFEZYJGuaL= 4Nw tBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wVN3p46RyBQuXqJV8ccE11m= 6vt ZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8vovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7= +8A CcxRU3b9Ihd7WYjJ+pQPCoWYKozvtEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQ= LvC wFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8= rpK o9OkCz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqmuKhYr= qJs CcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMTAAr2p7PSaHgo+hIVa= W/r KSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQIAQlFxtgvOqpPOZNzeKBa/+KbE8TG= gMW rkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3u= rqR 1cLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/= 0A9 J9nrnBMqZpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5hc= JBD EN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPpMyEs04zvsbsl4= vrp 2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouBur45UDKTZkMZrr9FGrtkyXCGA= xvK dcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQyoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaK= xlf tjO+Bj3Jj73Cr5eqej3qB5+V4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjg= Uky o1s4vjUOY8DyI+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIO= aHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg2YVf0izSp= yyz JeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc/MoSjTS65vNWbpzONZWMZ= uLE FraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5w= sDc BBABCgAGBQJbxcflAAoJEGo7ETk8pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer= 3UM TVQg10vpa7pmqOGhjIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCP= jt5 uAxmbBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6+uWyK= 171 RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh5EQsn0pIh9wZIAbMR= Lpg RKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6KLChn2aEHQd+PdY1GBpZEcmNEUPuov= wza tM0h64hCzTm41eDqRfihZVBT7TbfXQnv8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0= zG3 6VdZTQF7TF/4Lz7/3cJ56jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQ= eah r2ez3DRBg3qsHEjBV80yU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQ= GNz LnRjZC5pZT7CwYAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o= 3cC GQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKo= w5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3h= Rcs RvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmC= Y98 iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jd= h2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4= EIk CXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZ= DIJ pdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelceZTzC4= tvy a7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4= ul3 qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIc= G9g ivQd8MxYNAbNYgSPtkbhZ8TCwFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGt= w/r 1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZ= Jaf 3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u1= 4Q0 7+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGf= qtu Sw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/C= gHw 26293tlve2Q6UTrmHxP5U22DlsLBfQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKC= wIE FgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eL= rfb e5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWF= etu O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8= v39 +qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr= 1oD 3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Pr= m2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yoby= y/A UOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxO= jao P0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPkhnwYz= leL Z7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC= 2X4 pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jsLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g= 1MS BQJbtySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/l//34= YT0 auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX4Iec8+9ot6tIVg4sb= edD Sgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo7kD9FDHCjRN8XfhHQ4Q9cYyt06uF3= 1qG /aumgWYC9geCGgAwiHgwxNYb9GoJ0iZjCROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcV= YW6 R0a3Ra8KudX+nt25H5DRGd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg= 4Im VOLGqsUgVm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGxm= qyH eLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88zllsqhZAFQjNx= qnk SzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2EtMBhgojWwrGMvdLN6X3mnzNJ= Esc YyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezIz60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n= 2Hw xyRL5dVMyMdyQmntubbctfqrZ0tIwsDcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4F= eIY jlIXGghFWzsB4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8E= AuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwlvpNwiiBr4= 2AY R751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGkbPlPkztahsFqktgacIgXH= X5v aT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joBp823L7r5KfpqWTPpSCzVstQKZUGmmoE1q= Csw Y/Ud5wvp9SccpIILkRXj0rZRtfnE5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tq= yA4 3niUMy2n6q690of3berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7m= Eer 0rCL3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP80uU3RlcGhlbiBGYXJyZWxsI= Dxz dGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPsLBfQQTAQgAJwUCWj1RWgIbAwUJCZQmAAULC= QgH AgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZ= i0B igofkbcGfdhJyMSs19C0dhvncrAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhn= i9g OJLlUpXViQtgrlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTy= sIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1n= 66v xxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIqhCljJ9x40Fkn/= 3r2 BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjM= YtU N1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr= 5iW XO3qx1HtEiGEqkporMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/= zek ZyXRdS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78b= a0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdMLAXAQQAQgABgUCWj1SoAAKCRAvP= Ic2 gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06TQgW5wsqtNcrwn81yZTq6= XE6 i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I1= 16u /HwA9/FXsPo5isbh4ZqD4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/J= G9a SSYvk3lznNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IW= OMq N2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBwsFzBBABCAAdFiEEfhcKBFyEz= 0YO K3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0H6FJ23A9Ftpy+aXZ4= vYl zkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQOJSSHbQ49BFRLwb1J/wBZG4bbmrkLx= nNb KDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrhB+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+= 5HN HltSL3DF1c2fFOf2JrgBKVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq= 4hn l5+VC/48ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPwn= Zbg JO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2MvoolsW08FiZh3Ej4d= nJj j25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJlMbVLrMo2GXeo03OzNyvbs+u8= WLI aGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilc= dPC Yk4BsOlzpwwO74hNG7iyl0KdAlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTX= o4+ Ira2JUErL2cYzQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YvCwNwEEAEKAAYFAlvFx+UACgkQajsRO= Tyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04fZ2Ry4nF9= hZM 0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4NkC9JMpecfq62/teOAU2e5= P3f WYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOosp= cL2 lJTmy8e3r79R24hPlSB4LDe0wEN8AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbk= etP GRmWvx5xUvb2ALFBBdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3= zRq k3mttto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+QgevYE0= 20q pKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7vxflUEDuzsFNBFo9U= DIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4HJee+R9+5x= /nL PCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHE= hOV fBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1D= VI9 DYo2D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbT= uW/ eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yD= aWT 3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDPck/Q6= 1df mr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8= MAv 2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOA= HZR 5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQo= qj1 gwARAQABwsFlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6= Mas qXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOxi= RkM dNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB= ++/ KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lX= xMD rvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrf= ZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN= 2OE 0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHT= zcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7= IKP 3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeW= Iys s6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3D40Nd -----END PGP PUBLIC KEY BLOCK----- --------------505126075C72E0537FCAF305-- --50iqTJcy566ptwZuam0RiobjVo9gWAgA4-- --OKuKaaXt8DsqH3Oxfu0QTXs2BuYtsYgDv Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAmA780MFAwAAAAAACgkQWrL68XsXK+qf qhAAiuUpk5XMz8ACZJuTvBM3yblrWwzmljYY16zKMWPEeQbaY1LazTMXssQ7mM9sFk3a0XvHnTMr NrJ/lqjmQ3f5ulffLbncGIOhANOp7FzXP7aDoEPfdS0QeQn2YTnSu/F56f0ER2nMfrAmc6vb6wXl yiMT2dd3DNRfj7Gx61SrZYixbtVU0aRW8bKhcr2BWpl3WN527bl4hNmgKm1xCjNbCJA7u53SrQK0 gAtB5/GZTEoCU6+3SlcwN/u9AwXkbgus+nPPTgswcqlgWsGn4Oa+28dFfp6+2ChV5yNLkBdgwADp V/bJmYRhNsYIntjm2KvVsLj+TRzujDlq9xIRS4/5b5+VwL15E6fmjRcErQ2atOAEQjoN5Vlx8Glo Nm6fAyrrd5pAd0YCwTn7IZMJWTc6PklN/jZjwkNTfAdQWctnSMO1rX+EhX3Z8VRAWSjOqcinqQ33 /tB/fEUWJQoZ+vVuEQDBf6/lHW9qDiANep9eL6fPzpkvHg1lwmhE89taplv5G/yRBymNuGhpHEij 2SBESt+YUG6bebJHbMEKur/W4e+9OX+131ngb9E3h2DLyNX/GBoI48Si/UB9oCAaEdT5yzDrVHTC as6whAmLmwZ30kwS1oJCvm0tyKBIZE2yueX6D9sQ95tUi/rfX23ZTLdeQPS3+ckISu0ta1aowm4n Y6o= =7Iwn -----END PGP SIGNATURE----- --OKuKaaXt8DsqH3Oxfu0QTXs2BuYtsYgDv-- From nobody Sun Feb 28 12:06:19 2021 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 7052A3A1BAC for ; Sun, 28 Feb 2021 12:06:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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=pass (3072-bit key) header.d=crustytoothpaste.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 h6791yPamDqF for ; Sun, 28 Feb 2021 12:06:16 -0800 (PST) Received: from injection.crustytoothpaste.net (injection.crustytoothpaste.net [192.241.140.119]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F092E3A1BAB for ; Sun, 28 Feb 2021 12:06:15 -0800 (PST) Received: from camp.crustytoothpaste.net (unknown [IPv6:2001:470:b978:101:7d4e:cde:7c41:71c2]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by injection.crustytoothpaste.net (Postfix) with ESMTPSA id 68CB160DF4 for ; Sun, 28 Feb 2021 20:05:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crustytoothpaste.net; s=default; t=1614542744; bh=HUrj16U3kX9OOXpCi3yUvsHEn55EoDlfSPtGiZd6zHc=; h=Date:From:To:Subject:References:Content-Type:Content-Disposition: In-Reply-To:From:Reply-To:Subject:Date:To:CC:Resent-Date: Resent-From:Resent-To:Resent-Cc:In-Reply-To:References: Content-Type:Content-Disposition; b=aC+dHDG8b1AH/0H/DvCCvP89e2Ie0l/fTya4/p59SLPwP4bIlVv9PhYHIHusljzAu kDGInlMtkclVbWP2uaqYhZzKUV7NHh8+Zo06E9xYj6ErP71n0DRhTTMCRGOYHtRTEN Zk1OvFn/P4QIt0GQMWwsG4dDnHFdIXG3jD1T7KaXSRzD8XCOFAuKBBX2FsSYCVQZ/p /zrLt3ro4edQ1dMf9zSc7dhtKY1RMcurKlmeLGgxplAjIqxT7vXfUNnNBQ8/bq2DID 1WghM6qhxfWwf2gDiaIzCUkDtC42roFC7E7mCZcQNL6YdJjJCWdhZSQKZfbBs3y+wc +j5gBVTPUJiYZBYXoabtAvwegQmGXhBflogMaMeRF+5KEhNxPpY6U5NONFwNcZ7N3h WdXI3aMwN/ELlaX+SyHwLSFIyMgDYE7v0M59Gb/48cSBJK82GtSxGjm54rP//MmySg FHoBcSE3GZEc5JR7QyPw6rg7Ph9HXzyjMpew52VvPo0iSLlq4FM Date: Sun, 28 Feb 2021 20:05:39 +0000 From: "brian m. carlson" To: openpgp@ietf.org Message-ID: References: <87ft1g9goo.fsf@wheatstone.g10code.de> <6a1649f1-1b64-0a44-7a7d-07dae7b0dc20@cs.tcd.ie> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="AEWwMHIsJdDHYyiM" Content-Disposition: inline In-Reply-To: <6a1649f1-1b64-0a44-7a7d-07dae7b0dc20@cs.tcd.ie> User-Agent: Mutt/2.0.5 (2021-01-21) Archived-At: Subject: Re: [openpgp] RSA-PSS and RSA-OAEP for v5 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, 28 Feb 2021 20:06:17 -0000 --AEWwMHIsJdDHYyiM Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2021-02-28 at 19:47:15, Stephen Farrell wrote: >=20 > Hiya, >=20 > On 28/02/2021 19:26, brian m. carlson wrote: > >=20 > > I think it's very clear, based on a history of CVEs, that as practically > > implemented, PKCS #1 padding is weak compared to PSS and OAEP. >=20 > FWIW, my impression is that that is not clear. Quite a few > people do have that position for sure, but equally, the views > expressed by e.g. Werner and Peter Gutmann also seem fairly > commonly held afaics. >=20 > (As chair) would it be worthwhile pushing this question off > for a while? It may become easier to handle later on - or > even if it's no easier later, it still might be better to > postpone the bun fight for a bit:-) Sure, I'm happy to defer this for the moment. We don't need to make a decision immediately, and considering that I just proposed this yesterday, we can definitely let folks think about it for a while before coming back to it. > If pushing this to later made sense, I guess creating an > issue in gitlab would be the thing to do so's we don't lose > track of it. (Apologies if someone did that already, I didn't > go check just now.) I've created one so we don't lose track of it: https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/22 --=20 brian m. carlson (he/him or they/them) Houston, Texas, US --AEWwMHIsJdDHYyiM Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.2.27 (GNU/Linux) iHUEABYKAB0WIQQILOaKnbxl+4PRw5F8DEliiIeigQUCYDv3kwAKCRB8DEliiIei gaeoAQD3LmA+lZvBrofoeWGSAO+CIH75f7GtHqd3tJAH2x+TVwD8Dw6FytS3CpbL GiPkcg+/hetAcLo3jYZXF0zDNFmnDAM= =gcdI -----END PGP SIGNATURE----- --AEWwMHIsJdDHYyiM-- From nobody Sun Feb 28 12:10:24 2021 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 208543A1BB4 for ; Sun, 28 Feb 2021 12:10:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.001, 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=cs.tcd.ie 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 wJ706xTKhzDH for ; Sun, 28 Feb 2021 12:10:21 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D98793A1BB3 for ; Sun, 28 Feb 2021 12:10:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BF8B5BE3E; Sun, 28 Feb 2021 20:10:18 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UmwGr3wrfzN4; Sun, 28 Feb 2021 20:10:17 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id AE2DEBE2F; Sun, 28 Feb 2021 20:10:16 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1614543016; bh=hJTQBrTx4eeR7ovdxGVfCQLVacTr/PXJgLWrKzFxsDc=; h=Subject:To:References:From:Date:In-Reply-To:From; b=IHxgd6bSUb2U7159bESPs/s659MyruNvHFM5JgVb2arTb3VrUfwHiwvvykKgq5F6u Zl/8O/0VFmzYTokx3xbmDQz2s9iPXKTKIYet998Ua4gOJxTBrDNAWfEgeuMZBBgGDH x3odpPVDy8nwqRTvWxYO8IxVuW2WDJr6VSaJ+k04= To: "brian m. carlson" , openpgp@ietf.org References: <87ft1g9goo.fsf@wheatstone.g10code.de> <6a1649f1-1b64-0a44-7a7d-07dae7b0dc20@cs.tcd.ie> From: Stephen Farrell Message-ID: <4a880a24-9e3c-0832-e48f-28e089150c8e@cs.tcd.ie> Date: Sun, 28 Feb 2021 20:10:15 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ZnxdTeCmkJGIzBIeoFLc9BvX71VxErSmi" Archived-At: Subject: Re: [openpgp] RSA-PSS and RSA-OAEP for v5 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, 28 Feb 2021 20:10:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ZnxdTeCmkJGIzBIeoFLc9BvX71VxErSmi Content-Type: multipart/mixed; boundary="6uGpPKIrCtKjn2Z2vXBCb1OjwrV2FvDx9"; protected-headers="v1" From: Stephen Farrell To: "brian m. carlson" , openpgp@ietf.org Message-ID: <4a880a24-9e3c-0832-e48f-28e089150c8e@cs.tcd.ie> Subject: Re: [openpgp] RSA-PSS and RSA-OAEP for v5 References: <87ft1g9goo.fsf@wheatstone.g10code.de> <6a1649f1-1b64-0a44-7a7d-07dae7b0dc20@cs.tcd.ie> In-Reply-To: --6uGpPKIrCtKjn2Z2vXBCb1OjwrV2FvDx9 Content-Type: multipart/mixed; boundary="------------085D6FB256FD184B9910B337" Content-Language: en-US This is a multi-part message in MIME format. --------------085D6FB256FD184B9910B337 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hiya, On 28/02/2021 20:05, brian m. carlson wrote: > Sure, I'm happy to defer this for the moment. We don't need to make a > decision immediately, and considering that I just proposed this > yesterday, we can definitely let folks think about it for a while befor= e > coming back to it. Great, thanks. Sometimes these things do get easier based on earlier decisions, we'll see. >=20 >> If pushing this to later made sense, I guess creating an >> issue in gitlab would be the thing to do so's we don't lose >> track of it. (Apologies if someone did that already, I didn't >> go check just now.) > I've created one so we don't lose track of it: >=20 > https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/22 Thanks again, S. --------------085D6FB256FD184B9910B337 Content-Type: application/pgp-keys; name="OpenPGP_0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="OpenPGP_0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh5= Cg8 gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+QtaFq= 978 CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGu= D/Q 9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4= tNn cejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqB= wV+ 4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghVB5Uir= 1GC YChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5FmBKjG7cGcpBGmWav= ACY Ea7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK7uB7E7HlVE1IM1zNkVTYYGkKreU8D= VQu 8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER= 8la 5lsEEPbU/cDTcwARAQABzSFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT7CwX0EE= wEI ACcFAlo9UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qGC= xAA pYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKkrRl8beJ7j1CWX= Az9 +VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBrsjC+1uULaTU8zYEyET//GOGPL= F+X +degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZsdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4= g1U QAcCA4xlucY8QkJEyCrSNGpGnvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advre= k3U P71CKxpgtPmkd3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2= niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBGFEZYJGuaL= 4Nw tBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wVN3p46RyBQuXqJV8ccE11m= 6vt ZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8vovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7= +8A CcxRU3b9Ihd7WYjJ+pQPCoWYKozvtEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQ= LvC wFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8= rpK o9OkCz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqmuKhYr= qJs CcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMTAAr2p7PSaHgo+hIVa= W/r KSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQIAQlFxtgvOqpPOZNzeKBa/+KbE8TG= gMW rkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3u= rqR 1cLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/= 0A9 J9nrnBMqZpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5hc= JBD EN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPpMyEs04zvsbsl4= vrp 2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouBur45UDKTZkMZrr9FGrtkyXCGA= xvK dcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQyoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaK= xlf tjO+Bj3Jj73Cr5eqej3qB5+V4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjg= Uky o1s4vjUOY8DyI+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIO= aHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg2YVf0izSp= yyz JeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc/MoSjTS65vNWbpzONZWMZ= uLE FraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5w= sDc BBABCgAGBQJbxcflAAoJEGo7ETk8pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer= 3UM TVQg10vpa7pmqOGhjIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCP= jt5 uAxmbBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6+uWyK= 171 RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh5EQsn0pIh9wZIAbMR= Lpg RKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6KLChn2aEHQd+PdY1GBpZEcmNEUPuov= wza tM0h64hCzTm41eDqRfihZVBT7TbfXQnv8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0= zG3 6VdZTQF7TF/4Lz7/3cJ56jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQ= eah r2ez3DRBg3qsHEjBV80yU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQ= GNz LnRjZC5pZT7CwYAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o= 3cC GQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKo= w5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3h= Rcs RvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmC= Y98 iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jd= h2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4= EIk CXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZ= DIJ pdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelceZTzC4= tvy a7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4= ul3 qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIc= G9g ivQd8MxYNAbNYgSPtkbhZ8TCwFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGt= w/r 1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZ= Jaf 3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u1= 4Q0 7+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGf= qtu Sw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/C= gHw 26293tlve2Q6UTrmHxP5U22DlsLBfQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKC= wIE FgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eL= rfb e5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWF= etu O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8= v39 +qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr= 1oD 3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Pr= m2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yoby= y/A UOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxO= jao P0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPkhnwYz= leL Z7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC= 2X4 pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jsLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g= 1MS BQJbtySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/l//34= YT0 auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX4Iec8+9ot6tIVg4sb= edD Sgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo7kD9FDHCjRN8XfhHQ4Q9cYyt06uF3= 1qG /aumgWYC9geCGgAwiHgwxNYb9GoJ0iZjCROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcV= YW6 R0a3Ra8KudX+nt25H5DRGd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg= 4Im VOLGqsUgVm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGxm= qyH eLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88zllsqhZAFQjNx= qnk SzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2EtMBhgojWwrGMvdLN6X3mnzNJ= Esc YyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezIz60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n= 2Hw xyRL5dVMyMdyQmntubbctfqrZ0tIwsDcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4F= eIY jlIXGghFWzsB4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8E= AuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwlvpNwiiBr4= 2AY R751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGkbPlPkztahsFqktgacIgXH= X5v aT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joBp823L7r5KfpqWTPpSCzVstQKZUGmmoE1q= Csw Y/Ud5wvp9SccpIILkRXj0rZRtfnE5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tq= yA4 3niUMy2n6q690of3berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7m= Eer 0rCL3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP80uU3RlcGhlbiBGYXJyZWxsI= Dxz dGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPsLBfQQTAQgAJwUCWj1RWgIbAwUJCZQmAAULC= QgH AgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZ= i0B igofkbcGfdhJyMSs19C0dhvncrAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhn= i9g OJLlUpXViQtgrlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTy= sIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1n= 66v xxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIqhCljJ9x40Fkn/= 3r2 BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjM= YtU N1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr= 5iW XO3qx1HtEiGEqkporMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/= zek ZyXRdS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78b= a0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdMLAXAQQAQgABgUCWj1SoAAKCRAvP= Ic2 gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06TQgW5wsqtNcrwn81yZTq6= XE6 i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I1= 16u /HwA9/FXsPo5isbh4ZqD4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/J= G9a SSYvk3lznNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IW= OMq N2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBwsFzBBABCAAdFiEEfhcKBFyEz= 0YO K3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0H6FJ23A9Ftpy+aXZ4= vYl zkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQOJSSHbQ49BFRLwb1J/wBZG4bbmrkLx= nNb KDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrhB+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+= 5HN HltSL3DF1c2fFOf2JrgBKVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq= 4hn l5+VC/48ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPwn= Zbg JO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2MvoolsW08FiZh3Ej4d= nJj j25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJlMbVLrMo2GXeo03OzNyvbs+u8= WLI aGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilc= dPC Yk4BsOlzpwwO74hNG7iyl0KdAlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTX= o4+ Ira2JUErL2cYzQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YvCwNwEEAEKAAYFAlvFx+UACgkQajsRO= Tyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04fZ2Ry4nF9= hZM 0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4NkC9JMpecfq62/teOAU2e5= P3f WYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOosp= cL2 lJTmy8e3r79R24hPlSB4LDe0wEN8AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbk= etP GRmWvx5xUvb2ALFBBdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3= zRq k3mttto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+QgevYE0= 20q pKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7vxflUEDuzsFNBFo9U= DIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4HJee+R9+5x= /nL PCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHE= hOV fBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1D= VI9 DYo2D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbT= uW/ eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yD= aWT 3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDPck/Q6= 1df mr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8= MAv 2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOA= HZR 5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQo= qj1 gwARAQABwsFlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6= Mas qXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOxi= RkM dNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB= ++/ KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lX= xMD rvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrf= ZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN= 2OE 0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHT= zcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7= IKP 3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeW= Iys s6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3D40Nd -----END PGP PUBLIC KEY BLOCK----- --------------085D6FB256FD184B9910B337-- --6uGpPKIrCtKjn2Z2vXBCb1OjwrV2FvDx9-- --ZnxdTeCmkJGIzBIeoFLc9BvX71VxErSmi Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAmA7+KcFAwAAAAAACgkQWrL68XsXK+pQ kw//YBlnZ/sCYKZx73Sbk1BcqcvfzH4XYtVMQZUzVOsPuqGkuQm0PwCpGuJ5iI79duN90nK1bKss US+eB0hF7SpTMbi2997Xj8RcgY9SNoyzJMdHtF9aBqR6mNOOIYYpVpon1EOIWrJH+RtkGCwaCP1b sBcWhjV2o4BMyYfkdN62Dwcx9TJo3dLCaeBIuzWpfHxoeWMf7NtL+lIwM2v5SyiKh5ppSUxgMPvy HMSCZp22E5NGH32FFBNe4EMsEzgJUmyLWdKvmSxqa0cgp+aHj0y9p9xIEnbPAMUTI0y07LOgQ1Lu ZwVXLI3QQ/j7bpyb+9ckq81CorPeKTtyGZETTh7mHesA/XNYOSwqkz2x3aZimGeV++yhfDadItQJ i1KI3eI9rcORW+ZxIA47vWEGQlgcu9w6KAa/M9PaCnCFkS+z4YelTWDd8VlB8l4uxBENYnXrYqhG Jp8db9Ggr9PfcYjQUiZSuxly/GLSZi8TkSKzjCPGcu6Roma6beOW58YmVm3oYQGs9p3ResWj801I 1x0SL2exIX97lAS0nWfryx/oh3nrrqoJNsiyIP3+gw0/hhol2nUlLBgrdIVaMwYmt7U6mu5q+x3S F/UXFIuHPzhaImGidxlND8UJAIJ2xRlosqDIC18yYIZ0I04atq9Bvph33909BQ6cS0kFtD50FAHJ z3s= =AVJ5 -----END PGP SIGNATURE----- --ZnxdTeCmkJGIzBIeoFLc9BvX71VxErSmi-- From nobody Sun Feb 28 14:09:10 2021 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 61AF73A086E for ; Sun, 28 Feb 2021 14:09:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[SPF_PASS=-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 H5iUot8zed9c for ; Sun, 28 Feb 2021 14:09:07 -0800 (PST) Received: from mail.direccionemail.com (mail.direccionemail.com [199.195.249.9]) (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 ADD093A085E for ; Sun, 28 Feb 2021 14:09:07 -0800 (PST) Message-ID: <4a4f4ca9aa11c850bfcd5ebde7e3d57f51fdf38a.camel@16bits.net> From: =?ISO-8859-1?Q?=C1ngel?= To: openpgp@ietf.org Date: Sun, 28 Feb 2021 23:09:03 +0100 In-Reply-To: <1614483966879.85613@cs.auckland.ac.nz> References: <7d8bdda1-4e5c-6c10-f3cd-1d191fad595c@nohats.ca> <87h7lzavvc.wl-neal@walfield.org>,<87mtvqcdtk.fsf@fifthhorseman.net> <1614483966879.85613@cs.auckland.ac.nz> Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [openpgp] Sec. Considerations MUST about S2K [was: Re: I-D Action: draft-ietf-openpgp-crypto-refresh-02.txt] 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, 28 Feb 2021 22:09:09 -0000 On 2021-02-28 at 03:46 +0000, Peter Gutmann wrote: > Daniel Kahn Gillmor writes: >=20 > > I'm not sure about this at all. For example, consider a system > > that knows > > that the string is high-entropy ("good key equivalent") -- should > > they be > > prohibited from using Simple or Salted S2K? Is this MUST really an > > interoperability concern as =A76 of RFC 2119 suggests? >=20 > Agreed, but it's a pretty simple fix: >=20 > Where it's likely that a low-entropy secret is being employed, a > compliant > application SHOULD use [...] >=20 > Peter. I would suggest a didactic approach, something like > Simple S2K and Salted S2K specifiers are not particularly secure=20 > when used with a low-entropy secret, such as those typically provided > by users, and implementations SHOULD avoid using these methods on > encryption of both keys and messages. Best regards From nobody Sun Feb 28 17:38:51 2021 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 3BAE53A1243 for ; Sun, 28 Feb 2021 17:38:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.953 X-Spam-Level: X-Spam-Status: No, score=0.953 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.972, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rch3ZCVGCVR9 for ; Sun, 28 Feb 2021 17:38:47 -0800 (PST) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (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 14DFC3A123F for ; Sun, 28 Feb 2021 17:38:46 -0800 (PST) Received: from fews1.riseup.net (fews1-pn.riseup.net [10.0.1.83]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "Sectigo RSA Domain Validation Secure Server CA" (not verified)) by mx1.riseup.net (Postfix) with ESMTPS id 4Dpjb96ZxTzDyP5; Sun, 28 Feb 2021 17:38:45 -0800 (PST) X-Riseup-User-ID: FD1A444321C5B0B5CAEA86A6136EB4931C1366B5824DA086DFB4D02F9E219581 Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews1.riseup.net (Postfix) with ESMTPSA id 4Dpjb93xKvz5wVb; Sun, 28 Feb 2021 17:38:45 -0800 (PST) Date: Sun, 28 Feb 2021 20:38:44 -0500 From: Santiago Torres-Arias To: "brian m. carlson" Cc: openpgp@ietf.org Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="t8jyaA0xz475szGT" Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [openpgp] RSA-PSS and RSA-OAEP for v5 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, 01 Mar 2021 01:38:49 -0000 --t8jyaA0xz475szGT Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Feb 27, 2021 at 11:53:13PM +0000, brian m. carlson wrote: > One of the persistent pieces of feedback about OpenPGP I've received > from folks involved in the security and cryptography fields is that the > PKCS v1.5 algorithms are obsolete. It is well known that many > cryptographic libraries have suffered (and will likely continue, despite > their best efforts, to suffer) from padding vulnerabilities. TLS has > recently added support for RSA-PSS and it's widely preferred over > PKCS1-v1.5. >=20 > I'm interested in seeing if we can require v5 SKESK packets with RSA use > RSA-OAEP with SHA-256 and MGF1-SHA-256 and require that v5 signatures > with RSA use RSA-PSS, with the MGF using the same digest as the > signature. >=20 > Hard-coding SHA-256 as the algorithm for RSA-OAEP means we don't need to > specify it as a parameter, and since it's the must-implement algorithm, > there's no reason an implementation won't support it. Folks that wish > to provide a better than 128-bit security level will use ECDH instead, > since RSA at the 192-bit level (7680 bit keys) is much slower and such > keys are not practically used. >=20 > I realize this requires implementers to add additional code, but I think > the increase in security is worth it given the number of CVEs we've seen > for padding vulnerabilities. We can tell implementers to avoid this > vulnerability until we're blue in the face, but considering that both > OpenSSL and NSS had this problem, that doesn't seem prudent. To add to the conversation, I wanted to share some related bibliography[1]: "On the Security of the PKCS#1 v1.5 Signature Scheme" Tibor Jager, Paderborn Uninversity, Paderborn, Germany Saqib A Kakvi, Paderborn University, Paderborn, Germany Alexander May, Ruhr-University Bochum, Bochum, Germany The RSA PKCS#1 v1.5 signature algorithm is the most widely used digital signature scheme in practice. Its two main strengths are its extreme simplicity, which makes it very easy to implement, and that verification of signatures is significantly faster than for DSA or ECDSA. Despite the huge practical importance of RSA PKCS#1 v1.5 signatures, providing formal evidence for their security based on plausible cryptographic hardness assumptions has turned out to be very difficult. Therefore the most recent version of PKCS#1 (RFC 8017) even recommends a replacement the more complex and less efficient scheme RSA-PSS, as it is provably secure and therefore considered more robust. The main obstacle is that RSA PKCS#1 v1.5 signatures use a deterministic padding scheme, which makes standard proof techniques not applicable. We introduce a new technique that enables the first security proof for RSA-PKCS#1 v1.5 signatures. We prove full existential unforgeability against adaptive chosen-message attacks (EUF-CMA) under the standard RSA assumption. Furthermore, we give a tight proof under the Phi-Hiding assumption. These proofs are in the random oracle model and the parameters deviate slightly from the standard use, because we require a larger output length of the hash function. However, we also show how RSA-PKCS#1 v1.5 signatures can be instantiated in practice such that our security proofs apply. In order to draw a more complete picture of the precise security of RSA PKCS#1 v1.5 signatures, we also give security proofs in the standard model, but with respect to weaker attacker models (key-only attacks) and based on known complexity assumptions. The main conclusion of our work is that from a provable security perspective RSA PKCS#1 v1.5 can be safely used, if the output length of the hash function is chosen appropriately. Publication: CCS '18: Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, October 2018, Pages 1195=E2=80= =931208 Although I *personally think* that PSS is a better padding algorithm, I'm also rather cautious not to be as definitive when making calls. This paper shows two things: 1. It may take many decades to have a formal security proof (even if within the random oracle model) of a padding algorithm of this nature. 2. The argument that PSS is somewhat superior because of its "mathematically provable security" (i.e., the motivating point for PSS on RFC 4096) may not hold that strongly anymore. I agree that Bleichenbacher's Oracle is an issue within certain uses of PGP (being such a versatile tool almost always means that you will always find a use that raises security concerns :P), yet I also wonder if PKCSv1.5 also ended up having a series of CVE's because it has seen more field-usage throughout these decades. Not sure if I personally have a strong stance in any direction, just wanted to share my perspective... Cheers! -Santiago P.S. I'm also not entirely comfortable with hardcoding a hash algorithm for OAEP, but that's a different conversation and I may be missing context. [1] https://dl.acm.org/doi/10.1145/3243734.3243798 > --=20 > brian m. carlson (he/him or they/them) > Houston, Texas, US > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp --t8jyaA0xz475szGT Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEkDurc2QOttZVM+/zRo8SLOgWIpUFAmA8RZ8ACgkQRo8SLOgW IpUNzxAAwcMBMk0G5QgBn/3kdsZviDrRsS6G4bCHuQJHWnGHdxQapfaCo4Kj7Vkd xr49hoAHG/95Zm+wvB4XnYwW5ttay1xVxJZLeJLVhS8mDT1JnV25um3OYoJH/F7B hLVgXGjp4HMhWEGD5P0TyjJnIBKknSoAiqIrDf551LOXTT6ETxobpUCN2wBPl5d/ ltfgffCZ6kqzukxdyCPzAVqKKroxhDQNtmaW3iIWpM4T2CQrGUX/yLKzxeCvZVVZ xi+61LaY6e5QL+2P561Z2m/VeByekUYuKz7oiPf1uEihbvVYwHZvIQVHoDC+mIbS kLKncrchxjtOtffU5+f5u9clorJRNwivZTTWOkxkdqq5PiFHu58upBcuPf2dOtqI ph9K2XWgeYarv/t9MXGiIJ8suVhgVpZkszM3rR9z+if4KOOBmsaiFfFCryLOlHYv 66R6y/WpxCWqtPSETe/GbWpNf5shBtv6sFg3+jSw4fsNUGlnNFbWMCZ40ImviSwS +14mseglV+iBlBdpibR1hajh2Oy3j24mOP7wV5Gg/EMaW/k52vBGDkUNVoupkZSA jdletQMifFqo2rZfd57AXEVdBQYuUgm9dIfDMPFUVkfokFmGIFXb2yvUQ4tCrIqF t8q0qlhwju8aSbq5p+SVtrTa/8N0KAyPDqQduZO+a08U7AZnsJA= =6nf1 -----END PGP SIGNATURE----- --t8jyaA0xz475szGT-- From nobody Sun Feb 28 17:49:31 2021 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 0723D3A126C for ; Sun, 28 Feb 2021 17:49:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-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 raOQSk4J7FFL for ; Sun, 28 Feb 2021 17:49:27 -0800 (PST) Received: from mail.direccionemail.com (mail.direccionemail.com [199.195.249.9]) (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 EBCE53A1269 for ; Sun, 28 Feb 2021 17:49:26 -0800 (PST) Message-ID: <892669d525925be93e6d7358b4c806f9346dd093.camel@16bits.net> From: =?ISO-8859-1?Q?=C1ngel?= To: openpgp@ietf.org Date: Mon, 01 Mar 2021 02:49:22 +0100 In-Reply-To: <87v9aecg7i.fsf@fifthhorseman.net> References: <7d8bdda1-4e5c-6c10-f3cd-1d191fad595c@nohats.ca> <4f3d66b74b46b5b8bf27b5e1589bf80e.squirrel@mail2.ihtfp.org> <87a6rug0x5.fsf@wheatstone.g10code.de> <8473b015f635c0f88f9bceed8acda0f8.squirrel@mail2.ihtfp.org> <239af1473534565304e2ecfeca630219417ebc0e.camel@16bits.net> <87v9aecg7i.fsf@fifthhorseman.net> Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [openpgp] ECC Curve OIDs section 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, 01 Mar 2021 01:49:29 -0000 On 2021-02-26 at 23:00 -0500, Daniel Kahn Gillmor wrote: > > I would prefer to see the new section "ECC Curve OID" as 9.5 instead of= 9..2 > > The other blocks are clear registries used directly. "ECC Curve OID" > > are a different case since they are actually parameter inside Public ke= y with > > certain ids. It's probably as 9.2 because a former draft likely referre= d to it > > from 9.1, but that doesn't seem to be the case, and is only referred fr= om other > > completely separate sections. >=20 > There is a sense that an ECC Curve OID is a subtype of public-key > algorithms, so putting it closer to public-key algorithms is appealing. > But i think this argues not for leaving it as 9.2, but rather as a > subsection of the "Public-key Algorithms" section of the top-level > "Constants" header (i.e. 9.1.1). >=20 > fwiw, while we're nit-picking, this section ought to be named "ECC Curve > OIDs" (in the plural) >=20 > Seems like there are three choices: >=20 > a) leave "ECC Curve OIDs" as =A79.2 >=20 > b) make "ECC Curve OIDs" a subsection of "=A79.1 Public-key Algorithms", > i.e., =A79.1.1 >=20 > c) move "ECC Curve OIDs" to the end of the "=A79 Constants", i.e., =A79.= 5 >=20 > What do other folks think? I'm thinking that perhaps (d) we should not treat this as a registry at all, but as an specification for how to produce the Curve OIDs from the OID themselves (basically, the text below the table, as an spec). Then make the table itself informational. This could be kept at section 9 or moved to section 13. This links with the point mentioned by Werner during the call that implementing other curves is automatic as they are identified by their OID. PS: It would be good to include a note as well at 9.1 mentioning the public key algorithms which depend on a Curve parameter: ECDH (18), ECDSA (19) and -when added- EdDSA (22). From nobody Sun Feb 28 18:08:11 2021 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 98A153A129F for ; Sun, 28 Feb 2021 18:08:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-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 XQT89gC3VBRP for ; Sun, 28 Feb 2021 18:08:07 -0800 (PST) Received: from mail.direccionemail.com (mail.direccionemail.com [199.195.249.9]) (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 F2A603A129E for ; Sun, 28 Feb 2021 18:08:06 -0800 (PST) Message-ID: From: =?ISO-8859-1?Q?=C1ngel?= To: openpgp@ietf.org Date: Mon, 01 Mar 2021 03:08:04 +0100 In-Reply-To: <87v9aecg7i.fsf@fifthhorseman.net> References: <7d8bdda1-4e5c-6c10-f3cd-1d191fad595c@nohats.ca> <4f3d66b74b46b5b8bf27b5e1589bf80e.squirrel@mail2.ihtfp.org> <87a6rug0x5.fsf@wheatstone.g10code.de> <8473b015f635c0f88f9bceed8acda0f8.squirrel@mail2.ihtfp.org> <239af1473534565304e2ecfeca630219417ebc0e.camel@16bits.net> <87v9aecg7i.fsf@fifthhorseman.net> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [openpgp] who creates old-rfc registries? 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, 01 Mar 2021 02:08:09 -0000 > > Procedural question: is it the right thing for a RFC to state that it "= creates a > > new registry" for those registries which were actually created by an ol= der RFC > > it is obsoleting? >=20 > If you're talking about the Notation Flags registry, it doesn't > currently exist at IANA: >=20 > https://www.iana.org/assignments/pgp-parameters/pgp-parameters.xhtml >=20 > So yes, while the initial values that populate it came from the older, > obsoleted RFC, this RFC *is* the one that is creating the registry. No. I'm talking about every section but the "Signature Notation Data Subpac= ket Notation Flags" :-) The other sections of =C2=A710 were already created by 4880. It's probably explained somewhere, although I don't find the exact answer. I see however that=20 https://www.rfc-editor.org/rfc/rfc8126.html#section-8 mentions IANA registration info should be updated to the new RFC, so I guess the answer is that instead of "This specification creates a registry" they should all be "This specification becomes the reference for registry=E2=80= =A6" or something along that line. I have opened https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/23 to track= this. Best regards From nobody Sun Feb 28 18:09:36 2021 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 C030B3A129F for ; Sun, 28 Feb 2021 18:09:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-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 x_abKwAaHYKG for ; Sun, 28 Feb 2021 18:09:31 -0800 (PST) Received: from mail.direccionemail.com (mail.direccionemail.com [199.195.249.9]) (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 81EE13A129E for ; Sun, 28 Feb 2021 18:09:31 -0800 (PST) Message-ID: <7696a8aecfd78ac908ca72bfd415f1a77944d9ea.camel@16bits.net> From: =?ISO-8859-1?Q?=C1ngel?= To: openpgp@ietf.org Date: Mon, 01 Mar 2021 03:09:29 +0100 In-Reply-To: <87v9aecg7i.fsf@fifthhorseman.net> References: <7d8bdda1-4e5c-6c10-f3cd-1d191fad595c@nohats.ca> <4f3d66b74b46b5b8bf27b5e1589bf80e.squirrel@mail2.ihtfp.org> <87a6rug0x5.fsf@wheatstone.g10code.de> <8473b015f635c0f88f9bceed8acda0f8.squirrel@mail2.ihtfp.org> <239af1473534565304e2ecfeca630219417ebc0e.camel@16bits.net> <87v9aecg7i.fsf@fifthhorseman.net> Content-Type: multipart/mixed; boundary="=-qI52RwCVBFdMoYju/qZy" MIME-Version: 1.0 Archived-At: Subject: Re: [openpgp] I-D Action: draft-ietf-openpgp-crypto-refresh-02.txt (fwd) 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, 01 Mar 2021 02:09:34 -0000 --=-qI52RwCVBFdMoYju/qZy Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 2021-02-26 at 23:00 -0500, Daniel Kahn Gillmor wrote: > Thanks for this close read, =C3=81ngel. >=20 > You raised so many points in one message that i'm afraid some of them > might get lost. >=20 > I'm trying to address all of your concerns, either with a merge request > (MR) with a simple editorial patch, a call for further discussion, or a > new issue in gitlab. >=20 > If you want to follow up on one or the other, i recommend referring > to the specific issue or merge request in the subject of the mailing > list thread, if one exists. >=20 > I encourage folks to do this kind of tracking/triage on the issues > they raise on-list directly, it's quite a bit of work to make sure > that all the points get tracked so they can be handled. Thanks for that. Feel free to ask for patches. It seemed odd to simply propose a MR without first presenting that to the wg. What I consider a good phrasing may not be considered so by someone else. Or just come up with a better one. Not sure how to proceeds without flooding with mails or issues/MR or everything. It's straightforward if everyone simply agrees, but for things that get discussed, it would be easy to lose track of that, yes. I'm replying here directly to some points, stripping unrelated pieces, and splitting another two blocks as different threads. Best regards > On Fri 2021-02-26 02:25:49 +0100, =C3=81ngel wrote: >=20 > > I would prefer to keep single quotes for values referring to single > > bytes standing by themselves, as rfc4880 did. -00 changed them to > > double quotes but using single quotes as in C seems better. > >=20 > > This happens in > > * 5.9. Literal Data Packet (Tag 11) > > ('b', 't', 'u', 'l', '1') vs ("b", "t", "u", "l", "1") > >=20 > > * 6.2. Forming ASCII Armor with '-' and ':' > > * 7.1. Dash-Escaped Text with '-' > >=20 > > but does *not* apply to the characters in 8. Regular Expressions >=20 > I'm not sure how to address this request without doing some heavy > lifting in the toolchain, espcially since it looks like you want the > tooling to behave differently for characters in the two different > places. >=20 > Please take a look at the HTML rendering > ( > https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-02.html > ) > which sets off these literal string representations in a clearly > different style. I think that's an improvement worth keeping. >=20 > I'm also not sure how much single vs double quotes matters here. If > you want to propose a fix we can discuss it though :) Wow. That's even worse. I can't really see a difference here (they may have a slightly different font, I'm not even sure about that, that'd be barely noticeable). I guess that's completely different at your side. I'm attaching a screenshot. I see they get into tags, so it could be just a matter of adding CSS. > > Additionally, in 7.1 a single-quoted space (' ') was > > converted to use backticks (` `), which seems like an > > error when converting the document. It makes sense > > in some markdown conversions, but not in the rfc results. >=20 > hm, yes, this looks like a bug in kramdown-rfc2629 which i've > reported > here: >=20 > https://github.com/cabo/kramdown-rfc2629/issues/108 >=20 > I've proposed a formatting workaround: >=20 > https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/34 >=20 > -Dash-escaped cleartext is the ordinary cleartext where every line > starting with a dash `-` (0x2D) is prefixed by the sequence dash `-` > (0x2D) and space ` ` (0x20). > +Dash-escaped cleartext is the ordinary cleartext where every line > starting with a - is prefixed by the sequence - and > . >=20 > This results in the following change in the .txt version: >=20 > [=E2=80=A6] > Dash-escaped cleartext is the ordinary cleartext where every line > - starting with a dash "-" (0x2D) is prefixed by the sequence dash > "-" > - (0x2D) and space ` ` (0x20). =20 > + starting with a "-" (HYPHEN-MINUS, U+002D) is prefixed by the > + sequence "-" (HYPHEN-MINUS, U+002D) and " " (SPACE, U+0020). > [=E2=80=A6] >=20 > Hopefully that is no less clear than before, and the rendering is > more normalized without the backticks. Are those underlines? It seems (semantically) strange. The solution of Paul of simply putting literal ' seems better, although maybe there's a way to get a better output for html. I should have a look at the source and what kramdown-rfc is doing. > > In appendix A, an extra space was inserted between "Philip R."=20 > > and "Zimmermann" (Appendix C in -02) >=20 > I initially thought this was an artifact of the ./reflow > script. I've > added a special case to avoid it while still being able to use > ./reflow, > and suggested the fix here: >=20 > https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/35 >=20 > However, it looks like this is actually a bug in xml2rfc, which wants > to > put two spaces between a period and the next sentence. >=20 > I've reported this here: >=20 > =20 > https://mailarchive.ietf.org/arch/msg/xml2rfc/6V7C7l-zxg97jRqvuaq8r1QBQqw= / I have no problem with the nbsp, although manually looking for "Philip R. Zimmerman" in reflow looks like a hack (although if someone deserves to appear there it's him). Instead of adding that for, I would change the preceding split not to split for single letters: > # assume all sentences split with a period (.), and not ! or ? > # also, accept accidental breaks on abbreviations like John Q. > Public > - sentences:List[str] =3D x.split('. ') > + sentences:List[str] =3D re.split("(? > crypto-refresh-01/02 nitpicks > > =3D=3D=3D=3D=3D > > At 1. Introduction, change "RFC 5581 (Camellia cipher)" to "RFC 5581 > > (The Camellia Cipher in OpenPGP)" or "RFC 5581 (Camellia Cipher in > > OpenPGP)", since just "Camellia cipher" could be confused with the > > description itself of Camellia (rfc3713). > > "ECC for OpenPGP" should perhaps be changed to "ECC in OpenPGP" which i= s the > > preposition used in that rfc title. > > Full name of RFC 6637 is "Elliptic Curve Cryptography (ECC) in OpenPGP"= and > > would be the proper one if we wanted to use the complete names of the r= fc, > > albeit I don't think that would matter either way. >=20 > These aren't the full RFC names=20 > (4880 itself is not "OpenPGP"), I noticed :-) > they're shorthand labels, but i agree that they should be normalized > to be more readable. I submitted the editorial suggestion > https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/36 to make > them "Camellia in OpenPGP" and "Elliptic Curves in OpenPGP". Good. Best, =C3=81ngel --=-qI52RwCVBFdMoYju/qZy Content-Type: image/png; name="Literal data packet.png" Content-Disposition: attachment; filename="Literal data packet.png" Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAA1AAAABFCAYAAABE6AeEAAAgAElEQVR42uy9TWzj2nYm+iUIiqPi qDhJcSROJA2epEFLGlxTwIvpQcwLNMwAgRkgsBoBrEZgC7iwhZdXEjop+XWjVCNXv0bpvAZKp1/D vLiAdTuAeQNYegEsdQDLN4BVPTCdgeUMzJqInog1MT1ZbyDZlmxZP7brVJ1z9gdoYEsk117rW397 b5J/QEQEBgYGBgYGBgYGBgYGhrH4Q6YCBgYGBgYGBgYGBgaGyfBHP4dBep438nuO4xgTGBgYGBhY LmFgYGBgGAu2AjUKTgNGqQL7q4thoFSzmT0YGBgYfnSwUSsZaDhfW4waSkYDDjMIAwMDA2ugvhxc 1AppFFs8hK8siSB4MNMZlFnmY2BgYPhRwTFzSJddCF89kfCwS2nkKy4zCgMDA8MP30B5sIxVqLEA pEAYWqn109SMbeI7U0AyFcdX35QhaUjGLRRL1sPPUVlFIJZF42uP5VuR44uihaIagG44X02/TRbb Hg+3DD2goNBifPwi6m0WkVTCCEgBxJLln+jKiIXSZhORpAbpa4vCRZBMiqh+V37Eropvk0sMXx/N vIxAqgLv5zymn0zO+IYxqob8gfX/h6MCf1GLISBJkAJhKPmeuI6JjfwBxIyJRt1EURtMC15tHbLc NzjHgK4bI5JjCyUtBt34slvUfv9/xiD/7e8n75+qZTSDGhRxIOOjmFIRCwQQiKlYLTUxzVye2zSQ 1RXEAhIkKYz12rWS0CiuQpN7xYSaQnFgvwcPeSEOxyxjshbKQkFNwfzqkeyHkKOJvBxA0nQn4Na3 opdvF42siuzX7G7HxoshDCgoiK1W8DXm1b/mtX8cfuuhkVcQDkiQpABiWqkXw1owcpuwY5uoNuoo F5RbK/3T++43aQvLRNWJQFP6R+egVkhCCQcQCMSgrZfRmkjXTeRlCZJ09yPnb0+ZODBTMUiBVdT6 /isqGiKWieqE6darrEIrWF9Xh46JVExF0fp28tvUerkzhm87z/4QeeCr55ofRX3D8C3n5xENVBCp solc+Bl86TKquXivs7BgIwJVlSAIIgR+8ChOUqCqMq76DqdehTWSYALCmgo1IHxDanfxsW5BjMUg 9v3PzCRRdGQUzCrMgozzzRQyE26H8KwC9GQJrppFqdpEs1nFlUo9q4R3dR56oYxqrYx8zMZmKof+ U/MRBUHnAAeTJD77APVvYQbkq8txi1vfil6+VXhNVA+crzqDOD5e3IUY06DNSeC/grxf89o/Dr/l EM9VYSR9eBbLwSwnEexeBJbNI6wmIAoCxNuJ5AG++0Pawv1f/wP/9R+Ox/qKfXAAW1IQ6xPKNtJI lQG9aKJaziNwnEUy35jA74JIlSrY2dnp+xQw/+I5gpHBicxWKY2CLeDl7e0TQgyyZKF+MEne8tAw D75+Q8r7oGgawuK3klceoJfbY/iW8+wPkQe+gVzz469vGL52fp5qC59trkJJfo9Pl1WkgxKkYVuF LBOlch02ALuchJqp4/PHHOKSBCm8PmTZzcGBYcA87oUju4J8sjtjGQiEIWurMO4hacvMIqnK3d+G Zej5yhNtA2mh2eIghfuSkltFucZDy2aQkERIiQyyOo/a9yYctFDSApDXG9dB1bMKUAIqCpYHwIH5 1gCXLuGdnkBQ5MHzAvhecuOCGRjGBrS4BFEMYi6dRNyzcNA/bsGHgGCjOa66tIpQ1Q0cX9lIUnAz UebhtLwOTQ70ZoPXUR6Y+vRglddvVsK0VRjWTZpo5mUoeRPlrA45FkYgEIOSKqHpPrEcng0zq0MO ByAFYlBTRTQelMX7uDVKHqeGQrK7MhgIK0jmazdbXCqrCOsGWo3edqNAChUPgNNAcVWDErtaNVyF MWHl38zLULJllNe1rh7DMrSsOTAL7TUNrOtKTwdhKMlbOnBqKKTUrsyBGJSUgWFu4jayUMIqCldG um+sXgN5Vcf3p+f47V90Z7W1e1aF3WYJq1qf3xWbA/zRe/wJyzqyZusmSVZWEdaKqJS6q63hQHhA b/fGizG6tusGSlfXccvQw0mUKkWk1BjC4QDCsoas2TeWKWIMwMH7WERKiXWvraRQ7DPEwLXRQlGN Yb1sIp9UEAsHujou1Abi0si4NYRvxb+VEbi9KucY0AIy8s2hBkLpihsxBaniRzjchLHzXj+xUcmn oMkxBAISwrKG9X7bThVeDSTlNH73+YprKoqtB/puf34asIULy7hZ1Q/H7trh5lLT+/L57/87/svf /8uY8XtoNVvgA76+1TUbVaMJKZlFMi5BDM4hl9Xgmd+j5gFubR2xsI4b13NgpsKIpUw44CBIEoLB 4PVHcmo44FQsKXxf7CggXXqBzGpsyPZzEQEfB6s5rvJzUVmVkfrdOU6/+yUkSUIgZd6M1z1AMdXz oSEcd5slrKqxB8WBu2o8RrlkoO5gYi7Aa8HMJ6H0bjWIqeswnbux8zq/OJgwz92vl5Exu38ME+lg Qv6O0Me9NnDKSIZjSJk3Z7NLGsLyOhrOpHngZhVVCsSgrpZw7N3uke7Rx4hc85iabuSxk+SFCcY0 WX3Dwft4S/eVm+vUVsMIrw9WwlZBQSBZ7tWPk8euLlfLMNY1yOHw9bhbVhnrmoxYOIBwTBu4/qh4 18xPk2smy3cjY8EE39uVbLemCIQha1mUP2Hi22oekp/HyTMAGok2bS34afb9yc2/Dl/TjH+Zdu87 ZHeF/NFXtN/78+zDPPkXtqh97zVO6P28nxa32kTUod3lEM2s7NBJp0Od9gnt7+zSUece6fZ3aGf/ hNqdDrUP39NiKERrexd3fndxcUH1X4Uo9Oe/ol/921+Q3++n6J/+Nf23ZocuLu7+ni52adk/Q68P +/53+Iqi/mXa6f/53gqFQmu0R0R08oEWQjP0av+CiI7o/XyI5t8c0QUR0cUOLYfm6fX2B1pZmKWZ mVlaXNuio4v7VPKe5v0L9OHsri0Wts5oLHo2GpB1d4X8Pj/NLH+g/bM2ddpHtLUcJf/CB7o6Y2d3 maLRJfpweEadzhntv1+kUHSFdjtXp50hny9Ky9sn3XF1Dun1vJ9mXh89oRwXtP9qhkILb2jvrEOd 9iFtLUcptLhNw0d+SK9n/LS00xnDrXvkubLVq106aXeofbRDazN+mr/i/O4K+aOzNDu/TO93D+no 6Iw6REQXJ7S7vUdHZx3qdM5od22mbwy3rntHLTPk883Qys5ZV4/tPXo166fZ14d0LdrZHm3vHtJJ u0Ods/2ennuEvDiiN7N+ii59oL2jEzo52qfd/Z5Nev53SEQXRx9oMTRDK7vtycZKe7QSitLa/ghu nX2gBX+IFt/s0tHJCZ0c7tJez0HbO8sUDS3Q690jarfP6GjnFc2HorRyRaCe7WfXdumsO3DaG9Db PfFipK67+vQv7/Y4uU2LPh/5F17TfrvLp7PtZYr6l6hLkSlizNW55l/RzlGbOu0T2nuzQKHQEu20 h1ybTuj9vI98oUX6cNjpif6BFkPRgbg0Mm4N49vRG5r1L1I/ndpbi+SfeU2Hd4Wm3eUQ+edf0e5J mzpnR7SzNk9+n2+AjyNlGOonHTrc2aH9ozPqdDp00tPpdocmwtGbWfIv9tu1y7VX+5PkhftkuutX 17Y4ekOzoQV6c3hGnU6bzo72aGf/ntg5hl8DP63+in4RjVLI7yOfz0+haJSi0Sj91W/bQ3JJm7YW /TTfH8gvdmnFHxr0sc42LflnqBtGO7S3FqXQ4hadEVFnd4Wi0eVrvg07/+ybvvzc2aO12Vl6td/p 6iy00s1Pt22xvEMXY63Woe0lP82+ObplFx/5Qwv0aueI2p02ney9pnl/H8fPtrpxZ/uI2p1O7/sZ enV4MXEcuOOH/lm6HuZYLnS655tdoa39Ezo7OaL93f3eubuxc2Z5iw7P2tQ+2acPy1Hyz7+nE5o0 zw3Ty5iYfXsM43QwDX+H6WOMDdrbSze5vffbtb3OxHngbGuR/KEFerN3Ru32GR1uLdOM39cXC8fo 455rTFrTTV0Pjs0LE45pnN4727To95N/doW2++uovli5txKi0K2BH72ZJf/Sdre2mML2t2uJi6M3 tOD3kz+6RFsnF91xbi1RKLRCuxcTxLupcs0E+W5cLBj3/dEbmvVHaenDIZ112nSy/56Won7y9fUY o2LF1Pl5nDy38M09he/S8wDuGXieBy9IiKtzCN6z/ibEVahxCQLPQ4hoUIMeTk/vn6/4/K8uQv/h tzg4+B3+r//tX/GfVv4Tfj+stfQu4YEb3J7ounC553je3/ryAnjvHJ9dAFIShbQAM5dHuZBDEToK 6WC3U7Zt2J9bMMs25rJFGKUsAqcFJNdrQ7YBuKgVDdiJJFRxcCac4wHPfcyidxCpbBJxUQAvBKEv KeCtZm/LlA3zuxrEVB7JiAieFxFPrUJBFb9t9F0zkMS6JnXHxUegqxKc4+MpV/5GyOFW8b0JaPkM EiIPXohAX9UgNMs3s3dPuZOgUULJUbCem4Mk8BCCKjKpIFrl8s2KzrkHOb+J1FwEwaDYXQ7mJMxp V6uJIuY0GXzLwsQr+gEdaVXs6lFIIJOKwzbLNyu6YgLaXASSwIMX49BlEc7pJ7g9mQ07jtxmEomg BCkYx1xcGpiV8WwT6WQRyJTwdk6YfKxjYJVKsIJpFDJzCEoSpMgcEkG+y59SDbyeR24uCEEQEVQ3 kNc4VL83+/gRQTIzB7E7cCR0uY+D9y0CTanrZ8+RWM4gLnT9RlQXEOMsNFrTxxg8e4bEag5qUAAv SEhkstD4Bozq/WR8oa4iGeF7omvQgi6Oj+3J49ZtvgU1KGIT5esbVxxUzWb3fpY74aOKX9c4qNkc 5iQBvBiEurEK5fnjYifAI6KqiAdF8DwPSV1ABC1Y3+rbFTwPngfwnACeFyAGE1Dj4uP5NfMf8f/V 6/j1X/vx7Bf/AdV6HfV6Hf/3n/JDV6C6MvR5pvcZn8GD7/85/wLPOReu09VzIleA3CogVzKQ3zhA JJeHKgx1RpSaESST0s1qVSaHY20TuTgP3DNvygsc4HqP2prHK+vIqUEIvAApkYIeueG4ZZTQjGSw oQUh8DykRAaphINquX8K+wFxYOL9lXV8b3pQs2+hxyWIUhDxuThEAF6tBMNJIFPQEREFCFIcyUIG 8VYJpf5FgYfkuRExezhG6GAa/g6jxhgbCFoBuWAduayBUm4TtpJHLjHpRicbptGEqOeRSYgQBBER PY905Nkj9fGQuDTFsSPzwoRjmhCJ9Aa0qzoquYQ4LDRbXyB23aoluKAGRQIEdRW6xPXGqSLiHeNj a4J4N02umSDfjePhuO+bZRN2MIV8MgKRFyDFU8gmH/c4nsfIexvf2It0eSjrOZipNGQ5AlVfQlK/ r7hxYZU38c6ow3K6UddzLiEoIxT3v/8l/jzAA+Ax8zd/jV/If4d/+Je/xUz0zq4dcACm7VWkZAEp U0XmOxHL22kEr/Km68B9JiGZz0GVAEBCbl2FmSqj6SWQ4Pq2fBhpZA7CKJTVu49Pf2xyee6Dr98P eQ4cLnF5vW3xEh8LKsKb/fn+EsFzF+hJ80wU0X8KjuMAz3s6OWwLrc+fUNPDKPcN/POlCNu5FuPJ 4Byf4vzcQjpWHShyLnkfHKD75KznMciRW4vGdg3Fze9gfrS7PPFcnEOe+Lq39cj7fBDcY3xyAfCA 0zSw+a6Mg1Zvn7jrAJGunp3TU3iSgsC9+e4U36XKqAtpVPSbxmqisY7ZknR66oAPBCAO2fZqtQBp efAswVgQMJtoQe+a7vlL+IQBAvVx8L58Pa2uBfhE7tY1rmg6TYzpbnkaOBckBCWgatn3kPEZxOCg djiuf+Jjgrh1h28SNE1CqVyFrSchOnWYTRFKNjhEVxZakKBI3ECDEBSfof6I2AmvhcrmJr6vf4Tt drngXHLQv9WbGCIp5PUU0loM5YSG5FISWlwcvvXjkb48ovPv8m7qNJjARl6G8u9z8ORNVId2Tx5q pTIc5aa5ahlpFNwUjFRw5BaXq3D98KfLdjnO9Y2Tv+a4h9NjG5eNdcjhbN81L4HEObyr6z4kDkwK u9n1geDdETqnp/DEW7GTDyAgujg4ddCrrh+U50bF7OF5cIQOpuHvsDg91gYCtHwOpprBBr+AD5uJ Ke4TaaFlY/AWBwjw+Xjg/BH6eEhcmurYUXlhsjFNBrF7XN91nk9TJk1p+0GucuA4QBCFW+P0buLQ yHg3Ra4Zm+/G8XDc9y4+Dak3RJ+IZ4+MXQ+T927M/MYaKIAL6ijWVbQqZRS/y0Er/Ro5owT9VnXn mhnoeRepkoHNiAAODgxdhjHxhV7g5XMX5+fDv3vOu3DcwdUmwfuEz/1adJ3uqhR/87ftAHjmwnb6 fshx4CAMvgdEECF4BwPns800kpse0kYRc8LdPceOC/CPeZkIx40ll5wzUVAGf8fxwsBvHm/kkekd 3rMw0kYRmjBYjPBf6Dkjz3w6ikbqVgPB3ZTHvUDbN7+HQjIFM/wWJVOFxAFoZBFLTTGn62GoQ3aJ YCClb0LIlVAuBcEDaBUUqMcTnvvcgiuriFWL2DA1lPoKsLFjHSf0tLicloN35lIfpmvu8THmwecf 8eVEcYu7ewZJ1RDcNFG1k1APTDRFBffmtDHF8fSx00MjqyN9rKJYrCIhcoBXQSq8gW8XAhK5Mg6S TZildygmFZS0Esob8VuF4hP48ogJQV4A3P6ZH6632tR/evccnz1+YMeDe95N2J5jY+i8kWPi+yoH rXRV+Foolw7w6fQACSk38NN/J/0O4XwNZV3spSkX3Ivnj3o9B3evH3djxAtlE+VcZPAaHH/zN8fh 28aUee4hMXukDibl78Nt4LktOF6Xf+e9ibtHaah/PA/Qx2NquomP5R4xpunmTqbDQHc1re2fTXH9 8fFu+lzz0Fgw2fe3B8Nxj6tBHy7vXfxAW/i8KUsvHtJcEm/LJjakBorG3btErUYTXkRHMiL0Bmaj Nc12Eu8c559f4MWL4TMIQbHb/d6wKoIgLDT7RLEOjuFJkV4x6qJRyMAUM9h6G8FBLnvzFD0pjABn odG80YJnW7D5F3jR8winsg4960AvlnpLr7fl7T61yveSn1jn06E7s96yHPCCAKHvw3OPs/10kzcR SGjBsrkBGQSBf6L3cQ3KI/h84OxjfIJw53r3TzV+xEdbgJrsBSAA7qdPU22JuWw1B97F4hx/hMP7 8JIHPKsOi5OxqAd7AdODbTt9Mr8E1/qI4/su+EJF9u1bbOYiaGbT1zekTzZWb4TJeLz0CXCPj4e8 R0ZCRAJaHwf3KVhNq2fTB8aLJ9D1Q2NMrxLA6ak7MPtqtQBRetjjtB4ct0QVWsSCWbVw0NtSMTSn CUGIaKF566Es/deYTIaB23hR/+giqCW7zRMAOJ/ww+/em76B58QItFwJpqHBK3+Huvv0vjwqVfte CnBO7RvJOQkRycNxn594VhMWgrh+kJ5tIFOwobzfQhJFZIY8+7pVLqEh6tCvVyolJG8/oa8wjxfP ZOR3Kti83g/u4vTUgSBKX+j9hjx8ARHu6Sm8W3lE4LkfhgtiENJtH7hyj4APfOtgMHa6xzi2efh8 D5+hGxezH8ygcfwdqo8JbOBZ2MwYQHILH9QW8rnb7wYblQdESCJw/LH/iMF6aTJ9DF7jMTXdo+vB Ccb0ZJOKvWWvvmoQ9ifnEbafApPEu0lzzaNjwfjvX/oEuKeDW2ft009Ps1L9BLHrizdQvCACrSqq lgPXccfQzUWzXEbNsuF6HtxWEw0HEKW7xawoiYBVQbXlwnNbqOTfwnRGq/X8n/8B/9PpEvb0N/8v /un5L/An/uHOFA4LXae8HoiMRdVDeaOAWstGq1bEhuEgrqvdvdWNAjKmgHQ+ibiaRyZYRy7be/48 l0BS42Dm1lFu2rCtCvJvq+AVHREAbiMPPV2HlFpFDBaazSaaTQuW3Ufr1gGOvSDiPSa7jRKy2Xve CyVKEGDBNFtwXWfCrYgi1OUEvHIG60YDLceB3WqiVjaHP2VvolM+QA5ewbLGo5pLo1RrwXZstKwa yuXGyP3nrt1Cq9X3cdyJ5OESSaSkJvLpAiqWDce2YTVMGLUR0Zd/iZecgwOzCcdz4TQNZItTvrr2 k4mNQg0tx4XdLCGzaUHUdMQBcMJLCN5HVGs2XM+BZWbxrn6jPC6ehCbUUMiU0GjZXTtVmnf0I2gF bMRbKKRLaGGSsQoQBQ8H1Rps14UzxGARXYdkFZEp1mDZXduYDbvHHwWukUO+0oLjOmhV8siVPSjL 6sQ7L+/Ei6fQ9QNjTLfTvUStmIdpOXCdFmqFDZTdOHRFeKBLTB+3rmyjaBG0zLcwmiI07Z6WVJCh J7pxqtJy4DoWKoV3qH6+nFyGO34iQBKBVr0Ky/Xg2g0Uc6WBe4Tcyipi4SS+2Ov8po0lrQoMs4mW 48LzHFgfT+HyL/GCexpffvHyj4F/+Uf80ycP8Ib7CgBIsTBgHfTFaRFqMg67tIFSowXbqqCwUQaU Bch8t/AzMoXuPSlzcaTzGrxiZvD9QV4DJcNGfODlvBwEcfAJfUEfD457jpdBCSJ/XdmiYXEIx3oN lVNDMZuH2bpnwuQFD7tuoum4cN3JEkFQTyJiF5HOmmjaDhy7hWbFQMX6gbjAK1hUADOXRbnZgm1b aFQqsNxu7ExKDRQyBpq2C9duwsgU0JCSSMYnL7Ru62VczJ4ak/L3Hn2MtoEHazODkqchn44jkclD sfLIGJPmAQmqFoRt5FBs2HBdG81yHpuNmxgyXh93rzE2Lo3g6sPj6uRjepo6CwhGgvAOyri6jdZp FPCu1rd9dRrbT12QTxLvJsw1TxALxn0f0VSIzU3kjCZs14HdMLBR+nLvpZs2do15ka6K/MdLnG7q UPMPe+MZr6wiF3ew+cs4YloB41KT1yojpyuIBIOIaW/xSX6LgnZ3tlfU88hEjpFVIwjLKfxaWEUh 6Rsxq8bhj19e4jcr85iVFSz9/Qv86j//CtF7DggqMriDKm6en8AjsVFC5mUdGTUBNV0GpxdR0ITu YzkzZQjpArr3t3X3F0v1HLIVFwCHSKaEt/I5NpMJJLQcjgMbKPWWCS3TxOnlOepv/x3+7M/+rPf5 JbTCjbZa9TrsiHr9PpFWtYTyR2f4eAUV2bQEKzuHiJwc8ojge2qvuU0Yb2M4L6WgxuNIqCm8Ne2H b5Z/kBwc4hsGNjXAyKhIxBNQkxswR95dfImPb/8Mc3NzN5909e4s8lB5gkiVSki9qCOnJRBPKNAz BpqfR4mYQLqgAWUd8WAM6kYTc4Vc371s4/FcSUFz3yEpR5DQS3CVtyime91xJI1CUkA9nUAkrCJT iSBbUG+W77kIMsYmFM9ASk0goSaxYZ4OmZwQoObzkO0C0kUL3tixBpHM6hCqKSRiMtLmkJZVSqFU SoI3M9ASCah6DkZvOpefewtjI4DjtxrkiAxt4xjhnIG3c/zD48UT6PqhMQYAuBcLeLsuwUwriMVV pKsCUsXN4Tf1T1L7TR23+qyp6IhYdRyIKhTp/kZLLRSRFuvIqHHElDR+K6wi0/cUibEy3PETHmp2 A7JThBYJQ9bfwVncROb2fYFDp8e6L9LVS6e4PMhD1UuwfpBY8hn1YgqaHEEwKCNVfoF0MYM49zS+ zP/Jr/A3/+Zf8XfzEQRjKlZ+czqcP/E5xN06TKt/KJsoJjkYKRUJLYcDXwbFjTnwAGwjg0JLRj7X 3ZrHRTLIqy42M8VrvbnV72F6CpYeQkLLxIEnQ+kpwrPKKJZP4d3jovF0DioM6PEYlGx9spU5UUex lEHguICkEkdc0ZD+rj79rSQP5gKPubcGNmKfsJlUkUhoSL+r91ZYujFQf2YgpcYQUVIwkESplJpq lv2OXsbF7KkxIX/v08cIG3hWCZmSB72QQYQDwCeQy8toFTK9CZDxeUBMFlHUOBgpBZGYhlwtgmwm 1jfTNk4fd68xLi6N4upj4urEY3qqOkvLY0P+hLwSQDgcg/4dh1Q61rcRbwrbT736NVm8myzXPEEs GPd9MI3iWwVOUUciIkN/a0HNJhH4Uh3UlLHrD4iI8BOHN+buveH7uS0UFB2n6TqK6ld+TabXRF5J wclW8W6OB6729ypVmEkRDD8uNPMy9E9ZfCzOgWPqYJh8WhpFVYWpmjBTElPHjyKXeGisy8hwm6hu xL+yv7uorSrI8TeytIoqtIMkqiUNAjMvw7cc/RhXWa75xvCHTAX3IYjUuoxmsQjrK0vimO9gCimk r2byPQvNVgS6yponBoafDew6qq0gNJUltB8POMTTaYjVdyh/7Ue+twy8Owgik75q5FwcHziQFxVW kDJ842BcZbnm2wNbgcKoJwoxMDw92AoUw3QBzIXrtlDOpFDk8qgW58AzrbBcwsDAwMByzVfDHzEV MDAwMHzDDXdBg244EOIpbBZYQmNgYGBgYLnma+NnsQLFwMDAwMDAwMDAwMDwFGD3QDEwMDAwMDAw MDAwMLAGioGBgYGBgYGBgYGBgTVQDAwMDAwMDAwMDAwMXwXsIRIMDAwMDD87sCfqMTCeM54zMDwU bAWKgYGBgYFhItiolQw0nK8tRg0lowGHGYSBgYGBNVAMDAwMDAzfKhwzh3TZhfC13+Yp8LBLaeQr LjMKAwMDw8+jgWqhqAagG2zubGJUVhGIZdH4Kdhk3FicGvK6jLAkISCvg9UHPxQHfi74Qlx3y9AD Cgotxs+fLiyUNpuIJDVIX1sULoJkUkT1uzLsnxHNmnkZgVQFHgtkP6967VuPrz+V+MfqjG+9gfo5 wUJBTcH8wtG+kVWR/YkwvlnMwXBVFGsN1I0MEjzjzY/92j8lfv4c4ZlJBCQJ0tCPhpL9U/OB+0Qy UXUi0JT+5ScHtUISSjiAQCAGbb2M1kQyN5GXh+tUzje7eq+s3tG71qdsUdEQsUxUf6odlGNA1w22 TZHZ8svWHAUFsdUKnm6utoWSFoNu2N+43pnvSd4AACAASURBVL5MjPUqq9AK1s+C1uwhEl8S9gHq LSD4RaubJqoHDjz1p6AwF59OHYiyirgoMN78FK79k+LnzxOcUkC14nZn/Y83oa+fI1XOQ+YAcDwE EYD1E/KBe0U6gC1piPVN6thGGqkyh0zRhMK3UMykkcy/RHUjjtG35geRKlWgDdzgf4xiMo/LSHd9 yz0/BwLL2Cqo6F6SAy+KNz8XYpClPOoHLpLiT2+myalXYXkKc8Cnyq7/63/gN5/8+Ms/DYBjtryZ iIhp0IISns6DBIQ1FVxA+Lb19kVirIeGeQBXTP0sfGrsCpTbLGFVjSEgBRCWdWTN1vXyeTMvQ8mb KGd1yLEwAoEYlFQJTXfgBCilVMQCEgIxBaniRzj93mtXkE8qCAckBAJhyNoqjPuWab0WzHwSSiwA KRBGTF2H6fTJqcnd88QUJAu1vq0NLRTVGNbLJvJJBbFwAIFw9zfOVZcfkNGb+LsmQm09hnDK7M5M ODUUkkp3HGEFyXzf+d0y9HAKpt3dfhYIxJD9TRGquoHjyyrSQQmSpOCqKR+l065KstDlcE8fWZQ/ YXjA8xrIqzq+Pz3Hb/+iN0N5Nevh1FDo6V0KxKCmilPd+Dxan6Nt0TKzSKq9Y8My9Hxl/AyK10RR U7Fev8Tpd7+EJEnQy86EtpWRrbVgrmuIBQJQi62eTZIomQUklRjCgQBiagpGs4VGMQU11tXvHb6O lNFGJd+dbZYCYcjaOgyr7+DKKsK6gVajiKQSRiCQQsWb8jzW/bwBPJyW16HJAUhSADFtHeX+6W7P hpnVIYcDNzZ3x+hpYELqAZx1ykiGY0iZNxa2SxrC8joazgh+3kZlFWGtALPfNskiGq0mSqsq5HCg y6Urn52Up+PizwT+eDtBWOX1rn9KAYRlFfna1a85eB9vnavSL42NSj4FTY4hEJAQljWsTx1PLRir /eNpoLwaG9xiMypWTRNvrzsoAeLVKshLHgAH4epvUegrPB7Dz8l4OC622JX8TezUszBrRWhPsiXF Q6vZAh/wQeizZ9VoQkpmkYxLEINzyGU1eOb3qHmAW1tHLKzjhvIOzFQYsZQJp6fDYDB4/ZGcGg44 FUtKV6Ou7YDzxRC5/o2EwT5JRMDHwWq2nt6n7vWHx3LYhWWsQrvyn1hfHu63YzkJNVPH5485xCUJ Uni9z4afUM338+iWj0zKs3H+4DRQXNWgxLqyxtRVGJY3WFMYJrK6jFg4gHBMw3rZQquSh36dc1Yf 5gOYgO9T+vL57/87/svf/8vDtj+6BzfXiqlYNazr87jlJAJKYXAOpbGOWHgVtbG27C8BDKzrSk83 Pa7eoxu3UURKjSEgdfWipkpoehPm6dsUqBsoXXH4qm6odM8fDgcQljVkTfsWbUbVaA4ODAPmsTsY k6/yUCAGJWWgNcaf7tdbNwdd+VBMWx0Y30jdTBBjx8bxe/3CRWVVRup359c1XCBl/rS329IonG3R YmiGVraPqN3p0Mnea5r3z9CrwwsiIjp8PUM+X5SWt0/ogoioc0iv5/008/qod4IO7S6HyD//inZP 2tQ5O6KdtXny+3y0uNW+/n5mZYdOOh3qtE9of2eXjjrDhOnQ3toM+WdXaGv/hM5Ojmh/d5/OruWM 0tL7fTppt+nscJtWZv00+/qwKxed0Pt5H/lCi/ThsHvyi5MPtBiK0treBRG1aXvJTzOvDm8ud7FH a9EQrex2iOiI3s+HaP7VLp20O9Q+2qG1GT/Nvz/pibZNi/4ozc7P08rWHh0enVD7gogOX9OMf5l2 LibXKR29oVl/lJY+HNJZp00n++9pKeonX/QV7Q810h6thKK0NvDlEb2Z9dPM8hYdnrWpfbJPH5aj 5J9/TydDz3FC7+f9PZtMos8RtiCi9v4O7eyfULvTofbhe1oMhXp6JqLdFfLfO5YObS/5afb9yS19 jbOtn2Zm52nh1TbtHx3RSfuiaxOfj0IL76lr8jbtrETJ5w/R/Ks9ahMRdfbp9WyfHUeiQ/trM+Sf XaOdozNqt09o780ihUJLtH018N0V8kdnaXZ+md7vHtLR0Rl1HnKeYbzZXSG/z08zyx9o/6xNnfYR bS1Hyb/woaf3C9p/NUOhhTe0d9ahTvuQtpajFFrc7n1/j55u4wGcbW8vUSi6Qrudm9+u7XVG8HMI euPrt82rWR/5/bO0snNGF0R0cfSeFvxRerVPE/N0dPyZwB9vob2zTKHQPL3aOaSTsxM63Nulw/ZV DPCTf3aFtg/PqNM5o/33ixTyL9F258b2hzs7tH90Rp1Oh062lyna9/1E8XQl2h3PUZvaZ4e0vTZP IX/feEbGqmni7T04fEVR/9IgP56EnxPwcFxsOXlP8/4oLX3Yp7N2m0723tNi1H9vvLk4+2/05/5/ S/9P64IuLrqf+q9CFP0/6nRxcXuAbdpa9NP8hz5pL3ZpxR8a5HZnm5b8M9Q1WYf21qIUWtyiMyLq 7K5QNLpMO+2hzKKtRT/NvrmJRftrUfKHohQNhSgUnaXFta07tjp6M0v+5R26eFKfGuUPj+Tw0Rua DS3Qm8Mz6nTadHa0Rzv7Z8PLjw/z5F/YovYALWbI54/S4pu9Lr9Puvy+8ZFpeDbGHy5OaHd7j47O OtTpnNHu2kwfn3s1RXSJtk4uiOiCTraWKOTzU2jxJufsrkTJv3g1hil9YCTfJ/fli+qv6BfRKIX8 PvL5/BSKRikajdJf/bY9hOfDaoNu7fRm74TanTad7L6ieX/0OsZ3tpfIP/uGjvoP21+jaGiF9kbY 8q7B92h795BO2h3qnO33eHPYV2PNUtc99ulVNEpLW12Otk8OaXfnsHfuCfLrnVAzQ/7l3R5fu3WD f+E17be7NjvrcXynQxPWaLfqqYtuPRZd+kB7Ryd0crRPu/sn1zlqlD8N01tnd5mi0SX60J9nrvLv SN1MEGPHxvFxftGr4d4c0c8BIxuoozez5F/a6SsCL2hn2U/RXrQ9fD1DvltF+cn7efIvbvcC9jYt +aO0tn8xmHRCNw3UzpKfZtZ2RzsWEVFnp3uuvbsOf/R6hvwLWwNB6GJvhaKhZdq9uAkC0Vf7g8X6 4k3x3NlZotDMKzrsOz4UWqG9C6KL/TWKRteo/9LtrQXyz77pjr3ndHcK8SEEnUSnA2Tt6XSaBupi b41CoeUbh++zxav98Q3UWH2OsMV9hcHCVeExZQM1qW2vOdc33kV/iFZ2LwaO8/sX+wraW8FzEv7t D3QW9GG+r+jZXSG/b4ZeH1487jz3BrYF2upXxP4rivpXrm2yHLoq3PoD/SJ1zXqPniYIquM4252A CFF0ZYs+LEVpZm2v77dTNFDDbDMQX87ow4KfFibm6bj4M8nYaNBOC/ckh14DtdzvdBe7tOyPUv+8 zGBls0vL/hubPT6ejotVU8TbBzVQj+HnZA3UqNgybeycroHq2n6xX9iBZqmf7yFau6ocO3u0Eg3R 0octWpuJ0vJO+75ke1cX7SPa3z+ik5MTOtr7QMszfgotDfrv2Yf5+336IT41lT88gMOHr2nGv0Dv j8bnjnsbqFvF+sn72T4fmYZnU/rD/iuKhtZ6TUE3ng5Muna2ackfopV+59tboVB0rcu/aX1gJN8n l/2K29Z//lPy/+WvqX1xw/dJG6hB+1/Q3kqIQr28+WQN1O0r93Oxv4G62KO1UIiWts/u5u1J8uu4 BsofouXd2zH2Jo6PjzOD9dTF3hqF+huwkcYa9Ke7ejujrYW+eqqrbFqL+rsyj9LNxA3UiDg+1i9+ Xg3UH43asnB6bOOysQ45nL35r3cJJM6vl+WeiSLE/t0eHAdc7eu2LbQgQZH69sxwEoLiM9QBADyU 9RzMVBqyHIGqLyGpzyE4bDOq3eyeK8jdlfPUAR/wDcoRjEPySvjYAuaCAPAMYlAc3JnCAZ7blZWX FxHP5lBubCAS99Ao18Epm4hzgHN8ivNzC+lYte+yn3HJ++AA3ScyPXuJmCyN3QYyWqfde4D4QGBg LKJPxLNp9s2ensITFQT69cgHEBBdHJw6QFwYLeM4feI+W/S2aJQ38c6ow3K6uvWcSwjKw7bNTGrb oBKDMGQvsijeyMiBA8e9xAv+Nl8v4QGj94Vf8a+fyxARCPOwT4/hQeoe/zwGOcI9/jzD8NwHX78i eA4cLnF55WufP6Gmh1Hu09/nSxG2A3SVc5+eHsNZgIMALZ+DqWawwS/gw2Zi5H7yZl7Gn33/qftH YB0VM9X1Ie4lXvKD/gmhP75wXd143oQ8HRd/JhnbwIYaWC1AWr7Pz0X4fIMDeN4XDuG1UNncxPf1 j7Dd7vWdSw563x6Hx8XTcbFqinj7EDyan2P3EY2ILcNjpxTw4fnT3AkGDph+OwqfwEZehvLvc/Dk TVRVYaiP1UplOEoeA18LwZtQLUnYLLQgJ8uoOhp04YqrV9LdJ/aUPjXOHx7L4UgKeT2FtBZDOaEh uZSEFhenuifnmRgceAoix/GDPjIxz8b4g11DcfM7mB9tuB4Az8U55H5JIASF28qFKHAD/+O8Hm+m 9oFRfP/CvjyocYjSgEUhRUR45VPYk7ruJHVL08DmuzIOWk5vO50DRIZ4HJdAekNBKqtANhRoySSS aqQrx2Pya1/d4BNv2fDa16av0ZzTU3jSrXoMk+eEW5s60Wxd4mNBRXizP8RfInjujtbNU8Txifzi 54ORDRQAvFA2Uc5FBknH8X1/P5sg9Yz4LqijWFfRqpRR/C4HrfRr5IwS9ImfE+tN/A03ShI+gQXZ Q85sIBdxUa5zUIo3NwI/8+koGqlbj6/l+ojJYfwLvcfp1BuqMY579gNSwnvAN30h38xAz7tIlQxs RgRwcGDoMowvLMu9b1Pn7v7NfUl1cdzDzj+JckcSzIP3LIy0UYQmDA6YFybQ0yPjgOe24HgA3HOc u8CoDiqYKqGied2CjO8rtobJxj2F3z82xk1VZ997rUZWR/pYRbFYRULkAK+CVHjjTrEy3SXuxp2R serR8fbL8vPxseVL3R7Pgxe69yVdl4zcCzznXLgD96id47PHQ+D7/9VtPjzHxtA62THxfZWDVho9 8cCJEkQcdK/XO4nruOBePB/RQE3vU6Py0+M5LCCRK+Mg2YRZeodiUkFJK6G8EZ/8Jv6R+XA6nt1f f1goJFMww29RMlVIHIBGFrGUO3lN8UjZxvGd+5K+/AR5carJBttASt+EkCuhXAqCB9AqKFCP75mq Ut/CVNKolYv4rqBDKaVRMlKIPCa/ThVGnqJGm9Sf7ja0cs5EQbklQ49E9+qGe4o4Pplf/Fzwh6MS hi8gwj09hScIEPo//ISWEIIQ0ULz1k2ULfvutaS5JN6WTWxIDRSNIY90EoOQbp+rX87j44Gbxz2r gRYk3Fp0GukQCU0GqiYatSoOeAVavDtOwecDZx/jE27pQeAniyQT65THS58A9/R48Mbo00833f8E 0UoI+MC3DnA8kNiPcWzz8PnGVSsT6PNeWwBWowkvoiMZEXohZpi9Jy9ansa2TwAxgiDXQtMaeNwH jo9diD7f5Gl04vN4U8snoQXL5u5wlHtAYJ8qDngWNjMGkNzCB7WFfO72u2kG+ckJEqSrG+fFBzYq k3BjbPyZNsZ1z9v6+JCXkdiof3QR1JLdRAkAzqfp3uEzzO9uxdPJYtUE8fYL+M/0/PSmiC3DY6fz 6dP9nsQ9A4dLeN5k+cH3UoBzat+cj5MQkTwc9/HBs5qwEEREuikMMwUbyvstJFFEpnhX161yCQ1R hz6mwvFsCzZE3Dyg1MXpqQNBlJ6obRznD0/A4etmMAItV4JpaPDK36Hujmg6vjjPhviD8xEfbQFq slckAnA/fXrco66nlG2yXPpD+PIlbKuP9/BgNW1wYnf1n+stz3i3/O6zN7ktPasOi5OxqAd7jbQH 23bGkQgJfQOGuQnZLsJoPGGeHsGVaWs0wfcSXOvjYD02VU7o15uEoAS0LAf8LR8dSFnDdPMUneWX 8IufZgMFBPUkInYR6ayJpu3AsVtoVgxUJvVRQYae8FDeKKDScuA6FiqFd6h+vrxOAM1yGTXLhut5 cFtNNBxAlIY0JryCRQUwc1mUmy3YtoVGpQLLBYJ6CpFWEZliAy3HhWOVkd2ogteWoEyxpM3Fdcio 4+27OjhFu57N4BJJpKQm8ukCKpYNx7ZhNUwYtTGpQ5QgwIJptuC6DlxvvE4jmgqxuYmc0YTtOrAb BjZK1sgZPVHwcFCtwXZdOK4HLp5EUmqgkDHQtF24dhNGpoCGlEQyPl4PY/U5whaiJAJWBdWWC89t oZJ/C9O5fDBBn8q2kxa5Zj6LYs0Zyr8llYO5kYVpOXCdFmrFDDbtCJL6FA8CneQ8Q3gzyXmXNR7V XBqlWgu2Y6Nl1VAuN6Z7h8TUnPVgbWZQ8jTk03EkMnkoVh6Z60eP3eXnU2EsN8bGn2ljnAg1GYdj ZJCvWLB7caA20Yt/BEgi0KpXYbkeXLuBYq6EqVoxXoaW8GC+3UTNdrvcKbyFeX4zntGxalS89dDI ygirRXyRdmpafg7h4bjY0o2dReTKFhzXhd00kC9a908+8X74X37CP/9zbzup84/4+99/vncIUiwM WAd9+unywS5toNRowbYqKGyUAWUBMt+NJ0amAFvJIzcXRzqvwStmMNBDeQ2UDBvxOy/nbcEsFGE2 ujxrNQys50xAXeqduztx0bA4hGPiE/rUKH94Ag63KjDMJlqOC89zYH08hcu/xIshlS0viECriqrl wHXcyUq9qXg2wh/4l3jJOTgwm3A8F07TQLbY/EF9YDTfp6idenjx8o+Bf/lH/NMnD/D6YrFTQzGb hznqCX7VtyhUWnBcB61KHm+rHJTF7g4dLhCA6NRR7j0yz7MrKJQOprIlJ7yE4H1EtWbD9RxYZhbv 6t593RZMo4Km7cD1XNjWAU5dAYLwhHl6BKat0bh4EppQQyFTQqNlw241Uas04UzgT3f1JkJdTsAr Z7BuNNBynO75ymb3SZSjdDNBjB3P4XF+wePlCx523UTTceG6P+3WavRjzEUdxVIGgeMCkkoccUVD +rs6zic+vQC1UERarCOjxhFT0vitsIqMcrMr3WuVkdMVRIJBxLS3+CS/RUETh3b+c28NbMQ+YTOp IpHQkH5X73brooZiKY2X1Qw0OQI5WcS5vAlj7Ls4bjM9Ak3xcHzMQ9X6F4ODSJVKSL2oI6clEE8o 0DMGmp/HDV9FNi3Bys4hIidRbE2g02AaxbcKnKKORESG/taCmk0icH/KQzKrQ6imkIjJSJvOtbz6 MwMpNYaIkoKBJEql1GTP/B+rz/ttIep5ZCLHyKoRhOUUfi2sopB8xMzPU9l2ErgHKBsmrKGbSTjE NwxsKufYTMqIyBpy1RfIlIrQp6pfJjjPMN5Mel4NMDIqEvEE1OQGTGvKhmVKznpWCZmSB72Q6W4R 4BPI5WW0Cpne45uH8fOpVjXGcWN8/Jk2xgnaJkppHz5u6EgkEtDSJRxMNCQeanYDslOEFglD1t/B WdxEJjINiwWohRLSQh0ZJYKYksL3nA4t/GziWDV5vH1qTMnPITwcG1uCGZTeynA3dcQjMWgbTSSS yoh7oAL4q//4V8B/XYQ8O4+Ftf+J5/4/HlEIzSHu1mFa/WJuopjkYKRUJLQcDnwZFDfmwAOwjQwK LRn5XHdrHhfJIK+62MzcNKlu9XuYnoKlO/dG8Xju1bGZ1pBIJKCmS/gsb6K80bfNzzJx4MlQ4k8Y CUf6w1Nw+DPqxRQ0OYJgUEaq/ALpYgbDhsArq8jFHWz+Mo6YVkDzC/DsXn/gEkgXNKCsIx6MQd1o Yq6QQ4L74XxgHN+n9WX+T36Fv/k3/4q/m48gGFOx8pvTXj9SRrF8Cu/e3suHpcIy8H0SSiwONfcR gVwJG1dvuZdSKGQkfEzLCIdjUFK/hZRaQoCbwpaRNApJAfV0ApGwikwlguz1+8/urpo41bdIKXFE gjGomY8IbGwiHXzKPD1qlmHKGo2LIGNsQvEMpNQEEmoSG+YpvAn8aZjehLlNGG9jOC+loMbjSKgp vDXt3q7CUbqZINePpfB4v4inc1BhQI/HoGTrP+nVqT8gIgIDA0N3L2/aRaH+7pGJkoHhh0ILRVVF Xa/D0AWmjtuorSKc4VE82MDtxXdvzN69u/cLemisy8hwmxO8KPdLw0VtVUGO/xZkYfiWMY7ndkmD dpBEtaSBRRAGhsnxh0wFDAy9RHJ8DE7REWfVCMOPpjrq3lPx4gXPdDGsvTw+hSeIT1QYcoin0xCr 71C2v/bADLw7CCKTZs0Tw+Ma8eMDB/KiwponBoYpwVagGBgYGH4kaBoFHL9UIQdF8LBRzaeRPQhg s/oOcz/3HsqpoFi+RFgJIyhwcJol5NIluCkTZuruo8mmX4FiYPjxgfGcgeHL4I+YChgYGBh+HOA5 G+VcEvlP57h89hwvgwpyxRxrnrqVINyDd0gXWzj/fIlnL3yIa5sopiSmGwYGBgaGJwVbgWJgYGBg YGBgYGBgYJgQ7B4oBgYGBgYGBgYGBgYG1kAxMDAwMDAwMDAwMDCwBoqBgYGBgYGBgYGBgYE1UAwM DAwMDAwMDAwMDKyBYmBgYGBgYGBgYGBgYA0UAwMDAwMDAwMDAwMDa6AYGBgYGBgYGBgYGBgYvrkG yi1DDygotJgxngLNvIxAqgLvZ2WPFopqALrh/Pj0fRuVVQRiWTR+bDz6RuRmYGBgYGBgYPiqDZRX W4css6IIABpZFdnGI49xTKRiKorWj6ghKyiIrVbgfkMyeZVVaIWnVqKFgpqCOapjcAzougHnK+r/ ITz8FvFlbPiEeICtv5yvVLAaiGF9iN2tgoxAsgwXFgqKBEka/gmv1wA0kZfvfhdImvfK7DSKSKky woEAwrKGVcO6f3xP7h8T+CQDAwMDA8NXwB+N+pKTFKgqIP7cteQ1UT1w4KmPPIb3QdE0vPwRKVSM adCCEvhvxxhomAdwxdTTntY+QL0FBEfV1PUqLE/5evp/CA+/TYf6MjZ8yv7pAbb+ur4iIVWqQfM8 AC6qGR2GbxOllASAA8cLACwAzxBbLyOvcDdxnheHy+yayKWKcFNFlDURXrOITDqJgq+OjTj35f1j Ap9kYGBgYGD4Ghi9hc8yUSrXYQPobpOKYd0wkdVlxMIBhGMa1ssWWpU8dCWGcCCAmLqKcutqyrB7 zKphIq8rvWNUrBrWiK1BHqzyOjQ5jIAUQExbhWHdzHk28zKUfBnGugY5HEYgLEPPV9CyyljXbuTK Vuwpz2minNUhx8IIBGJQUiU0XQBeA3lVx/en5/jtX3RnbDXD7vVIBtZ1BXI4ACkQhpIsojHqGO8Y 5ZKBet8UrdssYVWTEQ5ICMQUJAs13Eje03nZRD7Z1V8g3P3NqFleDp9gZjXI4QACYRla1kSrX+FO DYWkglhA6p4v33/NWzVM3UDJbN3Yy7NhZvXemGNQU70xOwb0gIx8c9CWtfUYwqneDPeo63qtvvOG EVN0ZM3bUrmorMpI/e4cp9/9sjt7njJvZHMPUEwpXV0O0VPLzCKp9nTd440DAFYRqrqB48sq0kEJ kqTg9uKIXU5CzdTx+WMOcUmCFF7vW5n9hGq+Xyc97ozT2SQ15JX+R/BwpF7dMvRwCqZdQ16XEQjE uitYTgPFVQ1KrOcT6ioMa/KpfruShS6HEQiEIWtZlD8B3MD8wT2+McKG9x8zHAO+E5ahF5sD/q73 /D0s68j2c9gtQw8nUaoUkVJjCIe7qytXfLvX1mN0NuArY67RUyLyyR5fA2HI2iqMB2+d5cCL4vWq ksABEK7+FiEKfQ1T3+8kSRr4brAjstDyItD0OCRBRHAuCVVycfrpLk/u94/7Y69bW0csrMO4VokD MxVGLGXCmcAnGRgYGBgYvhpoFHZXyB99RftERHRC7+d95Isu0dbJBRFd0MnWEoV8fgotvqfDDhFR m3ZXouRf3KL27WOOOkRE1Nl/Qwv+KK3tdf+mzjYt+mfpzUnvz91likaX6MPhGXU6Z7T/fpFC0RXa 7f388PUM+XwztLJzRhdEdHH0hhb8fvL3yXW2tUSh0ArtXkxzzigtb5/QBRFR55Bez/tp5vVRTxF7 tBKK0tr+Lf2c7dH27iGdtDvUOdvvHXN4/zG3xkpnW7QYitLS+306abfp7HCbVmb9NPv6sCvHlf5C i/Shq2C6OPlAi6Eore1dDDXZ4esZ8vmjtPRhn87aHWofbdPKTPecXRzR+/kQzb/apZN2h9pHO7Q2 46f59ydDZTx8PUP+5d2ePBe0/2qGQgtvaO+sQ532IW0tRym0uE1n1KbtJT/NvDq8EeZij9aiIVrZ 7Yy9bntrkfyzr7rn7ZzR0d4O7Z0MG2OHtpf8NPvmqO9/XT35Qwv0aueI2p02ney9pnn/oJ7a+zu0 s39C7U6H2ofvaTEUuvn+8DXN+Jdp5+J+dzj7ME/+hStuD+p78c1ed1wn3XHdcGeUzsb53G39D+Ph JPaM0uz8PK1s7dHh0Qm1L4jo4oR2t/foqKfv3bUZ8i98uJZp8Lq3cPSGZv1RWvpwSGedNp3sv6el qJ98fXKP9o1hNhx3zB1j0II/RItvduno5IRODndprxdj2jvLFA0t0OvdI2q3z+ho5xXNh6I9HvZ0 4vORf+E17be7NjrbXqaof4l2Ovfbeiqdjb1Gh3aXQzSzskMnnQ512ie0v7NLvSHcJgWt+IfEHyI6 ejND/qVt6tz2kUU/zdzWLx3S6xk/Le10aCJcHNKb2RAtvDmkDhG1917RbGiRts4m94/RsbdDe2tR Ci1u0RkRdXZXKBpdpp02TeyTDAwMDAwMXwNTP0TipbIKXeIAcJBUFZFnHOTlJCI8AAiY02LgWk3c TKQ+w0t1FXqwu0mEj6exqnqo/roxZBXKhvldDWIqj2REBM+LiKdWoaCK3zb6fh3QkVZFcAC4oAZF AgT1Ri5RVRHxjvGxNc05k1jXpO4sC655CAAACgVJREFUOh+Brkpwjo9H7+cXE9DmIpAEHrwYhy6L cE4/TXwPhFUqoimlkU/FIQkCxIiGt1kFbvk71PpEe6GuItlVMDhJgxZ0cXxsj5BLQzYZhyjwEIIa NtJx2GYZDQBeo4SSo2A9NwdJ4CEEVWRSQbTKZYyd/Har+N4EtHwGCZEHL0Sgr2oQmmXUHQGKFodb L+N6HaBRRtWToSX4sdf1PK87i87z4HkRwYSKhMRNxU1eWUdODULgBUiJFPTIoJ6EuAo1LkHgeQgR DWrQw+npE9yxIWrIZhLdcUkqUrp4w52ROnv8pSey5+U5OHUT7/QEIsHe6gQnYU5LICh29T2nyeBb FiZZAGmWTdjBFPLJCERegBRPIZuUHu8bUxxjlUqwgmkUMnMIShKkyBwSQb7r76UaeD2P3FwQgiAi qG4gr3Gofm/e+POz50gsZxAX0IsZC4hxFhqjFDCtzsZc49LzAO5Zl/OChLg6h+AX3/93iXo60rcC NeLhK1wEmVIOwv/f3h1CJ66lARz/7549jYt6UY0C1SiiQAVFVdZs1kzUQw3PDGpQRIECRc1mFWrz VFzWFFUUVVQFlapUpSqjUjMr6JsC5dHQdt7bffv9zhkzJbnhu7m33725uQ3/jlWv0+rd4gY+bukl yC/1vSpNb4SVjPCmAYPhNaY3wNZkYlMIIcR/t78c9/ETNGPjt5uiANr2EhBFQSnYGhxp1c3fuApV o0oR3pIC22lXwjJ54GZkU5tsJIlfHjDuc2Bd9omub7yXpaAooOnb16VQPF7Da84JiqJAcXhJU7YM mFyEXCfZ47KdDMyyy6DWybt6Vtku12hQLabcJHBurGOuG9sZi6JAkf96OSe6sXVOtVJBy1fc5aCv brm/j+nWZ5vB4EGtkD2rj918KCb5cseVWyPc+B5fHnTSDFTrA42+R7gYYjYKFuEcpTWhoUD2QrkN p0931sG15jRslx/b7pEDqHWcNhYqoW7FKScOJ1wEc+Js/X9F9oD2Dq9snOjGVtwURX26d16IGW9M FrMy9XlySt3aqdn0Cn/yT6KblLwAipx7rBIl5tzdZqhnZ1v3mF7ROXlj2yh/zC9t52zP+5kJcQLV j9vf16gbEC1JcB9DrlHRd/otXmjyR8fsUBkqrc8eUaeLZZnY7o+03d9iAHVC7XPAqPVUkKJp610U f/o3DwDUGSwCXC0lmvgs9Q/02lWWvo8/DKlN25ilmmaJvldtMhxYtH7yKKwJMxk9CSGE+OMNoEBB Ob6UnaykOJilnGB5EaPWdjnrl6CfPrPnwt7/nAcHEwEdd4LmTQmnBiqQjFrYq9JBKf2TV8X8UDQq Ln7Q2RksKSVy+YLipEY38HG07WPXoWzyN6vAixZ4Zk44V2j5jW9Xf7Bc1aQTXOPEEaHv07WnWOOQ iyMSKkX59TjlUQ93kNOZBkxMDYWMwLUI3iOgyskbYvZb1Od6kuFJzKjdIaqNmUY2VQVY9Kl38qN6 gu3Yn7ytbRx1zCu2ZXvgyD5j1ytjdqAMxXDx5zbJZYj/Tw9n+jNeMMWt7jnJ7qzUVtd65JNavUq1 ujNSa3pEl531+RQVXYM8GtK/ruHPhjQUcO0WgWvTHdWYe2bpAdtLfW9+f79+By5LeYc5BSGEEOK7 +w3+DtQDSbzxAjc5q5sURa/smT2uYlQhiTNUTUPb+Ke+egzxXufcTmCKeE6sWHxwjccdrArSNDt4 zE4aQ+VMJ1+ttjZwKOIFCVWMN+zU95BuLyvKbldkaoVTFbRKBSVdccd2LDStxNS3blIlIU6VZ8cq j4le07FgFrG4mnGttnAed+sqW65m2HQuIsKuymwakb7TXRgvlhSmS9vUHq81JUlfk5gXx6XvL8bs 6NmIrct8VX1mN9ykGnb7cSAA5Hdll56qnFY08tvt5a3p7d23MUq5trHzrY465vEadtrOL+3drEJy s72wLl7Gj3VxXKyLd4nZ4XhWz9uMw4hhdYEf7NspQcfQClar3cWCGatVhlY5ffvOf4pGtWpgGAZG db0rXxonFHoDQ3m6jlpNI7u9PfC9N9tHib43DeiNUlr/+BdtfHrP/saD7GEuhBDi/3IABV9mFwwu Y7I8Iw77jK4UWh+aexJIHftjkyLs8TlYkGQZabLkKoy2dzU7ynucU0PXCq5nV6R5TpYXKNopWnHD 7ColLzLiqM/FvDh4zC7D7WAmPj1/QZLlZHFIfzhDdX6k9ZaM6DZkvHHOwWSJbjs0AKXZplNdMuiO uIxTsjQlXkQEVyWGKmqLj47KzOsyvUpIs5QkviIMF9+SaaXhYjFnfDFHaTn8Mk/9UrnZVUi0SMjy giKLubnJUDRtT2KocvqDSjqPWGY5eV6uEvWqDvElsySnyBMuB2Oi7GHzA2jERFFCnmfsWyGpajok M2ZxRp7l5VK7EjErb899+Jr6VE85VTKuoyVZkZMtA/r+svRVmI6NvpzgBUvSPCNdBAyn8UYu/lLb eF6HLx+zcw2uSzX26flXxOk6ptEifWzvLfLAY3CZkOUZyeUALyxofbRLP914VtdvjNlzOcsw5CpO yYuCPFmyyECvqnsngexOg3TS4VNwRZwkJPGCsN9mFBu0XfO79NvVeg11OWV0GZNl63q+iFIMq7Z3 wPa8fbzU96YEvRFpa4B33qA7cCj83tPfydvTJvPLT9Rr7Y2d+4QQQog/5ADqhHqnjfJzl1a9gTO6 peZNGTb3z79r5xOCcZ37aQe70aBpdxhHKW9Zxfb2cxq0+y7arEOzbtGNMjC7jNoa824Ts2bTuzTp j+yNxGLPMc+yegd/2uV01sOxTKy2z701IRg23rRor/Z5hJ2MaVsmDWfCnTXG75nfrqszndL5YY7n NGk0W7i9gOWXMmdWaAwDJg4EPZtmo4ndHhJtbn+tmDitgtVKxXbMrRgeLLdYMu05WKaBYbWZFg6T gb03UWt0PWwC3EadVn9e6imA7g7omSv6tknN6vCz9olRu/IUZ82m360S988xrTZ+sm8s9AmvkTH5 a4O6M6Jc+lwiZrzhPnxNfSpNuiMHQpeGUcceLjkfeTTL3nRGF3/cIvNdmqaFO46x+23Ovo1uXmob e+qwxDHb2X2H6bSNGvVwmk1s1yNYre8E9XxMMDxjNXawTAtnuKLmBYzPy89KPKvrt8ZsjyIJ8dwW pmFQd8bcWWNGzv5Hz7rjEwzrfJn2cM7POXe6+Hc1vGBKu/p9em6l6TH1zlgNXaxGg1Z3SmH7TH6l wH3t41DfmwY9RonFwGuiAorZY2DnTHo+8cE2KU+lhBBC/L7+9PXr16/f7/QJvm0zd+cErqxsF0II IYQQQvxv+7OEQAghhBBCCCFkACWEEEIIIYQQMoASQgghhBBCiN/Dd34HSgghhBBCCCH+OOQJlBBC CCGEEELIAEoIIYQQQgghZAAlhBBCCCGEEL+L/wA6YqQnbgBhpAAAAABJRU5ErkJggg== --=-qI52RwCVBFdMoYju/qZy--