[openpgp] Encrypting / Signing the mail subject?

[Albrecht Dreß]

A non-text attachment was scrubbed...
Name: not available
Type: text/rfc822-headers
Size: 522 bytes
Desc: not available
URL: </pipermail/attachments/20150328/ab76b1d5/attachment.bin>
-------------- next part --------------
Hi David:

Sorry for replying so late, I've been packed with my € work this week... :-/

Am 22.03.15 22:47 schrieb(en) Daniel Kahn Gillmor:
> 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

Yes, that's of course correct!

Werner already proposed to refer to a FAQ web page (which might offer a language selection), which is an excellent idea IMHO.  My extra header field was just a proposition of something which /might/ be helpful for confused users of old MUA's which don't implement the new scheme...

And, yes, I missed RFC 6648 which deprecates X-something headers - maybe a "Comments:" header might be used instead of it?

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

Ah!  That's interesting, I didn't know about the header protection mechanism of RFC 5751, sect. 3.1.  Using a message/rfc822 instead of the extra text/rfc822-headers part is also an interesting idea.  However, I think your proposal advantageous as the *only* use for the latter up to now seems to be the optional third part of a RFC 3462 multipart/report, whereas message/rfc822 is widely used afaict.  Thus I believe it's easier to detect the "protected" part with your proposal.

OTOH, it might be better to use the same scheme for s/mime *and* for pgp/mime as to avoid different implementations for the same goal in MUA's.  Hmmm....

> PS i love the content type "text/pain" -- can we register that one officially, please? ;)

Ouch.  Might be a good one for spam (although it's mostly text/paintml these days... ;-)

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

To be honest, I am not sure if this is a good idea.  As you already pointed out, older MUA's simply don't know about and thus omit it, which leads to perfect confusion.

And I think it's not necessary if RFC 5751 would simply define that the "inner" protected message container *must* have the same Message-ID as the "outer" one.  If anyone is concerned that this violates the requirement of uniqueness (RFC 5322, sect. 3.6.4), the inner container could have instead of the "Message-ID" (which is *not* required!) something like a "Protected-Message-ID" with the same value.  If someone tampered with the "outer" message-id, the receiving MUA could still detect this case by the presence of the "Protected-Message-ID".  This approach would *not* break compatibility with existing implementations.

Best,
Albrecht.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
URL: </pipermail/attachments/20150328/ab76b1d5/attachment.sig>