mirror/openssl
2
0
Fork 0
mirror of https://github.com/openssl/openssl.git synced 2024-12-27 06:21:43 +08:00
Code Issues Packages Projects Releases Wiki Activity
63d0f4d2b0
openssl/crypto/encode_decode/decoder_pkey.c

464 lines
16 KiB
C
Raw Normal View History

SERIALIZER: Add functions to deserialize into an EVP_PKEY EVP_PKEY is the fundamental type for provider side code, so we implement specific support for it, in form of a special context constructor. This constructor looks up and collects all available KEYMGMT implementations, and then uses those names to collect deserializer implementations, as described in the previous commit. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12410)
2020-07-09 05:19:13 +08:00
/*
Update copyright year Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/14235)
2021-02-18 22:57:13 +08:00
* Copyright 2020-2021 The OpenSSL Project Authors. All Rights Reserved.
SERIALIZER: Add functions to deserialize into an EVP_PKEY EVP_PKEY is the fundamental type for provider side code, so we implement specific support for it, in form of a special context constructor. This constructor looks up and collects all available KEYMGMT implementations, and then uses those names to collect deserializer implementations, as described in the previous commit. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12410)
2020-07-09 05:19:13 +08:00
*
* 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
*/
#include <openssl/core_names.h>
CORE: Define provider-native abstract objects This is placed as CORE because the core of libcrypto is the authority for what is possible to do and what's required to make these abstract objects work. In essence, an abstract object is an OSSL_PARAM array with well defined parameter keys and values: - an object type, which is a number indicating what kind of libcrypto structure the object in question can be used with. The currently possible numbers are defined in <openssl/core_object.h>. - an object data type, which is a string that indicates more closely what the contents of the object are. - the object data, an octet string. The exact encoding used depends on the context in which it's used. For example, the decoder sub-system accepts any encoding, as long as there is a decoder implementation that takes that as input. If central code is to handle the data directly, DER encoding is assumed. (*) - an object reference, also an octet string. This octet string is not the object contents, just a mere reference to a provider-native object. (**) - an object description, which is a human readable text string that can be displayed if some software desires to do so. The intent is that certain provider-native operations (called X here) are able to return any sort of object that belong with other operations, or an object that has no provider support otherwise. (*) A future extension might be to be able to specify encoding. (**) The possible mechanisms for dealing with object references are: - An object loading function in the target operation. The exact target operation is determined by the object type (for example, OSSL_OBJECT_PKEY implies that the target operation is a KEYMGMT) and the implementation to be fetched by its object data type (for an OSSL_OBJECT_PKEY, that's the KEYMGMT keytype to be fetched). This loading function is only useful for this if the implementations that are involved (X and KEYMGMT, for example) are from the same provider. - An object exporter function in the operation X implementation. That exporter function can be used to export the object data in OSSL_PARAM form that can be imported by a target operation's import function. This can be used when it's not possible to fetch the target operation implementation from the same provider. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12512)
2020-07-22 21:34:25 +08:00
#include <openssl/core_object.h>
DECODER: Add input structure support for EVP_PKEY decoding OSSL_DECODER_CTX_new_by_EVP_PKEY() takes one more argument to express the desired outermost structure for the input. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 20:17:42 +08:00
#include <openssl/provider.h>
SERIALIZER: Add functions to deserialize into an EVP_PKEY EVP_PKEY is the fundamental type for provider side code, so we implement specific support for it, in form of a special context constructor. This constructor looks up and collects all available KEYMGMT implementations, and then uses those names to collect deserializer implementations, as described in the previous commit. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12410)
2020-07-09 05:19:13 +08:00
#include <openssl/evp.h>
DESERIALIZER: Implement decryption of password protected objects This implements these functions: OSSL_DESERIALIZER_CTX_set_cipher() OSSL_DESERIALIZER_CTX_set_passphrase() OSSL_DESERIALIZER_CTX_set_passphrase_ui() OSSL_DESERIALIZER_CTX_set_passphrase_cb() To be able to deal with multiple deserializers trying to work on the same byte array and wanting to decrypt it while doing so, the deserializer caches the passphrase. This cache is cleared at the end of OSSL_DESERIALIZER_from_bio(). Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12410)
2020-07-10 21:13:55 +08:00
#include <openssl/ui.h>
Rename OSSL_SERIALIZER / OSSL_DESERIALIZER to OSSL_ENCODE / OSSL_DECODE Fixes #12455 Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12660)
2020-08-17 03:25:08 +08:00
#include <openssl/decoder.h>
SERIALIZER: Add functions to deserialize into an EVP_PKEY EVP_PKEY is the fundamental type for provider side code, so we implement specific support for it, in form of a special context constructor. This constructor looks up and collects all available KEYMGMT implementations, and then uses those names to collect deserializer implementations, as described in the previous commit. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12410)
2020-07-09 05:19:13 +08:00
#include <openssl/safestack.h>
DECODER: Add tracing Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-28 17:13:24 +08:00
#include <openssl/trace.h>
SERIALIZER: Add functions to deserialize into an EVP_PKEY EVP_PKEY is the fundamental type for provider side code, so we implement specific support for it, in form of a special context constructor. This constructor looks up and collects all available KEYMGMT implementations, and then uses those names to collect deserializer implementations, as described in the previous commit. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12410)
2020-07-09 05:19:13 +08:00
#include "crypto/evp.h"
STORE: Add a built-in 'file:' storemgmt implementation (loader) This replaces the older 'file:' loader that is now an engine. It's still possible to use the older 'file:' loader by explicitly using the engine, and tests will remain for it as long as ENGINEs are still supported (even through deprecated). To support this storemgmt implementation, a few internal OSSL_DECODER modifications are needed: - An internal function that implements most of OSSL_DECODER_CTX_new_by_EVP_PKEY(), but operates on an already existing OSSL_DECODER_CTX instead of allocating a new one. - Allow direct creation of a OSSL_DECODER from an OSSL_ALGORITHM. It isn't attached to any provider, and is only used internally, to simply catch any DER encoded object to be passed back to the object callback with no further checking. This implementation becomes the last resort decoder, when all "normal" decodation attempts (i.e. those that are supposed to result in an OpenSSL object of some sort) have failed. Because file_store_attach() uses BIO_tell(), we must also support BIO_ctrl() as a libcrypto upcall. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/12587)
2020-08-02 18:46:00 +08:00
#include "crypto/decoder.h"
Rename OSSL_SERIALIZER / OSSL_DESERIALIZER to OSSL_ENCODE / OSSL_DECODE Fixes #12455 Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12660)
2020-08-17 03:25:08 +08:00
#include "encoder_local.h"
DECODER: Add input structure support for EVP_PKEY decoding OSSL_DECODER_CTX_new_by_EVP_PKEY() takes one more argument to express the desired outermost structure for the input. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 20:17:42 +08:00
#include "e_os.h" /* strcasecmp on Windows */
SERIALIZER: Add functions to deserialize into an EVP_PKEY EVP_PKEY is the fundamental type for provider side code, so we implement specific support for it, in form of a special context constructor. This constructor looks up and collects all available KEYMGMT implementations, and then uses those names to collect deserializer implementations, as described in the previous commit. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12410)
2020-07-09 05:19:13 +08:00
Rename OSSL_SERIALIZER / OSSL_DESERIALIZER to OSSL_ENCODE / OSSL_DECODE Fixes #12455 Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12660)
2020-08-17 03:25:08 +08:00
int OSSL_DECODER_CTX_set_passphrase(OSSL_DECODER_CTX *ctx,
const unsigned char *kstr,
size_t klen)
DESERIALIZER: Implement decryption of password protected objects This implements these functions: OSSL_DESERIALIZER_CTX_set_cipher() OSSL_DESERIALIZER_CTX_set_passphrase() OSSL_DESERIALIZER_CTX_set_passphrase_ui() OSSL_DESERIALIZER_CTX_set_passphrase_cb() To be able to deal with multiple deserializers trying to work on the same byte array and wanting to decrypt it while doing so, the deserializer caches the passphrase. This cache is cleared at the end of OSSL_DESERIALIZER_from_bio(). Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12410)
2020-07-10 21:13:55 +08:00
{
CORE: Generalise internal pass phrase prompter The pass phrase prompter that's part of OSSL_ENCODER and OSSL_DECODER is really a passphrase callback bridge between the diverse forms of prompters that exist within OpenSSL: pem_password_cb, ui_method and OSSL_PASSPHRASE_CALLBACK. This can be generalised, to be re-used by other parts of OpenSSL, and to thereby allow the users to specify whatever form of pass phrase callback they need, while being able to pass that on to other APIs that are called internally, in the form that those APIs demand. Additionally, we throw in the possibility to cache pass phrases during a "session" (we leave it to each API to define what a "session" is). This is useful for any API that implements discovery and therefore may need to get the same password more than once, such as OSSL_DECODER and OSSL_STORE. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12512)
2020-08-02 18:14:19 +08:00
return ossl_pw_set_passphrase(&ctx->pwdata, kstr, klen);
DESERIALIZER: Implement decryption of password protected objects This implements these functions: OSSL_DESERIALIZER_CTX_set_cipher() OSSL_DESERIALIZER_CTX_set_passphrase() OSSL_DESERIALIZER_CTX_set_passphrase_ui() OSSL_DESERIALIZER_CTX_set_passphrase_cb() To be able to deal with multiple deserializers trying to work on the same byte array and wanting to decrypt it while doing so, the deserializer caches the passphrase. This cache is cleared at the end of OSSL_DESERIALIZER_from_bio(). Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12410)
2020-07-10 21:13:55 +08:00
}
Rename OSSL_SERIALIZER / OSSL_DESERIALIZER to OSSL_ENCODE / OSSL_DECODE Fixes #12455 Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12660)
2020-08-17 03:25:08 +08:00
int OSSL_DECODER_CTX_set_passphrase_ui(OSSL_DECODER_CTX *ctx,
const UI_METHOD *ui_method,
void *ui_data)
DESERIALIZER: Implement decryption of password protected objects This implements these functions: OSSL_DESERIALIZER_CTX_set_cipher() OSSL_DESERIALIZER_CTX_set_passphrase() OSSL_DESERIALIZER_CTX_set_passphrase_ui() OSSL_DESERIALIZER_CTX_set_passphrase_cb() To be able to deal with multiple deserializers trying to work on the same byte array and wanting to decrypt it while doing so, the deserializer caches the passphrase. This cache is cleared at the end of OSSL_DESERIALIZER_from_bio(). Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12410)
2020-07-10 21:13:55 +08:00
{
CORE: Generalise internal pass phrase prompter The pass phrase prompter that's part of OSSL_ENCODER and OSSL_DECODER is really a passphrase callback bridge between the diverse forms of prompters that exist within OpenSSL: pem_password_cb, ui_method and OSSL_PASSPHRASE_CALLBACK. This can be generalised, to be re-used by other parts of OpenSSL, and to thereby allow the users to specify whatever form of pass phrase callback they need, while being able to pass that on to other APIs that are called internally, in the form that those APIs demand. Additionally, we throw in the possibility to cache pass phrases during a "session" (we leave it to each API to define what a "session" is). This is useful for any API that implements discovery and therefore may need to get the same password more than once, such as OSSL_DECODER and OSSL_STORE. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12512)
2020-08-02 18:14:19 +08:00
return ossl_pw_set_ui_method(&ctx->pwdata, ui_method, ui_data);
DESERIALIZER: Implement decryption of password protected objects This implements these functions: OSSL_DESERIALIZER_CTX_set_cipher() OSSL_DESERIALIZER_CTX_set_passphrase() OSSL_DESERIALIZER_CTX_set_passphrase_ui() OSSL_DESERIALIZER_CTX_set_passphrase_cb() To be able to deal with multiple deserializers trying to work on the same byte array and wanting to decrypt it while doing so, the deserializer caches the passphrase. This cache is cleared at the end of OSSL_DESERIALIZER_from_bio(). Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12410)
2020-07-10 21:13:55 +08:00
}
Rename OSSL_SERIALIZER / OSSL_DESERIALIZER to OSSL_ENCODE / OSSL_DECODE Fixes #12455 Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12660)
2020-08-17 03:25:08 +08:00
int OSSL_DECODER_CTX_set_pem_password_cb(OSSL_DECODER_CTX *ctx,
pem_password_cb *cb, void *cbarg)
DESERIALIZER: Implement decryption of password protected objects This implements these functions: OSSL_DESERIALIZER_CTX_set_cipher() OSSL_DESERIALIZER_CTX_set_passphrase() OSSL_DESERIALIZER_CTX_set_passphrase_ui() OSSL_DESERIALIZER_CTX_set_passphrase_cb() To be able to deal with multiple deserializers trying to work on the same byte array and wanting to decrypt it while doing so, the deserializer caches the passphrase. This cache is cleared at the end of OSSL_DESERIALIZER_from_bio(). Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12410)
2020-07-10 21:13:55 +08:00
{
CORE: Generalise internal pass phrase prompter The pass phrase prompter that's part of OSSL_ENCODER and OSSL_DECODER is really a passphrase callback bridge between the diverse forms of prompters that exist within OpenSSL: pem_password_cb, ui_method and OSSL_PASSPHRASE_CALLBACK. This can be generalised, to be re-used by other parts of OpenSSL, and to thereby allow the users to specify whatever form of pass phrase callback they need, while being able to pass that on to other APIs that are called internally, in the form that those APIs demand. Additionally, we throw in the possibility to cache pass phrases during a "session" (we leave it to each API to define what a "session" is). This is useful for any API that implements discovery and therefore may need to get the same password more than once, such as OSSL_DECODER and OSSL_STORE. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12512)
2020-08-02 18:14:19 +08:00
return ossl_pw_set_pem_password_cb(&ctx->pwdata, cb, cbarg);
DESERIALIZER: Implement decryption of password protected objects This implements these functions: OSSL_DESERIALIZER_CTX_set_cipher() OSSL_DESERIALIZER_CTX_set_passphrase() OSSL_DESERIALIZER_CTX_set_passphrase_ui() OSSL_DESERIALIZER_CTX_set_passphrase_cb() To be able to deal with multiple deserializers trying to work on the same byte array and wanting to decrypt it while doing so, the deserializer caches the passphrase. This cache is cleared at the end of OSSL_DESERIALIZER_from_bio(). Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12410)
2020-07-10 21:13:55 +08:00
}
DECODER: Add function to set an OSSL_PASSPHRASE_CALLBACK type callback This makes it possible to use OSSL_DECODER in functions that are passed a OSSL_PASSPHRASE_CALLBACK already. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12512)
2020-08-02 20:29:33 +08:00
int OSSL_DECODER_CTX_set_passphrase_cb(OSSL_DECODER_CTX *ctx,
OSSL_PASSPHRASE_CALLBACK *cb,
void *cbarg)
{
return ossl_pw_set_ossl_passphrase_cb(&ctx->pwdata, cb, cbarg);
}
SERIALIZER: Add functions to deserialize into an EVP_PKEY EVP_PKEY is the fundamental type for provider side code, so we implement specific support for it, in form of a special context constructor. This constructor looks up and collects all available KEYMGMT implementations, and then uses those names to collect deserializer implementations, as described in the previous commit. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12410)
2020-07-09 05:19:13 +08:00
/*
Rename OSSL_ENCODER_CTX_new_by_EVP_PKEY and OSSL_DECODER_CTX_new_by_EVP_PKEY Additional renames done in encoder and decoder implementation to follow the style. Fixes #13622 Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/14155)
2021-02-11 23:57:37 +08:00
* Support for OSSL_DECODER_CTX_new_for_pkey:
DESERIALIZER: Rethink password handling The OSSL_DESERIALIZER API makes the incorrect assumption that the caller must cipher and other pass phrase related parameters to the individual desserializer implementations, when the reality is that they only need a passphrase callback, and will be able to figure out the rest themselves from the input they get. We simplify it further by never passing any explicit passphrase to the provider implementation, and simply have them call the passphrase callback unconditionally when they need, leaving it to libcrypto code to juggle explicit passphrases, cached passphrases and actual passphrase callback calls. Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12544)
2020-07-28 00:39:58 +08:00
* The construct data, and collecting keymgmt information for it
SERIALIZER: Add functions to deserialize into an EVP_PKEY EVP_PKEY is the fundamental type for provider side code, so we implement specific support for it, in form of a special context constructor. This constructor looks up and collects all available KEYMGMT implementations, and then uses those names to collect deserializer implementations, as described in the previous commit. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12410)
2020-07-09 05:19:13 +08:00
*/
DEFINE_STACK_OF(EVP_KEYMGMT)
Rename OSSL_ENCODER_CTX_new_by_EVP_PKEY and OSSL_DECODER_CTX_new_by_EVP_PKEY Additional renames done in encoder and decoder implementation to follow the style. Fixes #13622 Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/14155)
2021-02-11 23:57:37 +08:00
struct decoder_pkey_data_st {
DECODER EVP_PKEY: Don't store all the EVP_KEYMGMTs OSSL_DECODER_CTX_new_by_EVP_PKEY() would keep copies of all the EVP_KEYMGMTs it finds. This turns out to be fragile in certain circumstances, so we switch to fetch the appropriate EVP_KEYMGMT when it's time to construct an EVP_PKEY from the decoded data instead. This has the added benefit that we now actually use the property query string that was given by the caller for these fetches. Fixes #13503 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/13661)
2020-12-11 01:33:16 +08:00
OSSL_LIB_CTX *libctx;
char *propq;
DECODER & ENCODER: Make sure to pass around the original selection bits When decoding a key and asking the keymgmt to import the key data, it was told that the key data includes everything. This may not be true, since the user may have specified a different selection, and some keymgmts may want to be informed. Our key decoders' export function, on the other hand, didn't care either, and simply export anything they could, regardless. In both cases, the selection that was specified by the user is now passed all the way. Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/15934)
2021-06-28 11:52:42 +08:00
int selection;
DECODER EVP_PKEY: Don't store all the EVP_KEYMGMTs OSSL_DECODER_CTX_new_by_EVP_PKEY() would keep copies of all the EVP_KEYMGMTs it finds. This turns out to be fragile in certain circumstances, so we switch to fetch the appropriate EVP_KEYMGMT when it's time to construct an EVP_PKEY from the decoded data instead. This has the added benefit that we now actually use the property query string that was given by the caller for these fetches. Fixes #13503 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/13661)
2020-12-11 01:33:16 +08:00
ENCODER & DECODER: Make a tighter coupling between en/decoders and keymgmt If there are keymgmts and en/decoders from the same provider, try to combine them first. This avoids unnecessary export/import dances, and also tries to avoid issues where the keymgmt doesn't fully support exporting and importing, which we can assume will be the case for HSM protected keys. Fixes #15932 Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from https://github.com/openssl/openssl/pull/15933)
2021-06-28 11:37:22 +08:00
STACK_OF(EVP_KEYMGMT) *keymgmts;
SERIALIZER: Add functions to deserialize into an EVP_PKEY EVP_PKEY is the fundamental type for provider side code, so we implement specific support for it, in form of a special context constructor. This constructor looks up and collects all available KEYMGMT implementations, and then uses those names to collect deserializer implementations, as described in the previous commit. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12410)
2020-07-09 05:19:13 +08:00
char *object_type; /* recorded object data type, may be NULL */
void **object; /* Where the result should end up */
};
Rename OSSL_ENCODER_CTX_new_by_EVP_PKEY and OSSL_DECODER_CTX_new_by_EVP_PKEY Additional renames done in encoder and decoder implementation to follow the style. Fixes #13622 Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/14155)
2021-02-11 23:57:37 +08:00
static int decoder_construct_pkey(OSSL_DECODER_INSTANCE *decoder_inst,
const OSSL_PARAM *params,
void *construct_data)
SERIALIZER: Add functions to deserialize into an EVP_PKEY EVP_PKEY is the fundamental type for provider side code, so we implement specific support for it, in form of a special context constructor. This constructor looks up and collects all available KEYMGMT implementations, and then uses those names to collect deserializer implementations, as described in the previous commit. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12410)
2020-07-09 05:19:13 +08:00
{
Rename OSSL_ENCODER_CTX_new_by_EVP_PKEY and OSSL_DECODER_CTX_new_by_EVP_PKEY Additional renames done in encoder and decoder implementation to follow the style. Fixes #13622 Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/14155)
2021-02-11 23:57:37 +08:00
struct decoder_pkey_data_st *data = construct_data;
DECODER: Some cleanups, and aligning with OSSL_ENCODER Mostly source nits, but also removing a couple of OSSL_DECODER_PARAM macros that are never used or even make sense. Also, some function names weren't quite consistent. They were made a bit more consistent in the OSSL_ENCODER API, now we bring that back to OSSL_DECODER. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12873)
2020-09-14 17:35:07 +08:00
OSSL_DECODER *decoder = OSSL_DECODER_INSTANCE_get_decoder(decoder_inst);
void *decoderctx = OSSL_DECODER_INSTANCE_get_decoder_ctx(decoder_inst);
ENCODER & DECODER: Make a tighter coupling between en/decoders and keymgmt If there are keymgmts and en/decoders from the same provider, try to combine them first. This avoids unnecessary export/import dances, and also tries to avoid issues where the keymgmt doesn't fully support exporting and importing, which we can assume will be the case for HSM protected keys. Fixes #15932 Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from https://github.com/openssl/openssl/pull/15933)
2021-06-28 11:37:22 +08:00
const OSSL_PROVIDER *decoder_prov = OSSL_DECODER_get0_provider(decoder);
DECODER EVP_PKEY: Don't store all the EVP_KEYMGMTs OSSL_DECODER_CTX_new_by_EVP_PKEY() would keep copies of all the EVP_KEYMGMTs it finds. This turns out to be fragile in certain circumstances, so we switch to fetch the appropriate EVP_KEYMGMT when it's time to construct an EVP_PKEY from the decoded data instead. This has the added benefit that we now actually use the property query string that was given by the caller for these fetches. Fixes #13503 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/13661)
2020-12-11 01:33:16 +08:00
EVP_KEYMGMT *keymgmt = NULL;
ENCODER & DECODER: Make a tighter coupling between en/decoders and keymgmt If there are keymgmts and en/decoders from the same provider, try to combine them first. This avoids unnecessary export/import dances, and also tries to avoid issues where the keymgmt doesn't fully support exporting and importing, which we can assume will be the case for HSM protected keys. Fixes #15932 Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from https://github.com/openssl/openssl/pull/15933)
2021-06-28 11:37:22 +08:00
const OSSL_PROVIDER *keymgmt_prov = NULL;
int i, end;
SERIALIZER: Add functions to deserialize into an EVP_PKEY EVP_PKEY is the fundamental type for provider side code, so we implement specific support for it, in form of a special context constructor. This constructor looks up and collects all available KEYMGMT implementations, and then uses those names to collect deserializer implementations, as described in the previous commit. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12410)
2020-07-09 05:19:13 +08:00
/*
* |object_ref| points to a provider reference to an object, its exact
* contents entirely opaque to us, but may be passed to any provider
* function that expects this (such as OSSL_FUNC_keymgmt_load().
*
* This pointer is considered volatile, i.e. whatever it points at
* is assumed to be freed as soon as this function returns.
*/
void *object_ref = NULL;
size_t object_ref_sz = 0;
const OSSL_PARAM *p;
CORE: Define provider-native abstract objects This is placed as CORE because the core of libcrypto is the authority for what is possible to do and what's required to make these abstract objects work. In essence, an abstract object is an OSSL_PARAM array with well defined parameter keys and values: - an object type, which is a number indicating what kind of libcrypto structure the object in question can be used with. The currently possible numbers are defined in <openssl/core_object.h>. - an object data type, which is a string that indicates more closely what the contents of the object are. - the object data, an octet string. The exact encoding used depends on the context in which it's used. For example, the decoder sub-system accepts any encoding, as long as there is a decoder implementation that takes that as input. If central code is to handle the data directly, DER encoding is assumed. (*) - an object reference, also an octet string. This octet string is not the object contents, just a mere reference to a provider-native object. (**) - an object description, which is a human readable text string that can be displayed if some software desires to do so. The intent is that certain provider-native operations (called X here) are able to return any sort of object that belong with other operations, or an object that has no provider support otherwise. (*) A future extension might be to be able to specify encoding. (**) The possible mechanisms for dealing with object references are: - An object loading function in the target operation. The exact target operation is determined by the object type (for example, OSSL_OBJECT_PKEY implies that the target operation is a KEYMGMT) and the implementation to be fetched by its object data type (for an OSSL_OBJECT_PKEY, that's the KEYMGMT keytype to be fetched). This loading function is only useful for this if the implementations that are involved (X and KEYMGMT, for example) are from the same provider. - An object exporter function in the operation X implementation. That exporter function can be used to export the object data in OSSL_PARAM form that can be imported by a target operation's import function. This can be used when it's not possible to fetch the target operation implementation from the same provider. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12512)
2020-07-22 21:34:25 +08:00
p = OSSL_PARAM_locate_const(params, OSSL_OBJECT_PARAM_DATA_TYPE);
SERIALIZER: Add functions to deserialize into an EVP_PKEY EVP_PKEY is the fundamental type for provider side code, so we implement specific support for it, in form of a special context constructor. This constructor looks up and collects all available KEYMGMT implementations, and then uses those names to collect deserializer implementations, as described in the previous commit. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12410)
2020-07-09 05:19:13 +08:00
if (p != NULL) {
char *object_type = NULL;
if (!OSSL_PARAM_get_utf8_string(p, &object_type, 0))
return 0;
OPENSSL_free(data->object_type);
data->object_type = object_type;
}
/*
* For stuff that should end up in an EVP_PKEY, we only accept an object
* reference for the moment. This enforces that the key data itself
* remains with the provider.
*/
CORE: Define provider-native abstract objects This is placed as CORE because the core of libcrypto is the authority for what is possible to do and what's required to make these abstract objects work. In essence, an abstract object is an OSSL_PARAM array with well defined parameter keys and values: - an object type, which is a number indicating what kind of libcrypto structure the object in question can be used with. The currently possible numbers are defined in <openssl/core_object.h>. - an object data type, which is a string that indicates more closely what the contents of the object are. - the object data, an octet string. The exact encoding used depends on the context in which it's used. For example, the decoder sub-system accepts any encoding, as long as there is a decoder implementation that takes that as input. If central code is to handle the data directly, DER encoding is assumed. (*) - an object reference, also an octet string. This octet string is not the object contents, just a mere reference to a provider-native object. (**) - an object description, which is a human readable text string that can be displayed if some software desires to do so. The intent is that certain provider-native operations (called X here) are able to return any sort of object that belong with other operations, or an object that has no provider support otherwise. (*) A future extension might be to be able to specify encoding. (**) The possible mechanisms for dealing with object references are: - An object loading function in the target operation. The exact target operation is determined by the object type (for example, OSSL_OBJECT_PKEY implies that the target operation is a KEYMGMT) and the implementation to be fetched by its object data type (for an OSSL_OBJECT_PKEY, that's the KEYMGMT keytype to be fetched). This loading function is only useful for this if the implementations that are involved (X and KEYMGMT, for example) are from the same provider. - An object exporter function in the operation X implementation. That exporter function can be used to export the object data in OSSL_PARAM form that can be imported by a target operation's import function. This can be used when it's not possible to fetch the target operation implementation from the same provider. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12512)
2020-07-22 21:34:25 +08:00
p = OSSL_PARAM_locate_const(params, OSSL_OBJECT_PARAM_REFERENCE);
SERIALIZER: Add functions to deserialize into an EVP_PKEY EVP_PKEY is the fundamental type for provider side code, so we implement specific support for it, in form of a special context constructor. This constructor looks up and collects all available KEYMGMT implementations, and then uses those names to collect deserializer implementations, as described in the previous commit. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12410)
2020-07-09 05:19:13 +08:00
if (p == NULL || p->data_type != OSSL_PARAM_OCTET_STRING)
return 0;
object_ref = p->data;
object_ref_sz = p->data_size;
ENCODER & DECODER: Make a tighter coupling between en/decoders and keymgmt If there are keymgmts and en/decoders from the same provider, try to combine them first. This avoids unnecessary export/import dances, and also tries to avoid issues where the keymgmt doesn't fully support exporting and importing, which we can assume will be the case for HSM protected keys. Fixes #15932 Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from https://github.com/openssl/openssl/pull/15933)
2021-06-28 11:37:22 +08:00
/*
* First, we try to find a keymgmt that comes from the same provider as
* the decoder that passed the params.
*/
end = sk_EVP_KEYMGMT_num(data->keymgmts);
for (i = 0; i < end; i++) {
keymgmt = sk_EVP_KEYMGMT_value(data->keymgmts, i);
keymgmt_prov = EVP_KEYMGMT_get0_provider(keymgmt);
if (keymgmt_prov == decoder_prov
&& evp_keymgmt_has_load(keymgmt)
&& EVP_KEYMGMT_is_a(keymgmt, data->object_type))
break;
}
if (i < end) {
/* To allow it to be freed further down */
if (!EVP_KEYMGMT_up_ref(keymgmt))
return 0;
Coverity #1486687: fix potential dereference of NULL keymgmt Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from https://github.com/openssl/openssl/pull/15986)
2021-07-02 21:45:09 +08:00
} else if ((keymgmt = EVP_KEYMGMT_fetch(data->libctx,
data->object_type,
data->propq)) != NULL) {
ENCODER & DECODER: Make a tighter coupling between en/decoders and keymgmt If there are keymgmts and en/decoders from the same provider, try to combine them first. This avoids unnecessary export/import dances, and also tries to avoid issues where the keymgmt doesn't fully support exporting and importing, which we can assume will be the case for HSM protected keys. Fixes #15932 Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from https://github.com/openssl/openssl/pull/15933)
2021-06-28 11:37:22 +08:00
keymgmt_prov = EVP_KEYMGMT_get0_provider(keymgmt);
}
DECODER EVP_PKEY: Don't store all the EVP_KEYMGMTs OSSL_DECODER_CTX_new_by_EVP_PKEY() would keep copies of all the EVP_KEYMGMTs it finds. This turns out to be fragile in certain circumstances, so we switch to fetch the appropriate EVP_KEYMGMT when it's time to construct an EVP_PKEY from the decoded data instead. This has the added benefit that we now actually use the property query string that was given by the caller for these fetches. Fixes #13503 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/13661)
2020-12-11 01:33:16 +08:00
if (keymgmt != NULL) {
EVP_PKEY *pkey = NULL;
void *keydata = NULL;
SERIALIZER: Add functions to deserialize into an EVP_PKEY EVP_PKEY is the fundamental type for provider side code, so we implement specific support for it, in form of a special context constructor. This constructor looks up and collects all available KEYMGMT implementations, and then uses those names to collect deserializer implementations, as described in the previous commit. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12410)
2020-07-09 05:19:13 +08:00
/*
DECODER EVP_PKEY: Don't store all the EVP_KEYMGMTs OSSL_DECODER_CTX_new_by_EVP_PKEY() would keep copies of all the EVP_KEYMGMTs it finds. This turns out to be fragile in certain circumstances, so we switch to fetch the appropriate EVP_KEYMGMT when it's time to construct an EVP_PKEY from the decoded data instead. This has the added benefit that we now actually use the property query string that was given by the caller for these fetches. Fixes #13503 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/13661)
2020-12-11 01:33:16 +08:00
* If the EVP_KEYMGMT and the OSSL_DECODER are from the
* same provider, we assume that the KEYMGMT has a key loading
* function that can handle the provider reference we hold.
SERIALIZER: Add functions to deserialize into an EVP_PKEY EVP_PKEY is the fundamental type for provider side code, so we implement specific support for it, in form of a special context constructor. This constructor looks up and collects all available KEYMGMT implementations, and then uses those names to collect deserializer implementations, as described in the previous commit. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12410)
2020-07-09 05:19:13 +08:00
*
DECODER EVP_PKEY: Don't store all the EVP_KEYMGMTs OSSL_DECODER_CTX_new_by_EVP_PKEY() would keep copies of all the EVP_KEYMGMTs it finds. This turns out to be fragile in certain circumstances, so we switch to fetch the appropriate EVP_KEYMGMT when it's time to construct an EVP_PKEY from the decoded data instead. This has the added benefit that we now actually use the property query string that was given by the caller for these fetches. Fixes #13503 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/13661)
2020-12-11 01:33:16 +08:00
* Otherwise, we export from the decoder and import the
* result in the keymgmt.
SERIALIZER: Add functions to deserialize into an EVP_PKEY EVP_PKEY is the fundamental type for provider side code, so we implement specific support for it, in form of a special context constructor. This constructor looks up and collects all available KEYMGMT implementations, and then uses those names to collect deserializer implementations, as described in the previous commit. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12410)
2020-07-09 05:19:13 +08:00
*/
DECODER EVP_PKEY: Don't store all the EVP_KEYMGMTs OSSL_DECODER_CTX_new_by_EVP_PKEY() would keep copies of all the EVP_KEYMGMTs it finds. This turns out to be fragile in certain circumstances, so we switch to fetch the appropriate EVP_KEYMGMT when it's time to construct an EVP_PKEY from the decoded data instead. This has the added benefit that we now actually use the property query string that was given by the caller for these fetches. Fixes #13503 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/13661)
2020-12-11 01:33:16 +08:00
if (keymgmt_prov == decoder_prov) {
keydata = evp_keymgmt_load(keymgmt, object_ref, object_ref_sz);
} else {
struct evp_keymgmt_util_try_import_data_st import_data;
import_data.keymgmt = keymgmt;
import_data.keydata = NULL;
DECODER & ENCODER: Make sure to pass around the original selection bits When decoding a key and asking the keymgmt to import the key data, it was told that the key data includes everything. This may not be true, since the user may have specified a different selection, and some keymgmts may want to be informed. Our key decoders' export function, on the other hand, didn't care either, and simply export anything they could, regardless. In both cases, the selection that was specified by the user is now passed all the way. Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/15934)
2021-06-28 11:52:42 +08:00
import_data.selection = data->selection;
SERIALIZER: Add functions to deserialize into an EVP_PKEY EVP_PKEY is the fundamental type for provider side code, so we implement specific support for it, in form of a special context constructor. This constructor looks up and collects all available KEYMGMT implementations, and then uses those names to collect deserializer implementations, as described in the previous commit. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12410)
2020-07-09 05:19:13 +08:00
/*
DECODER EVP_PKEY: Don't store all the EVP_KEYMGMTs OSSL_DECODER_CTX_new_by_EVP_PKEY() would keep copies of all the EVP_KEYMGMTs it finds. This turns out to be fragile in certain circumstances, so we switch to fetch the appropriate EVP_KEYMGMT when it's time to construct an EVP_PKEY from the decoded data instead. This has the added benefit that we now actually use the property query string that was given by the caller for these fetches. Fixes #13503 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/13661)
2020-12-11 01:33:16 +08:00
* No need to check for errors here, the value of
* |import_data.keydata| is as much an indicator.
SERIALIZER: Add functions to deserialize into an EVP_PKEY EVP_PKEY is the fundamental type for provider side code, so we implement specific support for it, in form of a special context constructor. This constructor looks up and collects all available KEYMGMT implementations, and then uses those names to collect deserializer implementations, as described in the previous commit. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12410)
2020-07-09 05:19:13 +08:00
*/
DECODER EVP_PKEY: Don't store all the EVP_KEYMGMTs OSSL_DECODER_CTX_new_by_EVP_PKEY() would keep copies of all the EVP_KEYMGMTs it finds. This turns out to be fragile in certain circumstances, so we switch to fetch the appropriate EVP_KEYMGMT when it's time to construct an EVP_PKEY from the decoded data instead. This has the added benefit that we now actually use the property query string that was given by the caller for these fetches. Fixes #13503 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/13661)
2020-12-11 01:33:16 +08:00
(void)decoder->export_object(decoderctx,
object_ref, object_ref_sz,
&evp_keymgmt_util_try_import,
&import_data);
keydata = import_data.keydata;
import_data.keydata = NULL;
SERIALIZER: Add functions to deserialize into an EVP_PKEY EVP_PKEY is the fundamental type for provider side code, so we implement specific support for it, in form of a special context constructor. This constructor looks up and collects all available KEYMGMT implementations, and then uses those names to collect deserializer implementations, as described in the previous commit. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12410)
2020-07-09 05:19:13 +08:00
}
DECODER EVP_PKEY: Don't store all the EVP_KEYMGMTs OSSL_DECODER_CTX_new_by_EVP_PKEY() would keep copies of all the EVP_KEYMGMTs it finds. This turns out to be fragile in certain circumstances, so we switch to fetch the appropriate EVP_KEYMGMT when it's time to construct an EVP_PKEY from the decoded data instead. This has the added benefit that we now actually use the property query string that was given by the caller for these fetches. Fixes #13503 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/13661)
2020-12-11 01:33:16 +08:00
if (keydata != NULL
&& (pkey = evp_keymgmt_util_make_pkey(keymgmt, keydata)) == NULL)
evp_keymgmt_freedata(keymgmt, keydata);
*data->object = pkey;
/*
* evp_keymgmt_util_make_pkey() increments the reference count when
* assigning the EVP_PKEY, so we can free the keymgmt here.
*/
EVP_KEYMGMT_free(keymgmt);
SERIALIZER: Add functions to deserialize into an EVP_PKEY EVP_PKEY is the fundamental type for provider side code, so we implement specific support for it, in form of a special context constructor. This constructor looks up and collects all available KEYMGMT implementations, and then uses those names to collect deserializer implementations, as described in the previous commit. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12410)
2020-07-09 05:19:13 +08:00
}
/*
* We successfully looked through, |*ctx->object| determines if we
* actually found something.
*/
return (*data->object != NULL);
}
Rename OSSL_ENCODER_CTX_new_by_EVP_PKEY and OSSL_DECODER_CTX_new_by_EVP_PKEY Additional renames done in encoder and decoder implementation to follow the style. Fixes #13622 Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/14155)
2021-02-11 23:57:37 +08:00
static void decoder_clean_pkey_construct_arg(void *construct_data)
SERIALIZER: Add functions to deserialize into an EVP_PKEY EVP_PKEY is the fundamental type for provider side code, so we implement specific support for it, in form of a special context constructor. This constructor looks up and collects all available KEYMGMT implementations, and then uses those names to collect deserializer implementations, as described in the previous commit. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12410)
2020-07-09 05:19:13 +08:00
{
Rename OSSL_ENCODER_CTX_new_by_EVP_PKEY and OSSL_DECODER_CTX_new_by_EVP_PKEY Additional renames done in encoder and decoder implementation to follow the style. Fixes #13622 Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/14155)
2021-02-11 23:57:37 +08:00
struct decoder_pkey_data_st *data = construct_data;
SERIALIZER: Add functions to deserialize into an EVP_PKEY EVP_PKEY is the fundamental type for provider side code, so we implement specific support for it, in form of a special context constructor. This constructor looks up and collects all available KEYMGMT implementations, and then uses those names to collect deserializer implementations, as described in the previous commit. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12410)
2020-07-09 05:19:13 +08:00
DESERIALIZER: Refactor the constructor setting API It's not the best idea to set a whole bunch of parameters in one call, that leads to functions that are hard to update. Better to re-model this into several function made to set one parameter each. This also renames "finalizer" to "constructor", which was suggested earlier but got lost at the time. Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12544)
2020-07-28 03:51:44 +08:00
if (data != NULL) {
ENCODER & DECODER: Make a tighter coupling between en/decoders and keymgmt If there are keymgmts and en/decoders from the same provider, try to combine them first. This avoids unnecessary export/import dances, and also tries to avoid issues where the keymgmt doesn't fully support exporting and importing, which we can assume will be the case for HSM protected keys. Fixes #15932 Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from https://github.com/openssl/openssl/pull/15933)
2021-06-28 11:37:22 +08:00
sk_EVP_KEYMGMT_pop_free(data->keymgmts, EVP_KEYMGMT_free);
DECODER EVP_PKEY: Don't store all the EVP_KEYMGMTs OSSL_DECODER_CTX_new_by_EVP_PKEY() would keep copies of all the EVP_KEYMGMTs it finds. This turns out to be fragile in certain circumstances, so we switch to fetch the appropriate EVP_KEYMGMT when it's time to construct an EVP_PKEY from the decoded data instead. This has the added benefit that we now actually use the property query string that was given by the caller for these fetches. Fixes #13503 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/13661)
2020-12-11 01:33:16 +08:00
OPENSSL_free(data->propq);
DESERIALIZER: Refactor the constructor setting API It's not the best idea to set a whole bunch of parameters in one call, that leads to functions that are hard to update. Better to re-model this into several function made to set one parameter each. This also renames "finalizer" to "constructor", which was suggested earlier but got lost at the time. Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12544)
2020-07-28 03:51:44 +08:00
OPENSSL_free(data->object_type);
OPENSSL_free(data);
}
SERIALIZER: Add functions to deserialize into an EVP_PKEY EVP_PKEY is the fundamental type for provider side code, so we implement specific support for it, in form of a special context constructor. This constructor looks up and collects all available KEYMGMT implementations, and then uses those names to collect deserializer implementations, as described in the previous commit. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12410)
2020-07-09 05:19:13 +08:00
}
DECODER EVP_PKEY: Don't store all the EVP_KEYMGMTs OSSL_DECODER_CTX_new_by_EVP_PKEY() would keep copies of all the EVP_KEYMGMTs it finds. This turns out to be fragile in certain circumstances, so we switch to fetch the appropriate EVP_KEYMGMT when it's time to construct an EVP_PKEY from the decoded data instead. This has the added benefit that we now actually use the property query string that was given by the caller for these fetches. Fixes #13503 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/13661)
2020-12-11 01:33:16 +08:00
static void collect_name(const char *name, void *arg)
{
STACK_OF(OPENSSL_CSTRING) *names = arg;
SERIALIZER: Add functions to deserialize into an EVP_PKEY EVP_PKEY is the fundamental type for provider side code, so we implement specific support for it, in form of a special context constructor. This constructor looks up and collects all available KEYMGMT implementations, and then uses those names to collect deserializer implementations, as described in the previous commit. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12410)
2020-07-09 05:19:13 +08:00
DECODER EVP_PKEY: Don't store all the EVP_KEYMGMTs OSSL_DECODER_CTX_new_by_EVP_PKEY() would keep copies of all the EVP_KEYMGMTs it finds. This turns out to be fragile in certain circumstances, so we switch to fetch the appropriate EVP_KEYMGMT when it's time to construct an EVP_PKEY from the decoded data instead. This has the added benefit that we now actually use the property query string that was given by the caller for these fetches. Fixes #13503 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/13661)
2020-12-11 01:33:16 +08:00
sk_OPENSSL_CSTRING_push(names, name);
}
SERIALIZER: Add functions to deserialize into an EVP_PKEY EVP_PKEY is the fundamental type for provider side code, so we implement specific support for it, in form of a special context constructor. This constructor looks up and collects all available KEYMGMT implementations, and then uses those names to collect deserializer implementations, as described in the previous commit. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12410)
2020-07-09 05:19:13 +08:00
static void collect_keymgmt(EVP_KEYMGMT *keymgmt, void *arg)
{
DECODER EVP_PKEY: Don't store all the EVP_KEYMGMTs OSSL_DECODER_CTX_new_by_EVP_PKEY() would keep copies of all the EVP_KEYMGMTs it finds. This turns out to be fragile in certain circumstances, so we switch to fetch the appropriate EVP_KEYMGMT when it's time to construct an EVP_PKEY from the decoded data instead. This has the added benefit that we now actually use the property query string that was given by the caller for these fetches. Fixes #13503 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/13661)
2020-12-11 01:33:16 +08:00
STACK_OF(EVP_KEYMGMT) *keymgmts = arg;
SERIALIZER: Add functions to deserialize into an EVP_PKEY EVP_PKEY is the fundamental type for provider side code, so we implement specific support for it, in form of a special context constructor. This constructor looks up and collects all available KEYMGMT implementations, and then uses those names to collect deserializer implementations, as described in the previous commit. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12410)
2020-07-09 05:19:13 +08:00
if (!EVP_KEYMGMT_up_ref(keymgmt) /* ref++ */)
return;
DECODER EVP_PKEY: Don't store all the EVP_KEYMGMTs OSSL_DECODER_CTX_new_by_EVP_PKEY() would keep copies of all the EVP_KEYMGMTs it finds. This turns out to be fragile in certain circumstances, so we switch to fetch the appropriate EVP_KEYMGMT when it's time to construct an EVP_PKEY from the decoded data instead. This has the added benefit that we now actually use the property query string that was given by the caller for these fetches. Fixes #13503 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/13661)
2020-12-11 01:33:16 +08:00
if (sk_EVP_KEYMGMT_push(keymgmts, keymgmt) <= 0) {
DECODER: Some cleanups, and aligning with OSSL_ENCODER Mostly source nits, but also removing a couple of OSSL_DECODER_PARAM macros that are never used or even make sense. Also, some function names weren't quite consistent. They were made a bit more consistent in the OSSL_ENCODER API, now we bring that back to OSSL_DECODER. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12873)
2020-09-14 17:35:07 +08:00
EVP_KEYMGMT_free(keymgmt); /* ref-- */
SERIALIZER: Add functions to deserialize into an EVP_PKEY EVP_PKEY is the fundamental type for provider side code, so we implement specific support for it, in form of a special context constructor. This constructor looks up and collects all available KEYMGMT implementations, and then uses those names to collect deserializer implementations, as described in the previous commit. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12410)
2020-07-09 05:19:13 +08:00
return;
}
}
DECODER EVP_PKEY: Don't store all the EVP_KEYMGMTs OSSL_DECODER_CTX_new_by_EVP_PKEY() would keep copies of all the EVP_KEYMGMTs it finds. This turns out to be fragile in certain circumstances, so we switch to fetch the appropriate EVP_KEYMGMT when it's time to construct an EVP_PKEY from the decoded data instead. This has the added benefit that we now actually use the property query string that was given by the caller for these fetches. Fixes #13503 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/13661)
2020-12-11 01:33:16 +08:00
struct collect_decoder_data_st {
STACK_OF(OPENSSL_CSTRING) *names;
OSSL_DECODER_CTX *ctx;
DECODER & ENCODER: Add better tracing Now that we have functions to get the name and properties of the diverse implementations, we can as well display them for clarity. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/15604)
2021-06-09 16:58:33 +08:00
int total;
crypto: rename error flags in internal structures Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from https://github.com/openssl/openssl/pull/14405)
2021-03-03 01:15:32 +08:00
unsigned int error_occurred:1;
DECODER EVP_PKEY: Don't store all the EVP_KEYMGMTs OSSL_DECODER_CTX_new_by_EVP_PKEY() would keep copies of all the EVP_KEYMGMTs it finds. This turns out to be fragile in certain circumstances, so we switch to fetch the appropriate EVP_KEYMGMT when it's time to construct an EVP_PKEY from the decoded data instead. This has the added benefit that we now actually use the property query string that was given by the caller for these fetches. Fixes #13503 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/13661)
2020-12-11 01:33:16 +08:00
};
Rename OSSL_SERIALIZER / OSSL_DESERIALIZER to OSSL_ENCODE / OSSL_DECODE Fixes #12455 Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12660)
2020-08-17 03:25:08 +08:00
static void collect_decoder(OSSL_DECODER *decoder, void *arg)
DESERIALIZER: Adjust to allow the use several deserializers with same name A key type may be deserialized from one of several sources, which means that more than one deserializer with the same name should be possible to add to the stack of deserializers to try, in the OSSL_DESERIALIZER_CTX collection. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12574)
2020-08-04 03:04:05 +08:00
{
DECODER EVP_PKEY: Don't store all the EVP_KEYMGMTs OSSL_DECODER_CTX_new_by_EVP_PKEY() would keep copies of all the EVP_KEYMGMTs it finds. This turns out to be fragile in certain circumstances, so we switch to fetch the appropriate EVP_KEYMGMT when it's time to construct an EVP_PKEY from the decoded data instead. This has the added benefit that we now actually use the property query string that was given by the caller for these fetches. Fixes #13503 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/13661)
2020-12-11 01:33:16 +08:00
struct collect_decoder_data_st *data = arg;
DESERIALIZER: Adjust to allow the use several deserializers with same name A key type may be deserialized from one of several sources, which means that more than one deserializer with the same name should be possible to add to the stack of deserializers to try, in the OSSL_DESERIALIZER_CTX collection. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12574)
2020-08-04 03:04:05 +08:00
size_t i, end_i;
Rename all getters to use get/get0 in name For functions that exist in 1.1.1 provide a simple aliases via #define. Fixes #15236 Functions with OSSL_DECODER_, OSSL_ENCODER_, OSSL_STORE_LOADER_, EVP_KEYEXCH_, EVP_KEM_, EVP_ASYM_CIPHER_, EVP_SIGNATURE_, EVP_KEYMGMT_, EVP_RAND_, EVP_MAC_, EVP_KDF_, EVP_PKEY_, EVP_MD_, and EVP_CIPHER_ prefixes are renamed. Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from https://github.com/openssl/openssl/pull/15405)
2021-05-21 22:58:08 +08:00
const OSSL_PROVIDER *prov = OSSL_DECODER_get0_provider(decoder);
DECODER: Add input structure support for EVP_PKEY decoding OSSL_DECODER_CTX_new_by_EVP_PKEY() takes one more argument to express the desired outermost structure for the input. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 20:17:42 +08:00
void *provctx = OSSL_PROVIDER_get0_provider_ctx(prov);
DESERIALIZER: Adjust to allow the use several deserializers with same name A key type may be deserialized from one of several sources, which means that more than one deserializer with the same name should be possible to add to the stack of deserializers to try, in the OSSL_DESERIALIZER_CTX collection. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12574)
2020-08-04 03:04:05 +08:00
crypto: rename error flags in internal structures Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from https://github.com/openssl/openssl/pull/14405)
2021-03-03 01:15:32 +08:00
if (data->error_occurred)
DESERIALIZER: Adjust to allow the use several deserializers with same name A key type may be deserialized from one of several sources, which means that more than one deserializer with the same name should be possible to add to the stack of deserializers to try, in the OSSL_DESERIALIZER_CTX collection. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12574)
2020-08-04 03:04:05 +08:00
return;
Don't try the same decoder multiple times The function collect_decoder decides whether a given decoder should be tried or not. It loops through all the names for matching keymgmts to see if any are a match or not. If there is a match then the decoder gets added. However, each keymgmt may have multiple aliases and a decoder was being added for each one. For example DHX has 4 alias names, and therefore 4 instances of the DHX decoder were added and being tried. Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/15404)
2021-05-21 19:21:32 +08:00
if (data->names == NULL) {
data->error_occurred = 1;
return;
}
/*
* Either the caller didn't give a selection, or if they did,
* the decoder must tell us if it supports that selection to
* be accepted. If the decoder doesn't have |does_selection|,
* it's seen as taking anything.
*/
if (decoder->does_selection != NULL
&& !decoder->does_selection(provctx, data->ctx->selection))
Fix coverity CID #1465797 - Negative loop bound in collect_deserializer Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/12628)
2020-08-11 13:17:17 +08:00
return;
DESERIALIZER: Adjust to allow the use several deserializers with same name A key type may be deserialized from one of several sources, which means that more than one deserializer with the same name should be possible to add to the stack of deserializers to try, in the OSSL_DESERIALIZER_CTX collection. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12574)
2020-08-04 03:04:05 +08:00
DECODER & ENCODER: Add better tracing Now that we have functions to get the name and properties of the diverse implementations, we can as well display them for clarity. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/15604)
2021-06-09 16:58:33 +08:00
OSSL_TRACE_BEGIN(DECODER) {
BIO_printf(trc_out,
"(ctx %p) Checking out decoder %p:\n"
" %s with %s\n",
(void *)data->ctx, (void *)decoder,
OSSL_DECODER_get0_name(decoder),
OSSL_DECODER_get0_properties(decoder));
} OSSL_TRACE_END(DECODER);
DESERIALIZER: Adjust to allow the use several deserializers with same name A key type may be deserialized from one of several sources, which means that more than one deserializer with the same name should be possible to add to the stack of deserializers to try, in the OSSL_DESERIALIZER_CTX collection. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12574)
2020-08-04 03:04:05 +08:00
end_i = sk_OPENSSL_CSTRING_num(data->names);
for (i = 0; i < end_i; i++) {
const char *name = sk_OPENSSL_CSTRING_value(data->names, i);
DECODER: Add input structure support for EVP_PKEY decoding OSSL_DECODER_CTX_new_by_EVP_PKEY() takes one more argument to express the desired outermost structure for the input. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 20:17:42 +08:00
Don't try the same decoder multiple times The function collect_decoder decides whether a given decoder should be tried or not. It loops through all the names for matching keymgmts to see if any are a match or not. If there is a match then the decoder gets added. However, each keymgmt may have multiple aliases and a decoder was being added for each one. For example DHX has 4 alias names, and therefore 4 instances of the DHX decoder were added and being tried. Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/15404)
2021-05-21 19:21:32 +08:00
if (OSSL_DECODER_is_a(decoder, name)) {
void *decoderctx = NULL;
OSSL_DECODER_INSTANCE *di = NULL;
if ((decoderctx = decoder->newctx(provctx)) == NULL) {
data->error_occurred = 1;
return;
}
if ((di = ossl_decoder_instance_new(decoder, decoderctx)) == NULL) {
decoder->freectx(decoderctx);
data->error_occurred = 1;
return;
}
DECODER & ENCODER: Add better tracing Now that we have functions to get the name and properties of the diverse implementations, we can as well display them for clarity. Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/15498)
2021-05-27 18:51:04 +08:00
OSSL_TRACE_BEGIN(DECODER) {
BIO_printf(trc_out,
"(ctx %p) Checking out decoder %p:\n"
" %s with %s\n",
(void *)data->ctx, (void *)decoder,
OSSL_DECODER_get0_name(decoder),
OSSL_DECODER_get0_properties(decoder));
} OSSL_TRACE_END(DECODER);
Don't try the same decoder multiple times The function collect_decoder decides whether a given decoder should be tried or not. It loops through all the names for matching keymgmts to see if any are a match or not. If there is a match then the decoder gets added. However, each keymgmt may have multiple aliases and a decoder was being added for each one. For example DHX has 4 alias names, and therefore 4 instances of the DHX decoder were added and being tried. Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/15404)
2021-05-21 19:21:32 +08:00
if (!ossl_decoder_ctx_add_decoder_inst(data->ctx, di)) {
ossl_decoder_instance_free(di);
data->error_occurred = 1;
return;
}
DECODER & ENCODER: Add better tracing Now that we have functions to get the name and properties of the diverse implementations, we can as well display them for clarity. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/15604)
2021-06-09 16:58:33 +08:00
data->total++;
Don't try the same decoder multiple times The function collect_decoder decides whether a given decoder should be tried or not. It loops through all the names for matching keymgmts to see if any are a match or not. If there is a match then the decoder gets added. However, each keymgmt may have multiple aliases and a decoder was being added for each one. For example DHX has 4 alias names, and therefore 4 instances of the DHX decoder were added and being tried. Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/15404)
2021-05-21 19:21:32 +08:00
/* Success */
return;
DECODER: Add input structure support for EVP_PKEY decoding OSSL_DECODER_CTX_new_by_EVP_PKEY() takes one more argument to express the desired outermost structure for the input. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 20:17:42 +08:00
}
DESERIALIZER: Adjust to allow the use several deserializers with same name A key type may be deserialized from one of several sources, which means that more than one deserializer with the same name should be possible to add to the stack of deserializers to try, in the OSSL_DESERIALIZER_CTX collection. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12574)
2020-08-04 03:04:05 +08:00
}
Don't try the same decoder multiple times The function collect_decoder decides whether a given decoder should be tried or not. It loops through all the names for matching keymgmts to see if any are a match or not. If there is a match then the decoder gets added. However, each keymgmt may have multiple aliases and a decoder was being added for each one. For example DHX has 4 alias names, and therefore 4 instances of the DHX decoder were added and being tried. Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/15404)
2021-05-21 19:21:32 +08:00
/* Decoder not suitable - but not a fatal error */
data->error_occurred = 0;
DESERIALIZER: Adjust to allow the use several deserializers with same name A key type may be deserialized from one of several sources, which means that more than one deserializer with the same name should be possible to add to the stack of deserializers to try, in the OSSL_DESERIALIZER_CTX collection. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12574)
2020-08-04 03:04:05 +08:00
}
Rename OSSL_ENCODER_CTX_new_by_EVP_PKEY and OSSL_DECODER_CTX_new_by_EVP_PKEY Additional renames done in encoder and decoder implementation to follow the style. Fixes #13622 Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/14155)
2021-02-11 23:57:37 +08:00
int ossl_decoder_ctx_setup_for_pkey(OSSL_DECODER_CTX *ctx,
EVP_PKEY **pkey, const char *keytype,
OSSL_LIB_CTX *libctx,
const char *propquery)
SERIALIZER: Add functions to deserialize into an EVP_PKEY EVP_PKEY is the fundamental type for provider side code, so we implement specific support for it, in form of a special context constructor. This constructor looks up and collects all available KEYMGMT implementations, and then uses those names to collect deserializer implementations, as described in the previous commit. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12410)
2020-07-09 05:19:13 +08:00
{
Rename OSSL_ENCODER_CTX_new_by_EVP_PKEY and OSSL_DECODER_CTX_new_by_EVP_PKEY Additional renames done in encoder and decoder implementation to follow the style. Fixes #13622 Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/14155)
2021-02-11 23:57:37 +08:00
struct decoder_pkey_data_st *process_data = NULL;
DECODER EVP_PKEY: Don't store all the EVP_KEYMGMTs OSSL_DECODER_CTX_new_by_EVP_PKEY() would keep copies of all the EVP_KEYMGMTs it finds. This turns out to be fragile in certain circumstances, so we switch to fetch the appropriate EVP_KEYMGMT when it's time to construct an EVP_PKEY from the decoded data instead. This has the added benefit that we now actually use the property query string that was given by the caller for these fetches. Fixes #13503 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/13661)
2020-12-11 01:33:16 +08:00
STACK_OF(OPENSSL_CSTRING) *names = NULL;
DECODER & ENCODER: Add better tracing Now that we have functions to get the name and properties of the diverse implementations, we can as well display them for clarity. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/15604)
2021-06-09 16:58:33 +08:00
const char *input_type = ctx->start_input_type;
const char *input_structure = ctx->input_structure;
STORE: Add a built-in 'file:' storemgmt implementation (loader) This replaces the older 'file:' loader that is now an engine. It's still possible to use the older 'file:' loader by explicitly using the engine, and tests will remain for it as long as ENGINEs are still supported (even through deprecated). To support this storemgmt implementation, a few internal OSSL_DECODER modifications are needed: - An internal function that implements most of OSSL_DECODER_CTX_new_by_EVP_PKEY(), but operates on an already existing OSSL_DECODER_CTX instead of allocating a new one. - Allow direct creation of a OSSL_DECODER from an OSSL_ALGORITHM. It isn't attached to any provider, and is only used internally, to simply catch any DER encoded object to be passed back to the object callback with no further checking. This implementation becomes the last resort decoder, when all "normal" decodation attempts (i.e. those that are supposed to result in an OpenSSL object of some sort) have failed. Because file_store_attach() uses BIO_tell(), we must also support BIO_ctrl() as a libcrypto upcall. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/12587)
2020-08-02 18:46:00 +08:00
int ok = 0;
Special case SM2 when decoding SM2 abuses the EC oid by reusing it - but an EC key is different to an SM2 key. Therefore we have to special case SM2 during decoding. If we encounter the EC OID then we have to try both algorithms. Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/15522)
2021-05-21 18:55:33 +08:00
int isecoid = 0;
ENCODER & DECODER: Make a tighter coupling between en/decoders and keymgmt If there are keymgmts and en/decoders from the same provider, try to combine them first. This avoids unnecessary export/import dances, and also tries to avoid issues where the keymgmt doesn't fully support exporting and importing, which we can assume will be the case for HSM protected keys. Fixes #15932 Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from https://github.com/openssl/openssl/pull/15933)
2021-06-28 11:37:22 +08:00
int i, end;
Special case SM2 when decoding SM2 abuses the EC oid by reusing it - but an EC key is different to an SM2 key. Therefore we have to special case SM2 during decoding. If we encounter the EC OID then we have to try both algorithms. Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/15522)
2021-05-21 18:55:33 +08:00
if (keytype != NULL
&& (strcmp(keytype, "id-ecPublicKey") == 0
|| strcmp(keytype, "1.2.840.10045.2.1") == 0))
isecoid = 1;
SERIALIZER: Add functions to deserialize into an EVP_PKEY EVP_PKEY is the fundamental type for provider side code, so we implement specific support for it, in form of a special context constructor. This constructor looks up and collects all available KEYMGMT implementations, and then uses those names to collect deserializer implementations, as described in the previous commit. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12410)
2020-07-09 05:19:13 +08:00
DECODER & ENCODER: Add better tracing Now that we have functions to get the name and properties of the diverse implementations, we can as well display them for clarity. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/15604)
2021-06-09 16:58:33 +08:00
OSSL_TRACE_BEGIN(DECODER) {
BIO_printf(trc_out,
"(ctx %p) Looking for decoders producing %s%s%s%s%s%s\n",
(void *)ctx,
keytype != NULL ? keytype : "",
keytype != NULL ? " keys" : "keys of any type",
input_type != NULL ? " from " : "",
input_type != NULL ? input_type : "",
input_structure != NULL ? " with " : "",
input_structure != NULL ? input_structure : "");
} OSSL_TRACE_END(DECODER);
DECODER EVP_PKEY: Don't store all the EVP_KEYMGMTs OSSL_DECODER_CTX_new_by_EVP_PKEY() would keep copies of all the EVP_KEYMGMTs it finds. This turns out to be fragile in certain circumstances, so we switch to fetch the appropriate EVP_KEYMGMT when it's time to construct an EVP_PKEY from the decoded data instead. This has the added benefit that we now actually use the property query string that was given by the caller for these fetches. Fixes #13503 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/13661)
2020-12-11 01:33:16 +08:00
if ((process_data = OPENSSL_zalloc(sizeof(*process_data))) == NULL
|| (propquery != NULL
&& (process_data->propq = OPENSSL_strdup(propquery)) == NULL)
ENCODER & DECODER: Make a tighter coupling between en/decoders and keymgmt If there are keymgmts and en/decoders from the same provider, try to combine them first. This avoids unnecessary export/import dances, and also tries to avoid issues where the keymgmt doesn't fully support exporting and importing, which we can assume will be the case for HSM protected keys. Fixes #15932 Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from https://github.com/openssl/openssl/pull/15933)
2021-06-28 11:37:22 +08:00
|| (process_data->keymgmts = sk_EVP_KEYMGMT_new_null()) == NULL
DECODER EVP_PKEY: Don't store all the EVP_KEYMGMTs OSSL_DECODER_CTX_new_by_EVP_PKEY() would keep copies of all the EVP_KEYMGMTs it finds. This turns out to be fragile in certain circumstances, so we switch to fetch the appropriate EVP_KEYMGMT when it's time to construct an EVP_PKEY from the decoded data instead. This has the added benefit that we now actually use the property query string that was given by the caller for these fetches. Fixes #13503 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/13661)
2020-12-11 01:33:16 +08:00
|| (names = sk_OPENSSL_CSTRING_new_null()) == NULL) {
Rename OSSL_SERIALIZER / OSSL_DESERIALIZER to OSSL_ENCODE / OSSL_DECODE Fixes #12455 Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12660)
2020-08-17 03:25:08 +08:00
ERR_raise(ERR_LIB_OSSL_DECODER, ERR_R_MALLOC_FAILURE);
SERIALIZER: Add functions to deserialize into an EVP_PKEY EVP_PKEY is the fundamental type for provider side code, so we implement specific support for it, in form of a special context constructor. This constructor looks up and collects all available KEYMGMT implementations, and then uses those names to collect deserializer implementations, as described in the previous commit. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12410)
2020-07-09 05:19:13 +08:00
goto err;
}
DECODER EVP_PKEY: Don't store all the EVP_KEYMGMTs OSSL_DECODER_CTX_new_by_EVP_PKEY() would keep copies of all the EVP_KEYMGMTs it finds. This turns out to be fragile in certain circumstances, so we switch to fetch the appropriate EVP_KEYMGMT when it's time to construct an EVP_PKEY from the decoded data instead. This has the added benefit that we now actually use the property query string that was given by the caller for these fetches. Fixes #13503 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/13661)
2020-12-11 01:33:16 +08:00
process_data->object = (void **)pkey;
process_data->libctx = libctx;
DECODER & ENCODER: Make sure to pass around the original selection bits When decoding a key and asking the keymgmt to import the key data, it was told that the key data includes everything. This may not be true, since the user may have specified a different selection, and some keymgmts may want to be informed. Our key decoders' export function, on the other hand, didn't care either, and simply export anything they could, regardless. In both cases, the selection that was specified by the user is now passed all the way. Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/15934)
2021-06-28 11:52:42 +08:00
process_data->selection = ctx->selection;
SERIALIZER: Add functions to deserialize into an EVP_PKEY EVP_PKEY is the fundamental type for provider side code, so we implement specific support for it, in form of a special context constructor. This constructor looks up and collects all available KEYMGMT implementations, and then uses those names to collect deserializer implementations, as described in the previous commit. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12410)
2020-07-09 05:19:13 +08:00
DECODER EVP_PKEY: Don't store all the EVP_KEYMGMTs OSSL_DECODER_CTX_new_by_EVP_PKEY() would keep copies of all the EVP_KEYMGMTs it finds. This turns out to be fragile in certain circumstances, so we switch to fetch the appropriate EVP_KEYMGMT when it's time to construct an EVP_PKEY from the decoded data instead. This has the added benefit that we now actually use the property query string that was given by the caller for these fetches. Fixes #13503 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/13661)
2020-12-11 01:33:16 +08:00
/* First, find all keymgmts to form goals */
ENCODER & DECODER: Make a tighter coupling between en/decoders and keymgmt If there are keymgmts and en/decoders from the same provider, try to combine them first. This avoids unnecessary export/import dances, and also tries to avoid issues where the keymgmt doesn't fully support exporting and importing, which we can assume will be the case for HSM protected keys. Fixes #15932 Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from https://github.com/openssl/openssl/pull/15933)
2021-06-28 11:37:22 +08:00
EVP_KEYMGMT_do_all_provided(libctx, collect_keymgmt,
process_data->keymgmts);
SERIALIZER: Add functions to deserialize into an EVP_PKEY EVP_PKEY is the fundamental type for provider side code, so we implement specific support for it, in form of a special context constructor. This constructor looks up and collects all available KEYMGMT implementations, and then uses those names to collect deserializer implementations, as described in the previous commit. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12410)
2020-07-09 05:19:13 +08:00
DESERIALIZER: Adjust to allow the use several deserializers with same name A key type may be deserialized from one of several sources, which means that more than one deserializer with the same name should be possible to add to the stack of deserializers to try, in the OSSL_DESERIALIZER_CTX collection. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12574)
2020-08-04 03:04:05 +08:00
/* Then, we collect all the keymgmt names */
ENCODER & DECODER: Make a tighter coupling between en/decoders and keymgmt If there are keymgmts and en/decoders from the same provider, try to combine them first. This avoids unnecessary export/import dances, and also tries to avoid issues where the keymgmt doesn't fully support exporting and importing, which we can assume will be the case for HSM protected keys. Fixes #15932 Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from https://github.com/openssl/openssl/pull/15933)
2021-06-28 11:37:22 +08:00
end = sk_EVP_KEYMGMT_num(process_data->keymgmts);
for (i = 0; i < end; i++) {
EVP_KEYMGMT *keymgmt = sk_EVP_KEYMGMT_value(process_data->keymgmts, i);
SERIALIZER: Add functions to deserialize into an EVP_PKEY EVP_PKEY is the fundamental type for provider side code, so we implement specific support for it, in form of a special context constructor. This constructor looks up and collects all available KEYMGMT implementations, and then uses those names to collect deserializer implementations, as described in the previous commit. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12410)
2020-07-09 05:19:13 +08:00
DECODER EVP_PKEY: Don't store all the EVP_KEYMGMTs OSSL_DECODER_CTX_new_by_EVP_PKEY() would keep copies of all the EVP_KEYMGMTs it finds. This turns out to be fragile in certain circumstances, so we switch to fetch the appropriate EVP_KEYMGMT when it's time to construct an EVP_PKEY from the decoded data instead. This has the added benefit that we now actually use the property query string that was given by the caller for these fetches. Fixes #13503 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/13661)
2020-12-11 01:33:16 +08:00
/*
* If the key type is given by the caller, we only use the matching
* KEYMGMTs, otherwise we use them all.
Special case SM2 when decoding SM2 abuses the EC oid by reusing it - but an EC key is different to an SM2 key. Therefore we have to special case SM2 during decoding. If we encounter the EC OID then we have to try both algorithms. Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/15522)
2021-05-21 18:55:33 +08:00
* We have to special case SM2 here because of its abuse of the EC OID.
* The EC OID can be used to identify an EC key or an SM2 key - so if
* we have seen that OID we try both key types
DECODER EVP_PKEY: Don't store all the EVP_KEYMGMTs OSSL_DECODER_CTX_new_by_EVP_PKEY() would keep copies of all the EVP_KEYMGMTs it finds. This turns out to be fragile in certain circumstances, so we switch to fetch the appropriate EVP_KEYMGMT when it's time to construct an EVP_PKEY from the decoded data instead. This has the added benefit that we now actually use the property query string that was given by the caller for these fetches. Fixes #13503 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/13661)
2020-12-11 01:33:16 +08:00
*/
Special case SM2 when decoding SM2 abuses the EC oid by reusing it - but an EC key is different to an SM2 key. Therefore we have to special case SM2 during decoding. If we encounter the EC OID then we have to try both algorithms. Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/15522)
2021-05-21 18:55:33 +08:00
if (keytype == NULL
|| EVP_KEYMGMT_is_a(keymgmt, keytype)
|| (isecoid && EVP_KEYMGMT_is_a(keymgmt, "SM2"))) {
Don't hold a lock when calling a callback in ossl_namemap_doall_names We don't want to hold a read lock when calling a user supplied callback. That callback could do anything so the risk of a deadlock is high. Instead we collect all the names first inside the read lock, and then subsequently call the user callback outside the read lock. Fixes #14225 Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from https://github.com/openssl/openssl/pull/14250)
2021-02-20 01:03:43 +08:00
if (!EVP_KEYMGMT_names_do_all(keymgmt, collect_name, names)) {
ERR_raise(ERR_LIB_OSSL_DECODER, ERR_R_INTERNAL_ERROR);
goto err;
}
}
DESERIALIZER: Adjust to allow the use several deserializers with same name A key type may be deserialized from one of several sources, which means that more than one deserializer with the same name should be possible to add to the stack of deserializers to try, in the OSSL_DESERIALIZER_CTX collection. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12574)
2020-08-04 03:04:05 +08:00
}
SERIALIZER: Add functions to deserialize into an EVP_PKEY EVP_PKEY is the fundamental type for provider side code, so we implement specific support for it, in form of a special context constructor. This constructor looks up and collects all available KEYMGMT implementations, and then uses those names to collect deserializer implementations, as described in the previous commit. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12410)
2020-07-09 05:19:13 +08:00
DECODER & ENCODER: Add better tracing Now that we have functions to get the name and properties of the diverse implementations, we can as well display them for clarity. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/15604)
2021-06-09 16:58:33 +08:00
OSSL_TRACE_BEGIN(DECODER) {
ENCODER & DECODER: Make a tighter coupling between en/decoders and keymgmt If there are keymgmts and en/decoders from the same provider, try to combine them first. This avoids unnecessary export/import dances, and also tries to avoid issues where the keymgmt doesn't fully support exporting and importing, which we can assume will be the case for HSM protected keys. Fixes #15932 Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from https://github.com/openssl/openssl/pull/15933)
2021-06-28 11:37:22 +08:00
end = sk_OPENSSL_CSTRING_num(names);
DECODER & ENCODER: Add better tracing Now that we have functions to get the name and properties of the diverse implementations, we can as well display them for clarity. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/15604)
2021-06-09 16:58:33 +08:00
BIO_printf(trc_out,
" Found %d keytypes (possibly with duplicates)",
end);
for (i = 0; i < end; i++)
BIO_printf(trc_out, "%s%s",
i == 0 ? ": " : ", ",
sk_OPENSSL_CSTRING_value(names, i));
BIO_printf(trc_out, "\n");
} OSSL_TRACE_END(DECODER);
DESERIALIZER: Adjust to allow the use several deserializers with same name A key type may be deserialized from one of several sources, which means that more than one deserializer with the same name should be possible to add to the stack of deserializers to try, in the OSSL_DESERIALIZER_CTX collection. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12574)
2020-08-04 03:04:05 +08:00
/*
Rename OSSL_SERIALIZER / OSSL_DESERIALIZER to OSSL_ENCODE / OSSL_DECODE Fixes #12455 Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12660)
2020-08-17 03:25:08 +08:00
* Finally, find all decoders that have any keymgmt of the collected
DESERIALIZER: Adjust to allow the use several deserializers with same name A key type may be deserialized from one of several sources, which means that more than one deserializer with the same name should be possible to add to the stack of deserializers to try, in the OSSL_DESERIALIZER_CTX collection. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12574)
2020-08-04 03:04:05 +08:00
* keymgmt names
*/
DECODER EVP_PKEY: Don't store all the EVP_KEYMGMTs OSSL_DECODER_CTX_new_by_EVP_PKEY() would keep copies of all the EVP_KEYMGMTs it finds. This turns out to be fragile in certain circumstances, so we switch to fetch the appropriate EVP_KEYMGMT when it's time to construct an EVP_PKEY from the decoded data instead. This has the added benefit that we now actually use the property query string that was given by the caller for these fetches. Fixes #13503 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/13661)
2020-12-11 01:33:16 +08:00
{
struct collect_decoder_data_st collect_decoder_data = { NULL, };
SERIALIZER: Add functions to deserialize into an EVP_PKEY EVP_PKEY is the fundamental type for provider side code, so we implement specific support for it, in form of a special context constructor. This constructor looks up and collects all available KEYMGMT implementations, and then uses those names to collect deserializer implementations, as described in the previous commit. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12410)
2020-07-09 05:19:13 +08:00
DECODER EVP_PKEY: Don't store all the EVP_KEYMGMTs OSSL_DECODER_CTX_new_by_EVP_PKEY() would keep copies of all the EVP_KEYMGMTs it finds. This turns out to be fragile in certain circumstances, so we switch to fetch the appropriate EVP_KEYMGMT when it's time to construct an EVP_PKEY from the decoded data instead. This has the added benefit that we now actually use the property query string that was given by the caller for these fetches. Fixes #13503 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/13661)
2020-12-11 01:33:16 +08:00
collect_decoder_data.names = names;
collect_decoder_data.ctx = ctx;
OSSL_DECODER_do_all_provided(libctx,
collect_decoder, &collect_decoder_data);
sk_OPENSSL_CSTRING_free(names);
decoder: fix Coverity 1473236 & 1473386: resource leaks Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/14596)
2021-03-18 11:09:09 +08:00
names = NULL;
DECODER EVP_PKEY: Don't store all the EVP_KEYMGMTs OSSL_DECODER_CTX_new_by_EVP_PKEY() would keep copies of all the EVP_KEYMGMTs it finds. This turns out to be fragile in certain circumstances, so we switch to fetch the appropriate EVP_KEYMGMT when it's time to construct an EVP_PKEY from the decoded data instead. This has the added benefit that we now actually use the property query string that was given by the caller for these fetches. Fixes #13503 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/13661)
2020-12-11 01:33:16 +08:00
crypto: rename error flags in internal structures Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from https://github.com/openssl/openssl/pull/14405)
2021-03-03 01:15:32 +08:00
if (collect_decoder_data.error_occurred)
DECODER EVP_PKEY: Don't store all the EVP_KEYMGMTs OSSL_DECODER_CTX_new_by_EVP_PKEY() would keep copies of all the EVP_KEYMGMTs it finds. This turns out to be fragile in certain circumstances, so we switch to fetch the appropriate EVP_KEYMGMT when it's time to construct an EVP_PKEY from the decoded data instead. This has the added benefit that we now actually use the property query string that was given by the caller for these fetches. Fixes #13503 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/13661)
2020-12-11 01:33:16 +08:00
goto err;
DECODER & ENCODER: Add better tracing Now that we have functions to get the name and properties of the diverse implementations, we can as well display them for clarity. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/15604)
2021-06-09 16:58:33 +08:00
OSSL_TRACE_BEGIN(DECODER) {
BIO_printf(trc_out,
"(ctx %p) Got %d decoders producing keys\n",
(void *)ctx, collect_decoder_data.total);
} OSSL_TRACE_END(DECODER);
DECODER EVP_PKEY: Don't store all the EVP_KEYMGMTs OSSL_DECODER_CTX_new_by_EVP_PKEY() would keep copies of all the EVP_KEYMGMTs it finds. This turns out to be fragile in certain circumstances, so we switch to fetch the appropriate EVP_KEYMGMT when it's time to construct an EVP_PKEY from the decoded data instead. This has the added benefit that we now actually use the property query string that was given by the caller for these fetches. Fixes #13503 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/13661)
2020-12-11 01:33:16 +08:00
}
SERIALIZER: Add functions to deserialize into an EVP_PKEY EVP_PKEY is the fundamental type for provider side code, so we implement specific support for it, in form of a special context constructor. This constructor looks up and collects all available KEYMGMT implementations, and then uses those names to collect deserializer implementations, as described in the previous commit. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12410)
2020-07-09 05:19:13 +08:00
DECODER: Some cleanups, and aligning with OSSL_ENCODER Mostly source nits, but also removing a couple of OSSL_DECODER_PARAM macros that are never used or even make sense. Also, some function names weren't quite consistent. They were made a bit more consistent in the OSSL_ENCODER API, now we bring that back to OSSL_DECODER. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12873)
2020-09-14 17:35:07 +08:00
if (OSSL_DECODER_CTX_get_num_decoders(ctx) != 0) {
Rename OSSL_ENCODER_CTX_new_by_EVP_PKEY and OSSL_DECODER_CTX_new_by_EVP_PKEY Additional renames done in encoder and decoder implementation to follow the style. Fixes #13622 Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/14155)
2021-02-11 23:57:37 +08:00
if (!OSSL_DECODER_CTX_set_construct(ctx, decoder_construct_pkey)
DECODER EVP_PKEY: Don't store all the EVP_KEYMGMTs OSSL_DECODER_CTX_new_by_EVP_PKEY() would keep copies of all the EVP_KEYMGMTs it finds. This turns out to be fragile in certain circumstances, so we switch to fetch the appropriate EVP_KEYMGMT when it's time to construct an EVP_PKEY from the decoded data instead. This has the added benefit that we now actually use the property query string that was given by the caller for these fetches. Fixes #13503 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/13661)
2020-12-11 01:33:16 +08:00
|| !OSSL_DECODER_CTX_set_construct_data(ctx, process_data)
DECODER: Some cleanups, and aligning with OSSL_ENCODER Mostly source nits, but also removing a couple of OSSL_DECODER_PARAM macros that are never used or even make sense. Also, some function names weren't quite consistent. They were made a bit more consistent in the OSSL_ENCODER API, now we bring that back to OSSL_DECODER. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12873)
2020-09-14 17:35:07 +08:00
|| !OSSL_DECODER_CTX_set_cleanup(ctx,
Rename OSSL_ENCODER_CTX_new_by_EVP_PKEY and OSSL_DECODER_CTX_new_by_EVP_PKEY Additional renames done in encoder and decoder implementation to follow the style. Fixes #13622 Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/14155)
2021-02-11 23:57:37 +08:00
decoder_clean_pkey_construct_arg))
DECODER: Some cleanups, and aligning with OSSL_ENCODER Mostly source nits, but also removing a couple of OSSL_DECODER_PARAM macros that are never used or even make sense. Also, some function names weren't quite consistent. They were made a bit more consistent in the OSSL_ENCODER API, now we bring that back to OSSL_DECODER. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12873)
2020-09-14 17:35:07 +08:00
goto err;
SERIALIZER: Add functions to deserialize into an EVP_PKEY EVP_PKEY is the fundamental type for provider side code, so we implement specific support for it, in form of a special context constructor. This constructor looks up and collects all available KEYMGMT implementations, and then uses those names to collect deserializer implementations, as described in the previous commit. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12410)
2020-07-09 05:19:13 +08:00
DECODER EVP_PKEY: Don't store all the EVP_KEYMGMTs OSSL_DECODER_CTX_new_by_EVP_PKEY() would keep copies of all the EVP_KEYMGMTs it finds. This turns out to be fragile in certain circumstances, so we switch to fetch the appropriate EVP_KEYMGMT when it's time to construct an EVP_PKEY from the decoded data instead. This has the added benefit that we now actually use the property query string that was given by the caller for these fetches. Fixes #13503 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/13661)
2020-12-11 01:33:16 +08:00
process_data = NULL; /* Avoid it being freed */
DECODER: Some cleanups, and aligning with OSSL_ENCODER Mostly source nits, but also removing a couple of OSSL_DECODER_PARAM macros that are never used or even make sense. Also, some function names weren't quite consistent. They were made a bit more consistent in the OSSL_ENCODER API, now we bring that back to OSSL_DECODER. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12873)
2020-09-14 17:35:07 +08:00
}
SERIALIZER: Add functions to deserialize into an EVP_PKEY EVP_PKEY is the fundamental type for provider side code, so we implement specific support for it, in form of a special context constructor. This constructor looks up and collects all available KEYMGMT implementations, and then uses those names to collect deserializer implementations, as described in the previous commit. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12410)
2020-07-09 05:19:13 +08:00
STORE: Add a built-in 'file:' storemgmt implementation (loader) This replaces the older 'file:' loader that is now an engine. It's still possible to use the older 'file:' loader by explicitly using the engine, and tests will remain for it as long as ENGINEs are still supported (even through deprecated). To support this storemgmt implementation, a few internal OSSL_DECODER modifications are needed: - An internal function that implements most of OSSL_DECODER_CTX_new_by_EVP_PKEY(), but operates on an already existing OSSL_DECODER_CTX instead of allocating a new one. - Allow direct creation of a OSSL_DECODER from an OSSL_ALGORITHM. It isn't attached to any provider, and is only used internally, to simply catch any DER encoded object to be passed back to the object callback with no further checking. This implementation becomes the last resort decoder, when all "normal" decodation attempts (i.e. those that are supposed to result in an OpenSSL object of some sort) have failed. Because file_store_attach() uses BIO_tell(), we must also support BIO_ctrl() as a libcrypto upcall. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/12587)
2020-08-02 18:46:00 +08:00
ok = 1;
SERIALIZER: Add functions to deserialize into an EVP_PKEY EVP_PKEY is the fundamental type for provider side code, so we implement specific support for it, in form of a special context constructor. This constructor looks up and collects all available KEYMGMT implementations, and then uses those names to collect deserializer implementations, as described in the previous commit. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12410)
2020-07-09 05:19:13 +08:00
err:
Rename OSSL_ENCODER_CTX_new_by_EVP_PKEY and OSSL_DECODER_CTX_new_by_EVP_PKEY Additional renames done in encoder and decoder implementation to follow the style. Fixes #13622 Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/14155)
2021-02-11 23:57:37 +08:00
decoder_clean_pkey_construct_arg(process_data);
decoder: fix Coverity 1473236 & 1473386: resource leaks Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/14596)
2021-03-18 11:09:09 +08:00
sk_OPENSSL_CSTRING_free(names);
STORE: Add a built-in 'file:' storemgmt implementation (loader) This replaces the older 'file:' loader that is now an engine. It's still possible to use the older 'file:' loader by explicitly using the engine, and tests will remain for it as long as ENGINEs are still supported (even through deprecated). To support this storemgmt implementation, a few internal OSSL_DECODER modifications are needed: - An internal function that implements most of OSSL_DECODER_CTX_new_by_EVP_PKEY(), but operates on an already existing OSSL_DECODER_CTX instead of allocating a new one. - Allow direct creation of a OSSL_DECODER from an OSSL_ALGORITHM. It isn't attached to any provider, and is only used internally, to simply catch any DER encoded object to be passed back to the object callback with no further checking. This implementation becomes the last resort decoder, when all "normal" decodation attempts (i.e. those that are supposed to result in an OpenSSL object of some sort) have failed. Because file_store_attach() uses BIO_tell(), we must also support BIO_ctrl() as a libcrypto upcall. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/12587)
2020-08-02 18:46:00 +08:00
return ok;
}
DECODER: Allow precise result type for OSSL_DECODER_CTX_new_by_EVP_PKEY() There is some data that is very difficult to guess. For example, DSA parameters and X9.42 DH parameters look exactly the same, a SEQUENCE of 3 INTEGER. Therefore, callers may need the possibility to select the exact keytype that they expect to get. This will also allow use to translate d2i_TYPEPrivateKey(), d2i_TYPEPublicKey() and d2i_TYPEParams() into OSSL_DECODER terms much more smoothly. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/13061)
2020-10-02 20:21:51 +08:00
OSSL_DECODER_CTX *
Rename OSSL_ENCODER_CTX_new_by_EVP_PKEY and OSSL_DECODER_CTX_new_by_EVP_PKEY Additional renames done in encoder and decoder implementation to follow the style. Fixes #13622 Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/14155)
2021-02-11 23:57:37 +08:00
OSSL_DECODER_CTX_new_for_pkey(EVP_PKEY **pkey,
const char *input_type,
const char *input_structure,
const char *keytype, int selection,
OSSL_LIB_CTX *libctx, const char *propquery)
STORE: Add a built-in 'file:' storemgmt implementation (loader) This replaces the older 'file:' loader that is now an engine. It's still possible to use the older 'file:' loader by explicitly using the engine, and tests will remain for it as long as ENGINEs are still supported (even through deprecated). To support this storemgmt implementation, a few internal OSSL_DECODER modifications are needed: - An internal function that implements most of OSSL_DECODER_CTX_new_by_EVP_PKEY(), but operates on an already existing OSSL_DECODER_CTX instead of allocating a new one. - Allow direct creation of a OSSL_DECODER from an OSSL_ALGORITHM. It isn't attached to any provider, and is only used internally, to simply catch any DER encoded object to be passed back to the object callback with no further checking. This implementation becomes the last resort decoder, when all "normal" decodation attempts (i.e. those that are supposed to result in an OpenSSL object of some sort) have failed. Because file_store_attach() uses BIO_tell(), we must also support BIO_ctrl() as a libcrypto upcall. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/12587)
2020-08-02 18:46:00 +08:00
{
OSSL_DECODER_CTX *ctx = NULL;
if ((ctx = OSSL_DECODER_CTX_new()) == NULL) {
ERR_raise(ERR_LIB_OSSL_DECODER, ERR_R_MALLOC_FAILURE);
return NULL;
}
DECODER: Add tracing Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-28 17:13:24 +08:00
OSSL_TRACE_BEGIN(DECODER) {
BIO_printf(trc_out,
"(ctx %p) Looking for %s decoders with selection %d\n",
(void *)ctx, keytype, selection);
BIO_printf(trc_out, " input type: %s, input structure: %s\n",
input_type, input_structure);
} OSSL_TRACE_END(DECODER);
STORE: Add a built-in 'file:' storemgmt implementation (loader) This replaces the older 'file:' loader that is now an engine. It's still possible to use the older 'file:' loader by explicitly using the engine, and tests will remain for it as long as ENGINEs are still supported (even through deprecated). To support this storemgmt implementation, a few internal OSSL_DECODER modifications are needed: - An internal function that implements most of OSSL_DECODER_CTX_new_by_EVP_PKEY(), but operates on an already existing OSSL_DECODER_CTX instead of allocating a new one. - Allow direct creation of a OSSL_DECODER from an OSSL_ALGORITHM. It isn't attached to any provider, and is only used internally, to simply catch any DER encoded object to be passed back to the object callback with no further checking. This implementation becomes the last resort decoder, when all "normal" decodation attempts (i.e. those that are supposed to result in an OpenSSL object of some sort) have failed. Because file_store_attach() uses BIO_tell(), we must also support BIO_ctrl() as a libcrypto upcall. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/12587)
2020-08-02 18:46:00 +08:00
if (OSSL_DECODER_CTX_set_input_type(ctx, input_type)
DECODER: Add input structure support for EVP_PKEY decoding OSSL_DECODER_CTX_new_by_EVP_PKEY() takes one more argument to express the desired outermost structure for the input. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 20:17:42 +08:00
&& OSSL_DECODER_CTX_set_input_structure(ctx, input_structure)
&& OSSL_DECODER_CTX_set_selection(ctx, selection)
Rename OSSL_ENCODER_CTX_new_by_EVP_PKEY and OSSL_DECODER_CTX_new_by_EVP_PKEY Additional renames done in encoder and decoder implementation to follow the style. Fixes #13622 Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/14155)
2021-02-11 23:57:37 +08:00
&& ossl_decoder_ctx_setup_for_pkey(ctx, pkey, keytype,
libctx, propquery)
DECODER: Add tracing Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-28 17:13:24 +08:00
&& OSSL_DECODER_CTX_add_extra(ctx, libctx, propquery)) {
OSSL_TRACE_BEGIN(DECODER) {
BIO_printf(trc_out, "(ctx %p) Got %d decoders\n",
(void *)ctx, OSSL_DECODER_CTX_get_num_decoders(ctx));
} OSSL_TRACE_END(DECODER);
STORE: Add a built-in 'file:' storemgmt implementation (loader) This replaces the older 'file:' loader that is now an engine. It's still possible to use the older 'file:' loader by explicitly using the engine, and tests will remain for it as long as ENGINEs are still supported (even through deprecated). To support this storemgmt implementation, a few internal OSSL_DECODER modifications are needed: - An internal function that implements most of OSSL_DECODER_CTX_new_by_EVP_PKEY(), but operates on an already existing OSSL_DECODER_CTX instead of allocating a new one. - Allow direct creation of a OSSL_DECODER from an OSSL_ALGORITHM. It isn't attached to any provider, and is only used internally, to simply catch any DER encoded object to be passed back to the object callback with no further checking. This implementation becomes the last resort decoder, when all "normal" decodation attempts (i.e. those that are supposed to result in an OpenSSL object of some sort) have failed. Because file_store_attach() uses BIO_tell(), we must also support BIO_ctrl() as a libcrypto upcall. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/12587)
2020-08-02 18:46:00 +08:00
return ctx;
DECODER: Add tracing Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-28 17:13:24 +08:00
}
STORE: Add a built-in 'file:' storemgmt implementation (loader) This replaces the older 'file:' loader that is now an engine. It's still possible to use the older 'file:' loader by explicitly using the engine, and tests will remain for it as long as ENGINEs are still supported (even through deprecated). To support this storemgmt implementation, a few internal OSSL_DECODER modifications are needed: - An internal function that implements most of OSSL_DECODER_CTX_new_by_EVP_PKEY(), but operates on an already existing OSSL_DECODER_CTX instead of allocating a new one. - Allow direct creation of a OSSL_DECODER from an OSSL_ALGORITHM. It isn't attached to any provider, and is only used internally, to simply catch any DER encoded object to be passed back to the object callback with no further checking. This implementation becomes the last resort decoder, when all "normal" decodation attempts (i.e. those that are supposed to result in an OpenSSL object of some sort) have failed. Because file_store_attach() uses BIO_tell(), we must also support BIO_ctrl() as a libcrypto upcall. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/12587)
2020-08-02 18:46:00 +08:00
OSSL_DECODER_CTX_free(ctx);
return NULL;
SERIALIZER: Add functions to deserialize into an EVP_PKEY EVP_PKEY is the fundamental type for provider side code, so we implement specific support for it, in form of a special context constructor. This constructor looks up and collects all available KEYMGMT implementations, and then uses those names to collect deserializer implementations, as described in the previous commit. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/12410)
2020-07-09 05:19:13 +08:00
}
Reference in New Issue Copy Permalink