[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