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

Michael Richardson <> Fri, 04 June 2021 18:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D87823A1BAB for <>; Fri, 4 Jun 2021 11:10:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 2.5
X-Spam-Level: **
X-Spam-Status: No, score=2.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.398, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YgIgRa8RaOHf for <>; Fri, 4 Jun 2021 11:10:43 -0700 (PDT)
Received: from ( [IPv6:2a01:7e00::3d:b000]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 260973A1BA9 for <>; Fri, 4 Jun 2021 11:10:43 -0700 (PDT)
Received: from (unknown [IPv6:2607:f0b0:f:40::146]) by (Postfix) with ESMTPS id C85331F47A; Fri, 4 Jun 2021 18:10:37 +0000 (UTC)
Received: by (Postfix, from userid 179) id A76E01A02B4; Fri, 4 Jun 2021 14:10:36 -0400 (EDT)
From: Michael Richardson <>
To: Daniel Kahn Gillmor <>,
In-reply-to: <>
References: <>
Comments: In-reply-to Daniel Kahn Gillmor <> message dated "Fri, 04 Jun 2021 02:42:35 -0400."
X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 26.3
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Fri, 04 Jun 2021 14:10:36 -0400
Message-ID: <376548.1622830236@dooku>
Archived-At: <>
Subject: Re: [openpgp] v5 in the crypto-refresh draft
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, 04 Jun 2021 18:10:48 -0000

Daniel Kahn Gillmor <> wrote:
    >  2) v5 certifications ("key signatures") hash a four-octet length of
    > the subject key; v4 certifications hash instead a two-octet subject key
    > length.

    > -----

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

    > This change also has a consequence that it's not possible to transform
    > an embedded/inline signature into a detached or cleartext signature, or
    > vice versa, because detached or cleartext signatures have no place to
    > store the content byte, filename, or timestamp.  I've seen several use
    > cases where translating a signature between inline/embedded format and
    > detached or cleartext formats can be concretely useful.  In one
    > example, Debian's apt repository's Release, Release.gpg, and InRelease
    > files contain the same data and should be able to share cryptographic
    > signatures.

I think that your use case is reasonable.
I also was thinking that with the Executive Order wrt Supply Chain security,
and the number of systems which are debian based, and thus use Release.gpg at
the top, that having v5 sooner rather than later is probably important.

]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]        |   ruby on rails    [