From nobody Thu Sep 14 02:13:43 2017 Return-Path: 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 AD8E8132F76 for ; Thu, 14 Sep 2017 02:13:40 -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 gaiWGv2bpPk3 for ; 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 02543132D18 for ; 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 1dsQDI-000372-KG for ; Thu, 14 Sep 2017 11:13:36 +0200 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1dsQ5F-00074c-8g; Thu, 14 Sep 2017 11:05:17 +0200 From: Werner Koch To: Clint Adams Cc: openpgp@ietf.org References: <20170811201011.2fynredjcllcgz2f@scru.org> <20170827222946.xnrkx4sdtitefwoc@scru.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: Clint Adams , openpgp@ietf.org Date: Thu, 14 Sep 2017 11:05:10 +0200 In-Reply-To: <20170827222946.xnrkx4sdtitefwoc@scru.org> (Clint Adams's message of "Sun, 27 Aug 2017 22:29:46 +0000") Message-ID: <87bmmdtzuh.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=Commecen_ISEC_broadside_quiche_Agfa_threat_Cohiba_embassy_plutonium="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] Curve25519/ECDH X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Sep 2017 09:13:41 -0000 --=Commecen_ISEC_broadside_quiche_Agfa_threat_Cohiba_embassy_plutonium= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 28 Aug 2017 00:29, clint@debian.org said: > On Fri, Aug 11, 2017 at 08:10:11PM +0000, Clint Adams wrote: >> After speaking with NIIBE-san this morning, I think there could be some >> more clarity with regard to how Curve25519 keys are meant to be >> public-key algorithm 18. I have pushed your changes and also added the missing bit and octetsizes for Curve25519. Thanks/ Salam-Shalom, Werner =2D-=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=Commecen_ISEC_broadside_quiche_Agfa_threat_Cohiba_embassy_plutonium= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTX/8BjtAoilLlm20f/gK6dHew1jQUCWbpGRgAKCRD/gK6dHew1 jbbhAP9Q1Yu2LVPk6k/US0LVbOZBFCQWmEHUT3uxLIQMWFt87QD8Cuy9fDW06amQ FKL+VCq8GsssOWLOEArCbH+uBBArHAA= =uS+N -----END PGP SIGNATURE----- --=Commecen_ISEC_broadside_quiche_Agfa_threat_Cohiba_embassy_plutonium=-- From nobody Thu Sep 14 02:13:49 2017 Return-Path: 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 ; 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 ; 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 ; 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 ; 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 To: Guillem Jover 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 , 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: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Sep 2017 09:13:41 -0000 --=Taiwan_kibo_mailbomb_cracking_Sundevil_Lon_Horiuchi_AMW_2600_Magazin Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 12 Aug 2017 20:57, guillem@hadrons.org said: > I've fixed a couple of typos and, now opened a merge request > . I have pushed your changes. For reference I include the patch below. Thanks. Shalom-Salam, Werner =3D=3D=3D=3D=3D commit 24b1bba57e3739deb593554c94822b01b7589a32 Author: Guillem Jover Date: Mon Oct 19 16:33:32 2015 +0200 Clarify ASCII Armoring and Cleartext formats =20=20=20=20 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 =2D-- a/middle.mkd +++ b/middle.mkd @@ -2730,7 +2730,7 @@ ## {6.2} Forming ASCII Armor =20 * Armor Headers =20 =2D * A blank (zero-length, or containing only whitespace) line + * A blank line =20 * The ASCII-Armored data =20 @@ -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 =2Dhave 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 =2Dto 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. =20 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. =20 +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". =20 @@ -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 =2Dcleartext, 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.) =20 @@ -2977,7 +2983,7 @@ # {7} Cleartext Signature Framework =20 - One or more "Hash" Armor Headers, =20 =2D - Exactly one empty line not included into the message digest, + - Exactly one blank line not included into the message digest, =20 - 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. =20 =2DAlso, any trailing whitespace -- spaces (0x20) and tabs (0x09) -- at =2Dthe end of any line is removed when the cleartext signature is =2Dgenerated. +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. =20 # {8} Regular Expressions =20 =2D-=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=Taiwan_kibo_mailbomb_cracking_Sundevil_Lon_Horiuchi_AMW_2600_Magazin Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTX/8BjtAoilLlm20f/gK6dHew1jQUCWbpHBwAKCRD/gK6dHew1 jUNaAQDRXvPsq3ZT6l/NA1S32/qijlI4kkrg32XsXJRJbryK3gD7BYOP5au9lB5x NQoXTbYAfEiW/tHTwqgenWJmG4GVlAU= =7qNQ -----END PGP SIGNATURE----- --=Taiwan_kibo_mailbomb_cracking_Sundevil_Lon_Horiuchi_AMW_2600_Magazin-- From nobody Fri Sep 29 09:12:06 2017 Return-Path: X-Original-To: openpgp@ietf.org Delivered-To: openpgp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C585132F76; Fri, 29 Sep 2017 09:12:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: ekr@rtfm.com, openpgp@ietf.org, barryleiba@gmail.com, openpgp-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150670152411.14169.3601408773853822263.idtracker@ietfa.amsl.com> Date: Fri, 29 Sep 2017 09:12:04 -0700 Archived-At: Subject: [openpgp] openpgp - Not having a session at IETF 100 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Sep 2017 16:12:04 -0000 Barry Leiba, a chair of the openpgp working group, indicated that the openpgp working group does not plan to hold a session at IETF 100. This message was generated and sent by the IETF Meeting Session Request Tool.