Subject: Re: let's look... Re: Standardizing inline PGP for e-mail?

From: [email-masked]
Date: Thu, 23 Jan 2003 06:55:06 +0100 (CET)

On 23 Jan, Thomas Roessler wrote:
> This message contains inline PGP material tagged as text/x-pgp.  I'd
> be curious to learn what kind of behaviour this causes.  In
> particular, are those whose user agents aren't prepared to handle
> PGP by default able to display the "raw" clearsigned material
> without problems?

TkRat, just shows a blob stating that here is an object of type
text/x-pgp and some buttons with different actions. One of the actions
is "View as plain text" and selecting that shows the message content. It
also recognizes that it is an embedded pgp message and thus gives the
option to check the signature.

	/MaF

PS I am the author of TkRat so obviously I am biased:-)

---

From: [email-masked]
Date: Thu, 23 Jan 2003 06:43:38 -0800

-----BEGIN PGP SIGNED MESSAGE-----

On Wed, 22 Jan 2003 16:05:56 -0800 Michael Young
<[email-masked]> wrote:
>Excellent idea...
>
>Your message displays fine in Outlook Express.  (Yes, I know it's
>a noxious agent.)  The signature verified fine using PGP6.5's "current
>window" support.
>
>I'll try other agents when I can.

fwiw,

no clearsigned messages verify in hushmail,
they do not even display the pgp headers, footers and signatures unless the
'show actual message' display is checked, and even then, while it does
display everything, it verifies as 'bad'

also, btw,
the huhmail pgp armor has 66 characters per line as opposed to the standard
pgp 64

am signing this from hushmail, from the 'current window'

vedaal

Concerned about your privacy? Follow this link to get
FREE encrypted email: https://www.hushmail.com/?l=2 

Big $$$ to be made with the HushMail Affiliate Program: 
https://www.hushmail.com/about.php?subloc=affiliate&l=427

---

From: [email-masked]
Date: Fri, 24 Jan 2003 10:50:02 -0600

FWIW, Lotus Notes displayed this message with an attachment for the 
signature.
I have no idea how to verify it.  I suppose I would have to paste the 
content and the signature into a text file, mark up the -----BEGIN PGP 
etc. delimiter lines, and then try? 

--John

"Adrian 'Dagurashibanipal' von Bidder" <[email-masked]>
Sent by: [email-masked]
01/24/03 02:31 AM

        To:     [email-masked]
        cc: 
        Subject:        Re: let's look...  Re: Standardizing inline PGP for e-mail?

On Don, 2003-01-23 at 22:35, David Shaw wrote:
> I think in general that creating a new subtype of text to solve this
> problem is a non-starter.  Part of the original problem was that not
> enough mailers supported PGP/MIME (or indeed, MIME in general)
> sufficiently well.  I suspect that using a new subtype will eventually
> end up as "PGP/MIME lite" and will similarly not be supported.

Additionally, specifying inline PGP could make Software vendors even
more reluctant to support PGP/MIME properly. Why not make it absolutely
clear that PGP/MIME is the only form of PGP in email mailers are
supposed to use.

inline pgp won't get worse as it is - but manpower should be directed
into making PGP/MIME work, not into fixing inline pgp, imho.

cheers
-- vbi

--
featured link: http://fortytwo.ch/gpg/subkeys

---

From: "Brian Smith" <[email-masked]>
Date: Fri, 31 Jan 2003 12:01:16 -0800

>display everything, it verifies as 'bad'

HushMail will verify the clearsigned message if the public key corresponding to the signature has been uploaded to our keyserver.  Otherwise it should just display "Certificates could not be found for some of the signatures on the message".

That's the behavior that I get when I read the "let's look..." message.

Date: Fri, 31 Jan 2003 12:01:16 -0800
To: [email-masked]
Cc: 
Subject: Re: let's look...  Re: Standardizing inline PGP for e-mail?
From: "Brian Smith" <[email-masked]>
Sender: [email-masked]

>display everything, it verifies as 'bad'

HushMail will verify the clearsigned message if the public key corresponding to the signature has been uploaded to our keyserver.  Otherwise it should just display "Certificates could not be found for some of the signatures on the message".

That's the behavior that I get when I read the "let's look..." message.

Date: Tue, 28 Jan 2003 07:36:31 -0800
To: [email-masked]
Cc: 
Subject: Re: How about this? (Re: Standardizing inline PGP for e-mail?)
From: [email-masked]
Sender: [email-masked]

On Mon, 27 Jan 2003 08:17:54 -0800 [email-masked] wrote:
>How about this variation:
>
>Add an X-header to the message.  

or possibly a simple generic solution {*if * it would work}
on the user end,
to just preface the pgp clearsigned message with:

below is a clearsigned pgp message,

and so, try to 'fool' the e-mail client that the message begins and ends
with plain text.

am including a test clearsigned message in-line below, followed by an end plaintext,

clearsigned test

this ends the pgp message test,

vedaal

To: [email-masked]
Subject: How about this? (Re: Standardizing inline PGP for e-mail?)
From: [email-masked]
Date: Mon, 27 Jan 2003 10:17:54 -0600
Sender: [email-masked]

This is a multipart message in MIME format.
--=_alternative 005987B486256CBB_=
Content-Type: text/plain; charset="us-ascii"

How about this variation:

Add an X-header to the message.  Everybody not "in the know" will 
certainly ignore it.  It serves the same purpose as the original proposal, 
allowing those that are "in the know" to decode the message automatically 
or otherwise take action without having to parse the body to discover the 
existance of inline PGP.

If the purpose of this is to trigger automatic decoding, have something 
like
        X-PGP-autodecrypt: true

also, a value of false can explicitly tell the MUA not to automatically 
decrypt.

--John

"Michael Young" <[email-masked]>
Sent by: [email-masked]
01/24/03 12:53 PM

        To:     <[email-masked]>
        cc: 
        Subject:        Re: let's look...  Re: Standardizing inline PGP for e-mail?

From: "David Shaw" <[email-masked]>
> On Fri, Jan 24, 2003 at 11:08:25AM -0500, Michael Young wrote:
> > David Shaw wrote:
...
> I think we've seen in this thread that the "lite" form is not
> displayed at all in agents that don't support it.

That's an overstatement.  Several MUAs handled it just fine (and
mutt is clearly going to be changed in the process, so it will also).
(The only failure I saw was Outlook XP, but I may have missed something.)

