Encrypting / Signing the mail subject?
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Sun Mar 22 22:47:45 CET 2015
On Sun 2015-03-22 11:56:42 -0500, Albrecht Dreß wrote:
> Am 17.03.15 00:28 schrieb(en) Daniel Kahn Gillmor:
>> Are you thinking of having this line in the embedded header or in the
>> external header?
> Only in the embedded, signed headers block.
>> As for the embedded header, i'm not sure it's useful there either.
>> it seems like a bit of a chicken-and-egg problem.
> Hmmm, yes, thinking again about it, you're right. The only use of
> that header would be informing the recipient of a message about the
> purpose of this part if the MUA does not perform any further action
> with it (see the attached screen shot as example).
Hm, if the goal is human-friendliness, then we probably want to think
about how to be even friendlier -- english text plus a URL to an
en_US-only webpage isn't very nice to the majority of the world either
>> i think the list of encrypted headers might arguably be *all* of the
>> headers except for some dummy block that is generated per-message.
> What do you mean with "some dummy block"?
the "dummy block" is the headers that get wrapped around the outside of
Alexey Melnikov just pointed me to this draft:
which has a similar mechanism (and is designed for S/MIME), and it
refers to the same idea as a "stub value"
> BTW, the Message-Id header may also leak information if uses the
> recommended form of RFC 5322, sect 3.6.4 (domain or FQDN as right-hand
> side). The 'dot-atom-text - "@" - dot-atom-text' format with random
> data on both sides (which is also explicitly allowed) should be
> preferred IMHO, as long as it is guaranteed to be unique.
>>> I think this should read: "if the text/rfc822-headers part is
>>> * the first part of a multipart/mixed, which in turn is the first part of the top-level multipart/signed or application/pkcs7-mime, or
>>> * the first part of the top-level decrypted multipart/mixed for unsigned, but encrypted messages."
>> That seems more narrowly scoped, which is probably a good thing, but
>> it might be more brittle too; are there specific cases that you're
>> trying to carve out from my broader suggestion?
> I think your definition would try to match the text/rfc822-headers
> part to the message headers in the following weird case:
> +- multipart/mixed <-- message #1 does *not* contain protected headers
> | +- text/pain
> | +- message/rfc822 <-- forwarded message #2 *with* protected headers
> | +- multipart/signed
> | +- multipart/mixed
> | | +- text/rfc822-headers <-- protected headers of forwarded message #2
> | | +- text/plain
> | +- application/pgp-signature
> +- application/pgp-signature
> Here, text/rfc822-headers *is* the first non-multipart part within a
> multipart/signed, but it doesn't belong to the (top-level) message #1,
> so it's wrong to compare them. I think, my definition would catch
> this case.
You're right. I think this distinction is useful.
PS i love the content type "text/pain" -- can we register that one officially,
Melnikov's draft proposes a content-type parameter "forwarded" to be
used on the message/rfc822 element, to distinguish these cases. I
haven't thought through the consequences of the way this his draft sets
it up, though -- it seems possible to misinterpret the lack of a header
from a non-compatible sender forwarding a message.
More information about the Gnupg-devel