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

Daniel Kahn Gillmor <> Sun, 06 June 2021 15:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8D4BA3A1E40 for <>; Sun, 6 Jun 2021 08:12:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
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: (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.b=zZsmX+aJ; dkim=pass (2048-bit key) header.b=4eljZ4dC
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FUrgFIFZj0sZ for <>; Sun, 6 Jun 2021 08:12:30 -0700 (PDT)
Received: from ( [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5DC923A1E3D for <>; Sun, 6 Jun 2021 08:12:30 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple;;; q=dns/txt; s=2019; t=1622992347; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=CVbZ3P3p2b6+YLZbQqlnrAcrtBqf56SXH6X3vTA25To=; b=zZsmX+aJfuLZXdFqX3yt9BCMx3yXa33D+K8pEcUIaLdnH/+ywGwy5QBO46WULZbJgDb/s Dm5WwxjKPwlWr50Cg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; q=dns/txt; s=2019rsa; t=1622992347; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=CVbZ3P3p2b6+YLZbQqlnrAcrtBqf56SXH6X3vTA25To=; b=4eljZ4dC46/fKT4L6vj7tEJ8dSkYUoUvLNYv4F1EdRyXyrgcomfBGYEmh5e+Z3Rr6ujC8 zUHzVy2HmqlaubZJEgpdS0tWbVRpuKjycz3UkeoTd1aV1J4E5aPKeh8v1tLK1Fg4Q3121F+ wRQe8n/H8Nm8KjoLo35QXguLSg6Ya9DfN9oKwHJRs13G3tbtujXDZuIfYdQkDi7ExrA1LFS RuHC0eAgKBHScBL00bEuHgCtUuI3auva91epyQ3tTr1C0wnmBGuzwpdMfobJsvCq3b5JLFF SjvCR0TasC1vqRFDxxyGCRwcPCXGiGVvAtQ54owBb7Z0InuLtyO7YWvMjI1Q==
Received: from ( []) (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 (Postfix) with ESMTPSA id 9B6CAF9A5; Sun, 6 Jun 2021 11:12:27 -0400 (EDT)
Received: by (Postfix, from userid 1000) id 274CA204D8; Sun, 6 Jun 2021 11:01:09 -0400 (EDT)
From: Daniel Kahn Gillmor <>
To: Michael Richardson <>,
In-Reply-To: <14974.1622924947@localhost>
References: <> <376548.1622830236@dooku> <> <14974.1622924947@localhost>
Autocrypt:; 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: Sun, 06 Jun 2021 11:01:08 -0400
Message-ID: <>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
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: Sun, 06 Jun 2021 15:12:36 -0000

On Sat 2021-06-05 16:29:07 -0400, Michael Richardson wrote:
> 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.

I think these are the right assumptions.

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

Each "key signature" (certification) is its own OpenPGP packet, right?
and the context we're talking about here is a hash context that is used
to calculate a key signature.

While there is some zoomed-out view that might well have multiple
signatures, and there might be other data signatures that happen over
collections of information that do include keys, those contexts aren't
relevant for this specific calculation.

If the concern is how to "skip over" an artifact from an algorithm that
you don't understand, i don't think this increased size field is
relevant, because any implementation can just "skip over" the signature
by skipping to the end of the signature packet (whose length is already
known; this field doesn't appear on the wire), or not calculating the
digest itself at all.

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

yes, i agree with this, though it is not "skipping over" -- it's
"preparing for certifications of larger keys".  We still don't know
whether this is *sufficient* for dealing with whatever eventual PQ
algorithm arises, but i agree with you that it seems to be *necessary*
to handle them.

It might be worth including change (2) as a precautionary gamble, since
it doesn't appear to have any downside other than a slightly tweaked
codepath during certification creation and verification.

What do other folks in the WG think?