Subject: PGP/MIME: Time for last call?

From: Thomas Roessler <[email-masked]>
Date: Wed, 10 May 2000 12:32:54 +0200

Does anyone see a reason why we should not start getting
the OpenPGP/MIME and multipart/mixed signature drafts into
the RFC process?

-- 
http://www.guug.de/~roessler/

---

From: Ian Bell <[email-masked]>
Date: Thu, 11 May 2000 09:44:28 +0100

>the OpenPGP/MIME and multipart/mixed signature drafts into

Should the issue of binary versus text-mode signatures be addressed?

RFC1847 had the design objective of aiding single-pass signature
verification. To that end, it defined the micalg paramater so that the
client could pre-calculate the hash over the MIME data.

RFC2015 and RFC2015bis clients know what hash is required for the
signature, but they don't know what data has actually been hashed. The
line endings will always be CRLF because of the MIME canonicalization,
but trailing spaces may or may not be included in the hash depending on
the signature mode.

Possible improvements to openPGP/MIME could therefore be:

1) Simply state the problem, and indicate that for one-pass processing,
   two hashes will have to be prepared - one for binary-mode signatures
   and one for text-mode signatures.

2) Mandate which form of signature must be used. Trailing spaces are
   often significant in email/news (sig-seps, RFC2646), so a binary-mode
   signature might seem preferable. However, existing PGP/MIME clients
   may be using either.

3) Define a "pgp-mode" parameter, pgp-mode=binary or pgp-mode=text and
   ensure that new clients add the parameter to the multipart/signed
   header. If the parameter is missing (RFC2015 messages), then one-pass
   clients will have to prepare two hashes.

I feel that 3) is the most satisfactory fix to the problem, but that at
least 1) is incorporated into the draft before it is sent to last call.

-- 
Ian Bell                                           T U R N P I K E  Ltd

---

From: Florian Weimer <[email-masked]>
Date: 12 May 2000 16:46:10 +0200

Ian Bell <[email-masked]> writes:

[micalg parameter doesn't contain all information to precompute the hash]

> least 1) is incorporated into the draft before it is sent to last call.

Or 4): Drop the micalg parameter.  This will make one-pass processing
impossible, but I doubt that it's worth the trouble (unless the
theoretical possibility of one-pass processing is required by some
MIME standard).  Future revisions of the OpenPGP message standard
might specify additional hash algorithms (which might even require
some parameters); OpenPGP implementators might want to use proprietary
algorithms, and so on.  Synchronizing OpenPGP-MIME with these
developments is not very complicated, but I think the benifit of
having a micalg parameter is even too small for that.

-- 
Florian Weimer 	                  [email-masked]
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898
http://ca.uni-stuttgart.de:11371/pks/lookup?op=get&search=0xC06EC3B5

---

From: Thomas Roessler <[email-masked]>
Date: Fri, 12 May 2000 17:07:10 +0200

On 2000-05-12 16:46:10 +0200, Florian Weimer wrote:

> Synchronizing OpenPGP-MIME with these developments is
> not very complicated, but I think the benifit of having
> a micalg parameter is even too small for that.

Please note that the draft text already solves this:

| The "micalg" parameter for the "application/pgp-signature"
| protocol MUST contain exactly one hash-symbol of the
| format "pgp-<hash- symbol>", where <hash-symbol>
| identifies the Message Integrity Check (MIC) algorithm
| used to generate the signature. Hash-symbols are
| constructed from the text names registered in [1] or
| according to the mechanism defined in that document by
| converting the text name to lower case and prefixing it
| with the four characters "pgp-".

Ian: I'll come back to the issue you raised later.  I'll
have to check some things in 1847 for this.

---

From: Ian Bell <[email-masked]>
Date: Fri, 12 May 2000 16:33:16 +0100

On Fri, 12 May 2000, Florian Weimer <[email-masked]
Stuttgart.DE> wrote:
>MIME standard). 

The micalg parameter is a required parameter of RFC1847.
One-pass processing seems to have been a design-goal of RFC1847.

I think there are benefits deriving from the fact that openPGP/MIME is
based on RFC1847 which mean that the micalg parameter should not be
dropped.

(not least of which is that the multipart/mixed signature draft is
written in terms of multiple RFC1847 signatures, not multiple
openPGP/MIME signatures.)

---

From: Thomas Roessler <[email-masked]>
Date: Mon, 22 May 2000 13:14:29 +0200

On 2000-05-11 09:44:28 +0100, Ian Bell wrote:

> 1) Simply state the problem, and indicate that for
>    one-pass processing, two hashes will have to be
>    prepared - one for binary-mode signatures and one
>    for text-mode signatures.

> 2) Mandate which form of signature must be used.
>    Trailing spaces are often significant in email/news
>    (sig-seps, RFC2646), so a binary-mode signature
>    might seem preferable. However, existing PGP/MIME
>    clients may be using either.

> 3) Define a "pgp-mode" parameter, pgp-mode=binary or
>    pgp-mode=text and ensure that new clients add the
>    parameter to the multipart/signed header. If the
>    parameter is missing (RFC2015 messages), then
>    one-pass clients will have to prepare two hashes.

Well...  As a fourth possibility, we could mandate that
any trailing whitespace within body parts should lead to
the use of quoted-printable or base64, thus effectively
working around the problem.  However, this is _not_
currently mandated by RFC 1847.

Actually, doing this is suggested in one of the example
messages, but for different reasons.

---

From: Ian Bell <[email-masked]>
Date: Tue, 23 May 2000 09:31:21 +0100

>currently mandated by RFC 1847.

Mandating quoted-printable just as a workround for a sig-mode problem 
seems a little of a kludge - 3) still seems to me the solution that fits 
best with the aims of RFC1847.

[However, Turnpike already forces its PGP-signed messages into 
quoted-printable so that trailing-space corruption and Berkeley-From 
corruption problems are avoided]