[linux-elitists] Fwd: PGP signature attachments!

Karsten M. Self kmself@ix.netcom.com
Fri Sep 7 14:18:16 PDT 2001


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

on Fri, Sep 07, 2001 at 08:42:11PM +0100, Sean Neakums (sneakums@zork.net) wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> begin  Karsten M Self quotation:
> 
> > RFC 2015 is a defined, if draft, standard.  It works, it provides
> > useful functionality, it has minimal side effects (as opposed, say,
> > to the automated parsing of email for inline elements such as is
> > used in Microsoft products which will effectively truncate mail
> > starting at begin some text (note the two blanks following 'begin').

> There is big difference betwen interpreting a de-facto standard such
> as "-----BEGIN PGP SIGNED MESSAGE-----" as denoting a signed message
> and writing a mail client that chokes on what a bad programmer assumed
> would always be a uuencoded inclusion.  Unlike Outlook, Gnus's
> interpretation of such plain-text markers can be disabled[0].

...and if it's not disabled?  I presume something like the following...


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: WHERE IS THE LASER?

...might_prove_to_be_unreadable_by_default_within_your_mailer_of
choice.
-----END PGP SIGNATURE-----

If that doesn't work, there's probably some way to misuse this feature
which will emerge on further exploration.  That's not my aim, it's
merely a risk.

MIME encoding typically breaks when abused (or malformed or twiddled by
broken mail-handling agents), in frequently resulting in a plain-text
rendering of the message payload.

Moreover, RFC 2015 includes directives to mail handling utilities
regarding integrity of messages, and how they are or aren't to modify a
message text which has been signed or encrypted.  As you've certainly
read my rant closely by now, you'll note the specific reference I've
made to the munging issue.  Cleartext signing provides no such hints,
and there is no assurance your cleartext signed message will be
delivered intact.  A non-RFC 2015 compliant MTA/MDA can have a bug
report filed on it, or be listed as noncompliant and deprecated.

> > Parsing of inline content is changing the interpretation of plain
> > text messages.  Why do this when there is a perfectly good, open,
> > free standard based on good, open, free MIME encoding, which
> > operates properly.
> 
> A MIME message is just a special case of plain-text message with some
> extra headers and boundary markers.  Just like a PGP-style
> signed/encrypted message, except a raw PGP-signed message has a lot
> less noise than a raw PGP/MIME message.

From a structural standpoint, you may have a case.  From a contextual
one, far from it.  MIME is an established and official IETF standard.
RFC 2015 is not officially recognized, due to its draft status, but it's
a fairly widely implemented standard.  The Gnus feature is, by contrast,
an exploitation of a convention.

> > Your "a good user agent" is a specious as mine.  A good user agent
> > follows standards and doesn't impose unexpected behavior based on
> > arbitrary content.
> 
> How is interpreting a message surrounded by plain-text PGP as a signed
> message infrastructure "unexpected"?  

See text following "contextual" above.

Cheers.

-- 
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
   Free Dmitry! Boycott Adobe! Repeal the DMCA!    http://www.freesklyarov.org
Geek for Hire                        http://kmself.home.netcom.com/resume.html
-------------- 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/20010907/6ee49e53/attachment.pgp 


More information about the linux-elitists mailing list