Something that came up here, which could be useful to discuss in the
security consideration: OpenPGP says that trailing white space on an
article is ignored when computing digest on a cleartext signed
message. This means that someone can add, in transit, a format=flowed
header to a (regular, non-flowed) vanilla PGP (not PGP/MIME) signed
message and introduce arbitrary trailing SPC characters without being
detected. This change the rendering of the article, if the client
support format=flowed, possibly even in a malicious way.
Consider someone sending:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
My favorite letters, ordered by priority (letters on the same line
are of the same priority):
A Q
C
L O
X
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.3.2-cvs (GNU/Linux)
iQC1AwUBPylPae2iHpS1ZXFvAQJExwT+JPl/+MCgjggqab0I7E3E964S6+FijyGI
NT0n9WD1hWYB9TYyQAtzDA4AIHhvcMu0QJaiPb/DNDE0RP+n/5rESU8wt+BoDo33
h1pEzvCtPL/QFW5fRBqaJO9KXsrqofMym+xoYZrtAMzttPWb8OxjpWSYfd5TnGKM
qpYGI8YKWfGonDx2ed7Aa9GbX3Tx8EOd5mGTAciJit23m6NQtG9MfQ==
=gRko
-----END PGP SIGNATURE-----
that is (using the syntax of the draft)
A Q#
C#
L O#
X#
Someone could add a format=flowed header to the message, and add
trailing SPC to two of the lines, turning the message into
A Q*
C#
L O*
X#
which would still verify correctly, but be rendered by the client as
A Q C
L O X
together with a successful PGP verification, but the result has a
different meaning.
Section 5.6 of the document discusses digital signatures, but I'm not
convinced it covers for this problem. OTOH, one could consider this a
bug in 2440; a message should not verify successfully if it isn't the
same as the one that was signed.
Thanks.
(Of course, the imaginative reader will realize similar problems in
other systems, that have this "canceling" property that format=flowed
together with OpenPGP exhibit in this example.)