Subject: Finalizing OpenPGP/MIME?

From: Thomas Roessler <[email-masked]>
Date: Thu, 18 Jan 2001 00:58:33 +0100

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				    <[email-masked]>

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

---

From: Florian Weimer <[email-masked]>
Date: 18 Jan 2001 13:57:15 +0100

Thomas Roessler <[email-masked]> writes:

> draft-ietf-openpgp-multsig-01.txt.

Suggestions for typographical corrections are prefixed with [T],
changes in wording with [W], changes to the specification with [S].

Generall:

[T] Use symbolic bibliographic references instead of bare numbers.
    (Makes reading easier.)

Section 1:

[T] Replace 'RFC 1847' with 'RFC 1847'. (Consistency)

Section 2:

[T] Replace 'multipart ASCII armor OpenPGP format' with
    'multi-part ASCII armor OpenPGP format' (cf. OpenPGP)

[S] Make MIME multipart mechanism in favor of OpenPGP multi-part messages
    REQUIRED.  (It is hard to imagine how OpenPGP multi-part messages can
    interoperate with other implementations.)

Section 5:

[S] Include wildcard value for "micalg" parameter.  (Makes generating
    OpenPGP/MIME messages much easier in some situations, but breaks
    one-pass processing, of course.  Today, the majority of
    OpenPGP/MIME installations/implementations doesn't deal correctly
    with this parameter anyway.)

Still Section 5, enumeration (2):

[T] Spell 'recommended' in capital letters.

[W] Replace 'mail transfer agents' with 'mail delivery agents' (or
    both).  In general, only MDAs touch messages in this way, not MTAs.

Still Section 5, example message:

[W] The signature on the example message doesn't seem to be valid (?).
    BITNET is dead.

Section 6.1:

[W] The signature on the example message is invalid.

Section 7:

[S] Neither OpenPGP nor OpenPGP/MIME specify the transfer format of
    public key blocks, so this section doesn't make much sense.

Section 10:

[T] Replace 'OP' with 'OpenPGP'.

-- 
Florian Weimer 	                  [email-masked]
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

---

From: Kazu Yamamoto (山本和彦) <[email-masked]>
Date: Mon, 22 Jan 2001 13:25:49 +0900 (JST)

From: Thomas Roessler <[email-masked]>
Subject: Finalizing OpenPGP/MIME?

> For that reason, I'd propose the changes listed below for a

Probably you know this, but I'm sending a message just in case.

The example in Section 5 has a minor bug:

----
         --bar

        Content-Type: application/pgp-signature
----

should read

----
         --bar
        Content-Type: application/pgp-signature
----

RFC 2015 also has an error in the example in Section 5. We should not
make the same mistake again.

--Kazu

---

From: Kazu Yamamoto (山本和彦) <[email-masked]>
Date: Mon, 22 Jan 2001 14:33:12 +0900 (JST)

> machine at hand?). 

Let me confirm. Can this problem be solved if we use the binary
signature?

--Kazu

---

From: Thomas Roessler <[email-masked]>
Date: Mon, 22 Jan 2001 12:13:08 +0100

If everyone would just be using binary signatures, the problem
wouldn't occur, right.  Bad enough, most current implementations
seem to rely on text-mode signatures.

Also, using the new text-mode signatures with the restrictions in
the draft actually has the nice side-effect of moving PGP/MIME
closer to one of the features found throughout MIME: Resistance
against tampering with trailing whitespace.  It's not really helpful
if changes which don't affect the message's contents are detected by
PGP/MIME.

(But, of course, if most people here feel that binary mode should be
used, we could still change the text.)

On 2001-01-22 14:33:12 +0900, Kazu Yamamoto wrote:
> Date: Mon, 22 Jan 2001 14:33:12 +0900 (JST)
> To: [email-masked]
> Cc: [email-masked], [email-masked], [email-masked],
> 	[email-masked], [email-masked], [email-masked]
> Subject: Re: Finalizing OpenPGP/MIME?
> From: Kazu Yamamoto (???????????) <[email-masked]>
> X-Mailer: Mew version 1.95b99 on Emacs 20.7 / Mule 4.1 (AOI)
>

