From 159e601ec1e05d78d51a1e8af30e10260617848a Mon Sep 17 00:00:00 2001 From: Guillem Jover 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