But, I missed that you were talking specifically about the subtype idea...

> Thomas' original suggestion to use UTF8 encoding along with text/plain
> works very nicely on several levels.  First, it works without forcing
> the MUA author to do anything.  Second, in most cases even if MUA "A"
> does it slightly wrong (say, not doing the UTF8), MUA "B" can still
> handle it.  It's simple.  It works.  Where is the problem?

The main reason we went down the subtype path was that Ned balked at
using text/plain with extra tags.  (Thomas suggested the tags to let
in-the-know MUAs take automatic action, and Ned balked there, too.)
Experimenting with subtypes was a fine idea, but it hasn't been a
complete success.  I'm happy to back off to text/plain, and I'm happy
with the extra tags.

--=_alternative 005987B486256CBB_=
Content-Type: text/html; charset="us-ascii"

<br><font size=2 face="sans-serif">How about this variation:</font>
<br>
<br><font size=2 face="sans-serif">Add an X-header to the message. &nbsp;Everybody not &quot;in the know&quot; will certainly ignore it. &nbsp;It serves the same purpose as the original proposal, allowing those that are &quot;in the know&quot; to decode the message automatically or otherwise take action without having to parse the body to discover the existance of inline PGP.</font>
<br>
<br><font size=2 face="sans-serif">If the purpose of this is to trigger automatic decoding, have something like</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; X-PGP-autodecrypt: true</font>
<br>
<br><font size=2 face="sans-serif">also, a value of false can explicitly tell the MUA not to automatically decrypt.</font>
<br>
<br><font size=2 face="sans-serif">--John</font>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>&quot;Michael Young&quot; &lt;[email-masked]&gt;</b></font>
<br><font size=1 face="sans-serif">Sent by: [email-masked]</font>
<p><font size=1 face="sans-serif">01/24/03 12:53 PM</font>
<br>
<td><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To: &nbsp; &nbsp; &nbsp; &nbsp;&lt;[email-masked]&gt;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; &nbsp; &nbsp;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;Re: let's look... &nbsp;Re: Standardizing inline PGP for e-mail?</font></table>
<br>
<br>
<br><font size=2 face="Courier New"><br>
-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
From: &quot;David Shaw&quot; &lt;[email-masked]&gt;<br>
&gt; On Fri, Jan 24, 2003 at 11:08:25AM -0500, Michael Young wrote:<br>
&gt; &gt; David Shaw wrote:<br>
&gt; &gt; &gt; I think in general that creating a new subtype of text to solve this<br>
...<br>
&gt; I think we've seen in this thread that the &quot;lite&quot; form is not<br>
&gt; displayed at all in agents that don't support it.<br>
<br>
That's an overstatement. &nbsp;Several MUAs handled it just fine (and<br>
mutt is clearly going to be changed in the process, so it will also).<br>
(The only failure I saw was Outlook XP, but I may have missed something.)<br>
<br>
But, I missed that you were talking specifically about the subtype idea...<br>
<br>
&gt; Thomas' original suggestion to use UTF8 encoding along with text/plain<br>
&gt; works very nicely on several levels. &nbsp;First, it works without forcing<br>
&gt; the MUA author to do anything. &nbsp;Second, in most cases even if MUA &quot;A&quot;<br>
&gt; does it slightly wrong (say, not doing the UTF8), MUA &quot;B&quot; can still<br>
&gt; handle it. &nbsp;It's simple. &nbsp;It works. &nbsp;Where is the problem?<br>
<br>
The main reason we went down the subtype path was that Ned balked at<br>
using text/plain with extra tags. &nbsp;(Thomas suggested the tags to let<br>
in-the-know MUAs take automatic action, and Ned balked there, too.)<br>
Experimenting with subtypes was a fine idea, but it hasn't been a<br>
complete success. &nbsp;I'm happy to back off to text/plain, and I'm happy<br>
with the extra tags.<br>
<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: PGP Personal Privacy 6.5.3<br>
<br>
iQA/AwUBPjGLmOc3iHYL8FknEQJ37ACghzrVLCZlW9gUpPafuY1/8GRObN4An112<br>
t8VJroo4FslcDx/6bTVCw77+<br>
=xHO7<br>
-----END PGP SIGNATURE-----<br>
<br>
<br>
<br>
</font>
<br>
<br>
--=_alternative 005987B486256CBB_=--

Date: Sat, 25 Jan 2003 17:41:56 -0800 (PST)
From: [email-masked]
Subject: Re: Standardizing inline PGP for e-mail?
To: Thomas Roessler <[email-masked]>
Cc: Michael Young <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

> On 2003-01-22 14:30:48 -0500, Michael Young wrote:

> > This only seems useful if you convince *forward-looking* user
> > agents to adopt it, for the benefit of those using naive user
> > agents.  That seems unlikely, as many of them have picked up on
> > PGP/MIME, and would view this as a step backwards.  But I'm happy
> > for you to write it up.

> Maybe I should explain the rationale somewhat more.  First of all,
> with mutt, we generally try to parse things as late as possible --
> scanning text/plain for signs of encrypted or signed material is an
> action which explicitly has to be triggered by the user.  From that
> point of view, having a separate content type is certainly the thing
> to do.

> On the other hand, we had lots of complaints when we were using an
> application/ content type for inline PGP messages (from those who
> insisted in sending and receiving inline messages).  So we were
> looking for a way to generate inline messages which can (1) be
> handled by users with pgp-agnostic user agents, and (2) be
> recognized as PGP-messages early in the parsing process.  A MIME
> parameter for text/plain looked like an easy way to do this.

The default handling rules for unknown application types are very different
from those for unknown text subtypes. It seems to me that the default for text
subtypes is more or less what you want.

Of course not all user agents follow the rules for either one. But this will
hold true for any trick you use. For example, there's a popular user agent that
can fail in the presence of unexpected media type parameters. (Specifically,
its an older agent used in Japan that's sensitive both to unknown parameters
and parameter ordering, both entirely contrary to the MIME specification.)

Another example is how the original deployment of MIME was hindered by the
presence of agents that removed headers they did not recognize, such as
content-type or content-transfer-encoding.

There's a point where you have to say "enough" and move forward anyhow.
The real question is where that point lies.

				Ned

Date: Sat, 25 Jan 2003 15:05:08 -0800 (PST)
From: [email-masked]
Subject: Re: let's look...  Re: Standardizing inline PGP for e-mail?
To: Cyrus Daboo <[email-masked]>
Cc: Michael Young <[email-masked]>, [email-masked]
Sender: [email-masked]

