Subject: bis04

From: Werner Koch <[email-masked]>
Date: Mon, 15 Apr 2002 16:35:02 +0200

Hi!

The latest draft dropped a paragraph from 2.4:

  Note that many applications, particularly messaging applications,
  will want more advanced features as described in the OpenPGP-MIME
  document, RFC2015. An application that implements OpenPGP for
  messaging SHOULD implement OpenPGP-MIME.

I might have missed it but I can't remember that we agreed on this.  I
don't want to repeat the pros and cons here as we discussed this far
too often.  

Removing this requirement is a bad thing because a reader might get
the impression that PGP/MIME had been consired to be a failed idea.
This is definitely not the case and can't stress enough how important
PGP/MIME is.  The fact that some mail clients are not able to support
it is a pitty but not a reason to drop PGP/MIME.

U.S. centric programmers didn't care about 8 bit cleanness for many
many years and users all over the rest of the world had to suffer with
this problem.  Don't let this happen again by suggesting the use of
PGP-armor.

Thanks for releasing the draft, Jon.

  Werner

---

From: Jon Callas <[email-masked]>
Date: Mon, 15 Apr 2002 17:38:13 -0700

>it is a pitty but not a reason to drop PGP/MIME.

I wrote a grumpy note earlier this year about this issue.

The reason I dropped it is because some implementers claim that base
OpenPGP with armoring is deprecated. This is *not* the case.

I support OpenPGP/MIME. I think it's a great idea. But I am sick of not
being able to verify messages because some implementers think that
OpenPGP/MIME is the only way to go.

I support anyone who puts in MIME encoding as an *option*. It isn't mandatory.

The problem is that some people don't understand the difference between
SHOULD-implement and SHOULD require all users to use. Our illustrious area
directors have gone on long dissertations about the difference between
implementing and forcing users to use.

If an implementer who politically wants to support the cause of security
multiparts chooses to do so, more power to them. But when the implementer
responds to people who want to do armoring with, "Hey, don't complain to
me, complain to the standards guys who *FORCE* me to do it" (which someone
has said to me and other people), then we part company. And since I'm the
aforementioned standards guy who allegedly is holding a gun to said
developer's head, I can do something about it.

I thought long and hard about just the right thing to say that would say
"I'm okay, you're okay" and couldn't come up with one. So I thought nothing
was the best thing to say. After all, this is the *format* document. It
lays out the bits. If an implementer wants to receive 3DES but never emit
anything but AES, that's their choice. Similarly, if an implementer wants
to always emit OpenPGP/MIME, that's their choice. But I don't want to be
holding the bag for either of them.

If you can come up with wording that says MIME is great, but so is
armoring, send it and I'll look at it.

>Thanks for releasing the draft, Jon.

You're welcome.

	Jon

---

From: Thomas Roessler <[email-masked]>
Date: Tue, 16 Apr 2002 09:16:38 +0200

On 2002-04-15 17:38:13 -0700, Jon Callas wrote:

>The reason I dropped it is because some implementers claim that 
>base OpenPGP with armoring is deprecated. This is *not* the case.

With all due respect, OpenPGP with armoring gets you into all kinds  
of hell as soon as you want to sign more than just us-ascii text,  
and as soon as you want to verify the signature on a system  
different from the one the signature was created on.  This is, in  
particular, the case when users have to feed PGP with a recoded 
version of the message.  Such recoding may be necessary in order to 
properly display the message to you.

Here's a test - this message is encoded in utf-8, it's clearsigned,  
and here is a number of special characters: € ä ö ü æ ç

Using widespread Windows software, can you find a messaging program 
which (1) verifies the signature AND (2) correctly displays the 
special characters (Euro symbol, a-umlaut, o-umlaut, u-umlaut, ae 
ligature, c-cedilla)?  Please tell us.

>armoring, send it and I'll look at it.

How about this?

	Note: A specification for using MIME to encapsulate OpenPGP  
	signed or encrypted messages, and for signing and encrypting 
	complex MIME objects with OpenPGP, can be found in RFC 3156.

I'll send a separate message with somewhat more on the character
set issues later today.

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

---

From: "vedaal" <[email-masked]>
Date: Tue, 16 Apr 2002 09:31:21 -0400

- ----- Original Message -----
From: "Thomas Roessler" <[email-masked]>
To: "Jon Callas" <[email-masked]>
Cc: "Werner Koch" <[email-masked]>; <[email-masked]>
Sent: Tuesday, April 16, 2002 3:16 AM
Subject: Re: bis04
...
> ligature, c-cedilla)?  Please tell us.
...
could not verify your signature, but could see the special characters,
have been able to both verify signatures and display special characters,
using the very common
OE 5.5 set to allow utf-8 encoding

vedaal

n.b.
the above message was done in OE 5.5, displayed the special characters, and
verified the signature
vedaal

---

From: Thomas Roessler <[email-masked]>
Date: Tue, 16 Apr 2002 15:47:51 +0200

On 2002-04-16 09:31:21 -0400, vedaal wrote:

>the above message was done in OE 5.5, displayed the special 
>characters, and verified the signature vedaal

Well, I was, however, unable to verify your signature, using mutt.

--

---

From: Paul Holman <[email-masked]>
Date: Thu, 18 Apr 2002 21:28:25 -0700

Just confirmation, I finally performed this test, and my experience 
mirrors Jon's.  I use Mail.app on MacOS X which I suppose is uncommonly, 
multilinguistically savvy, it displayed all the characters correctly.  
GnuPG and the associated plugin handled the signature fine.

pablos.

On Tuesday, April 16, 2002, at 12:16 AM, Thomas Roessler wrote:

>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
>
> iQEVAwUBPLvP1dImKUTOasbBAQKr6wgAwHjiE9UzYcSvhQjmFyj4Fq34S54UmOKR
> RrF70Ecuofy77GrLapkqybhMdKlxobrncoTVE3QLnXwhvaaHD+9JIycUeu07h2nI
> ce1KBZei1CJDq0J8LY81lLAIcrOQFtkporpBKITqNdaN/AUTKOfTD+5pT+D8PWq7
> EaAP8ZXyvr4Ydswx1u1cPNM5Y79bZCsmnpaJuwqPSM8XMo6+x8FFS6lKtiZuVazP
> eoKcE1PF+UU4/hEh/FB3ypivgmykwSIAOJmSaztZr/Rrf8OWaUxodZTL6Y1lz0aJ
> FoOmlZDEsiUcvw2VOA+Nh5sM+Fc+EcSVm1SGNrQs1V70ZbZJK5yqZw==
> =LZ1m
> -----END PGP SIGNATURE-----
>