[openssl-users] How to Implement a new PubKey method correctly

[Dr. Pala]

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:

      o 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?

      o 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
OpenCA Logo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180822/959b710e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: eonooiokingombaf.png
Type: image/png
Size: 3146 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180822/959b710e/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3994 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180822/959b710e/attachment.bin>