[openpgp] A way to securely define cleartext signature charset
Andre Heinecke <aheinecke@intevation.de> Fri, 07 September 2018 13:52 UTC
Return-Path: <aheinecke@intevation.de>
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 <openpgp@ietfa.amsl.com>; 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 <openpgp@ietfa.amsl.com>; 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 <openpgp@ietf.org>; 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 <openpgp@ietf.org>; 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 <openpgp@ietf.org>; 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 <openpgp@ietf.org>; 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 <openpgp@ietf.org>; Fri, 7 Sep 2018 15:52:44 +0200 (CEST)
From: Andre Heinecke <aheinecke@intevation.de>
To: IETF OpenPGP <openpgp@ietf.org>
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: <https://mailarchive.ietf.org/arch/msg/openpgp/QVYXtB2XN82Y001qW4qL-1zzPzY>
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." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Sep 2018 13:52:51 -0000
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: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Charset: UTF-8 This is än example mässäge. -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQRwkxlKrbuKLRTTyRcpeOnUDLq6XAUCW5J/hwAKCRApeOnUDLq6 XLEJAP45MRTaU61PFP8RDaV6cvyzFqQUmXy6lvQIf2TcomOfcwEAt+oa3hUzaAGT KEEKB1375wj2nf38Tg+FjgWKsHkKZAw= =R36C -----END PGP SIGNATURE----- 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/ -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
- [openpgp] A way to securely define cleartext sign… Andre Heinecke
- Re: [openpgp] A way to securely define cleartext … Peter Pentchev
- Re: [openpgp] A way to securely define cleartext … Marcus Brinkmann
- Re: [openpgp] A way to securely define cleartext … Andre Heinecke
- Re: [openpgp] A way to securely define cleartext … Andre Heinecke
- Re: [openpgp] A way to securely define cleartext … Neil Hunsperger
- Re: [openpgp] A way to securely define cleartext … Jon Callas
- Re: [openpgp] A way to securely define cleartext … Andre Heinecke
- Re: [openpgp] A way to securely define cleartext … Werner Koch
- Re: [openpgp] A way to securely define cleartext … Andre Heinecke
- Re: [openpgp] A way to securely define cleartext … Vincent Breitmoser
- Re: [openpgp] A way to securely define cleartext … Andre Heinecke
- Re: [openpgp] A way to securely define cleartext … Werner Koch
- Re: [openpgp] A way to securely define cleartext … Jon Callas
- Re: [openpgp] A way to securely define cleartext … Jon Callas