Re: [openpgp] Character encodings

Werner Koch <wk@gnupg.org> Wed, 18 March 2015 09:21 UTC

Return-Path: <wk@gnupg.org>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEBCF1A8788 for <openpgp@ietfa.amsl.com>; Wed, 18 Mar 2015 02:21:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
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 R4pZwhV4Tv_A for <openpgp@ietfa.amsl.com>; Wed, 18 Mar 2015 02:21:23 -0700 (PDT)
Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51BC81A1A4F for <openpgp@ietf.org>; Wed, 18 Mar 2015 02:21:22 -0700 (PDT)
Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1YYAAC-0006pq-RT for <openpgp@ietf.org>; Wed, 18 Mar 2015 10:21:20 +0100
Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YYA4i-0005DB-JF; Wed, 18 Mar 2015 10:15:40 +0100
From: Werner Koch <wk@gnupg.org>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
References: <9A043F3CF02CD34C8E74AC1594475C73AAFB4B37@uxcn10-5.UoA.auckland.ac.nz>
Organisation: g10 Code GmbH
X-message-flag: Mails containing HTML will not be read! Please send only plain text.
OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com
Date: Wed, 18 Mar 2015 10:15:40 +0100
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAFB4B37@uxcn10-5.UoA.auckland.ac.nz> (Peter Gutmann's message of "Wed, 18 Mar 2015 03:48:11 +0000")
Message-ID: <87619y1xab.fsf@vigenere.g10code.de>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Archived-At: <http://mailarchive.ietf.org/arch/msg/openpgp/bL1Pk8DT7tZWhJNdoRsh7B2dEPM>
Cc: "openpgp@ietf.org" <openpgp@ietf.org>
Subject: Re: [openpgp] Character encodings
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Wed, 18 Mar 2015 09:21:29 -0000

On Wed, 18 Mar 2015 04:48, pgut001@cs.auckland.ac.nz said:

>>> Just get rid of the notion of text. Make it be all binary. Push the
>>> problem up a layer in the software stack -- they have to deal with it
>>> anyway, and all OpenPGP can do is make it worse.
>>
>>+1
>
> +2.  The rest of the world has made do with the existing infrastructure for

+3.  The text mode and the different interpretation on how to handle
line endings has likely been the most troublesome experience for any
implementation.  And it still does not work universally (the last LF
problem).

The drawback will be the loss of the easy to c+p clearsign method.  It
might be replaced by something MIMEish to still allow for c+p.

> (If all else fails, make the contents of the PGP message a MIME body like
> S/MIME does, so the processing-flow is "MIME message" (S/MIME data) -> filter
> implementing the crypto (in decoded, binary form) -> "MIME message"

i.e. PGP/MIME without the requirement of using an armored message.
Should be easy to implement in any MUA.


Shalom-Salam,

   Werner

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