[[EMAIL PROTECTED] - Thu Jul 18 22:15:39 2002]:
> In message <[EMAIL PROTECTED]> on Thu, 18 Jul 2002 21:07:10 > +0100, Ben Laurie <[EMAIL PROTECTED]> said: > > ben> The issue as reported to me was that the body had CRLF, but > headers LF > ben> only... > ben> > ben> Seems to me they should be consistent. > > I agree. However, what kinds of complications does that add regarding > proper signatures and so on? Also, right now, I've no idea what the > impact on VMS is. I guess I should play a bit... The actual MIME code used for OpenSSL S/MIME is somewhat primitive. It was designed at the time to handle the more common cases, things such as plain text content or 7 bit MIME. It will mess up some cases such as 8 bit attachments or where the signature isn't base64 encoded. Nevertheless at the time it interoped with the clients I tried and it passed the RSA S/MIME interop tests. I wrote the MIME code becausethere weren't any simple MIME parsers available then which could be readily interfaced with the library and which didn't mess up the multipart/signed type. As far as CRLFs are concerned the rules for multipart/signed are such that the first part must be in "canonical MIME" format. This is normally CRLF for EOL for many MIME types. So the signature *must* be computed over CRLF EOL for the signed content. The signed content is converted to this form when its digest it calculated. That's why it uses \r\n when it adds plain text headers within the signed content. This results in a situation where the signed content is CRLF but the surrounding lines may not be: that is the mail headers, the multipart/signed MIME headers and those of the base64 encoded signature. If you want to be consistent there are several possible ways to handle this. For example I was considering writing a filter BIO that did CRLF<->LF conversion at one point. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