> Hi Michael,

> --On Friday, January 24, 2003 01:53:29 PM -0500 Michael Young

> | The main reason we went down the subtype path was that Ned balked at
> | using text/plain with extra tags.  (Thomas suggested the tags to let
> | in-the-know MUAs take automatic action, and Ned balked there, too.)
> | Experimenting with subtypes was a fine idea, but it hasn't been a
> | complete success.  I'm happy to back off to text/plain, and I'm happy
> | with the extra tags.

> One alternative, that may or not be as controversial as adding parameters
> to Content-Type, would be to add a parameter to Content-Disposition
> instead, e.g.:

> Content-Disposition: inline; signed=pgp

This isn't what content-disposition parameters are for either: They are
supposed to be used to elaborate on the chosen disposition, in a fashion
similar to how media type parameters elaborate on the media type.

Another approach would be to make this a new content-disposition, however, the
default semantics of an unknown disposition (treat as attachment) are nowhere
near as good as the default semantics for an unknown text subtype (show or
offer to show the data to the user). There's also the issue that existing
dispositions seem largely (but not entirely) orthogonal to whether or not the
object is clearsigned.

> This has the benefit of leaving Content-Type as-is, and its also easily
> accessible to IMAP clients via the IMAP BODYSTRUCTURE response, removing
> the need for such clients to retrieve individual MIME part headers, which
> they would otherwise have to do if some X-Content header were used. The
> argument against this is that this change may be against the original
> design for Content-Disposition.

It is not, however, something existing client dispatch mechanisms are likely to
support. Support for dispatch based on media type is widely supported.

> So there are five alternatives to choose from:

> 1) Do nothing (actually promote better support/understanding for PGP/MIME)

I note that several people appear to favor this approach. I certainly have
no problem with this choice.

> 2) Add a parameter to Content-Type

I find this unacceptable for the multiple reasons I've already given.

> 3) Use a different text subtype for Content-Type

This is the approach I favor.

> 4) Add a parameter to Content-Disposition

This has many of the same problems as adding a new content type parameter.

> 5) Add a new MIME part header

Yuck.

				Ned

Subject: Re: let's look...  Re: Standardizing inline PGP for e-mail?
From: "Adrian 'Dagurashibanipal' von Bidder" <[email-masked]>
To: [email-masked]
Organization: 
Date: 25 Jan 2003 15:09:13 +0100
Sender: [email-masked]

--=-rDQ6as0TgwxSPCatqMD0
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Fre, 2003-01-24 at 22:35, Cyrus Daboo wrote:

> One alternative, that may or not be as controversial as adding parameters=
=20
> to Content-Type, would be to add a parameter to Content-Disposition=20
> instead, e.g.:

Hmmm. While it's not so nice to access via IMAP, and it's conceptually
not so elegant, why not add an extra header?=20

X-PGP-Data: clearsigned=20
or
X-PGP-Data: encrypted

We get
 + no MIME parser gets confused, situation will be no worse than it is
now
 + many MUAs allow extra headers to be added to messages with little
effort. So, people could use this even if their mailer doesn't.
 + same, for incoming mail: procmail and formail are your friends, so if
your MUA supports this you can view (almost) all inline signed msgs
 - needs special casing in the MUA when parsing a message. But inline
pgp needs special casing anyway, so it's probably still better than
status quo.

The idea to standardise to utf-8 may still be a good one, but I feel
it's not necessary as long as both gpg and sending MUA have the same
opinion of the charset used (and declare it, too).

cheers
-- vbi

--=20

--=-rDQ6as0TgwxSPCatqMD0
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

Signature policy: http://fortytwo.ch/legal/gpg/email.20020822

--=-rDQ6as0TgwxSPCatqMD0--

Date: Fri, 24 Jan 2003 22:46:49 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Standardizing inline PGP for e-mail?
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Fri, Jan 24, 2003 at 07:17:09PM -0800, [email-masked] wrote:

> > FWIW, there is a standards track precedence for Thomas' approach; the
> > RFC 2646 format=flowed parameter that modifies how text/plain is
> > rendered.
> 
> I did and do have deep misgivings about format=flowed; it treads dangerously
> close to the line and may indeed step a bit over it. But there's a huge
> difference between something that says "it is OK to wrap these lines for
> display" and something that says "Surprise! This is now structured material
> containing an elaborate security object that requires extensive processing in
> order to handle properly".

I don't know if I'd go that far.  Perhaps it is structured material,
but does it matter?  The client can perfectly legally just display it
to the user completely untouched with no processing at all.  The tag
seems more like a processing hint to me, which can be ignored by the
MUA.

David

-- 
   David Shaw  |  [email-masked]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson

Date: Fri, 24 Jan 2003 19:17:09 -0800 (PST)
From: [email-masked]
Subject: Re: Standardizing inline PGP for e-mail?
To: Simon Josefsson <[email-masked]>
Cc: [email-masked], Thomas Roessler <[email-masked]>, [email-masked]
Sender: [email-masked]

> [email-masked] writes:

> >> 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",
> >> "pgp-sign".
> >
> > 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.

> FWIW, there is a standards track precedence for Thomas' approach; the
> RFC 2646 format=flowed parameter that modifies how text/plain is
> rendered.

I did and do have deep misgivings about format=flowed; it treads dangerously
close to the line and may indeed step a bit over it. But there's a huge
difference between something that says "it is OK to wrap these lines for
display" and something that says "Surprise! This is now structured material
containing an elaborate security object that requires extensive processing in
order to handle properly".

The two cases really aren't at all comparable IMO.

				Ned

Date: Fri, 24 Jan 2003 23:53:42 +0100
From: Marc Mutz <[email-masked]>
Subject: Re: let's look...  Re: Standardizing inline PGP for e-mail?
To: [email-masked]
Organization: KDE
Sender: [email-masked]

--Boundary-02=_EQcM+Gzft5cr8/P
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Description: signed data
Content-Disposition: inline

On Thursday 23 January 2003 00:54, Thomas Roessler wrote:
<snip>
> This message contains inline PGP material tagged as text/x-pgp.
<snip>

KMail (1.5.x) displays it as if it was t/p.

Marc

=2D-=20
It's good fortune for the government that the masses don't think.
                                                         -- Adolf Hitler

