>Hello!
>
>I used SMIME command tool to create some SMIME messages.
>
>I can create signed, encrypted message and to verify and decrypt them with my
>functions.
>
>Now I want to make this messages fully compliant with existing mail clients:
>1. My functions to can verify and decrypt message created by other mail clients.
>2. Messages created by my functions to can be verifed and decripted from other mail
>clients (e.g Outlook Express).
>
>
>When I create signed or encrypted message, I get as input param SMTP header + MIME
>message.
>Do I have to signed and encrypt both (SMTP header + MIME message) or just the second
>part?
>What should be the SMTP header of the Signed or(and) Encrypted message?
>
>I'll be very happy If someone can help me?
>
>Thanks
>Maya
I'm not sure if I'm addressing your exact problem here, but here
goes anyways :)
I too, have recently been writing some SMIME code using the OpenSSL functions.
What I am doing is writing some higher-level wrapper functions around the
various SMIME operations, and I have recently just been testing the signing
end of things, which Outlook was failing to verify for me.
My signing wrapper receives the message to sign as a simple char *, to
facilitate some flexibility later down the road. I then create a memory-backed
BIO from this char *, and call PKCS7_sign() and SMIME_write_PKCS7() to perform
the required operations. The flags passed to these functions are
PKCS7_DETACHED|PKCS7_TEXT.
==> NOTE: I am using 0.9.7beta2 <==
What I have found is this:
PKCS7_sign, takes the input BIO, and runs it through a function that
translates all the end of line markers to \r\n (crlf). If you have PKCS7_TEXT
turned on, it also puts the "Content-Type: text/plain\r\n\r\n" at the
beginning. The signature for this string is then computed.
Now, in SMIME_write_PKCS7(), some SMTP headers are written out, and
the necessary MIME attachment boundaries etc. When it goes to write the
plaintext you signed into the mail message, it reads it directly from
your BIO, with no end of line translation. It also adds the
Content-Type header, but with \n\n as the terminator, not \r\n\r\n.
So when outlook goes to verify this, it fails, since the signature
was based on all EOL markers being crlf, but the attached text may
not be.
There are a few solutions that I can see:
1) Pass in the flag PKCS7_BINARY, and if your signed data is indeed
text, and you'd like to have it show up as such, explicitly prefix
it with the Content-Type: header
2) Go through the text/plain attachment after it is returned to you from
SMIME_write_PKCS7, and munge all EOLs to \r\n (along with fixing the
Content-Type EOL and header/body seperator).
3) Make sure that what I want to be signed is already munged with
all EOL as \r\n. Unfortunatly, this won't work either, due to
the inconsistent handling of the Content-Type: header. However, even
with doing this, all the headers come back to you with \n EOL markers
(see below).
Number 3 would work, and I suppose you could consider this the 'actual'
bug in the SMIME handling.
Number 1 is a passable hack, I don't consider number 2 to be a very
viable option, especially from a usability standpoint. The predominant
practice is that you try to resist mangling strings that you have just
crypotgraphically signed. It makes sense: the point of signing is to
detect changes, so changing the data after the signature operation would
just invalidate the entire point of doing it to begin with.
Ideally, the OpenSSL side of things should insure that what it ACTUALLY
signed is what it outputs in the plaintext attachment part of the message.
This would greatly enhance the ease of use of these particular functions.
Also, on an semi-related note, the MIME outputting functions are using
\n as EOL on SMTP headers, and \n to indicate the end of all headers.
This greatly confuses at least one SMTP library (libesmtp) as it (rightly)
expects the header/body seperation to be \r\n, I'm not sure if the intention
is that I should be walking all the text returned to me by SMIME_write_PKCS7
and translating every bare \n to \r\n, but if it is, I would suggest this
is a horrible requirement from an ease of use standpoint (especially
in the context of signed data, as detailed above).
Sorry if this isn't the exact issue you were seeing, but I just ran into it
myself tonite, and your message had some bit of familiarity to it
-=Zakk
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
