On Thu, 20 Mar 2003, Michael Bell wrote: > > 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.
Tricky bussiness :), since the 90% of the code would not have anything to do with openssl :) > 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. At this moment, the implementation is taking X509 objects which then saves in a file (but I run into a inconscistency: I do not have a KEY object -and, by the way, the possibility of storing the key along with the crt in X509 seems wrong to me: the key is not part of x509!), but as I save them on a database, I have to make X509 parse the raw data each time (I should check some way of serializing the object).. Anyway, this is only a question of wasted time. > > (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 > The question in the paranthesis is a little bit problematical to understand: It wasn't a question to you! It was commentary :) I meant, I want to check if the signer of the mail is the same cert I have on my database, check if I issued it, etc... And I do this more easily if I work with X509 objects all the time. eg: when signing, I run a recursive search for issuers until I found the top CA, and then attach this chain to the PKCS7 structure. > 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. When I said in-core I meant passing the certs as objects. I already have a minimal version of the module, as I have all the basic functionality coded, I'll post a copy so you can see it Martin. ps: why on OpenCA modules you implement errno and errval as package variables, instead of instantiated variables??? ------------------------------------------------------- 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