--Boundary-02=_EQcM+Gzft5cr8/P
Content-Type: application/pgp-signature
Content-Description: signature

--Boundary-02=_EQcM+Gzft5cr8/P--

Date: Sat, 25 Jan 2003 00:00:56 +0100
From: Marc Mutz <[email-masked]>
Subject: Re: Standardizing inline PGP for e-mail?
To: [email-masked]
Organization: KDE
Sender: [email-masked]

--Boundary-02=_oWcM+83vJe590gE
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Description: signed data
Content-Disposition: inline

On Wednesday 22 January 2003 20:30, Michael Young wrote:
<snip>
> > 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.
<snip>
> (I also wouldn't call this an operational change to how PGP signs
> things -- the actual signing doesn't change.  We're simply talking
> about the MIME wrapping done by the mail user agent.)
<snip>

It _is_ an operational change, since the "pre-draft" proposes to label=20
utf-8 data with us-ascii. MUAs will not be prepared to decode UTF-8=20
when the Content-Type says "us-ascii"...

Marc

=2D-=20
They [RIAA,MPAA] are trying to invent a new crime:
interference with a business model.
                           --Bruce Schneier, Crypto-Gram 08/2002

--Boundary-02=_oWcM+83vJe590gE
Content-Type: application/pgp-signature
Content-Description: signature

--Boundary-02=_oWcM+83vJe590gE--

Date: Fri, 24 Jan 2003 16:35:31 -0500
From: Cyrus Daboo <[email-masked]>
To: Michael Young <[email-masked]>, [email-masked]
Subject: Re: let's look...  Re: Standardizing inline PGP for e-mail?
Sender: [email-masked]

Hi Michael,

--On Friday, January 24, 2003 01:53:29 PM -0500 Michael Young 
<[email-masked]> wrote:

| The main reason we went down the subtype path was that Ned balked at
| using text/plain with extra tags.  (Thomas suggested the tags to let
| in-the-know MUAs take automatic action, and Ned balked there, too.)
| Experimenting with subtypes was a fine idea, but it hasn't been a
| complete success.  I'm happy to back off to text/plain, and I'm happy
| with the extra tags.

One alternative, that may or not be as controversial as adding parameters 
to Content-Type, would be to add a parameter to Content-Disposition 
instead, e.g.:

Content-Disposition: inline; signed=pgp

This has the benefit of leaving Content-Type as-is, and its also easily 
accessible to IMAP clients via the IMAP BODYSTRUCTURE response, removing 
the need for such clients to retrieve individual MIME part headers, which 
they would otherwise have to do if some X-Content header were used. The 
argument against this is that this change may be against the original 
design for Content-Disposition.

So there are five alternatives to choose from:

1) Do nothing (actually promote better support/understanding for PGP/MIME)
2) Add a parameter to Content-Type
3) Use a different text subtype for Content-Type
4) Add a parameter to Content-Disposition
5) Add a new MIME part header

-- 
Cyrus Daboo

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Re: let's look...  Re: Standardizing inline PGP for e-mail?
Date: Fri, 24 Jan 2003 13:53:29 -0500
Sender: [email-masked]

From: "David Shaw" <[email-masked]>
> On Fri, Jan 24, 2003 at 11:08:25AM -0500, Michael Young wrote:
> > David Shaw wrote:
...
> I think we've seen in this thread that the "lite" form is not
> displayed at all in agents that don't support it.

That's an overstatement.  Several MUAs handled it just fine (and
mutt is clearly going to be changed in the process, so it will also).
(The only failure I saw was Outlook XP, but I may have missed something.)

But, I missed that you were talking specifically about the subtype idea...

> Thomas' original suggestion to use UTF8 encoding along with text/plain
> works very nicely on several levels.  First, it works without forcing
> the MUA author to do anything.  Second, in most cases even if MUA "A"
> does it slightly wrong (say, not doing the UTF8), MUA "B" can still
> handle it.  It's simple.  It works.  Where is the problem?

The main reason we went down the subtype path was that Ned balked at
using text/plain with extra tags.  (Thomas suggested the tags to let
in-the-know MUAs take automatic action, and Ned balked there, too.)
Experimenting with subtypes was a fine idea, but it hasn't been a
complete success.  I'm happy to back off to text/plain, and I'm happy
with the extra tags.

Date: Fri, 24 Jan 2003 09:42:42 -0800 (PST)
From: Len Sassaman <[email-masked]>
To: Thomas Roessler <[email-masked]>
Cc: <[email-masked]>
Subject: Re: let's look...  Re: Standardizing inline PGP for e-mail?
Sender: [email-masked]

On Thu, 23 Jan 2003, Thomas Roessler wrote:

> > Thanks for that suggestion.  Will look into it.
>

This works just fine with pine/pgpenvelope (which gives enormous headaches
with PGP/MIME or application/pgp).

Date: Fri, 24 Jan 2003 12:03:27 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: let's look...  Re: Standardizing inline PGP for e-mail?
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Fri, Jan 24, 2003 at 11:08:25AM -0500, Michael Young wrote:

> David Shaw wrote:
> The point is that the "lite" form is displayed reasonably even in
> agents that don't "support" it.  They show it as text.  When
> confronted with multipart/signed, some agents display the pieces
> as attachments or not at all; this makes reading the text painful,
> and verifying the signature manually even more so.

I think we've seen in this thread that the "lite" form is not
displayed at all in agents that don't support it.

There will always be some email client that can't handle the new
content-type.  One of the main complaints about PGP/MIME is that it
does not degrade well, and this has the same problem.  Even mutt,
(which Thomas should know well ;)), had a problem with his test mail
until I went in and mucked with the configuration.  Why go out of our
way to make regular clearsigned messages more confusing and much more
likely to Just Not Work for fiddling reasons that are going to be
different on every single mailer?

Getting fancy here feels good and we can produce all sorts of
interesting documents that most MUA writers will ignore, and argue
about little details until we are blue in the face, but it does not
fix the actual problem we're having in the real world.

Thomas' original suggestion to use UTF8 encoding along with text/plain
works very nicely on several levels.  First, it works without forcing
the MUA author to do anything.  Second, in most cases even if MUA "A"
does it slightly wrong (say, not doing the UTF8), MUA "B" can still
handle it.  It's simple.  It works.  Where is the problem?

David

-- 
   David Shaw  |  [email-masked]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson

To: [email-masked]
Subject: Re: let's look...  Re: Standardizing inline PGP for e-mail?
From: [email-masked]
Date: Fri, 24 Jan 2003 10:50:02 -0600
Sender: [email-masked]

