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
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
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
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.