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

[Chris Hastie]

On Wed, 8 Jan 2003, Michael M Slusarz <slusarz at bigworm.colorado.edu> 
wrote
>Quoting Chris Hastie <lists at oak-wood.co.uk>:
>|
>| |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:
>| |          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.
>
>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.

Er, no, I don't think it was! The point was that as far as I can make 
out when generating an encrypted OpenPGP message there is a requirement 
to convert text to CRLF endings prior to encrypting it.

Decrypting the application/octet-stream part of PGP/MIME message 
generated by Imp, it is clear that it was encrypted with LF, not CRLF. 
That is to say, taking the raw message, grabbing everything between
 > -----BEGIN PGP MESSAGE----- and -----END PGP MESSAGE----- < and 
decrypting it manually, what I see are LF endings.

I'm not actually saying this is causing any inter operability problems - 
Turnpike certainly handles it any way and the only other MUA I have 
around to test with is OE, which just doesn't handle PGP/MIME so it's a 
bit academic. But not complying as far as possible with RFC's is likely 
to lead to inter operability problems at some point.

>
>| 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 :) ).
>
Well I had a look, and couldn't get the hang of what was going on at all 
I'm afraid. I might come back to it (not before next month mind), but it 
would help if I had some idea what I was doing.
-- 
Chris Hastie