Indeed it would be a good idea, especially for RSA_generate_key, since people have to generate their key thru an interface that is extern to OpenSSL, then sign their CSR with that key using OpenSSL, when everything could be implemented within OpenSSL. The major benefit would come for, a PKI architecture based on OpenSSL, imagine a CA tree, if I want the key of the ROOT CA, the SUB-CAs to be stocked in a hardware device, you can't make it thru OpenSSL, and it become a pain in the butt if your architecture is managed thru the network, you will have to physically go on the CA computer, to generate each of the SUB-CAs keys.
--- Geoff Thorpe via RT <[EMAIL PROTECTED]> wrote: > > Just attaching a little more "state" to this ticket > ... > > [[EMAIL PROTECTED] - Wed Jun 19 09:52:27 2002]: > > > The problem is that the use oF engines should be > > totaly transparent to the higher API, but > apparently > > it's not. > > I don't call RSA_check_key for a hardware key, I > call > > it for my CA private key, and I don't know if it's > a > > hardware or software key since it's transparent. > [snip] > > Richard just added a couple of notes to the > documentation at the same > time I was working on it. I may or may not put my > changes over the top > of his yet, but in the mean time ... > > I think the ultimate solution to this problem will > be similar to the > ultimate solution to the problem of "generic" key > generation - ie. key > generation that is independant of the ENGINE > implementation being used. > When you think about the underlying problem, the > solution is rather > obvious (but perhaps annoying to implement); the > basic problem is that > RSA_generate_key() and RSA_check_key() both directly > deal with structure > elements rather than using members of the RSA_METHOD > vt. If > RSA_public_decrypt() did the same thing, it would > have the same problem > of not working with replacement RSA implementations. > I think the > "check_key" functionality needs to go into a handler > callback in the > RSA_METHOD itself so that any implementation that > alters the way key > material is stored and managed can similarly > implement a corresponding > mechanism for verifying key integrity. > > In the mean time, the short-term solution (bear in > mind this will break > binary compatibility to some extent and will require > all ENGINEs to be > adapted) is to alter the documentation to describe > the situation. > > Cheers, > Geoff > > -- > > Geoff Thorpe, RT/openssl.org ______________________________________________________________________ Post your ad for free now! http://personals.yahoo.ca ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
