PROVIDER-KEYMGMT(7ossl)

πŸ’… PROVIDER-KEYMGMT(7ossl) β€” the KEYMGMT library <-> provider functions ✨

okay bestie, welcome to provider-keymgmt (that's the 7ossl manual section, iykyk) β€” this is THE page about how the KEYMGMT operation talks to providers, and it's lowkey a whole vibe. grab a snack πŸ“, we're getting into it.


🌸 SYNOPSIS 🌸

#include <openssl/core_dispatch.h>

/*
 * None of these are actual functions, but are displayed like this for
 * the function signatures for functions that are offered as function
 * pointers in OSSL_DISPATCH arrays.
 */

/* Key object (keydata) creation and destruction */
void *OSSL_FUNC_keymgmt_new(void *provctx);
void OSSL_FUNC_keymgmt_free(void *keydata);

/* Generation, a more complex constructor */
void *OSSL_FUNC_keymgmt_gen_init(void *provctx, int selection,
                                 const OSSL_PARAM params[]);
int OSSL_FUNC_keymgmt_gen_set_template(void *genctx, void *template);
int OSSL_FUNC_keymgmt_gen_get_params(void *genctx, OSSL_PARAM params[]);
int OSSL_FUNC_keymgmt_gen_set_params(void *genctx, const OSSL_PARAM params[]);
const OSSL_PARAM *OSSL_FUNC_keymgmt_gen_gettable_params(void *genctx,
                                                        void *provctx);
const OSSL_PARAM *OSSL_FUNC_keymgmt_gen_settable_params(void *genctx,
                                                        void *provctx);
void *OSSL_FUNC_keymgmt_gen(void *genctx, OSSL_CALLBACK *cb, void *cbarg);
void OSSL_FUNC_keymgmt_gen_cleanup(void *genctx);

/* Key loading by object reference, also a constructor */
void *OSSL_FUNC_keymgmt_load(const void *reference, size_t reference_sz);

/* Key object information */
int OSSL_FUNC_keymgmt_get_params(void *keydata, OSSL_PARAM params[]);
const OSSL_PARAM *OSSL_FUNC_keymgmt_gettable_params(void *provctx);
int OSSL_FUNC_keymgmt_set_params(void *keydata, const OSSL_PARAM params[]);
const OSSL_PARAM *OSSL_FUNC_keymgmt_settable_params(void *provctx);

/* Key object content checks */
int OSSL_FUNC_keymgmt_has(const void *keydata, int selection);
int OSSL_FUNC_keymgmt_match(const void *keydata1, const void *keydata2,
                            int selection);

/* Discovery of supported operations */
const char *OSSL_FUNC_keymgmt_query_operation_name(int operation_id);

/* Key object import and export functions */
int OSSL_FUNC_keymgmt_import(void *keydata, int selection, const OSSL_PARAM params[]);
const OSSL_PARAM *OSSL_FUNC_keymgmt_import_types(int selection);
const OSSL_PARAM *OSSL_FUNC_keymgmt_import_types_ex(void *provctx, int selection);
int OSSL_FUNC_keymgmt_export(void *keydata, int selection,
                             OSSL_CALLBACK *param_cb, void *cbarg);
const OSSL_PARAM *OSSL_FUNC_keymgmt_export_types(int selection);
const OSSL_PARAM *OSSL_FUNC_keymgmt_export_types_ex(void *provctx, int selection);

/* Key object duplication, a constructor */
void *OSSL_FUNC_keymgmt_dup(const void *keydata_from, int selection);

/* Key object validation */
int OSSL_FUNC_keymgmt_validate(const void *keydata, int selection, int checktype);
πŸ’€ real talk before you panic: none of those are actual functions you can just call β€” they're all shown in this style so you can see the function signatures for the function pointers that live in OSSL_DISPATCH arrays. it's giving "menu, not meal".

πŸ¦‹ DESCRIPTION πŸ¦‹

So the KEYMGMT operation isn't really a public-facing main character in the OpenSSL libraries β€” it's more of an internal operation, and it's literally designed to work in tandem with the operations that actually use private/public key pairs. supporting role, but the plot would collapse without it. 🫢

And because KEYMGMT shares knowledge with the operations it works with in tandem, they must belong to the same provider. The OpenSSL libraries will make sure of that for you, no cap.

Its primary responsibility? Holding the provider side key data for the OpenSSL library EVP_PKEY structure. that's the whole job. iconic of it honestly. πŸ‘‘

Every "function" we're talking about here gets passed as a function pointer between libcrypto and the provider, inside OSSL_DISPATCH(3) arrays, which come through OSSL_ALGORITHM(3) arrays that the provider's provider_query_operation() function returns (peep "Provider Functions" in provider-base(7)).

Every single one of these "functions" has:

  • a matching function type definition named OSSL_FUNC_{name}_fn, and
  • a lil helper function that fetches the function pointer out of an OSSL_DISPATCH(3) element, named OSSL_FUNC_{name}.

For example, the "function" OSSL_FUNC_keymgmt_new() has these besties:

typedef void *(OSSL_FUNC_keymgmt_new_fn)(void *provctx);
static ossl_inline OSSL_FUNC_keymgmt_new_fn
    OSSL_FUNC_keymgmt_new(const OSSL_DISPATCH *opf);

OSSL_DISPATCH(3) arrays are indexed by numbers, and those numbers are handed to you as macros in openssl-core_dispatch.h(7), like this:

OSSL_FUNC_keymgmt_new                  OSSL_FUNC_KEYMGMT_NEW
OSSL_FUNC_keymgmt_free                 OSSL_FUNC_KEYMGMT_FREE

OSSL_FUNC_keymgmt_gen_init             OSSL_FUNC_KEYMGMT_GEN_INIT
OSSL_FUNC_keymgmt_gen_set_template     OSSL_FUNC_KEYMGMT_GEN_SET_TEMPLATE
OSSL_FUNC_keymgmt_gen_get_params       OSSL_FUNC_KEYMGMT_GEN_GET_PARAMS
OSSL_FUNC_keymgmt_gen_gettable_params  OSSL_FUNC_KEYMGMT_GEN_GETTABLE_PARAMS
OSSL_FUNC_keymgmt_gen_set_params       OSSL_FUNC_KEYMGMT_GEN_SET_PARAMS
OSSL_FUNC_keymgmt_gen_settable_params  OSSL_FUNC_KEYMGMT_GEN_SETTABLE_PARAMS
OSSL_FUNC_keymgmt_gen                  OSSL_FUNC_KEYMGMT_GEN
OSSL_FUNC_keymgmt_gen_cleanup          OSSL_FUNC_KEYMGMT_GEN_CLEANUP

OSSL_FUNC_keymgmt_load                 OSSL_FUNC_KEYMGMT_LOAD

OSSL_FUNC_keymgmt_get_params           OSSL_FUNC_KEYMGMT_GET_PARAMS
OSSL_FUNC_keymgmt_gettable_params      OSSL_FUNC_KEYMGMT_GETTABLE_PARAMS
OSSL_FUNC_keymgmt_set_params           OSSL_FUNC_KEYMGMT_SET_PARAMS
OSSL_FUNC_keymgmt_settable_params      OSSL_FUNC_KEYMGMT_SETTABLE_PARAMS

OSSL_FUNC_keymgmt_query_operation_name OSSL_FUNC_KEYMGMT_QUERY_OPERATION_NAME

OSSL_FUNC_keymgmt_has                  OSSL_FUNC_KEYMGMT_HAS
OSSL_FUNC_keymgmt_validate             OSSL_FUNC_KEYMGMT_VALIDATE
OSSL_FUNC_keymgmt_match                OSSL_FUNC_KEYMGMT_MATCH

OSSL_FUNC_keymgmt_import               OSSL_FUNC_KEYMGMT_IMPORT
OSSL_FUNC_keymgmt_import_types         OSSL_FUNC_KEYMGMT_IMPORT_TYPES
OSSL_FUNC_keymgmt_import_types_ex      OSSL_FUNC_KEYMGMT_IMPORT_TYPES_EX
OSSL_FUNC_keymgmt_export               OSSL_FUNC_KEYMGMT_EXPORT
OSSL_FUNC_keymgmt_export_types         OSSL_FUNC_KEYMGMT_EXPORT_TYPES
OSSL_FUNC_keymgmt_export_types_ex      OSSL_FUNC_KEYMGMT_EXPORT_TYPES_EX

OSSL_FUNC_keymgmt_dup                  OSSL_FUNC_KEYMGMT_DUP

πŸŽ€ Key Objects πŸŽ€

A key object is basically a lil collection of data for an asymmetric key, and in this manual it's called keydata. cute name, love that for it.

The exact contents of a key object? defined by the provider, periodt. And the assumption is that different operations inside one and the same provider use the exact same structure to represent this collection of data β€” so like, a key object created with the KEYMGMT interface we're documenting right here can be passed as-is to other provider operations, for example OP_signature_sign_init() (see provider-signature(7)). sharing is caring, bestie 🫢

With some of the KEYMGMT functions you can pick a specific subset of data to handle, and that's governed by the bits in a selection indicator. the bits are:

  • OSSL_KEYMGMT_SELECT_PRIVATE_KEY β€” saying the private key data in a key object should be considered.
  • OSSL_KEYMGMT_SELECT_PUBLIC_KEY β€” saying the public key data in a key object should be considered.
  • OSSL_KEYMGMT_SELECT_DOMAIN_PARAMETERS β€” saying the domain parameters in a key object should be considered.
  • OSSL_KEYMGMT_SELECT_OTHER_PARAMETERS β€” saying the other parameters in a key object should be considered.

Other parameters = key parameters that don't fit into any of the other classifications. In other words this particular selector bit is basically a last resort bit bucket selector. the misc drawer of selectors, no shade.

Some of the selector bits have also been combined already, for easier use:

  • OSSL_KEYMGMT_SELECT_ALL_PARAMETERS β€” saying all key object parameters should be considered, regardless of their more granular classification.

This is a combination of OSSL_KEYMGMT_SELECT_DOMAIN_PARAMETERS and OSSL_KEYMGMT_SELECT_OTHER_PARAMETERS.

  • OSSL_KEYMGMT_SELECT_KEYPAIR β€” saying the whole key pair in a key object should be considered, i.e. the combination of public and private key.

This is a combination of OSSL_KEYMGMT_SELECT_PRIVATE_KEY and OSSL_KEYMGMT_SELECT_PUBLIC_KEY.

  • OSSL_KEYMGMT_SELECT_ALL β€” saying everything in a key object should be considered.

How exactly those bits get interpreted, or how they combine, is left to each individual function where you can specify a selector. and it's left to the provider implementation to decide what's reasonable to do with the selector bits it receives, and how to do it. among others, an implementation of OSSL_FUNC_keymgmt_match() might choose to skip comparing the private half if it already compared the public half β€” because a match of one half implies a match of the other half. efficient queen. πŸ’…


✨ Constructing and Destructing Functions ✨

  • OSSL_FUNC_keymgmt_new() should create a provider side key object. The provider context provctx gets passed in and may be incorporated into the key object β€” but that's not mandatory, so no pressure.
  • OSSL_FUNC_keymgmt_free() should free the passed keydata.

OSSL_FUNC_keymgmt_gen_init(), OSSL_FUNC_keymgmt_gen_set_template(), OSSL_FUNC_keymgmt_gen_get_params(), OSSL_FUNC_keymgmt_gen_gettable_params(), OSSL_FUNC_keymgmt_gen_set_params(), OSSL_FUNC_keymgmt_gen_settable_params(), OSSL_FUNC_keymgmt_gen() and OSSL_FUNC_keymgmt_gen_cleanup() all work together as a more elaborate, context based key object constructor. the whole squad, fr fr.

  • OSSL_FUNC_keymgmt_gen_init() should create the key object generation context and initialize it with selections, which determine what kind of contents the key object to be generated should get. The params, if not NULL, should be set on the context in a manner similar to using OSSL_FUNC_keymgmt_set_params().
  • OSSL_FUNC_keymgmt_gen_set_template() should add template to the context genctx. The template is assumed to be a key object constructed with the same KEYMGMT, and the implementation can use content from it that it chooses as a template for the key object to be generated. Typically, generating a DSA or DH key would grab the domain parameters from this template. reusing what already exists, main character energy. πŸ‘‘
  • OSSL_FUNC_keymgmt_gen_get_params() should retrieve parameters into params in the key object generation context genctx.
  • OSSL_FUNC_keymgmt_gen_gettable_params() should return a constant array of descriptor OSSL_PARAM(3), for parameters that OSSL_FUNC_keymgmt_gen_get_params() can handle.
  • OSSL_FUNC_keymgmt_gen_set_params() should set additional parameters from params in the key object generation context genctx.
  • OSSL_FUNC_keymgmt_gen_settable_params() should return a constant array of descriptor OSSL_PARAM(3), for parameters that OSSL_FUNC_keymgmt_gen_set_params() can handle.
  • OSSL_FUNC_keymgmt_gen() should perform the key object generation itself and return the result. The callback cb should be called at regular intervals with indications on how the key object generation progresses β€” yes bestie, it updates you as it goes, communication is key πŸ’–

So like, OSSL_FUNC_keymgmt_gen_cleanup() is the cleanup crew bestie πŸ’… β€” it should tidy up and free the key object generation context genctx, no leftovers, no leaks, periodt.

Then OSSL_FUNC_keymgmt_load() is the glow-up-from-a-reference function ✨ β€” it creates a provider side key object based on a reference object with a size of reference_sz bytes. That reference is something only the provider knows how to interpret, but it may come from other operations. Outside the provider, this reference is simply an array of bytes (iconic, honestly).

And here's the mandatory vibe check, so listen up πŸ‘‘: at least one of OSSL_FUNC_keymgmt_new(), OSSL_FUNC_keymgmt_gen() and OSSL_FUNC_keymgmt_load() are mandatory, as well as OSSL_FUNC_keymgmt_free() and OSSL_FUNC_keymgmt_has(). Additionally, if OSSL_FUNC_keymgmt_gen() is present, OSSL_FUNC_keymgmt_gen_init() and OSSL_FUNC_keymgmt_gen_cleanup() must be present as well. No half-committing to the group chat 🫢.


πŸ’– Key Object Information Functions πŸ’–

OSSL_FUNC_keymgmt_get_params() should extract information data associated with the given keydata, see "Common Information Parameters". It's giving "tell me everything about this key" energy πŸ”.

OSSL_FUNC_keymgmt_gettable_params() should return a constant array of descriptor OSSL_PARAM(3), for parameters that OSSL_FUNC_keymgmt_get_params() can handle. Like a menu of what you're allowed to ask for πŸ“‹.

And no cap: if OSSL_FUNC_keymgmt_gettable_params() is present, OSSL_FUNC_keymgmt_get_params() must also be present, and vice versa. They're a package deal, iykyk πŸŽ€.

OSSL_FUNC_keymgmt_set_params() should update information data associated with the given keydata, see "Common Information Parameters". The reverse glow-up πŸ’….

OSSL_FUNC_keymgmt_settable_params() should return a constant array of descriptor OSSL_PARAM(3), for parameters that OSSL_FUNC_keymgmt_set_params() can handle.

Same rules fr fr: if OSSL_FUNC_keymgmt_settable_params() is present, OSSL_FUNC_keymgmt_set_params() must also be present, and vice versa πŸ’–.

πŸ¦‹ Key Object Checking Functions πŸ¦‹

OSSL_FUNC_keymgmt_query_operation_name() should return the name of the supported algorithm for the operation operation_id. This is similar to provider_query_operation() (see provider-base(7)), but only works as an advisory β€” it's an opinion, not a decree πŸ’β€β™€οΈ. If this function is not present, or returns NULL, the caller is free to assume that there's an algorithm from the same provider, of the same name as the one used to fetch the keymgmt and try to use that. Slay, flexible queen.

OSSL_FUNC_keymgmt_has() should check whether the given keydata contains the subsets of data indicated by the selector. A combination of several selector bits must consider all those subsets, not just one πŸ”₯. An implementation is, however, free to consider an empty subset of data to still be a valid subset. For algorithms where some selection is not meaningful such as OSSL_KEYMGMT_SELECT_DOMAIN_PARAMETERS for RSA keys the function should just return 1 as the selected subset is not really missing in the key. Lowkey "I have what I have, bestie" behaviour.

OSSL_FUNC_keymgmt_validate() should check if the keydata contains valid data subsets indicated by selection. Some combined selections of data subsets may cause validation of the combined data πŸ‘€. For example, the combination of OSSL_KEYMGMT_SELECT_PRIVATE_KEY and OSSL_KEYMGMT_SELECT_PUBLIC_KEY (or OSSL_KEYMGMT_SELECT_KEYPAIR for short) is expected to check that the pairwise consistency of keydata is valid β€” like checking that the private and public keys are actually in the same situationship πŸ’ž.

The checktype parameter controls what type of check is performed on the subset of data. Two types of check are defined: OSSL_KEYMGMT_VALIDATE_FULL_CHECK and OSSL_KEYMGMT_VALIDATE_QUICK_CHECK. The interpretation of how much checking is performed in a full check versus a quick check is key type specific β€” so it's giving "each algorithm does its own thing" 🌈. Some providers may have no distinction between a full check and a quick check. For algorithms where some selection is not meaningful such as OSSL_KEYMGMT_SELECT_DOMAIN_PARAMETERS for RSA keys the function should just return 1 as there is nothing to validate for that selection. Standing there with nothing to do and still returning 1? Main character energy ⭐.

OSSL_FUNC_keymgmt_match() should check if the data subset indicated by selection in keydata1 and keydata2 match. It is assumed that the caller has ensured that keydata1 and keydata2 are both owned by the implementation of this function β€” like, don't bring a key from another provider's party πŸ™ˆ.


πŸŽ€ Key Object Import, Export and Duplication Functions πŸŽ€

OSSL_FUNC_keymgmt_import() should import data indicated by selection into keydata with values taken from the OSSL_PARAM(3) array params. Come through, data πŸ“₯✨.

OSSL_FUNC_keymgmt_export() should extract values indicated by selection from keydata, create an OSSL_PARAM(3) array with them and call param_cb with that array as well as the given cbarg. Sending it right back out 🧚.

OSSL_FUNC_keymgmt_import_types() and OSSL_FUNC_keymgmt_import_types_ex() should return a constant array of descriptor OSSL_PARAM(3) for data indicated by selection, for parameters that OSSL_FUNC_keymgmt_import() can handle. Either OSSL_FUNC_keymgmt_import_types() or OSSL_FUNC_keymgmt_import_types_ex(), must be implemented, if OSSL_FUNC_keymgmt_import_types_ex() is implemented, then it is preferred over OSSL_FUNC_keymgmt_import_types(). Providers that are supposed to be backward compatible with OpenSSL 3.0 or 3.1 must continue to implement OSSL_FUNC_keymgmt_import_types(). So the _ex version is the new fav πŸ’… but the old one still needs to show up for the legacy besties 🫢.

OSSL_FUNC_keymgmt_export_types() and OSSL_FUNC_keymgmt_export_types_ex() should return a constant array of descriptor OSSL_PARAM(3) for data indicated by selection, that the OSSL_FUNC_keymgmt_export() callback can expect to receive. Either OSSL_FUNC_keymgmt_export_types() or OSSL_FUNC_keymgmt_export_types_ex(), must be implemented, if OSSL_FUNC_keymgmt_export_types_ex() is implemented, then it is preferred over OSSL_FUNC_keymgmt_export_types(). Providers that are supposed to be backward compatible with OpenSSL 3.0 or 3.1 must continue to implement OSSL_FUNC_keymgmt_export_types(). Same rules, no exceptions, periodt ✨.

OSSL_FUNC_keymgmt_dup() should duplicate data subsets indicated by selection or the whole key data keydata_from and create a new provider side key object with the data. Twin sister behaviour, obsessed πŸ’–.


🌸 Common Information Parameters 🌸

See OSSL_PARAM(3) for further details on the parameters structure.

Common information parameters currently recognised by all built-in keymgmt algorithms are as follows:

"bits" (OSSL_PKEY_PARAM_BITS) <integer>

The value should be the cryptographic length of the cryptosystem to which the key belongs, in bits. The definition of cryptographic length is specific to the key cryptosystem β€” so don't come for the meaning, it varies by algorithm 😌.

"max-size" (OSSL_PKEY_PARAM_MAX_SIZE) <integer>

The value should be the maximum size that a caller should allocate to safely store a signature (called sig in provider-signature(7)), the result of asymmetric encryption / decryption (out in provider-asym_cipher(7)), a derived secret (secret in provider-keyexch(7)), and similar data.

Providers need to implement this parameter in order to properly support various use cases such as CMS signing. Like, it's genuinely required, not optional aesthetic 🌈.

Because an EVP_KEYMGMT method is always tightly bound to another method (signature, asymmetric cipher, key exchange, ...) and must be of the same provider, this number only needs to be synchronised with the dimensions handled in the rest of the same provider. Stay in your lane, but make sure your lane knows the number πŸ’….

"security-bits" (OSSL_PKEY_PARAM_SECURITY_BITS) <integer>

The value should be the number of security bits of the given key. Bits of security is defined in SP800-57. Cited source, we love an academic queen πŸ“šβœ¨.

"mandatory-digest" (OSSL_PKEY_PARAM_MANDATORY_DIGEST) <UTF8 string>

If there is a mandatory digest for performing a signature operation with keys from this keymgmt, this parameter should get its name as value.

When EVP_PKEY_get_default_digest_name() queries this parameter and it's filled in by the implementation, its return value will be 2.

If the keymgmt implementation fills in the value "" or "UNDEF", EVP_PKEY_get_default_digest_name(3) will place the string "UNDEF" into its argument mdname. This signifies that no digest should be specified with the corresponding signature operation. So like, no digest, by decree πŸ‘‘

"default-digest" (OSSL_PKEY_PARAM_DEFAULT_DIGEST) <UTF8 string>

If there is a default digest for performing a signature operation with keys from this keymgmt, this parameter should get its name as value.

When EVP_PKEY_get_default_digest_name(3) queries this parameter and it's filled in by the implementation, its return value will be 1. Note that if OSSL_PKEY_PARAM_MANDATORY_DIGEST is responded to as well, EVP_PKEY_get_default_digest_name(3) ignores the response to this parameter. Rude? A little. But the rules are the rules 😭.

If the keymgmt implementation fills in the value "" or "UNDEF", EVP_PKEY_get_default_digest_name(3) will place the string "UNDEF" into its argument mdname. This signifies that no digest has to be specified with the corresponding signature operation, but may be specified as an option. Optional, not mandatory β€” the difference matters bestie πŸ’….


The OpenSSL FIPS provider also supports the following parameters:

"fips-indicator" (OSSL_PKEY_PARAM_FIPS_APPROVED_INDICATOR) <integer>

A getter that returns 1 if the operation is FIPS approved, or 0 otherwise. This may be used after calling OSSL_FUNC_keymgmt_gen() function. It may return 0 if either the "key-check", or "sign-check" are set to 0. The receipts are right there 🧾✨.

"key-check" (OSSL_PKEY_PARAM_FIPS_KEY_CHECK) <integer>

If required this parameter should be set using OSSL_FUNC_keymgmt_gen_set_params() or OSSL_FUNC_keymgmt_gen_init(). The default value of 1 causes an error during the init if the key is not FIPS approved (e.g. The key has a security strength of less than 112 bits). Setting this to 0 will ignore the error and set the approved "fips-indicator" to 0. This option breaks FIPS compliance if it causes the approved "fips-indicator" to return 0.

⚠️ Yeah, that last bit is serious β€” it breaks FIPS compliance. Don't just vibe your way through that one πŸ’€.

"sign-check" (OSSL_PKEY_PARAM_FIPS_SIGN_CHECK) <integer>

If required this parameter should be set before the OSSL_FUNC_keymgmt_gen() function. This value is not supported by all keygen algorithms β€” so check before you assume, bestie πŸ™ˆ. The default value of 1 will cause an error if the generated key is not allowed to be used for signing. Setting this to 0 will ignore the error and set the approved "fips-indicator" to 0. This option breaks FIPS compliance if it causes the approved "fips-indicator" to return 0.

⚠️ Same energy: breaks FIPS compliance. Not a cute look πŸ‘‘.

πŸ“‹ RETURN VALUES πŸ“‹

Here's the graded report card, no cap πŸŽ“:

  • OSSL_FUNC_keymgmt_new() and OSSL_FUNC_keymgmt_dup() should return a valid reference to the newly created provider side key object, or NULL on failure. New key, who dis ✨.
  • OSSL_FUNC_keymgmt_import(), OSSL_FUNC_keymgmt_export(), OSSL_FUNC_keymgmt_get_params() and OSSL_FUNC_keymgmt_set_params() should return 1 for success or 0 on error.
  • OSSL_FUNC_keymgmt_validate() should return 1 on successful validation, or 0 on failure. Validated, slay πŸ”₯.
  • OSSL_FUNC_keymgmt_has() should return 1 if all the selected data subsets are contained in the given keydata or 0 otherwise.
  • OSSL_FUNC_keymgmt_query_operation_name() should return a pointer to a string matching the requested operation, or NULL if the same name used to fetch the keymgmt applies.
  • OSSL_FUNC_keymgmt_gettable_params() and OSSL_FUNC_keymgmt_settable_params(), OSSL_FUNC_keymgmt_import_types(), OSSL_FUNC_keymgmt_import_types_ex(), OSSL_FUNC_keymgmt_export_types(), OSSL_FUNC_keymgmt_export_types_ex() should always return a constant OSSL_PARAM(3) array πŸ’–.

✨ SEE ALSO ✨

ok bestie, if you wanna go deeper (and you know you do πŸ‘€), these are the pages to pull up next:

like, that's the whole friend group right there πŸ’– go say hi.


🌸 HISTORY 🌸

the lore drop, because we love a timeline πŸ“œβœ¨

  • the KEYMGMT interface? introduced in OpenSSL 3.0 β€” the moment it all began, no cap.
  • functions OSSL_FUNC_keymgmt_import_types_ex() and OSSL_FUNC_keymgmt_export_types_ex() were added with OpenSSL 3.2. glow-up era πŸ¦‹
  • the functions OSSL_FUNC_keymgmt_gen_get_params() and OSSL_FUNC_keymgmt_gen_gettable_params() were added in OpenSSL 3.4.
  • the parameters "sign-check" and "fips-indicator" were added in OpenSSL 3.4. yes queen, more params πŸ’…
  • support for the ML-DSA, ML-KEM and SLH-DSA algorithms was added in OpenSSL 3.5. main character algorithms honestly πŸ”₯

Copyright 2019-2025 The OpenSSL Project Authors. All Rights Reserved.

licensed under the Apache License 2.0 (the "License"). you may not use this file except in compliance with the License πŸ’€ like, actually read it, bestie. you can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.


and that's a wrap on PROVIDER-KEYMGMT(7ossl) πŸŽ€ you made it to the end, i'm so proud of you fr fr 🫢 this page shipped as part of OpenSSL 3.5.9, dated 2026-09-29 β€” screenshot it, frame it, put it on your wall, it's giving iconic πŸŒˆπŸ’œ

πŸ“¦ where this page comes from