On Tue, 18 Mar 2003, Michael Bell wrote:
Well, after thinking a lot about this, I came to the conclusion that it
would be better if the S/MIME functionality is in a separate module, and
works with MIME::Entity, as it seems to be the natural option (openssl
reads and writes MIME entities). You create the object giving it a file or
a MIME::Entity, apply the sign/verify/encrypt/decrypt methods, and then
fetch the resulting file or entity with correct headers and the final
content.
The main reason to use MIME::Entity is that it eases the parsing of headers (otherwise them will be lost when decrypting, or signed/encrypted if not correctly stripped), is real easy to build new multipart messages from scratch and it has its own cache of temporary files which allows to use very little memory independiently of message/attachments size.
It would be better explained when I finish the first version. But please tell me if you think this is the wrong approach.
If you want to put S/MIME support in a different module then do it. It's your choice. The reason to put S/MIME-support into OpenCA::OpenSSL was the idea to have a modular design which allows the replacement of the cryptotoolkit in the future. I work also on a new design to support hardwaretokens. S/MIME itself is complex enough to put it into a module that's correct. If you create a new module then it should include the keywords SMIME and OpenSSL to allow other implementations of SMIME.
There is a module Crypt::OpenSSL::SMIME but it looks a little bit poor for a complete wrapper of OpenSSL's SMIME command. If you want to contribute it too the project then you should use the prefix OpenCA. OpenCA::OpenSSL::SMIME would be a good idea in this case.
Also, I want to ask you something. IMHO the passing of certificates is best done with OpenCA::X509 objects which I write in a local cache of temporary files for openssl, and allows me to easily run checks on them (the one that signed the mail is the same I expect for this email? Is it issued by my CA? etc.). But I'd seen that in your implementation of getSIME you always expect filenames.
There are two apects first the object orientation and second the interface of OpenSSL. An object oriented interface usually expects objects but OpenSSL works with files. Therefore we use files and not objects. Nevertheless if you use an own cache directory and you have to move files then it is a good idea to use an object oriented interface. By the way it is really simple to create an object from a file with OpenCA::X509 but it costs time.
The question in the paranthesis is a little bit problematical to understand:
1. The cert which sign the email is the senders cert. You need the key for it and the cert should be issued by your CA.
2. The encrpytion cert is from the recipient of the email and the issuing CA is not relevant for you (only the CRL ;) ).
I could write routines that automagically check which kind of data you are passing, but I think it would increase the complexity of the interface too much... Inside openca you store the certs and such in a database isn't it? (I am doing that for my project) In that case, it would be better if we pass them in-core. Tell me if I'm wrong...
What is in-core? If we implement SMIME in a seperate but OpenCA specific module then we should use objects because the speed is not the most important thing. I think a consistent and easily understandable interface is much more important.
Greetings
Michael -- ------------------------------------------------------------------- Michael Bell Email: [EMAIL PROTECTED] ZE Computer- und Medienservice Tel.: +49 (0)30-2093 2482 (Computing Centre) Fax: +49 (0)30-2093 2704 Humboldt-University of Berlin Unter den Linden 6 10099 Berlin Email (private): [EMAIL PROTECTED] Germany http://www.openca.org
-------------------------------------------------------
This SF.net email is sponsored by: Tablet PC. Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
_______________________________________________
OpenCA-Devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/openca-devel
