Since EncryptedPrivateKeyInfo is a recognised structure, it's
reasonable to think that someone might want to specify it.
To be noted is that if someone specifies the structure PrivateKeyInfo
but has also passed a passphrase callback, the result will still
become a EncryptedPrivateKeyInfo structure.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16466)
The data structure wasn't given for recognised certificates or CRLs.
It's better, though, to specify it for those objects as well, so they
can be used to filter what actually gets decoded, which will be
helpful for our OSSL_STORE 'file:' scheme implementation.
Fixes#16224
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16466)
encode_key2text.c(689): error C4703: potentially uninitialized local pointer variable 'modulus_label' used
encode_key2text.c(691): error C4703: potentially uninitialized local pointer variable 'exponent_label' used
CLA: trivial
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12845)
When decoding a key and asking the keymgmt to import the key data, it
was told that the key data includes everything. This may not be true,
since the user may have specified a different selection, and some
keymgmts may want to be informed.
Our key decoders' export function, on the other hand, didn't care
either, and simply export anything they could, regardless.
In both cases, the selection that was specified by the user is now
passed all the way.
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15934)
This is to avoid creating confusion where other PEM decoder
implementations may know better what PEM names that are unknown to us
actually mean.
Fixes#15929
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15930)
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)
This has us switch from the 'structure' "pkcs8" to "PrivateKeyInfo",
which is sensible considering we already have "SubjectPublicKeyInfo".
We also add "EncryptedPrivateKeyInfo", and use it for a special decoder
that detects and decrypts an EncryptedPrivateKeyInfo structured DER
blob into a PrivateKeyInfo structured DER blob and passes that on to
the next decoder implementation.
The result of this change is that PKCS#8 decryption should only happen
once per decoding instead of once for every expected key type.
Furthermore, this new decoder implementation sets the data type to the
OID of the algorithmIdentifier field, thus reducing how many decoder
implementations are tentativaly run further down the call chain.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15498)
They aren't needed at all any more, since the properties contain the
same information.
This also drops the parameter names OSSL_ENCODER_PARAM_OUTPUT_TYPE
and OSSL_ENCODER_PARAM_OUTPUT_STRUCTURE
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15570)
This was a poor substitute for using the name of the decoder implementation,
and since there is functionality to get the latter now, this parameter
can be dropped.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15570)
They aren't needed at all any more, since the properties contain the
same information.
This also drops the parameter names OSSL_DECODER_PARAM_INPUT_TYPE
and OSSL_DECODER_PARAM_INPUT_STRUCTURE.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15570)
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14587)
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14587)
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14587)
Remove a TODO that is no longer relevant and
drop some more non-fips sources from the fips checksums.
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/15191)
This commit sets the error mark before calling d2i_X509_SIG
and clear it if that function call is successful.
The motivation for this is that if d2i_X509_SIG returns NULL then the
else clause will be entered and d2i_PKCS8_PRIV_KEY_INFO will be
called. If d2i_X509_SIG raised any errors those error will be on the
error stack when d2i_PKCS8_PRIV_KEY_INFO gets called, and even if it
returns successfully those errors will still be on the error stack.
We ran into this issue when upgrading Node.js to 3.0.0-alpha15.
More details can be found in the ref links below.
Refs: https://github.com/nodejs/node/issues/38373
Refs: https://github.com/danbev/learning-libcrypto/blob/master/notes/wrong-tag-issue2.md
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/15067)
libimplementations.a was a nice idea, but had a few flaws:
1. The idea to have common code in libimplementations.a and FIPS
sensitive helper functions in libfips.a / libnonfips.a didn't
catch on, and we saw full implementation ending up in them instead
and not appearing in libimplementations.a at all.
2. Because more or less ALL algorithm implementations were included
in libimplementations.a (the idea being that the appropriate
objects from it would be selected automatically by the linker when
building the shared libraries), it's very hard to find only the
implementation source that should go into the FIPS module, with
the result that the FIPS checksum mechanism include source files
that it shouldn't
To mitigate, we drop libimplementations.a, but retain the idea of
collecting implementations in static libraries. With that, we not
have:
libfips.a
Includes all implementations that should become part of the FIPS
provider.
liblegacy.a
Includes all implementations that should become part of the legacy
provider.
libdefault.a
Includes all implementations that should become part of the
default and base providers.
With this, libnonfips.a becomes irrelevant and is dropped.
libcommon.a is retained to include common provider code that can be
used uniformly by all providers.
Fixes#15157
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15171)
This includes the special decoder used in our STOREMGMT 'file:' implementation
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14834)
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)
