=pod =head1 NAME provider-keymgmt - The KEYMGMT library E-E provider functions =head1 SYNOPSIS #include /* * 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 *OP_keymgmt_new(void *provctx); void OP_keymgmt_free(void *keydata); /* Key object information */ int OP_keymgmt_get_params(void *keydata, OSSL_PARAM params[]); const OSSL_PARAM *OP_keymgmt_gettable_params(void); /* Key object content checks */ int OP_keymgmt_has(void *keydata, int selection); /* Discovery of supported operations */ const char *OP_keymgmt_query_operation_name(int operation_id); /* Key object import and export functions */ int OP_keymgmt_import(int selection, void *keydata, const OSSL_PARAM params[]); const OSSL_PARAM *OP_keymgmt_import_types, (int selection); int OP_keymgmt_export(int selection, void *keydata, OSSL_CALLBACK *param_cb, void *cbarg); const OSSL_PARAM *OP_keymgmt_export_types(int selection); /* Key object validation */ int OP_keymgmt_validate(void *keydata, int selection); /* Discovery of supported operations */ const char *OP_keymgmt_query_operation_name(int operation_id); =head1 DESCRIPTION The KEYMGMT operation doesn't have much public visibility in OpenSSL libraries, it's rather an internal operation that's designed to work in tandem with operations that use private/public key pairs. Because the KEYMGMT operation shares knowledge with the operations it works with in tandem, they must belong to the same provider. The OpenSSL libraries will ensure that they do. The primary responsibility of the KEYMGMT operation is to hold the provider side key data for the OpenSSL library EVP_PKEY structure. All "functions" mentioned here are passed as function pointers between F and the provider in B arrays via B arrays that are returned by the provider's provider_query_operation() function (see L). All these "functions" have a corresponding function type definition named B, and a helper function to retrieve the function pointer from a B element named B. For example, the "function" OP_keymgmt_new() has these: typedef void *(OSSL_OP_keymgmt_new_fn)(void *provctx); static ossl_inline OSSL_OP_keymgmt_new_fn OSSL_get_OP_keymgmt_new(const OSSL_DISPATCH *opf); B arrays are indexed by numbers that are provided as macros in L, as follows: OP_keymgmt_new OSSL_FUNC_KEYMGMT_NEW OP_keymgmt_free OSSL_FUNC_KEYMGMT_FREE OP_keymgmt_get_params OSSL_FUNC_KEYMGMT_GET_PARAMS OP_keymgmt_gettable_params OSSL_FUNC_KEYMGMT_GETTABLE_PARAMS OP_keymgmt_query_operation_name OSSL_FUNC_KEYMGMT_QUERY_OPERATION_NAME OP_keymgmt_has OSSL_FUNC_KEYMGMT_HAS OP_keymgmt_validate OSSL_FUNC_KEYMGMT_VALIDATE OP_keymgmt_import OSSL_FUNC_KEYMGMT_IMPORT OP_keymgmt_import_types OSSL_FUNC_KEYMGMT_IMPORT_TYPES OP_keymgmt_export OSSL_FUNC_KEYMGMT_EXPORT OP_keymgmt_export_types OSSL_FUNC_KEYMGMT_EXPORT_TYPES =head2 Key Objects A key object is a collection of data for an asymmetric key, and is represented as I in this manual. The exact contents of a key object are defined by the provider, and it is assumed that different operations in one and the same provider use the exact same structure to represent this collection of data, so that for example, a key object that has been created using the KEYMGMT interface that we document here can be passed as is to other provider operations, such as OP_signature_sign_init() (see L). With some of the KEYMGMT functions, it's possible to select a specific subset of data to handle, governed by the bits in a I indicator. The bits are: =over 4 =item B Indicating that the private key data in a key object should be considered. =item B Indicating that the public key data in a key object should be considered. =item B Indicating that the domain parameters in a key object should be considered. =item B 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. =back Some selector bits have also been combined for easier use: =over 4 =item B Indicating that all key object parameters should be considered, regardless of their more granular classification. =for comment This should used by EVP functions such as EVP_PKEY_copy_parameters() and EVP_PKEY_cmp_parameters() This is a combination of B and B. =for comment If more parameter categories are added, they should be mentioned here too. =item B 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 B and B. =item B Indicating that everything in a key object should be considered. =back The exact interpretation of those bits or how they combine is left to each function where you can specify a selector. =for comment One might think that a combination of bits means that all the selected data subsets must be considered, but then you have to consider that when comparing key objects (future function), an implementation might opt to not compare the private key if it has compared the public key, since a match of one half implies a match of the other half. =head2 Constructing and Destructing Functions OP_keymgmt_new() should create a provider side key object. The provider context I is passed and may be incorporated in the key object, but that is not mandatory. OP_keymgmt_free() should free the passed I. The constructor and destructor are mandatory, a KEYMGMT implementation without them will not be accepted. =for comment when new constructors appear, it's sufficient if only one of them is present. The remark above will have to change to reflect that. =head2 Key Object Information Functions OP_keymgmt_get_params() should extract information data associated with the given I, see L. OP_keymgmt_gettable_params() should return a constant array of descriptor B, for parameters that OP_keymgmt_get_params() can handle. If OP_keymgmt_gettable_params() is present, OP_keymgmt_get_params() must also be present. =head2 Key Object Checking Functions OP_keymgmt_query_operation_name() should return the name of the supported algorithm for the operation I. This is similar to provider_query_operation() (see L), but only works as an advisory. 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. OP_keymgmt_has() should check whether the given I the subsets of data indicated by the I. 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. OP_keymgmt_validate() should check if the I contains valid data subsets indicated by I. Some combined selections of data subsets may cause validation of the combined data. For example, the combination of B and B (or B for short) is expected to check that the pairwise consistency of I is valid. =head2 Key Object Import and Export Functions OP_keymgmt_import() should import data indicated by I into I with values taken from the B array I. OP_keymgmt_export() should extract values indicated by I from I, create an B array with them and call I with that array as well as the given I. OP_keymgmt_import_types() should return a constant array of descriptor B for data indicated by I, for parameters that OP_keymgmt_import() can handle. OP_keymgmt_export_types() should return a constant array of descriptor B for data indicated by I, that the OP_keymgmt_export() callback can expect to receive. =head2 Information Parameters See L for further details on the parameters structure. Parameters currently recognised by built-in keymgmt algorithms' OP_keymgmt_get_params: =over 4 =item "bits" (B) 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. =item "max-size" (B) The value should be the maximum size that a caller should allocate to safely store a signature (called I in L), the result of asymmmetric encryption / decryption (I in L, a derived secret (I in L, and similar data). 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. =item "security-bits" (B) The value should be the number of security bits of the given key. Bits of security is defined in SP800-57. =back =head1 SEE ALSO L =head1 HISTORY The KEYMGMT interface was introduced in OpenSSL 3.0. =head1 COPYRIGHT Copyright 2019-2020 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. You can obtain a copy in the file LICENSE in the source distribution or at L. =cut