I don't know if this is the proper place to bring this up, or if a project fork would be more appropriate (given the investment that exists in the current API/ABI)...
I would like to be able to determine and document what parameters of a cryptographic object passed to any given library function must exist, may exist, and must not exist. (This is brought up by the recent question on the openssl-users list, "EVP_verify on self-signed cert", and its answer: EVP_Verify* doesn't care whether or not the cert from which the key is extracted is trusted, valid or self-signed. If the cert contains a valid public key the above code should work. Cheers, Nils) What function sets care about various states? From a purely off-the-top-of-my-head view, I'm seeing: Plain Text Encrypted Text Symmetric Key (Initialization) Symmetric Key Algorithm Asymmetric Key (public) (Initialization) Asymmetric Key (private) (Initialization) Asymmetric Key Algorithm Certificate Certificate trust I guess I'm trying to look at this from a "guarantee-of-parameter", "operation", "guarantee of output integrity" contract-based programming view. (Among other things, this could allow blobs of data to flow freely into and out of the FIPS core, given structure magic numbers and such.) Just a thought? Any comments? -Kyle H ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
