We try EVP_PKEY_dup() and if it fails we re-decode it using the
legacy method as provided keys should be duplicable.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16648)
Previously all the SubjectPublicKeyInfo decoders were specific to a key
type. We would iterate over all them until a match was found for the correct
key type. Each one would fully decode the key before then testing whether
it was a match or not - throwing it away if not. This was very inefficient.
Instead we introduce a generic SubjectPublicKeyInfo decoder which figures
out what type of key is contained within it, before subsequently passing on
the data to a key type specific SubjectPublicKeyInfo decoder.
Fixes#15646
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15662)
The X509_PUBKEY_get0() was attempting to recreate any errors that might
have occurred from the earlier decode process when obtaining the EVP_PKEY.
This is brittle at best and the approach would only work with legacy keys.
We remove this and just report an error directly.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15504)
The function pem_read_bio_key_legacy() is a fallback route if we
failed to load a key via a provider. We should be using the legacy
specific d2i functions to force legacy otherwise we end up using a
provider anyway
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15504)
We should use a provider to decode a SubjectPublicKeyInfo structure if
we can. We should only use the legacy route if we are forcing legacy, or
if an ENGINE is in use.
Fixes#15393Fixes#15327
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15504)
If we are decoding a SubjectPublicKeyInfo structure then we must use all
of the data and must not have bytes "left over".
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15504)
When a key (SubjectPublicKeyInfo) is embedded in some other structure
it may use an implicit tag. However the decoders can only handle the
universal class and don't know how to interpret the implicit tag.
Therefore we modify the data into a form the decoders can handle.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15504)
Make sure we pass the libctx/propq around everywhere that we need it to
ensure we get provider keys when needed.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15591)
An ASN.1 object such as an X509 may have embedded objects in it such as
an X509_PUBKEY. If there is a libctx/propq in use then we need to make sure
we pass these down to the constructors of these embedded objects.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15591)
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)
Using OSSL_STORE is too heavy and breaks things.
There were also needed various fixes mainly for missing proper
handling of the SM2 keys in the OSSL_DECODER.
Fixes#14788
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15045)
The comment talks about the EVP_PKEY that is contained within an
X509_PUBKEY object and whether it has to be exactly the same as the one
passed by the caller in X509_PUBKEY_set(). IMO it does, so the TODO should
be dropped.
Fixes#14378
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14845)
This makes it possible to use d2i_<TYPE>_PUBKEY instead of the generic
d2i_PUBKEY()
This required adding a number of new d2i_<TYPE>_PUBKEY functions.
These are all kept internal.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14314)
When a SubjectPublicKeyInfo (SPKI) is decoded into an X509_PUBKEY
structure, the corresponding EVP_PKEY is automatically added as well.
This used to only support our built-in keytypes, and only in legacy
form.
This is now refactored by making The ASN1 implementation of the
X509_PUBKEY an EXTERN_ASN1, resulting in a more manual implementation
of the basic support routines. Specifically, the d2i routine will do
what was done in the callback before, and try to interpret the input
as an EVP_PKEY, first in legacy form, and then using OSSL_DECODER.
Fixes#13893
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14281)
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)
The configuration option 'no-rsa' was dropped with OpenSSL 1.1.0, so
this is simply a cleanup of the remains.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/13700)
This includes error reporting for libcrypto sub-libraries in surprising
places.
This was done using util/err-to-raise
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13318)
This also modifies i2d_PublicKey() and i2d_KeyParams() to support
provided keys.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13167)
These are meant to be used with functions like
OSSL_ENCODER_CTX_new_by_EVP_PKEY()
The OSSL_ENCODER_CTX_new_by_EVP_PKEY() manual is also expanded on the
topics of output types and selections.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13189)
This change makes the naming more consistent, because three different terms
were used for the same thing. (The term libctx was used by far most often.)
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12621)
Many of the new types introduced by OpenSSL 3.0 have an OSSL_ prefix,
e.g., OSSL_CALLBACK, OSSL_PARAM, OSSL_ALGORITHM, OSSL_SERIALIZER.
The OPENSSL_CTX type stands out a little by using a different prefix.
For consistency reasons, this type is renamed to OSSL_LIB_CTX.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12621)
The functions i2d_PrivateKey(), try_key_value() i store_result.c and
X509_PUBKEY_set() were all essentially duplicating this functionality
to some degree.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/13094)
Also adds error output tests on loading key files with unsupported algorithms to 30-test_evp.t
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/13023)
Just like d2i_PrivateKey() / d2i_PrivateKey_ex(), there's a need to
associate an EVP_PKEY extracted from a PUBKEY to a library context and
a property query string. Without it, a provider-native EVP_PKEY can
only fetch necessary internal algorithms from the default library
context, even though an application specific context should be used.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12671)
without error handling.
This takes up the ball from #11278
without trying to solve everything at once.
[extended tests]
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
(Merged from https://github.com/openssl/openssl/pull/11850)
The role of this cache was two-fold:
1. It was a cache of key copies exported to providers with which an
operation was initiated.
2. If the EVP_PKEY didn't have a legacy key, item 0 of the cache was
the corresponding provider side origin, while the rest was the
actual cache.
This dual role for item 0 made the code a bit confusing, so we now
make a separate keymgmt / keydata pair outside of that cache, which is
the provider side "origin" key.
A hard rule is that an EVP_PKEY cannot hold a legacy "origin" and a
provider side "origin" at the same time.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/11148)
It's already used internally, there's no reason the DER serializer
propqueries shouldn't be present alongside the PEM and TEXT ones.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11055)
Use of the low level DSA functions has been informally discouraged for a
long time. We now formally deprecate them.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10977)
With the provided method of creating the new X509_PUBKEY, an extra
EVP_PKEY is created and needs to be properly cleaned away.
(note: we could choose to keep it just as well, but there are
consequences, explained in a comment in the code)
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/11038)
We do this by letting a serializer serialize the provider side key to
a DER blob formatted according to the SubjectPublicKeyInfo structure
(see RFC 5280), and deserialize it in libcrypto using the usual d2i
function.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10851)
