ietf-822
[Top] [All Lists]

Re: Format=Flowed/RFC 2646 Bis (-02)

2003-11-13 17:44:33

Randall Gellens <randy(_at_)qualcomm(_dot_)com> writes:

At 7:59 PM +0100 11/3/03, Simon Josefsson wrote:

 Thanks for adding the OpenPGP discussion.  Given the subtleness of the
 issue, I believe the document should not only mention it, but also
 give normative advice on how the combination of OpenPGP and
 format=flowed is to be implemented.  Otherwise implementors will
 ignore the problem, as they do today.

 When I look at how to properly implement both OpenPGP and
 format=flowed, I can't come to any other conclusion than that security
 is more important than maintaining soft paragraph breaks.  That means
 a client should not flow OpenPGP signed data, when it present the
 outcome as something that OpenPGP guarantee is what the sender sent.
 If the client would flow a message, someone in transit may modify the
 rendering of a message without being detected by OpenPGP.

 Repeating the text from RFC 2440, saying that PGP/MIME aka RFC 3156
 SHOULD be used in messaging applications, may be sufficient.  Perhaps
 promote it to MUST within the scope of flowed messages.

The current text says to use quoted-printable to protect the trailing
spaces so that the signature is calculated on the on-the-wire format:

5.6.  Digital Signatures and Encryption
       If a message is digitally signed or encrypted it is important
       that
     cryptographic processing use the on-the-wire Format=Flowed format.
     That is, during generation the message SHOULD be prepared for
     transmission, including addition of soft line breaks,
     space-stuffing, and [Quoted-Printable] encoding (to protect soft
     line breaks) before being digitally signed or encrypted; similarly,
     on receipt the message SHOULD have the signature verified or be
     decrypted before [Quoted-Printable] decoding and removal of stuffed
     spaces, soft line breaks and quote marks, and reflowing.
       Note that [OpenPGP] specifies (in section 7.1) that "any
       trailing
     whitespace (spaces, and tabs, 0x09) at the end of any line is
     ignored when the cleartext signature is calculated."
       Thus it would be possible to add, in transit, a format=flowed
       header
     to a regular, format=fixed vanilla PGP (not PGP/MIME) signed message
     and add arbitrary trailing space characters without this addition
     being detected.  This would change the rendering of the article by a
     client which supported format=flowed.

In thinking about this some more, I'm not sure that the extra text on
OpenPGP is really needed, since if the text above is followed it
shouldn't be an issue.

The problem is that the above procedure is flawed, so it is not always
possible to use it in the real world.  There are several problems with
that text, I believe the two major issues are:

1) It leads to invalid MIME messages on the wire.  After following the
   above procedure, what is sent is a message marked with CTE qp but
   only the contents of the inline PGP message actually follow the QP
   rules.  The PGP armor itself do not follow the QP rules.  More
   precisely, the base64 '=' character that is always part of the
   final CRC value would be a unescaped '=' character.  So transit or
   recipient systems might reject it due to invalid QP, and IMAP
   servers might refuse to search within the message, or refuse it
   altogether because it isn't valid MIME.

   This problem could be solved by performing QP encoding on the PGP
   armor itself as well, after signing the QP encoded message body.
   The text above does not suggest that (there is even a SHOULD
   arguing otherwise), and existing clients do not appear to perform
   QP on the PGP armor (at least not those I'm familiar with).
   Furthermore, because existing clients do not QP encode to the PGP
   armor, I doubt existing clients would understand they have to first
   QP decode the PGP armor, and then pass the resulting QP decoded PGP
   armor plus QP encoded body to the PGP implementation.  Still,
   adding such a clarification would be a way forward.

2) Non-ASCII text within the armor (e.g., 'Comments:') do exist, some
   translated products even add such strings by default.  If the
   charset used for the armor isn't the same as the message body, it
   is not even possible to QP for the armor.  I don't see a solution
   to this problem.  It has been argued in the past that the PGP armor
   cannot contain non-ASCII, but I believe it remains to be clarified
   since it is frequent in the wild.

Saying that cryptographic processing is something that should be done,
on the generating side, after all 822 and MIME processing, and on the
receiving side, before all 822 and MIME processing, does not work.  It
leads to the above problems.

Before we loose sight of the big picture, I'd like to repeat that none
of these issues apply if PGP/MIME is used, which is what RFC 2440 says
SHOULD be used.  (Well, at least, the problems do not _necessarily_
apply; PGP/MIME can be implemented incorrectly that leads to similar
problems.)  Unless it can be demonstrated that implementing PGP and
format=flowed is possible without breaking the MIME standard, I still
maintain that qualifying the SHOULD to a MUST, within the scope of
format=flowed messages, is better.

Thanks,
Simon