Subject: [openpgp] MIME signature impact

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 7 Apr 2015 09:02:29 -0400

If we are doing an overhaul of PGP, one of the things that needs
fixing is a way to send signed messages that does not get in the way.

http://www.explainxkcd.com/wiki/index.php/1181:_PGP

'If this is there, its probably fine'.

Problem with the ASCII approach is that most of the important stuff in
mail is in the attachments.

When PGP was invented, mail had huge amounts of lossage that would
break things for no reason. That is no longer the case. Most mail
transport is 8-bit clean.

A way to use a PGP key for DKIM would be nice. And PGP should make use
of the same code paths in MIME that mean that S/MIME headers don't get
in the way.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 07 Apr 2015 13:35:24 -0400

> fixing is a way to send signed messages that does not get in the way.

I think you're saying we need to figure out how to make cleartext
signatures that can live somewhere that non-compatible mail user agents
won't show them to the (presumably confused) user.

(this is not at all about encrypted+signed messages, right?  I'll leave
those for a separate discussion)

[ i also think this might not be in-scope for the revised OpenPGP
  working group if we're just going to work on 4880bis -- it could be
  relevant for CMS messages as well, and maybe we should find some other
  place to have this discussion.  that said, more clarifications below ]

I agree with you that securing only the text part (and not even the
character encoding) of an e-mail message is insufficient today.

It also sounds to me like you think that PGP/MIME clearsigned messages
do "get in the way".  In particular, confused MUAs will present them as
attachments that confused users then try to download and "open", and
they "don't work".

Is that right?

Placing the signature in the message header is problematic when any
intermediary modifies the content of a message.  RFC 2015 makes it quite
clear that multipart/signed message parts should be treated as bytewise
opaque -- mail transfer agents should not modify them.  Moving the
signature to the header and leaving the rest of the message undecorated
seems likely to encourage in MTAs the temptation to fiddle with the
content.  The more that message signatures fail due to MTA fiddling, the
more users will become careless about bad-signature alerts, so i think
that's a pretty risky outcome.

Do you see some way that we can effectively signal the need for message
(or message-part) opacity to MTAs while not causing UI/UX confusion for
users trapped on ignorant MUAs?

        --dkg

---

From: Neil Hunsperger <[email-masked]>
Date: Tue, 7 Apr 2015 10:38:38 -0700

> From: openpgp [mailto:[email-masked]] On Behalf Of Phillip
> Hallam-Baker
> 

One solution is PGP Partitioned format, which supports in-line signatures for ASCII bodies and detached signatures for other email content:
http://www.ietf.org/mail-archive/web/openpgp/current/msg01811.html

> of the same code paths in MIME that mean that S/MIME headers don't get

There is a standard for PGP/MIME clear-signing content and the result looks a lot like S/MIME. Major S/MIME enabled mail clients (e.g. Microsoft Outlook and Mozilla Thunderbird) render it nicely when PGP/MIME-aware software is absent so I would consider that staying out of the way. See:
https://tools.ietf.org/rfc/rfc3156.txt

Using the above as a starting point, what aspect of a MIME signature's impact is left to solve?

Cheers,
-Neil

---

From: Werner Koch <[email-masked]>
Date: Wed, 08 Apr 2015 14:09:16 +0200

On Tue,  7 Apr 2015 19:38, [email-masked] said:

> One solution is PGP Partitioned format, which supports in-line
> signatures for ASCII bodies and detached signatures for other email

That was a kludge to support Outlook.  With Outlook < 2010 it was not
possible to send/receive arbitrary MIME mails because Outlook's crypto
layer processed all multipart/{encrypted,signed} mail before a plugin
could get it hands on it.  Well, there is a hack to work around that
which we used in GpgOL but it is using non-documented behaviour.  With
Outlook 2010 a new API exists to get the raw unprocessed mail before the
crypto layer kicks in and thus it very likely that one can implement
PGP/MIME without resorting to the above hack.

IIRC, the Partitioned format has no means to guarantee the integrity of
the entire message and thus you can replace attachments.

> Using the above as a starting point, what aspect of a MIME signature's

The micalg parameter should be removed or made optional.  The micalg
needs to be emitted before the signed data and the signature.  It is
useless for OpenPGP and a major hassle for any one-pass creation of
signatures because only the signing tool can determine the used hash
algorithm from the set of signing keys.  This should not be
controversial because may MUAs use a fixed string anyway.

Salam-Shalom,

   Werner

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

---

From: Neil Hunsperger <[email-masked]>
Date: Wed, 8 Apr 2015 15:03:25 -0700

> From: Werner Koch [mailto:[email-masked]]
> 

> the entire message and thus you can replace attachments.

To clarify, one can remove attachments, re-arrange them, or change any MIME property except for the file name. Replacing attachments would require a signature of the new file made by the same key at about the same time.

Up until the recent spate of new UIs implementing OpenPGP I would have expected the discussion of encrypted email formats to die out, with the comparatively simple PGP/MIME format (or perhaps a variant with secure subject lines) becoming ubiquitous. Now implementers seem to be asking for something that simultaneously meets the needs of existing back-end message decomposition and existing front-end usability. The OpenPGP v4 format seems to provide enough flexibility to solve these use cases so I'd consider tackling OpenPGP v5 and email as separate tasks with the advantage of having separate timelines.

> controversial because may MUAs use a fixed string anyway.

+1. PGP Desktop actually used a fixed string until ~5 years ago when Enigmail reported it was causing signature verification failures.

-Neil