add various checks for malformedness to static check_chain_extensions() in x509_vfc.c
improve error reporting of X509v3_cache_extensions() in v3_purp.c
add error reporting to x509_init_sig_info() in x509_set.c
improve static setup_dp() and related functions in v3_purp.c and v3_crld.c
add test case for non-conforming cert from https://tools.ietf.org/html/rfc8410#section-10.2
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12478)
If a path is specified with the -module option it will use this path to load the library when the provider is activated,
instead of also having to set the environment variable OPENSSL_MODULES.
Added a platform specific opt_path_end() function that uses existing functionality used by opt_progname().
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12761)
* Use strenghtened cert chain building, verifying chain using optional trust store
while making sure that no certificate status (e.g., CRL) checks are done
* Use OSSL_CMP_certConf_cb() by default and move its doc to OSSL_CMP_CTX_new.pod
* Simplify certificate and cert store loading in apps/cmp.c
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12741)
PEM_write_bio_PrivateKey_traditional() didn't handle provider-native
keys very well. Originally, it would simply use the corresponding
encoder, which is likely to output modern PEM (not "traditional").
PEM_write_bio_PrivateKey_traditional() is now changed to try and get a
legacy copy of the input EVP_PKEY, and use that copy for traditional
output, if it has such support.
Internally, evp_pkey_copy_downgraded() is added, to be used when
evp_pkey_downgrade() is too intrusive for what it's needed for.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12738)
Add the AuthEnvelopedData as defined in RFC 5083 with AES-GCM
parameter as defined in RFC 5084.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/8024)
The example to create an EC key from user data didn't show what one
could expect and application to do, especially with regard to how it's
done with raw EC functions. We therefore refactor it to make proper
use of a BIGNUM where expected, and also use OSSL_PARAM_BLD(3) for
easier handling of the OSSL_PARAM array.
Fixes#12388
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12389)
* Add -own_trusted option to CMP app
* Add OSSL_CMP_CTX_build_cert_chain()
* Add optional trust store arg to ossl_cmp_build_cert_chain()
* Extend the tests in cmp_protect_test.c and the documentation accordingly
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12791)
From this point on, this engine must be specifically specified.
To replace the internal EMBEDDED hack with something unique for the
new module, functions to create application specific OSSL_STORE_INFO
types were added.
Furthermore, the following function had to be exported:
ossl_do_blob_header()
ossl_do_PVK_header()
asn1_d2i_read_bio()
Finally, evp_pkcs82pkey_int() has become public under a new name,
EVP_PKCS82PKEY_with_libctx()
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12587)
Include more information about the new HMAC parameter. Also fill in some
missing documentation about the EVP_PKEY MAC bridge.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12732)
* In the cmp app so far the -verbosity option had been missing.
* Extend log output helpful for debugging CMP applications
in setup_ssl_ctx() of the cmp app, ossl_cmp_msg_add_extraCerts(),
OSSL_CMP_validate_msg(), and OSSL_CMP_MSG_http_perform().
* Correct suppression of log output with insufficient severity.
* Add logging/severity level OSSL_CMP_LOG_TRACE = OSSL_CMP_LOG_MAX.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12739)
CLA: trivial
Correct right shift to left shift.
Pseudo code `a&=~((~0)>>n)` means "get higher n-bits of a", but actually crypto lib gives lower n-bits.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12727)
Add an option to configuration files "config_diagnostics" that when set to a
non-zero value, overrides the error ignoring flags. The outcome is that
diagnostic option is produced when e.g. sections are missing.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12663)
This adds a flag, OCSP_PARTIAL_CHAIN, to the OCSP_basic_verify()
function. This is equivlent to X509_V_FLAG_PARTIAL_CHAIN, in that
if any certificate in the OCSP response is in the trust store, then
trust it.
Reviewed-by: David von Oheimb <david.von.oheimb@siemens.com>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12666)
This adds the needed code to make the OSSL_STORE API functions handle
provided STORE implementations.
This also modifies OSSL_STORE_attach() for have the URI, the
library context and the properties in the same order as
OSSL_STORE_open_with_libctx().
The most notable change, though, is how this creates a division of
labor between libcrypto and any storemgmt implementation that wants to
pass X.509, X.509 CRL, etc structures back to libcrypto. Since those
structures aren't directly supported in the libcrypto <-> provider
interface (asymmetric keys being the only exception so far), we resort
to a libcrypto object callback that can handle passed data in DER form
and does its part of figuring out what the DER content actually is.
This also adds the internal x509_crl_set0_libctx(), which works just
like x509_set0_libctx(), but for X509_CRL.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12512)
This makes it possible to use OSSL_DECODER in functions that are passed
a OSSL_PASSPHRASE_CALLBACK already.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12512)
When some function receives an OSSL_PARAM array to pilfer for data,
and there is a string of some sort, and all the code needs is to get
the pointer to the data, rather than a copy, there is currently no
other way than to use |param->data| directly. This is of course a
valid method, but lacks any safety check (is |param->data_type|
correct, for example?).
OSSL_PARAM_get_utf8_string_ptr() and OSSL_PARAM_get_octet_string_ptr()
helps the programmer with such things, by setting the argument pointer
to |param->data|.
Additionally, the handle the data types OSSL_PARAM_UTF8_PTR and
OSSL_PARAM_OCTET_PTR as well.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12512)
This includes fixing a bug that could only be discovered when no
loaders were registered.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12512)
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)
