ietf-openpgp
[Top] [All Lists]

Re: Shortcomings of current schemes (Was: One-pass signatures)

1998-07-27 06:40:02
On Sat, Jul 25, 1998 at 06:45:28PM -0500, William H.
Geiger III wrote:

One really needs to run a second pass over any encrypted
message after it has been decrypted as the contents of the
encrypted packet are unknown until decryption. The client
software should be capable of handeling multiple layers of
PGP messages one inside of another.


I'm not sure what you mean by this.  

IMNSHO, PGP client software should never ever interpret
the contents of a literal data packet, but handle it as
precisely this: Literal data. Interpreting data packets'
content has to be done by mail user agents or users
themselves.


An example: Think about someone who gets a message which
agrees to current PGP/MIME standards.  He encapsulates
this message into a message/rfc822 type attachment and
forwards it (along with some comment) to a friend.  The
forwarded message is PGP/MIME encrypted.

We get a message which looks like this:

        multipart/encrypted
        |
        +- application/pgp-encrypted (This is just "Version: 1")
        `- application/octet-stream

The application/octet-stream contains ASCII armored,
encrypted stuff.  After decryption, we get a valid
message/rfc822 MIME attachment which contains an
attachment tree like this one:

        multipart/signed
        |
        +- text/plain (This is the payload)
        `- application/pgp-signature

The application/pgp-signature attachment contains an ASCII
armored signature of the preceeding attachment.

Now, imagine a PGP implementation which tries to interpret
the contents of a literal data packet. Such an
implementation would recognize the
applicatin/pgp-signature attachment's contents as ASCII
armord PGP stuff and try to interpret it.  Bumm.


There are worse cases to be considered: Imagine the
forwarded message uses the traditional application/pgp
stuff.  In this case, a cleartext signature of the text in
question is generated _before_ any MIME encoding is being
applied.  This means that the PGP encrypted stuff I just
talked about will return a message/rfc822 MIME attachment
which contains precisely one body part of type
application/pgp:

        message/rfc822
        |
        `- application/pgp; transfer encoding: quoted printable

The armor delimiters will be left unchanged by quoted
printable encoding, while the messages' content _will_ be
changed.  An implementation of PGP which interprets
literal data packets' content will recognize the
delimiters, try to decode the message, and end up with a
bad signature where we actually had a good one.

Finally, a message may contain "sample code" which looks
like PGP armor, but is not.

Similar problems occur with public keys which are
formatted according to the PGP/MIME RFCs.  Note that this
is not just theory, but real problems.  E.g., try sending
and reading PGP/MIME signed public keys with recent Mutt
versions and PGP 5.  The output looks really funny.


To make a long story short: We should consider literal
data packets as AS IS data.  Their content MUST NOT be
interpreted by an OpenPGP implementation, but passed to
the user or invoking software for further inspection.
These programs MAY then interpret PGP/MIME content type
definitions and invoke an OpenPGP client to work on the
nested data.

Maybe something along these lines should be added to the
latest draft.  (I didn't check if it's there already.)

tlr
--
Thomas Roessler · 74a353cc0b19 · dg1ktr · http://home.pages.de/~roessler/
     2048/CE6AC6C1 · 4E 04 F0 BC 72 FF 14 23 44 85 D1 A1 3B B0 73 C1