-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 on Tue, Sep 25, 2001 at 06:34:53PM -0700, Meyer Wolfsheim (wolf@priori.net) wrote:
On Tue, 25 Sep 2001, Karsten M. Self wrote:
I suppose this has also been discussed, but if anyone has a favorite compelling argument I'd be interested in seeing it.
Check the archives for such discussions.
Several Web archives include signatures. Checking, e.g.:, debian-user, I found I couldn't validate my own posts. However, archives in mbox format with full text of mail as received should work.
Most archives don't work that way. You will not be able to verify PGP/MIME messages in the majority of web archives available, nor will you be able to verify them with the majority of email clients available.
I can think of several compelling arguments for supporting signed list messages, should the sender wish to sign.
Certainly. However, those people should use RFC 2440 signed messages, not 2015.
I refer you to RFC 2440: Note that many applications, particularly messaging applications, will want more advanced features as described in the OpenPGP-MIME document, RFC 2015. An application that implements OpenPGP for messaging SHOULD implement OpenPGP-MIME. RFC 2440 is a low-level standard defining the structure, RFC 2015 is in some respects a specialized application of same. Among the advantages offered by RFC 2015 is that it defines MIME-encoded PGP components as opaque: message handling systems should treat these components as opaque. The failure to do so by most web archival systems then becomes a compliance issue with RFC 2015. Note that many artifacts of tagging will render signed messages unverifiable, regardless of whether clearsigned or RFC 2015 signed. Defining *a* standard and complying with it is the preferred solution. I'd suggest for reading: RFC 3156: "MIME Security with OpenGPG", M. Elkins, D. Del Torto, R. Levien, T. Roessler (August 2001). Updates RFC 2015. ftp://ftp.isi.edu/in-notes/rfc3156.txt
Tim May <tcmay@got.net> wrote:
If messages are signed, great care should be taken to ensure that the signatures do not in any way interfere with the normal presentation of good old ASCII text, the lingua franca of the online world.
Declan McCullagh <declan@well.com> wrote:
But there seems to be little benefit to (a) signing messages, though this admittedly a personal issue and (b) using MIME types when some mailreaders will not support them. Heck, even leaving aside the Eudora problem, MIME attachments would pose problems if I want to use /bin/mail in a pinch.
petro <petro@bounty.org> wrote:
Of course, [Mutt] doesn't play well with others, but that's common.
You can read the entire tread here: http://www.inet-one.com/cypherpunks/dir.2000.12.04-2000.12.10/msg00006.html
Thanks. A few points: - It's not that Mutt doesn't play well with others (and yes, I'm aware of the curious synchronicity between the authors of mutt and RFC 2015), it's that (some) others have chosen not to play with Mutt. This isn't world+dog playing catchup to a fluid, Redmond-devised, monopoly-ensuring "standard". It's world+dog being afraid to enter into the encryption frey. RFC 2015 is unchanged since 1996. Actually, plug-in support for a range of mailers is available for most mainstream products and platforms, including both MS Outlook and Eudora (two most frequently cited apps). - RSA is almost certainly partially to blame for this. The RSA PKI patent only expired in September of 2000. If this patent hadn't existed, widespread use and implementation of crypto support in mail tools would be fait acompli, and discussion of legislation such as the Anti-Terrorism Act of 2001 would be largely moot. - Backward-compatibility of RFC 2015 would be nice. OTOH, when visiting a (Win2K) using friend recently, I discovered I'd stymied him with plain text attachments (copies of mail messages I'd forwarded as attachments) the other day. Without a file extention, legacy MS Windows has no idea what to do with the content, and the simple precedents of either using a tool like the GNU/Linux "file" command (to guess file contents using the compelling heuristic of...looking at file contents), or simply throwing the shitheap at a (text-capable) pager, are beyond the pale for legacy MS Windows users.... <sigh> - Backwards-compatibility II: RFC 2015 renders the message and signature components as inline quoted printable, and inline, respectively. Mailer disposition should be to simply render these using existing inline text representation. This is a failure of such mailers to provide fundamentally sane handling of MIME. - As has been pointed out, RFC 2015 messages are composed of nothing but ASCII. Technically, so are UU encoded messages. It's how that ASCII's handled that's significant. Still, the raw encoding provided by RFC 2015 is transparent to humans. - My own philosophy on using signed email is summed up in my standard GPG rant: http://kmself.home.netcom.com/Download/rant-o-matic.tar.gz # install $ rant gpg In part: - Your mailer is broken. - This is your problem, not mine. - File a bug report with your vendor. <...> So, Why Do You Insist On Signing Your Mail Anyway? Fair question. Part of the reason is for your benefit, where you are the reader of my mail. It is your responsibility to ensure that what you are reading as attributed to me is in fact my own writing[...] Why is it your responsibility? Simple: you know you've received mail from me. I may or may not know I've sent it. As is well known, email is an insecure, unauthenticated medium. It's quite possible that someone is sending something claiming to be someone they aren't[....] If it's not signed by me, your assumption should be that it isn't *from* me. A large reason though is to encourage and advocate use and adoption of tools that support public key infrastructure (PKI) methods, both the ability to create and properly process signed and encrypted mail. I've found myself at several times needing to send authenticated or encrypted mail to persons, only to find that the recipients did not have a public key, PKI support within their mailer, or even, at times, a mailer capable of supporting PKI. It's been suggested variously that I sign messages inline, or in some instances, that mailing lists drop all MIME-encoded attachments. I believe this is the wrong solution for two reasons: - It breaks useful behavior. MIME attachments *can* provide useful information, including support of non-ASCII charactersets, required for basic communications in much of the world[...] - It's not the root problem. The root problem is mail clients which handle untrusted content in an insecure fashion. This is like dousing 75% of the population with gasoline, then placing match-confiscating personnel at the doors of all public arenas. The problem isn't the matches. It's the gasoline. Palliative measures to reduce the apparent risk without addressing the actual cause mask the problem without fixing it. If sufficient people feel the pain, we'll eventually see changes either to client behavior or choice. - My general suggestion to list maintainers is that policies be set on what MIME encoding is or isn't allowed. Content filtering based on such rules would reject malfomred messages. Likely targets: HTML mail, various binary attachments. This strikes me as more useful than de-miming all messages. While we're at it, attacking the dozen-plus line disclaimers showing up in more and more corporate email would be a blessing. But I believe this constitutes thread drift.... - I'll put in a vote for suggesting the cypherpunks list support broader adoption of encryption standards by allowing and supporting RFC 2015 signed messages.
(I found it in about 30 seconds with google.)
Ain't Google grand :-)
[demime 0.97c removed an attachment of type application/pgp-signature]
Snicker.
Go ahead, laugh. I sign my mail. When I have to, I clearsign it, under protest. 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 iD8DBQE7sWx0OEeIn1XyubARAkxXAJwKjfyvpmTnTIay+wvvNiFfpY8YtACdHOYl X6qqREV6Q4jDlq2etrL+O+M= =dpxv -----END PGP SIGNATURE-----