Subject: Re: [openpgp] OpenPGP Armor Message specification

From: Guillem Jover <[email-masked]>
Date: Mon, 19 Oct 2015 18:52:13 +0200

Hi!

On Fri, 2015-09-18 at 18:24:58 +0200, Guillem Jover wrote:
> As I mentioned to Werner and Daniel at DebConf 15, I think the
> specification of the OpenPGP Armor Messages has some unclear parts,
> which I think were part of the reason for several security issues
> in multiple projects due to mismatched parsing of Armor Header Lines.
> 
>   <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695919>
>   <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695932>
>   <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=696230>
>   <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=696234>
>   <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704613>
> 
> Here are some things that would be good to clarify in RFC4880:
> 
> * In §6.2 there's no explicit definition of what ASCII characters are
>   to be considered whitespace (contrast that with §7.1). In this case
>   GnuPG considers whitespace to be «SPACE 0x20, HT 0x09 and CR 0x0D»
>   and now most tools in Debian do too. I don't know if that matches
>   with PGP for example.
> 
> * In §7, mention that this is a specific instance of §6.2?
> 
> * In §7, probably clarify that by «empty» in:
>   «- Exactly one empty line not included into the message digest,»
>   it means «blank» as in §6.2:
>   «- A blank (zero-length, or containing only whitespace) line»

Ok, how about something along the lines of the attached patch against
RFC4880bis?

Although maybe it would be better to define "whitespace" just once
instead of inlining it in several places.

Thanks,
Guillem
From 159e601ec1e05d78d51a1e8af30e10260617848a Mon Sep 17 00:00:00 2001
From: Guillem Jover <[email-masked]>
Date: Mon, 19 Oct 2015 16:33:32 +0200
Subject: [PATCH] Clarify ASCII Armoring and Cleartext formats

Describe explicitly what ASCII characters are considered whitespace.
Use "blank" instead of "empty" when referring to a blank line that can
be either zero-length or contain only whitespace, and describe what it
means. Mention that Section 7 follows the same format and restrictions
of Section 6.2. Add that trailing whitespace at the end of any line is
removed for both signature generation and verification.
---
 misc/id/rfc4880bis/middle.mkd | 20 +++++++++++++-------
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/misc/id/rfc4880bis/middle.mkd b/misc/id/rfc4880bis/middle.mkd
index 80c0a61..1c919aa 100644
--- a/misc/id/rfc4880bis/middle.mkd
+++ b/misc/id/rfc4880bis/middle.mkd
@@ -2403,7 +2403,7 @@ Concatenating the following data creates ASCII Armor:
 
   * Armor Headers
 
-  * A blank (zero-length, or containing only whitespace) line
+  * A blank line
 
   * The ASCII-Armored data
 
@@ -2450,7 +2450,8 @@ 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 following them on the same line.  These
+have text other than whitespace -- space (0x20), tab (0x09) or carriage
+return (0x0d) -- 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).
@@ -2517,6 +2518,9 @@ Currently defined Armor Header Keys are as follows:
     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".
 
@@ -2639,7 +2643,9 @@ would have no leading whitespace.
 It is desirable to be able to sign a textual octet stream without
 ASCII armoring the stream itself, so the signed text is still readable
 without special software.  In order to bind a signature to such a
-cleartext, this framework is used. (Note that this framework is not
+cleartext, this framework is used, which follows the the same basic
+format and restrictions as the ASCII armoring described above in
+"Forming ASCII Armor" (Section 6.2). (Note that this framework is not
 intended to be reversible.  RFC 3156 [](#RFC3156) defines another way
 to sign cleartext messages for environments that support MIME.)
 
@@ -2650,7 +2656,7 @@ The cleartext signed message consists of:
 
   - One or more "Hash" Armor Headers,
 
-  - Exactly one empty line not included into the message digest,
+  - Exactly one blank line not included into the message digest,
 
   - The dash-escaped cleartext that is included into the message
     digest,
@@ -2695,9 +2701,9 @@ 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) and tabs (0x09) -- at
-the end of any line is removed when the cleartext signature is
-generated.
+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.
 
 # {8}  Regular Expressions
 
-- 
2.6.1.204.gc021fdf