Hi Bjarni, On Monday 24 November 2014 at 10:25:43, Bjarni Runar Einarsson wrote: > Bernhard Reiter <bernh...@intevation.de> wrote: > And thank you for the friendly reply. :-)
you are welcome! I know that some people sound a little but grumpy, but this mostly is the case, because they feel like they are reiterating well known arguments. This is partly true. Still I believe that we all feel some pressure to make the situation better for users. So we may need to rethink the solutions radically again, to see if we come to the same answer. > > I am on the PGP/MIME side of things, I recommend it as default for > > sending out emails. See also http://wiki.gnupg.org/SignatureHandling . > > > > a) for encrypted emails, there is no drawback. Every email client just > > have to be able to deal with message/rfc822 mime-parts anyway. > > I actually disagree, the drawbacks are significant if you broaden the > scope to include users of mail clients that do not have native support - > which once you step out of the Free Software bubble, is most mail > clients. You are saying that "most mail" clients cannot handle PGP/MIME encrypted email. And you say that is especially true for web based email clients. My argument starts at: almost all MUAs (mail user clients) can deal with MIME. So they must have a working MIME parser. For them to implement PGP/MIME for decryption is very easy: Just decrypt the contents and put it through the parser they already have. If someone aims for implementing this, it can be done easily. > As discussed in my post, if you have a PGP key but are unable to use a > PGP/MIME aware mail client for whatever reason (work supplied laptop, no > Internet outside of Internet cafés etc.), then you will not easily be > able to receive and decrypt PGP/MIME attachments, In this case of course they might also lack the standard tools to unzip the archive in your first ad-hoc strategy. So it will be better to fall back on an attachment (that includes an archive file) that people can decrypt. Oh, what about the idea to just ship a MIME parser with GnuPG. >;) If more people implement the good standard PGP/MIME, more clients will implement it as well. So I see that sending PGP/MIME as default is good, with an option that the user can fall back to a zipped and encrypted (gpg-zip/gpg-tar compatible format) attachment, > It is tempting to blame the Python libraries, but the fact > is that they do generate valid MIME - after swearing at Python for > months, it dawned on me that it's probably the PGP/MIME standard that is > just being too picky. The email standard library assumed that whitespace and header lines are insignificant (last time I've looked, I think I even filed an issue with mailman and with python, but it was a long while ago). So they completely disassemble them to put the together again when they are needed. In this process they strip whitespaces, headerlines and reformat linebreaks. So there is a designed loss of information in the library. To me that is a design issue of the library. And I believe most other MIME libraries will not share it. From the security point of view I think it is good that PGP/MIME enforces that mime(sub)parts will not be modified, because if you allow changes there, which are to be assumed identical, you may introduce an attack surface because some clients may display the contents slight differently. A clever attacker may exploit this to play tricks on the user. > This is part of what I meant by tightly coupled in a previous e-mail - > unless MIME libraries and interfaces are explicitly written with > PGP/MIME in mind, and carefully tested, they easily end up being > incompatible. There is one criteria added to the design of MIME libraries: If I save a mime object -- let us say an message/rfc822 -- I can get it out the same way I have put it in. I'd say that this would be good design anyway. Again, the problem is only really there for signatures verification or email forwarding or so. For encryption, you are writing your own mime-parts so it is easy to not create strange headers or double whitespaces in them. For decryption you just decrypt the blob and then have a regular MIME structure. > MIME is a forgiving standard, PGP/MIME is emphatically > not. This causes headaches for people trying to implement PGP/MIME and > any source of friction like this reduces tool support and uptake. There are some rules about whitespace to not have it getting in the way, but in general conceptually I see no other way, if you want to make sure that an email has not been tampered with. > All the other issues aside, I don't think anyone will > seriously argue that an e-mail encryption standard which transmits the > subject line in the clear is a "good standard". If you want some indication about what the communication is about before opening it, the indication has to be on the "envelope" and thus cannot be encrypted. Once opened, there can be a different contents. I can think of coming up with something where there is a second message/rfc822 within the message and the subject: line in there should be displayed instead of the envelope subject by email clients that have already done the complete decryption (though then you have the interface problem where to display the envelope subject). In total I would say that having an envelope subject is good anyway and that most email clients would continue to display it, because it could contain important information still. > So really, I guess I'm asking this community for feedback on two things: > > 1) Are these problems as common as my experiences imply, or am I just > really unlucky? I'd say you are slightly unlucky with pythons "email" library. (It is really hard to say from the little I know.) > 2) Is there any interest in trying to improve the standards? There is always (some) interest, but it is hard work. Some of your assumptions do not seem to be shared in full by others. Best Regards, Bernhard -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabrück, Germany; Amtsgericht Osnabrück, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
