This discussion seem to have degenerated into
Thomas Roessler <roessler(_at_)does-not-exist(_dot_)org> writes:
I'm writing as one of the co-authors of
draft-ietf-openpgp-mime-06, which is hoped to become the
successor of RFC 2015 (PGP/MIME) soon.
In section 6.21.3 of draft-*-article-04, you write the following:
In the same way, Content-Types requiring special processing for
their display, such as "application", "image", "audio", "video"
and "multipart/related" are discouraged except in groups
specifically intended (by policy or custom) to include them.
Exceptionally, those application types defined in [RFC 1847] and
[RFC 2015] for use within "multipart/signed" articles, and the
type "application/pgp-keys" (or other similar types containing
digital certificates) may be used freely but, contrary to [RFC
2015] and unless the article is intended to be sent by mail also,
the Content-Transfer-Encoding SHOULD be left as "8bit" (or "7bit"
as appropriate).
I consider this section harmful for various reasons.
First, it should be noted that problems with transmitting 8bit
content are not the only reason for which an agent implementing
PGP/MIME may elect to use quoted-printable or base64 as a body
part's encoding.
In particular, draft-ietf-openpgp-mime-06 specifies that the signed
material in a PGP/MIME multipart/signed entity MUST NOT include any
trailing whitespace. This may either be achieved by cutting off
trailing whitespace, or by protecting it with an appropriate
transfer encoding.
The reason for this lies in the definition of a text-mode signature
in RFC 2440 [OpenPGP], which is incompatible with the definition
used by traditional implementations (aka pgp version 2).
More precisely, a text-mode signature traditionally meant that any
line feed has to be canonicalized to CR LF before hashing. With
OpenPGP, trailing whitespace is additionally snipped. (That's the
kind of processing which has traditionally been applied to
clearsigned messages.)
Now, the processing rules for multipart/signed make sure that line
feeds are canonical before they hit the signing engine. With
traditional PGP, that meant that text-mode and binary-mode hashes of
the material would be identical. This is no longer valid with
OpenPGP, which has two consequences: (1) In order to determine what
hash is to be computed, a receiving agent would have to look at the
signature. This would break the possibility to process
multipart/signed in one pass. (2) In the presence of trailing
whitespace, text-mode signatures wouldn't be interoperable between
implementations using PGP 2 and OpenPGP implementations.
The best way to fix both problems is to make sure that no trailing
whitespace is present, by applying appropriate encodings. (With
text/plain; format=flowed, this will be something which is
encountered quite frequently.)
For this reason alone, mandating transparent encodings may not be
the best idea at this point.
It should also be noted it's impossible to convert a
multipart/signed entity which contains 8bit body parts to any 7bit
format without breaking the signature. (Remember that MIME
explicitly forbids nested MIME encodings: Recoding has to happen on
the leaf level of a nested MIME structure.)
This implies, that a multipart/signed entity wihich contains 8bit
body parts cannot be legally transported via Internet e-mail without
ruining the signature - be it as part of message/rfc822
encapsulation, be it as a direct attachment.
Finally, I'd like to warn you that signature generation and
verification interoperability may seriously be endangered by
allowing 8bit body parts in a multipart/signed.
More precisely, a multipart/signed body part may generally contain
textual data in various character sets - it may even contain a
nested multipart/mixed with text/plain subparts which bear different
character sets.
However, PGP signature generators and verifiers have traditionally
been expecting that they are presented with data in a local
character set when preparing text-mode signatures. For this reason,
signature generators and verifiers may attempt to recode data they
are presented with to whatever character set is considered to be
canonical (utf-8 with OpenPGP, iso-latin-1 or koi-8 with pgp 2).
When applying such (unnecessary) transformations to 8bit messages in
on-the-wire-format (which would inevitably happen when a
of course, be ruined.
Restricting the signed material to 7bit data also helps to make
signature generation and verification more robust against such
problems, and implementations considerably simpler.
For all these reasons, I urge the Usenet format working group to
remove the reference to multipart/signed from section 6.21.3.
--
Thomas Roessler
<roessler(_at_)does-not-exist(_dot_)org>