On Fri 2021-03-19 00:19:15 +0100, Ángel wrote:
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.
As an implementer and a maintainer, I am in favor of this change. I
think it makes the draft more accurately represent the state of the
ecosystem, where i suspect implementations are willing to accomodate
an absent CRCs.
As a chair, I note that this does seem to subtly change the semantics of
the document, and therefore I think we need to hear from more people in
the WG about whether this seems correct. Thanks to Werner for already
weighing in on this.
The other way is to have hard data about what implementations are
willing to accept. I've opened
https://gitlab.com/sequoia-pgp/openpgp-interoperability-test-suite/-/issues/42
to suggest that the interoperability test suite should have a batch of
consumer tests that demonstrate which implementations can handle a
missing CRC.
If folks are interested in helping out with the test suite, this might
be a relatively easy way to make a contribution.
--dkg
signature.asc
Description: PGP signature
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp