Home | Mail | Resume | Karsten M. Self

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

By
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. The reason is that I'm using an open Internet standard, RFC 2015 encoding, to sign, or authenticate, my mail. This standard has existed since 1996, and can be freely implemented by any email software author. It provides means to both authenticate, and encrypt, email. You have a legal right to do this in many parts of the free world.

By sending mail encoded per RFC 2015, I and others are creating compelling content under this standard. At some point it's sufficient that others will want to access it. By doing so, they are also (usually) availing themselves of practical crypto, including generating keys, getting these signed, and the other appurtenances of a viable public key infrastructure.

Merely having a legal right to encryption doesn't mean you have the technical right. Merely having the technical capability doesn't mean you have (or know how to use) your keys. Merely having a key doesn't mean that it is signed, in use, well known, or part of a web of trust. If you find yourself with a need to produce authenticated or encrypted content, you're going to have to find, install, learn to use, and build the infrastructures necessary, for same. There's a saying among the Boy Scouts here, "be prepared".

Hence the intentional role I and others play as goads to the online world.

As to the immediate problem, the short answer is that:

The long answer is the rest of this document.

For a well-reasoned essay on why public key infrastructures, including encryption and authentication, are vital to a modern economy, please read:

http://gnu-darwin.sourceforge.net/war.html

"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:

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 are RFC 2015 and 3156 and 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. It's been updated with a second standard, RFC 3156 (also below).

While RFC 2015 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: quoted-printable

...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, sometimes due to security concerns of the recipient in receiving attachments. I believe this is the wrong solution for two reasons:

So Where Can I Find RFC 2015/3156 Compliant Mailers, Or Other PGP/GPG Encryption Support?

For lists:

MUA implementations of RFC 2015:

Got Any Funny Clueless Luser Stories For Us?

Funny you should ask.

One particularly illuminating response I've received 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
        message:

           <<< MIME ATTACHMENT STRIPPED >>>

        I keep getting empty emails as the result of this
        reconfiguration.

        Thanks

        Regards,

        <name deleted to protect the lusers>

This prompted the following response from me:

        <rant>

        So let me get this right.

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

    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 but:

      - 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 this.

        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.

        </rant>

Resources:

Some additional informational resources for your benefit:

Copyright (c) 2001, Karsten M. Self <kmself@ix.netcom.com>
This document may be freely distributed with attribution.
The original of this document is found at http://kmself.home.netcom.com/Rants/gpg-signed-mail.html

Home
mail: kmself@ix.netcom.com
Last updated: 2004/04/11 22:29:00