ietf-openpgp
[Top] [All Lists]

[openpgp] whitespace definitions in OpenPGP [was: Re: I-D Action: draft-ietf-openpgp-crypto-refresh-01.txt]

2021-02-15 17:57:18
On Thu 2021-02-11 16:51:07 +0100, Guillem Jover wrote:
On Mon, 2021-02-08 at 10:50:02 +0000, Andrew Gallagher wrote:
On 07/02/2021 10:25, Peter Gutmann wrote:
Heiko Stamer <HeikoStamer(_at_)gmx(_dot_)net> writes:

For spaces and tabs the intention is clear for me, however, I am not sure
about carriage returns in general. According to Unicode Character 
Database
there are some other whitespace characters, e.g., form feed (0x0c). 
Should
such characters be included, too?

That also just seems wrong in general, the last major OS type I know of 
that
used CR delimiters was Mac OS from 1984.  Shouldn't this be LF or CRLF?
Wherever this came from, it's not in 4880, or any other common RFC that
defines a format for blank lines.

It reads to me like this change is intended to cover a "blank line" of
assorted spaces and tabs, with an optional trailing carriage return before
the line feed delimiter. The admission of carriage returns elsewhere in the
whitespace sequence is surely unintentional.

Yes this was the intention, as prompted by:

  
<https://git.dpkg.org/cgit/dpkg/dpkg.git/commit/?id=aea291e3db1ac0414dcf005a0a607e78bdd77a5e>

The original MR:

  <https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/6>

Note that the similar definition of "trailing white space" on line 69 should
be kept consistent with that of "blank line".

Ah probably missed that one.

Thanks for this discussion, all.

It seems clear to me that the text about whitespace that was merged into
-01 doesn't have WG consensus at the moment -- iiuc, it may address the
original concern raised by Guillem, but is unintentionally overbroad,
and might introduce further incompatibilities between implementations if
they try to follow the spec as written.

I propose the way forward for this is for now, we revert those changes,
and the next revision (-02) could retain the language about whitsepace
from RFC4880.  I've proposed that here:

    https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/33

(see also the attached diff)

In the meantime, so we don't lose sight of the legitimate problem that
Guillem wants addressed, I've opened
https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/11

If someone from the group wants to propose alternate text that addresses
the issue but doesn't introduce the inconsistencies identified by Andrew
and others, then please propose that text on-list here (in a different
thread?)  -- and if you can also make it as a merge request on gitlab
that'd be a bonus.

Regards,

   --dkg

From 0bf360cfc448211a85b287e2728b0a5792ba851d Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor <dkg(_at_)fifthhorseman(_dot_)net>
Date: Mon, 15 Feb 2021 18:33:30 -0500
Subject: [RFC4880bis PATCH] Revert "clarify blank lines and whitespace"

This reverts commit d343098838f7ef22df16dc187163417a7d0733e4.

[Discussion on the mailing
list](https://mailarchive.ietf.org/arch/msg/openpgp/AvsVX6SREEstygUHzHNjps40vq0/)
suggest that the changes in that commit don't have full consensus, and
indeed even the original author of the changes appears to acknowledge
that the definition doesn't cover the specific ground it intends to
cover.
---
 crypto-refresh.md | 10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/crypto-refresh.md b/crypto-refresh.md
index 7e17b6f..3616585 100644
--- a/crypto-refresh.md
+++ b/crypto-refresh.md
@@ -1989,7 +1989,7 @@ Concatenating the following data creates ASCII Armor:
 
 - Armor Headers
 
-- A blank line
+- A blank (zero-length, or containing only whitespace) line
 
 - The ASCII-Armored data
 
@@ -2024,7 +2024,7 @@ BEGIN PGP SIGNATURE
 
 Note that all these Armor Header Lines are to consist of a complete line.
 That is to say, there is always a line ending preceding the starting five 
dashes, and following the ending five dashes.
-The header lines, therefore, MUST start at the beginning of a line, and MUST 
NOT have text other than whitespace --- space (0x20), tab (0x09) or carriage 
return (0x0d) --- following them on the same line.
+The header lines, therefore, MUST start at the beginning of a line, and MUST 
NOT have text other than whitespace following them on the same line.
 These line endings are considered a part of the Armor Header Line for the 
purposes of determining the content they delimit.
 This is particularly important when computing a cleartext signature (see 
below).
 
@@ -2071,8 +2071,6 @@ Currently defined Armor Header Keys are as follows:
   In such instances, an implementation MAY override the UTF-8 default by using 
this header key.
   An implementation MAY implement this key and any translations it cares to; 
an implementation MAY ignore it and assume all text is UTF-8.
 
-The blank line can either be zero-length or contain only whitespace, that is 
spaces (0x20), tabs (0x09) or carriage returns (0x0d).
-
 The Armor Tail Line is composed in the same manner as the Armor Header Line, 
except the string "BEGIN" is replaced by the string "END".
 
 ## Encoding Binary in Radix-64 {#encoding-binary-radix64}
@@ -2189,7 +2187,7 @@ The cleartext signed message consists of:
 
 - One or more "Hash" Armor Headers,
 
-- Exactly one blank line not included into the message digest,
+- Exactly one empty line not included into the message digest,
 
 - The dash-escaped cleartext that is included into the message digest,
 
@@ -2219,7 +2217,7 @@ The line ending (i.e., the \<CR>\<LF>) before the 
`-----BEGIN PGP SIGNATURE-----
 
 When reversing dash-escaping, an implementation MUST strip the string `- ` if 
it occurs at the beginning of a line, and SHOULD warn on `-` and any character 
other than a space at the beginning of a line.
 
-Also, any trailing whitespace --- spaces (0x20), tabs (0x09) or carriage 
returns (0x0d) --- at the end of any line is removed when the cleartext 
signature is generated and verified.
+Also, any trailing whitespace --- spaces (0x20) and tabs (0x09) --- at the end 
of any line is removed when the cleartext signature is generated.
 
 # Regular Expressions {#regular-expressions}
 
-- 
2.30.0

Attachment: signature.asc
Description: PGP signature

_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp
<Prev in Thread] Current Thread [Next in Thread>