The parameter makes the dsa key encoder to skip saving the DSA
key parameters similarly to what the legacy dsa key encoder did.
Fixes#14362
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/14746)
The legacy implementation would print the ASN.1 value of the trailerfield,
except when it wasn't set (i.e. is default).
For better consistency, we now always print the ASN.1 value, both in the
legacy and the provided implementation.
Fixes#14363
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14676)
To make this cleaner, decoder_ms2key.c is split into decoder_msblob2key.c
and decoder_pvk2key.c.
This required a great deal of refactoring of crypto/pem/pvkfmt.c, to
make cleaner internal functions that our decoder implementations can
use.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14314)
This required refactoring a number of functions from the diverse
EVP_PKEY_ASN1_METHOD implementations to become shared backend
functions. It also meant modifying a few of them to return pointers
to our internal RSA / DSA/ DH / EC_KEY, ... structures instead of
manipulating an EVP_PKEY pointer directly, letting the caller do the
latter.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14314)
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)
The decoding of DER into keys with keytype specific routines depended
entirely on the absence of the generic algo specific C type from
EVP_PKEYs. That is not necessary, and may even prove to be a bit of a
disadvantage, depending on what libcrypto has to offer in terms of
type specific d2i functionality for different kinds of input
structures.
To remedy, we try with all available type specific functions first,
and only turn to the general d2i functions (those that return an
EVP_PKEY) as a last resort.
Furthermore, there are cases where the decoder might not get the key
type it expected. This may happen when certain key types that share
the same OpenSSL structure may be mixed up somehow. The known cases
are EC vs SM2 and RSA vs RSA-PSS.
To remedy, we add the possibility to specify a checking function that
can check if the key that was decoded meets decoder expectations.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14314)
Those TODOs do not really apply to 3.0 as the legacy internal
keys will stay.
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14367)
Partial fix for #12964
This adds ossl_ names for the following symbols:
ec_*, ecx_*, ecdh_*, ecdsa_*, sm2_*
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14231)
Partial fix for #12964
This adds ossl_ names for the following symbols:
dsa_check_pairwise, dsa_check_params, dsa_check_priv_key, dsa_check_pub_key, dsa_check_pub_key_partial,
dsa_do_sign_int, dsa_ffc_params_fromdata,
dsa_generate_ffc_parameters, dsa_generate_public_key,
dsa_get0_params, dsa_key_fromdata, dsa_new_with_ctx, dsa_pkey_method, dsa_sign_int
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14231)
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)
The pem2der decoder can infer certain information about the endoded der
data based on the PEM headers. This information should be passed to the
next decoders in the chain to ensure we end up loading the correct type of
thing.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14191)
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/14086)
The PROV_R codes can be returned to applications so it is useful
to have some common set of provider reason codes for the applications
or third party providers.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/14086)
The EC KEYMGMT implementation handled SM2 as well, except what's
needed to support decoding: loading functions for both EC and SM2 that
checks for the presence or absence of the SM2 curve the same way as
the EC / SM2 import functions.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14028)
Because decoders are coupled with keymgmts from the same provider,
ours need to produce provider side keys the same way. Since our
keymgmts create key data with the provider library context, so must
our decoders.
We solve with functions to adjust the library context of decoded keys,
and use them.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/13661)
When OpenSSL is configured with 'no-dh', 'no-dsa' and 'no-ec'
combined, some static functions have no use, which the compiler may
complain about. We therefore add extra guards to silence it.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/13589)
EVP_PKEY_CTX_set_dh_ functions were only available when DH was enabled
('no-dsa' not configured). However, that makes it impossible to use
these functions with an engine or a provider that happens to implement
DH. This change solves that problem by shuffling these functions to
more appropriate places.
By consequence, there are a number of places where we can remove the
check of OPENSSL_NO_DH. This requires some re-arrangements of
internal tables to translate between numeric identities and names.
Partially fixes#13550
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/13589)
This allows 15-test_rsa.t to succeed, and provides the same OSSL_ENCODER
support for these formats as for all other formats supported in OpenSSL.
Fixes#13379
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/13645)
The OPENSSL_NO_RC4 guard remain around protected PVK tests in
test/endecoder_test.c.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13648)
Fixes#10366
The one place that actually used was in the legacy printing of ecparams.
This has been replaced by the pointtobuf variant.
The ecparam app was using one of these functions - this line has just been
removed as another PR will remove all the code generated lines..
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/13294)
The base functionality to implement the keypair encoders 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 output, the output type ("TEXT", "DER" or "PEM") and the
outermost output 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: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13167)
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)
The following internal functions are affected:
ossl_do_blob_header
ossl_do_PVK_header
ossl_b2i
ossl_b2i_bio
This is reflected by moving include/internal/pem.h to include/crypto/pem.h
engines/e_loader_attic gets the source code added to it to have
continued access to those functions.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/13195)
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)
We were getting confused with DHX parameters and encoding them as PKCS3
DH parameters instead.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13050)
The PEM->DER decoder passes the data type of its contents, something
that decoder_process() ignored.
On the other hand, the PEM->DER decoder passed nonsense.
Both issues are fixed here.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13060)
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)
This stops them leaking into other namespaces in a static build.
They remain internal.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13013)
ECX_KEY was not meant for public consumption, it was only to be
accessed indirectly via EVP routines. However, we still need internal
access for our decoders.
This partially reverts 7c664b1f1b5f60bf896f5fdea5c08c401c541dfe
Fixes#12880
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12956)
This only refactors them for the changed API, there's not yet a
separate DER to PEM encoder and therefore no chaining possibility
yet.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12873)
The encoder implementations were implemented by unnecessarily copying
code into numerous topical source files, making them hard to maintain.
This changes merges all those into two source files, one that encodes
into DER and PEM, the other to text.
Diverse small cleanups are included.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12803)
