diff options
author | Richard Levitte <levitte@openssl.org> | 2020-10-02 14:21:51 +0200 |
---|---|---|
committer | Richard Levitte <levitte@openssl.org> | 2020-10-04 13:01:47 +0200 |
commit | 70c06aafa691a77861bd3d3aaf93afa2a55e04ce (patch) | |
tree | 2ccf9e7a520951f69585d9afaa1d82fe4bc4f7a5 /doc | |
parent | ecadfdadde491572b0bdf3c5a95e7a6a004585c6 (diff) |
DECODER: Allow precise result type for OSSL_DECODER_CTX_new_by_EVP_PKEY()
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)
Diffstat (limited to 'doc')
-rw-r--r-- | doc/man3/OSSL_DECODER_CTX_new_by_EVP_PKEY.pod | 13 |
1 files changed, 10 insertions, 3 deletions
diff --git a/doc/man3/OSSL_DECODER_CTX_new_by_EVP_PKEY.pod b/doc/man3/OSSL_DECODER_CTX_new_by_EVP_PKEY.pod index 4190c4232b..c57438072b 100644 --- a/doc/man3/OSSL_DECODER_CTX_new_by_EVP_PKEY.pod +++ b/doc/man3/OSSL_DECODER_CTX_new_by_EVP_PKEY.pod @@ -14,7 +14,8 @@ OSSL_DECODER_CTX_set_passphrase_cb #include <openssl/decoder.h> OSSL_DECODER_CTX * - OSSL_DECODER_CTX_new_by_EVP_PKEY(const EVP_PKEY *pkey, const char *input_type, + OSSL_DECODER_CTX_new_by_EVP_PKEY(const EVP_PKEY *pkey, + const char *input_type, const char *keytype, OPENSSL_CTX *libctx, const char *propquery); int OSSL_DECODER_CTX_set_passphrase(OSSL_DECODER_CTX *ctx, @@ -44,8 +45,14 @@ data suitable for B<EVP_PKEY>s. All these implementations are implicitly fetched using I<libctx> and I<propquery>. The search of decoder implementations can be limited with I<input_type>, -which specifies a starting input type. This is further explained in -L<OSSL_DECODER_CTX_set_input_type(3)>. +which specifies a starting input type. NULL is valid input and signifies +that the decoder implementations will find out the input type on their own. +This is further explained in L<OSSL_DECODER_CTX_set_input_type(3)>. + +The search of decoder implementations can also be limited with I<keytype>, +which specifies the expected resulting keytype. NULL is valid input and +signifies that the decoder implementations will find out the keytype on +their own from the input they get. If no suitable decoder implementation is found, OSSL_DECODER_CTX_new_by_EVP_PKEY() still creates a B<OSSL_DECODER_CTX>, but |