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

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Sat, 05 June 2021 17:55 UTC

Return-Path: <dkg@fifthhorseman.net>
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 373BE3A2A4D for <openpgp@ietfa.amsl.com>; Sat, 5 Jun 2021 10:55:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=ppKleZ7z; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=2CuKmLJI
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 Gx7yfcwtuQ4i for <openpgp@ietfa.amsl.com>; Sat, 5 Jun 2021 10:55:02 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A94973A2A98 for <openpgp@ietf.org>; Sat, 5 Jun 2021 10:55:02 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1622915700; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=dDqeLSz3GssKhXD+bSc4Po5G+j/jayXALF81bf/Irrc=; b=ppKleZ7zcfqhAiBrCtP7X521V2BOnI7quVCXg6NcqSJQllUOORN605wQl/aKxgX3gId4x C8Dp9xVjWrpC/L/Cw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1622915700; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=dDqeLSz3GssKhXD+bSc4Po5G+j/jayXALF81bf/Irrc=; b=2CuKmLJIMaO7Jso4yztJF9S8CQPwDxAxuuDp3JQyCgTIl8p3PCy8tyfQZHtalQebKqKAl p5633VcZmXlw6rOvvjQ5JfRV1SNl3lR/eoatVtQCGcIi1W3wTCx/T2SYciNeeE1R8/wMvSd 5jHIc82A1W62iBtN+DR28LBAonnf4kuW2nsoP1uT+ubJvweRqPZXwuqTGZHzxqibKtrqRgL nX7qW4KK5438Qp4x8mMbMDdDrfedVxPAlnFBp2THPa/ZJrS80pLI+u2D6gU/ntL6iTVFkHy WY+uzY25/moUfBDwrX0hE6Bz1T/VTfbr7I2p8oNv4PlPVtr+OFtetckoRC4A==
Received: from fifthhorseman.net (ip68-0-212-178.ri.ri.cox.net [68.0.212.178]) (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 194B6F9A6; Sat, 5 Jun 2021 13:54:59 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id 0505F20928; Sat, 5 Jun 2021 13:41:29 -0400 (EDT)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Michael Richardson <mcr+ietf@sandelman.ca>, openpgp@ietf.org
In-Reply-To: <376548.1622830236@dooku>
References: <87lf7q6sh0.fsf@fifthhorseman.net> <376548.1622830236@dooku>
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: Sat, 05 Jun 2021 13:41:27 -0400
Message-ID: <87v96sqke0.fsf@fifthhorseman.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/STV1iWxHtYAdM8ti32ZIbTKT-TA>
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 17:55:07 -0000

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.

Honestly, i find (2) the least problematic of the changes listed -- it
doesn't affect the wire format, and it's just a slight change to the
hashing algorithm which already needs a special case for the bytes
hashed (0x99 for v4 vs 0x9a for v5).  If the WG decides that the change
in (2) is worth keeping because it just might come in handy for some
as-yet-unspecified scheme, that's a plausible argument to me, but i
don't see how it helps anyone skip over anything.  Can you explain more?

    --dkg