From nobody Fri Sep 7 06:52:53 2018 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 E1778130E11 for ; Fri, 7 Sep 2018 06:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_TVD_MIME_EPI=0.01] 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 3nSYugOME18m for ; Fri, 7 Sep 2018 06:52:48 -0700 (PDT) Received: from kolab.intevation.de (kolab.intevation.de [212.95.107.133]) by ietfa.amsl.com (Postfix) with ESMTP id 67F70130DD5 for ; Fri, 7 Sep 2018 06:52:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by kolab.intevation.de (Postfix) with ESMTP id 8D05362601 for ; Fri, 7 Sep 2018 15:52:45 +0200 (CEST) X-Virus-Scanned: by amavisd-new at intevation.de Received: from kolab.intevation.de ([127.0.0.1]) by localhost (kolab.intevation.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63VGTSu5ouFv for ; Fri, 7 Sep 2018 15:52:44 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by kolab.intevation.de (Postfix) with ESMTP id 478FF62618 for ; Fri, 7 Sep 2018 15:52:44 +0200 (CEST) Received: from esus.localnet (81-5-224-141.hdsl.highway.telekom.at [81.5.224.141]) (Authenticated sender: andre.heinecke@intevation.de) by kolab.intevation.de (Postfix) with ESMTPSA id 1F91562601 for ; Fri, 7 Sep 2018 15:52:44 +0200 (CEST) From: Andre Heinecke To: IETF OpenPGP Date: Fri, 07 Sep 2018 15:52:43 +0200 Message-ID: <1803390.QxyNr08ExB@esus> User-Agent: KMail/5.2.3 (Linux/4.9.0-8-amd64; KDE/5.28.0; x86_64; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart14272849.uAfqNS25KT"; micalg="pgp-sha256"; protocol="application/pgp-signature" Archived-At: Subject: [openpgp] A way to securely define cleartext signature charset X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2018 13:52:51 -0000 --nextPart14272849.uAfqNS25KT Content-Type: multipart/mixed; boundary="nextPart2830790.aGJa6Veiee" Content-Transfer-Encoding: quoted-printable This is a multi-part message in MIME format. --nextPart2830790.aGJa6Veiee Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Hi, today I struggled for several hours with "charset guessing" code, that hand= les=20 cleartext signatures in outlook and I thought that maybe this situation cou= ld=20 be improved a bit in the future? I dislike cleartext signatures as much as the next guy (probably more ;-) ). The points made in [1] are valid and such messages should not be used. But realistically I think that they won't go away. My idea would be to define that after the Hash: header and the blank line=20 (which starts the hashing) that there can be: Optionally a "Charset" Armor Header followed by one blank line, both included in the message digest. So a message like: =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Charset: UTF-8 This is =E4n example m=E4ss=E4ge. =2D----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQRwkxlKrbuKLRTTyRcpeOnUDLq6XAUCW5J/hwAKCRApeOnUDLq6 XLEJAP45MRTaU61PFP8RDaV6cvyzFqQUmXy6lvQIf2TcomOfcwEAt+oa3hUzaAGT KEEKB1375wj2nf38Tg+FjgWKsHkKZAw=3D =3DR36C =2D----END PGP SIGNATURE----- An rfc4880 implementation would just show: =2D--- Charset: UTF-8 This is =E4n example m=E4ss=E4ge. =2D--- Ok that is slightly ugly but it's informative and the signature will still = be=20 verified correctly. An rfc4880bis application could evaluate the header and omit it in the outp= ut. Attached is a patch to the draft. Best Regards, Andre 1: https://dkg.fifthhorseman.net/notes/inline-pgp-harmful/ =2D-=20 Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr=FCck | AG Osnabr=FCck, HR B = 18998 Gesch=E4ftsf=FChrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner --nextPart2830790.aGJa6Veiee Content-Disposition: attachment; filename="0001-Add-optional-charset-specification.patch" Content-Transfer-Encoding: 7Bit Content-Type: text/x-patch; charset="UTF-8"; name="0001-Add-optional-charset-specification.patch" From=208ac7a240edeb28229cb5afe722484462703f9b4e Mon Sep 17 00:00:00 2001 From: Andre Heinecke Date: Fri, 7 Sep 2018 15:44:33 +0200 Subject: [PATCH] Add optional charset specification --- middle.mkd | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/middle.mkd b/middle.mkd index 9e5bb58..1347aea 100644 --- a/middle.mkd +++ b/middle.mkd @@ -3074,6 +3074,9 @@ The cleartext signed message consists of: - Exactly one blank line not included into the message digest, + - Optionally a "Charset" Armor Header followed by one blank line, + both included in the message digest, + - The dash-escaped cleartext that is included into the message digest, @@ -3090,6 +3093,15 @@ contains a comma-delimited list of used message digests. Current message digest names are described below with the algorithm IDs. +If the "Charset" Armor Header is given, the specified message is +to be expected in that encoding. If the Header is omitted an +implementation SHOULD try to guess the charset from the context +of the message. For example by using the systems local 8 bit +charset or checking for the content-type in a MIME context. + +An implementation MAY assume UTF-8 encoding in case the "Charset" +Header is omitted. + An implementation SHOULD add a line break after the cleartext, but MAY omit it if the cleartext ends with a line break. This is for visual clarity. -- 2.11.0 --nextPart2830790.aGJa6Veiee-- This is a multi-part message in MIME format. --nextPart2830790.aGJa6Veiee Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Hi, today I struggled for several hours with "charset guessing" code, that hand= les=20 cleartext signatures in outlook and I thought that maybe this situation cou= ld=20 be improved a bit in the future? I dislike cleartext signatures as much as the next guy (probably more ;-) ). The points made in [1] are valid and such messages should not be used. But realistically I think that they won't go away. My idea would be to define that after the Hash: header and the blank line=20 (which starts the hashing) that there can be: Optionally a "Charset" Armor Header followed by one blank line, both included in the message digest. So a message like: =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Charset: UTF-8 This is =E4n example m=E4ss=E4ge. =2D----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQRwkxlKrbuKLRTTyRcpeOnUDLq6XAUCW5J/hwAKCRApeOnUDLq6 XLEJAP45MRTaU61PFP8RDaV6cvyzFqQUmXy6lvQIf2TcomOfcwEAt+oa3hUzaAGT KEEKB1375wj2nf38Tg+FjgWKsHkKZAw=3D =3DR36C =2D----END PGP SIGNATURE----- An rfc4880 implementation would just show: =2D--- Charset: UTF-8 This is =E4n example m=E4ss=E4ge. =2D--- Ok that is slightly ugly but it's informative and the signature will still = be=20 verified correctly. An rfc4880bis application could evaluate the header and omit it in the outp= ut. Attached is a patch to the draft. Best Regards, Andre 1: https://dkg.fifthhorseman.net/notes/inline-pgp-harmful/ =2D-=20 Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr=FCck | AG Osnabr=FCck, HR B = 18998 Gesch=E4ftsf=FChrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner --nextPart2830790.aGJa6Veiee Content-Disposition: attachment; filename="0001-Add-optional-charset-specification.patch" Content-Transfer-Encoding: 7Bit Content-Type: text/x-patch; charset="UTF-8"; name="0001-Add-optional-charset-specification.patch" >From 8ac7a240edeb28229cb5afe722484462703f9b4e Mon Sep 17 00:00:00 2001 From: Andre Heinecke Date: Fri, 7 Sep 2018 15:44:33 +0200 Subject: [PATCH] Add optional charset specification --- middle.mkd | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/middle.mkd b/middle.mkd index 9e5bb58..1347aea 100644 --- a/middle.mkd +++ b/middle.mkd @@ -3074,6 +3074,9 @@ The cleartext signed message consists of: - Exactly one blank line not included into the message digest, + - Optionally a "Charset" Armor Header followed by one blank line, + both included in the message digest, + - The dash-escaped cleartext that is included into the message digest, @@ -3090,6 +3093,15 @@ contains a comma-delimited list of used message digests. Current message digest names are described below with the algorithm IDs. +If the "Charset" Armor Header is given, the specified message is +to be expected in that encoding. If the Header is omitted an +implementation SHOULD try to guess the charset from the context +of the message. For example by using the systems local 8 bit +charset or checking for the content-type in a MIME context. + +An implementation MAY assume UTF-8 encoding in case the "Charset" +Header is omitted. + An implementation SHOULD add a line break after the cleartext, but MAY omit it if the cleartext ends with a line break. This is for visual clarity. -- 2.11.0 --nextPart2830790.aGJa6Veiee-- --nextPart14272849.uAfqNS25KT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRwkxlKrbuKLRTTyRcpeOnUDLq6XAUCW5KCqwAKCRApeOnUDLq6 XOJOAQC+Pw/gQ2ba7SP3qK1Ey3eUgQ31cDxccQieyWo2HpcQBwD/Qw9D2N9RZUDb OZtJu1zAxbhTSBz8/v1aFQTVQnTBkwU= =W3ih -----END PGP SIGNATURE----- --nextPart14272849.uAfqNS25KT-- From nobody Sat Sep 8 04:20:01 2018 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 C42C41286E3 for ; Sat, 8 Sep 2018 04:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_ABOUTYOU=0.5, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 sYsOtAiQz6EI for ; Sat, 8 Sep 2018 04:19:57 -0700 (PDT) Received: from nimbus.fccf.net (nimbus.fccf.net [77.77.144.35]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9CE91277D2 for ; Sat, 8 Sep 2018 04:19:57 -0700 (PDT) Received: from straylight.m.ringlet.net (212-39-89-232.ip.btc-net.bg [212.39.89.232]) by nimbus.fccf.net (Postfix) with ESMTPSA id BF7E4331 for ; Sat, 8 Sep 2018 14:19:54 +0300 (EEST) Received: from roam (uid 1000) (envelope-from roam@ringlet.net) id 6208c9 by straylight.m.ringlet.net (DragonFly Mail Agent v0.11); Sat, 08 Sep 2018 14:19:53 +0300 Date: Sat, 8 Sep 2018 14:19:53 +0300 From: Peter Pentchev To: Andre Heinecke Cc: IETF OpenPGP Message-ID: <20180908111953.GE5330@straylight.m.ringlet.net> References: <1803390.QxyNr08ExB@esus> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8nsIa27JVQLqB7/C" Content-Disposition: inline In-Reply-To: <1803390.QxyNr08ExB@esus> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [openpgp] A way to securely define cleartext signature charset X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2018 11:20:00 -0000 --8nsIa27JVQLqB7/C Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 07, 2018 at 03:52:43PM +0200, Andre Heinecke wrote: > Hi, >=20 > today I struggled for several hours with "charset guessing" code, that ha= ndles=20 > cleartext signatures in outlook and I thought that maybe this situation c= ould=20 > be improved a bit in the future? >=20 > I dislike cleartext signatures as much as the next guy (probably more ;-)= ). > The points made in [1] are valid and such messages should not be used. > But realistically I think that they won't go away. >=20 > My idea would be to define that after the Hash: header and the blank line= =20 > (which starts the hashing) that there can be: >=20 > Optionally a "Charset" Armor Header followed by one blank line, > both included in the message digest. >=20 > So a message like: >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 >=20 > Charset: UTF-8 >=20 > This is =C3=A4n example m=C3=A4ss=C3=A4ge. > -----BEGIN PGP SIGNATURE----- Hmm, is there any way to guard against a false positive identification of an "old" message that just happens to start with such a line? I can't think of any off the top of my head... Don't get me wrong, I *do* see the good things about your proposal. Best regards, Peter --=20 Peter Pentchev roam@{ringlet.net,debian.org,FreeBSD.org} pp@storpool.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 --8nsIa27JVQLqB7/C Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEELuenpRf8EkzxFcNUZR7vsCUn3xMFAluTsFQACgkQZR7vsCUn 3xPtxg//V3GMtk0AT9AEDOG9mLm+vJm0xBkMdM5D2pSlrqel3GCaOsDZDBPFmxXB OTWspcORH4rU+T9YXIqqGvzXCx0C8lXmxON29FXJ9RAgq8VO14ztM2q0hqUXNw+o cEYf8qoN68D6LLGPs1u0sXj/UfmgSLVVea4v5zEuJMw/dgESSeKGc3W8aZPj21wY Ecdv6F3va0Uw6ZaXNK0ENZ/1lkU8MG8aPECYQ0I3Dexcr/7MBREkJy2VheZbR88c cC5bB82iRXxm14adzNvGqFUOdiBvV9tAvTyaLxgE4+RCd0vn+9LtkX/R8Go0rbJR viV6ccuOHTqapiLBMkltRytYbfrk2/KrsQjbRG/3VOHvfY32K1k5Pl0RlmjlRCvh 0wshQP1Vywb/y//PB5d3WmVSpBBXNC5V2i9Quug+1sV2DcC9iKUn8HX7XmvWIuo5 ab++yXu8nHaHmsUbOxs7M4D6/P6OIGRH81vfOCQ4J3k0y56Qs75hUB6hcs5XCQPz V6gW0qQ26Ek9hh/yrKxcPREOeYeyggcrAbBvz+Uwor3EVwwO7Ah9dViPQZugd3y8 g0RJ3dNqSG5TnOrfLgR75B+/c8RjWK90vguOBgTd0QiQ3oSaoDyZY7HPw0qtnGfq B+ib0sspA8lHrMy5arfAR5FAziR78TR9pYx1BOx0cbB/i1zsn1U= =KQ+o -----END PGP SIGNATURE----- --8nsIa27JVQLqB7/C-- From nobody Sat Sep 8 07:43:33 2018 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 36366128CFD for ; Sat, 8 Sep 2018 07:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ruhr-uni-bochum.de 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 Hs0aE5B4_Sns for ; Sat, 8 Sep 2018 07:43:29 -0700 (PDT) Received: from out2.mail.ruhr-uni-bochum.de (out2.mail.ruhr-uni-bochum.de [IPv6:2a05:3e00:c:1001::8693:2ae5]) (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 08430126CC7 for ; Sat, 8 Sep 2018 07:43:29 -0700 (PDT) Received: from mx2.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by out2.mail.ruhr-uni-bochum.de (Postfix mo-ext) with ESMTP id 426xrG43fsz4yBS for ; Sat, 8 Sep 2018 16:43:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ruhr-uni-bochum.de; s=mail-2017; t=1536417806; bh=dR0NFezEe3GC7qM8NDffzY9v6XVP21oVuWgdxV1IOEg=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Tu5RnLAOf5b4Fbl0z+c2U6CMk/CWqxGFVBpc6diQvSeo4AgN0ZtQzGbJmAme8vtCI o/RMn/9dO11/Of7e+5pur2LUHv7bS3MZutbKDJ1QnH59JnfIphHhVdhB3vN4m0hXkJ aV0/xCUsA2W75FN7MItSTYFgDovJCauW33BvLhN4= Received: from out2.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by mx2.mail.ruhr-uni-bochum.de (Postfix idis) with ESMTP id 426xrG3Bbfz4yDp for ; Sat, 8 Sep 2018 16:43:26 +0200 (CEST) X-Envelope-Sender: X-RUB-Notes: Internal origin=134.147.42.227 Received: from mail1.mail.ruhr-uni-bochum.de (mail1.mail.ruhr-uni-bochum.de [134.147.42.227]) by out2.mail.ruhr-uni-bochum.de (Postfix mi-int) with ESMTP id 426xrG0Zx7z4yBS for ; Sat, 8 Sep 2018 16:43:25 +0200 (CEST) Received: from [192.168.142.139] (p4FE3F0F0.dip0.t-ipconnect.de [79.227.240.240]) by mail1.mail.ruhr-uni-bochum.de (Postfix) with ESMTPSA id 426xrF4mCqzyW8 for ; Sat, 8 Sep 2018 16:43:25 +0200 (CEST) To: openpgp@ietf.org References: <1803390.QxyNr08ExB@esus> From: Marcus Brinkmann Openpgp: preference=signencrypt Message-ID: Date: Sat, 8 Sep 2018 16:43:25 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <1803390.QxyNr08ExB@esus> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.4 at mail1.mail.ruhr-uni-bochum.de X-Virus-Status: Clean Archived-At: Subject: Re: [openpgp] A way to securely define cleartext signature charset X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2018 14:43:31 -0000 Why not a hashed signature subpacket? On 09/07/2018 03:52 PM, Andre Heinecke wrote:> Hi, > > today I struggled for several hours with "charset guessing" code, that handles > cleartext signatures in outlook and I thought that maybe this situation could > be improved a bit in the future? > > I dislike cleartext signatures as much as the next guy (probably more ;-) ). > The points made in [1] are valid and such messages should not be used. > But realistically I think that they won't go away. > > My idea would be to define that after the Hash: header and the blank line > (which starts the hashing) that there can be: > > Optionally a "Charset" Armor Header followed by one blank line, > both included in the message digest. > > So a message like: > > Charset: UTF-8 > > This is än example mässäge. > > > An rfc4880 implementation would just show: > ---- > Charset: UTF-8 > > This is än example mässäge. > ---- > > Ok that is slightly ugly but it's informative and the signature will still be > verified correctly. > An rfc4880bis application could evaluate the header and omit it in the output. > > > Attached is a patch to the draft. > > > Best Regards, > Andre > > > 1: https://dkg.fifthhorseman.net/notes/inline-pgp-harmful/ > > > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > From nobody Sat Sep 8 11:00:52 2018 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 2FA4B130E2B for ; Sat, 8 Sep 2018 11:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_ABOUTYOU=0.5, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=no 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 sIR3dhhi2aqz for ; Sat, 8 Sep 2018 11:00:49 -0700 (PDT) Received: from kolab.intevation.de (kolab.intevation.de [212.95.107.133]) by ietfa.amsl.com (Postfix) with ESMTP id 153C6130E1C for ; Sat, 8 Sep 2018 11:00:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by kolab.intevation.de (Postfix) with ESMTP id 6A17262286 for ; Sat, 8 Sep 2018 20:00:48 +0200 (CEST) X-Virus-Scanned: by amavisd-new at intevation.de Received: from kolab.intevation.de ([127.0.0.1]) by localhost (kolab.intevation.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgb-YQTQ1tiL for ; Sat, 8 Sep 2018 20:00:45 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by kolab.intevation.de (Postfix) with ESMTP id C4168622F0 for ; Sat, 8 Sep 2018 20:00:45 +0200 (CEST) Received: from esus.localnet (81-5-224-141.hdsl.highway.telekom.at [81.5.224.141]) (Authenticated sender: andre.heinecke@intevation.de) by kolab.intevation.de (Postfix) with ESMTPSA id 9694F62273; Sat, 8 Sep 2018 20:00:45 +0200 (CEST) From: Andre Heinecke To: openpgp@ietf.org Cc: Peter Pentchev Date: Sat, 08 Sep 2018 20:00:44 +0200 Message-ID: <2724293.aWr2D75my6@esus> User-Agent: KMail/5.2.3 (Linux/4.9.0-8-amd64; KDE/5.28.0; x86_64; ; ) In-Reply-To: <20180908111953.GE5330@straylight.m.ringlet.net> References: <1803390.QxyNr08ExB@esus> <20180908111953.GE5330@straylight.m.ringlet.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2132294.v3e1ENcnqK"; micalg="pgp-sha256"; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] A way to securely define cleartext signature charset X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2018 18:00:50 -0000 --nextPart2132294.v3e1ENcnqK Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Hi, On Saturday, September 8, 2018 2:19:53 PM CEST Peter Pentchev wrote: > Hmm, is there any way to guard against a false positive identification of > an "old" message that just happens to start with such a line? I can't > think of any off the top of my head... I do not think so. Well you could put additional information in the signatu= re=20 that will identify it as a cleartext signature following rfc4880bis and onl= y=20 then handle the charset header. But I think that would overcomplicate it. I do not think that a false positivie would not hurt much. PGP Inline chars= et=20 handling is basically guessing so a false positive would just be a false=20 guess. And I think that if someone today signs a message that says Charset: XYZ And then continues with some text in another charset it would be weird anyw= ay.=20 > Don't get me wrong, I *do* see the good things about your proposal. Thanks!=20 Best Regards, Andre =2D-=20 Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr=FCck | AG Osnabr=FCck, HR B = 18998 Gesch=E4ftsf=FChrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner --nextPart2132294.v3e1ENcnqK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRwkxlKrbuKLRTTyRcpeOnUDLq6XAUCW5QOTQAKCRApeOnUDLq6 XFSaAQDoBZmIOtfPsQle0xn9YS2NnOjgsL6he9O895QH9GEJ8gD+Pncge+GFboag clJlXjmY1phq2DK32I6nCnTQCsPGTw0= =Foj6 -----END PGP SIGNATURE----- --nextPart2132294.v3e1ENcnqK-- From nobody Sat Sep 8 11:27:35 2018 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 BB97C130E3F for ; Sat, 8 Sep 2018 11:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] 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 oFBPYmziY6kD for ; Sat, 8 Sep 2018 11:27:32 -0700 (PDT) Received: from kolab.intevation.de (kolab.intevation.de [212.95.107.133]) by ietfa.amsl.com (Postfix) with ESMTP id 54C7C130E37 for ; Sat, 8 Sep 2018 11:27:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by kolab.intevation.de (Postfix) with ESMTP id 22E5D6243C for ; Sat, 8 Sep 2018 20:27:31 +0200 (CEST) X-Virus-Scanned: by amavisd-new at intevation.de Received: from kolab.intevation.de ([127.0.0.1]) by localhost (kolab.intevation.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2XQ1pBlOU6Jj for ; Sat, 8 Sep 2018 20:27:30 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by kolab.intevation.de (Postfix) with ESMTP id 559356245A for ; Sat, 8 Sep 2018 20:27:30 +0200 (CEST) Received: from esus.localnet (81-5-224-141.hdsl.highway.telekom.at [81.5.224.141]) (Authenticated sender: andre.heinecke@intevation.de) by kolab.intevation.de (Postfix) with ESMTPSA id 28F846243C for ; Sat, 8 Sep 2018 20:27:30 +0200 (CEST) From: Andre Heinecke To: openpgp@ietf.org Date: Sat, 08 Sep 2018 20:27:29 +0200 Message-ID: <11022095.V4M2a8AgS6@esus> User-Agent: KMail/5.2.3 (Linux/4.9.0-8-amd64; KDE/5.28.0; x86_64; ; ) In-Reply-To: References: <1803390.QxyNr08ExB@esus> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4746153.78YUkml5oY"; micalg="pgp-sha256"; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] A way to securely define cleartext signature charset X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2018 18:27:34 -0000 --nextPart4746153.78YUkml5oY Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Hi, On Saturday, September 8, 2018 4:43:25 PM CEST Marcus Brinkmann wrote: > Why not a hashed signature subpacket? Mostly because in an Application you can already use the information from t= he=20 header before you do any OpenPGP parsing / signature verification. E.g. in a MUA you usually want to show the data while you are verifying the= =20 signature. A charset Header could be easily parsed by a MUA and taken as a= =20 suggestion how to present the data. There might also be the case where you know the charset was changed in=20 transfer and you have to convert the charset back to get the correct=20 bytestream that matches the signature before passing it to your OpenPGP=20 backend. That is not to say that I'm totally against a subpacket, if the correct=20 charset would be known after verification / parsing it would also help. Best Regards, Andre =2D-=20 Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr=FCck | AG Osnabr=FCck, HR B = 18998 Gesch=E4ftsf=FChrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner --nextPart4746153.78YUkml5oY Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRwkxlKrbuKLRTTyRcpeOnUDLq6XAUCW5QUkQAKCRApeOnUDLq6 XG3mAQC4nQWC9tGP9dWrGszPb5QfG3qRzwfiUEYnDIGYbl6L4wD5ASmhnHhUGled jjSTJcqDjX/YsoNK4gsQfvbUpzokeA4= =bIXp -----END PGP SIGNATURE----- --nextPart4746153.78YUkml5oY-- From nobody Mon Sep 10 11:23:42 2018 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 13B3F130F40 for ; Mon, 10 Sep 2018 11:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=symantec.com header.b=cJ229oP4; dkim=pass (1024-bit key) header.d=symantec.com header.b=evtND1JW 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 ZG7QdcAJQycE for ; Mon, 10 Sep 2018 11:23:39 -0700 (PDT) Received: from asbsmtoutape02.symantec.com (asbsmtoutape02.symantec.com [155.64.138.34]) (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 566E1130F3B for ; Mon, 10 Sep 2018 11:23:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=Symantec.com; s=2; c=relaxed/simple; q=dns/txt; i=@Symantec.com; t=1536603818; x=2400517418; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=fNWQem3bipdWISpWHJdEh1HCOc4iinZCaahI0k/AnwA=; b=cJ229oP4YPCR+J45ER2h0eSDrryCpJm7qYDZxktRYaMSPrq+0M7LSCE1M2GYfafj Uq2mVZlhVGWYH00GkJSb2c9TqzQkidV93e6WXJtmmSnbf8MxmGbyu2w3KTe+TlgV 02qkeTYBhigJitbqeqslJs28LFbzm/juMXIqNYLg8w0=; Received: from asbsmtmtaapi02.symc.symantec.com (asb1-f5-symc-ext-prd-snat9.net.symantec.com [10.90.75.9]) by asbsmtoutape02.symantec.com (Symantec Messaging Gateway) with SMTP id 0A.7A.55316.AA6B69B5; Mon, 10 Sep 2018 18:23:38 +0000 (GMT) X-AuditID: 0a5af81a-9e3019e00001d814-97-5b96b6aaa363 Received: from TUSXCHMBXWPI01.SYMC.SYMANTEC.COM (asb1-f5-symc-ext-prd-snat1.net.symantec.com [10.90.75.1]) by asbsmtmtaapi02.symc.symantec.com (Symantec Messaging Gateway) with SMTP id EE.D8.63223.AA6B69B5; Mon, 10 Sep 2018 18:23:38 +0000 (GMT) Received: from TUSXCHMBXWPI02.SYMC.SYMANTEC.COM (10.44.91.34) by TUSXCHMBXWPI01.SYMC.SYMANTEC.COM (10.44.91.33) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 10 Sep 2018 11:23:36 -0700 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (10.44.128.8) by TUSXCHMBXWPI02.SYMC.SYMANTEC.COM (10.44.91.34) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Mon, 10 Sep 2018 11:23:36 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=symantec.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fNWQem3bipdWISpWHJdEh1HCOc4iinZCaahI0k/AnwA=; b=evtND1JWd4x+Iz2rL6zRmSuu9mzKMczeCWHaOMjosbibG/0KGI6wSZw9TZL9mzKTsksZIF/l3YASNwd5X5WcJn0o7/90qjM8nMkvPvBMhFgRVWwaNyZgy98Bq8t2pp9VH2L9Co2lAnmwfzjStuyyc2Gle5q3LTbmq5HDONk7jgo= Received: from BY2PR16MB0278.namprd16.prod.outlook.com (10.163.66.12) by BY2PR16MB0311.namprd16.prod.outlook.com (10.163.66.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1122.16; Mon, 10 Sep 2018 18:23:35 +0000 Received: from BY2PR16MB0278.namprd16.prod.outlook.com ([fe80::e0b7:65d8:dcad:d5d5]) by BY2PR16MB0278.namprd16.prod.outlook.com ([fe80::e0b7:65d8:dcad:d5d5%2]) with mapi id 15.20.1122.018; Mon, 10 Sep 2018 18:23:35 +0000 From: Neil Hunsperger To: Andre Heinecke , IETF OpenPGP Thread-Topic: [openpgp] A way to securely define cleartext signature charset Thread-Index: AdRJM0zEISP8RqHATWKN2qZawteo6g== Date: Mon, 10 Sep 2018 18:23:35 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Neil_Hunsperger@symantec.com; x-originating-ip: [155.64.23.33] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BY2PR16MB0311; 6:w1wkND/pZBGLqM6ALpNlE1mrEI5uPq0/HBI/2GFhGGIHgb1/GodP4ONtOezX7qcY7J0xzLXWLltzvJLW5Ot/YzkNhqZ9S0S7EjjT1bCd1zvrUPgbtg1dVzSPtpQNFEmaDmi8Z3pgHJLVt0vFskLLTmPELCA5NodrLJpUHtD/YchVPGcKUf7x53uykmdawtDNbJpPYuOpHZmlFtd0GPfiy/K1XaHRpinCvgtlm198tkdpc2+GJrKHKBpOyRFc7jipSPTTwTGiCstjQxXFAywdQ8RRVl8cggTh5yOJp+q7aMHwUBokaCAOZgIiV32NX3jZGPzsjyrRCFg715Iv8flzcbb2DQr+lVDE6UU5MnOlsNCp9nYQJTIgbUuuAcktABZtiytOluGtPo4u0QbItsdBMwqZSDvZoiSIn1c6/YzRK/5nfzkCzQbvIYnn4447V/Wln84+IZlvmSNKML8+00AqpA==; 5:Q5/RJuokskB7KgiREPFw8My3sPAwpVbX9joxiBkwrxdzmMUTphEZQPzMDbM/Fe7lUAnKivYRdwmhF/F9sk29MHx50eHKD+GjOrKhJgooDQDAy0d00Tnd9v+nTTml9DmoqM40wrAh6UOgIcFI+AvkkSOfU2lITep35jZ5wKdQduM=; 7:M5jqN8pY8/5v5FkR9CkKET7aDWdy0ecV4S3ri+vUQX2TdWgl+LIK3vMYWmbBq/UOAsgrk8Q8NIEGe3oWlEbp/fwvUDW3hJ6Fs7J1uJ/h1hwitwLIJ1o9WrhR4oY+gmwsMiMeagHQY04w9teWZnPjExns/9nMe6rBuo/IBHqys47/ZgbywmTyZBZHKBniV9TR6DOIk+HY+3RISMjlVongOdPrXjwIFPeykRNDsLQvfj+hO5rbxxl68V2MQPl7/k9d x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 098b2e2e-31e1-4b06-81a9-08d6174a8594 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:BY2PR16MB0311; x-ms-traffictypediagnostic: BY2PR16MB0311: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231311)(944501410)(52105095)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201708071742011)(7699050); SRVR:BY2PR16MB0311; BCL:0; PCL:0; RULEID:; SRVR:BY2PR16MB0311; x-forefront-prvs: 07915F544A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(39860400002)(376002)(136003)(366004)(199004)(189003)(6246003)(72206003)(2906002)(6436002)(256004)(316002)(7696005)(53936002)(99286004)(86362001)(186003)(5250100002)(486006)(45080400002)(26005)(55016002)(14444005)(14454004)(102836004)(6506007)(110136005)(229853002)(10290500003)(105586002)(3846002)(106356001)(6116002)(66066001)(476003)(9686003)(25786009)(478600001)(8676002)(68736007)(7736002)(81166006)(81156014)(305945005)(74316002)(8936002)(33656002)(97736004)(80792005)(2900100001)(5660300001)(43043002)(9010500006); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR16MB0311; H:BY2PR16MB0278.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: symantec.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: hmhzj7m/QdQW4MP+O9cTMZnQ5jCNjydD0VjfzyJjRvxT9CfgpMlwMUDnL/g0jo/mDxonBWrrsEI+9igd6AhFue6oT1Fe2bmwHcxQX9gLWpYTrSmeh9p18tfY2FqF9fWkAMzHaapqsW2WUsrf9PuByYOagghacecsKadIUF5eRw04GsC30Asvec72WIb3RE+gHb8iKvOEHmlzSu4K6SLSwLPTrN07heTVni/TwLcXcwaL5fMNaOFDI0BvKyqM7YGWQNXWuLEuH+vXECHALHfxj3GrWW7zyLoQOjTghvl+x8z1UPLs6fr3ccHDynFljPFrsri53qFT+beKW82h1XfI8PawPuOHKE6WBCnmrNIaOo8= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 098b2e2e-31e1-4b06-81a9-08d6174a8594 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Sep 2018 18:23:35.4363 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 3b217a9b-6c58-428b-b022-5ad741ce2016 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR16MB0311 X-OriginatorOrg: symantec.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAKsWRmVeSWpSXmKPExsXCFeXNqbtq27Rog5PX+Sxu3F7MZtHw7yG7 A5PHkiU/mTxOng0MYIrisklJzcksSy3St0vgypjXM5G94ABrxaVpt1kbGHewdDFyckgImEhs OP6NtYuRi0NI4COjRPPpe0wwicYJf9ghEt8YJW7ueARVdYRR4su6k1DOC0aJ+R1H2EAcFoEJ zBJtu1vZIDKTmCQWNLexgQwTEnjEKPFqIj+IzQY0eO30NrAlIgK+EtN+PGEEsYUFvCX2f17H BhH3kXi3ahbQcg4gW0+i7YkNSJhFQFVi6bs5YOW8AjES+zf0go1hFBCT+H5qDZjNLCAucevJ fKgfBCSW7DnPDGGLSrx8/I8Voj5eou31VKi4gsTh2S3sELasxKX53Ywg90sI7GOXOHXpNTSU dCU+TAVp4ACyfSV2HqyAqDnOKNF/eQLUIC2JzS8/QS3Olujd+hCq11ri5bndrBC2nMSqXpA4 SPNKZolrR2azTGA0moXkcAhbR2LB7k9sELa2xLKFr5lngT0tKHFy5hOWBYwsqxgVEouTinNL 8ktLEgtSDYz0iitzk0FEIjCVJOsl5+duYgSnkx9SOxif3PE5xCjAwajEw3tsw7RoIdbEMqDK Q4wSHMxKIry7dIBCvCmJlVWpRfnxRaU5qcWHGKU5WJTEeTd9L44WEkhPLEnNTk0tSC2CyTJx cEo1MMqbLJG6PXU6b+fs+0xuPb+6ru9mnuHTObf3Lu/SDSU3Js882xDavUVutcViCcab9ZMu 3QgpyzmXUL/mJLNB+ooM/Y2t84vrpNhi+Q4X3719OGF+/u5lc4/Vrv7WMU3dtP+D1oO/TmKF WQ6113ymbY1XfbxfaU/MHG/eMOsZfbdrmNskWbIcHiixFGckGmoxFxUnAgCFs5qNIwMAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCIsWRmVeSWpSXmKPExsXCFeXNqLtq27Rog2ndnBY3bi9ms2j495Dd gcljyZKfTB4nzwYGMEVx2aSk5mSWpRbp2yVwZczrmchecIC14tK026wNjDtYuhg5OSQETCQa J/xh72Lk4hAS+MYocXPHI1YI5wijxJd1J6GcF4wS8zuOsIE4LAITmCXadreyQWQmMUksaG5j AxkmJPCIUeLVRH4Qmw1o8NrpbUwgtoiAr8S0H08YQWxhAW+J/Z/XsUHEfSTerZoFtJwDyNaT aHtiAxJmEVCVWPpuDlg5r0CMxP4NvWBjGAXEJL6fWgNmMwuIS9x6Mp8J4gcBiSV7zjND2KIS Lx//Y4Woj5doez0VKq4gcXh2CzuELStxaX43I8j9EgL72CVOXXoNDQxdiQ9TQRo4gGxfiZ0H KyBqjjNK9F+eADVIS2Lzy09Qi7Mlerc+hOq1lnh5bjcrhC0nsaoXJA7SvJJZ4tqR2SwQQ2Uk Fq8NhIhfYpW4fuIk4wRGvVlIHoKwdSQW7P7EBmFrSyxb+Jp5FjgwBCVOznzCsoCRZRWjQmJx UnFuSW5JYmJBpoGRXnFlbjKISAQmkmS95PzcTYzgZPJbfAfjuT8+hxgFOBiVeHg1cqdFC7Em lgFVHmKU5mBREucVLoqMFhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cC48OrpO9tnnLrSwaFQ FPpTYH7aOTFz/7Mzv6vH5hxtSXOzs1sx6avPm3PB/TUNfgd2TjrRFDbjlU7QbbF+TT+m9x57 9yT+n5Jmu2qK8DG/BTLXknUz7V1WPd1heLi+4juzELv2XKtVx6cZTLJMa5Y9zFgRcqmSQVxW se6+XNU/N7ULCv+PN/5QYinOSDTUYi4qTgQAq0yDggcDAAA= X-CFilter-Loop: ASB03 Archived-At: Subject: Re: [openpgp] A way to securely define cleartext signature charset X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2018 18:23:41 -0000 > today I struggled for several hours with "charset guessing" code, that ha= ndles > cleartext signatures in outlook and I thought that maybe this situation c= ould > be improved a bit in the future? I'll add a data point. Some years back, the PGP Desktop product added an un= signed "Charset" header to its ASCII armor. The result looked like this: -----BEGIN PGP SIGNATURE----- Version: PGP SDK 4.2.1 Charset: iso-8859-1 It solved a real-world problem of intermediate software re-writing characte= r sets using lossless conversions. It didn't solve the security issue in yo= ur link to DKG's post. In practice it also didn't avoid 2-pass signature ve= rification. Cheers, -Neil From nobody Mon Sep 10 16:53:11 2018 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 8D6AA130F74 for ; Mon, 10 Sep 2018 16:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.com 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 lRQX06kW09Bd for ; Mon, 10 Sep 2018 16:53:07 -0700 (PDT) Received: from st13p27im-asmtp004.me.com (st13p27im-asmtp004.me.com [17.162.190.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8C4A130E14 for ; Mon, 10 Sep 2018 16:53:07 -0700 (PDT) Received: from process-dkim-sign-daemon.st13p27im-asmtp004.me.com by st13p27im-asmtp004.me.com (Oracle Communications Messaging Server 8.0.2.2.20180531 64bit (built May 31 2018)) id <0PEV018005W5NP00@st13p27im-asmtp004.me.com> for openpgp@ietf.org; Mon, 10 Sep 2018 23:53:07 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1536623586; bh=4+Sub64VI44cwzzBzvd/HPm6bUOCQlpoFRkZ8b7ZErE=; h=From:Message-id:Content-type:MIME-version:Subject:Date:To; b=QuhoYx7HK99+8W9E2irPC9rrCxmArew5aN3rcA+7+9QCEjmgO4P8wqdlnO6QvdGr4 qgbc1J0OOrf1MNzK6R/8q6rHD9H8TPRGiPAHhY4H/xyoovrDmJ527pRFJbZSr4cpme ogKvw23hwMSVmPKpxp/y4kuwCxB7dVIfRj98c9f3faoalXm0wI8/QC1jfPIssn8iD2 MDhZQfc0Ay/sP92l31k6GGoC4m4lzy9A1W82Qi0QTUP0kKF4UzG48X3pFYs/5zHleJ 8D23/CLtQ8ANTkQe2RA4IDcJAIAb2wU7ej544ROXqlcbqccIW1MQbHystIBsf0Grih w3FoWsG8JCP4Q== Received: from icloud.com ([127.0.0.1]) by st13p27im-asmtp004.me.com (Oracle Communications Messaging Server 8.0.2.2.20180531 64bit (built May 31 2018)) with ESMTPSA id <0PEV00CZ86CGFS20@st13p27im-asmtp004.me.com>; Mon, 10 Sep 2018 23:53:06 +0000 (GMT) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1809100236 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-09-10_11:,, signatures=0 From: Jon Callas Message-id: <8B546F88-AD17-4EBE-B8F8-F2D72D02CE8A@icloud.com> Content-type: multipart/alternative; boundary="Apple-Mail=_DAF4BDE3-1C36-4D62-9B7A-582E3E63A7D2" MIME-version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Mon, 10 Sep 2018 16:53:03 -0700 In-reply-to: Cc: Jon Callas , Andre Heinecke , IETF OpenPGP To: Neil Hunsperger References: X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [openpgp] A way to securely define cleartext signature charset X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2018 23:53:10 -0000 --Apple-Mail=_DAF4BDE3-1C36-4D62-9B7A-582E3E63A7D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Sep 10, 2018, at 11:23 AM, Neil Hunsperger = wrote: >=20 > I'll add a data point. Some years back, the PGP Desktop product added = an unsigned "Charset" header to its ASCII armor. The result looked like = this: And for what it=E2=80=99s worth, section 6.2 of RFC 4880 says: - "Charset", a description of the character set that the plaintext is in. Please note that OpenPGP defines text to be in UTF-8. An implementation will get best results by translating into and out of UTF-8. However, there are many instances where this is easier said than done. Also, there are communities of users who have no need for UTF-8 because they are all happy with a character set like ISO Latin-5 or a Japanese character set. In such instances, an implementation MAY override the UTF-8 default by using this header key. An implementation MAY implement this key and any translations it cares to; an implementation MAY ignore it and assume all text is UTF-8. All those MAYs are there because of the real world considerations. = People still use JIS all over the place, for example, and this allows = them to mark their text and have it work correctly. (That=E2=80=99s why = we put it in both the standard and software. The examples of Latin-5 and = JIS were real.) On the other hand, there was a completely reasonable = objection that there are not only silly character sets that one could = make up (nods to the computer language =E2=80=9CWhitespace=E2=80=9D), = and real-world issues of what happens when the diehard Latin-5 people = start sending messages to the diehard JIS people, and the resulting N^2 = testing matrix. Thus, this section lets an implementation throw its hands up in the air = and scream wherever and whenever it wants, while giving a decent way to = clearsign Japanese text. Jon --Apple-Mail=_DAF4BDE3-1C36-4D62-9B7A-582E3E63A7D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Sep 10, 2018, at 11:23 AM, Neil Hunsperger <Neil_Hunsperger=3D40symantec.com@dmarc.ietf.org> = wrote:

I'll add a = data point. Some years back, the PGP Desktop product added an unsigned = "Charset" header to its ASCII armor. The result looked like this:

And for what it=E2=80=99s worth, section 6.2 of RFC 4880 = says:

     - "Charset", a =
description of the character set that the plaintext
       is in.  Please note that OpenPGP defines text to be in UTF-8.  An
       implementation will get best results by translating into and out
       of UTF-8.  However, there are many instances where this is easier
       said than done.  Also, there are communities of users who have no
       need for UTF-8 because they are all happy with a character set
       like ISO Latin-5 or a Japanese character set.  In such instances,
       an implementation MAY override the UTF-8 default by using this
       header key.  An implementation MAY implement this key and any
       translations it cares to; an implementation MAY ignore it and
       assume all text is UTF-8.

All = those MAYs are there because of the real world considerations. People = still use JIS all over the place, for example, and this allows them to = mark their text and have it work correctly. (That=E2=80=99s why we put = it in both the standard and software. The examples of Latin-5 and JIS = were real.) On the other hand, there was a completely reasonable = objection that there are not only silly character sets that one could = make up (nods to the computer language =E2=80=9CWhitespace=E2=80=9D), = and real-world issues of what happens when the diehard Latin-5 people = start sending messages to the diehard JIS people, and the resulting N^2 = testing matrix.

Thus, this section lets an implementation throw its hands up = in the air and scream wherever and whenever it wants, while giving a = decent way to clearsign Japanese text.

Jon

= --Apple-Mail=_DAF4BDE3-1C36-4D62-9B7A-582E3E63A7D2-- From nobody Tue Sep 11 01:36:41 2018 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 653FF131084 for ; Tue, 11 Sep 2018 01:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] 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 VBLadqmgWLE4 for ; Tue, 11 Sep 2018 01:36:37 -0700 (PDT) Received: from kolab.intevation.de (kolab.intevation.de [212.95.107.133]) by ietfa.amsl.com (Postfix) with ESMTP id 2D55D130E60 for ; Tue, 11 Sep 2018 01:36:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by kolab.intevation.de (Postfix) with ESMTP id 776A662848 for ; Tue, 11 Sep 2018 10:36:35 +0200 (CEST) X-Virus-Scanned: by amavisd-new at intevation.de Received: from kolab.intevation.de ([127.0.0.1]) by localhost (kolab.intevation.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1uYhLQ4WXWaN for ; Tue, 11 Sep 2018 10:36:33 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by kolab.intevation.de (Postfix) with ESMTP id C82096288B for ; Tue, 11 Sep 2018 10:36:33 +0200 (CEST) Received: from esus.localnet (81-5-224-141.hdsl.highway.telekom.at [81.5.224.141]) (Authenticated sender: andre.heinecke@intevation.de) by kolab.intevation.de (Postfix) with ESMTPSA id 94DE462802; Tue, 11 Sep 2018 10:36:33 +0200 (CEST) From: Andre Heinecke To: openpgp@ietf.org Cc: Jon Callas Date: Tue, 11 Sep 2018 10:36:32 +0200 Message-ID: <4583135.Hku5QGgJE0@esus> User-Agent: KMail/5.2.3 (Linux/4.9.0-8-amd64; KDE/5.28.0; x86_64; ; ) In-Reply-To: <8B546F88-AD17-4EBE-B8F8-F2D72D02CE8A@icloud.com> References: <8B546F88-AD17-4EBE-B8F8-F2D72D02CE8A@icloud.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2253596.LtcxTvYFki"; micalg="pgp-sha256"; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] A way to securely define cleartext signature charset X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2018 08:36:40 -0000 --nextPart2253596.LtcxTvYFki Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Hi Jon, Neil, thanks for your comments! On Monday, September 10, 2018 4:53:03 PM CEST Jon Callas wrote: > > On Sep 10, 2018, at 11:23 AM, Neil Hunsperger=20 wrote: > > I'll add a data point. Some years back, the PGP Desktop product added a= n=20 unsigned "Charset" header to its ASCII armor. The result looked like this: That would also be an option. I don't prefer it because it would be unsigne= d=20 but it would already help with usability issues. > And for what it=E2=80=99s worth, section 6.2 of RFC 4880 says: >=20 > - "Charset", a description of the character set that the plaintext > is in. Please note that OpenPGP defines text to be in UTF-8. An > implementation will get best results by translating into and out > of UTF-8. However, there are many instances where this is easier > said than done. Also, there are communities of users who have no > need for UTF-8 because they are all happy with a character set > like ISO Latin-5 or a Japanese character set. In such instances, > an implementation MAY override the UTF-8 default by using this > header key. An implementation MAY implement this key and any > translations it cares to; an implementation MAY ignore it and > assume all text is UTF-8. There is indeed very little definition in this section,... > However, there are many instances where this is easier > said than done.=20 And that is the problem. E.g. a webmailer in which you paste UTF-8 Text, th= en=20 the webmailer sees that it can encode that message as latin 1 and sends it = as=20 latin 1. Now on the receiving side you have a content-type saying "latin 1"= =20 but the message was actually signed in UTF-8. And so you have to "try"=20 multiple charsets if you whish to verify the message (as it could also be=20 signed as latin1). =20 > All those MAYs are there because of the real world considerations.=20 Well, my proposed change would be optional. Without the "Charset" in the=20 message an implementation would fallback to the "do what you want" guessing= =20 game with all these MAYs :-) > People still use JIS all over the place, for example, and this allows them > to mark their text and have it work correctly. (That=E2=80=99s why we put= it in both > the standard and software. The examples of Latin-5 and JIS were real.) On= =20 > the other hand, there was a completely reasonable objection that there are > not only silly character sets that one could make up (nods to the computer > language =E2=80=9CWhitespace=E2=80=9D), and real-world issues of what hap= pens when the > diehard Latin-5 people start sending messages to the diehard JIS people, = and > the resulting N^2 testing matrix. I'm not sure if you say that we should not add standardized way to define t= he=20 charset for cleartext signatures or that we should? I don't really see the problem of either silly character sets or Latin-5 / = JIS=20 messages. As long as It can be converted to the display charset / for passa= ge=20 through the openpgp engine it should be ok. > Thus, this section lets an implementation throw its hands up in the air a= nd > scream wherever and whenever it wants, while giving a decent way to > clearsign Japanese text. Yeah, but from a usability standpoint I do not like guessign, screaming and= =20 failing if it can be avoided at all :-). Best Regards, Andre =2D-=20 Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr=C3=BCck | AG Osnabr=C3=BCck,= HR B 18998 Gesch=C3=A4ftsf=C3=BChrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver = Wagner --nextPart2253596.LtcxTvYFki Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRwkxlKrbuKLRTTyRcpeOnUDLq6XAUCW5d+kAAKCRApeOnUDLq6 XDTVAP4iLMaSgjbCluNtxRgeRfkTRHAJwoNxm1TmvGGMXjoI7wD/Uu+QsvcY0K0t 5dOWL5tWF/iQoxzyvhuvNwFERVNz2gY= =FDaz -----END PGP SIGNATURE----- --nextPart2253596.LtcxTvYFki-- From nobody Tue Sep 11 03:04:28 2018 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 A7361130934 for ; Tue, 11 Sep 2018 03:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] 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 HnyRkCAWQvD8 for ; Tue, 11 Sep 2018 03:04:23 -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 B2AD612D7EA for ; Tue, 11 Sep 2018 03:04:23 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1fzfWv-0004i9-IK for ; Tue, 11 Sep 2018 12:04:21 +0200 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1fzfMu-0006gh-El; Tue, 11 Sep 2018 11:54:00 +0200 From: Werner Koch To: Andre Heinecke Cc: openpgp@ietf.org References: <1803390.QxyNr08ExB@esus> <11022095.V4M2a8AgS6@esus> Organisation: GnuPG e.V. X-message-flag: Mails containing HTML will not be read! Please send only plain text. Mail-Followup-To: Andre Heinecke , openpgp@ietf.org Date: Tue, 11 Sep 2018 11:53:54 +0200 In-Reply-To: <11022095.V4M2a8AgS6@esus> (Andre Heinecke's message of "Sat, 08 Sep 2018 20:27:29 +0200") Message-ID: <87r2i0xsul.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=smuggle_ASPIC_Blowfish_FSF_COSCO_Firewalls_argus_Taiwan_Ft._Bragg=es"; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] A way to securely define cleartext signature charset X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2018 10:04:26 -0000 --=smuggle_ASPIC_Blowfish_FSF_COSCO_Firewalls_argus_Taiwan_Ft._Bragg=es Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 8 Sep 2018 20:27, aheinecke@intevation.de said: > Mostly because in an Application you can already use the information from= the=20 > header before you do any OpenPGP parsing / signature verification. Verification tools already need to consider an unsigned armor header to figure out the digest algorithm to use. However, this is sometimes not enough because some tools used to have peculiar interpretation of white space and line endings or the "Hash" header line was missing. Thus, for one-pass processing running a second hash context was (or well, is) useful. Adding a "Charset" header and automatically try to convert would lead to an even more complex verification step. I don't think that is justified. Better have a way to sign the character set info and present this to the user in the Good and in the Bad verification case. On a bad verification the user can then choose to convert and try a verification again. That would not be a one-pass processing anymore but for the ugly cleartext signatures this seems to be acceptable. I would thus suggest this new standard notation: ##### The 'charset' Notation =20=20 The "charset" notation is a description of the character set used to encode the signed plaintext. The default value is "UTF-8". If used, the value MUST be encoded as human readable and MUST be present in the hashed subpacket section of the signature. This notation is useful for cleartext signatures in cases where it is not possible to encode the text in UTF-8. By having the used character set a part of the signed data, attacks exploiting different representation of code points will be mitigated. Shalom-Salam, Werner =20=20 =2D-=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=smuggle_ASPIC_Blowfish_FSF_COSCO_Firewalls_argus_Taiwan_Ft._Bragg=es Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTX/8BjtAoilLlm20f/gK6dHew1jQUCW5eQsgAKCRD/gK6dHew1 jZaiAP9LbAORv8SAYFYyHZ6rEzdx5FMRJEDU6sKGAwt3Yb6LEAEAz555M6FxVWRJ YglcgeYPA2HmSNmD7gAtXkzLGTsanwo= =6eeG -----END PGP SIGNATURE----- --=smuggle_ASPIC_Blowfish_FSF_COSCO_Firewalls_argus_Taiwan_Ft._Bragg=es-- From nobody Tue Sep 11 03:14:50 2018 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 DFC18130DE0 for ; Tue, 11 Sep 2018 03:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] 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 iZjUcZsm-0SN for ; Tue, 11 Sep 2018 03:14:47 -0700 (PDT) Received: from kolab.intevation.de (kolab.intevation.de [212.95.107.133]) by ietfa.amsl.com (Postfix) with ESMTP id 1C993127332 for ; Tue, 11 Sep 2018 03:14:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by kolab.intevation.de (Postfix) with ESMTP id 4F4F6622A4 for ; Tue, 11 Sep 2018 12:14:46 +0200 (CEST) X-Virus-Scanned: by amavisd-new at intevation.de Received: from kolab.intevation.de ([127.0.0.1]) by localhost (kolab.intevation.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7gU5hPmnE06 for ; Tue, 11 Sep 2018 12:14:44 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by kolab.intevation.de (Postfix) with ESMTP id 2D8AD6256F for ; Tue, 11 Sep 2018 12:14:44 +0200 (CEST) Received: from esus.localnet (81-5-224-141.hdsl.highway.telekom.at [81.5.224.141]) (Authenticated sender: andre.heinecke@intevation.de) by kolab.intevation.de (Postfix) with ESMTPSA id 021EB622A4; Tue, 11 Sep 2018 12:14:44 +0200 (CEST) From: Andre Heinecke To: Werner Koch Cc: openpgp@ietf.org Date: Tue, 11 Sep 2018 12:14:43 +0200 Message-ID: <2069480.MVc5JfVDOz@esus> User-Agent: KMail/5.2.3 (Linux/4.9.0-8-amd64; KDE/5.28.0; x86_64; ; ) In-Reply-To: <87r2i0xsul.fsf@wheatstone.g10code.de> References: <1803390.QxyNr08ExB@esus> <11022095.V4M2a8AgS6@esus> <87r2i0xsul.fsf@wheatstone.g10code.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1736439.6m2XM5yh0A"; micalg="pgp-sha256"; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] A way to securely define cleartext signature charset X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2018 10:14:49 -0000 --nextPart1736439.6m2XM5yh0A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" On Tuesday, September 11, 2018 11:53:54 AM CEST Werner Koch wrote: > Verification tools already need to consider an unsigned armor header to > figure out the digest algorithm to use. However, this is sometimes not > enough because some tools used to have peculiar interpretation of white > space and line endings or the "Hash" header line was missing. Thus, for > one-pass processing running a second hash context was (or well, is) > useful. Adding a "Charset" header and automatically try to convert > would lead to an even more complex verification step. I don't think > that is justified. Thinking more from the "backend" standpoint and less from the Application=20 using the backend this makes sense to me. A minor issue is that my Applicat= ion=20 might temporarily show the wrong representation before the verification is = done=20 but I guess that is indeed minor. > Better have a way to sign the character set info and present this to the > user in the Good and in the Bad verification case. On a bad > verification the user can then choose to convert and try a verification > again. That would not be a one-pass processing anymore but for the ugly > cleartext signatures this seems to be acceptable. Yes, as for me the "User" would be my Application and not the person sittin= g=20 in front of the Computer I think that is acceptable as it can be handled=20 automatically. > I would thus suggest this new standard notation: >=20 > ##### The 'charset' Notation > =20 > The "charset" notation is a description of the character set used to > encode the signed plaintext. The default value is "UTF-8". If used, > the value MUST be encoded as human readable and MUST be present in the > hashed subpacket section of the signature. This notation is useful > for cleartext signatures in cases where it is not possible to encode > the text in UTF-8. By having the used character set a part of the > signed data, attacks exploiting different representation of code > points will be mitigated. I like it. "The default value is "UTF-8"" -> Do I understand this correctly that this= =20 basically means: If no charset notation is provided a cleartext signature M= UST=20 be in UTF-8? That would be great. Thanks and best regards, Andre =2D-=20 Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr=FCck | AG Osnabr=FCck, HR B = 18998 Gesch=E4ftsf=FChrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner --nextPart1736439.6m2XM5yh0A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRwkxlKrbuKLRTTyRcpeOnUDLq6XAUCW5eVkwAKCRApeOnUDLq6 XCjlAP9k2qo83+UzIIiRam+Cf93Npi5rRObDeJa5hprnW9r25AEA0Ml2ezBwED0M /tMNnciQJS9QvAWrK09WHyZm4p34IAY= =fPtf -----END PGP SIGNATURE----- --nextPart1736439.6m2XM5yh0A-- From nobody Tue Sep 11 03:50:19 2018 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 7C395130E73 for ; Tue, 11 Sep 2018 03:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=my.amazin.horse 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 3ich502POTyI for ; Tue, 11 Sep 2018 03:50:16 -0700 (PDT) Received: from mail.mugenguild.com (mugenguild.com [5.135.189.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CD0E130DC1 for ; Tue, 11 Sep 2018 03:50:16 -0700 (PDT) Received: from localhost (x590fed44.dyn.telefonica.de [89.15.237.68]) by mail.mugenguild.com (Postfix) with ESMTPSA id 289BC5FA63; Tue, 11 Sep 2018 12:50:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=my.amazin.horse; s=mail; t=1536663014; bh=cnZVpJlD2Z0mbe/ah8bNPcwxXA7HVqJwcIYL87577zw=; h=Date:From:To:Subject:Autocrypt:From; b=Wy/rjSON9pjMnbrbXRwyXvzWbJ5k33Bo/eRpaIzwylO6czcTe8Myr2U1cUBGQ/i/T nDGhAf6EsaauHd9wKIK0Z2zOQQDnEk+6ukFqtpN4I5XPjZAD6t0MPUZ5GxJT6iCBXs 1E7UR0LsBxCKJJeE+57qlrxlcBjffUOz5+/60NPM= Date: Tue, 11 Sep 2018 12:50:11 +0200 From: Vincent Breitmoser To: Andre Heinecke Cc: Werner Koch , openpgp@ietf.org Message-Id: In-Reply-To: <2069480.MVc5JfVDOz@esus> References: <2069480.MVc5JfVDOz@esus> <1803390.QxyNr08ExB@esus> <11022095.V4M2a8AgS6@esus> <87r2i0xsul.fsf@wheatstone.g10code.de> Autocrypt: addr=look@my.amazin.horse; keydata=mQINBFAB3UABEADCyB/vbIBA3m1Bwc yjTieEMLySwYgt54EQ2hglOocdtIhqC+b05t6sLSkwx2ukxrU2cegnCBkdyF/FZ/+Et638CUEBbf 4bjplwpt2IPLazQgjkwjMuhz0OcYDpMhwimTvh3mIl+0wzpOts6mEmMw0QZdl3RXvIW+NSynOn7q mz/fAv4Htt6lv2Ka0s6R2voyi+5U7CcIqizPad5qZVn2uxmovcFreTzFt6nk37ZbbTfvA3e5F0bR RQeH3viT5XxpJF4Y76v/Ua+5N3Kd18K0sX85rD1G7cmxR2CZ5gW1X24sDqdYZdDbf10N39UIwjJH PTeuVMQqry792Ap0Etyj135YFCE0loDnZYKvy2Y1i0RuEdTUIonIHrLhe2J0bXQGbQImHIyMgB9/ lva8D+yvy2gyf2vjRhmJEEco7w9FdzP7p3PhKrUiTjRsjHw8iV8LOCFx9njZOq9mism9ZZ16tZpx 9mXOf11HcH1RtVuyyQRS/4ytQPzwshXdSDDW6Btkmo9AbZQKC54/hSyzpp3Br2T2xDH7ecnonDB/ jv8rWuKXSTbX3xWAIrNBNDcTYaNe4jkms4HF7jJE19eRlqsXMMx6Fxvrh4TtKICwJYJ3AUmXrK3X Ti/mjqYfJ1fpBn54rWs8nhSR1fuZPD+aMlcP8BDUPlNKPKtj0DGSh3/VlnnwARAQABtClWaW5jZW 50IEJyZWl0bW9zZXIgPGxvb2tAbXkuYW1hemluLmhvcnNlPokCOAQTAQIAIgUCVTNZmgIbAwYLCQ gHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQe9GDIN6t+hHcVg//aeiijNqsQ3pjbFQn3VvND7hNfJ vrVcLZ+U4kOzXPF818aVdOnDyNXyE17vBDDcvaZ730sCsZIRZJ3KhUJ+nPvdttKjUIGLARmx+pA3 Jl3IIv2uLtOb3I0TMuyfIGJVGF+q10/CeDMKVjKlmyOVrR0opkel+KEoN7VLq3Hf3zPKENO1HBgp LHeP31tlb9cgs+u4o2wLrVe9myHbuFBW7EjWbSvdz2zliwbsFeFVLMNcWrKAU0GkkiH69SgnwmXU RkhGma4L27GLtkHHufsxfbcPqPtmtCttsGZU4EmrghGUqVyDOxnn8ZqybzLrRfpin+OCIX+aHJz5 r2L8qtrP0LorNMX3Gopd26vfhNvq/wq8xk++bW1R5FmkaUhx9h+DhO2ybcg7p/E8JHc8zrWv+bb3 0o9lkrOaU8GxXrgtb1cjtbb+MxFvjm0Elw7MSZDG7sF/APFU6cwuIA9Nai/OGAUCSt/W2ecS8Zox cWWbGSEiDvjtEctkpmHjfVuGoL34966Olm41VdH+NjgoSYUJKx4Mty8DRcZxdyoXll84LvDkEEYK ZqOIACsJf8CDFvUkmhXc+moCj15Yxtj3/RslRVEiOUyrpDwB72zWcZG8YnzoyGxhcRIc/gFejO/y SI8bzCpYngeuTb5NjFG+ChGiInHbQcFeHBlaHtKi2o/B5axIO5Ag0EVDvOgQEQALJby/ztliToGE u1lslvWQUQ6teKZVUQ7hy9bM4N83G0AGLatUBHtY6PkJBe4XkIw3sK7LoFCV2W4GSt4zWp9l+kG3 /J8Ow7EFjN0F7DrCg0M0lMg9dQz9jYSoBR8skaH3BRzCq9AKIVKV94poL/G65289L7zKDHoZnnyF qbBtedYZir0SZx+kiouZ1qnmxRPaYmH2fkuiuvYEAyzLDLYM8F5gQhdZM4YVtuvSICYPet0z4CDi JX/vZmDi3AzzoEVaKeAM/0H9f9Ni547J2+8dZSllgTrA+fq0aMJVScAObIxTAQtEq0DoNBzPpVrm W10b4bmgePrAvNkifqSr5StymSBgwvoeW6GrJiyN4XhoLOadZzwgjqioR1nXw5tXtrr5sYdkZ06b 1WWHkxtu1hFTdLC7RYNxY07ytLNM+C2lplCwCwlWB7RwI9BL1Dhre4kv8uaaX2Gksaq9mDf9MSDW qQ0TJ/RAiwMGmFrzBEYI1J2Oyeshi/dqW4/OiZAukOIlxOnt6u8zU2KL6Qjxqqna0oTbS4Zv3fRd YkuUCL6CDEJdkuRAiW+Gw+lKcMjXqApEqixhaDkoB/kwtu+2gIFTzAxMfwFN1YtNc0kJZWnFkGIW MrrwTcOwAFzlFz7wn/EyMFtg+ERcqMX0+olXDwM8MODI2+BzulPuEDEteCw09hABEBAAGJAh8EGA ECAAkFAlQ7zoECGwwACgkQe9GDIN6t+hFjuQ//UQyg49f8TytUYQaBb8R0UfI+KhQFs1Nsz2z8a3 0CD1MeiHHYWdAcomVvTkg4g5LbnYHVDrj/XagY3FN/AIE97usFbsTG+rsWAOLi7N2dN2ehWZ634k MvrgyC9uTiOdkw31+B8K5MpyySgD8e6SAzRfiu06/bcQOUyJifw8Hudpj9by4uyGhSH+kHu4afrp OduUighbsGFtcuRwwQ/w/oSk68XvPUgiOQWMZh/pVoXdFyFvrt/hgArCi8dfy5UPK58nl7jPnu/I uQXrJ50nNAFIIxPVeo2/B83KAnEZPU+qWZsdba0V+FIIQQVizLtQFMuJJk4/UTAOfJ2tBpQ9PADX 6/scqDE7unXNWdxcHTjK7KmWjXC8CyhGOx8V/rb7Ial4mZo4cTED6SNlO7dV1XYwnSctL2HCYNM3 RUe4eJ7JWuu7/Nbf6yip2eq7BQKZ9hAH/se/OSZNYsEkZ4pxUc8W5U3uAZImUwC6L74SM0jBZIuD mQhOYX6sZZ6urIn/MYlj4/hqSBFS4vTK7nXRLmtr7+5T5U5srVseUiYc+l9pu9/XD8zGIu+M2xEd 41NwP44GDQTQm0bFljRv5fSblwmi56YHPFQUIh2RZNX3kOJgeyQ3enw5uY+7ocKRVP38hpnffliL lJcO6TtHWnElS3pACbTQM0RHJox3zqU3q6K3c= Archived-At: Subject: Re: [openpgp] A way to securely define cleartext signature charset X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2018 10:50:18 -0000 > A minor issue is that my Application might temporarily show the wrong > representation before the verification is done but I guess that is indeed > minor. Cleartext signatures are typically short. Is there a reason for even showing the text before the signature is verified and the charset known? - V From nobody Tue Sep 11 04:01:36 2018 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 D3ADC130E7A for ; Tue, 11 Sep 2018 04:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] 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 zJea6_JSQFQM for ; Tue, 11 Sep 2018 04:01:33 -0700 (PDT) Received: from kolab.intevation.de (kolab.intevation.de [212.95.107.133]) by ietfa.amsl.com (Postfix) with ESMTP id A84F5130E73 for ; Tue, 11 Sep 2018 04:01:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by kolab.intevation.de (Postfix) with ESMTP id 07B576246B for ; Tue, 11 Sep 2018 13:01:32 +0200 (CEST) X-Virus-Scanned: by amavisd-new at intevation.de Received: from kolab.intevation.de ([127.0.0.1]) by localhost (kolab.intevation.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6QuKzpsKqg3D for ; Tue, 11 Sep 2018 13:01:31 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by kolab.intevation.de (Postfix) with ESMTP id 2E17A6265E for ; Tue, 11 Sep 2018 13:01:31 +0200 (CEST) Received: from esus.localnet (81-5-224-141.hdsl.highway.telekom.at [81.5.224.141]) (Authenticated sender: andre.heinecke@intevation.de) by kolab.intevation.de (Postfix) with ESMTPSA id 007C06246B; Tue, 11 Sep 2018 13:01:30 +0200 (CEST) From: Andre Heinecke To: openpgp@ietf.org Cc: Vincent Breitmoser , Werner Koch Date: Tue, 11 Sep 2018 13:01:30 +0200 Message-ID: <4596731.BY6HxoI61K@esus> User-Agent: KMail/5.2.3 (Linux/4.9.0-8-amd64; KDE/5.28.0; x86_64; ; ) In-Reply-To: References: <2069480.MVc5JfVDOz@esus> <87r2i0xsul.fsf@wheatstone.g10code.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1841864.LKsFlQjK8a"; micalg="pgp-sha256"; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] A way to securely define cleartext signature charset X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2018 11:01:35 -0000 --nextPart1841864.LKsFlQjK8a Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" On Tuesday, September 11, 2018 12:50:11 PM CEST Vincent Breitmoser wrote: > > A minor issue is that my Application might temporarily show the wrong > > representation before the verification is done but I guess that is inde= ed > > minor. >=20 > Cleartext signatures are typically short. Is there a reason for even show= ing=20 the > text before the signature is verified and the charset known? In GnuPG we have the option "auto-key-retrieve" which I prefer to use. That= =20 option will fetch an unknown signing key from remote sources e.g. Keyserve= r=20 or WKD, which can take a while. But as I said, this is a minor issue. Regards, Andre =2D-=20 Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr=FCck | AG Osnabr=FCck, HR B = 18998 Gesch=E4ftsf=FChrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner --nextPart1841864.LKsFlQjK8a Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRwkxlKrbuKLRTTyRcpeOnUDLq6XAUCW5egigAKCRApeOnUDLq6 XGVwAQDZQYbIukSNGx3jBbZuX+lhbNQjGIBYFYh0KsdOCZmLcgEA0dG9A1a8WgBb 4DwEg91LZUvZhx9SpZ6ZtQCPLnRCaAE= =RVHD -----END PGP SIGNATURE----- --nextPart1841864.LKsFlQjK8a-- From nobody Tue Sep 11 06:59:27 2018 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 8AFA5130DDB for ; Tue, 11 Sep 2018 06:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] 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 UBo_rpzNWbGx for ; Tue, 11 Sep 2018 06:59:23 -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 8A8F1130DC6 for ; Tue, 11 Sep 2018 06:59:23 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1fzjCL-00078D-G0 for ; Tue, 11 Sep 2018 15:59:21 +0200 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1fzj0R-0007rv-FP; Tue, 11 Sep 2018 15:47:03 +0200 From: Werner Koch To: Andre Heinecke Cc: openpgp@ietf.org References: <1803390.QxyNr08ExB@esus> <11022095.V4M2a8AgS6@esus> <87r2i0xsul.fsf@wheatstone.g10code.de> <2069480.MVc5JfVDOz@esus> Organisation: GnuPG e.V. X-message-flag: Mails containing HTML will not be read! Please send only plain text. Mail-Followup-To: Andre Heinecke , openpgp@ietf.org Date: Tue, 11 Sep 2018 15:46:47 +0200 In-Reply-To: <2069480.MVc5JfVDOz@esus> (Andre Heinecke's message of "Tue, 11 Sep 2018 12:14:43 +0200") Message-ID: <87musoxi2g.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=world_domination_quarter_SEAL_Team_6_Khaddafi_gamma_Belknap_Maple=CN"; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] A way to securely define cleartext signature charset X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2018 13:59:25 -0000 --=world_domination_quarter_SEAL_Team_6_Khaddafi_gamma_Belknap_Maple=CN Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 11 Sep 2018 12:14, aheinecke@intevation.de said: > basically means: If no charset notation is provided a cleartext signature= MUST=20 > be in UTF-8? Yes, that is due to=20 ## {3.4} Text =20=20 Unless otherwise specified, the character set for text is the UTF-8 [](#RFC3629) encoding of Unicode [](#ISO10646). this has not changed since 2440. But agreed in the beginning the world was US-centric and this fact was often overlooked. And PGP-2 had no such definition. Salam-Shalom, Werner =2D-=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=world_domination_quarter_SEAL_Team_6_Khaddafi_gamma_Belknap_Maple=CN Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTX/8BjtAoilLlm20f/gK6dHew1jQUCW5fHSAAKCRD/gK6dHew1 jXVXAP944a6FvOArL8jISZ+XQoUxY8IhaPKk2hQAqOU/bFBybQD/f+oSXsYVoVYn xq+y6w9EfnJWkF/SINxATaEMyuXEfAY= =C3FI -----END PGP SIGNATURE----- --=world_domination_quarter_SEAL_Team_6_Khaddafi_gamma_Belknap_Maple=CN-- From nobody Fri Sep 14 23:47:43 2018 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 D3005129C6B for ; Fri, 14 Sep 2018 23:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.com 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 0vVhJSA2rHuJ for ; Fri, 14 Sep 2018 23:47:39 -0700 (PDT) Received: from st13p27im-asmtp004.me.com (st13p27im-asmtp004.me.com [17.162.190.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD3A81292AD for ; Fri, 14 Sep 2018 23:47:39 -0700 (PDT) Received: from process-dkim-sign-daemon.st13p27im-asmtp004.me.com by st13p27im-asmtp004.me.com (Oracle Communications Messaging Server 8.0.2.2.20180531 64bit (built May 31 2018)) id <0PF300J003JHKZ00@st13p27im-asmtp004.me.com> for openpgp@ietf.org; Sat, 15 Sep 2018 06:47:39 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1536994059; bh=E5YcCgYURw9gsEmYIoAzfs4ZLUR/MjBAJCAY8AYMhBo=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=rTHCu1XNOYSlp9Hlf5xKzBh+6pDDnUrByx8N12gDZE7j3zV5cqmotP/oLaPb/eLkI r3dbZz/RWTBvCZ329D3mj8cev7fvZhSfW/Jn6x3o2qmvWXCuR2Dt6tFsEAjxM5kTsG 1DVNGlX2whIO3QlJV9AYBKsFpki/6fO5ldY6gUltbf9XVq5eMMz8M5jN9hS5PTaA65 d9AovFfOgaDSZ94RG+DiV8xpLeYVqm1X//tfJ8FKm6G4r/R5c4Y7OLH2lyH7nZ93jU ySt4/I1bm5AHQz4+pxZOQHXecIU/PqaqnKnwmaX9Nr3S5ZeflT0p+qYYqIZV8RVT0k xSaIE2WXWGGVA== Received: from icloud.com ([127.0.0.1]) by st13p27im-asmtp004.me.com (Oracle Communications Messaging Server 8.0.2.2.20180531 64bit (built May 31 2018)) with ESMTPSA id <0PF300S4U47BDS00@st13p27im-asmtp004.me.com>; Sat, 15 Sep 2018 06:47:38 +0000 (GMT) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1809150072 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-09-15_02:,, signatures=0 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jon Callas In-reply-to: <4583135.Hku5QGgJE0@esus> Date: Fri, 14 Sep 2018 23:47:34 -0700 Cc: Jon Callas , openpgp@ietf.org Content-transfer-encoding: quoted-printable Message-id: <3C389CCA-5C16-44AE-B2D2-13A028B2DC6A@icloud.com> References: <8B546F88-AD17-4EBE-B8F8-F2D72D02CE8A@icloud.com> <4583135.Hku5QGgJE0@esus> To: Andre Heinecke X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [openpgp] A way to securely define cleartext signature charset X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2018 06:47:42 -0000 > On Sep 11, 2018, at 1:36 AM, Andre Heinecke = wrote: >=20 > Hi Jon, Neil, >=20 > thanks for your comments! >=20 > On Monday, September 10, 2018 4:53:03 PM CEST Jon Callas wrote: >>> On Sep 10, 2018, at 11:23 AM, Neil Hunsperger=20 > wrote: >>> I'll add a data point. Some years back, the PGP Desktop product = added an=20 > unsigned "Charset" header to its ASCII armor. The result looked like = this: >=20 > That would also be an option. I don't prefer it because it would be = unsigned=20 > but it would already help with usability issues. [=E2=80=A6] >=20 > And that is the problem. E.g. a webmailer in which you paste UTF-8 = Text, then=20 > the webmailer sees that it can encode that message as latin 1 and = sends it as=20 > latin 1. Now on the receiving side you have a content-type saying = "latin 1"=20 > but the message was actually signed in UTF-8. And so you have to "try"=20= > multiple charsets if you whish to verify the message (as it could also = be=20 > signed as latin1). I think you=E2=80=99re over-thinking this, Andre. OpenPGP has many things in it from its past, and its past includes the = computing environment of 1991, namely DOS, and as a system to post = messages on BBSes. There are many things that we=E2=80=99d do = differently, if we were starting over. There are many things that are = basically layering violations, as well. For example, the compression stuff there is so that people wouldn=E2=80=99= t have to edit something up, then run Zip, and then encrypt that. = Another thing, and what is relevant here is the distinction between = =E2=80=9CText=E2=80=9D and =E2=80=9CBinary,=E2=80=9D which inherits in = some backwards way from FTP. With RFC 2440, we made a (then) bold step of effectively saying that = OpenPGP says that Text is Unicode, coded in UTF-8. By the time of the = early 2000s, just about everyone had moved to Unicode but with holdouts, = particularly in Japan, where they still liked (and like) Shift-JIS. The = amusingly named =E2=80=9CISO Latin-5=E2=80=9D is actually Cyrillic, = which is not Latin at all, but it was an eight-bit character set for = them. I=E2=80=99m sure I am oversimplifying and there are other holdouts = as well, because long tails are like that. Nonetheless, every day that = tail becomes more tail-like, because Unicode is what just about everyone = uses. > I'm not sure if you say that we should not add standardized way to = define the=20 > charset for cleartext signatures or that we should? I=E2=80=99m saying we *have* a standardized way. The charset is Unicode = encoded in UTF-8. And then we have this bag on the side so that the long-tail people can = put hints in. Back to Neil=E2=80=99s comments, we found out in the = mid-2000s that Unicode wasn=E2=80=99t getting traction in Japan and they = were doing all sorts of contortions to deal with crossed character sets. = The final compromise within the working group was to put this in so that = we could both recognize that the official stance (text is Unicode) and = let the dissenters have a better experience. It=E2=80=99s actually good that the header isn=E2=80=99t signed, because = if it were, it would end up causing more issues =E2=80=94 is it part of = the message or not, to start with. That header is metadata, and it=E2=80=99= s metadata that can=E2=80=99t be definitely stated because of layering. = It=E2=80=99s good that a component can slide that hint in without having = to be integrated with the whole of the crypto system. >=20 > I don't really see the problem of either silly character sets or = Latin-5 / JIS=20 > messages. As long as It can be converted to the display charset / for = passage=20 > through the openpgp engine it should be ok. I concur; the OpenPGP engine should not have to worry about character = sets. It=E2=80=99s got too much to worry about as it is. >=20 >> Thus, this section lets an implementation throw its hands up in the = air and >> scream wherever and whenever it wants, while giving a decent way to >> clearsign Japanese text. >=20 > Yeah, but from a usability standpoint I do not like guessign, = screaming and=20 > failing if it can be avoided at all :-). The only time you have to guess is if someone is not using Unicode. = That=E2=80=99s the whole point. Jon From nobody Fri Sep 14 23:50:09 2018 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 BA6D0129C6B for ; Fri, 14 Sep 2018 23:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.com 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 cgtGD2OPxzTi for ; Fri, 14 Sep 2018 23:50:06 -0700 (PDT) Received: from st13p27im-asmtp004.me.com (st13p27im-asmtp004.me.com [17.162.190.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8980D1292AD for ; Fri, 14 Sep 2018 23:50:06 -0700 (PDT) Received: from process-dkim-sign-daemon.st13p27im-asmtp004.me.com by st13p27im-asmtp004.me.com (Oracle Communications Messaging Server 8.0.2.2.20180531 64bit (built May 31 2018)) id <0PF300J003JHKZ00@st13p27im-asmtp004.me.com> for openpgp@ietf.org; Sat, 15 Sep 2018 06:50:05 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1536994205; bh=S21TkoVe+YcyVQLzGAC8a/pBCLvowUcww6gMszT0BUs=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=Vno969U4frOzkAlxIZr5f3eTaeamoupamH0vnMHdYTGeiKY4F9QqbuECZKw4fGWB4 lo1L0JuEcA0WwuZJ36uqTowhu5C7CUvY2Sa5RMsF0VBhaYqnbq/6Wc4aAIoPjKhL26 z941c/hb16ak1nwIUy2sazO3UqkZW8zcZoImGZJrW/cmOjJEYC3iCKEmhFTiNaUalw QObJ8HvdDx+svLAPSRaQIRgv1upVwapngqDS5VWMLZZhg5Xy5Mvg0sX/wW3nlK6/wL AJ/nDL1TyYMuTZ6jqnFoAKX6JD7KqSuqs2W1LG6iTd0kKNtvDhMFFNgz36FjOcXfyd ZO5UwyFJ0fmMA== Received: from icloud.com ([127.0.0.1]) by st13p27im-asmtp004.me.com (Oracle Communications Messaging Server 8.0.2.2.20180531 64bit (built May 31 2018)) with ESMTPSA id <0PF300EFU4BF6Z10@st13p27im-asmtp004.me.com>; Sat, 15 Sep 2018 06:50:05 +0000 (GMT) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=585 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1809150072 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-09-15_02:,, signatures=0 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jon Callas In-reply-to: Date: Fri, 14 Sep 2018 23:50:02 -0700 Cc: Jon Callas , Andre Heinecke , Werner Koch , openpgp@ietf.org Content-transfer-encoding: quoted-printable Message-id: <863ABC24-68D4-436C-8872-09E0A8E3A294@icloud.com> References: <2069480.MVc5JfVDOz@esus> <1803390.QxyNr08ExB@esus> <11022095.V4M2a8AgS6@esus> <87r2i0xsul.fsf@wheatstone.g10code.de> To: Vincent Breitmoser X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [openpgp] A way to securely define cleartext signature charset X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2018 06:50:08 -0000 > On Sep 11, 2018, at 3:50 AM, Vincent Breitmoser = wrote: >=20 > Cleartext signatures are typically short. Is there a reason for even = showing the > text before the signature is verified and the charset known? Yes. Cleartext signatures exist so that someone with no PGP can read the = message. Remember =E2=80=94 DOS and BBSes. When you=E2=80=99re planning = a meeting, you don=E2=80=99t want to isolate the people who don=E2=80=99t = have enough space on their floppy disk for PGP *and* the BBS software. Jon