Encrypting / Signing the mail subject?

Hanno Böck hanno at hboeck.de
Fri Jan 16 13:43:24 CET 2015


Hi,

I wanted to share some thoghts about a potential change to the PGP mail
format I had. I'm not sure if this is the right place to discuss this,
but afaik there is currently no active openpgp standards list at IETF
and gnupg is likely the only implementation in widespread use. I recall
that I have read something alike already somewhere sometime, however I
don't exactly remember in what context.

One of the things I find unfortunate about OpenPGP encryption is that
the subject of a mail is not encrypted and signed. This is imho very
bad from a usability point of view and also not really neccessary,
because there are ways this could work without changing too much about
the way pgp mails work.

What I have in mind is something like this: Whenever a PGP mail app
creates a mail it replaces the subject with a defined keyword. This
could be something trivial like "__ENCRYPTED_SUBJECT__". It then places
a Subject line inside the encrypted mail body. This is followed by two
newlines and then the real encrypted body of the mail follows.

A mail client supporting this format would then replace the
__ENCRYPTED_SUBJECT__ in the UI with the Subject from the body and it
would hide the Subject: ... and the two newlines from the UI display of
the mail body.

Doing this would provide some kind of backwards compatibility to old
clients. A client not supporting this mechanism would still be able to
read a mail. It would also show the subject as part of the encrypted
mail body. There would even be some compatibility in the other way. A
user aware of how this works could manually set the subject keyword and
the Subject in the mail body in a mail client not supporting this
mechanism.


There are some things that'd need consideration if such a mechanism
would be created:
* This would move the subject to the encrypted part of a message. A
mail client may decide that it needs some kind of caching of mail
subjects available, because it is not feasible to decrypt them on
demand, especially on large mailboxes. Therefore a client might move
data from the encrypted context to a nonencrypted storage. This is a
trade-off, but imho it is still a lot better than not encrypting the
subject at all.
* One would have to make a clear decision how the Subject is encoded to
avoid confusion and incompatibilities. Currently a subject with special
chars has some kind of utf8-prefix-encoding. A mail body has its own
encoding. One would have to decide if the subject encoding is just the
body encoding or if the same format as in the header is used. Technical
detail, but should be done right and should be unambigious.

So far my rough proposal.
What do people think about it? Is this the right place to discuss it?
If you like it do you think it should become a standard/RFC? Anyone
interested in impementing it in whatever mail client implementation?

(and to proove my point why this is desirable just see this mail by dkb
where he explains why it's bad to rely on subject information in the
mail content: http://seclists.org/oss-sec/2015/q1/137 )

cu, Hanno

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: hanno at hboeck.de
GPG: BBB51E42
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20150116/0b890675/attachment.sig>


More information about the Gnupg-devel mailing list