PROVIDER-KEYMGMT(7SSL)

📦

version 4.0.3 · 13 versions

💖 PROVIDER-KEYMGMT 💖 (that's the `7SSL` manual, bestie)

okay so this is the OpenSSL page for provider-keymgmt, and no cap, it is the page about the KEYMGMT library <-> provider functions. it's giving internal plumbing, but the plumbing is iconic ✨

✨ 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_new_ex(void *provctx, const OSSL_PARAM params[]);
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);

🦋 DESCRIPTION 🦋

okay so real talk — the KEYMGMT operation doesn't really have much public visibility in the OpenSSL libraries. she's lowkey an internal operation, designed to work in tandem with operations that use private/public key pairs. behind-the-scenes main character energy 💅

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 that they do. no mixing, no matching, periodt.

the primary responsibility of the KEYMGMT operation is to hold the provider side key data for the OpenSSL library EVP_PKEY structure. that's the whole gig ✨

all the "functions" mentioned here are passed as function pointers between libcrypto and the provider in OSSL_DISPATCH(3) arrays via OSSL_ALGORITHM(3) arrays that get returned by the provider's provider_query_operation() function (peep "Provider Functions" in provider-base(7)).

and every single one of these "functions" has a matching function type definition named OSSL_FUNC_{name}_fn, plus a helper function to grab the function pointer from an OSSL_DISPATCH(3) element named OSSL_FUNC_{name}. like, for example, the "function" OSSL_FUNC_keymgmt_new() has these:

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 that are provided as macros in openssl-core_dispatch.h(7), and they line up 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 a collection of data for an asymmetric key, and in this manual it gets called keydata. cute, right?

the exact contents of a key object are defined by the provider, and it's assumed that different operations in one and the same provider use the exact same structure to represent this collection of data. so like, a key object that was created using the KEYMGMT interface we're documenting right here can be passed as-is to other provider operations, such as OP_signature_sign_init() (see provider-signature(7)). sharing is caring 🫶

with some of the KEYMGMT functions, it's possible to select a specific subset of data to handle, governed by the bits in a selection indicator. the bits are:

OSSL_KEYMGMT_SELECT_PRIVATE_KEY — indicating that the private key data in a key object should be considered.
OSSL_KEYMGMT_SELECT_PUBLIC_KEY — indicating that the public key data in a key object should be considered.
OSSL_KEYMGMT_SELECT_DOMAIN_PARAMETERS — indicating that the domain parameters in a key object should be considered.
OSSL_KEYMGMT_SELECT_OTHER_PARAMETERS — indicating that other parameters in a key object should be considered.

other parameters are key parameters that don't fit any other classification. in other words, this particular selector bit works as a last resort bit bucket selector. it's the catch-all bestie 💀

some selector bits have also been combined for easier use:

OSSL_KEYMGMT_SELECT_ALL_PARAMETERS — indicating that 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 — indicating that both 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 — indicating that everything in a key object should be considered.

the exact interpretation of those bits or how they combine is left to each function where you can specify a selector. it's also left to the provider implementation to decide what's reasonable to do with regards to received selector bits and how to do it. among others, an implementation of OSSL_FUNC_keymgmt_match() might opt to not compare the private half if it has already compared the public half, since a match of one half implies a match of the other half. efficient! we love to see it 👑

🎀 Constructing and Destructing Functions 🎀

OSSL_FUNC_keymgmt_new() should create a provider side key object. the provider context provctx is passed and may be incorporated in the key object, but that is not mandatory. OSSL_FUNC_keymgmt_new_ex() may optionally be defined and does the same as OSSL_FUNC_keymgmt_new(), but also accepts an array of parameters. currently no parameters are defined for this function.
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() work together as a more elaborate context based key object constructor. it's a whole squad fr fr ✨
OSSL_FUNC_keymgmt_gen_init() should create the key object generation context and initialize it with selections, which will 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 from which content that the implementation chooses can be used as a template for the key object to be generated. typically, the generation of a DSA or DH key would get the domain parameters from this template.
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.

🌸 okay bestie that's part 1! there's more coming, don't go anywhere 💖

