[openpgp] OpenPGP Armor Message specification

[Guillem Jover]

Hi!

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»

Thanks,
Guillem

[Guillem Jover]

Hi!

Post by Guillem Jover
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>
* 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?
«- Exactly one empty line not included into the message digest,»
«- 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

[Guillem Jover]

Hi!

Post by Guillem Jover

Post by Guillem Jover
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>
* 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?
«- Exactly one empty line not included into the message digest,»
«- 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.

I've fixed a couple of typos and, now opened a merge request
<https://gitlab.com/openpgp-wg/rfc4880bis/merge_requests/6>.

Thanks,
Guillem

[Werner Koch]

Post by Guillem Jover
I've fixed a couple of typos and, now opened a merge request
<https://gitlab.com/openpgp-wg/rfc4880bis/merge_requests/6>.

I have pushed your changes. For reference I include the patch below.
Thanks.


Shalom-Salam,

Werner


=====
commit 24b1bba57e3739deb593554c94822b01b7589a32
Author: Guillem Jover <***@hadrons.org>
Date: Mon Oct 19 16:33:32 2015 +0200

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.

Modified middle.mkd
diff --git a/middle.mkd b/middle.mkd
index ec864c4..7f4b1fb 100644
--- a/middle.mkd
+++ b/middle.mkd
@@ -2730,7 +2730,7 @@ ## {6.2} Forming ASCII Armor

* Armor Headers

- * A blank (zero-length, or containing only whitespace) line
+ * A blank line

* The ASCII-Armored data

@@ -2777,7 +2777,8 @@ ## {6.2} Forming ASCII Armor
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).
@@ -2798,7 +2799,7 @@ ## {6.2} Forming ASCII Armor
there is a limit of 76 characters for the Radix-64 data (Section 6.3),
there is no limit to the length of Armor Headers. Care should be taken
that the Armor Headers are short enough to survive transport. One way
-to do this is to repeat an Armor Header key multiple times with
+to do this is to repeat an Armor Header Key multiple times with
different values for each so that no one line is overly long.

Currently defined Armor Header Keys are as follows:
@@ -2844,6 +2845,9 @@ ## {6.2} Forming ASCII Armor
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".

@@ -2966,7 +2970,9 @@ # {7} Cleartext Signature Framework
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 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.)

@@ -2977,7 +2983,7 @@ # {7} Cleartext Signature Framework

- 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,
@@ -3022,9 +3028,9 @@ ## {7.1} Dash-Escaped Text
"- " 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