Encrypting / Signing the mail subject?

[Daniel Kahn Gillmor]

Hi Albrecht--

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
:P
>> 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
the message.

Alexey Melnikov just pointed me to this draft:

  https://tools.ietf.org/html/draft-melnikov-smime-header-signing-00

which has a similar mechanism (and is designed for S/MIME), and it
refers to the same idea as a "stub value"

  https://tools.ietf.org/html/draft-melnikov-smime-header-signing-00#section-3

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

good point!

>>> 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/signed
>   +- 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,
please? ;)

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.

        --dkg