Subject: Re: draft-ietf-usefor-article-04.txt: 6.21.3 considered harmful.

From: Erron Criddle <[email-masked]>
Date: Tue, 17 Apr 2001 10:30:16 +0800

Thought I'd clarify:

At 11:23 AM 14/04/2001 +0200, Thomas Roessler <[email-masked]> 
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
[email-masked]