Subject: Re: [openpgp] Character encodings

From: Peter Gutmann <[email-masked]>
Date: Wed, 18 Mar 2015 03:48:11 +0000

Phillip Hallam-Baker <[email-masked]> writes:
>On Tue, Mar 17, 2015 at 3:44 PM, Jon Callas <[email-masked]> wrote:
>> One of the things that OpenPGP doesn't do very well that needs to be fixed
>> is layering.
>>[...]
>> 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
getting data from A to B, one way or another, without civilisation collapsing.
PGP isn't a universal character-format translator, it's an encryption app, and
should restrict itself to that.  Leave the character-set issues to other
layers where they belong.

(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"
(plaintext) back out to the mail app).

Peter.

---

From: Werner Koch <[email-masked]>
Date: Wed, 18 Mar 2015 10:15:40 +0100

> +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.

> 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.

---

From: Nicholas Cole <[email-masked]>
Date: Wed, 18 Mar 2015 09:42:09 +0000

> Should be easy to implement in any MUA.

Wouldn't anything that can be cut and pasted essentially run in to
this problem? I do think there is still utility in having something
that is a "clearsign" (that is, human-readable even without OpenPGP
software) that can be easily cut and pasted.

---

From: Werner Koch <[email-masked]>
Date: Wed, 18 Mar 2015 11:37:32 +0100

> this problem? I do think there is still utility in having something

Yeah, but we would delegate that to the MIME department and thus
simplify OpenPGP itself.

Shalom-Salam,

   Werner

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 18 Mar 2015 09:08:26 -0400

> (plaintext) back out to the mail app).

This makes it a lot easier for folk who have an S/MIME implementation to
add OpenPGP support. It is also the approach that has been debugged and is
known to work with legacy mail infrastructure.

One of the main challenges with end-to-end mail is Webmail which is now
used by most mail users. It is possible to get end-to-end to work with
webmail on the receiver side but it requires a mechanism that allows the
server to say 'here is an encrypted blob in format X, decrypt it with the
key you hold locally and present it to the user'. On the sender side you
need an editing widget that can be called out that will deliver the content
to be encrypted.

That is going to be easiest to get from the browser community if there is
least variation between the E2E email formats.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 18 Mar 2015 18:13:20 -0400

> least variation between the E2E email formats.

Please take a look at the "end-to-end" website API:

 https://github.com/google/end-to-end/wiki/Website-API

I don't think it covers all the cases you describe, but it's nicely
concise at the moment, and maybe just needs a few tweaks to be able to
reach some of the mechanisms you're looking for.

      --dkg