OSSL_FUNC_keymgmt_gen() is the one that actually ✨does the thing✨ — it's the whole key object generation moment, bestie. It generates the key object itself and hands back the result. And the cb callback? You're calling that at regular intervals to spill how far along the generation is, like a little progress bar for your bestie 💅

OSSL_FUNC_keymgmt_gen_cleanup() handles the ✨aftermath✨ — it cleans up and frees the key object generation context genctx. Say thank you and let it go 🎀

OSSL_FUNC_keymgmt_load() builds a provider-side key object from a reference object that's reference_sz bytes big. Only the provider knows how to interpret it, but listen — that reference can come from other operations too. Outside the provider? It's literally just an array of bytes. Nothing more, nothing less 🦋

⚠️ Mandatory-functions vibe check: you need at least one of OSSL_FUNC_keymgmt_new(), OSSL_FUNC_keymgmt_gen() and OSSL_FUNC_keymgmt_load() — that's non-negotiable. Also OSSL_FUNC_keymgmt_free() and OSSL_FUNC_keymgmt_has() are required, periodt. And if you've got OSSL_FUNC_keymgmt_gen() in the mix, then OSSL_FUNC_keymgmt_gen_init() and OSSL_FUNC_keymgmt_gen_cleanup() must be there too. Package deal, no exceptions 😭

🧠 Key Object Information Functions 💖

OSSL_FUNC_keymgmt_get_params() pulls out the info data attached to the given keydata — go check out "Common Information Parameters" for the deets 🍓

OSSL_FUNC_keymgmt_gettable_params() returns a constant array of descriptor OSSL_PARAM(3), covering all the parameters that OSSL_FUNC_keymgmt_get_params() can handle ✨

Ok so if OSSL_FUNC_keymgmt_gettable_params() is present, then OSSL_FUNC_keymgmt_get_params() must be present too — and vice versa. They're a package deal, they do not go anywhere without each other 💀

OSSL_FUNC_keymgmt_set_params() updates the info data attached to the given keydata — again, see "Common Information Parameters" 🌸

OSSL_FUNC_keymgmt_settable_params() returns a constant array of descriptor OSSL_PARAM(3), covering all the parameters that OSSL_FUNC_keymgmt_set_params() can handle ✨

Same rule, different duo: if OSSL_FUNC_keymgmt_settable_params() is present, OSSL_FUNC_keymgmt_set_params() must be present too — and vice versa. Iconic symmetry tbh 🫶

🔍 Key Object Checking Functions 👑

OSSL_FUNC_keymgmt_query_operation_name() should return the name of the supported algorithm for the operation_id operation. It's lowkey similar to provider_query_operation() (peep provider-base(7)), but it only works as an advisory. So if this function isn't there, or it returns NULL? The caller is totally free to assume there's an algorithm from the same provider, with the same name as the one used to fetch the keymgmt, and just try to use that. Casual 💅

OSSL_FUNC_keymgmt_has() checks whether the given keydata contains the subsets of data indicated by the selector. And careful — a combination of several selector bits has to consider all those subsets, not just one of them. That said, an implementation is free to consider an empty subset of data as still being a valid subset ✨

For algorithms where some selection isn't meaningful — like OSSL_KEYMGMT_SELECT_DOMAIN_PARAMETERS for RSA keys — the function should just return 1, because that selected subset isn't really missing from the key. No drama needed 🎀

OSSL_FUNC_keymgmt_validate() checks if the keydata contains valid data subsets indicated by selection. Some combined selections of data subsets may trigger 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. The checktype parameter controls what type of check gets performed on the subset of data. Two types of check are defined: OSSL_KEYMGMT_VALIDATE_FULL_CHECK and OSSL_KEYMGMT_VALIDATE_QUICK_CHECK. How much checking actually happens in a full check versus a quick check is key type specific — some providers straight up have no distinction between the two. And for algorithms where some selection isn't meaningful, like OSSL_KEYMGMT_SELECT_DOMAIN_PARAMETERS for RSA keys, the function should just return 1, because there's literally nothing to validate for that selection 💅

OSSL_FUNC_keymgmt_match() checks if the data subset indicated by selection in keydata1 and keydata2 match. And it's assumed that the caller already made sure keydata1 and keydata2 are both owned by the implementation of this function. That's a you problem, not a me problem 💀

