From nobody Thu Apr 1 20:20: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 9C6673A2EF5 for ; Thu, 1 Apr 2021 20:20:56 -0700 (PDT) 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 (2048-bit key) header.d=fsij.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 BNSlOcvX_2PD for ; Thu, 1 Apr 2021 20:20:51 -0700 (PDT) Received: from akagi.fsij.org (akagi.fsij.org [217.70.189.144]) (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 7B6753A2EF4 for ; Thu, 1 Apr 2021 20:20:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=fsij.org; s=main; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To: 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=SXhioxe/BamHDatCcQTEJ6EcZvguGCFklowNguGkQSQ=; b=hYhs6DhJF7ecPaOh7JnYWTglvg w8sKdzvyNYFT/MeW7n1BfWwunmqHMEiebK00qPqph6L+lCEVr+ZGCEGedw8K9k/+P6B2WG9yFLls9 vb9YFPA2CnH/FLRL6hIDVvqJiGTESoC5VzEaGHmuXoyWInmJBF4TKFbzwLXVirK6ywHD56gf3ifv/ 4jRoITbwX+lGzzh/aeluz8FHJivFWgqNwrpH8ozaxvIEkqLFgMR6ZbVm5WiEbI5ij177HTqhydTcn sFN/n4TNC68SyPQVby/qcKRby7ysN6Kjn8fytV8a2kiOAaW2kvcePMPtAvxalzohL7VlxgyOF/A8R rOYRd0Eg==; Received: from m014008080161.v4.enabler.ne.jp ([14.8.80.161] helo=iwagami.gniibe.org) by akagi.fsij.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lSAMY-0008CR-Gi; Fri, 02 Apr 2021 05:20:47 +0200 Received: by iwagami.gniibe.org (sSMTP sendmail emulation); Fri, 02 Apr 2021 12:20:41 +0900 From: NIIBE Yutaka To: Florian Weimer Cc: openpgp@ietf.org In-Reply-To: <875z1awebr.fsf@mid.deneb.enyo.de> References: <87eeg42gti.fsf@fifthhorseman.net> <87im5ebfgf.fsf@iwagami.gniibe.org> <87r1jypfbc.fsf@jumper.gniibe.org> <875z1awebr.fsf@mid.deneb.enyo.de> Date: Fri, 02 Apr 2021 12:20:41 +0900 Message-ID: <87r1jtwewm.fsf@iwagami.gniibe.org> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [openpgp] Algorithm-specific data: problems with Simple Octet Strings, and possible alternatives 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, 02 Apr 2021 03:20:57 -0000 Florian Weimer wrote: > Let me note again that zero-stripping for MPIs affects RSA as well and > makes OpenPGP inconsistent with its normative references. I think that you mean "Algorithm-Specific Fields for RSA signatures" in RFC 4880. "RSA signature value m**d mod n" may be interpreted as "an integer signature representative s" in "RSA signature" in RFC 3447 (now RFC 8017), I mean, the small "s" (instead of large S = I2OSP (s,k)). It is a bit difficult interpretation (but not impossible). Otherwise, I agree that it's inconsistent. -- From nobody Fri Apr 16 07:24: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 67C043A27D2 for ; Fri, 16 Apr 2021 07:24:44 -0700 (PDT) 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 xTMgYmgm36zN for ; Fri, 16 Apr 2021 07:24:40 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [202.61.250.5]) (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 D1FEA3A27D1 for ; Fri, 16 Apr 2021 07:24:39 -0700 (PDT) Received: from p5de92c26.dip0.t-ipconnect.de ([93.233.44.38] helo=forster.huenfield.org) by mail.dasr.de with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lXPOd-0003yx-5k for openpgp@ietf.org; Fri, 16 Apr 2021 16:24:35 +0200 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 1lXPOc-0007Bn-M7 for openpgp@ietf.org; Fri, 16 Apr 2021 16:24:34 +0200 Date: Fri, 16 Apr 2021 16:24:34 +0200 Message-ID: <87zgxynw7x.wl-neal@walfield.org> From: "Neal H. Walfield" To: openpgp@ietf.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/27 (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] Intended Recipient observation 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, 16 Apr 2021 14:24:44 -0000 Hi, I just encountered a complication when respecting the Intended Recipient subpacket. Others might find this useful. Consider. Alice has a certificate A with an encryption subkey S. The encryption key is stored externally on something like an HSM (in my case, gpg agent). The key is addressable by its grip (basically a hash of its public MPI). https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=doc/Notes;h=d420ff0aca38732cc1c867f317529f3e34e92207;hb=refs/heads/master#l87 Mallory creates certificate M and adopts S. This is possible, because unlike signing subkeys, encryption subkeys do not need a backsig. Alice imports the certificate M into her local keystore. She now has two certificates with the subkey S. Alice receives a signed and encrypted message. The message is encrypted to S (the PKESK's recipient field has the keyid of S, S'), and A is listed as an intended recipient in the signature. Alice's OpenPGP implementation looks in her keystore for a certificate with S' and finds M. She sees that S is in her HSM, so she decrypts the message using the HSM. It works. Alice's OpenPGP implementation now checks whether M is in the set of intended recipients. Since it isn't, her OpenPGP implementation marks the signature as invalid. Ouch. Marking the key in a special way (e.g., A is a personal key, and only personal keys should be used for decryption) is not sufficient. I'm aware of people who use the same key material on multiple certificates: $ gpg --with-keygrip -k XXX pub dsa1024/0xE0BB1C42B6A8C559 2002-03-01 [SCA] Key fingerprint = 8C88 F05D EE7E 7A36 075F 609B E0BB 1C42 B6A8 C559 Keygrip = 08E03C5C2B608ABBE643F4CCDC15AB1266E6F847 ... sub rsa2048/0x6374E7B91E8D8306 2016-01-27 [A] Keygrip = FAF3D6010613E9D1E3D66C4F81DA6914052C6DE3 sub rsa2048/0xCB3A5ACDBA0C288F 2016-01-27 [E] Keygrip = F270EF185112798820DB4AC669BC0CB1DC5523BE sub rsa2048/0x44C4193E2D42869B 2016-01-27 [S] Keygrip = 6931F49B045414D50AFE18240BB96C4610AA018E pub dsa3072/0xDCF666F298FA0DCF 2021-01-06 [SC] Key fingerprint = 3361 C438 401F C9C9 D52C DDC7 DCF6 66F2 98FA 0DCF Keygrip = DA44D0AD8506E6CB0ECDE60DF9925D5A6AD05F3C ... sub rsa2048/0x46E8EF0E42FE802B 2021-01-06 [A] Keygrip = FAF3D6010613E9D1E3D66C4F81DA6914052C6DE3 sub rsa2048/0x940C2C3BDB9A2EF6 2021-01-06 [E] Keygrip = F270EF185112798820DB4AC669BC0CB1DC5523BE sub rsa2048/0xB86888BABA9CD070 2021-01-06 [S] Keygrip = 6931F49B045414D50AFE18240BB96C4610AA018E (In this person's case, the subkeys happily have different fingerprints, but this need not be the case.) So it seems that when checking the intended recipients, it is necessary to check whether any of the certificates with S is listed, not just the first one that happens to have that subkey, which is my case was sufficient to decrypt the message. :) Neal From nobody Fri Apr 16 09:31: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 669233A2BBE for ; Fri, 16 Apr 2021 09:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 AN1NnOlTM6FY for ; Fri, 16 Apr 2021 09:31:03 -0700 (PDT) Received: from smtp5.hushmail.com (smtp5.hushmail.com [65.39.178.142]) (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 812DC3A2BBC for ; Fri, 16 Apr 2021 09:31:03 -0700 (PDT) Received: from smtp5.hushmail.com (localhost [127.0.0.1]) by smtp5.hushmail.com (Postfix) with SMTP id AE9B820174 for ; Fri, 16 Apr 2021 16:31:01 +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=oDzIXC4xbY0TSqAnX6FiKP9Ei3MQpmq3KSf3wngvdqM=; b=f9wwEvXpTSNazJfRnNM53gMe+1QHAswf4E6PoxA9u1ifV6KnmMULTNJVZOL8nHxZDox1hic19nB9l+y5Ka8/tkEdYDm2VQeIcUY239pqwyvSjZGe3xAx0AhVvoH49GC6NrpuO0FHIFV6Q7J/JSxGivC78Ed6GDP1wbAHTrfs2+MixjE2Lzx8GY+/Vr7z9TokIYDG70r8+yst04kQKozilpITZGakw5Avs7yhem0tTdEnZUgjIwVQNcUHS0HacroEPDbc0cfzgKdyDO6PkQmFgf3vuWwRFUPVqhAk2oM7uX2fs9lWxuf4EUg/il52VROo8wHaqYcmvR2RNoB/77Dr4A== Received: from smtp.hushmail.com (w7.hushmail.com [65.39.178.32]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp5.hushmail.com (Postfix) with ESMTPS; Fri, 16 Apr 2021 16:31:01 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 48) id 3A49E80614A; Fri, 16 Apr 2021 16:31:01 +0000 (UTC) MIME-Version: 1.0 Date: Fri, 16 Apr 2021 12:31:01 -0400 To: "Neal H. Walfield" , "openpgp" From: vedaal@nym.hush.com In-Reply-To: <87zgxynw7x.wl-neal@walfield.org> X-hush-end-of-body-position: 70 Content-Type: multipart/alternative; boundary="=_3aef84a64d7902218c037f40e5e6f5d0" Message-Id: <20210416163101.3A49E80614A@smtp.hushmail.com> Archived-At: Subject: Re: [openpgp] Intended Recipient observation 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, 16 Apr 2021 16:31:08 -0000 --=_3aef84a64d7902218c037f40e5e6f5d0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" On 4/16/2021 at 10:24 AM, "Neal H. Walfield" wrote:I just encountered a complication when respecting the Intended Recipient subpacket. Others might find this useful. Consider. Alice has a certificate A with an encryption subkey S. T Mallory creates certificate M and adopts S. This is possible, because unlike signing subkeys, encryption subkeys do not need a backsig. Alice imports the certificate M into her local keystore. ===== Why would Alice want to import M's key? Unless M was once a friend of Alice, and unsuspected by her, now bears her ill will, and is familiar with her encryption subkey S, and now created a new certificate M' with her encryption subkey S, and sends it to the server. Still, in order for her to Import M' as a new key by M, she would check first if M' was also signed by M. If she then sees a decryption problem, she would (thanks to your pointing this out), check for duplicate subkey S in her keyring, and then find out that M does bear her ill will. As most users are familiar with their encryption subkey's fingerprint, it would be a good idea to check any prospective public key for an encryption subkey fingerprint, before importing it. Thanks for pointing this out. (Doesn't affect me though, as am from old school that doesn't use subkeys, where the primary certificate signs, decrypts and authenticates). vedaal --=_3aef84a64d7902218c037f40e5e6f5d0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8" On = 4/16/2021 at 10:24 AM, "Neal H. Walfield" <neal@walfield.org> wrote:<= blockquote style=3D"border-left:solid 1px #ccc;margin-left:10px;padding-lef= t:10px;">I just encountered a complication when respecting the Intended
= Recipient subpacket. Others might find this useful. Consider.

Alic= e has a certificate A with an encryption subkey S. T
Mallory creates ce= rtificate M and adopts S. This is possible, because
unlike signing subk= eys, encryption subkeys do not need a backsig.

Alice imports the cer= tificate M into her local keystore. 

=3D=3D=3D=3D=3D

Why= would Alice want to import M's key?

Unless M was once a friend of A= lice, and unsuspected by her, now bears her ill will,
and is familiar wi= th her encryption subkey S, and now created a new certificate M'
with he= r encryption subkey S, and sends it to the server.

Still, in order f= or her to Import M' as a new key by M, she would check first if M' was also= signed by M.
If she then sees a decryption problem, she would (thanks t= o your pointing this out), 
check for duplicate subkey S in her key= ring, and then find out that M does bear her ill will.

As most users= are familiar with their encryption subkey's fingerprint, it would be a goo= d idea to check any prospective public key for an encryption subkey fingerp= rint, before importing it.

Thanks for pointing this out.
(Doesn't= affect me though, as am from old school that doesn't use subkeys,
where= the primary certificate signs, decrypts and authenticates).

vedaal<= br>


 --=_3aef84a64d7902218c037f40e5e6f5d0-- From nobody Fri Apr 16 09:42: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 A05E63A2BFF for ; Fri, 16 Apr 2021 09:42:12 -0700 (PDT) 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 xINGiTj2ZN9j for ; Fri, 16 Apr 2021 09:42:07 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [202.61.250.5]) (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 CB22D3A2518 for ; Fri, 16 Apr 2021 09:42:06 -0700 (PDT) Received: from p5de92c26.dip0.t-ipconnect.de ([93.233.44.38] helo=forster.huenfield.org) by mail.dasr.de with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lXRXb-00067Q-8S; Fri, 16 Apr 2021 18:41:59 +0200 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 1lXRXa-0000UX-OK; Fri, 16 Apr 2021 18:41:58 +0200 Date: Fri, 16 Apr 2021 18:41:58 +0200 Message-ID: <87y2dinpux.wl-neal@walfield.org> From: "Neal H. Walfield" To: vedaal@nym.hush.com Cc: "openpgp" In-Reply-To: <20210416163101.3A49E80614A@smtp.hushmail.com> References: <87zgxynw7x.wl-neal@walfield.org> <20210416163101.3A49E80614A@smtp.hushmail.com> 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/27 (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] Intended Recipient observation 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, 16 Apr 2021 16:42:13 -0000 On Fri, 16 Apr 2021 18:31:01 +0200, vedaal@nym.hush.com wrote: > On 4/16/2021 at 10:24 AM, "Neal H. Walfield" wrote: > Why would Alice want to import M's key? In the software that I'm working on the "keyring" is simply a cache. We aggresively harvest all keys that we encounter (storage is cheap), and rely on our trust model to separate the wheat from the chaff. > Still, in order for her to Import M' as a new key by M, she would check first if M' was also signed by M. > If she then sees a decryption problem, she would (thanks to your pointing this out), > check for duplicate subkey S in her keyring, and then find out that M does bear her ill will. In my opinion, we should shift as little complexity as possible to the user. In our case, this means that Sequoia has to worry about a lot more corner cases, such as this one, but I think it is worth it. > As most users are familiar with their encryption subkey's > fingerprint, it would be a good idea to check any prospective > public key for an encryption subkey fingerprint, before importing > it. The user population that I'm targetting doesn't understand how to do this nor do they want to learn about these nuances. > Thanks for pointing this out. > (Doesn't affect me though, as am from old school that doesn't use subkeys, > where the primary certificate signs, decrypts and authenticates). Thanks for the feedback! :) Neal From nobody Wed Apr 28 08:54:53 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 D0D7C3A11E5 for ; Wed, 28 Apr 2021 08:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.819 X-Spam-Level: X-Spam-Status: No, score=-2.819 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_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=protonmail.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 E1guDvnRCza2 for ; Wed, 28 Apr 2021 08:54:41 -0700 (PDT) Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch [185.70.40.133]) (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 0EE043A11EB for ; Wed, 28 Apr 2021 08:54:40 -0700 (PDT) Date: Wed, 28 Apr 2021 15:54:22 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1619625278; bh=opZKob3M+OwvHuL8gSWbHGnp985/bFW9y6h2VvDz0KA=; h=Date:To:From:Reply-To:Subject:From; b=ua/AbRhDIckl3g9Ph7XoNZA/mzfiRFWats5tfVHs9TiPytH8YPKP+5KQxrtAa5CQT xx3I7SmFfOuAcGOoVyMiRbWRKBsM/cGtWlnAkOw+JCF1Xisxi+fCGv+QSrPMIt0ans +a1f9Okdt1br0TUV+bLijlYFP3dw+wrQXCOqwcUQ= To: "openpgp@ietf.org" From: Daniel Huigens Reply-To: Daniel Huigens Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [openpgp] Ed25519 in a draft 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, 28 Apr 2021 15:54:52 -0000 Hi all, and dear editors, Would it be possible to get a new draft out with Ed25519 in it? (I'm not sure if this work is blocked by anything, but I'm sending this email purely in case some encouragement is helpful ^.^ Let me know if I can do anything more helpful than that.) We (OpenPGP.js) would like to switch to generating ECC keys by default, and the current situation where Ed25519 is not in any non-expired draft is a bit awkward, in that context. (FWIW, I also care about a bunch of other stuff in rfc4880bis, but this one seems the most uncontroversial to me ^.^) Thanks for all your work! Best, Daniel Huigens From nobody Wed Apr 28 09:04: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 E9A253A122B for ; Wed, 28 Apr 2021 09:03:58 -0700 (PDT) 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 V0ESLt7kIvPr for ; Wed, 28 Apr 2021 09:03:53 -0700 (PDT) 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 BA2213A1285 for ; Wed, 28 Apr 2021 09:03:51 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4FVk2Y1HQVzKGy; Wed, 28 Apr 2021 18:03:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1619625829; bh=vKPmBlMtZsmihU0X2pvXPtn2Pr+sdiYEGV2TPwrBzWw=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=tRfUPid4qsOZz1hza2HLeW0XSotM26T1XFBi6EeABIw65HG91FDhpJm3GH3faZll3 qvjvx/edKv6fnfhHofYET7Bcc2553jQHOZH1HEZ56v1iR85IOq7lgzWTrPb14Wtq81 iGIPMNrjMwlHnX3hb14ZU8pUiJhz274ykPhW4hpc= 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 i2kFrbViVjyM; Wed, 28 Apr 2021 18:03:48 +0200 (CEST) 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; Wed, 28 Apr 2021 18:03:48 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 02C8C6029A70; Wed, 28 Apr 2021 12:03:46 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id EE4E766B7C; Wed, 28 Apr 2021 12:03:46 -0400 (EDT) Date: Wed, 28 Apr 2021 12:03:46 -0400 (EDT) From: Paul Wouters To: Daniel Huigens cc: "openpgp@ietf.org" In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [openpgp] Ed25519 in a draft 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, 28 Apr 2021 16:04:03 -0000 On Wed, 28 Apr 2021, Daniel Huigens wrote: > Would it be possible to get a new draft out with Ed25519 in it? Apologies. we will get an updated draft out today. > We (OpenPGP.js) would like to switch to generating ECC keys by > default, and the current situation where Ed25519 is not in any > non-expired draft is a bit awkward, in that context. understood. Paul From nobody Wed Apr 28 13:02:08 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 E79283A1E38 for ; Wed, 28 Apr 2021 13:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.598 X-Spam-Level: X-Spam-Status: No, score=-1.598 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gEp-yZ-58Dom for ; Wed, 28 Apr 2021 13:02:05 -0700 (PDT) Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) (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 9EE023A1E37 for ; Wed, 28 Apr 2021 13:02:05 -0700 (PDT) Received: by mail-ej1-x632.google.com with SMTP id mu3so5350913ejc.6 for ; Wed, 28 Apr 2021 13:02:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:mime-version:date:reply-to:message-id; bh=DcQZk4qo3zPmOIAzOU4ZNTaKfpC7F7V7UTu/qd++Mgw=; b=g4bw52hzrbRLlPfHmZ+/1RqtOGnGpVKWx89gyzEQ9h7ABWUPyz9bGwRFosZYu1msB/ JRl5uNnpAopQ+9gXanDgw7YsM7FN5mxlIvslGInaPE6F2Mq6u6kW1d0on9GgIr4CkYAC 3xY6GmuefaFfD/nHrSFT5JJwCEwV78n9mX1U8bgmlrzyo8ahG3vhAnr5UvWhFYvgvfjS zJwef5LNj18yhvHcwplUIxGf3ZT/cX+bdSqlXaruoSkI0tGj9ZME0cryJUTsiax5wDg3 0JHxPYPvDzntuIlzNLBcL9VxgPvaJgRQq+jIOdaQgQ7LZ2C/SMP/R99P62yvjzAeMqK6 r57w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:mime-version:date:reply-to :message-id; bh=DcQZk4qo3zPmOIAzOU4ZNTaKfpC7F7V7UTu/qd++Mgw=; b=b8Oq++k1ZZGEuP80g2/s/5sgDLeGDsSZs4jzlnmqyBa4lkJWX5KpJHfpX6b6RC9I/I mrxbtb57rbhTThKZ8x/Wd5vm6/34fYa3nn5RYImMTHwxTBEWFeib6PUt3pIvf4dQtdCG pUYfGp/WXoVazQtG8QONG2SSPy2Gr59SXnI2QbzaW8o8p0A1xqLkWJ48PhVP9ah+xLeW 00g2srLYAFiwsiPC0x/nadmOVP1gWxh4pKwQyKfJzJ7kEbDPdszAa55MPmgci8BQYxVV +yPioaM8o6Tw9Fk9wClpn0ceH8qZj4zAEupP3K4cfZZ8Min9AWF3oRTwlCNbzAw3MutH 2Jvg== X-Gm-Message-State: AOAM5317pUmzRxISbsK1Br3Wte8jYeNfUrA/gJ+XQIOZ7cdM1lGG0EcG WO4JMsPjXxPQsLnrxoG+uycLvwCgM5o= X-Google-Smtp-Source: ABdhPJy0mMxiRUlb4n9EkJxlvf7hSHsosoFresM3UQjkULKGdcGjdFxRl3AhBfm0z/iiw1yMfV38tQ== X-Received: by 2002:a17:906:c836:: with SMTP id dd22mr4762676ejb.427.1619640121611; Wed, 28 Apr 2021 13:02:01 -0700 (PDT) Received: from f30.my.com (f30.my.com. [185.30.177.92]) by smtp.gmail.com with ESMTPSA id z11sm457967ejc.122.2021.04.28.13.02.00 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Apr 2021 13:02:01 -0700 (PDT) X-Mailru-Internal-From: vietthangdang76@gmail.com From: vietthangdang76@gmail.com To: openpgp@ietf.org, =?UTF-8?B?VmlldCBUaGFuZyBEYW5n?= MIME-Version: 1.0 X-Mailer: My.com Mailer 1.0 Date: Wed, 28 Apr 2021 23:02:00 +0300 X-Letter-Fingerprint: tNTdwfVzDJWlTH1iC4yXGzW80UCMRSBE X-Priority: 3 (Normal) X-Mailru-Compose-Stats: =?UTF-8?B?eyJVc2VyU2Vzc2lvblRpbWUiOjczMDE3MSwiSG9zdCI6ImUtYWoubXkuY29t?= =?UTF-8?B?In0=?= Reply-To: vietthangdang76@gmail.com Message-ID: <1619640120.648937005@f30.my.com> Content-Type: multipart/mixed; boundary="----9d99d5f41f76490c814b445592cc5d39-ucvE7sHkK58xdns9-1619640120" X-7564579A: EEAE043A70213CC8 X-77F55803: 68A6F98766B02875A0F21CC061F2095323D2FBEB2644075C88316D329552D91DFDFD98CC4DA7C75764904806EFFF663DEE8B5C298AC693B0 X-C1DE0DAB: 0D63561A33F958A5997A70D648F8B93FEED85A0BE69C7B679FEAC331D6C292F58E8E86DC7131B365E7726E8460B7C23C X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D3498EF79680EE3725CE241618509A8BC459FAD7D2CE387F798C507797140C87970E3AC6EC11E16902F1D7E09C32AA3244C2EB01FD0CAD3C7B654433CB221B569F551E887DA02A9F7BF729B2BEF169E0186 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5+wYjsrrSY/u8Y3PrTqANeitKFiSd6Yd7yPpbiiZ/d5BsxIjK0jGQgCHUM3Ry2Lt2G3MDkMauH3h0dBdQGj+BB/iPzQYh7XS329fgu+/vnDhpX5b7RiMo2BOYqaNPD9i5w== X-Mailru-Sender: 6621552DE5F8A32521149D0F3756178F0A5FE7B9C95CDCD58042664A838FF6E67679BAC3386AB9C828E3B031584DD82D4598FC5372097033BA79896850B0E8BD835FBBB63573708922B820C1B2086D890DA7A0AF5A3A8387 X-Mras: Ok X-Spam: undefined Archived-At: Subject: [openpgp] =?utf-8?q?image-29-04-21-06-01=2Ejpeg?= 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, 28 Apr 2021 20:02:07 -0000 ------9d99d5f41f76490c814b445592cc5d39-ucvE7sHkK58xdns9-1619640120 Content-Type: multipart/alternative; boundary="--ALT--9d99d5f41f76490c814b445592cc5d391619640120" ----ALT--9d99d5f41f76490c814b445592cc5d391619640120 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 CgoKVmlldHRoYW5nIERhbmcgVCBH4butaSB04burIOG7qG5nIGThu6VuZyBjaG8gR21haWwK ----ALT--9d99d5f41f76490c814b445592cc5d391619640120 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 CjxIVE1MPjxCT0RZPjxkaXYgaWQ9ImNvbXBvc2VXZWJWaWV3X2VkaXRhYmxlX2NvbnRlbnQiIGRh dGEtbWFpbHJ1YXBwLWNvbXBvc2UtaWQ9ImNvbXBvc2VXZWJWaWV3X2VkaXRhYmxlX2NvbnRlbnQi IHN0eWxlPSJ0ZXh0LWFsaWduOiBsZWZ0OyI+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+ PGRpdiBpZD0ibWFpbC1hcHAtYXV0by1zaWduYXR1cmUiPgoKVmlldHRoYW5nIERhbmcgVCBH4but aSB04burIOG7qG5nIGThu6VuZyBjaG8gR21haWwKPC9kaXY+PGRpdiBpZD0iY29tcG9zZVdlYlZp ZXdfcHJldmlvdXNlX2NvbnRlbnQiIGRhdGEtbWFpbHJ1YXBwLWNvbXBvc2UtaWQ9ImNvbXBvc2VX ZWJWaWV3X3ByZXZpb3VzZV9jb250ZW50Ij48L2Rpdj48L2Rpdj48L0JPRFk+PC9IVE1MPgo= ----ALT--9d99d5f41f76490c814b445592cc5d391619640120-- ------9d99d5f41f76490c814b445592cc5d39-ucvE7sHkK58xdns9-1619640120 Content-Type: image/jpeg; name="=?UTF-8?B?aW1hZ2UtMjktMDQtMjEtMDYtMDEuanBlZw==?=" Content-Disposition: attachment; filename="=?UTF-8?B?aW1hZ2UtMjktMDQtMjEtMDYtMDEuanBlZw==?=" Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQAASABIAAD/4QBMRXhpZgAATU0AKgAAAAgAAYdpAAQAAAABAAAAGgAAAAAA A6ABAAMAAAABAAEAAKACAAQAAAABAAAAQKADAAQAAAABAAAAQAAAAAD/7QA4UGhvdG9zaG9wIDMu MAA4QklNBAQAAAAAAAA4QklNBCUAAAAAABDUHYzZjwCyBOmACZjs+EJ+/8AAEQgAQABAAwEiAAIR AQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAAB fQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5 OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeo qaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMB AQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYS QVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNU VVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5 usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/bAEMAAQEBAQEBAgEBAgMCAgID BAMDAwMEBQQEBAQEBQYFBQUFBQUGBgYGBgYGBgcHBwcHBwgICAgICQkJCQkJCQkJCf/bAEMBAQEB AgICBAICBAkGBQYJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJ CQkJCf/dAAQABP/aAAwDAQACEQMRAD8A/bz/AILBf8FgfEf7OPiif9l/9mSeFPFcUKNrWskCX+zj Ku9Le3U5U3BQq7s4ZUVgoBckp/I94z+LfxD+I2uS+JfHut3+s6hOxaS4vbiSeRievzSEn8OlcN8T fiXr3xL+I2vfETxNK02oa5qFxfXDMxYmS4kaRufQE4HtVTwb4X8ZfELWF0HwVYTahdNyVjB2ov8A ekY/Ki+7Ee3PFf7oeG/BPDHh3w59YxMqdJU4c1avUcYrb3pSnJpRguibUUvO7f8ABfEmYZvxTmqw 9CM6jnLlp04JyfkoxV25P0u39xsf29ff89X/AO+jR/b19/z1f/vo16L8Rv2b/i38NdMj1nULdNQt iF85rJmlaBiOVdcZIB43jIzjOK+df7UPr+pr6/wr8duEeOMt/tfhDMKWLoJ8rlSkpJSX2ZLeL62k k7WezTPO4+8Ic/4Wxv8AZ3EeDnh6rV1GcWrrvF7SXmm1fTdM9F/t6+/56v8A99Gj+3r7/nq//fRr zr+1T6n8zXfeE/A/i3xnCbzSkWK1VihnmYhNw7AD5m/AYHrX32P4jwmFp+1xM1GPd2XyXd+S1K8O vB3iHi7M4ZNwxgqmKxEtoU4uTt3fSMV1lJqK6tHZ+DPi38QvhzrcXiXwFrd9o2oQMGS5sriSCVSO nzRsDj26V/XH/wAEgP8AgsJ4k/aR8UwfswftOTQv4rkhZtF1lVWL+0fJXc9vcIuEFzsBdHQKsiqQ QHAL/wAZXiDSvEHha5FrrkDQls7WBLI2P7rDg/zrZ+GXxL174afEfQfiJ4ZlaLUdDv7e+t3VipEl vIsi8jsSuD7da/JvGTwtyXjHKKmHxNOPtuVunUSXNGVtNd3FvSUb2a87Ne9l1PiDgnO5ZfmVGpQq U5WqUailFrunGSTTs7p27PVPX//Q/Frw+tvrfjiy0e6LeTd3scLBTg7ZJApweecGv6GfBul/DzwB oieGfCOnQ6PEpAYIAPMIzgvJ95zz1av5xvAmoA/FXSICP+Yrbr1/6bqK/oR8REhHI6jP9a/MP2/H EmY18y4cyVYiaw06dacqak1CU1KCjKUfhlKKuotptXdrXd/7C/ZD8G5fWwmc4+rSi60Z0oxnZcyi 4zbinuk3ZtLeyvsbviKRS52NnKtn8foAP1/xPxv8U/2ffh540nbVPIbTb6VtzTWm1AxPdkIKHp2A PJ5zX7K/tXeG/C/g39hD4F+MPDml2lpqesS3S39zFCiTXIWN8CWQAM2MAjJ681j/AAo/ZU+B9l+z 5pf7T37YXi658M6L4lmMOg6XpqJLd3YXf853I5y21mCgABACxBYCv84foxZdxfwHxZ7XhvHyo1PY 06sqkJuEeScYz5al3yySckuWSkm7WR/pRxbiOCuKeHY/63ZesRQlXqUYUpU/azlUpznD93GKclJq EpXi1aN7tK5+Hnh/9nbwH4VlN9dCTVJlyy/acbFx0wigA4/2t3+Hf36KkIjQYUcAAcYAr9nfiV+x /wDsPfD74F+HP2mtR+KWqal4F8Ra3/Z4v7CyjlaGFopyEeNdzGaOWEpIwGOSQnHPD+Ov2Cf2IvFX 7H/if9rrwb8U/EQ8P6XBcxaW+oWcVpBfajGu2GCONoxNKr3AWMkdCGIICkj/AHZ8OfGPNK9eGN4o xU8RV2TbutbaK3uxX+FL5n3Hgfxf4YcFYOnhOGctnhKFWt7G8MJVXNX5nH2c5cnNKondcs3zJeR+ IPiPU/D88DWd4sd4rj/VgBweo5PQY+ufavhrXp7Sz8ZT2tkphhjuNqx5zgA9MnFfS6/eGa+QvF98 I/iFd25H/L1jr6sO2K/1E8MuN8VmMX7WyjGOiXr1e7f4eR/MX7dfgnLFwJk+bqhH6ysUqftOVc/I 6NWThzWvy80U7XtdXP/R/Av4dXkjfFzQlc5zq9sD/wB/196/pA8QqWVlXqcj+dfyvjX73SfEP9ta a7Q3NtcedE6kZR0bcpGe4I4yPwr9b/g1/wAFFfDPi6SLw98bbdNFvCMLqNssj2kjdAJIwGeEn+9l k7kqK7/2xH0XuNuOXlPE3CmDeKp4OnVjVhDWqlJwkpRp7zWjuoc0lvy21X9L/s0PHXhfhGpmGTcQ 4hUJ4mdNwlLSm+VSTUp7Reqs5Wi+99D+o/xDoP7NX7S37Fvwo+GPi/4taX4I1Twik09xHOomctLv TYyll24BB754/HlviDp37K/7VHwB0L9lC6+LOm+HvEvwivHh0rWr5CmmatZvGFMq/Oij5WCECTcH jJwysDX4x3t1Zajaxanp0kc8FwA6SxMrq6kZBDKMEEdMHHtXnmqfdH1/xr/HzgjxheJxCoYjAQUv Zwo1HeopTjTSUU1zWjKLgndJO69Uf7C8P/R9bnGtg81qxUKs69G0aLVOdWUpSabptzjKM5xcZtq0 rqzSa/cJ9C/4JwXX7H/w6/Yxn+NemX+j6R4yGpeIdQZjbvciKK4e5ECHBihld0gilywwd4LkGuR/ 4KFeG/2cf2l9NtbfwR+0R4N8P+B/AWlPF4Z8IWUUjoDBB1d1ly88pURqRG2xMBVLFy/80y9F+tW5 nSONZJCFVQSSeAAK/wBh/Cuj9bnSnD3HolbXp5pn7tkP0SKmXZrSzqjntd1Kc6tT34YeS56z5qs0 pUuWM5L3OaKTjC8Y2Td7YOXzXwz8Qbp4/ibfovGLoYI69u+f6V6/4/8A2hfD/hyVtO8KhNUvFJDN kiCMj1YD5/op/Gvka58S3+veJf7c1Rg9xPMrvtwqk57DPA/z9f8AW3wuy7EYTC+0rx5brrv93+Z/ lJ+2J+lHwRxbk2C4J4bxixOJw+I9rUdP3qUUqdSHL7T4ZTvNXUOZRs1JqWh//9L+bf4y+BfEXwe+ Lnij4T+MU8nVfDWq3mmXaYOBNazNE+M9VJXKnuMGvNvtq/3v0r+7z/gu/wD8EI/GX7U3i66/bI/Y 1tYrjxrPEB4h8Olo4BqYgjwl3aOQq/a9qhJI3bEw2srK6kS/wy/Er4R/GH4M+JJPB3xb8K6t4Z1W LO601S0mtZcA4yElRSV9GGQexr/WXw58UcDxBgIV6NRe0sueF9Yvrp2vs9mj8EzbhueFquMlp0fc 9B+E/wC0P8R/g1dg+Eb4tYs4aawnG+2l/wCAn7h/2kKtwMkgYr9LPhn+1p8NviuV0y7/AOJFqp+b 7NcuDE+M8RTcBsDHDBGPYEAmvxR2X/8Az7yfkf8ACjZf/wDPvJ+R/wAK/BvHv6GfAvH1WWZYvDqh jn/y/pJRm+3tF8NVbL3lzpaRnFH9S/R1+mNxr4cVqdHAVvb4NPWhUbcLdeR/FTfVcvu31lCWx+nH jj4x+C/A0TQ3U/2u9XOLaAhmB4Pzt0TqDzzjoDXxt44+Nfi7xyHtLqf7JYtgfZoMhWAIPzt95+Rn B+XPQV4h5d/1+zyfkf8ACjZf/wDPvJ+R/wAK/RvCPwMyThKhH2N6tZfbl/7bFaR/F/3j7v6T/wC0 E8QfExTy+tV+qYB6ewotpSX/AE9n8VTzT5aez5L6m8LxAMA4H0r0r4N+BfEXxh+Lnhf4T+Dk87Vf Euq2emWiYODNdTLEhOOigtknsATXMfDX4R/GH4zeJI/B3wk8K6t4m1WXG200u0mupcE4yUiRiF9W OAO5r+5r/ghB/wAEI/GX7LPi61/bI/bKtYrfxrBER4e8Oho5xpgnjw93duAy/a9rMkcaHEI3MzM5 Ai+z8RvFHBZBgJ169Re0s+SN9ZPpp2vu9kvx/h7KOG54qqoRWnV9j//Z ------9d99d5f41f76490c814b445592cc5d39-ucvE7sHkK58xdns9-1619640120-- From nobody Wed Apr 28 20:58:34 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 694C93A2DB0 for ; Wed, 28 Apr 2021 20:58:32 -0700 (PDT) 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 zP6ol-RP2NAZ for ; Wed, 28 Apr 2021 20:58:27 -0700 (PDT) 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 6C40B3A2DAF for ; Wed, 28 Apr 2021 20:58:27 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4FW1v25Gsfz1K7; Thu, 29 Apr 2021 05:58:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1619668702; bh=uBDzpnOInkJ7X/6HU9JWJJIU+cRbpEj7utgYRSFsueI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=bERMBFL4rM7uy7/Va2znsk5h3QYME9Eg2+2WUoXXutKeQYKclW17oZ+PQQ1NRJEHY 5Q9Zc3RQbAR8uEgfIDcDaaOvfV1eOA2WqS1w362EwzdJ72Qh+idNdPqDT07U7dgnPI 8cSjtfLHoDAeJi89S8cRYzGHcaU/vmf6O8zY7bCo= 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 42r4ssPuqCnk; Thu, 29 Apr 2021 05:58:21 +0200 (CEST) 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; Thu, 29 Apr 2021 05:58:21 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 1B7BE6029A70; Wed, 28 Apr 2021 23:58:20 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 12BFF66B7C; Wed, 28 Apr 2021 23:58:20 -0400 (EDT) Date: Wed, 28 Apr 2021 23:58:19 -0400 (EDT) From: Paul Wouters To: =?ISO-8859-15?Q?=C1ngel?= cc: openpgp@ietf.org In-Reply-To: <9cf9ae77e21fa330918df0754707e9304a41fd36.camel@16bits.net> Message-ID: <2587c395-7ce0-c9dd-817c-1b53321a8ed@nohats.ca> References: <20210317145508.136021-1-dkg@fifthhorseman.net> <5a927ffed96b38efa08c58b6a29e565dff87a535.camel@16bits.net> <87blbfpr9b.fsf@wheatstone.g10code.de> <9cf9ae77e21fa330918df0754707e9304a41fd36.camel@16bits.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [openpgp] The checksum may appear 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, 29 Apr 2021 03:58:32 -0000 On Thu, 25 Mar 2021, Ángel wrote: It is not clear to me what the WG would like to do here on the "optional checksum" item. Ángel proposed something, Werner agreed, but then Ángel wasn't sure anymore. It would be good to get more and/or clarified views on this issue. Paul > On 2021-03-19 at 07:54 +0100, Werner Koch wrote: >> > -The checksum with its leading equal sign MAY appear on the first line >> > after the base64 encoded data. >> > +If present, the checksum with its leading equal sign SHALL appear on >> > the next line after the base64 encoded data. >> >> Adding "optional" and making the CRC a SHOULD create indeed clarifies >> the intention of the RFC. Thus I am in favor of this change. > > Note I wasn't placing the later. I only stated that you can only place > the checksum at the end. > I was planning to treat this as a feature request and add a phrase with > such SHOULD, since I agree it's a good idea, but turns out I can't come > out with a better rationale than “it's cheap enough it makes sense to > do it even if not giving much value”. > > What is the goal of the armor CRC? > The only good use case I can think of is when a human has been > involved, such as when restoring a key from paper. > > On other scenarios, the CRC would either be too weak (e.g. in presence > of an active attacker) or protecting from an error that would already > have been handled at lower layers. > [1] and [2] suggest it was added to avoid modem line noise altering the > messages (which nowadays should be discarded at e.g. TCP). > > Without a compelling use case, I don't think it should be a SHOULD. > And finally, we should at least mention why it was once considered > useful. > > > The original change is available in git mode at > https://gitlab.com/Angel-Gonzalez/rfc4880bis/-/tree/checksum-may-appear > > > Best regards > > 1- https://mailarchive.ietf.org/arch/msg/openpgp/3K6tSdebEjQw8K1z1pZkXxyvu-k/ > 2- https://mailarchive.ietf.org/arch/msg/openpgp/2FmAqP-nJkV08E1qQ4YNO2xR2Pc/ > > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp From nobody Wed Apr 28 20:59: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 264903A2DB4 for ; Wed, 28 Apr 2021 20:59:01 -0700 (PDT) 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 CNWwE-CbqqI0 for ; Wed, 28 Apr 2021 20:58:56 -0700 (PDT) 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 83F0A3A2DB0 for ; Wed, 28 Apr 2021 20:58:55 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4FW1vb3Ltsz1K7; Thu, 29 Apr 2021 05:58:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1619668731; bh=KKVZPrRlLRrENHAcPBMj5RVu8r/NCN5WRLkFsGDCTuA=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Mbsj3Kt2dx08MrSJlBDZwFQdqHNRZnBpi0uXXRXOh5HvLpoJNVyujCoZsR134y/Cb AtGoDBGHyJrK4kRAS20JzZfAxJxZ3jidUz5hDDkUx7Uqf0wLeo7vqp7mPBnfiCGQw8 8ycCHe1QMFeAabi0fa/8VSDjmMZ3yLvD/bgP34Jg= 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 8b7AyuFh4bRa; Thu, 29 Apr 2021 05:58:50 +0200 (CEST) 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; Thu, 29 Apr 2021 05:58:50 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id DFE856029A70; Wed, 28 Apr 2021 23:58:48 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id DE91966B7C; Wed, 28 Apr 2021 23:58:48 -0400 (EDT) Date: Wed, 28 Apr 2021 23:58:48 -0400 (EDT) From: Paul Wouters To: =?ISO-8859-15?Q?=C1ngel?= cc: openpgp@ietf.org In-Reply-To: Message-ID: References: <87wnu86mep.fsf@fifthhorseman.net> <20210324021213.333485-1-dkg@fifthhorseman.net> <87pmzp2taf.fsf@fifthhorseman.net> <26945b02701cdbcf7af0ebd3adaa325b91021be7.camel@16bits.net> <87blb72yto.fsf@fifthhorseman.net> <029c60b6a313d33cf5cc7e15791be8c0c582370c.camel@16bits.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-15 Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [openpgp] [RFC4880bis PATCH] Drop "Compatibility Profiles" 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: Thu, 29 Apr 2021 03:59:01 -0000 On Sat, 27 Mar 2021, ngel wrote: >> And that the place within the document might be right too? > > That's an editorial matter, but I don't think so. I find the security > section to contain many things without a clear script, just a mixture > of things related to security. The problem is that most of the rfc has > some relation to security :-) > There are rfcs with only a few security points to note. Having a > section listing all of them is good. But I don't think that's suitable > for OpenPGP. > > I would prefer to see as little as possible on the Security > Considerations, with the points within the most relevant section to the > topic. See for example how I positioned the line about you MUST use > Iterated and salted s2k at the part discussing rather than in that > generic section. IMHO that makes more sense, instead of having a S2K > requisite in a complete separate part of the document. > Nevertheless, the Security Considerations need an overhaul. There are This is a good point and I've added this as an issue: https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/29 >>> (*) A phrase that got removed but should be recovered is MDC MUST be >>> used when a symmetric encryption key is protected by ECDH.. I pondered >>> where to move it, but I concluded that should better go at its own >>> changeset stating that new algorithms cannot be used without MDC i.e. >>> they cannot be used with the "Symmetrically Encrypted Data Packet" >>> (still somewhat redundant, as that one MUST NOT be created). >> >> If others agree, we need a tracking item for this too? > > Yes, probably. Unless we get a quick consensus on this topic. We did not, so I opened a tracking item for this too: https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/30 >>> Additionally, the phrase "A compliant application MUST only use >>> iterated and salted S2K"... is also mostly fine, but I had already >>> covered a proposal for that one in the previous >>> https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/42 >> >> I would need to hear from more people about this change to see if >> there is consensus for this. >> >> speaking with no roles others than an individual: > > This part was proposed in February on a different thread. I am moving > your comment there and replying in that one: > > https://mailarchive.ietf.org/arch/msg/openpgp/ml5gzuQtSY6ANBejs8Xk66x_abQ I've merged in this change in a seperate commit, please review as part of the next draft update. (commit 464ac8232f9) Paul From nobody Wed Apr 28 21:01: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 129C53A2DC4 for ; Wed, 28 Apr 2021 21:01:17 -0700 (PDT) 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 ZzL_G7IN3gz4 for ; Wed, 28 Apr 2021 21:01:13 -0700 (PDT) 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 E46903A2DC1 for ; Wed, 28 Apr 2021 21:01:12 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4FW1yG6qtxz3R4; Thu, 29 Apr 2021 06:01:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1619668870; bh=IUZzj+s7Z422bJGk/pX7mznTzJWaVcPGD/xFGTmRfok=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=KPmPJEgbugQ+HoRXFk0t/w6amD+kDSH7kyBUCDwvOPpCu9gNmA66SSz2SPPPBx5c9 kWFrkFXrK7+h4xShF2xmnf1VEKOCzf/S6WkHAxMvpxQsX24KxyA0X4v9jeJ31yppxD eElYdWb8KN0xfF1rcZfuNUmm11fvB0XAibyhtr84= 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 5KLl4wDHHdHJ; Thu, 29 Apr 2021 06:01:09 +0200 (CEST) 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; Thu, 29 Apr 2021 06:01:09 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 7F6C86029A70; Thu, 29 Apr 2021 00:01:08 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 7E0CC66B7C; Thu, 29 Apr 2021 00:01:08 -0400 (EDT) Date: Thu, 29 Apr 2021 00:01:08 -0400 (EDT) From: Paul Wouters To: =?ISO-8859-15?Q?=C1ngel?= cc: Daniel Kahn Gillmor , openpgp@ietf.org In-Reply-To: <39e6b111f642a944214fd28d2fb53914b540c780.camel@16bits.net> Message-ID: <367f66eb-85a6-953f-1f18-f193f5c5b87c@nohats.ca> References: <20210317145508.136021-1-dkg@fifthhorseman.net> <871rcd7rdh.fsf@fifthhorseman.net> <25e8d5713bcccb7b86e0f9ce75dafba80fb41530.camel@16bits.net> <87sg4t5fz8.fsf@fifthhorseman.net> <87k0q4rgml.fsf@wheatstone.g10code.de> <60773433fb4dfae65a59c089c22e24c37e7913cf.camel@16bits.net> <87blbf5a6c.fsf@fifthhorseman.net> <39e6b111f642a944214fd28d2fb53914b540c780.camel@16bits.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [openpgp] [RFC4880bis PATCH] Clarify CRC-24 C example implementation 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, 29 Apr 2021 04:01:17 -0000 On Sat, 20 Mar 2021, ngel wrote: > Subject: Re: [openpgp] [RFC4880bis PATCH] Clarify CRC-24 C example > implementation This issue was also left with multiple competing texts, and so I would like the WG to come up with 1 change for me to apply :) Paul > On 2021-03-19 at 13:24 -0400, Daniel Kahn Gillmor wrote: >> >> fwiw, i'm fine with either of these. I note that the change i'd >> originally proposed renamed the constant to CRC24_GENERATOR, to align >> it with the term in the text ("poly" doesn't appear anywhere in the >> text, but "generator" does). > > Right. I began from Hal's mail [1] Particularly the second option is > his code just adding the comment. Thus I didn't want to add another > change with the constant rename (something I'm fine with). > > > Another potential point is if 0xffffff should have been changed to > 0xffffffUL, as we are also changing the type to unsigned, but it looks > redundant. > > >> That said, we are pretty clearly in bike-shedding territory here. >> >> I have heard no one advocate for leaving the text unchanged, and i have >> heard no one advocate for just silently amending the code to drop bit 25 >> from the constant. > > Indeed. Even if discussing which wording might be (slightly) better, > let me explicitly state my support, in that I think all proposed > changes on this thread represent an improvement over the existing text. > > Best regards > > > 1- > https://mailarchive.ietf.org/arch/msg/openpgp/UMLreIiKtKzXEnPT5ZbcDDjRQX0/ > > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > From nobody Wed Apr 28 21:23:50 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 7409D3A2E72 for ; Wed, 28 Apr 2021 21:23:48 -0700 (PDT) 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 HDtcEtQ6GWbu for ; Wed, 28 Apr 2021 21:23:44 -0700 (PDT) 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 08D083A2E71 for ; Wed, 28 Apr 2021 21:23:43 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4FW2SG5CSBz3Tr; Thu, 29 Apr 2021 06:23:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1619670222; bh=5cUqt4eQ7bxDbI/qlPDiwOy7WoZJDejov8W9VsGgb/s=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=eRup0qlbdR5y+79rX4WdG7K4yqy4Sxj7Bm1YLu7KMkEc3BS5pfE9To04NYoAhCU9S c65ZhnLb6dWsadbp5MwsFFXzl9gUM3md+bnbVW+ZT1Izn4bQr7q8wIgjh6rQr4dHlZ 1caQ/IDe1trFVNCOgFv8OhBtjJr+0U/B8yeWgQ7A= 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 XjCzDRq3shQ0; Thu, 29 Apr 2021 06:23:41 +0200 (CEST) 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; Thu, 29 Apr 2021 06:23:41 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 73FE46029A70; Thu, 29 Apr 2021 00:23:40 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6B46666B7C; Thu, 29 Apr 2021 00:23:40 -0400 (EDT) Date: Thu, 29 Apr 2021 00:23:40 -0400 (EDT) From: Paul Wouters To: "Neal H. Walfield" cc: Daniel Kahn Gillmor , openpgp@ietf.org In-Reply-To: <877dmraytj.wl-neal@walfield.org> Message-ID: <36edd7dd-8217-fc9a-88f-90cd47c5695@nohats.ca> References: <7d8bdda1-4e5c-6c10-f3cd-1d191fad595c@nohats.ca> <87im6faw06.wl-neal@walfield.org> <87pn0mcecf.fsf@fifthhorseman.net> <877dmraytj.wl-neal@walfield.org> 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: Thu, 29 Apr 2021 04:23:48 -0000 On Mon, 1 Mar 2021, Neal H. Walfield wrote: >> On Fri 2021-02-26 12:50:17 +0100, Neal H. Walfield wrote: >>> -- 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. >>> +- [ ] 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). > > I don't know how that crept it. > >> what does the [ ] you've inserted here mean? It looks like a markdown >> todo-list "checkbox", maybe it was inserted by mistake? It is not in the markdown original, so I'm not sure how/why it is happening. >>> - 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? > > Good points! I think using s0 and s1 is the best suggestion so far. Done via commit 27e70ca. Paul From nobody Thu Apr 29 09:02: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 B31D13A4123 for ; Thu, 29 Apr 2021 09:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.305 X-Spam-Level: X-Spam-Status: No, score=-1.305 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, 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=FX1N+66t; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=CcAtjMgV 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 Vg1Ua-wacY_C for ; Thu, 29 Apr 2021 09:02:39 -0700 (PDT) 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 ED5423A4122 for ; Thu, 29 Apr 2021 09:02:38 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1619712156; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=LLoupd6+PFiAz+dRVAhvR9GmxRfaxxGiEz2NuksjIrc=; b=FX1N+66tThKm5JDT+ZhNgpdw2aLqxil1DSJ8EvMJ/UVBoht/zPLbw08debO69mzvNsgUe qjbydjFC6UKd6KCCg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1619712156; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=LLoupd6+PFiAz+dRVAhvR9GmxRfaxxGiEz2NuksjIrc=; b=CcAtjMgV0qPnPijLHDAYaJypskvKuX8QmqP90lf64UQDQUE+Yx6fzg5+4CbmaMoqI/g3z wYqtzUl3y8kULJHsRmnoDHAVbNKM0kM4YVZT+CpZBfj9W5PijV6wau/MYv/vSXaoZrEI5cG ri9KRfPKz28aSqNaqzwIJ52jcOnj8ffx2OQ77EF1Vl8Ftylh1UKs1xXmYcUc84zrqiVLRS4 2M6O3DPos3ZjRJ5IBFQopgcMUX6ESnJvwCeQqfWr7/Lh+G9qp1/A1iL8sXkWQ23ZRdzynAQ rwKdSGtk0L61NgLRkxPSEhCGih510S2LTmwL+l9Kg4F7+uIzBZdFIVEC+OtQ== 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 8E2EEF9A5; Thu, 29 Apr 2021 12:02:36 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 810352033A; Thu, 29 Apr 2021 11:57:33 -0400 (EDT) From: Daniel Kahn Gillmor To: Paul Wouters , =?utf-8?Q?=C3=81ngel?= Cc: openpgp@ietf.org In-Reply-To: References: <87wnu86mep.fsf@fifthhorseman.net> <20210324021213.333485-1-dkg@fifthhorseman.net> <87pmzp2taf.fsf@fifthhorseman.net> <26945b02701cdbcf7af0ebd3adaa325b91021be7.camel@16bits.net> <87blb72yto.fsf@fifthhorseman.net> <029c60b6a313d33cf5cc7e15791be8c0c582370c.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: Thu, 29 Apr 2021 11:57:32 -0400 Message-ID: <87eeetaxsj.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] [RFC4880bis PATCH] Drop "Compatibility Profiles" 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: Thu, 29 Apr 2021 16:02:44 -0000 --=-=-= Content-Type: text/plain On Wed 2021-04-28 23:58:48 -0400, Paul Wouters wrote: >>>> Additionally, the phrase "A compliant application MUST only use >>>> iterated and salted S2K"... is also mostly fine, but I had already >>>> covered a proposal for that one in the previous >>>> https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/42 >>> >>> I would need to hear from more people about this change to see if >>> there is consensus for this. >>> >>> speaking with no roles others than an individual: >> >> This part was proposed in February on a different thread. I am moving >> your comment there and replying in that one: >> >> https://mailarchive.ietf.org/arch/msg/openpgp/ml5gzuQtSY6ANBejs8Xk66x_abQ > > I've merged in this change in a seperate commit, please review as part > of the next draft update. (commit 464ac8232f9) I think the commit you're talking about is now public as 1edfd5d45a49a5a15d08eff9fff7d5c482acb6da, 'update text on "Simple S2K and Salted S2K specifiers" as per WG discussion'. minor clarification: among a few other changes, it adds this line: +Implementations SHOULD NOT use these methods on encryption of both keys and messages. I think this "both" should be "either" -- otherwise, the guidance sounds like it applies only to some combination encryption (which isn't possible iirc). otherwise, it looks good to me. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQttUkcnfDcj0MoY88+nXFzcd5WXAUCYIrXbQAKCRA+nXFzcd5W XJ7iAQCSfmUkA9H4QkW6mqG6zL+6oxkbZSldNOUvm6DlH/p1UQEAzwuCMSpOgJV2 Q1g/K9JQYoOTlmsFrGkvFitH3wuKRAg= =VxmI -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Apr 29 09:16: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 5FAFD3A416C for ; Thu, 29 Apr 2021 09:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.305 X-Spam-Level: X-Spam-Status: No, score=-1.305 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, 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=453QpuWP; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=0hYeVuA4 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 6wQc4rg2noQl for ; Thu, 29 Apr 2021 09:15:57 -0700 (PDT) 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 B7D533A416A for ; Thu, 29 Apr 2021 09:15:57 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1619712955; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=wimUYCgRp8h0fcq2wsydcXly3DH7sX4sT4mtbkDl+RM=; b=453QpuWPmq8bNXu8I1yWq6qmmQH3Mz4kJCmOzVfe+P3CbRs/ldr1C/RE2cWnCq1TTxTL3 ZjEVBLe14Ae5pPqDQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1619712955; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=wimUYCgRp8h0fcq2wsydcXly3DH7sX4sT4mtbkDl+RM=; b=0hYeVuA40Ab7tMlSJIma1wKFRJ1CB5InATsUXqO2RgQqywoX0A/ZjZzew652twNbsk+d+ sOAugrZGn2eC5nRy/xlLR0v6odNA9xa8lEV9mJ1DmO7VwKAymSXSJ8FCKbCrNdvQQSZl8/4 hIDaFo3tZSkFNHuUeg/YWeH7ibeK3tamZCBDSdz4mnzG2xZKDKWRFqBJwW9+JQ0+mvi4D9h NIOdvrjnVbJRqswnIJBuenf2yslbKeHvzxIrzezCRhFholY7KxNlmhV4e+DN0VbN91YcBBN d1Y0R2s4P8wtCcC3CgaG1CQ9cBirh8OYCduYWuy826ZyAlOuUfSvTCgj2ucw== 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 854DAF9A5; Thu, 29 Apr 2021 12:15:55 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 221EC2033A; Thu, 29 Apr 2021 12:15:53 -0400 (EDT) From: Daniel Kahn Gillmor To: Paul Wouters , =?utf-8?Q?=C3=81ngel?= Cc: openpgp@ietf.org In-Reply-To: <367f66eb-85a6-953f-1f18-f193f5c5b87c@nohats.ca> References: <20210317145508.136021-1-dkg@fifthhorseman.net> <871rcd7rdh.fsf@fifthhorseman.net> <25e8d5713bcccb7b86e0f9ce75dafba80fb41530.camel@16bits.net> <87sg4t5fz8.fsf@fifthhorseman.net> <87k0q4rgml.fsf@wheatstone.g10code.de> <60773433fb4dfae65a59c089c22e24c37e7913cf.camel@16bits.net> <87blbf5a6c.fsf@fifthhorseman.net> <39e6b111f642a944214fd28d2fb53914b540c780.camel@16bits.net> <367f66eb-85a6-953f-1f18-f193f5c5b87c@nohats.ca> 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, 29 Apr 2021 12:15:52 -0400 Message-ID: <87bl9xawxz.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] [RFC4880bis PATCH] Clarify CRC-24 C example implementation 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, 29 Apr 2021 16:16:02 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Thu 2021-04-29 00:01:08 -0400, Paul Wouters wrote: > On Sat, 20 Mar 2021, =C3=81ngel wrote: > >> Subject: Re: [openpgp] [RFC4880bis PATCH] Clarify CRC-24 C example >> implementation > > This issue was also left with multiple competing texts, and so I would > like the WG to come up with 1 change for me to apply :) The version that you've committed to gitlab's main branch looks good to me: =2D----- ## An Implementation of the CRC-24 in "C" #define CRC24_INIT 0xB704CEL #define CRC24_GENERATOR 0x864CFBL typedef unsigned long crc24; crc24 crc_octets(unsigned char *octets, size_t len) { crc24 crc =3D CRC24_INIT; int i; while (len--) { crc ^=3D (*octets++) << 16; for (i =3D 0; i < 8; i++) { crc <<=3D 1; if (crc & 0x1000000) { crc &=3D 0xffffff; /* Clear bit 25 to avoid overflow */ crc ^=3D CRC24_GENERATOR; } } } return crc & 0xFFFFFFL; } =2D----- It's a little bit weird that one constant is written as 0xFFFFFFL and the other is written as 0xffffff -- maybe we want to align the orthography (and should 0x1000000 also have an L suffix)? But even without those little tweaks, this is strictly better than the earlier version. If anyone has any objections to this, please speak up! --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQttUkcnfDcj0MoY88+nXFzcd5WXAUCYIrbuAAKCRA+nXFzcd5W XDglAP0bdsyEQwwRqMkFO3JAU8oxozTXWqe2EdF5yG8b9bm44QD7BjPTTn7GIk7L eV4Dvd4jxzNg4ADBYjM9L70JrSxoZQE= =owQZ -----END PGP SIGNATURE----- --=-=-=--