--=_mixed 005C76C286256CB8_=
Content-Type: multipart/alternative; boundary="=_alternative 005C76C286256CB8_="

--=_alternative 005C76C286256CB8_=
Content-Type: text/plain; charset="us-ascii"

--John

        To:     [email-masked]
        cc: 

cheers
-- vbi

--=_alternative 005C76C286256CB8_=
Content-Type: text/html; charset="us-ascii"

<br><font size=2 face="sans-serif">FWIW, Lotus Notes displayed this message with an attachment for the signature.</font>
<br><font size=2 face="sans-serif">I have no idea how to verify it. &nbsp;I suppose I would have to paste the content and the signature into a text file, mark up the -----BEGIN PGP etc. delimiter lines, and then try? &nbsp;</font>
<br>
<br><font size=2 face="sans-serif">--John</font>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>&quot;Adrian 'Dagurashibanipal' von Bidder&quot; &lt;[email-masked]&gt;</b></font>
<br><font size=1 face="sans-serif">Sent by: [email-masked]</font>
<p><font size=1 face="sans-serif">01/24/03 02:31 AM</font>
<br>
<td><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To: &nbsp; &nbsp; &nbsp; &nbsp;[email-masked]</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; &nbsp; &nbsp;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;Re: let's look... &nbsp;Re: Standardizing inline PGP for e-mail?</font></table>
<br>
<br>
<br><font size=2><tt>On Don, 2003-01-23 at 22:35, David Shaw wrote:<br>
&gt; I think in general that creating a new subtype of text to solve this<br>
&gt; problem is a non-starter. &nbsp;Part of the original problem was that not<br>
&gt; enough mailers supported PGP/MIME (or indeed, MIME in general)<br>
&gt; sufficiently well. &nbsp;I suspect that using a new subtype will eventually<br>
&gt; end up as &quot;PGP/MIME lite&quot; and will similarly not be supported.<br>
</tt></font>
<br><font size=2><tt>Additionally, specifying inline PGP could make Software vendors even<br>
more reluctant to support PGP/MIME properly. Why not make it absolutely<br>
clear that PGP/MIME is the only form of PGP in email mailers are<br>
supposed to use.<br>
</tt></font>
<br><font size=2><tt>inline pgp won't get worse as it is - but manpower should be directed<br>
into making PGP/MIME work, not into fixing inline pgp, imho.<br>
</tt></font>
<br><font size=2><tt>cheers<br>
-- vbi<br>
</tt></font>
<br><font size=2><tt>--<br>

featured link: http://fortytwo.ch/gpg/subkeys</tt></font>
<br>
<br>
--=_alternative 005C76C286256CB8_=--
--=_mixed 005C76C286256CB8_=
Content-Type: application/octet-stream; name="signature.asc"
Content-Disposition: attachment; filename="signature.asc"
Content-Transfer-Encoding: base64

LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IEdudVBHIHYxLjIuMSAoR05V
L0xpbnV4KQ0KQ29tbWVudDogZ2V0IG15IGtleSBmcm9tIGh0dHA6Ly9mb3J0eXR3by5jaC9ncGcv
OTIwODI0ODENCg0KaUhNRUFCRUNBRE1GQWo0dytjMHNHbWgwZEhBNkx5OW1iM0owZVhSM2J5NWph
QzlzWldkaGJDOW5jR2N2WlcxaA0KYVd3dU1qQXdNakE0TWpJQUNna1FpNlF4aStXbjk5WUs1QUNm
YzA2Znd0eG9xcElJcWVjaytxNXVIRXl2S2xjQQ0Kb0o0RTVvRFFBVjhibENkL0Rrakw0SFhjaEZj
Sg0KPWN5NVkNCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQ0KU2lnbmF0dXJlIHBvbGljeTog
aHR0cDovL2ZvcnR5dHdvLmNoL2xlZ2FsL2dwZy9lbWFpbC4yMDAyMDgyMg0K
--=_mixed 005C76C286256CB8_=--

To: [email-masked]
Subject: Re: Standardizing inline PGP for e-mail?
From: [email-masked]
Date: Fri, 24 Jan 2003 10:29:01 -0600
Sender: [email-masked]

This is a multipart message in MIME format.
--=_alternative 005A8C5D86256CB8_=
Content-Type: text/plain; charset="us-ascii"

I use inline PGP messages in applications like Lotus Notes and web-based 
email that have no concept of PGP or MIME.  I can paste a coded ASCII 
Armored block into such a program and call it "text", and get my message 
through (privately).  The very fact that I'm using inline PGP implies that 
I can't do anything about the mail message headers!
--=_alternative 005A8C5D86256CB8_=
Content-Type: text/html; charset="us-ascii"

<br><font size=2 face="sans-serif">I use inline PGP messages in applications like Lotus Notes and web-based email that have no concept of PGP or MIME. &nbsp;I can paste a coded ASCII Armored block into such a program and call it &quot;text&quot;, and get my message through (privately). &nbsp;The very fact that I'm using inline PGP implies that I can't do anything about the mail message headers!</font>
--=_alternative 005A8C5D86256CB8_=--

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Re: let's look...  Re: Standardizing inline PGP for e-mail?
Date: Fri, 24 Jan 2003 11:08:25 -0500
Sender: [email-masked]

> end up as "PGP/MIME lite" and will similarly not be supported.

The point is that the "lite" form is displayed reasonably even in
agents that don't "support" it.  They show it as text.  When
confronted with multipart/signed, some agents display the pieces
as attachments or not at all; this makes reading the text painful,
and verifying the signature manually even more so.

For agents that do support PGP/MIME, yes, this is another thing
that they might want to understand.  If one doesn't, then it may
appear to have taken a step backward *when confronted with one
of these "lite" messages*.  A small step, in my opinion.

Once again, Thomas should correct me if I'm wrong, but I don't
think this is intended as a replacement, or even as a default.
It's an *option* for senders that know that they are sending to
receivers that can't (or don't want to) handle PGP/MIME.
It would just be nice if all the agents that offered such
an option did it the same way; that lets smart receivers still
get some of the benefit.

> clear that PGP/MIME is the only form of PGP in email mailers are

While it's possible that some vendor will choose to implement only the
"lite" form on the receiving side, I think it's far more likely
that they will implement neither, official PGP/MIME, or both.
The most likely implementors are people who've already built
PGP/MIME support.

