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 ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
