IETF Logo Mail Archive

Re: [openpgp] v5 in the crypto-refresh draft

Michael Richardson <mcr+ietf@sandelman.ca> Sat, 05 June 2021 20:29 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 2C96E3A2F0E for <openpgp@ietfa.amsl.com>; Sat, 5 Jun 2021 13:29:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_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 T4RNE5LL8osU for <openpgp@ietfa.amsl.com>; Sat, 5 Jun 2021 13:29:09 -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 302E63A2F0D for <openpgp@ietf.org>; Sat, 5 Jun 2021 13:29:09 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 77C5138AE4; Sat, 5 Jun 2021 16:29:41 -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 bnvtCnkhjckK; Sat, 5 Jun 2021 16:29:41 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 00B4038AE3; Sat, 5 Jun 2021 16:29:41 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 1551967E; Sat, 5 Jun 2021 16:29:07 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, openpgp@ietf.org
In-Reply-To: <87v96sqke0.fsf@fifthhorseman.net>
References: <87lf7q6sh0.fsf@fifthhorseman.net> <376548.1622830236@dooku> <87v96sqke0.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<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Sat, 05 Jun 2021 16:29:07 -0400
Message-ID: <14974.1622924947@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/Op54GZZpXmtih49r9HwTg-Tyfww>
Subject: Re: [openpgp] v5 in the crypto-refresh draft
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 20:29:14 -0000

Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
    > On Fri 2021-06-04 14:10:36 -0400, Michael Richardson wrote:
    >> > (2) appears to prepare for keys larger than 65536 octets.  This looks
    >> > like post-quantum planning to me, but we are not including any PQ
    >> > schemes in the specification, and it's not clear that this change on
    >> > its own would be sufficient to support such a new scheme (especially
    >> > because there doesn't seem to be any CFRG consensus on what PQ scheme
    >> > to endorse yet).
    >>
    >> Sure, but wouldn't it help a v5 implementation to more intelligently skip
    >> such a thing?  I don't know if we can support multiple signatures with
    >> different algorithms.

    > Would it?  In what context?  The change for (2) has to do with how to
    > structure data fed into a hash algorithm for a certification ("key
    > signature") but isn't anything on the wire.

Assume in the future that we have keys larger than 64K octets.  We are doing
that, not because there has been a quantum event, but because we are preparing for it.
We may still not even be sure which PQ scheme is the right one.

(There are multiple keys present, and possibly multiple signatures over both
end-user-data, and over keys)

A v5-capable tool, which does not speak these new formats can still process
the packets.  It could also verify that these large keys are signed by our
legacy algorithms.

--
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