Re: [openpgp] I-D Action: draft-ietf-openpgp-crypto-refresh-02.txt (fwd)

"Robert J. Hansen" <> Tue, 23 February 2021 16:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E8D1D3A2D26 for <>; Tue, 23 Feb 2021 08:10:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id glnSveCJ1X8p for <>; Tue, 23 Feb 2021 08:10:41 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 333C03A1D5B for <>; Tue, 23 Feb 2021 08:10:38 -0800 (PST)
Received: from [IPv6:2600:8806:404:9100::9baa] (unknown [IPv6:2600:8806:404:9100::9baa]) by (Postfix) with ESMTPSA id 3644C4D0C5DC0 for <>; Tue, 23 Feb 2021 08:10:37 -0800 (PST)
References: <> <>
From: "Robert J. Hansen" <>
Message-ID: <>
Date: Tue, 23 Feb 2021 11:10:35 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 ( []); Tue, 23 Feb 2021 08:10:37 -0800 (PST)
Archived-At: <>
Subject: Re: [openpgp] I-D Action: draft-ietf-openpgp-crypto-refresh-02.txt (fwd)
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: Tue, 23 Feb 2021 16:10:44 -0000

> I'm confused by this text.  If an implementation chooses to process 
> this packet type (e.g. I have 20-year-old PGP-encrypted messages
> that I'd still like to be able to read without re-encrypting them),
> why are you saying that it should return an error and stop
> processing? So it MAY process but SHOULD stop processing?  I'm
> confused.

"MAY process but SHOULD stop" is the way I'd read that guidance:
although a conforming implementation technically may process the packet,
it should not do so absent a compelling reason.

Perhaps this text instead?

"This packet is obsolete.  An implementation MUST NOT create this
packet.  An implementation MAY process such a packet but it MUST
return a clear diagnostic that a non-integrity protected packet has
been processed.  Unless the user explicitly directs otherwise, the
implementation SHOULD also return an error in this case and stop