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

[Richard Levitte]

In message <ba9e222e-9cf5-2550-f46b-c8231074904f at openca.org> on Wed, 22 Aug 2018 08:55:02 -0600, "Dr. Pala" <director at openca.org> 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 at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/