Memory Hole discussion / OpenPGP e-mail header protection

[Alexander Strobel]

>> Patrick wrote on another thread:
>>> >> We should agree on certain specifics like how to display non-ASCII
>>> >> characters in the memory hole headers. I would vote against using RFC
>>> >> 2047, section 2 (e.g. =?UTF-8?blah?=), such that users can read the
>>> >> headers easily if their mailers would not yet understand memory hole.
>> >
>> > I think I disagree. Although I applaud the sentiment (it's awesome that
>> > we're considering usability here), my gut feeling is the headers should
>> > be exactly like they are in the public header section. This will make
>> > both the spec and the code to implement it much simpler, lowering the
>> > bar to getting everyone to adopt this.
> I agree with Bjarni here -- i don't want any different parsers to have
> to apply to this stuff, and demanding that senders re-encode these
> embedded headers seems like trouble to me.
> 
> fwiw, i think thunderbird already displays the headers correctly if
> they're packed with RFC 2047 encodings.
I am weakly for the variation to use RFC 2047 within the
protected-headers. Most MUA are capable of en/decoding these strings by
default, so transferring them from/to the protected headers can easily
be done and they will be displayed correctly.

We have to implement some kind of conversion anyhow, so we should do
this only at the moment we have to display the protected-headers side by
side to the email.

Bjarni Runar Einarsson wrote:
> The headers we protect are not PGP/MIME headers. I think something like
> "protected-headers" or "secure-headers" would be better.
I vote for the term "protected-headers".

@All: New fields to consider
Please correct me if I understood it wrong: In thes slides[1] DKG wrote,
there is the minimum set of fields to put into the "protected-headers".
Did anyone think about MUA specific header fields at this moment? How
should the new standard handle them?
In my opinion we should use the fields mentioned in your slides as
minimum everyone has to implement.
I am unsure about how to handle MUA specific fields which aren't
directly shown to the user. We should allow these fields in the
"protected-headers" and the analyzing software has to show/ignore these
(irrelevant) fields.

The "Thread-Index" in Microsoft Outlook is one of these fields for
example. As this field is used by Outlook for building/displaying a
conversation tree it is neccessary to "protect"  (sign) this field.

[1] https://www.ietf.org/proceedings/92/slides/slides-92-appsawg-0.pdf


Regards
 Alex Strobel
 (www.gpg4o.com)