2020-07-27 18:40:05 +02:00
|
|
|
/*
|
|
|
|
* Copyright 2020 The OpenSSL Project Authors. All Rights Reserved.
|
|
|
|
*
|
|
|
|
* Licensed under the Apache License 2.0 (the "License"). You may not use
|
|
|
|
* this file except in compliance with the License. You can obtain a copy
|
|
|
|
* in the file LICENSE in the source distribution or at
|
|
|
|
* https://www.openssl.org/source/license.html
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* low level APIs are deprecated for public use, but still ok for
|
|
|
|
* internal use.
|
|
|
|
*/
|
|
|
|
#include "internal/deprecated.h"
|
|
|
|
|
|
|
|
#include <openssl/core_dispatch.h>
|
|
|
|
#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 15:34:25 +02:00
|
|
|
#include <openssl/core_object.h>
|
2020-07-27 18:40:05 +02:00
|
|
|
#include <openssl/crypto.h>
|
2020-09-07 12:25:17 +02:00
|
|
|
#include <openssl/err.h>
|
2020-07-27 18:40:05 +02:00
|
|
|
#include <openssl/params.h>
|
2020-09-07 12:25:17 +02:00
|
|
|
#include <openssl/pem.h> /* PEM_BUFSIZE and public PEM functions */
|
|
|
|
#include <openssl/pkcs12.h>
|
2020-07-27 18:40:05 +02:00
|
|
|
#include <openssl/x509.h>
|
2021-02-05 17:40:42 +01:00
|
|
|
#include <openssl/proverr.h>
|
2020-09-07 12:25:17 +02:00
|
|
|
#include "internal/cryptlib.h" /* ossl_assert() */
|
|
|
|
#include "internal/asn1.h"
|
2020-12-11 11:01:09 +01:00
|
|
|
#include "crypto/dh.h"
|
|
|
|
#include "crypto/dsa.h"
|
|
|
|
#include "crypto/ec.h"
|
2020-09-07 12:25:17 +02:00
|
|
|
#include "crypto/ecx.h"
|
2020-12-11 11:01:09 +01:00
|
|
|
#include "crypto/rsa.h"
|
2020-07-27 18:40:05 +02:00
|
|
|
#include "prov/bio.h"
|
|
|
|
#include "prov/implementations.h"
|
2020-09-07 12:25:17 +02:00
|
|
|
#include "endecoder_local.h"
|
2020-07-27 18:40:05 +02:00
|
|
|
|
2020-09-28 16:14:14 +02:00
|
|
|
#define SET_ERR_MARK() ERR_set_mark()
|
|
|
|
#define CLEAR_ERR_MARK() \
|
|
|
|
do { \
|
|
|
|
int err = ERR_peek_last_error(); \
|
|
|
|
\
|
|
|
|
if (ERR_GET_LIB(err) == ERR_LIB_ASN1 \
|
|
|
|
&& (ERR_GET_REASON(err) == ASN1_R_HEADER_TOO_LONG \
|
|
|
|
|| ERR_GET_REASON(err) == ASN1_R_UNSUPPORTED_TYPE \
|
|
|
|
|| ERR_GET_REASON(err) == ERR_R_NESTED_ASN1_ERROR)) \
|
|
|
|
ERR_pop_to_mark(); \
|
|
|
|
else \
|
|
|
|
ERR_clear_last_mark(); \
|
|
|
|
} while(0)
|
|
|
|
#define RESET_ERR_MARK() \
|
|
|
|
do { \
|
|
|
|
CLEAR_ERR_MARK(); \
|
|
|
|
SET_ERR_MARK(); \
|
|
|
|
} while(0)
|
|
|
|
|
2020-09-07 12:25:17 +02:00
|
|
|
static int read_der(PROV_CTX *provctx, OSSL_CORE_BIO *cin,
|
|
|
|
unsigned char **data, long *len)
|
|
|
|
{
|
|
|
|
BUF_MEM *mem = NULL;
|
|
|
|
BIO *in = bio_new_from_core_bio(provctx, cin);
|
|
|
|
int ok = (asn1_d2i_read_bio(in, &mem) >= 0);
|
|
|
|
|
|
|
|
if (ok) {
|
|
|
|
*data = (unsigned char *)mem->data;
|
|
|
|
*len = (long)mem->length;
|
|
|
|
OPENSSL_free(mem);
|
|
|
|
}
|
|
|
|
BIO_free(in);
|
|
|
|
return ok;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int der_from_p8(unsigned char **new_der, long *new_der_len,
|
|
|
|
unsigned char *input_der, long input_der_len,
|
|
|
|
OSSL_PASSPHRASE_CALLBACK *pw_cb, void *pw_cbarg)
|
|
|
|
{
|
|
|
|
const unsigned char *derp;
|
|
|
|
X509_SIG *p8 = NULL;
|
|
|
|
int ok = 0;
|
|
|
|
|
|
|
|
if (!ossl_assert(new_der != NULL && *new_der == NULL)
|
|
|
|
|| !ossl_assert(new_der_len != NULL))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
derp = input_der;
|
|
|
|
if ((p8 = d2i_X509_SIG(NULL, &derp, input_der_len)) != NULL) {
|
|
|
|
char pbuf[PEM_BUFSIZE];
|
|
|
|
size_t plen = 0;
|
|
|
|
|
|
|
|
if (!pw_cb(pbuf, sizeof(pbuf), &plen, NULL, pw_cbarg)) {
|
|
|
|
ERR_raise(ERR_LIB_PROV, PROV_R_READ_KEY);
|
|
|
|
} else {
|
|
|
|
const X509_ALGOR *alg = NULL;
|
|
|
|
const ASN1_OCTET_STRING *oct = NULL;
|
|
|
|
int len = 0;
|
|
|
|
|
|
|
|
X509_SIG_get0(p8, &alg, &oct);
|
|
|
|
if (PKCS12_pbe_crypt(alg, pbuf, plen, oct->data, oct->length,
|
|
|
|
new_der, &len, 0) != NULL)
|
|
|
|
ok = 1;
|
|
|
|
*new_der_len = len;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
X509_SIG_free(p8);
|
|
|
|
return ok;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* ---------------------------------------------------------------------- */
|
2020-07-27 18:40:05 +02:00
|
|
|
|
2020-08-16 21:25:08 +02:00
|
|
|
static OSSL_FUNC_decoder_freectx_fn der2key_freectx;
|
|
|
|
static OSSL_FUNC_decoder_decode_fn der2key_decode;
|
|
|
|
static OSSL_FUNC_decoder_export_object_fn der2key_export_object;
|
2020-07-27 18:40:05 +02:00
|
|
|
|
2020-12-11 11:01:09 +01:00
|
|
|
struct der2key_ctx_st; /* Forward declaration */
|
2020-07-27 18:40:05 +02:00
|
|
|
typedef void *(extract_key_fn)(EVP_PKEY *);
|
2020-12-11 11:01:09 +01:00
|
|
|
typedef void (adjust_key_fn)(void *, struct der2key_ctx_st *ctx);
|
2020-07-27 18:40:05 +02:00
|
|
|
typedef void (free_key_fn)(void *);
|
|
|
|
struct keytype_desc_st {
|
PROV: Re-implement all the keypair decoders
The base functionality to implement the keypair decoders doesn't
change much, but this results in a more massive amount of
OSSL_DISPATCH and OSSL_ALGORITHM arrays, to support a fine grained
selection of implementation based on what parts of the keypair
structure (combinations of key parameters, public key and private key)
should be expected as input, the input type ("DER", "PEM", ...) and the
outermost input structure ("pkcs8", "SubjectPublicKeyInfo", key
type specific structures, ...).
We add support for the generic structure name "type-specific", to
allow selecting that without knowing the exact name of that structure.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 13:22:54 +01:00
|
|
|
const char *keytype_name;
|
2020-07-27 18:40:05 +02:00
|
|
|
const OSSL_DISPATCH *fns; /* Keymgmt (to pilfer functions from) */
|
|
|
|
|
PROV: Re-implement all the keypair decoders
The base functionality to implement the keypair decoders doesn't
change much, but this results in a more massive amount of
OSSL_DISPATCH and OSSL_ALGORITHM arrays, to support a fine grained
selection of implementation based on what parts of the keypair
structure (combinations of key parameters, public key and private key)
should be expected as input, the input type ("DER", "PEM", ...) and the
outermost input structure ("pkcs8", "SubjectPublicKeyInfo", key
type specific structures, ...).
We add support for the generic structure name "type-specific", to
allow selecting that without knowing the exact name of that structure.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 13:22:54 +01:00
|
|
|
/* The input structure name */
|
|
|
|
const char *structure_name;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The EVP_PKEY_xxx type macro. Should be zero for type specific
|
|
|
|
* structures, non-zero when the outermost structure is PKCS#8 or
|
|
|
|
* SubjectPublicKeyInfo. This determines which of the function
|
|
|
|
* pointers below will be used.
|
|
|
|
*/
|
|
|
|
int evp_type;
|
|
|
|
|
|
|
|
/* The selection mask for OSSL_FUNC_decoder_does_selection() */
|
|
|
|
int selection_mask;
|
|
|
|
|
|
|
|
/* For type specific decoders, we use the corresponding d2i */
|
|
|
|
d2i_of_void *d2i_private_key;
|
|
|
|
d2i_of_void *d2i_public_key;
|
|
|
|
d2i_of_void *d2i_key_params;
|
2020-12-11 11:01:09 +01:00
|
|
|
|
2020-07-27 18:40:05 +02:00
|
|
|
/*
|
PROV: Re-implement all the keypair decoders
The base functionality to implement the keypair decoders doesn't
change much, but this results in a more massive amount of
OSSL_DISPATCH and OSSL_ALGORITHM arrays, to support a fine grained
selection of implementation based on what parts of the keypair
structure (combinations of key parameters, public key and private key)
should be expected as input, the input type ("DER", "PEM", ...) and the
outermost input structure ("pkcs8", "SubjectPublicKeyInfo", key
type specific structures, ...).
We add support for the generic structure name "type-specific", to
allow selecting that without knowing the exact name of that structure.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 13:22:54 +01:00
|
|
|
* For PKCS#8 decoders, we use EVP_PKEY extractors, EVP_PKEY_get1_{TYPE}()
|
2020-07-27 18:40:05 +02:00
|
|
|
*/
|
|
|
|
extract_key_fn *extract_key;
|
2020-12-11 11:01:09 +01:00
|
|
|
/*
|
|
|
|
* For any key, we may need to make provider specific adjustments, such
|
|
|
|
* as ensure the key carries the correct library context.
|
|
|
|
*/
|
|
|
|
adjust_key_fn *adjust_key;
|
PROV: Re-implement all the keypair decoders
The base functionality to implement the keypair decoders doesn't
change much, but this results in a more massive amount of
OSSL_DISPATCH and OSSL_ALGORITHM arrays, to support a fine grained
selection of implementation based on what parts of the keypair
structure (combinations of key parameters, public key and private key)
should be expected as input, the input type ("DER", "PEM", ...) and the
outermost input structure ("pkcs8", "SubjectPublicKeyInfo", key
type specific structures, ...).
We add support for the generic structure name "type-specific", to
allow selecting that without knowing the exact name of that structure.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 13:22:54 +01:00
|
|
|
/* {type}_free() */
|
2020-07-27 18:40:05 +02:00
|
|
|
free_key_fn *free_key;
|
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
2020-08-16 21:25:08 +02:00
|
|
|
* Context used for DER to key decoding.
|
2020-07-27 18:40:05 +02:00
|
|
|
*/
|
|
|
|
struct der2key_ctx_st {
|
|
|
|
PROV_CTX *provctx;
|
|
|
|
const struct keytype_desc_st *desc;
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct der2key_ctx_st *
|
|
|
|
der2key_newctx(void *provctx, const struct keytype_desc_st *desc)
|
|
|
|
{
|
|
|
|
struct der2key_ctx_st *ctx = OPENSSL_zalloc(sizeof(*ctx));
|
|
|
|
|
|
|
|
if (ctx != NULL) {
|
|
|
|
ctx->provctx = provctx;
|
|
|
|
ctx->desc = desc;
|
|
|
|
}
|
|
|
|
return ctx;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void der2key_freectx(void *vctx)
|
|
|
|
{
|
|
|
|
struct der2key_ctx_st *ctx = vctx;
|
|
|
|
|
|
|
|
OPENSSL_free(ctx);
|
|
|
|
}
|
|
|
|
|
PROV: Re-implement all the keypair decoders
The base functionality to implement the keypair decoders doesn't
change much, but this results in a more massive amount of
OSSL_DISPATCH and OSSL_ALGORITHM arrays, to support a fine grained
selection of implementation based on what parts of the keypair
structure (combinations of key parameters, public key and private key)
should be expected as input, the input type ("DER", "PEM", ...) and the
outermost input structure ("pkcs8", "SubjectPublicKeyInfo", key
type specific structures, ...).
We add support for the generic structure name "type-specific", to
allow selecting that without knowing the exact name of that structure.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 13:22:54 +01:00
|
|
|
static const OSSL_PARAM *
|
|
|
|
der2key_gettable_params(void *provctx, const struct keytype_desc_st *desc)
|
2020-07-27 18:40:05 +02:00
|
|
|
{
|
|
|
|
static const OSSL_PARAM gettables[] = {
|
2020-08-16 21:25:08 +02:00
|
|
|
{ OSSL_DECODER_PARAM_INPUT_TYPE, OSSL_PARAM_UTF8_PTR, NULL, 0, 0 },
|
2020-07-27 18:40:05 +02:00
|
|
|
OSSL_PARAM_END,
|
|
|
|
};
|
PROV: Re-implement all the keypair decoders
The base functionality to implement the keypair decoders doesn't
change much, but this results in a more massive amount of
OSSL_DISPATCH and OSSL_ALGORITHM arrays, to support a fine grained
selection of implementation based on what parts of the keypair
structure (combinations of key parameters, public key and private key)
should be expected as input, the input type ("DER", "PEM", ...) and the
outermost input structure ("pkcs8", "SubjectPublicKeyInfo", key
type specific structures, ...).
We add support for the generic structure name "type-specific", to
allow selecting that without knowing the exact name of that structure.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 13:22:54 +01:00
|
|
|
static const OSSL_PARAM gettables_w_structure[] = {
|
|
|
|
{ OSSL_DECODER_PARAM_INPUT_TYPE, OSSL_PARAM_UTF8_PTR, NULL, 0, 0 },
|
|
|
|
{ OSSL_DECODER_PARAM_INPUT_STRUCTURE, OSSL_PARAM_UTF8_PTR, NULL, 0, 0 },
|
|
|
|
OSSL_PARAM_END,
|
|
|
|
};
|
2020-07-27 18:40:05 +02:00
|
|
|
|
PROV: Re-implement all the keypair decoders
The base functionality to implement the keypair decoders doesn't
change much, but this results in a more massive amount of
OSSL_DISPATCH and OSSL_ALGORITHM arrays, to support a fine grained
selection of implementation based on what parts of the keypair
structure (combinations of key parameters, public key and private key)
should be expected as input, the input type ("DER", "PEM", ...) and the
outermost input structure ("pkcs8", "SubjectPublicKeyInfo", key
type specific structures, ...).
We add support for the generic structure name "type-specific", to
allow selecting that without knowing the exact name of that structure.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 13:22:54 +01:00
|
|
|
return desc->structure_name != NULL ? gettables_w_structure : gettables;
|
2020-07-27 18:40:05 +02:00
|
|
|
}
|
|
|
|
|
PROV: Re-implement all the keypair decoders
The base functionality to implement the keypair decoders doesn't
change much, but this results in a more massive amount of
OSSL_DISPATCH and OSSL_ALGORITHM arrays, to support a fine grained
selection of implementation based on what parts of the keypair
structure (combinations of key parameters, public key and private key)
should be expected as input, the input type ("DER", "PEM", ...) and the
outermost input structure ("pkcs8", "SubjectPublicKeyInfo", key
type specific structures, ...).
We add support for the generic structure name "type-specific", to
allow selecting that without knowing the exact name of that structure.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 13:22:54 +01:00
|
|
|
static int der2key_get_params(OSSL_PARAM params[],
|
|
|
|
const struct keytype_desc_st *desc)
|
2020-07-27 18:40:05 +02:00
|
|
|
{
|
|
|
|
OSSL_PARAM *p;
|
|
|
|
|
2020-08-16 21:25:08 +02:00
|
|
|
p = OSSL_PARAM_locate(params, OSSL_DECODER_PARAM_INPUT_TYPE);
|
2020-07-27 18:40:05 +02:00
|
|
|
if (p != NULL && !OSSL_PARAM_set_utf8_ptr(p, "DER"))
|
|
|
|
return 0;
|
PROV: Re-implement all the keypair decoders
The base functionality to implement the keypair decoders doesn't
change much, but this results in a more massive amount of
OSSL_DISPATCH and OSSL_ALGORITHM arrays, to support a fine grained
selection of implementation based on what parts of the keypair
structure (combinations of key parameters, public key and private key)
should be expected as input, the input type ("DER", "PEM", ...) and the
outermost input structure ("pkcs8", "SubjectPublicKeyInfo", key
type specific structures, ...).
We add support for the generic structure name "type-specific", to
allow selecting that without knowing the exact name of that structure.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 13:22:54 +01:00
|
|
|
if (desc->structure_name != NULL) {
|
|
|
|
p = OSSL_PARAM_locate(params, OSSL_DECODER_PARAM_INPUT_STRUCTURE);
|
|
|
|
if (p != NULL && !OSSL_PARAM_set_utf8_ptr(p, desc->structure_name))
|
|
|
|
return 0;
|
|
|
|
}
|
2020-07-27 18:40:05 +02:00
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
PROV: Re-implement all the keypair decoders
The base functionality to implement the keypair decoders doesn't
change much, but this results in a more massive amount of
OSSL_DISPATCH and OSSL_ALGORITHM arrays, to support a fine grained
selection of implementation based on what parts of the keypair
structure (combinations of key parameters, public key and private key)
should be expected as input, the input type ("DER", "PEM", ...) and the
outermost input structure ("pkcs8", "SubjectPublicKeyInfo", key
type specific structures, ...).
We add support for the generic structure name "type-specific", to
allow selecting that without knowing the exact name of that structure.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 13:22:54 +01:00
|
|
|
static int der2key_check_selection(int selection,
|
|
|
|
const struct keytype_desc_st *desc)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* The selections are kinda sorta "levels", i.e. each selection given
|
|
|
|
* here is assumed to include those following.
|
|
|
|
*/
|
|
|
|
int checks[] = {
|
|
|
|
OSSL_KEYMGMT_SELECT_PRIVATE_KEY,
|
|
|
|
OSSL_KEYMGMT_SELECT_PUBLIC_KEY,
|
|
|
|
OSSL_KEYMGMT_SELECT_ALL_PARAMETERS
|
|
|
|
};
|
|
|
|
size_t i;
|
|
|
|
|
|
|
|
/* The decoder implementations made here support guessing */
|
|
|
|
if (selection == 0)
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
for (i = 0; i < OSSL_NELEM(checks); i++) {
|
|
|
|
int check1 = (selection & checks[i]) != 0;
|
|
|
|
int check2 = (desc->selection_mask & checks[i]) != 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If the caller asked for the currently checked bit(s), return
|
|
|
|
* whether the decoder description says it's supported.
|
|
|
|
*/
|
|
|
|
if (check1)
|
|
|
|
return check2;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* This should be dead code, but just to be safe... */
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int der2key_decode(void *vctx, OSSL_CORE_BIO *cin, int selection,
|
2020-08-16 21:25:08 +02:00
|
|
|
OSSL_CALLBACK *data_cb, void *data_cbarg,
|
|
|
|
OSSL_PASSPHRASE_CALLBACK *pw_cb, void *pw_cbarg)
|
2020-07-27 18:40:05 +02:00
|
|
|
{
|
|
|
|
struct der2key_ctx_st *ctx = vctx;
|
2020-10-15 12:55:50 +03:00
|
|
|
void *libctx = PROV_LIBCTX_OF(ctx->provctx);
|
2020-07-27 18:40:05 +02:00
|
|
|
unsigned char *der = NULL;
|
|
|
|
const unsigned char *derp;
|
|
|
|
long der_len = 0;
|
|
|
|
unsigned char *new_der = NULL;
|
|
|
|
long new_der_len;
|
|
|
|
EVP_PKEY *pkey = NULL;
|
|
|
|
void *key = NULL;
|
PROV: Re-implement all the keypair decoders
The base functionality to implement the keypair decoders doesn't
change much, but this results in a more massive amount of
OSSL_DISPATCH and OSSL_ALGORITHM arrays, to support a fine grained
selection of implementation based on what parts of the keypair
structure (combinations of key parameters, public key and private key)
should be expected as input, the input type ("DER", "PEM", ...) and the
outermost input structure ("pkcs8", "SubjectPublicKeyInfo", key
type specific structures, ...).
We add support for the generic structure name "type-specific", to
allow selecting that without knowing the exact name of that structure.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 13:22:54 +01:00
|
|
|
int orig_selection = selection;
|
2020-09-28 16:14:14 +02:00
|
|
|
int ok = 0;
|
2020-07-27 18:40:05 +02:00
|
|
|
|
|
|
|
/*
|
PROV: Re-implement all the keypair decoders
The base functionality to implement the keypair decoders doesn't
change much, but this results in a more massive amount of
OSSL_DISPATCH and OSSL_ALGORITHM arrays, to support a fine grained
selection of implementation based on what parts of the keypair
structure (combinations of key parameters, public key and private key)
should be expected as input, the input type ("DER", "PEM", ...) and the
outermost input structure ("pkcs8", "SubjectPublicKeyInfo", key
type specific structures, ...).
We add support for the generic structure name "type-specific", to
allow selecting that without knowing the exact name of that structure.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 13:22:54 +01:00
|
|
|
* The caller is allowed to specify 0 as a selection mark, to have the
|
|
|
|
* structure and key type guessed. For type-specific structures, this
|
|
|
|
* is not recommended, as some structures are very similar.
|
|
|
|
* Note that 0 isn't the same as OSSL_KEYMGMT_SELECT_ALL, as the latter
|
|
|
|
* signifies a private key structure, where everything else is assumed
|
|
|
|
* to be present as well.
|
2020-07-27 18:40:05 +02:00
|
|
|
*/
|
PROV: Re-implement all the keypair decoders
The base functionality to implement the keypair decoders doesn't
change much, but this results in a more massive amount of
OSSL_DISPATCH and OSSL_ALGORITHM arrays, to support a fine grained
selection of implementation based on what parts of the keypair
structure (combinations of key parameters, public key and private key)
should be expected as input, the input type ("DER", "PEM", ...) and the
outermost input structure ("pkcs8", "SubjectPublicKeyInfo", key
type specific structures, ...).
We add support for the generic structure name "type-specific", to
allow selecting that without knowing the exact name of that structure.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 13:22:54 +01:00
|
|
|
if (selection == 0)
|
|
|
|
selection = ctx->desc->selection_mask;
|
|
|
|
if ((selection & ctx->desc->selection_mask) == 0) {
|
|
|
|
ERR_raise(ERR_LIB_PROV, ERR_R_PASSED_INVALID_ARGUMENT);
|
|
|
|
return 0;
|
2020-07-27 18:40:05 +02:00
|
|
|
}
|
|
|
|
|
PROV: Re-implement all the keypair decoders
The base functionality to implement the keypair decoders doesn't
change much, but this results in a more massive amount of
OSSL_DISPATCH and OSSL_ALGORITHM arrays, to support a fine grained
selection of implementation based on what parts of the keypair
structure (combinations of key parameters, public key and private key)
should be expected as input, the input type ("DER", "PEM", ...) and the
outermost input structure ("pkcs8", "SubjectPublicKeyInfo", key
type specific structures, ...).
We add support for the generic structure name "type-specific", to
allow selecting that without knowing the exact name of that structure.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 13:22:54 +01:00
|
|
|
SET_ERR_MARK();
|
|
|
|
if (!read_der(ctx->provctx, cin, &der, &der_len))
|
|
|
|
goto end;
|
2020-07-27 18:40:05 +02:00
|
|
|
|
PROV: Re-implement all the keypair decoders
The base functionality to implement the keypair decoders doesn't
change much, but this results in a more massive amount of
OSSL_DISPATCH and OSSL_ALGORITHM arrays, to support a fine grained
selection of implementation based on what parts of the keypair
structure (combinations of key parameters, public key and private key)
should be expected as input, the input type ("DER", "PEM", ...) and the
outermost input structure ("pkcs8", "SubjectPublicKeyInfo", key
type specific structures, ...).
We add support for the generic structure name "type-specific", to
allow selecting that without knowing the exact name of that structure.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 13:22:54 +01:00
|
|
|
if (ctx->desc->extract_key == NULL) {
|
|
|
|
/*
|
|
|
|
* There's no EVP_PKEY extractor, so we use the type specific
|
|
|
|
* functions.
|
|
|
|
*/
|
2020-08-02 13:12:54 +02:00
|
|
|
derp = der;
|
PROV: Re-implement all the keypair decoders
The base functionality to implement the keypair decoders doesn't
change much, but this results in a more massive amount of
OSSL_DISPATCH and OSSL_ALGORITHM arrays, to support a fine grained
selection of implementation based on what parts of the keypair
structure (combinations of key parameters, public key and private key)
should be expected as input, the input type ("DER", "PEM", ...) and the
outermost input structure ("pkcs8", "SubjectPublicKeyInfo", key
type specific structures, ...).
We add support for the generic structure name "type-specific", to
allow selecting that without knowing the exact name of that structure.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 13:22:54 +01:00
|
|
|
if ((selection & OSSL_KEYMGMT_SELECT_PRIVATE_KEY) != 0) {
|
|
|
|
key = ctx->desc->d2i_private_key(NULL, &derp, der_len);
|
|
|
|
if (key == NULL && orig_selection != 0)
|
|
|
|
goto end;
|
|
|
|
}
|
|
|
|
if (key == NULL
|
|
|
|
&& (selection & OSSL_KEYMGMT_SELECT_PUBLIC_KEY) != 0) {
|
|
|
|
key = ctx->desc->d2i_public_key(NULL, &derp, der_len);
|
|
|
|
if (key == NULL && orig_selection != 0)
|
|
|
|
goto end;
|
|
|
|
}
|
|
|
|
if (key == NULL
|
|
|
|
&& (selection & OSSL_KEYMGMT_SELECT_ALL_PARAMETERS) != 0) {
|
|
|
|
key = ctx->desc->d2i_key_params(NULL, &derp, der_len);
|
|
|
|
}
|
|
|
|
} else {
|
2020-07-27 18:40:05 +02:00
|
|
|
/*
|
PROV: Re-implement all the keypair decoders
The base functionality to implement the keypair decoders doesn't
change much, but this results in a more massive amount of
OSSL_DISPATCH and OSSL_ALGORITHM arrays, to support a fine grained
selection of implementation based on what parts of the keypair
structure (combinations of key parameters, public key and private key)
should be expected as input, the input type ("DER", "PEM", ...) and the
outermost input structure ("pkcs8", "SubjectPublicKeyInfo", key
type specific structures, ...).
We add support for the generic structure name "type-specific", to
allow selecting that without knowing the exact name of that structure.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 13:22:54 +01:00
|
|
|
* There is a EVP_PKEY extractor, so we use the more generic
|
|
|
|
* EVP_PKEY functions, since they know how to unpack PKCS#8 and
|
|
|
|
* SubjectPublicKeyInfo.
|
2020-07-27 18:40:05 +02:00
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
PROV: Re-implement all the keypair decoders
The base functionality to implement the keypair decoders doesn't
change much, but this results in a more massive amount of
OSSL_DISPATCH and OSSL_ALGORITHM arrays, to support a fine grained
selection of implementation based on what parts of the keypair
structure (combinations of key parameters, public key and private key)
should be expected as input, the input type ("DER", "PEM", ...) and the
outermost input structure ("pkcs8", "SubjectPublicKeyInfo", key
type specific structures, ...).
We add support for the generic structure name "type-specific", to
allow selecting that without knowing the exact name of that structure.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 13:22:54 +01:00
|
|
|
* Opportunistic attempt to decrypt. If it doesn't work, we try
|
|
|
|
* to decode our input unencrypted.
|
2020-07-27 18:40:05 +02:00
|
|
|
*/
|
PROV: Re-implement all the keypair decoders
The base functionality to implement the keypair decoders doesn't
change much, but this results in a more massive amount of
OSSL_DISPATCH and OSSL_ALGORITHM arrays, to support a fine grained
selection of implementation based on what parts of the keypair
structure (combinations of key parameters, public key and private key)
should be expected as input, the input type ("DER", "PEM", ...) and the
outermost input structure ("pkcs8", "SubjectPublicKeyInfo", key
type specific structures, ...).
We add support for the generic structure name "type-specific", to
allow selecting that without knowing the exact name of that structure.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 13:22:54 +01:00
|
|
|
if (der_from_p8(&new_der, &new_der_len, der, der_len,
|
|
|
|
pw_cb, pw_cbarg)) {
|
|
|
|
OPENSSL_free(der);
|
|
|
|
der = new_der;
|
|
|
|
der_len = new_der_len;
|
|
|
|
}
|
|
|
|
RESET_ERR_MARK();
|
|
|
|
|
|
|
|
if ((selection & OSSL_KEYMGMT_SELECT_PRIVATE_KEY) != 0) {
|
|
|
|
derp = der;
|
|
|
|
pkey = d2i_PrivateKey_ex(ctx->desc->evp_type, NULL, &derp, der_len,
|
|
|
|
libctx, NULL);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (pkey == NULL
|
|
|
|
&& (selection & OSSL_KEYMGMT_SELECT_PUBLIC_KEY) != 0) {
|
|
|
|
RESET_ERR_MARK();
|
|
|
|
derp = der;
|
|
|
|
pkey = d2i_PUBKEY_ex(NULL, &derp, der_len, libctx, NULL);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (pkey != NULL) {
|
|
|
|
/*
|
|
|
|
* Tear out the low-level key pointer from the pkey,
|
|
|
|
* but only if it matches the expected key type.
|
|
|
|
*
|
|
|
|
* TODO: The check should be done with EVP_PKEY_is_a(), but
|
|
|
|
* as long as we still have #legacy internal keys, it's safer
|
|
|
|
* to use the type numbers inside the provider.
|
|
|
|
*/
|
|
|
|
if (EVP_PKEY_id(pkey) == ctx->desc->evp_type)
|
|
|
|
key = ctx->desc->extract_key(pkey);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* ctx->desc->extract_key() is expected to have incremented
|
|
|
|
* |key|'s reference count, so it should be safe to free |pkey|
|
|
|
|
* now.
|
|
|
|
*/
|
|
|
|
EVP_PKEY_free(pkey);
|
|
|
|
}
|
2020-07-27 18:40:05 +02:00
|
|
|
}
|
|
|
|
|
2020-12-11 11:01:09 +01:00
|
|
|
if (key != NULL && ctx->desc->adjust_key != NULL)
|
|
|
|
ctx->desc->adjust_key(key, ctx);
|
|
|
|
|
PROV: Re-implement all the keypair decoders
The base functionality to implement the keypair decoders doesn't
change much, but this results in a more massive amount of
OSSL_DISPATCH and OSSL_ALGORITHM arrays, to support a fine grained
selection of implementation based on what parts of the keypair
structure (combinations of key parameters, public key and private key)
should be expected as input, the input type ("DER", "PEM", ...) and the
outermost input structure ("pkcs8", "SubjectPublicKeyInfo", key
type specific structures, ...).
We add support for the generic structure name "type-specific", to
allow selecting that without knowing the exact name of that structure.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 13:22:54 +01:00
|
|
|
end:
|
|
|
|
/*
|
|
|
|
* Prune low-level ASN.1 parse errors from error queue, assuming
|
|
|
|
* that this is called by decoder_process() in a loop trying several
|
|
|
|
* formats.
|
|
|
|
*/
|
|
|
|
CLEAR_ERR_MARK();
|
|
|
|
|
2020-07-27 18:40:05 +02:00
|
|
|
OPENSSL_free(der);
|
|
|
|
|
|
|
|
if (key != NULL) {
|
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 15:34:25 +02:00
|
|
|
OSSL_PARAM params[4];
|
|
|
|
int object_type = OSSL_OBJECT_PKEY;
|
2020-07-27 18:40:05 +02:00
|
|
|
|
|
|
|
params[0] =
|
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 15:34:25 +02:00
|
|
|
OSSL_PARAM_construct_int(OSSL_OBJECT_PARAM_TYPE, &object_type);
|
|
|
|
params[1] =
|
|
|
|
OSSL_PARAM_construct_utf8_string(OSSL_OBJECT_PARAM_DATA_TYPE,
|
PROV: Re-implement all the keypair decoders
The base functionality to implement the keypair decoders doesn't
change much, but this results in a more massive amount of
OSSL_DISPATCH and OSSL_ALGORITHM arrays, to support a fine grained
selection of implementation based on what parts of the keypair
structure (combinations of key parameters, public key and private key)
should be expected as input, the input type ("DER", "PEM", ...) and the
outermost input structure ("pkcs8", "SubjectPublicKeyInfo", key
type specific structures, ...).
We add support for the generic structure name "type-specific", to
allow selecting that without knowing the exact name of that structure.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 13:22:54 +01:00
|
|
|
(char *)ctx->desc->keytype_name,
|
|
|
|
0);
|
2020-07-27 18:40:05 +02:00
|
|
|
/* The address of the key becomes the octet string */
|
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 15:34:25 +02:00
|
|
|
params[2] =
|
|
|
|
OSSL_PARAM_construct_octet_string(OSSL_OBJECT_PARAM_REFERENCE,
|
2020-07-27 18:40:05 +02:00
|
|
|
&key, sizeof(key));
|
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 15:34:25 +02:00
|
|
|
params[3] = OSSL_PARAM_construct_end();
|
2020-07-27 18:40:05 +02:00
|
|
|
|
|
|
|
ok = data_cb(params, data_cbarg);
|
|
|
|
}
|
|
|
|
ctx->desc->free_key(key);
|
|
|
|
|
|
|
|
return ok;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int der2key_export_object(void *vctx,
|
|
|
|
const void *reference, size_t reference_sz,
|
|
|
|
OSSL_CALLBACK *export_cb, void *export_cbarg)
|
|
|
|
{
|
|
|
|
struct der2key_ctx_st *ctx = vctx;
|
|
|
|
OSSL_FUNC_keymgmt_export_fn *export =
|
|
|
|
ossl_prov_get_keymgmt_export(ctx->desc->fns);
|
|
|
|
void *keydata;
|
|
|
|
|
|
|
|
if (reference_sz == sizeof(keydata) && export != NULL) {
|
|
|
|
/* The contents of the reference is the address to our object */
|
|
|
|
keydata = *(void **)reference;
|
|
|
|
|
|
|
|
return export(keydata, OSSL_KEYMGMT_SELECT_ALL,
|
|
|
|
export_cb, export_cbarg);
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
PROV: Re-implement all the keypair decoders
The base functionality to implement the keypair decoders doesn't
change much, but this results in a more massive amount of
OSSL_DISPATCH and OSSL_ALGORITHM arrays, to support a fine grained
selection of implementation based on what parts of the keypair
structure (combinations of key parameters, public key and private key)
should be expected as input, the input type ("DER", "PEM", ...) and the
outermost input structure ("pkcs8", "SubjectPublicKeyInfo", key
type specific structures, ...).
We add support for the generic structure name "type-specific", to
allow selecting that without knowing the exact name of that structure.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 13:22:54 +01:00
|
|
|
/* ---------------------------------------------------------------------- */
|
|
|
|
|
|
|
|
#ifndef OPENSSL_NO_DH
|
|
|
|
# define dh_evp_type EVP_PKEY_DH
|
|
|
|
# define dh_evp_extract (extract_key_fn *)EVP_PKEY_get1_DH
|
|
|
|
# define dh_d2i_private_key NULL
|
|
|
|
# define dh_d2i_public_key NULL
|
|
|
|
# define dh_d2i_key_params (d2i_of_void *)d2i_DHparams
|
|
|
|
# define dh_free (free_key_fn *)DH_free
|
|
|
|
|
2020-12-11 11:01:09 +01:00
|
|
|
static void dh_adjust(void *key, struct der2key_ctx_st *ctx)
|
|
|
|
{
|
|
|
|
ossl_dh_set0_libctx(key, PROV_LIBCTX_OF(ctx->provctx));
|
|
|
|
}
|
|
|
|
|
PROV: Re-implement all the keypair decoders
The base functionality to implement the keypair decoders doesn't
change much, but this results in a more massive amount of
OSSL_DISPATCH and OSSL_ALGORITHM arrays, to support a fine grained
selection of implementation based on what parts of the keypair
structure (combinations of key parameters, public key and private key)
should be expected as input, the input type ("DER", "PEM", ...) and the
outermost input structure ("pkcs8", "SubjectPublicKeyInfo", key
type specific structures, ...).
We add support for the generic structure name "type-specific", to
allow selecting that without knowing the exact name of that structure.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 13:22:54 +01:00
|
|
|
# define dhx_evp_type EVP_PKEY_DHX
|
|
|
|
# define dhx_evp_extract (extract_key_fn *)EVP_PKEY_get1_DH
|
|
|
|
# define dhx_d2i_private_key NULL
|
|
|
|
# define dhx_d2i_public_key NULL
|
|
|
|
# define dhx_d2i_key_params (d2i_of_void *)d2i_DHxparams
|
|
|
|
# define dhx_free (free_key_fn *)DH_free
|
2020-12-11 11:01:09 +01:00
|
|
|
# define dhx_adjust dh_adjust
|
PROV: Re-implement all the keypair decoders
The base functionality to implement the keypair decoders doesn't
change much, but this results in a more massive amount of
OSSL_DISPATCH and OSSL_ALGORITHM arrays, to support a fine grained
selection of implementation based on what parts of the keypair
structure (combinations of key parameters, public key and private key)
should be expected as input, the input type ("DER", "PEM", ...) and the
outermost input structure ("pkcs8", "SubjectPublicKeyInfo", key
type specific structures, ...).
We add support for the generic structure name "type-specific", to
allow selecting that without knowing the exact name of that structure.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 13:22:54 +01:00
|
|
|
#endif
|
|
|
|
|
|
|
|
/* ---------------------------------------------------------------------- */
|
|
|
|
|
|
|
|
#ifndef OPENSSL_NO_DSA
|
|
|
|
# define dsa_evp_type EVP_PKEY_DSA
|
|
|
|
# define dsa_evp_extract (extract_key_fn *)EVP_PKEY_get1_DSA
|
|
|
|
# define dsa_d2i_private_key (d2i_of_void *)d2i_DSAPrivateKey
|
|
|
|
# define dsa_d2i_public_key (d2i_of_void *)d2i_DSAPublicKey
|
|
|
|
# define dsa_d2i_key_params (d2i_of_void *)d2i_DSAparams
|
|
|
|
# define dsa_free (free_key_fn *)DSA_free
|
2020-12-11 11:01:09 +01:00
|
|
|
|
|
|
|
static void dsa_adjust(void *key, struct der2key_ctx_st *ctx)
|
|
|
|
{
|
|
|
|
ossl_dsa_set0_libctx(key, PROV_LIBCTX_OF(ctx->provctx));
|
|
|
|
}
|
PROV: Re-implement all the keypair decoders
The base functionality to implement the keypair decoders doesn't
change much, but this results in a more massive amount of
OSSL_DISPATCH and OSSL_ALGORITHM arrays, to support a fine grained
selection of implementation based on what parts of the keypair
structure (combinations of key parameters, public key and private key)
should be expected as input, the input type ("DER", "PEM", ...) and the
outermost input structure ("pkcs8", "SubjectPublicKeyInfo", key
type specific structures, ...).
We add support for the generic structure name "type-specific", to
allow selecting that without knowing the exact name of that structure.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 13:22:54 +01:00
|
|
|
#endif
|
|
|
|
|
|
|
|
/* ---------------------------------------------------------------------- */
|
|
|
|
|
|
|
|
#ifndef OPENSSL_NO_EC
|
|
|
|
# define ec_evp_type EVP_PKEY_EC
|
|
|
|
# define ec_evp_extract (extract_key_fn *)EVP_PKEY_get1_EC_KEY
|
|
|
|
# define ec_d2i_private_key (d2i_of_void *)d2i_ECPrivateKey
|
|
|
|
# define ec_d2i_public_key NULL
|
|
|
|
# define ec_d2i_key_params (d2i_of_void *)d2i_ECParameters
|
|
|
|
# define ec_free (free_key_fn *)EC_KEY_free
|
|
|
|
|
2020-12-11 11:01:09 +01:00
|
|
|
static void ec_adjust(void *key, struct der2key_ctx_st *ctx)
|
|
|
|
{
|
|
|
|
ec_key_set0_libctx(key, PROV_LIBCTX_OF(ctx->provctx));
|
|
|
|
}
|
|
|
|
|
PROV: Re-implement all the keypair decoders
The base functionality to implement the keypair decoders doesn't
change much, but this results in a more massive amount of
OSSL_DISPATCH and OSSL_ALGORITHM arrays, to support a fine grained
selection of implementation based on what parts of the keypair
structure (combinations of key parameters, public key and private key)
should be expected as input, the input type ("DER", "PEM", ...) and the
outermost input structure ("pkcs8", "SubjectPublicKeyInfo", key
type specific structures, ...).
We add support for the generic structure name "type-specific", to
allow selecting that without knowing the exact name of that structure.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 13:22:54 +01:00
|
|
|
/*
|
|
|
|
* ED25519, ED448, X25519, X448 only implement PKCS#8 and SubjectPublicKeyInfo,
|
|
|
|
* so no d2i functions to be had.
|
|
|
|
*/
|
2020-12-11 11:01:09 +01:00
|
|
|
|
|
|
|
static void ecx_key_adjust(void *key, struct der2key_ctx_st *ctx)
|
|
|
|
{
|
|
|
|
ecx_key_set0_libctx(key, PROV_LIBCTX_OF(ctx->provctx));
|
|
|
|
}
|
|
|
|
|
PROV: Re-implement all the keypair decoders
The base functionality to implement the keypair decoders doesn't
change much, but this results in a more massive amount of
OSSL_DISPATCH and OSSL_ALGORITHM arrays, to support a fine grained
selection of implementation based on what parts of the keypair
structure (combinations of key parameters, public key and private key)
should be expected as input, the input type ("DER", "PEM", ...) and the
outermost input structure ("pkcs8", "SubjectPublicKeyInfo", key
type specific structures, ...).
We add support for the generic structure name "type-specific", to
allow selecting that without knowing the exact name of that structure.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 13:22:54 +01:00
|
|
|
# define ed25519_evp_type EVP_PKEY_ED25519
|
|
|
|
# define ed25519_evp_extract (extract_key_fn *)evp_pkey_get1_ED25519
|
|
|
|
# define ed25519_d2i_private_key NULL
|
|
|
|
# define ed25519_d2i_public_key NULL
|
|
|
|
# define ed25519_d2i_key_params NULL
|
|
|
|
# define ed25519_free (free_key_fn *)ecx_key_free
|
2020-12-11 11:01:09 +01:00
|
|
|
# define ed25519_adjust ecx_key_adjust
|
PROV: Re-implement all the keypair decoders
The base functionality to implement the keypair decoders doesn't
change much, but this results in a more massive amount of
OSSL_DISPATCH and OSSL_ALGORITHM arrays, to support a fine grained
selection of implementation based on what parts of the keypair
structure (combinations of key parameters, public key and private key)
should be expected as input, the input type ("DER", "PEM", ...) and the
outermost input structure ("pkcs8", "SubjectPublicKeyInfo", key
type specific structures, ...).
We add support for the generic structure name "type-specific", to
allow selecting that without knowing the exact name of that structure.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 13:22:54 +01:00
|
|
|
|
|
|
|
# define ed448_evp_type EVP_PKEY_ED448
|
|
|
|
# define ed448_evp_extract (extract_key_fn *)evp_pkey_get1_ED448
|
|
|
|
# define ed448_d2i_private_key NULL
|
|
|
|
# define ed448_d2i_public_key NULL
|
|
|
|
# define ed448_d2i_key_params NULL
|
|
|
|
# define ed448_free (free_key_fn *)ecx_key_free
|
2020-12-11 11:01:09 +01:00
|
|
|
# define ed448_adjust ecx_key_adjust
|
PROV: Re-implement all the keypair decoders
The base functionality to implement the keypair decoders doesn't
change much, but this results in a more massive amount of
OSSL_DISPATCH and OSSL_ALGORITHM arrays, to support a fine grained
selection of implementation based on what parts of the keypair
structure (combinations of key parameters, public key and private key)
should be expected as input, the input type ("DER", "PEM", ...) and the
outermost input structure ("pkcs8", "SubjectPublicKeyInfo", key
type specific structures, ...).
We add support for the generic structure name "type-specific", to
allow selecting that without knowing the exact name of that structure.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 13:22:54 +01:00
|
|
|
|
|
|
|
# define x25519_evp_type EVP_PKEY_X25519
|
|
|
|
# define x25519_evp_extract (extract_key_fn *)evp_pkey_get1_X25519
|
|
|
|
# define x25519_d2i_private_key NULL
|
|
|
|
# define x25519_d2i_public_key NULL
|
|
|
|
# define x25519_d2i_key_params NULL
|
|
|
|
# define x25519_free (free_key_fn *)ecx_key_free
|
2020-12-11 11:01:09 +01:00
|
|
|
# define x25519_adjust ecx_key_adjust
|
PROV: Re-implement all the keypair decoders
The base functionality to implement the keypair decoders doesn't
change much, but this results in a more massive amount of
OSSL_DISPATCH and OSSL_ALGORITHM arrays, to support a fine grained
selection of implementation based on what parts of the keypair
structure (combinations of key parameters, public key and private key)
should be expected as input, the input type ("DER", "PEM", ...) and the
outermost input structure ("pkcs8", "SubjectPublicKeyInfo", key
type specific structures, ...).
We add support for the generic structure name "type-specific", to
allow selecting that without knowing the exact name of that structure.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 13:22:54 +01:00
|
|
|
|
|
|
|
# define x448_evp_type EVP_PKEY_X448
|
|
|
|
# define x448_evp_extract (extract_key_fn *)evp_pkey_get1_X448
|
|
|
|
# define x448_d2i_private_key NULL
|
|
|
|
# define x448_d2i_public_key NULL
|
|
|
|
# define x448_d2i_key_params NULL
|
|
|
|
# define x448_free (free_key_fn *)ecx_key_free
|
2020-12-11 11:01:09 +01:00
|
|
|
# define x448_adjust ecx_key_adjust
|
2021-01-28 08:22:09 +01:00
|
|
|
|
|
|
|
# ifndef OPENSSL_NO_SM2
|
|
|
|
# define sm2_evp_type EVP_PKEY_SM2
|
|
|
|
# define sm2_evp_extract (extract_key_fn *)EVP_PKEY_get1_EC_KEY
|
|
|
|
# define sm2_d2i_private_key (d2i_of_void *)d2i_ECPrivateKey
|
|
|
|
# define sm2_d2i_public_key NULL
|
|
|
|
# define sm2_d2i_key_params (d2i_of_void *)d2i_ECParameters
|
|
|
|
# define sm2_free (free_key_fn *)EC_KEY_free
|
|
|
|
# define sm2_adjust ec_adjust
|
|
|
|
# endif
|
PROV: Re-implement all the keypair decoders
The base functionality to implement the keypair decoders doesn't
change much, but this results in a more massive amount of
OSSL_DISPATCH and OSSL_ALGORITHM arrays, to support a fine grained
selection of implementation based on what parts of the keypair
structure (combinations of key parameters, public key and private key)
should be expected as input, the input type ("DER", "PEM", ...) and the
outermost input structure ("pkcs8", "SubjectPublicKeyInfo", key
type specific structures, ...).
We add support for the generic structure name "type-specific", to
allow selecting that without knowing the exact name of that structure.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 13:22:54 +01:00
|
|
|
#endif
|
|
|
|
|
|
|
|
/* ---------------------------------------------------------------------- */
|
|
|
|
|
|
|
|
#define rsa_evp_type EVP_PKEY_RSA
|
|
|
|
#define rsa_evp_extract (extract_key_fn *)EVP_PKEY_get1_RSA
|
|
|
|
#define rsa_d2i_private_key (d2i_of_void *)d2i_RSAPrivateKey
|
|
|
|
#define rsa_d2i_public_key (d2i_of_void *)d2i_RSAPublicKey
|
|
|
|
#define rsa_d2i_key_params NULL
|
|
|
|
#define rsa_free (free_key_fn *)RSA_free
|
|
|
|
|
2020-12-11 11:01:09 +01:00
|
|
|
static void rsa_adjust(void *key, struct der2key_ctx_st *ctx)
|
|
|
|
{
|
|
|
|
ossl_rsa_set0_libctx(key, PROV_LIBCTX_OF(ctx->provctx));
|
|
|
|
}
|
|
|
|
|
PROV: Re-implement all the keypair decoders
The base functionality to implement the keypair decoders doesn't
change much, but this results in a more massive amount of
OSSL_DISPATCH and OSSL_ALGORITHM arrays, to support a fine grained
selection of implementation based on what parts of the keypair
structure (combinations of key parameters, public key and private key)
should be expected as input, the input type ("DER", "PEM", ...) and the
outermost input structure ("pkcs8", "SubjectPublicKeyInfo", key
type specific structures, ...).
We add support for the generic structure name "type-specific", to
allow selecting that without knowing the exact name of that structure.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 13:22:54 +01:00
|
|
|
#define rsapss_evp_type EVP_PKEY_RSA_PSS
|
|
|
|
#define rsapss_evp_extract (extract_key_fn *)EVP_PKEY_get1_RSA
|
|
|
|
#define rsapss_d2i_private_key (d2i_of_void *)d2i_RSAPrivateKey
|
|
|
|
#define rsapss_d2i_public_key (d2i_of_void *)d2i_RSAPublicKey
|
|
|
|
#define rsapss_d2i_key_params NULL
|
|
|
|
#define rsapss_free (free_key_fn *)RSA_free
|
2020-12-11 11:01:09 +01:00
|
|
|
#define rsapss_adjust rsa_adjust
|
PROV: Re-implement all the keypair decoders
The base functionality to implement the keypair decoders doesn't
change much, but this results in a more massive amount of
OSSL_DISPATCH and OSSL_ALGORITHM arrays, to support a fine grained
selection of implementation based on what parts of the keypair
structure (combinations of key parameters, public key and private key)
should be expected as input, the input type ("DER", "PEM", ...) and the
outermost input structure ("pkcs8", "SubjectPublicKeyInfo", key
type specific structures, ...).
We add support for the generic structure name "type-specific", to
allow selecting that without knowing the exact name of that structure.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 13:22:54 +01:00
|
|
|
|
|
|
|
/* ---------------------------------------------------------------------- */
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The DO_ macros help define the selection mask and the method functions
|
|
|
|
* for each kind of object we want to decode.
|
|
|
|
*/
|
|
|
|
#define DO_type_specific_keypair(keytype) \
|
|
|
|
"type-specific", 0, \
|
|
|
|
( OSSL_KEYMGMT_SELECT_KEYPAIR ), \
|
|
|
|
keytype##_d2i_private_key, \
|
|
|
|
keytype##_d2i_public_key, \
|
|
|
|
NULL, \
|
|
|
|
NULL, \
|
2020-12-11 11:01:09 +01:00
|
|
|
keytype##_adjust, \
|
PROV: Re-implement all the keypair decoders
The base functionality to implement the keypair decoders doesn't
change much, but this results in a more massive amount of
OSSL_DISPATCH and OSSL_ALGORITHM arrays, to support a fine grained
selection of implementation based on what parts of the keypair
structure (combinations of key parameters, public key and private key)
should be expected as input, the input type ("DER", "PEM", ...) and the
outermost input structure ("pkcs8", "SubjectPublicKeyInfo", key
type specific structures, ...).
We add support for the generic structure name "type-specific", to
allow selecting that without knowing the exact name of that structure.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 13:22:54 +01:00
|
|
|
keytype##_free
|
|
|
|
|
|
|
|
#define DO_type_specific_pub(keytype) \
|
|
|
|
"type-specific", 0, \
|
|
|
|
( OSSL_KEYMGMT_SELECT_PUBLIC_KEY ), \
|
|
|
|
NULL, \
|
|
|
|
keytype##_d2i_public_key, \
|
|
|
|
NULL, \
|
|
|
|
NULL, \
|
2020-12-11 11:01:09 +01:00
|
|
|
keytype##_adjust, \
|
PROV: Re-implement all the keypair decoders
The base functionality to implement the keypair decoders doesn't
change much, but this results in a more massive amount of
OSSL_DISPATCH and OSSL_ALGORITHM arrays, to support a fine grained
selection of implementation based on what parts of the keypair
structure (combinations of key parameters, public key and private key)
should be expected as input, the input type ("DER", "PEM", ...) and the
outermost input structure ("pkcs8", "SubjectPublicKeyInfo", key
type specific structures, ...).
We add support for the generic structure name "type-specific", to
allow selecting that without knowing the exact name of that structure.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 13:22:54 +01:00
|
|
|
keytype##_free
|
|
|
|
|
|
|
|
#define DO_type_specific_priv(keytype) \
|
|
|
|
"type-specific", 0, \
|
|
|
|
( OSSL_KEYMGMT_SELECT_PRIVATE_KEY ), \
|
|
|
|
keytype##_d2i_private_key, \
|
|
|
|
NULL, \
|
|
|
|
NULL, \
|
|
|
|
NULL, \
|
2020-12-11 11:01:09 +01:00
|
|
|
keytype##_adjust, \
|
PROV: Re-implement all the keypair decoders
The base functionality to implement the keypair decoders doesn't
change much, but this results in a more massive amount of
OSSL_DISPATCH and OSSL_ALGORITHM arrays, to support a fine grained
selection of implementation based on what parts of the keypair
structure (combinations of key parameters, public key and private key)
should be expected as input, the input type ("DER", "PEM", ...) and the
outermost input structure ("pkcs8", "SubjectPublicKeyInfo", key
type specific structures, ...).
We add support for the generic structure name "type-specific", to
allow selecting that without knowing the exact name of that structure.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 13:22:54 +01:00
|
|
|
keytype##_free
|
|
|
|
|
|
|
|
#define DO_type_specific_params(keytype) \
|
|
|
|
"type-specific", 0, \
|
|
|
|
( OSSL_KEYMGMT_SELECT_ALL_PARAMETERS ), \
|
|
|
|
NULL, \
|
|
|
|
NULL, \
|
|
|
|
keytype##_d2i_key_params, \
|
|
|
|
NULL, \
|
2020-12-11 11:01:09 +01:00
|
|
|
keytype##_adjust, \
|
PROV: Re-implement all the keypair decoders
The base functionality to implement the keypair decoders doesn't
change much, but this results in a more massive amount of
OSSL_DISPATCH and OSSL_ALGORITHM arrays, to support a fine grained
selection of implementation based on what parts of the keypair
structure (combinations of key parameters, public key and private key)
should be expected as input, the input type ("DER", "PEM", ...) and the
outermost input structure ("pkcs8", "SubjectPublicKeyInfo", key
type specific structures, ...).
We add support for the generic structure name "type-specific", to
allow selecting that without knowing the exact name of that structure.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 13:22:54 +01:00
|
|
|
keytype##_free
|
|
|
|
|
|
|
|
#define DO_type_specific(keytype) \
|
|
|
|
"type-specific", 0, \
|
|
|
|
( OSSL_KEYMGMT_SELECT_ALL ), \
|
|
|
|
keytype##_d2i_private_key, \
|
|
|
|
keytype##_d2i_public_key, \
|
|
|
|
keytype##_d2i_key_params, \
|
|
|
|
NULL, \
|
2020-12-11 11:01:09 +01:00
|
|
|
keytype##_adjust, \
|
PROV: Re-implement all the keypair decoders
The base functionality to implement the keypair decoders doesn't
change much, but this results in a more massive amount of
OSSL_DISPATCH and OSSL_ALGORITHM arrays, to support a fine grained
selection of implementation based on what parts of the keypair
structure (combinations of key parameters, public key and private key)
should be expected as input, the input type ("DER", "PEM", ...) and the
outermost input structure ("pkcs8", "SubjectPublicKeyInfo", key
type specific structures, ...).
We add support for the generic structure name "type-specific", to
allow selecting that without knowing the exact name of that structure.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 13:22:54 +01:00
|
|
|
keytype##_free
|
|
|
|
|
|
|
|
#define DO_type_specific_no_pub(keytype) \
|
|
|
|
"type-specific", 0, \
|
|
|
|
( OSSL_KEYMGMT_SELECT_PRIVATE_KEY \
|
|
|
|
| OSSL_KEYMGMT_SELECT_ALL_PARAMETERS ), \
|
|
|
|
keytype##_d2i_private_key, \
|
|
|
|
NULL, \
|
|
|
|
keytype##_d2i_key_params, \
|
|
|
|
NULL, \
|
2020-12-11 11:01:09 +01:00
|
|
|
keytype##_adjust, \
|
PROV: Re-implement all the keypair decoders
The base functionality to implement the keypair decoders doesn't
change much, but this results in a more massive amount of
OSSL_DISPATCH and OSSL_ALGORITHM arrays, to support a fine grained
selection of implementation based on what parts of the keypair
structure (combinations of key parameters, public key and private key)
should be expected as input, the input type ("DER", "PEM", ...) and the
outermost input structure ("pkcs8", "SubjectPublicKeyInfo", key
type specific structures, ...).
We add support for the generic structure name "type-specific", to
allow selecting that without knowing the exact name of that structure.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 13:22:54 +01:00
|
|
|
keytype##_free
|
|
|
|
|
|
|
|
#define DO_PKCS8(keytype) \
|
|
|
|
"pkcs8", keytype##_evp_type, \
|
|
|
|
( OSSL_KEYMGMT_SELECT_PRIVATE_KEY ), \
|
|
|
|
NULL, \
|
|
|
|
NULL, \
|
|
|
|
NULL, \
|
|
|
|
keytype##_evp_extract, \
|
2020-12-11 11:01:09 +01:00
|
|
|
keytype##_adjust, \
|
PROV: Re-implement all the keypair decoders
The base functionality to implement the keypair decoders doesn't
change much, but this results in a more massive amount of
OSSL_DISPATCH and OSSL_ALGORITHM arrays, to support a fine grained
selection of implementation based on what parts of the keypair
structure (combinations of key parameters, public key and private key)
should be expected as input, the input type ("DER", "PEM", ...) and the
outermost input structure ("pkcs8", "SubjectPublicKeyInfo", key
type specific structures, ...).
We add support for the generic structure name "type-specific", to
allow selecting that without knowing the exact name of that structure.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 13:22:54 +01:00
|
|
|
keytype##_free
|
|
|
|
|
|
|
|
#define DO_SubjectPublicKeyInfo(keytype) \
|
|
|
|
"SubjectPublicKeyInfo", keytype##_evp_type, \
|
|
|
|
( OSSL_KEYMGMT_SELECT_PUBLIC_KEY ), \
|
|
|
|
NULL, \
|
|
|
|
NULL, \
|
|
|
|
NULL, \
|
|
|
|
keytype##_evp_extract, \
|
2020-12-11 11:01:09 +01:00
|
|
|
keytype##_adjust, \
|
PROV: Re-implement all the keypair decoders
The base functionality to implement the keypair decoders doesn't
change much, but this results in a more massive amount of
OSSL_DISPATCH and OSSL_ALGORITHM arrays, to support a fine grained
selection of implementation based on what parts of the keypair
structure (combinations of key parameters, public key and private key)
should be expected as input, the input type ("DER", "PEM", ...) and the
outermost input structure ("pkcs8", "SubjectPublicKeyInfo", key
type specific structures, ...).
We add support for the generic structure name "type-specific", to
allow selecting that without knowing the exact name of that structure.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 13:22:54 +01:00
|
|
|
keytype##_free
|
|
|
|
|
|
|
|
#define DO_DH(keytype) \
|
|
|
|
"DH", 0, \
|
|
|
|
( OSSL_KEYMGMT_SELECT_ALL_PARAMETERS ), \
|
|
|
|
NULL, \
|
|
|
|
NULL, \
|
|
|
|
keytype##_d2i_key_params, \
|
|
|
|
NULL, \
|
2020-12-11 11:01:09 +01:00
|
|
|
keytype##_adjust, \
|
PROV: Re-implement all the keypair decoders
The base functionality to implement the keypair decoders doesn't
change much, but this results in a more massive amount of
OSSL_DISPATCH and OSSL_ALGORITHM arrays, to support a fine grained
selection of implementation based on what parts of the keypair
structure (combinations of key parameters, public key and private key)
should be expected as input, the input type ("DER", "PEM", ...) and the
outermost input structure ("pkcs8", "SubjectPublicKeyInfo", key
type specific structures, ...).
We add support for the generic structure name "type-specific", to
allow selecting that without knowing the exact name of that structure.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 13:22:54 +01:00
|
|
|
keytype##_free
|
|
|
|
|
|
|
|
#define DO_DHX(keytype) \
|
|
|
|
"DHX", 0, \
|
|
|
|
( OSSL_KEYMGMT_SELECT_ALL_PARAMETERS ), \
|
|
|
|
NULL, \
|
|
|
|
NULL, \
|
|
|
|
keytype##_d2i_key_params, \
|
|
|
|
NULL, \
|
2020-12-11 11:01:09 +01:00
|
|
|
keytype##_adjust, \
|
PROV: Re-implement all the keypair decoders
The base functionality to implement the keypair decoders doesn't
change much, but this results in a more massive amount of
OSSL_DISPATCH and OSSL_ALGORITHM arrays, to support a fine grained
selection of implementation based on what parts of the keypair
structure (combinations of key parameters, public key and private key)
should be expected as input, the input type ("DER", "PEM", ...) and the
outermost input structure ("pkcs8", "SubjectPublicKeyInfo", key
type specific structures, ...).
We add support for the generic structure name "type-specific", to
allow selecting that without knowing the exact name of that structure.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 13:22:54 +01:00
|
|
|
keytype##_free
|
|
|
|
|
|
|
|
#define DO_DSA(keytype) \
|
|
|
|
"DSA", 0, \
|
|
|
|
( OSSL_KEYMGMT_SELECT_ALL ), \
|
|
|
|
keytype##_d2i_private_key, \
|
|
|
|
keytype##_d2i_public_key, \
|
|
|
|
keytype##_d2i_key_params, \
|
|
|
|
NULL, \
|
2020-12-11 11:01:09 +01:00
|
|
|
keytype##_adjust, \
|
PROV: Re-implement all the keypair decoders
The base functionality to implement the keypair decoders doesn't
change much, but this results in a more massive amount of
OSSL_DISPATCH and OSSL_ALGORITHM arrays, to support a fine grained
selection of implementation based on what parts of the keypair
structure (combinations of key parameters, public key and private key)
should be expected as input, the input type ("DER", "PEM", ...) and the
outermost input structure ("pkcs8", "SubjectPublicKeyInfo", key
type specific structures, ...).
We add support for the generic structure name "type-specific", to
allow selecting that without knowing the exact name of that structure.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 13:22:54 +01:00
|
|
|
keytype##_free
|
|
|
|
|
|
|
|
#define DO_EC(keytype) \
|
|
|
|
"EC", 0, \
|
|
|
|
( OSSL_KEYMGMT_SELECT_PRIVATE_KEY \
|
|
|
|
| OSSL_KEYMGMT_SELECT_ALL_PARAMETERS ), \
|
|
|
|
keytype##_d2i_private_key, \
|
|
|
|
NULL, \
|
|
|
|
keytype##_d2i_key_params, \
|
|
|
|
NULL, \
|
2020-12-11 11:01:09 +01:00
|
|
|
keytype##_adjust, \
|
PROV: Re-implement all the keypair decoders
The base functionality to implement the keypair decoders doesn't
change much, but this results in a more massive amount of
OSSL_DISPATCH and OSSL_ALGORITHM arrays, to support a fine grained
selection of implementation based on what parts of the keypair
structure (combinations of key parameters, public key and private key)
should be expected as input, the input type ("DER", "PEM", ...) and the
outermost input structure ("pkcs8", "SubjectPublicKeyInfo", key
type specific structures, ...).
We add support for the generic structure name "type-specific", to
allow selecting that without knowing the exact name of that structure.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 13:22:54 +01:00
|
|
|
keytype##_free
|
|
|
|
|
|
|
|
#define DO_RSA(keytype) \
|
|
|
|
"RSA", 0, \
|
|
|
|
( OSSL_KEYMGMT_SELECT_KEYPAIR ), \
|
|
|
|
keytype##_d2i_private_key, \
|
|
|
|
keytype##_d2i_public_key, \
|
|
|
|
NULL, \
|
|
|
|
NULL, \
|
2020-12-11 11:01:09 +01:00
|
|
|
keytype##_adjust, \
|
PROV: Re-implement all the keypair decoders
The base functionality to implement the keypair decoders doesn't
change much, but this results in a more massive amount of
OSSL_DISPATCH and OSSL_ALGORITHM arrays, to support a fine grained
selection of implementation based on what parts of the keypair
structure (combinations of key parameters, public key and private key)
should be expected as input, the input type ("DER", "PEM", ...) and the
outermost input structure ("pkcs8", "SubjectPublicKeyInfo", key
type specific structures, ...).
We add support for the generic structure name "type-specific", to
allow selecting that without knowing the exact name of that structure.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 13:22:54 +01:00
|
|
|
keytype##_free
|
|
|
|
|
|
|
|
/*
|
|
|
|
* MAKE_DECODER is the single driver for creating OSSL_DISPATCH tables.
|
|
|
|
* It takes the following arguments:
|
|
|
|
*
|
|
|
|
* keytype_name The implementation key type as a string.
|
|
|
|
* keytype The implementation key type. This must correspond exactly
|
|
|
|
* to our existing keymgmt keytype names... in other words,
|
|
|
|
* there must exist an ossl_##keytype##_keymgmt_functions.
|
|
|
|
* type The type name for the set of functions that implement the
|
|
|
|
* decoder for the key type. This isn't necessarily the same
|
|
|
|
* as keytype. For example, the key types ed25519, ed448,
|
|
|
|
* x25519 and x448 are all handled by the same functions with
|
|
|
|
* the common type name ecx.
|
|
|
|
* kind The kind of support to implement. This translates into
|
|
|
|
* the DO_##kind macros above, to populate the keytype_desc_st
|
|
|
|
* structure.
|
|
|
|
*/
|
|
|
|
#define MAKE_DECODER(keytype_name, keytype, type, kind) \
|
|
|
|
static const struct keytype_desc_st kind##_##keytype##_desc = \
|
|
|
|
{ keytype_name, ossl_##keytype##_keymgmt_functions, \
|
|
|
|
DO_##kind(keytype) }; \
|
|
|
|
\
|
|
|
|
static OSSL_FUNC_decoder_newctx_fn kind##_der2##keytype##_newctx; \
|
|
|
|
static OSSL_FUNC_decoder_gettable_params_fn \
|
|
|
|
kind##_der2##keytype##_gettable_params; \
|
|
|
|
static OSSL_FUNC_decoder_get_params_fn \
|
|
|
|
kind##_der2##keytype##_get_params; \
|
|
|
|
\
|
|
|
|
static void *kind##_der2##keytype##_newctx(void *provctx) \
|
|
|
|
{ \
|
|
|
|
return der2key_newctx(provctx, &kind##_##keytype##_desc); \
|
|
|
|
} \
|
|
|
|
static const OSSL_PARAM * \
|
|
|
|
kind##_der2##keytype##_gettable_params(void *provctx) \
|
|
|
|
{ \
|
|
|
|
return \
|
|
|
|
der2key_gettable_params(provctx, &kind##_##keytype##_desc); \
|
|
|
|
} \
|
|
|
|
static int kind##_der2##keytype##_get_params(OSSL_PARAM params[]) \
|
|
|
|
{ \
|
|
|
|
return der2key_get_params(params, &kind##_##keytype##_desc); \
|
|
|
|
} \
|
|
|
|
static int kind##_der2##keytype##_does_selection(void *provctx, \
|
|
|
|
int selection) \
|
2020-07-27 18:40:05 +02:00
|
|
|
{ \
|
PROV: Re-implement all the keypair decoders
The base functionality to implement the keypair decoders doesn't
change much, but this results in a more massive amount of
OSSL_DISPATCH and OSSL_ALGORITHM arrays, to support a fine grained
selection of implementation based on what parts of the keypair
structure (combinations of key parameters, public key and private key)
should be expected as input, the input type ("DER", "PEM", ...) and the
outermost input structure ("pkcs8", "SubjectPublicKeyInfo", key
type specific structures, ...).
We add support for the generic structure name "type-specific", to
allow selecting that without knowing the exact name of that structure.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 13:22:54 +01:00
|
|
|
return der2key_check_selection(selection, \
|
|
|
|
&kind##_##keytype##_desc); \
|
2020-07-27 18:40:05 +02:00
|
|
|
} \
|
PROV: Re-implement all the keypair decoders
The base functionality to implement the keypair decoders doesn't
change much, but this results in a more massive amount of
OSSL_DISPATCH and OSSL_ALGORITHM arrays, to support a fine grained
selection of implementation based on what parts of the keypair
structure (combinations of key parameters, public key and private key)
should be expected as input, the input type ("DER", "PEM", ...) and the
outermost input structure ("pkcs8", "SubjectPublicKeyInfo", key
type specific structures, ...).
We add support for the generic structure name "type-specific", to
allow selecting that without knowing the exact name of that structure.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 13:22:54 +01:00
|
|
|
const OSSL_DISPATCH \
|
|
|
|
ossl_##kind##_der_to_##keytype##_decoder_functions[] = { \
|
2020-08-16 21:25:08 +02:00
|
|
|
{ OSSL_FUNC_DECODER_NEWCTX, \
|
PROV: Re-implement all the keypair decoders
The base functionality to implement the keypair decoders doesn't
change much, but this results in a more massive amount of
OSSL_DISPATCH and OSSL_ALGORITHM arrays, to support a fine grained
selection of implementation based on what parts of the keypair
structure (combinations of key parameters, public key and private key)
should be expected as input, the input type ("DER", "PEM", ...) and the
outermost input structure ("pkcs8", "SubjectPublicKeyInfo", key
type specific structures, ...).
We add support for the generic structure name "type-specific", to
allow selecting that without knowing the exact name of that structure.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 13:22:54 +01:00
|
|
|
(void (*)(void))kind##_der2##keytype##_newctx }, \
|
2020-08-16 21:25:08 +02:00
|
|
|
{ OSSL_FUNC_DECODER_FREECTX, \
|
2020-07-27 18:40:05 +02:00
|
|
|
(void (*)(void))der2key_freectx }, \
|
2020-08-16 21:25:08 +02:00
|
|
|
{ OSSL_FUNC_DECODER_GETTABLE_PARAMS, \
|
PROV: Re-implement all the keypair decoders
The base functionality to implement the keypair decoders doesn't
change much, but this results in a more massive amount of
OSSL_DISPATCH and OSSL_ALGORITHM arrays, to support a fine grained
selection of implementation based on what parts of the keypair
structure (combinations of key parameters, public key and private key)
should be expected as input, the input type ("DER", "PEM", ...) and the
outermost input structure ("pkcs8", "SubjectPublicKeyInfo", key
type specific structures, ...).
We add support for the generic structure name "type-specific", to
allow selecting that without knowing the exact name of that structure.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 13:22:54 +01:00
|
|
|
(void (*)(void))kind##_der2##keytype##_gettable_params }, \
|
2020-08-16 21:25:08 +02:00
|
|
|
{ OSSL_FUNC_DECODER_GET_PARAMS, \
|
PROV: Re-implement all the keypair decoders
The base functionality to implement the keypair decoders doesn't
change much, but this results in a more massive amount of
OSSL_DISPATCH and OSSL_ALGORITHM arrays, to support a fine grained
selection of implementation based on what parts of the keypair
structure (combinations of key parameters, public key and private key)
should be expected as input, the input type ("DER", "PEM", ...) and the
outermost input structure ("pkcs8", "SubjectPublicKeyInfo", key
type specific structures, ...).
We add support for the generic structure name "type-specific", to
allow selecting that without knowing the exact name of that structure.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 13:22:54 +01:00
|
|
|
(void (*)(void))kind##_der2##keytype##_get_params }, \
|
|
|
|
{ OSSL_FUNC_DECODER_DOES_SELECTION, \
|
|
|
|
(void (*)(void))kind##_der2##keytype##_does_selection }, \
|
2020-08-16 21:25:08 +02:00
|
|
|
{ OSSL_FUNC_DECODER_DECODE, \
|
|
|
|
(void (*)(void))der2key_decode }, \
|
|
|
|
{ OSSL_FUNC_DECODER_EXPORT_OBJECT, \
|
2020-07-27 18:40:05 +02:00
|
|
|
(void (*)(void))der2key_export_object }, \
|
|
|
|
{ 0, NULL } \
|
|
|
|
}
|
|
|
|
|
|
|
|
#ifndef OPENSSL_NO_DH
|
PROV: Re-implement all the keypair decoders
The base functionality to implement the keypair decoders doesn't
change much, but this results in a more massive amount of
OSSL_DISPATCH and OSSL_ALGORITHM arrays, to support a fine grained
selection of implementation based on what parts of the keypair
structure (combinations of key parameters, public key and private key)
should be expected as input, the input type ("DER", "PEM", ...) and the
outermost input structure ("pkcs8", "SubjectPublicKeyInfo", key
type specific structures, ...).
We add support for the generic structure name "type-specific", to
allow selecting that without knowing the exact name of that structure.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 13:22:54 +01:00
|
|
|
MAKE_DECODER("DH", dh, dh, PKCS8);
|
|
|
|
MAKE_DECODER("DH", dh, dh, SubjectPublicKeyInfo);
|
|
|
|
MAKE_DECODER("DH", dh, dh, type_specific_params);
|
|
|
|
MAKE_DECODER("DH", dh, dh, DH);
|
|
|
|
MAKE_DECODER("DHX", dhx, dhx, PKCS8);
|
|
|
|
MAKE_DECODER("DHX", dhx, dhx, SubjectPublicKeyInfo);
|
|
|
|
MAKE_DECODER("DHX", dhx, dhx, type_specific_params);
|
|
|
|
MAKE_DECODER("DHX", dhx, dhx, DHX);
|
2020-07-27 18:40:05 +02:00
|
|
|
#endif
|
|
|
|
#ifndef OPENSSL_NO_DSA
|
PROV: Re-implement all the keypair decoders
The base functionality to implement the keypair decoders doesn't
change much, but this results in a more massive amount of
OSSL_DISPATCH and OSSL_ALGORITHM arrays, to support a fine grained
selection of implementation based on what parts of the keypair
structure (combinations of key parameters, public key and private key)
should be expected as input, the input type ("DER", "PEM", ...) and the
outermost input structure ("pkcs8", "SubjectPublicKeyInfo", key
type specific structures, ...).
We add support for the generic structure name "type-specific", to
allow selecting that without knowing the exact name of that structure.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 13:22:54 +01:00
|
|
|
MAKE_DECODER("DSA", dsa, dsa, PKCS8);
|
|
|
|
MAKE_DECODER("DSA", dsa, dsa, SubjectPublicKeyInfo);
|
|
|
|
MAKE_DECODER("DSA", dsa, dsa, type_specific);
|
|
|
|
MAKE_DECODER("DSA", dsa, dsa, DSA);
|
2020-07-27 18:40:05 +02:00
|
|
|
#endif
|
|
|
|
#ifndef OPENSSL_NO_EC
|
PROV: Re-implement all the keypair decoders
The base functionality to implement the keypair decoders doesn't
change much, but this results in a more massive amount of
OSSL_DISPATCH and OSSL_ALGORITHM arrays, to support a fine grained
selection of implementation based on what parts of the keypair
structure (combinations of key parameters, public key and private key)
should be expected as input, the input type ("DER", "PEM", ...) and the
outermost input structure ("pkcs8", "SubjectPublicKeyInfo", key
type specific structures, ...).
We add support for the generic structure name "type-specific", to
allow selecting that without knowing the exact name of that structure.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 13:22:54 +01:00
|
|
|
MAKE_DECODER("EC", ec, ec, PKCS8);
|
|
|
|
MAKE_DECODER("EC", ec, ec, SubjectPublicKeyInfo);
|
|
|
|
MAKE_DECODER("EC", ec, ec, type_specific_no_pub);
|
|
|
|
MAKE_DECODER("EC", ec, ec, EC);
|
|
|
|
MAKE_DECODER("X25519", x25519, ecx, PKCS8);
|
|
|
|
MAKE_DECODER("X25519", x25519, ecx, SubjectPublicKeyInfo);
|
|
|
|
MAKE_DECODER("X448", x448, ecx, PKCS8);
|
|
|
|
MAKE_DECODER("X448", x448, ecx, SubjectPublicKeyInfo);
|
|
|
|
MAKE_DECODER("ED25519", ed25519, ecx, PKCS8);
|
|
|
|
MAKE_DECODER("ED25519", ed25519, ecx, SubjectPublicKeyInfo);
|
|
|
|
MAKE_DECODER("ED448", ed448, ecx, PKCS8);
|
|
|
|
MAKE_DECODER("ED448", ed448, ecx, SubjectPublicKeyInfo);
|
2021-01-28 08:22:09 +01:00
|
|
|
# ifndef OPENSSL_NO_SM2
|
|
|
|
MAKE_DECODER("SM2", sm2, ec, PKCS8);
|
|
|
|
MAKE_DECODER("SM2", sm2, ec, SubjectPublicKeyInfo);
|
|
|
|
# endif
|
2020-07-27 18:40:05 +02:00
|
|
|
#endif
|
PROV: Re-implement all the keypair decoders
The base functionality to implement the keypair decoders doesn't
change much, but this results in a more massive amount of
OSSL_DISPATCH and OSSL_ALGORITHM arrays, to support a fine grained
selection of implementation based on what parts of the keypair
structure (combinations of key parameters, public key and private key)
should be expected as input, the input type ("DER", "PEM", ...) and the
outermost input structure ("pkcs8", "SubjectPublicKeyInfo", key
type specific structures, ...).
We add support for the generic structure name "type-specific", to
allow selecting that without knowing the exact name of that structure.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13248)
2020-10-26 13:22:54 +01:00
|
|
|
MAKE_DECODER("RSA", rsa, rsa, PKCS8);
|
|
|
|
MAKE_DECODER("RSA", rsa, rsa, SubjectPublicKeyInfo);
|
|
|
|
MAKE_DECODER("RSA", rsa, rsa, type_specific_keypair);
|
|
|
|
MAKE_DECODER("RSA", rsa, rsa, RSA);
|
|
|
|
MAKE_DECODER("RSA-PSS", rsapss, rsapss, PKCS8);
|
|
|
|
MAKE_DECODER("RSA-PSS", rsapss, rsapss, SubjectPublicKeyInfo);
|