ASCII armoring should not require the CRC line

SecurityInnovation / PGPy

Pretty Good Privacy for Python

BSD 3-Clause "New" or "Revised" License

313 stars 98 forks source link

ASCII armoring should not require the CRC line #421

Open dkg opened 1 year ago

dkg commented 1 year ago

See the rationale from the upcoming standard:

https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-07.html#name-optional-checksum

bwbroersma commented 2 months ago

Note 1.5 years later and it is still a draft: https://datatracker.ietf.org/doc/draft-ietf-openpgp-crypto-refresh/

Is the CRC checksum required in the current PGP spec? I'm unsure, RFC 4880 - OpenPGP Message Format § 6 Radix-64 Conversions states:

The checksum with its leading equal sign MAY appear on the first line after the base64 encoded data.

§ 6.2 Forming ASCII Armor is not explicit about the requirement, although it is about the order.

dkg commented 2 months ago

On Fri 2024-07-05 13:36:45 -0700, Benjamin W. Broersma wrote:

Note 1.5 years later and it is still a draft: https://datatracker.ietf.org/doc/draft-ietf-openpgp-crypto-refresh/

It will soon be RFC 9580. Yes, it has taken a long time, with a heavy process and a contentious history. No, it is not derelict. And it has significant support of a wide range of community members.

bwbroersma commented 1 month ago

Ok, I checked RFC 4880 for the regex PR I wrote, the current regex and tests are not compliant with that RFC in regard to:

not allowing whitespace between the Armor Headers and the cleartext
allowing numbers in the Armor Header key names

Maybe recheck those with the draft too.

dkg commented 1 month ago

If this is about some other PR, it'd probably be best to point to it, and comment over there.