[imp] PGP bug? - compliance with RFCs 3156 & 1847

[Michael M Slusarz]

Quoting Chris Hastie <lists at oak-wood.co.uk>:

| On Mon, 6 Jan 2003, Michael M Slusarz <slusarz at bigworm.colorado.edu>
| wrote
| >| I also note that the decrypted section from Imp has LF line
| terminators
| >| rather than CRLF. Given that this should decrypt to a plain text
| email,
| >| this seems a strange choice.
| >
| >CRLF would be bad because on most systems CRLF translates to 2 breaks
| per
| >line.  CRLF is only required for mail transport - not for local display
| or
| >even handling on the local end.  LF seems to work fine on all systems
| when
| >handling messages locally - even windows (which normally requires CRLF).
| 
| Michael
| 
| The Turnpike developers are adamant that CRLF is required here, and from
| what I can make out they are correct.
| 
| RFC3156 requires
| 
| |4.  OpenPGP encrypted data
| |
| |   Before OpenPGP encryption, the data is written in MIME canonical
| |   format (body and headers).
| 
| MIME canonical format is defined in RFC2049, which includes this at
| section 4:
| 
| |   (2)   Conversion to canonical form.
| |
|            <snip>
| |
| |          For example, in the case of text/plain data, the text
| |          must be converted to a supported character set and
| |          lines must be delimited with CRLF delimiters in
| |          accordance with RFC 822.  Note that the restriction on
| |          line lengths implied by RFC 822 is eliminated if the
| |          next step employs either quoted-printable or base64
| |          encoding.
| 
| and goes on
| 
| |   NOTE: Some confusion has been caused by systems that represent
| |   messages in a format which uses local newline conventions which
| |   differ from the RFC822 CRLF convention.  It is important to note that
| |   these formats are not canonical RFC822/MIME.  These formats are
| |   instead *encodings* of RFC822, where CRLF sequences in the canonical
| |   representation of the message are encoded as the local newline
| |   convention.  Note that formats which encode CRLF sequences as, for
| |   example, LF are not capable of representing MIME messages containing
| |   binary data which contains LF octets not part of CRLF line separation
| |   sequences.
| 
| RFC3156 is even more explicit about the need to use CRLF in signed
| message, since there is a need to ensure that the message being verified
| is identical to that which was signed, including line ends.

This is all correct.  But IMP already *does* this and, furthermore, this is 
only important for how messages are _sent_, and how messages are 
_verified_.  For example, imp/lib/MIME/Viewer/pgp.php uses 
getCanonicalContents(), which ensures the message data is in canonical 
form.  This info is used ONLY when determining the authenticity of the 
signed message.  (Similarly, when the message is sent, the function 
toCanonicalString() is used to create the signature).  Thus, whenever 
IMP/Horde is dealing with the contents of the entire PGP message, it is 
doing so in the canonical format (e.g. with CRLF linebreaks).

However, when _viewing_ OpenPGP messages, there is absolutely NOTHING in 
the RFCs that requires certain linebreaks to use.  The local MUA is free to 
convert those CRLF into anything it wants to display to the viewer (IMP 
sets to LF; theoretically, a MUA could set the linebreaks to "HEY LOOK AT 
ME, I'M A LINEBREAK!" if it wanted to).

Hopefully this is what you were asking about.

| Another problem I'm having with PGP in Imp is with non-MIME ASCII
| signatures, (as opposed to PGP/MIME). With pgp_scan_body set, all such
| messages are displayed as having an invalid signature. If I view the
| message source and use PGPTray in Windows to verify the current window
| it returns OK. Similarly if I cut the body from the message source
| window and paste it into a file I can verify the signature with gpg,
| irrespective, by the way, of whether I save the file with LF or CRLF
| endings. So it would seem the signatures are fine, but there is a
| problem in Imp recognising this fact.

The non-MIME ASCII signature recognition is a work in progress.  It was not 
something that I desired very much - thus, it is not that well developed.  
This support could definitely be improved if someone wants to help with 
this (hint hint :) ).

michael

______________________________________________
Michael Slusarz [slusarz at bigworm.colorado.edu]