Finalizing OpenPGP/MIME?

Thomas Roessler <roessler@does-not-exist.org> Thu, 18 January 2001 00:15 UTC

Received: from ns.secondary.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29457 for <openpgp-archive@odin.ietf.org>; Wed, 17 Jan 2001 19:15:21 -0500 (EST)
Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id PAA08960 for ietf-openpgp-bks; Wed, 17 Jan 2001 15:54:34 -0800 (PST)
Received: from smtp2.nikoma.de (smtp2.nikoma.de [212.122.128.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA08955 for <ietf-openpgp@imc.org>; Wed, 17 Jan 2001 15:54:29 -0800 (PST)
Received: from sobolev.does-not-exist.org (dialin100.pg5-nt.frankfurt.nikoma.de [213.54.36.100]) by smtp2.nikoma.de (8.9.3/8.9.3) with ESMTP id AAA32199; Thu, 18 Jan 2001 00:59:22 +0100 (CET) (envelope-from roessler@does-not-exist.org)
Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id A223C2ED13; Thu, 18 Jan 2001 00:58:33 +0100 (CET)
Date: Thu, 18 Jan 2001 00:58:33 +0100
From: Thomas Roessler <roessler@does-not-exist.org>
To: ietf-openpgp@imc.org
Cc: Ian Bell <ianbell@turnpike.com>, Michael Elkins <me@mutt.org>, Dave Del Torto <ddt@cryptorights.org>, Raph Levien <raph@acm.org>, John W Noerenberg II <jwn2@qualcomm.com>
Subject: Finalizing OpenPGP/MIME?
Message-ID: <20010118005833.A16813@sobolev.does-not-exist.org>
Mail-Followup-To: ietf-openpgp@imc.org, Ian Bell <ianbell@turnpike.com>, Michael Elkins <me@mutt.org>, Dave Del Torto <ddt@cryptorights.org>, Raph Levien <raph@acm.org>, John W Noerenberg II <jwn2@qualcomm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.3.13i
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

I suppose we should somehow bring OpenPGP/MIME to a decent end -
it's long overdue.

There haven't been any substantial changes for a long time, and the
only thing we still have to resolve in a decent way is that ugly
incompatibility with respect to canonical text signatures which
hurts us badly, since it does - among other things - ruin
one-pass-abilities for OpenPGP/MIME.  I don't think there is any
real solution to this problem (or does anyone here have a time
machine at hand?).  However, looking at the latest draft
(draft-ietf-openpgp-mime-02.txt), we should most likely document the
problem in detail.

For that reason, I'd propose the changes listed below for a
draft-*-03.txt.

To everyone: Please re-read draft-ietf-openpgp-mime-02.txt and
draft-ietf-openpgp-multsig-01.txt.  Please forward any concerns or
problems you have to this list, so we can get out new and -
hopefully - final drafts.

To the co-authors of these documents: Please verify the affiliations
listed for correctness.

Thanks, and a happy new year to everyone,
-- 
Thomas Roessler				    <roessler@does-not-exist.org>



--- draft-ietf-openpgp-mime-02.n	Thu Jan 18 00:31:00 2001
+++ draft-ietf-openpgp-mime-03.n	Thu Jan 18 00:45:15 2001
@@ -8,9 +8,9 @@
 .nr LT 7.2i
 .ds LF Elkins, et al.
 .ds RF FORMFEED[Page %]
-.ds CF Expires February 2001 
+.ds CF Expires July 2001
 .ds LH INTERNET-DRAFT
-.ds RH August 2000
+.ds RH January 2001
 .ds CH MIME Security with OpenPGP
 .ad l
 .in 0
@@ -28,7 +28,7 @@
 expand;
 lr.
 OpenPGP Working Group	M. Elkins
-draft-ietf-openpgp-mime-02.txt	Network Associates, Inc.
+draft-ietf-openpgp-mime-03.txt	Network Associates, Inc.
 Obsoletes: 2015	D. Del Torto
 	CryptoRights Foundation
 	R. Levien
@@ -142,7 +142,19 @@
 protect these body parts against corruption by transport or delivery
 agents.  Applying this rule also ensures that trailing whitespace in
 the data encoded cannot be modified without invalidating the
-signature.
+signature.  Applications SHOULD ensure that no trailing whitespace
+is present after the MIME encoding has been applied.
+.RS
+.pp
+Note: Trailing white space does not alter the actual contents of a
+Quoted-Printable or Base64 encoded body part, or the meaning of MIME
+headers. However, the presence of trailing white space may trigger a
+compatibility problem which was introduced in [1]: With traditional
+implementations of PGP, trailing whitespace was included with
+signatures of canonical text documents.  [1] changes this behaviour
+in an incompatible way, by specifying that trailing white space is
+ignored in signatures of canonical text documents.
+.RE
 .pp
 Data that is ONLY to be encrypted is allowed to contain 8-bit
 characters and therefore need not be converted to a 7-bit format.