[Top] [All Lists]

Re: Standardizing inline PGP for e-mail?

2003-01-22 10:44:00

It seems like inline PGP messages just can't be eradicated, despite
all the PGP/MIME we have.  I'm wondering if it would be reasonable
to produce an RFC on (1) how to tag this on the MIME level, and (2)
how to avoid character set problems.

Here's the simple proposal (in rough words), as currently
implemented in the Mutt mail user agent.

1. Inline PGP messages use text/plain as their MIME type.  Inline
PGP material is announced in an additional MIME parameter (we call
it x-action right now), which can take the values "pgp-encrypt",

Such usage clearly violates RFC 2046 section 4.1.3, which states
that text/plain is intended for material that isn't formatted in any way:

  Plain text is intended to be displayed "as-is", that is, no interpretation of
  embedded formatting commands, font attribute specifications, processing
  instructions, interpretation directives, or content markup should be necessary
  for proper display

It also violates the intended use of media type parameters, which are supposed
to qualify the format being used rather than identifying it. Format
identification is supposed to be done by the media type.

Additionally, your typical user agent is far better equipped to dispatch off a
media subtype than it is to dispatch on a media type parameter value.

Finally, situations exist in non-IETF standards where media types are used
without allowing for media type parameters. (That such a situation has come
into being is unfortunate, but not something we can do anything about.)

This is a total nonstarter IMO.

Use of a subtype other than text is a possibility, assuming of course that the
idea itself holds water.

2. Clearsigned messages are converted to UTF-8 before they are
signed and sent.  Since UTF-8 is OpenPGP's standard text character
set, there is no Charset armor header.  The MIME charset header is
set to utf-8 as well.

Sounds fine, but it begs the question of why, if you're going to introduce a
major operationaal change to how PGP signs things, you  don't just change to
generating multipart/signed.

3. Encrypted messages are likewise converted to UTF-8 before they
are passed to OpenPGP.  Once again, there is no Charset header on
the ASCII armor. However, on the MIME level, the message will be
us-ascii -- we're using ASCII armor.

Again, a separate media type is going to be needed.