---

From: Michael Elkins <[email-masked]>
Date: Mon, 22 Jan 2001 09:34:54 -0800

> used, we could still change the text.)

Can someone remind me what the difference between text mode and binary mode
signatures is?  We're always going to need to muck with the line endings, no
way around that.  But I don't see how that precludes one-pass processing if
your client is smart enough to canonicalize each line of text and pass it in
a pipe (or stream) to the OpenPGP engine.

me

---

From: Thomas Roessler <[email-masked]>
Date: Mon, 22 Jan 2001 19:13:22 +0100

On 2001-01-22 09:34:54 -0800, Michael Elkins wrote:

> Can someone remind me what the difference between text mode and
> binary mode signatures is?  We're always going to need to muck
> with the line endings, no way around that.  But I don't see how
> that precludes one-pass processing if your client is smart enough
> to canonicalize each line of text and pass it in a pipe (or
> stream) to the OpenPGP engine.

With traditional PGP, text mode just meant that you canonicalized
the line ends.  That is, RFC 2015 had one-pass abilities by
mandating canonicalization.

With OpenPGP, text mode means stripping trailing white space, and
then canonicalizing line ends.  So you'll have to compute two hashes
when going over the message.

(OpenPGP's concept of text mode is basically what traditional PGP
used for clearsigning.)

---

From: Derek Atkins <[email-masked]>
Date: 22 Jan 2001 13:54:23 -0500

In text-mode signatures, PGP will auto-canonicalize line-endings,
including removing any trailing white-space, whereas with binary the
canonicalization is not done and trailing white-space is included in
the signature.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: saku <[email-masked]>
Date: Wed, 24 Jan 2001 14:54:46 +0900

Hi everyone.

[From] Kazu Yamamoto (山本和彦) <[email-masked]>
[Date] Mon, 22 Jan 2001 14:33:12 +0900 (JST)
[Subject] Re: Finalizing OpenPGP/MIME?
[Message-id] <[email-masked]>
> Let me confirm. Can this problem be solved if we use the binary

I think that it is the best way.
However, UA using traditional PGP easily cannot make text mode 
signatur.

I think that it should be as follows.

