|
Hi all,
I am working on providing a new Public Key method that will
handle Composite Keys (i.e., multiple keys with different algos -
e.g., one RSA and one EC) and Composite Signatures (i.e.,
multiple signatures generated with the corresponding Composite
Keys). In particular, I would like to be able to add a method that
will, in turn, call the methods supported by the different keys
that form the COMPOSITE_PKEY structure.
I have looked around how to do it and I am a bit confused about
how to proceed as there are some conflicting implementations for
different algorithms.
Here's some high-level questions related to the EVP_PKEY
interface, in particular:
- EVP_PKEY_ASN1_METHOD vs. EVP_PKEY_METHOD - when these
two different types of methods are used? Shall both be
implemented?
- After providing the implementation for the ameth/pmeth, how
does the integration work with openssl? In particular,
should I add them to the list of the default ameth/pmeth
supported? Here's some more specific questions:
- It seems there is an app_method stack of
EVP_PKEY_ASN1_METHOD - how do I add the method there (in case
I will use a user-level - i.e., not integrated into OpenSSL
code - approach by using the functions in the
crypto/asn1/ameth_lib.c file). Will the EVP_PKEY_asn1_add0()
function call be sufficient?
- It seems there is an standard_methods stack of
EVP_PKEY_ASN1_METHOD - how do I add the method there if we
need to have a more tight integration with the core of the
library (in case we can not do our proof-of-concept without
touching the openssl's code / requiring a fork)
- COMPOSITE_PKEY struct and COMPOSITE_PKEY_CTX struct. I
noticed that, for example, both RSA and EC implement some form
of _CTX and _PKEY structures. Are these used only internally or
should they be implemented and integrated with the METHOD(s) ?
- Given the above is implemented correctly - will this enable
the use of the method for processing signatures with the new
(pseudo-)algorithm for different structures (e.g., CRLs, X509,
X509_REQ, OCSP_REQ, OCSP_RESP, etc.) ? I see that there is
some sort of different usages that can be implemented in the
CTRL of the ameth (e.g., rsa_pkey_ctrl), however this seems to
be targeted to the following operations:
ASN1_PKEY_CTRL_PKCS7_SIGN
ASN1_PKEY_CTRL_PKCS7_ENCRYPT
ASN1_PKEY_CTRL_CMS_SIGN
ASN1_PKEY_CTRL_CMS_ENVELOPE
ASN1_PKEY_CTRL_CMS_RI_TYPE
ASN1_PKEY_CTRL_DEFAULT_MD_NID
- Last but not least, since the EVP_PKEY has a union that points
to the internal key (i.e., crypto/internal/evp_int.h -
evp_pkey_st) where, besides the rsa, dsa, dh, and ec pointers, a
void * ptr is defined. Shall I use that pointer to reference the
composite_pkey_st (at least for the user-space implementation) ?
Thanks for any help for understanding all these details... :D
Cheers,
Max
--
Best Regards,
Massimiliano
Pala, Ph.D.
OpenCA Labs Director
|
