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

[Matt Caswell]

On 22/08/18 15:55, Dr. Pala 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?

It's a bit confusing and not particularly well defined, with some anomalies.

EVP_PKEY_ASN1_METHOD generally contain functions that operate *on* keys
and parameters.

EVP_PKEY_METHOD generally contains functions that *use* keys and
parameters to perform their operations.

A significant distinction is that (almost) all the EVP_PKEY_METHOD
functions operate within the context of an EVP_PKEY_CTX while none of
the EVP_PKEY_ASN1_METHOD functions do.

Typically you would define both method types for a particular algorithm.

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

Yes, that is the purpose of that function. See:

https://www.openssl.org/docs/man1.1.1/man3/EVP_PKEY_asn1_add0.html

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


It's defined in crypto/asn1/standard_methods.h, so you just need to add
your custom method in there. Obviously, you will then need to also add
an implementation of that method and integrate it into the OpenSSL build
system.

It's probably worth looking at how other methods have been integrated,
e.g. you could look at ed448_asn1_meth which was recently added to 1.1.1.

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

These are used internally only. You don't *need* to have them - but you
may want to have them if you have algorithm specific data that you need
to store.

> 
>   * *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

In general once the methods are in place they should be useable
throughout the library. However you may find that some areas may need
additional tweaks to get them working, e.g. see the
X509_certificate_type() function. If integration into TLS was an
objective then that would definitely require additional custom code.


> 
>   * 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. If you go down the tighter integration route then you can add your
own custom type there.

Matt


> 
> Thanks for any help for understanding all these details... :D
> 
> Cheers,
> Max
> 
> -- 
> Best Regards,
> Massimiliano Pala, Ph.D.
> OpenCA Labs Director
> OpenCA Logo
> 
>