Hi there, On Wed, 19 Jun 2002, Giudicelli Frédéric via RT wrote:
> The problem is that the use oF engines should be > totaly transparent to the higher API, but apparently > it's not. The problem is RSA_check_key() is not a general "transparent" RSA function, it's designed (it would seem) to check that all the values in an RSA key structure are valid relative to one-another. This violates encapsulation and completely ignores the use of RSA_METHOD, so together that's where the "transparency" is broken. In general cases, where the RSA object could represent an HSM-protected key or just a public key, virtually all of those internal structure elements become redundant - and not necessarily NULL (an ENGINE implementation is free to store any values it likes in the structure elements, as long as the handler functions do their job properly). By consequence, there remains very little that you could actually *check* inside the RSA key structure in the general case! OTOH: You could test that the RSA object behaves "normally" by calling various RSA functions with various inputs and checking that you can't trip it up. These should all work (in theory) because those RSA functions (encrypt, decrypt, etc) would delegate to the implementation function pointers. So in the case of HSM keys, the ENGINE code would be performing the key operations anyway so it wouldn't matter whether or not rsa->dmq1 was NULL or whether rsa->flags included RSA_FLAG_EXT_PKEY, etc. This is I guess your point about being "transparent". I simply don't think RSA_check_key() should be called except by programs that manipulate RSA structures already - eg. converters between different key formats (eg. PGP/ssh/... key importers, key file readers, alternative key-generation implementations, etc). If you want to contemplate an "external" way of testing RSA keys - ie. simply by performing operations with them - then that would certainly be more what you're looking for. Feel free to suggest an implementation :-) > 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. Again, you are really looking for a different sort of function to what RSA_check_key() is/does. > I'm supposed to be able to call any RSA API with a > hardware key, but I can't, so I don't know if it's bug > or a conception problem on engines layer. This probably needs a documentation change to avoid similar misunderstandings in future. > It wouldn't take much to make this function > compatible, or the others that I haven't used and that > have the same problem, maybe create a new flag for the > RSA keys, I already use RSA_FLAG_EXT_PKEY, what about > something like RSA_FLAG_ENGINE_PKEY, I imagine that it > would force peoples to modify there code for their > engines, to add this flag when they load a key. *Maybe* ... but even then it doesn't solve the case of public keys. Moreover, how do you actually test a public key? What does "check" actually mean in this case? > This problem will probably show up for DSA, DH, DES > keys aswell. Perhaps - but again, I think you're assuming RSA_check_key() to mean something far more generic than it actually does, and I perfectly understand why you might misinterpret it that way too. I think a new function is required to test keys via transparent operations, perhaps RSA_is_valid()? Cheers, Geoff ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
