Subject: PGP/MIME: encoding restrictions.

From: Thomas Roessler <[email-masked]>
Date: Sun, 16 Jul 2000 12:30:00 +0200

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

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

It should, and I believe the following would be the most
robust solution:

(1) require clients to create text mode signatures
(2) require clients to use either quoted-printable or
    base64 for any body parts which contain trailing
    whitespace.

Note that this seems to be what most clients do anyway at
present.

Rationale: MIME has been carefully designed in a way which
makes sure that all essential information makes it through
gateways which tamper with trailing whitespace.  Thus, we
should make sure that PGP/MIME signed messages don't lose
any information on such paths, either.

Not losing any information in the signed body is
guaranteed by the use of qp/base64, whenever trailing
whitespace is present.

Not unnecesarily invalidating signatures is guaranteed by
the use of text-mode signatures, since these signatures
will ignore any trailing whitespace.  Note that this
trailing whitespace must be ignored by standard-conforming
decoders for qp/base64, too, and doesn't carry any meaning
in RFC822 (think about message/rfc822 attachments) or MIME
headers, so signature verification will fail if and only
if actual content has been modified.

Binary-mode signatures would also be invalidated if
trailing whitespace is tampered with, even though it
doesn't carry any meaning to the MIME encoding used.

Comments?

-- 
Thomas Roessler              <[email-masked]>

---

From: Ian Bell <[email-masked]>
Date: Tue, 18 Jul 2000 09:42:58 +0100

>Note that this seems to be what most clients do anyway at

[snip rationale]

This also satisfies the design objective of RFC1847 for single-pass
processing of the hashes (whether or not there are clients that rely on
that) without inventing new parameters.

I would suggest:
        clients MUST create text mode signature
though  clients MAY verify binary-mode signatures

However, I'm not so sure about (2). At most:

        clients SHOULD use qp or base64 whenever there is significant
        white space (i.e. _not_ MUST).

The cost of not using qp is that trailing whitespace is not protected,
but if clients have "good" reasons for not using qp they should be
allowed to consider that option.

For example, in draft-ietf-usefor-article-02 (USEFOR) it says "Posting
agents SHOULD NOT use the encoding method quoted-printable". Since
USEFOR articles will usually contain trailing whitespace (personal
signatures MUST be delimited by "-- "), clients will be unable to post
RFC2015bis articles to UseNet without breaking one RFC or another.

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

---

From: Thomas Roessler <[email-masked]>
Date: Tue, 18 Jul 2000 11:39:14 +0200

On 2000-07-18 09:42:58 +0100, Ian Bell wrote:

> For example, in draft-ietf-usefor-article-02 (USEFOR)
> it says "Posting agents SHOULD NOT use the encoding
> method quoted-printable". Since USEFOR articles will
> usually contain trailing whitespace (personal
> signatures MUST be delimited by "-- "), clients will be
> unable to post RFC2015bis articles to UseNet without
> breaking one RFC or another.

If you happen to be on the USEFOR list, it would be nice
if you could ask them to add an exception for
cryptographically signed messages just like the one in the
"text/plain; format=flowed" RFC.  After all, a restriction
like the one you quote only makes sense in a context where
MIME is avoided.  People using multipart/signed bother
recipients with MIME anyway, so the
content-transfer-encoding of the text transmitted isn't
really an issue any more.