====
  SHOUD sign by binary mode signatue.

  Note:
   When using traditional PGP, UAs MAY sign by text mode   
   signature after MIME transfer encoding (Base64, Quated-printable,
   etc).  But, that UA is called `weak agent in OpenPGP/MIME'.
====

-- 
saku (SAKUDA Yasunori)
 PGP-KeyID: 0x9C891697 (DH/DSS)
 PGP-FP: ABDE C7B9 F635 592A C9F4  AD13 020A 6654 9C89 1697

---

From: saku <[email-masked]>
Date: Wed, 24 Jan 2001 15:44:32 +0900

Hi everyone.

[From] Kazu Yamamoto <[email-masked]>
[Date] Mon, 22 Jan 2001 14:33:12 +0900 (JST)
[Subject] Re: Finalizing OpenPGP/MIME?
[Message-id] <[email-masked]>

====

  Note:

# sorry. <[email-masked]> is CT:ISO-2022-JP

---

From: Thomas Roessler <[email-masked]>
Date: Thu, 25 Jan 2001 10:26:12 +0100

> [T] Replace 'RFC 1847' with 'RFC 1847'. (Consistency)

ok.

>     'multi-part ASCII armor OpenPGP format' (cf. OpenPGP)

ok.

>     interoperate with other implementations.)

I don't think this REQUIRED actually is required.

>     with this parameter anyway.)

I don't think we should break one of the basic design goals of MIME.

> [T] Spell 'recommended' in capital letters.

Now in section 3, and I don't think we should make it a
capital-letters recommended.

>     both).  In general, only MDAs touch messages in this way, not MTAs.

"mail transfer and delivery agents"

> [W] The signature on the example message doesn't seem to be valid (?).

Consider this part of the example as a historical courtesy.

> [W] The signature on the example message is invalid.

Mhhhh.  Do these signatures really have to verify? ,-)

> [S] Neither OpenPGP nor OpenPGP/MIME specify the transfer format
>     of public key blocks, so this section doesn't make much
>     sense.

They don't sepcify the storage format, but section 10.1 of RFC 2440
describes transferable public keys.  It could, however, be argued
that the OpenPGP/MIME document should be a bit more specific about
what is expected in applications/pgp-keys.  Maybe like this?

  A MIME body part of this content type contains ASCII-armored
  Transferable Public Keys as defined in [1], section 10.1.

> [T] Replace 'OP' with 'OpenPGP'.

Thanks.

I suppose it's getting time for a new draft.  I'll submit one to
internet-drafts, and not consider it final. *sigh*

---

From: Werner Koch <[email-masked]>
Date: Thu, 25 Jan 2001 11:19:26 +0100

> I don't think we should break one of the basic design goals of MIME.

Agreed.  For historical reasons, micalg was always md5 and nobody
cared about it because it does not make sense. 

However, it is pretty easy to set micalg to the correct value, given
that a) it should nearly always be SHA1 today, b) that I know no
mail implementaion which creates a signed message without first
storing the entire message (and it does not make sense to create a
multi hundred megabyte signed email becuase the majority of MUAs
will not be able to handle them unless they have a huge swap space
and are alloed to use these amounts of memory) and c) that many MTAs
do limit the maximum size of a message for good reasons.

   Werner

-- 
Werner Koch                                              <[email-masked]>
GNU Privacy Guard                                (http://www.gnupg.org)
Free Software Foundation Europe              (http://www.fsfeurope.org)
           [Please see X-* mail header for OpenPGP key info]

---

From: Florian Weimer <[email-masked]>
Date: 25 Jan 2001 11:41:37 +0100

> Mhhhh.  Do these signatures really have to verify? ,-)

I think the examples should be complete and instructive.  Therefore,
the signatures should be valid.

> describes transferable public keys.

Oh, I missed it.  Thanks.

> It could, however, be argued that the OpenPGP/MIME document should
> be a bit more specific about what is expected in
> applications/pgp-keys.  Maybe like this?
> 

Perhaps you can refer to section 6.2 as well?

---

From: Florian Weimer <[email-masked]>
Date: 25 Jan 2001 11:57:38 +0100

Werner Koch <[email-masked]> writes:

[Implications of a wildcard micalg parameter]

> Agreed.

I wouldn't suggest that if I had not observed that the parameter isn't
set correctly by many users.

> that a) it should nearly always be SHA1 today,

Okay, that's certainly a point.  But there will always be a certain
percentage of PGP 2.6.x users (and according to some rumors, most
people who seriously use OpenPGP technology are in this category).
Maybe it's time for MD5 to finally die by the hands of the
cryptanalysts. ;-)

> b) that I know no mail implementaion which creates a signed message
> without first storing the entire message

The problem isn't that it's technically impossible to generate this
header.  Most OpenPGP implementations simply do not provide the
necessary data to the calling MUA while creating the signature.  (Of
course, you can extract it using 'gpg --list-packet', and in fact I
plan to add this to Gnus some day, but this seems to be rather
hackish.)

---

From: Kazu Yamamoto (山本和彦) <[email-masked]>
Date: Thu, 25 Jan 2001 20:12:05 +0900 (JST)

Werner, 

From: Werner Koch <[email-masked]>
Subject: Re: Finalizing OpenPGP/MIME?

> that

This is incorrect.

> a) it should nearly always be SHA1 today

Yes, but not 100%. It is difficult for PGP/MIME UAs, which don't know
PGP format, to set a CORRECT value to the micalg parameter in all
cases.

This is why I asked you to add the feature to GNUPG, that tells hash
function types to UAs so that the UAs can set them to the micalg
parameter. (Thank you for your implementation.)

Unfortunately, to my best knowledge, other PGP implementations don't
have such a feature. So, many PGP/MIME UAs tend to either
1) set a fix value (pgp-sha1 for example) to the micalg parameter
or
2) reply on PGP/MIME functionality of the PGP implementations.

I know this is not a PGP/MIME issue but a Multipart/Security issue.

And I would like to know how should Multipart/Security UAs treat a
received Multipart/Security message if the micalg parameter is
inconsistent with the hash function actually used.

--Kazu

---

From: Werner Koch <[email-masked]>
Date: Thu, 25 Jan 2001 12:39:33 +0100

> have such a feature. So, many PGP/MIME UAs tend to either

What they should do is to parse the beginning of the message.  Well,
okay than it is not anymore simple to implemnt it, becuase you need
a base64 decoder and some OpenPGP packet parsing code.

> inconsistent with the hash function actually used.

For PGP I would just ignore that parameter; don't know about S/MIME.

  Werner

---

From: Werner Koch <[email-masked]>
Date: Thu, 25 Jan 2001 12:52:24 +0100

> course, you can extract it using 'gpg --list-packet', and in fact I

The 

    SIG_CREATED <type> <pubkey algo> <hash algo> <class> <timestamp> <key fpr>
    
status output is available since June ;-)

---

From: Kazu Yamamoto (山本和彦) <[email-masked]>
Date: Thu, 25 Jan 2001 21:25:06 +0900 (JST)

Werner,

> a base64 decoder and some OpenPGP packet parsing code.

I know it is easy for you to implement a PGP parser. :-) Also, it is
not so difficult for me to do it. ;-)

Actually, I implemented a parser called "pgpdump". 
	ftp://pgp.iijlab.net/pub/tools/

# gpg --list-packet was not enough for me to visualize PGP packets.

Nonetheless, it is not so easy for many PGP/MIME programmers to embed
such PGP parser functionality to their MIME UAs.

> For PGP I would just ignore that parameter; don't know about S/MIME.

This is a point. This means that the micalg parameter is meaningless.
I wonder why we should make an effort to set a correct value to such a
meaningless value?

Or if you are suggesting just to set a bogus value to the micalg
parameter because it is meaningless, why don't you support the idea of
wildcard value?

P.S.

The micalg parameter and the protocol parameter bites me always.

--Kazu

---

From: Florian Weimer <[email-masked]>
Date: 25 Jan 2001 13:29:40 +0100

> status output is available since June ;-)

But it's not in the CVS HEAD branch, and I checked only that. ;-)

---

From: Kazu Yamamoto (山本和彦) <[email-masked]>
Date: Thu, 25 Jan 2001 22:00:34 +0900 (JST)

From: Florian Weimer <[email-masked]>
Subject: Re: Finalizing OpenPGP/MIME?

> But it's not in the CVS HEAD branch, and I checked only that. ;-)

At least, GNUPG 1.04 provides this feature. My UA relies on it.

--Kazu

---

From: Werner Koch <[email-masked]>
Date: Thu, 25 Jan 2001 13:59:32 +0100

> I wonder why we should make an effort to set a correct value to such a

I think it is good style to create data in a correct fashion but be
liberal in what to accept.

> parameter because it is meaningless, why don't you support the idea of

I won't object against a wildcard or a new value "unknown"

  Werner

---

From: Werner Koch <[email-masked]>
Date: Thu, 25 Jan 2001 15:02:53 +0100

> At least, GNUPG 1.04 provides this feature. My UA relies on it.

HEAD is the development branche and a lot of things did change.  I
known that I have to merge in the new stuff from STABLE-BRANCH-1-0.

  Werner

---

From: Kazu Yamamoto (山本和彦) <[email-masked]>
Date: Thu, 25 Jan 2001 23:49:21 +0900 (JST)

> liberal in what to accept.

Yes, of course. However, this is a signature service. I can't tell
whether such inconsistency is modification by a bad guy or just
composer's hard coding.

--Kazu

---

From: Thomas Roessler <[email-masked]>
Date: Tue, 30 Jan 2001 17:09:19 +0100

> Perhaps you can refer to section 6.2 as well?

I don't think that's necessary.  After all, ASCII-armor is being
referred to all over the text.