Cyrus Daboo <daboo(_at_)cyrusoft(_dot_)com> writes:
Hi Simon,
--On Friday, November 14, 2003 22:46 +0100 Simon Josefsson
<simon+ietf-822(_at_)josefsson(_dot_)org> wrote:
| I haven't seen a way to support both inline PGP and format=flowed
| without creating one problem or another.
That's been my experience and in fact I deliberately turn off
format=flowed when generating inline PGP signed messages. It remains
on for PGP/MIME messages (which is the default for new users).
I'm coming to the same conclusion myself, but it would be nice if
people implementing this aren't forced to handle the same problems.
One way to achieve that goal is to include text in the document.
| I'd love to be proved wrong on this, since currently I'm stuck in my
| implementation of inline PGP and format=flowed, because of my
| perceived problems.
|
| I thing Gellens is right in that the there are more modes than what
| you describe. There are at least 4 incompatible ways to do inline
| PGP; QP before, QP after sign (but don't touch PGP armor), QP after
| sign (including PGP armor), don't QP at all. I have seen all of them
| in the wild. Incidentally, my experiences is that the last one works
| best, although it breaks the most specifications. The format=flowed
| draft says only one of the SHOULD be used even though it violate MIME.
I think you need to look at this problem from the recipients end to
actually decide what it is the sender needs to do. In particular its
important that the signature verify for both types of recipients:
those that are format=flowed aware and those that aren't. The later
type effectively determines the order of processing for flowing, PGP
signing and CTE:
A non-format=flowed aware client, when processing a received
format=flowed message, will first do CTE decoding and then display
the message. Verification of the signature will then be done on the
unflowed text (i.e. with trailing spaces and CRLFs etc).
Following the current format=flowed specification, the client would
encounter errors during QP decode, because the '=' within the base64
encoded PGP armor is not QP encoded.
Thus a format=flowed aware client that generates a message would first
wrap the text doing flow, then do the PGP signature, and then do CTE
encoding. That is the only way to work with non-aware clients.
It is not the only way that would work, here's another that I believe
is better: ('PGP aware' means aware of inline PGP, and 'format=flowed
aware' imply 'MIME-aware')
Generate: Do CTE encoding of message, sign, and CTE encode PGP armor.
Receive (non-MIME, non-PGP aware): display.
Receive (MIME-aware, non-PGP aware): CTE decode, display.
Receive (format=flowed aware, non-PGP aware): CTE decode,
format=flowed process, display.
Receive (non-MIME aware, PGP aware): cannot detect valid PGP message,
display.
Receive (MIME-aware, PGP aware): CTE decode PGP armor, verify, CTE
body, display.
Receive (format=flowed aware, PGP aware): CTE decode PGP armor,
verify, CTE decode body, format=flowed process, display.
Comparing your and my approaches: your is vulnerable to the
man-in-the-middle attack inserting trailing SPC and adding
format=flowed header, thus altering the rendering of the message. The
PGP signature would not detect the added trailing SPC for you. Both
approaches break for non-MIME aware, but PGP aware, clients. Your
approach cannot interoperate with RFC 1991 implementions, but my can
(by QP encoding '^-' in the body). Neither of our approaches can
handle non-ASCII characters within the PGP armor encoded in a charset
that isn't compatible with the body charset.
Using UTF-8 and 8-bit (no QP) is another option. The advantage is
that it is possible pipe the incoming RFC 2822 article directly into
the OpenPGP implementation, so it would work for non-MIME aware, but
PGP aware, clients. It also support non-ASCII in PGP armor. The
(only?) disadvantage is that trailing whitespace may be lost in
transit, invalidating the signature. But it still works much better
in practice than any of the QP variants.
Regards,
Simon