Re: [openpgp] Éric Vyncke's No Objection on draft-ietf-openpgp-crypto-refresh-12: (with COMMENT)

Paul Wouters <> Thu, 14 December 2023 02:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5CE5AC14CEFD; Wed, 13 Dec 2023 18:21:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.104
X-Spam-Status: No, score=-7.104 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7rZPL1buyT6e; Wed, 13 Dec 2023 18:21:51 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 936D3C14F5FC; Wed, 13 Dec 2023 18:21:48 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 4SrGLy1Klbz5CN; Thu, 14 Dec 2023 03:21:46 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1702520506; bh=HBShTi6MZB6Tc+TEk+qeRqIEAOgycm/L/Vk3XMH4EP4=; h=From:Subject:Date:References:Cc:In-Reply-To:To; b=Gcgl2fXwGT+k0PGl028okQjf3KxKEt5oiBAOLXMLmjnW9yZH4NOcw/GO/Zq4WYNd7 KFMeUdNcK9wdeURQjdnRdrx/VPH7IgeG6KnWc5teqy+9Iz9nqW3T7fTMqOoUKnjigd FQQhnVjC5veOaYg6hkKAA14aWhPXnRUoU8asW7iI=
X-Virus-Scanned: amavisd-new at
Received: from ([IPv6:::1]) by localhost ( [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id LbfqpvZXoRSz; Thu, 14 Dec 2023 03:21:45 +0100 (CET)
Received: from (unknown []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS; Thu, 14 Dec 2023 03:21:45 +0100 (CET)
Received: from (unknown []) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPSA id 103F110E11C3; Wed, 13 Dec 2023 21:21:44 -0500 (EST)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Paul Wouters <>
Mime-Version: 1.0 (1.0)
Date: Wed, 13 Dec 2023 21:21:33 -0500
Message-Id: <>
References: <>
Cc: Éric Vyncke <>, The IESG <>,,,
In-Reply-To: <>
To: Stephen Farrell <>
X-Mailer: iPhone Mail (21B101)
Archived-At: <>
Subject: Re: [openpgp] Éric Vyncke's No Objection on draft-ietf-openpgp-crypto-refresh-12: (with COMMENT)
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 14 Dec 2023 02:21:56 -0000

> On Dec 13, 2023, at 16:26, Stephen Farrell <> wrote:
> Hiya,
> Answering the shepherd-like questions...
>> # COMMENTS (non-blocking)
>> ## The most concise shepherd's write-up
>> The justification for the intended status is just "PS"... not even expanded...
> It seemed obvious:-) If you'd like it in more words, this is
> adding new crypto as a revision of a complex spec that has
> lots of history and significant deployment so PS seems like
> the only sensible target.

It also is a bis document of a standards track document 😀

> Not sure "very rough" is right in this case so maybe the write-up was
> a bit misleading (sorry if so). There's good consensus among currently
> active WG participants, which includes a set of implementers. The issue
> is that the main contributor to one important implementation no longer
> support the draft. That's a shame IMO, but doesn't make the consensus
> very rough.

It also included a positive voice of at least one author of RFC 4880 and possibly two (I’d have to hunt the archives to confirm). The person now objecting and claiming to speak as “the old group of openpgp” was not listed as author in RFC4880.

>> ## IANA registries
>> Should this I-D be an opportunity to reserve some registry values for a FCFS
>> allocation ?
> The WG did not discuss FCFS, but did explicitly discuss lowering the bar
> for registration of new codepoints in many registries. I'd be surprised
> though if there was consensus to take that as far as FCFS registrations.
> That's fairly consistent with many other crypto related registries where
> we generally only want to get as "loose" as specification required, e.g.
> to avoid registration of codepoints for snake-oil or secret algorithms,
> which FCFS would permit.

Indeed. Especially because encrypted messages tend to still need to be decryptable decades into the future. So a Delegated Expert with specification required seems more appropriate.