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

[Chris Hastie]

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.

That said, following your inclusion of headers in the encrypted part 
Turnpike is now displaying encrypted messages from Imp correctly.

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