Thought I'd clarify:
At 11:23 AM 14/04/2001 +0200, Thomas Roessler <roessler(_at_)does-not-exist(_dot_)org>
wrote:
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.
<snip>
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.
<snip>
The reason for this lies in the definition of a text-mode signature
in RFC 2440 [OpenPGP]
<snip>
Now, the processing rules for multipart/signed make sure that line
feeds are canonical before they hit the signing engine.
ie, trailing white space is included.
<snip>
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.
<snip>
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.
This is important for 7-bit relays...
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.
True, if the raley server can only handle 7-bit ASCII
<snip>
When applying such (unnecessary) transformations to 8bit messages in
on-the-wire-format (which would inevitably happen when a
multipart/signed is verified or generated), interoperability will,
of course, be ruined.
This comment regards various character sets...
Restricting the signed material to 7bit data also helps to make
signature generation and verification more robust against such
problems, and implementations considerably simpler.
True.
For all these reasons, I urge the Usenet format working group to
remove the reference to multipart/signed from section 6.21.3.
Ditto.
Regards
Erron Criddle
Comasp Ltd.
Level 2, 45 Stirling Hwy
NEDLANDS WA 6009
Australia
Fax: +61 8 9386 9473
Tel: + 61 8 9386 9534
http://www.comasp.com
ejc(_at_)comasp(_dot_)com