Re: [openpgp] OpenPGP Armor Message specification

Werner Koch <wk@gnupg.org> Thu, 14 September 2017 09:13 UTC

Return-Path: <wk@gnupg.org>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB78132D18 for <openpgp@ietfa.amsl.com>; Thu, 14 Sep 2017 02:13:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Ma_DDaz9oPY for <openpgp@ietfa.amsl.com>; Thu, 14 Sep 2017 02:13:39 -0700 (PDT)
Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0280C132D51 for <openpgp@ietf.org>; Thu, 14 Sep 2017 02:13:38 -0700 (PDT)
Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1dsQDJ-00037F-4m for <openpgp@ietf.org>; Thu, 14 Sep 2017 11:13:37 +0200
Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1dsQ8F-00077A-KT; Thu, 14 Sep 2017 11:08:23 +0200
From: Werner Koch <wk@gnupg.org>
To: Guillem Jover <guillem@hadrons.org>
Cc: openpgp@ietf.org
References: <20150918162458.GA14374@gaara.hadrons.org> <20151019165213.GA15609@gaara.hadrons.org> <20170812185752.lagvmaf62h3tv2rb@gaara.hadrons.org>
Organisation: The GnuPG Project
X-message-flag: Mails containing HTML will not be read! Please send only plain text.
OpenPGP: url=https://k.gnupg.net/80615870F5BAD690333686D0F2AD85AC1E42B367
Mail-Followup-To: Guillem Jover <guillem@hadrons.org>, openpgp@ietf.org
Date: Thu, 14 Sep 2017 11:08:23 +0200
In-Reply-To: <20170812185752.lagvmaf62h3tv2rb@gaara.hadrons.org> (Guillem Jover's message of "Sat, 12 Aug 2017 20:57:53 +0200")
Message-ID: <877ex1tzp4.fsf@wheatstone.g10code.de>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=Taiwan_kibo_mailbomb_cracking_Sundevil_Lon_Horiuchi_AMW_2600_Magazin"; micalg="pgp-sha256"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/kCxa9A8eQxcuH6t4btZpAVIiKCo>
Subject: Re: [openpgp] OpenPGP Armor Message specification
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Sep 2017 09:13:41 -0000

On Sat, 12 Aug 2017 20:57, guillem@hadrons.org said:

> 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 <guillem@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
 

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.