Re: [openpgp] The checksum may appear

Ángel <angel@16bits.net> Thu, 18 March 2021 23:19 UTC

Return-Path: <angel@16bits.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 94C173A0DDD for <openpgp@ietfa.amsl.com>; Thu, 18 Mar 2021 16:19:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71Z9kRMwnxgX for <openpgp@ietfa.amsl.com>; Thu, 18 Mar 2021 16:19:17 -0700 (PDT)
Received: from mail.direccionemail.com (mail.direccionemail.com [199.195.249.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 122463A0B72 for <openpgp@ietf.org>; Thu, 18 Mar 2021 16:19:16 -0700 (PDT)
Message-ID: <5a927ffed96b38efa08c58b6a29e565dff87a535.camel@16bits.net>
From: =?ISO-8859-1?Q?=C1ngel?= <angel@16bits.net>
To: openpgp@ietf.org
Date: Fri, 19 Mar 2021 00:19:15 +0100
In-Reply-To: <20210317145508.136021-1-dkg@fifthhorseman.net>
References: <20210317145508.136021-1-dkg@fifthhorseman.net>
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/dTsyiSSgq8y4-ZDoBB6UD5fahJ0>
Subject: Re: [openpgp] The checksum may appear
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: Thu, 18 Mar 2021 23:19:19 -0000

Looking at the Radix-64 section, I noticed the phrase
> The checksum with its leading equal sign MAY appear on the first line
> after the base64 encoded data.

I understand it is that way to convey that the checksum may not appear
at all, but it would be better to explicitly say so.



diff --git a/crypto-refresh.md b/crypto-refresh.md
index 9fbb6eb..bb9635b 100644
--- a/crypto-refresh.md
+++ b/crypto-refresh.md
@@ -2100,7 +2100,7 @@ As stated in the introduction, OpenPGP's underlying native representation for ob
 In principle, any printable encoding scheme that met the requirements of the unsafe channel would suffice, since it would 
not change the underlying binary bit streams of the native OpenPGP data structures.
 The OpenPGP standard specifies one such printable encoding scheme to ensure interoperability.
 
-OpenPGP's Radix-64 encoding is composed of two parts: a base64 encoding of the binary data and a checksum.
+OpenPGP's Radix-64 encoding is composed of two parts: a base64 encoding of the binary data and an optional checksum.
 The base64 encoding is identical to the MIME base64 content-transfer-encoding {{RFC2045}}.
 
 The checksum is a 24-bit Cyclic Redundancy Check (CRC) converted to four characters of radix-64 encoding by the same MIME 
base64 transformation, preceded by an equal sign (=).
@@ -2108,7 +2108,7 @@ The CRC is computed by using the generator 0x864CFB and an initialization of 0xB
 The accumulation is done on the data before it is converted to radix-64, rather than on the converted data.
 A sample implementation of this algorithm is in the next section.
 
-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.
 
 Rationale for CRC-24: The size of 24 bits fits evenly into printable base64.
 The nonzero initialization can detect more errors than a zero initialization.