If I believed Adrian's premise, then I might believe in enforcing
"the full standard or nothing at all", but I don't.  I might enforce
it if legacy agents weren't caused such grief.  But they are, and
I find it hard to stand on principle in the face of obvious pain.

From: "Richard Laager" <[email-masked]>
To: "'Dominikus Scherkl'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: let's look...  Re: Standardizing inline PGP for e-mail?
Date: Fri, 24 Jan 2003 09:20:04 -0600
Organization: Wikstrom Telecom Internet
Importance: Normal
Sender: [email-masked]

Dominikus Scherkl wrote:
> > Simon Josefsson wrote:
> > > > Things don't look well for Outlook. It displays the message
> > > > as a text attachment.
> > > 
> > > Maybe it needs a Content-Disposition: inline.  Does this
> > > message render better?
> > 
> > Nope. It still shows as a text attachment.
> 
> ?!?
> What Outlook version (or configuration?!?) do you use?

Outlook XP, a.k.a. Outlook 2002 (10.3513.3501) SP-1

> With mine it works fine (and our Plug-In Crypto-Ex has no
> problem to verify the signature).

Richard Laager

Subject: RE: let's look...  Re: Standardizing inline PGP for e-mail?
Date: Fri, 24 Jan 2003 11:30:27 +0100
Content-Class: urn:content-classes:message
From: "Dominikus Scherkl" <[email-masked]>
To: "Richard Laager" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

> Simon Josefsson wrote:
> > > Things don't look well for Outlook. It displays the message as a
> > > text attachment.
> > 
> > Maybe it needs a Content-Disposition: inline.  Does this message
> > render better?
> 
> Nope. It still shows as a text attachment.

?!?
What Outlook version (or configuration?!?) do you use?
With mine it works fine (and our Plug-In Crypto-Ex has no
problem to verify the signature).

Best regards.
-- 
Dominikus Scherkl
[email-masked]

Subject: Re: let's look...  Re: Standardizing inline PGP for e-mail?
From: "Adrian 'Dagurashibanipal' von Bidder" <[email-masked]>
To: [email-masked]
Organization: 
Date: 24 Jan 2003 09:31:10 +0100
Sender: [email-masked]

--=-bS/CV2WSjjwyHUwGyZM0
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

cheers
-- vbi

--=20

--=-bS/CV2WSjjwyHUwGyZM0
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

Signature policy: http://fortytwo.ch/legal/gpg/email.20020822

--=-bS/CV2WSjjwyHUwGyZM0--

Date: Thu, 23 Jan 2003 16:35:37 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: let's look...  Re: Standardizing inline PGP for e-mail?
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Anything that causes the equivalent of
 "cat message | gpg --clearsign | mail [email-masked]"
to no longer work well is not going to work out in the real world.  I
like the original suggestion far better (with or without the x-action:
tag) as it does not preclude the above pipeline.

David

-- 
   David Shaw  |  [email-masked]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson

From: "Richard Laager" <[email-masked]>
To: "'Simon Josefsson'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: let's look...  Re: Standardizing inline PGP for e-mail?
Date: Thu, 23 Jan 2003 13:40:11 -0600
Organization: Wikstrom Telecom Internet
Importance: Normal
Sender: [email-masked]

Simon Josefsson wrote:
> > Things don't look well for Outlook. It displays the message as a
> > text attachment.
> 
> Maybe it needs a Content-Disposition: inline.  Does this message
> render better?

Nope. It still shows as a text attachment.

Richard Laager

Date: Thu, 23 Jan 2003 06:43:38 -0800
To: [email-masked]
Cc: 
Subject: Re: let's look...  Re: Standardizing inline PGP for e-mail?
From: [email-masked]
Sender: [email-masked]

-----BEGIN PGP SIGNED MESSAGE-----

fwiw,

also, btw,

vedaal

To: [email-masked]
Cc: Thomas Roessler <[email-masked]>, [email-masked]
Subject: Re: Standardizing inline PGP for e-mail?
From: Simon Josefsson <[email-masked]>
Date: Thu, 23 Jan 2003 14:41:36 +0100
Sender: [email-masked]

[email-masked] writes:

>> 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",
>> "pgp-sign".
>
> 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.

FWIW, there is a standards track precedence for Thomas' approach; the
RFC 2646 format=flowed parameter that modifies how text/plain is
rendered.

To: "Richard Laager" <[email-masked]>
Cc: "'Thomas Roessler'" <[email-masked]>, <[email-masked]>
Subject: Re: let's look...  Re: Standardizing inline PGP for e-mail?
From: Simon Josefsson <[email-masked]>
Date: Thu, 23 Jan 2003 14:36:40 +0100
Sender: [email-masked]

"Richard Laager" <[email-masked]> writes:

>  
>> -----Original Message-----
>> From: [email-masked] 
>> [mailto:[email-masked]] On Behalf Of Thomas
>> Roessler Sent: Wednesday, January 22, 2003 5:55 PM
>> To: Michael Young; [email-masked]; [email-masked]
>> Subject: let's look... Re: Standardizing inline PGP for e-mail?
>
> Things don't look well for Outlook. It displays the message as a text
> attachment.

Maybe it needs a Content-Disposition: inline.  Does this message
render better?

Date: Thu, 23 Jan 2003 00:44:26 -0800
Subject: Re: Standardizing inline PGP for e-mail?
From: Jon Callas <[email-masked]>
To: Thomas Roessler <[email-masked]>, OpenPGP <[email-masked]>
Sender: [email-masked]

I'll summarize an opinion I've stated before.

The list of MUAs that handle OpenPGP/MIME correctly is very small. The list
of MUAs that handle plain old clear-signed messages is very large. The work
that needs to be done is in user software, not in RFCs.

    Jon

Date: Thu, 23 Jan 2003 16:32:51 +0900 (JST)
To: [email-masked]
Subject: Re: Standardizing inline PGP for e-mail?
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[email-masked]>
Sender: [email-masked]

From: Greg Troxel <[email-masked]>
Subject: Re: Standardizing inline PGP for e-mail?

> Given Ned's comments, how about "text/openpgp"?

I will support the text/openpgp (only for PGP clear signature, see
below) if proposed.

Note that the text/pgp approach was proposed several times (once
during standardizing RFC 2015, and several times after RFC 2015)
to maintain backward compatibility to both non-MIME-aware and 
MIME-aware-but-non-PGP/MIME-aware user agents.