📦 Key Object Import, Export and Duplication Functions 🌈

OSSL_FUNC_keymgmt_import() imports data indicated by selection into keydata, with the values taken from the OSSL_PARAM(3) array params ✨

OSSL_FUNC_keymgmt_export() extracts the values indicated by selection from keydata, builds an OSSL_PARAM(3) array with them, then calls param_cb with that array plus the given cbarg 🎀

OSSL_FUNC_keymgmt_import_types() and OSSL_FUNC_keymgmt_import_types_ex() return a constant array of descriptor OSSL_PARAM(3) for the data indicated by selection — for the parameters that OSSL_FUNC_keymgmt_import() can handle.

Fr fr, this matters: 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(). And providers that are supposed to be backward compatible with OpenSSL 3.0 or 3.1 must continue to implement OSSL_FUNC_keymgmt_import_types(). No skipping 😤

OSSL_FUNC_keymgmt_export_types() and OSSL_FUNC_keymgmt_export_types_ex() return a constant array of descriptor OSSL_PARAM(3) for the data indicated by selection, which is data that the OSSL_FUNC_keymgmt_export() callback can expect to receive.

Same energy here: 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, it is preferred over OSSL_FUNC_keymgmt_export_types(). And providers that need to stay backward compatible with OpenSSL 3.0 or 3.1 must continue to implement OSSL_FUNC_keymgmt_export_types() 🫶

OSSL_FUNC_keymgmt_dup() duplicates the data subsets indicated by selection, or the whole key data keydata_from, and creates a new provider-side key object with that data. Copy-paste but make it ✨legit✨ 🦋

📋 Common Information Parameters 🌸

Peep OSSL_PARAM(3) for the full rundown on the parameters structure 💜

