Jonathan Joseph Chiarella

If I understand what I'm reading about Pretty Easy Privacy from their proposed drafts, it seems incompatible with autocrypt. The methods of key transfer are different (metadata for autocrypt, mime attachment for PEP). Additionally, header protection seems fundamentally flawed. PEP only protects the "Subject: " header and only if it is encrypted. On the other hand, autocrypt/memory hole protects the "Subject: " and the "To: " and the "From: " fields. Autocrypt/memory hole protects these fields as...

The "bad" part is autogenerating keys. New users who have Thunderbird on a PC and a laptop will end up creating separate keys on each and may not be aware they have a different key on each device if the keys are both identified as "kelly@g.com."

Thank you for your reply and pointing me to that PEP is following RFC 3156. I kept coming across examples of encrypted messages of PEP 1 and decrypted messages showing nested structure of PEP 2 and was operating on guesswork. I'm fairly sure the Autocrypt people took over Memory Hole, right? The incoproration of it or protected headers is on the horizon. I can understand PEP doing basic defaults for all and whatnot. I may not like some of the choices, but as can be seen with WireGuard simplicity...

I don't want to disparage the work gone into Enigmail supporting both, which is a good decision. I am just baffled as to why PEP should even exist at this point and I disagree strongly with defaulting to PEP. Having support for PEP reading, like supporting reading DSA1024 mail even though DSA1024 keys are discouraged, is great, of course.

If I understand what I'm reading about Pretty Easy Privacy from their proposed drafts, it seems incompatible with autocrypt. The methods of key transfer are different (metadata for autocrypt, mime attachment for PEP). Additionally, header protection seems fundamentally flawed. PEP only protects the "Subject: " header and only if it is encrypted. On the other hand, autocrypt/memory hole protects the "Subject: " and the "To: " and the "From: " fields. Autocrypt/memory hole protects these fields as...

Wow.... Maybe PGP/MIME is just never going to work in certain contexts. If mailman is removing MIME layers and contents, it or any other service could strip out signatures, section breaks or attachments. PGP/Inline ideally has format=flowed off (as well as line wrap disabled), because even the Enigmail and PGP clean up of > and trailing whitespace isn't fool-proof. which is good because mail programs sometimes mess up contents. However, I did notice that very long lines (~1000+) get turned to Base64,...

Actually, I just thought of a solution. Why not rewrite the Subject Title entirely in Unicode? Make the whole thing =?UTF-8?B?........?= or =?UTF-8?Q?........?= and use Base64 or Quoted-Printable always. (Right now, the subject line is 7-bit ASCII, if a non-ASCII character is included, it is Quoted Printable or Base64, but using these seems to cause no issues. I tried writing a Subject line manually this way on a normal e-mail and everyone plays nicely with it, even webmail interfaces.

I think it may be a good idea to keep the protected headers but to not display a warning for the headers being changed. Unlike a changed body, changed headers can be 100% restored by the memory hole (redundancy). Just fix the headers displayed by Thunderbird without telling the user that some list-serve reformatted ed the subject line or reference number. But keep a notification for a bad signature on the body content. The original body cannot be regained and you need to know if it has been altered,...