[linux-elitists] GPG luser rant

Karsten M. Self kmself@ix.netcom.com
Thu Apr 12 18:17:03 PDT 2001

I've had the small joy of dealing with folks to whom the concept of GPG
signatures is, well, foreign at best.  I've shared some episodes with
this list in the past.

I've strung together a few of my previous responses into a FAQ of sorts
on the topic.  It's still kinda rough (don't write nastygrams at 2am),
and desperately needs:

  - Information on what Win/Mac software is GPG and RFC 2015 compatible.

  - Resources on same.

  - Why Standards Matter®

  - A cogent argument for why signing mail is a Good Thing®.  Note the
    distinction made between cryptographic digital signatures, and the
    recently enacted "Electronic Signatures" law.  The former is a way
    of providing some measure of confidence that identity and content
    are accurately represented, the latter is a trick to allow you and
    your money to be separated through fscking brain-dead mechanisms
    like touch-tone phones and web-form checkboxes.  Actually, some hard
    facts on this might be helpful for a separate rant.

    My core argument at present is "authenticating the sender is *your*
    problem", WRT email.  This is probably going into my sig or X-Header
    list at some point (K5's doing fine w/o my plugging,

  - Better treatment of PKI.

  - Better organization.  I threw together what I had, diced it, then
    wet-pasted the bits together.  The structure sucks, I know that.
    Critiques welcomed.

  - A strong defense of *why* 2015 should be considered a standard
    despite its draft status.  I'll hit Michael Elkins separately.

I've got some mutt screenshots showing validated, trusted, and bad
signatures which I'll link into the web version.

This is meant as a group resource.  I'd like for this to be something
people can (and want to) point at.  I might even tone down the language,
if someone can come up with any fucking convincing arguments for doing
gutless shit like that.


Karsten M. Self <kmself@ix.netcom.com>    http://kmself.home.netcom.com/
 What part of "Gestalt" don't you understand?       There is no K5 cabal
  http://gestalt-system.sourceforge.net/         http://www.kuro5hin.org
-------------- next part --------------
		  A Short Rant / FAQ on the Subject of 
	      Signed E-Mail and Public Key Infrastructure

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

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.

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.

  - No, this isn't a virus, a bomb, a bug, a worm, or any other
    executable code.

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

There's an Internet standard, called a "request for comments", or RFC,
which covers MIME encoded encryption and signatures.  This is RFC 2015
(more info below under "Resources").
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: quoted-printable

...which should be handled properly as inline plain-text content.  If
your mailer doens'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

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.

You might ask why I insist on signing my mail.  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 passkey necessary to utilize it.  Consider it the
equivalent of an electronic signet ring.

I've been active on the Internet for over fifteen years.  I've had
dozens of email accounts, and have had my identity spoofed, publicly, in
front of those who know me well.  By adopting the practice of signing
every piece of email I send, I'm establishing a practice of plausible
deniability in the event unauthorized communications are made in my
name.  If it's not signed by me, your assumption should be that it isn't
*from* me.  No, the system's not perfect, but it's a hell of a sight
better than nothing.

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.

    Pallative measures to reduce tha 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.

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

> 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:
> I keep getting empty emails as the result of this reconfiguration. 
> Thanks
> Regards,
> <name deleted to protect the imbecillic>

This prompted a response:

    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 extentions) 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 procedes
	to allow execution of unsafe content within it (MS Word macro

      - There is no ready tool for looking at the raw (text/binary) form
	of the attachment to detrmine 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 havok 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

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

    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>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
Url : http://allium.zgp.org/pipermail/linux-elitists/attachments/20010412/71aeaab5/attachment.pgp 

More information about the linux-elitists mailing list