Re: [openpgp] The checksum may appear

Ángel <> Thu, 25 March 2021 00:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CBA663A13AD for <>; Wed, 24 Mar 2021 17:07:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IuSkKQHcNnTT for <>; Wed, 24 Mar 2021 17:07:25 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 774BD3A1411 for <>; Wed, 24 Mar 2021 17:07:06 -0700 (PDT)
Message-ID: <>
From: =?ISO-8859-1?Q?=C1ngel?= <>
Date: Thu, 25 Mar 2021 01:07:06 +0100
In-Reply-To: <>
References: <> <> <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [openpgp] The checksum may appear
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: Thu, 25 Mar 2021 00:07:35 -0000

On 2021-03-19 at 07:54 +0100, Werner Koch wrote:
> > -The checksum with its leading equal sign MAY appear on the first line
> > after the base64 encoded data.
> > +If present, the checksum with its leading equal sign SHALL appear on
> > the next line after the base64 encoded data.
> Adding "optional" and making the CRC a SHOULD create indeed clarifies
> the intention of the RFC.  Thus I am in favor of this change.

Note I wasn't placing the later. I only stated that you can only place
the checksum at the end.
I was planning to treat this as a feature request and add a phrase with
such SHOULD, since I agree it's a good idea, but turns out I can't come
out with a better rationale than “it's cheap enough it makes sense to
do it even if not giving much value”.

What is the goal of the armor CRC?
The only good use case I can think of is when a human has been
involved, such as when restoring a key from paper.

On other scenarios, the CRC would either be too weak (e.g. in presence
of an active attacker) or protecting from an error that would already
have been handled at lower layers.
[1] and [2] suggest it was added to avoid modem line noise altering the
messages (which nowadays should be discarded at e.g. TCP).

Without a compelling use case, I don't think it should be a SHOULD.
And finally, we should at least mention why it was once considered

The original change is available in git mode at

Best regards