IETF Logo Mail Archive

Re: [openpgp] [RFC4880bis PATCH] WIP: bind wire format representations to specific pubkey algorithms

Michael Richardson <mcr+ietf@sandelman.ca> Sat, 05 June 2021 17:32 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 9D4373A299F for <openpgp@ietfa.amsl.com>; Sat, 5 Jun 2021 10:32:20 -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, RCVD_IN_DNSWL_BLOCKED=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 4QxU_Gaq4fSy for <openpgp@ietfa.amsl.com>; Sat, 5 Jun 2021 10:32:16 -0700 (PDT)
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 79B403A299D for <openpgp@ietf.org>; Sat, 5 Jun 2021 10:32:15 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 3E6BE38AF2; Sat, 5 Jun 2021 13:32:47 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id rja8Jt2o8kgv; Sat, 5 Jun 2021 13:32:46 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E4A8038AEE; Sat, 5 Jun 2021 13:32:45 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 747C11D3; Sat, 5 Jun 2021 13:32:12 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Daniel Huigens <d.huigens@protonmail.com>, Daniel Kahn Gillmor <dkg@fifthhorseman.net>, IETF OpenPGP WG <openpgp@ietf.org>
In-Reply-To: <ov3xkN45qQt8XtXqpa4KYsQzr-44tJMuTWg7aaYFHSAPaVDXtq_ywZK7KZz49Z0m7-fk6O8qkkUc5kWbGyf0EU59y415YgvoDNVqhZPLiNk=@protonmail.com>
References: <20210602230847.3593022-1-dkg@fifthhorseman.net> <ov3xkN45qQt8XtXqpa4KYsQzr-44tJMuTWg7aaYFHSAPaVDXtq_ywZK7KZz49Z0m7-fk6O8qkkUc5kWbGyf0EU59y415YgvoDNVqhZPLiNk=@protonmail.com>
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<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Sat, 05 Jun 2021 13:32:12 -0400
Message-ID: <30581.1622914332@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/a_dagC4jQiWaB1QnsxFWeBKZVaY>
Subject: Re: [openpgp] [RFC4880bis PATCH] WIP: bind wire format representations to specific pubkey algorithms
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 05 Jun 2021 17:32:21 -0000

Daniel Huigens <d.huigens=40protonmail.com@dmarc.ietf.org> wrote:
    > Once we do specify a new public key algorithm (e.g. post-quantum), as
    > opposed to just a new curve (my expectation is that adding post-quantum
    > algorithms will be the next "crypto refresh", and that we will never
    > need a new curve after Curve448), I fully agree that we definitely
    > shouldn't do this byte-string-in-MPI thing again. When we do so, we
    > could specify a new octet string type, or something else. But I'm not
    > sure that between Curve25519 and Curve448 is the correct place to "draw
    > the line in the sand".

I don't think that it's right to think of post-quantum as being a crypto-refresh.
That is, replacement of one set of algorithms with another.
Rather, I think it's better to try to think about this as being multiple
algorithms present at the same time.

having said that, we shouldn't allow better to get in the way of good enough.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

v2.23.0 | Report a Bug | By Email