The common information parameters that are 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 the key belongs to, in bits. And how "cryptographic length" is defined is specific to that key cryptosystem, iykyk ✨
"max-size" (OSSL_PKEY_PARAM_MAX_SIZE) <integer> — the value should be the maximum size a caller should allocate to safely store a signature (that's 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 🔥

Because an EVP_KEYMGMT method is always tightly bound to another method (signature, asymmetric cipher, key exchange, ...) and has to be from 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 bestie 💅

"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 🎀
"security-category" (OSSL_PKEY_PARAM_SECURITY_CATEGORY) <integer> — the value is the NIST post-quantum security category (link: https://nvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8547.ipd.pdf) for the algorithm. It's an integer value in the range [0, 5], inclusive 🦋
"mandatory-digest" (OSSL_PKEY_PARAM_MANDATORY_DIGEST) <UTF8 string> — if there's 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 the implementation fills it in, its return value will be 2 ✨

If the keymgmt implementation fills in the value "" or "UNDEF", then EVP_PKEY_get_default_digest_name(3) will place the string "UNDEF" into its argument mdname. That signifies no digest should be specified with the corresponding signature operation 💀

"default-digest" (OSSL_PKEY_PARAM_DEFAULT_DIGEST) <UTF8 string> — if there's 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 the implementation fills it in, its return value will be 1. But heads up — if OSSL_PKEY_PARAM_MANDATORY_DIGEST gets responded to as well, then EVP_PKEY_get_default_digest_name(3) ignores the response to this parameter. Sorry not sorry 🙈

If the keymgmt implementation fills in the value "" or "UNDEF", then EVP_PKEY_get_default_digest_name(3) will place the string "UNDEF" into its argument mdname. That signifies no digest has to be specified with the corresponding signature operation, though it may still be specified as an option. Optional queen behavior 👑

"ri-type" (OSSL_PKEY_PARAM_CMS_RI_TYPE) <integer> — the value should be the CMS RecipientInfo type for the given key, like CMS_RECIPINFO_KEM or CMS_RECIPINFO_AGREE. The values you can pass through this parameter live in <openssl/cms.h>, and the macros all have names starting with "CMS_RECIPINFO_" 🌸

CMS will query this parameter first to work out the RecipientInfo type. If this parameter isn't filled in, CMS will check for known key types and map them to the appropriate RecipientInfo type. Otherwise, CMS will default to using CMS_RECIPINFO_TRANS. Default behavior, we love to see it 💅

"kemri-kdf-alg" (OSSL_PKEY_PARAM_CMS_KEMRI_KDF_ALGORITHM) <UTF8 string> — the value should be the DER-encoded X509_ALGOR for the default KDF for this key, if it supports the KEMRecipientInfo (CMS_RECIPINFO_KEM) type 🔥

Any KDF that takes OSSL_KDF_PARAM_KEY and OSSL_KDF_PARAM_INFO parameters and is otherwise fully defined by its OID can be used — for example, HKDF-SHA256 ✨

If OSSL_PKEY_PARAM_CMS_KEMRI_KDF_ALGORITHM isn't implemented, then HKDF-SHA256 will be used as the default KDF 🎀

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 the OSSL_FUNC_keymgmt_gen() function. It may return 0 if either the "key-check" or "sign-check" are set to 0 💜
"key-check" (OSSL_PKEY_PARAM_FIPS_KEY_CHECK) <integer> — bestie, if you need this one, set it with OSSL_FUNC_keymgmt_gen_set_params() or OSSL_FUNC_keymgmt_gen_init(). The default is 1, which means if your key ain't FIPS approved (think: security strength under 112 bits 😭) you get an error right at init. Set it to 0 and the error just… gets ignored, and the approved "fips-indicator" flips to 0. Heads up: this option breaks FIPS compliance if it makes that "fips-indicator" return 0. Not the vibe you want in a compliance audit 💀
"sign-check" (OSSL_PKEY_PARAM_FIPS_SIGN_CHECK) <integer> — if you need it, set this before the OSSL_FUNC_keymgmt_gen() function runs. Also ngl, not every keygen algorithm supports it. Default is 1, which throws an error if the freshly generated key isn't allowed to sign. Set it to 0 and the error is ignored and the approved "fips-indicator" gets set to 0. Same warning as above, no cap: this option breaks FIPS compliance if that "fips-indicator" ends up returning 0.

✨ RETURN VALUES ✨

Okay so here's the receipts on what each function hands back 💖

OSSL_FUNC_keymgmt_new() and OSSL_FUNC_keymgmt_dup() — should return a valid reference to the brand new provider side key object you just made, or NULL if it flopped.
OSSL_FUNC_keymgmt_import(), OSSL_FUNC_keymgmt_export(), OSSL_FUNC_keymgmt_get_params() and OSSL_FUNC_keymgmt_set_params() — return 1 for slay, 0 on error.
OSSL_FUNC_keymgmt_validate() — 1 when validation succeeds, 0 when it doesn't.
OSSL_FUNC_keymgmt_has() — 1 if all the selected data subsets are sitting inside the given keydata, 0 if not.
OSSL_FUNC_keymgmt_query_operation_name() — returns a pointer to a string matching the requested operation, or NULL if the same name you 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. Always. Periodt.

🌸 NOTES 🌸

LMS support is disabled by default at compile-time, fr fr. If you want it, specify the enable-lms build configuration option. That's the whole trick bestie 🫶

🦋 HISTORY 🦋

The lore, in order ✨

The KEYMGMT interface was introduced in OpenSSL 3.0.
Functions OSSL_FUNC_keymgmt_import_types_ex() and OSSL_FUNC_keymgmt_export_types_ex() were added with OpenSSL 3.2.
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.
Support for the ML-DSA, ML-KEM and SLH-DSA algorithms was added in OpenSSL 3.5.
Support for the LMS algorithm was added in OpenSSL 3.6.

💜 COPYRIGHT 💜

Licensed under the Apache License 2.0 (the "License"). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

That's a wrap on the whole page bestie 🎀 This part shipped as version 4.0.3, dated 2026-09-29, and it lives in the man page PROVIDER-KEYMGMT(7SSL). Go read the whole thing top to bottom, you ate this 💅✨

📦 where this page comes from

ubuntu stonking: openssl 4.0.3-1ubuntu1
💖 girlified by deepseek-ai/DeepSeek-V4.1-Flash on 2026-11-03: a language model's rewrite of the original, under its terms