Memory Hole discussion / OpenPGP e-mail header protection
patrick at enigmail.net
Mon Jun 29 20:33:17 CEST 2015
On 28.06.15 19:31, Bjarni Runar Einarsson wrote:
> Patrick Brunschwig <patrick at enigmail.net> wrote:
>>> This allows for versioning and also binds the part to the message it
>>> applies to, which was one of the questions raised in April. I suspect
>>> we'll want to rename from "memoryhole" to something less cool but more
>>> descriptive sooner rather than later; "pgp-mime-headers" comes to mind?
>> The headers we protect are not PGP/MIME headers. I think something like
>> "protected-headers" or "secure-headers" would be better.
> I'm assuming this will be an extension to whatever RFCs discuss
> PGP/MIME, which is why I used those words. In fact, if/when there is an
> RFC for this, I'd vote for calling them rfc9999-headers. :-)
That's the worst of all options. RFCs are changed over time leading to
new RFC numbers. Eg. RFC 2015 has been superseeded by RFC 3156.
> 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.
> Showing the headers to the user at all is a backwards-compatibility hack
> which should only be necessary for a relatively brief window in time, as
> all the PGP plugins and mailers implement the new standard. Considering
> how many folks we had in the room in April, I don't think I'm being
> overly optimistic... :-)
True, but my point here is that it's not guaranteed that all clients
will send charset="us-ascii". Therefore you will anyway need to apply
the charset decoding _before_ you can apply the mail header decoding.
That is, the mail header decoding is in any case an additional step.
More information about the Gnupg-devel