OSSL_FUNC_decoder_does_selection() is a dispatchable decoder implementation
function that should return 1 if the given |selection| is supported by an
decoder implementation and 0 if not. This can be used by libcrypto
functionality to figure out if an encoder implementation should be
considered or not.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13248)
OSSL_DECODER_CTX_set_params() and OSSL_ENCODER_CTX_set_params() would
stop as soon as a decoder / encoder instance failed, which leaves the
rest of them with a possibly previous and different value.
Instead, these functions will now call them all, but will return 0 if
any of the instance calls failed.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13156)
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)
This adds OSSL_ENCODER_to_data() and OSSL_DECODER_from_data(). These
functions allow fairly simple rewrites of type-specific i2d and d2i
calls.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/13094)
If an explicit decoder start type was provided then it wasn't being
handled correctly in all cases. Specifically if a PEM start type was
provided then the decoder would fail.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/13050)
There is some data that is very difficult to guess. For example, DSA
parameters and X9.42 DH parameters look exactly the same, a SEQUENCE
of 3 INTEGER. Therefore, callers may need the possibility to select
the exact keytype that they expect to get.
This will also allow use to translate d2i_TYPEPrivateKey(),
d2i_TYPEPublicKey() and d2i_TYPEParams() into OSSL_DECODER terms much
more smoothly.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13061)
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)
Mostly source nits, but also removing a couple of OSSL_DECODER_PARAM
macros that are never used or even make sense.
Also, some function names weren't quite consistent. They were made a
bit more consistent in the OSSL_ENCODER API, now we bring that back to
OSSL_DECODER.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12873)
OSSL_ENCODER was developed before OSSL_DECODER, so the idea of
chaining and the resulting API came later. This series of changes
brings the same sort of API and functionality back to OSSL_ENCODER,
making the two APIs more consistent with each other.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/12873)
The conditions for a valid implementation allowed the 'decode'
function to be NULL or the 'export_object' was NULL. That condition
is changed so that 'decode' is checked to be non-NULL by itself.
Fixes#12819
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12849)
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)
This replaces the older 'file:' loader that is now an engine.
It's still possible to use the older 'file:' loader by explicitly
using the engine, and tests will remain for it as long as ENGINEs are
still supported (even through deprecated).
To support this storemgmt implementation, a few internal OSSL_DECODER
modifications are needed:
- An internal function that implements most of
OSSL_DECODER_CTX_new_by_EVP_PKEY(), but operates on an already
existing OSSL_DECODER_CTX instead of allocating a new one.
- Allow direct creation of a OSSL_DECODER from an OSSL_ALGORITHM.
It isn't attached to any provider, and is only used internally, to
simply catch any DER encoded object to be passed back to the
object callback with no further checking. This implementation
becomes the last resort decoder, when all "normal"
decodation attempts (i.e. those that are supposed to result
in an OpenSSL object of some sort) have failed.
Because file_store_attach() uses BIO_tell(), we must also support
BIO_ctrl() as a libcrypto upcall.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12587)
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)
The pass phrase prompter that's part of OSSL_ENCODER and OSSL_DECODER
is really a passphrase callback bridge between the diverse forms of
prompters that exist within OpenSSL: pem_password_cb, ui_method and
OSSL_PASSPHRASE_CALLBACK.
This can be generalised, to be re-used by other parts of OpenSSL, and
to thereby allow the users to specify whatever form of pass phrase
callback they need, while being able to pass that on to other APIs
that are called internally, in the form that those APIs demand.
Additionally, we throw in the possibility to cache pass phrases during
a "session" (we leave it to each API to define what a "session" is).
This is useful for any API that implements discovery and therefore may
need to get the same password more than once, such as OSSL_DECODER and
OSSL_STORE.
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)
