-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 on Wed, Sep 26, 2001 at 01:15:54PM -0700, Meyer Wolfsheim (wolf@priori.net) wrote:
[My apologies to the list for continuing this thread. I should know better.]
On Wed, 26 Sep 2001, Karsten M. Self wrote:
Incorrect. There is no PGP/MIME support in Outlook, and the Eudora PGP/MIME handling is less than perfect.
My information is different, though I've not used Outlook in some years.
Your information is wrong.
Noted. PGP/GPG is supported, RFC 2015 is not. Apologies. <...>
This will get you killfiled.
I"m willing to risk that. Responses have varied, most people appreciate the information (they simply don't know the issues). Maybe one in ten responds as you suggest. I try to provide compelling content, where possible.
You've got arguments against signing? Again, pointers appreciated.
That isn't what this discussion is about.
The argument's about what it's about. I'm interested in seeing arguments on both sides of the discussion: why is or isn't signing recommended, why is or isn't RFC 2015/3156 recommended, what is the best way to secure broader 2015/3156 support (assuming same is a commendable goal). <...>
First of all, there is nothing insecure with the way RFC 2440 specifies message creation. The benefits that PGP/MIME offers mainly take effect when MIME is already being used for other reasons -- i.e., signing of messages with attachments, etc.
PGP/MIME offers no benefits when it is a plain text ASCII email being signed.
False: PGP/MIME creates a requirement that all mail applications treat the encoded material as opaque, and not subject to manipulation. Encrypted messages which are modified by transports are rendered non-decryptable. Signed messages which are modified by transports fail authentication. I've seen both issues fairly frequently when dealing with signed/encrypted mails using 2015 encoding. You haven't made clear (and it's not clear from the RFC) how 2440 protects against such damage. If I've misread the spec, please disabuse me.
People who march around the net using incompatible, irrelevant, or otherwise inconvenient protocols and subject others to the cruft these protocols generate, all in the name of "standards compliance" and "standards evangelization" are in fact hurting the greater cause.
I'm ordinarially somewhat inclined to agree with you. I'm not completely comfortable with my stance here, though I'm going to continue until an alternative emerges that speaks to the issues addressed in RFC 2015 / 3156. I generally strongly resist "standards" which deprive the user of control or discretion over their systems or data, or introduce security issues, often by way of executing untrusted content. The Web is rife with examples, Javascript, Java, and Flash being prime among them. PGP/GPG encryption and authentication are the opposite of this: the user is given more control, more authentication, higher security, and greater discretion over data and processes. Full implementation for the purpose of handling signed data isn't required so long as the underlying data are cleartext. I'm also trying to be clear in distinguishing advocacy for *support* (strongly encouraged) with advocacy for *use* (encouraged, but not mandatory). It's not clear to me why clients cannot implement at least sufficient 2015 compliance to be able to display signed messages without issue. Note that Declan's observation that MIME would create issues using /bin/mail is largely mooted by the fact that 2015 encoding is transparent to humans -- the underlying content is comprehend able. It's clients that insist on not presenting raw format, but don't render MIME-encoded formats properly, which cause problems. There are also new clients being developed which don't support MIME at all. A friend's mobile phone/PDA is an example -- it can't handle _any_ MIME attachments, let alone 2015 encoded mail. IMVAO, RFC 2015/3156 have followed the appropriate track of specifying a standard, demonstrating multiple implementations, and providing a largely trivial track to achieving compliance. This is strongly preferable to, say, modifying a Kerberos implementation and consequently encumbering the modified specification.
Saying "My email client follows the RFCs to the letter, yours is broken, so it's not my problem that you can't read my mail" *harms* attempts to facilitate wide-spread adoption of crypto technologies. Joe User sees this sort of thing happening, and decides to stay far away from PGP because "it breaks email." You're being obstinate and foolish.
More widespread adoption of an open standard should create broader pressures for yet more widespread adoption. When I hear from those who have issues accessing my mail, I copy them the rant mentioned above. I'm still revising the document to be informative without being inflammatory -- a delicate balance. A similar (but contrary) argument applies to proprietary file formats. If, say, Microsoft's share of the office / "productivity" application space falls to, say, 80%, there will be sufficient interaction inefficiencies that they will be required to, de facto, open and/or freeze their standards. User interoperability and Metcalfe effects will dictate this. At this point, Microsoft's monopoly on this space will effectively broken.
Was this in your rant tarball? I didn't download it.
Accusing others of not reading while not following your own advice is hardly commendable. At 32KB, it's probably not too steep a price.
Summarizing:
You seem to think I am telling you not to sign your messages. This isn't the case; I am telling you not to send MIME attachments to public lists. It has nothing to do with crypto.
I'm not convinced.
I'm not set up to run same, but I'm interested in finding one that doesn't demise.
Thanks. Peace. - - -- Karsten M. Self <kmself@ix.netcom.com> http://kmself.home.netcom.com/ What part of "Gestalt" don't you understand? Home of the brave http://gestalt-system.sourceforge.net/ Land of the free Free Dmitry! Boycott Adobe! Repeal the DMCA! http://www.freesklyarov.org Geek for Hire http://kmself.home.netcom.com/resume.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7sk9yOEeIn1XyubARAqi4AJ4kpvSJgHSkJ5MMt7nKV7rJC3P7JgCghKkL L78GcuEo2hCCjIDWbKKpvXU= =AEjQ -----END PGP SIGNATURE-----