My concern is that these proposals were always rejected by IETF
without reasons which make sense to me.

> This would specify the type of the content in the type, and whether
> the contents are a key block, encrypted message, signed message, or
> clearsigned message is already in the contents.

Please use subtypes of "application" for signed message and encrypted
message. We need to carefully consider character set issues for them.
Just saying "use UTF-8" does not solve situation at least in Japan.
Conversion from a traditional CJK character set to UTF-8 is quite
tough.

For PGP clear signature, we are free from this kind of character set
issues because the "charset" parameter tells. See the followin
example:

	Content-Type: text/openpgp; charset=iso-8859-1
	Content-Transfer-Encoding: quoted-printable

	Quoted-Printable(PGP clear signature in ISO-8859-1)

--Kazu

Date: Thu, 23 Jan 2003 06:55:06 +0100 (CET)
From: [email-masked]
Reply-To: [email-masked]
Subject: Re: let's look...  Re: Standardizing inline PGP for e-mail?
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

	/MaF

From: "Richard Laager" <[email-masked]>
To: "'Thomas Roessler'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: let's look...  Re: Standardizing inline PGP for e-mail?
Date: Wed, 22 Jan 2003 20:16:30 -0600
Organization: Wikstrom Telecom Internet
Importance: Normal
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Thomas
> Roessler Sent: Wednesday, January 22, 2003 5:55 PM
> To: Michael Young; [email-masked]; [email-masked]
> Subject: let's look... Re: Standardizing inline PGP for e-mail?

Things don't look well for Outlook. It displays the message as a text
attachment.

Richard Laager

Date: Wed, 22 Jan 2003 16:27:26 -0800
To: [email-masked]
From: Bill Frantz <[email-masked]>
Subject: Re: let's look...  Re: Standardizing inline PGP for e-mail?
Sender: [email-masked]

At 3:54 PM -0800 1/22/03, Thomas Roessler wrote:
>Hash: SHA1
>On 2003-01-22 23:37:54 +0100, Thomas Roessler wrote:
>
>> On 2003-01-22 13:29:07 -0800, [email-masked] wrote:
>
>> > I never suggested any such thing. What I suggest was a different
>> > subtype of text.
>
>> Thanks for that suggestion.  Will look into it.
>
>Thanks, and kind regards,
>- --
>Thomas Roessler                        <[email-masked]>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.1 (GNU/Linux)
>
>iQEVAwUBPi8vN9ImKUTOasbBAQL/iQgAvRAAcl/+s6dv9L3bo6LtJueHoZ3eR5KB
>iUnq9lAky5KO2cKG+giS7R2MeSSt4/BvWezPWoCyoQjMoJvIWR3+e8sOB3OoFZhU
>uJ+klrGP6LcXMeV0R1MOJ+pEEHVxEM8rHzcoEwaPkKCECC3WXg0c5R2PXNUO/723
>EnV9dgtDo7kxz6WOo8heXlEP/2lSa9ogbTRaBgs4cx+QBBVbAEmTvxmzu1Jbjfg+
>/WG/60lERXnnuJN3UE8nJcWMBJJKbacyijf4SaqX6PyknyGAr4FOIG7qguijIjpr
>OpGHOdNbyadpST9Y7tqDVfH5ubKwTNRvKLjZr2zOT40ipAvWr9fT6A==
>=CPvZ
>-----END PGP SIGNATURE-----

My Eudora 3.1 doesn't seem to have a problem with it.  On the other hand, I
don't see any MIME headers when I view the full message.

Cheers - Bill

-------------------------------------------------------------------------
Bill Frantz           | Sacred cows make the   | Periwinkle -- Consulting
(408)356-8506         | tastiest hamburgers.   | 16345 Englewood Ave.
[email-masked] |         - David Wagner | Los Gatos, CA 95032, USA

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Re: let's look...  Re: Standardizing inline PGP for e-mail?
Date: Wed, 22 Jan 2003 19:05:56 -0500
Sender: [email-masked]

Excellent idea...

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Re: Standardizing inline PGP for e-mail?
Date: Wed, 22 Jan 2003 18:58:38 -0500
Sender: [email-masked]

[email-masked] <[email-masked]> writes:
> This sure sounds like sophistry to me.

It wasn't intended as such.  The terms in the excerpt strongly
suggested display-oriented formatting to me.  It is certainly
not necessary to display the PGP clearsigned text specially in
order to express the appearance that the sender intended.

> And as it happens I'm the one who wrote this text. I can assure you that the
> intent was to ban the use of text/plain for formatted materials.

Thanks.  I apologize for my misinterpretation.

I really shouldn't have commented on the MIME specification at all.
It's not my specialty, as you have made clear.  But more importantly,
I don't think it's really the point.

I don't think that Thomas is trying to claim that this is either ideal
or strictly legal.  He appears to be documenting an actual
implementation of an extra-legal extension to solve a practical
problem in the hopes that others would adopt the same solution.  The
problem involves both non-MIME agents and MIME agents that handle
PGP/MIME badly, so it's no surprise that a purely MIME-compliant
solution may not be possible.

If I have misrepresented Thomas's intentions, perhaps he'll clarify.

> I never suggested any such thing. What I suggest was a different
> subtype of text.

My apologies.  Rereading your original note alone, that still isn't
clear to me, but that's my fault.

Perhaps others can comment on whether their user agents react
to text/something-else better than proper PGP/MIME.

Separately, "Greg Troxel" <[email-masked]> writes:
> I suppose it all comes down to one's opinion on whether it is
> reasonable to send PGP with a non-MIME-aware MUA.

I think it's a more a matter of wanting to send PGP-encoded
material to *receivers* that don't understand MIME or PGP/MIME,
and wanting the best possible display given their limitations,
all the while allowing PGP-aware agents to use the extra
formatting.

Date: Thu, 23 Jan 2003 00:54:31 +0100
From: Thomas Roessler <[email-masked]>
To: Michael Young <[email-masked]>, [email-masked], [email-masked]
Subject: let's look...  Re: Standardizing inline PGP for e-mail?
Mail-Followup-To: Michael Young <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

On 2003-01-22 23:37:54 +0100, Thomas Roessler wrote:

> On 2003-01-22 13:29:07 -0800, [email-masked] wrote:

> > I never suggested any such thing. What I suggest was a different
> > subtype of text.

> Thanks for that suggestion.  Will look into it.

