[linux-elitists] Fwd: PGP signature attachments!

Aaron Lehmann aaronl@vitelus.com
Fri Sep 7 10:51:00 PDT 2001

On Fri, Sep 07, 2001 at 10:44:55AM -0700, Wil Cooley wrote:
> How the hell do you respond to someone like this?

Try Karsten's canned response:

	A (not so) Short Rant / FAQ on the Subject of 
	Signed E-Mail and Public Key Infrastructure

	Karsten M. Self <kmself@ix.netcom.com>

	    You're probably reading this because you either stumbled across it
	    at my website, or I sent it to you in response to an email you sent
	    me saying you can't read my mail.  In the latter case, the short
	    answer is that:

	      - Your mailer is broken.

	      - This is your problem, not mine.

	      - File a bug report with your vendor.

	      - I'm going to continue signing my mail, and if you don't
	        change your end of things, you're going to continue
	        having problems reading it.

	        In some cases (you're cute, my mom, or you're offering
	        sufficient reasons per hour), I'll make exceptions, but
	        this is on a case-by-case basis, and I'm intentionally
	        leaving it as a PITA manual process so that each of us
	        is reminded it's a bad idea:  me, when I do it, you,
	        when I forget and you're stuck with unreadable mail from
	        me.  GET A REAL MAILER.

	      - No, this isn't a virus, a bomb, a bug, a worm, or any
	        other executable code.  And if it is, that's your
	        problem, not mine.

	      - If your IT or MIS department is brain-dead enough to
	        actually strip off these attachments before you get your
	        mail, I'm going to laugh at you in public.  Sorry, this
	        ain't the sympathy department.  There's a nice rant
	        below about why this is such a pathetic action, though,
	        you might enjoy reading it.

	    The long answer is the rest of this document.

	"Your Mail is Weird"

	    I use a combination of tools in my email to create messages which
	    are cryptographically signed in such a way that it is readily
	    possible for the recipient to gain a good level of assurance that
	    the message:

	      - Originates from me.

	      - Hasn't been modified in any way en route.

	    This is sometimes called a digital signature (a technical term, not
	    to be confused with the recently passed US legislation on
	    "electronic signatures", regarding legal contractual powers
	    associated with various, and largely very weak, methods of inserting
	    corporate hands into your wallet).  The system under which it
	    operates is known as public key infrastructure, and is based on
	    public key encryption.  You're probably going to start hearing a
	    whole lot about this over the next year or so.

	    That's the long description.

	    The short story is that there's a way for me to keep half a secret
	    and spread the other half to the world in such a way that you can
	    tell if a particular message came from my half of the secret.  It's
	    pretty cool.

	    The other part:

	    You're responsible for determining whether or not a communication
	    that purports to come from me is in fact from me.  And if I didn't
	    sign it, it almost certainly didn't.  If the message *is* signed,
	    it's still your obligation to verify the signature itself.

	What is RFC 2015 and Why Can't I Read Your Mail?

	    There's an Internet standard, called a "request for
	    comments", or RFC, which covers MIME encoded encryption and
	    signatures.  This is RFC 2015, "MIME Security with Pretty
	    Good Privacy", (more info below under "Resources"), and
	    defines how to handle public key infrastructure (PKI)
	    encryption and authentication via standard MIME protocols.

	    While it is still a draft standard, it is widely supported
	    on multiple platforms.  There are some pieces of Internet
	    mail plumbing which break the protocol -- multiple mail
	    clients ("email applications" to you), as well as some
	    server applications.   LISTSERV and beromail are two I'm
	    aware of -- but compatibility modes are frequently available
	    for such software, and in many cases, support is planned in
	    future upgrades.  But that's another story.

	    If you're interested in the gory technical details, read on.
	    You should be able to save my email as a text file and open
	    it in a simple editor (e.g.:  Notepad or Write under Legacy
	    MS Windows).  You'll find that the message body content type
	    of my messages is expressed as:

	        Content-Type: text/plain; charset=us-ascii
	        Content-Disposition: inline Content-Transfer-Encoding:

	    ...which should be handled properly as inline plain-text
	    content.  If your mailer doesn't present the message body in
	    this format, you should report a bug to the program
	    maintainer or vendor.

	    The signature is presented as:

	        Content-Type: application/pgp-signature
	        Content-Disposition: inline

	    Again, this is plain text, non-executable, and in no way
	    represents a threat or possible exploit on your system.  For
	    an intelligent mailer, this should be interpreted, rather
	    than presented, and used to validate the message content
	    itself.  Otherwise, the content can be presented or
	    concealed, at the user's preference.

	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.  While digital (or sometimes "electronic"
	    signatures now carry some legal standing, I'm not vesting my
	    GPG hash with this power.  However, you can be pretty
	    confident that words appearing over my signature, verified
	    against my public key, were written by me, or by someone who
	    has access to my computer, my private key, and the pass-key
	    necessary to utilize it.  

	    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.  In fact, this
	    happens as a matter of course with spam.  Since you (the
	    recipient) have the evidence in front of your eyes, and I've
	    no idea it's been sent, if it's not from me, the burden of
	    authentication lies with the recipient.

	    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.  In the case of
	        signed messages, a recent SANS alert of the BIND exploit
	        of the day was copied to a mailing list I'm subscribed
	        to as cleartext-signed message.  The body of the message
	        was modified in two generations of distribution and the
	        signature rendered invalid.  This is not immediately
	        apparent as messages which are cleartext- signed must be
	        verified as a separate, manual, step.  In the case of
	        security exploits and announcements, such verification
	        and authentication is of some importance.

	      - 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

	So Where Can I Find RFC 2015 Compliant Mailers

	    For lists:  


	    MUA implementations of RFC 2015:

	        GNU/Linux / UNIX (most also ported to other platforms via
	        compatibility kits such as Cygwin, UWIN, MKS, MS Unix
	        Services for NT, etc.)

	            emacs (through various mail extensions), exmh,
	            ishmail, mew (an emacs mail reader), mutt, premail
	            (Netscape plugin), Gnus 5.6.45 with TM and
	            Mailcrypt, KMail, Mixmaster 2.9 (internal mail
	            reader), Sylpheed 0.4.63, TkRat, XCmail, XFMail 1.3.

	        Legacy MS Windows, Macintosh, and other platforms.

	            Claris Em@iler with PGP 5 (?), Datula (plugin), Edmax
	            (plugin), MS Outlook Express (plugin), MS Outlook
	            (plugin), Mulberry (plugin), PMMail (native), Qualcomm
	            Eudora (full and light version for Windows and Mac)
	            since version 3.02 with PGP 5.5.3i and 6.0.2i Plugin,
	            Turnpike (native), Voodo on Amiga.

	Got Any Funny Clueless Luser Stories For Us?

	    Funny you should ask.

	    One particularly illuminating response I've receive runs
	    more or less as follows:

	        My company's MIS department has recently configured the
	        email system so that if an email has suspected attachment,
	        it will not be delivered.  Instead, the recipient gets the
	        following message:
	            This message uses a character set that is not
	            supported by the Internet Service.  To view the
	            original message content, open the attached message.
	            If the text doesn't display correctly, save the
	            attachment to disk, and then open it using a viewer
	            that can display the original character set.
	        If you try to save it as instructed, you will see another
	           <<< MIME ATTACHMENT STRIPPED >>>
	        I keep getting empty emails as the result of this
	        <name deleted to protect the lusers>

	    This prompted the following response from me:

	    So let me get this right.

	    You use a mail client which allows, among other things,

	    You use a mail client which, among other things, includes
	    executable content to be sent as attachments.

	    You use a mail client which, among other things,
	    *automatically executes* this content, without verifying its
	    source or asking for user intervention.  As an added bonus,
	    there is content which *does* require the user to launch it

	      - Mail and/or OS features disguise the fact that the
	        attachment is, in fact, an executable, by hiding such
	        extensions as might actually reveal such a fact.

	      - A file content coding scheme (file extensions) which is
	        bypassed by the fact that a program can be coded to open
	        content which should be safe (say, a text or RTF
	        document) but then proceeds to allow execution of unsafe
	        content within it (MS Word macro viruses).

	      - There is no ready tool for looking at the raw
	        (text/binary) form of the attachment to determine its
	        true Buddha nature.  I've got raw text and binary
	        viewers at my fingertips, and use them.

	      - OS features and security  are such that unprivileged
	        users can wreak havoc on their own systems, networked
	        storage, and other users systems, without protections
	        afforded by sane filesystem security, user permissions,
	        and file organization.

	      - OS and application features are such that users
	        routinely send, and are expected to utilized, arbitrary
	        content, much of which may be executable.  Which might
	        be translated as "the user is an idiot", but is
	        conditioned by the fact that the user has been trained
	        that acting like an idiot: running arbitrary software,
	        or engaging arbitrary methods, which may or may not
	        include executing code, on arbitrary content, is not
	        only a perfectly acceptable standard of operation, but
	        _is required to perform basic job functions_. 

	      - In order to compensate for all these "features", your
	        system administrators have seen fit, in their divine
	        wisdom, to extricate all attachments from email.
	        Including such attachments as might actually serve to
	        provide some level of authentication as to whether or
	        not the source of a particular email is who it claims to
	        be, and possibly even a trust level associated with

	    And this is now a problem for third party sites to deal with
	    on your behalf?

	    I'm sorry.  I don't follow the logic.  

	    This is your problem, not mine.

	    If you're going to strip all such features from your email, why
	    don't you just go back to a plain text mailer and stop asking the
	    rest of the world to please stop passing bombs your way with fuses
	    you insist on lighting.




	    Some additional informational resources for your benefit:

	      - RFC 2015, "MIME Security with Pretty Good Privacy", M. Elkins,
	        October, 1996,
	        http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2015.html , spells
	        out the standards for encrypted and cryptographically signed
	        email.  Note that signature-as-attachment is required by

	        Note also that munging the content of multipart/signed messages
	        violates RFC2015.  This addresses issues with several broken
	        mailing list management software packages.

	     -  For a list of mailers supporting RFC2015, see:

	     -  For information on GnuPG, the GNU Privacy Guard, see

	Copyright (c) 2001, Karsten M. Self <kmself@ix.netcom.com>
	This document may be freely distributed with attribution.


More information about the linux-elitists mailing list