Re: How to Implement a new PubKey method correctly

[Dmitry Belyavsky <beldmit@xxxxxxxxx>]

Dear Max, 

You can take a look at https://github.com/gost-engine/engine as an example of providing new algorithms via engine. 

On Fri, Aug 24, 2018 at 10:45 AM Dr. Pala <director@xxxxxxxxxx> wrote:

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?
  

The 1st one is for processing ASN1 structures and the 2nd  is for crypto-operations.

• 
  
• 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)
  

See register_ameth/register_pmeth in GOST engine.

• 
  
• 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) ?
  

I suspect you need your own representation of key owning RSA and EC keys and manage themselves.

• 
  
• 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) ?

Yes. 

Thanks for any help for understanding all these details... :D

Cheers,
Max

--

Best Regards,

Massimiliano Pala, Ph.D.
OpenCA Labs Director

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

--

SY, Dmitry Belyavsky

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users