Thanks, and kind regards,
- -- 
Thomas Roessler                        <[email-masked]>

Date: Wed, 22 Jan 2003 23:37:54 +0100
From: Thomas Roessler <[email-masked]>
To: Michael Young <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: Re: Standardizing inline PGP for e-mail?
Mail-Followup-To: Michael Young <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

On 2003-01-22 14:30:48 -0500, Michael Young wrote:

> This only seems useful if you convince *forward-looking* user
> agents to adopt it, for the benefit of those using naive user
> agents.  That seems unlikely, as many of them have picked up on
> PGP/MIME, and would view this as a step backwards.  But I'm happy
> for you to write it up.

Maybe I should explain the rationale somewhat more.  First of all,
with mutt, we generally try to parse things as late as possible --
scanning text/plain for signs of encrypted or signed material is an
action which explicitly has to be triggered by the user.  From that
point of view, having a separate content type is certainly the thing
to do.

On the other hand, we had lots of complaints when we were using an
application/ content type for inline PGP messages (from those who
insisted in sending and receiving inline messages).  So we were
looking for a way to generate inline messages which can (1) be
handled by users with pgp-agnostic user agents, and (2) be
recognized as PGP-messages early in the parsing process.  A MIME
parameter for text/plain looked like an easy way to do this.

On 2003-01-22 13:29:07 -0800, [email-masked] wrote:

> I never suggested any such thing. What I suggest was a different
> subtype of text.

Thanks for that suggestion.  Will look into it.

-- 
Thomas Roessler                        <[email-masked]>

Date: Wed, 22 Jan 2003 13:29:07 -0800 (PST)
From: [email-masked]
Subject: Re: Standardizing inline PGP for e-mail?
To: Michael Young <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

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

> Based on my reading of the RFC excerpt that Ned provided, I disagree,
> for clearsigned messages.  No interpretation is *necessary* for
> proper display -- an agent can simply show the whole mess.
> (The MIME charset header would apply, I presume.)

This sure sounds like sophistry to me.

And as it happens I'm the one who wrote this text. I can assure you that the
intent was to ban the use of text/plain for formatted materials. This was the
consensus at the time, and subsequent  abuse of the type have if anything
strengthened the validity of this take on things.

> Switching to yet another MIME multipart scheme won't help.

I never suggested any such thing. What I suggest was a different
subtype of text.

				Ned

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Re: Standardizing inline PGP for e-mail?
Date: Wed, 22 Jan 2003 14:30:48 -0500
Sender: [email-masked]

I use mail agents that are PGP/MIME-naive (including one that is
MIME-aware, but that makes PGP/MIME messages painful to read),
so I'm generally appreciative of what Thomas is trying to do here.
But, I'll admit I'm not a MIME specification expert.

Quotes are from <[email-masked]>,
> and "Thomas Roessler" <[email-masked]>

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

This only seems useful if you convince *forward-looking* user agents
to adopt it, for the benefit of those using naive user agents.  That
seems unlikely, as many of them have picked up on PGP/MIME, and would
view this as a step backwards.  But I'm happy for you to write it up.

Those of us using naive user agents will continue to clearsign by
hand.  (I'm in no position to inject any MIME tags manually.)

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

Based on my reading of the RFC excerpt that Ned provided, I disagree,
for clearsigned messages.  No interpretation is *necessary* for
proper display -- an agent can simply show the whole mess.
(The MIME charset header would apply, I presume.)

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

It seems that the point is to use a simple MIME type that can be
displayed by PGP/MIME-naive agents, or that are acceptable in places
that discourage complicated MIME messages (like some newsgroups
and mailing lists).

Switching to yet another MIME multipart scheme won't help.

(I also wouldn't call this an operational change to how PGP signs
things -- the actual signing doesn't change.  We're simply talking
about the MIME wrapping done by the mail user agent.)

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

Here, it may be fair to argue that this violates the plain/text
guidelines.  But, what's the harm, if that's what I really want my
agent to do in order to make (some of) my recipients happy?
Since some agents are going to do this technically-non-compliant
thing, Thomas is simply trying to reach agreement on how they do it.

To: Thomas Roessler <[email-masked]>
Cc: [email-masked]
Subject: Re: Standardizing inline PGP for e-mail?
From: Greg Troxel <[email-masked]>
Date: 22 Jan 2003 14:12:14 -0500
Lines: 27
Sender: [email-masked]

I'm not very clueful about MIME and I18N, so I post with some
trepidation.

Given Ned's comments, how about "text/openpgp"?
This would specify the type of the content in the type, and whether
the contents are a key block, encrypted message, signed message, or
clearsigned message is already in the contents.

It sounds like for messages which are in ASCII, the conversion to
UTF-8 is a no-op.

To me, part of the point of backwards compatibility is ensuring that
an MUA can deal with incoming messages of the form that have been
commonly sent for years.  emacs/mh-e/mailcrypt, for example, does not
insert any MIME headers at all.  So, it seems an MUA has to scan a
text/plain or a non-MIME message for PGP headers, and process it if
they are present.  Having messages tagged as the standard would make
it reasonable to make this either an explicit user command to process
untagged messages or an option that could be defaulted to off.

I suppose it all comes down to one's opinion on whether it is
reasonable to send PGP with a non-MIME-aware MUA.  I do this all the
time, and think it is a reasonable thing to want to do.  (Opinions on
a mh-e/RMAIL style interface that does PGP/MIME nicely are welcome
offlist.)

        Greg Troxel <[email-masked]>

Date: Wed, 22 Jan 2003 09:31:56 -0800 (PST)
From: [email-masked]
Subject: Re: Standardizing inline PGP for e-mail?
To: Thomas Roessler <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> 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",
> "pgp-sign".

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.

				Ned

Date: Wed, 22 Jan 2003 16:21:36 +0100
From: Thomas Roessler <[email-masked]>
To: [email-masked]
Subject: Standardizing inline PGP for e-mail?
Mail-Followup-To: [email-masked]
Sender: [email-masked]

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",
"pgp-sign".

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.

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.

What's gained by this?  You don't have to look at the contents of
body parts in order to identify PGP material, which saves you a lot
of time.  You don't have the complications with non-compliant mail
user agents which are caused by content types like application/pgp.
You avoid character set conversion confusions.

If there is any interest in documenting this as an RFC, I'd be
willing to do the drafting.

Regards,
-- 
Thomas Roessler                        <[email-masked]>