In message <ba9e222e-9cf5-2550-f46b-c8231074904f@xxxxxxxxxx> on Wed, 22 Aug 2018 08:55:02 -0600, "Dr. Pala" <director@xxxxxxxxxx> said: director> Hi all, director> director> I am working on providing a new Public Key method that will handle director> Composite Keys (i.e., multiple keys with different algos - e.g., one RSA director> and one EC) and Composite Signatures (i.e., multiple signatures director> generated with the corresponding Composite Keys). In particular, I would director> like to be able to add a method that will, in turn, call the methods director> supported by the different keys that form the COMPOSITE_PKEY structure. director> director> I have looked around how to do it and I am a bit confused about how to director> proceed as there are some conflicting implementations for different director> algorithms. director> director> Here's some high-level questions related to the EVP_PKEY interface, in director> particular: director> director> * *EVP_PKEY_ASN1_METHOD vs. EVP_PKEY_METHOD *- when these two director> different types of methods are used? Shall both be implemented? Frankly, I'm a bit confused by this myself at times, so you have my understanding. The way I understand it is that: - EVP_PKEY_ASN1_METHOD is related to the type itself, and defines everything that deals with manipulating the type itself and its contents. This is also much more focused on ASN.1, i.e. encoding and decoding to/from DER, or printing out in a human readable form. - EVP_PKEY_METHOD is about operations using the type. The type itself is simply context to perform the operations in. This is where the common operations (encryption, decryption, signing, verifying) belong. These methods also usually combine the pkey type with appropriate digest algos. It can be argued that these two methods have methods that might belong in the other, and one might also wonder why there is a pkey check in both... director> * *After providing the implementation for the ameth/pmeth, how does director> the integration work with openssl?* In particular, should I add them director> to the list of the default ameth/pmeth supported? Here's some more director> specific questions: director> director> o It seems there is an *app_method stack* of EVP_PKEY_ASN1_METHOD director> - how do I add the method there (in case I will use a user-level director> - i.e., not integrated into OpenSSL code - approach by using the director> functions in the crypto/asn1/ameth_lib.c file). Will the director> EVP_PKEY_asn1_add0() function call be sufficient? A call to EVP_PKEY_asn1_add0() should be sufficient. director> o It seems there is an standard_methods stack of director> EVP_PKEY_ASN1_METHOD - how do I add the method there if we need director> to have a more tight integration with the core of the library director> (in case we can not do our proof-of-concept without touching the director> openssl's code / requiring a fork) If you want to integrate it more tightly, you will have to include some code called att init time that does the EVP_PKEY_asn1_add0() call mentioned above, or you will have to bite the bullet and fork (hey, PRs welcome!) director> * *COMPOSITE_PKEY struct and COMPOSITE_PKEY_CTX struct.* I noticed director> that, for example, both RSA and EC implement some form of _CTX and director> _PKEY structures. Are these used only internally or should they be director> implemented and integrated with the METHOD(s) ? EVP_PKEY and EVP_PKEY_CTX? Is that what you're talking about? director> * *Given the above is implemented correctly - will this enable the use director> of the method for processing signatures with the new director> (pseudo-)algorithm for different structures (e.g., CRLs, X509, director> X509_REQ, OCSP_REQ, OCSP_RESP, etc.)* ? I see that there is some director> sort of different usages that can be implemented in the CTRL of the director> ameth (e.g., rsa_pkey_ctrl), however this seems to be targeted to director> the following operations: director> director> ASN1_PKEY_CTRL_PKCS7_SIGN director> ASN1_PKEY_CTRL_PKCS7_ENCRYPT director> ASN1_PKEY_CTRL_CMS_SIGN director> ASN1_PKEY_CTRL_CMS_ENVELOPE director> ASN1_PKEY_CTRL_CMS_RI_TYPE director> ASN1_PKEY_CTRL_DEFAULT_MD_NID (I'm currently digging through that, and am not quite done) director> * Last but not least, since the EVP_PKEY has a union that points to director> the internal key (i.e., crypto/internal/evp_int.h - evp_pkey_st) director> where, besides the rsa, dsa, dh, and ec pointers, a void * ptr is director> defined. Shall I use that pointer to reference the composite_pkey_st director> (at least for the user-space implementation) ? Use the ->ptr field, or even better (because evp_int.h is internal so you shouldn't look), use EVP_PKEY_get0(). director> Thanks for any help for understanding all these details... :D Let's keep talking... I need to dig deeper anyway ;-) Cheers, Richard -- Richard Levitte levitte@xxxxxxxxxxx OpenSSL Project http://www.openssl.org/~levitte/ -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
