summaryrefslogtreecommitdiffstats
path: root/doc/man7
diff options
context:
space:
mode:
authorRichard Levitte <levitte@openssl.org>2022-12-05 16:59:06 +0100
committerRichard Levitte <levitte@openssl.org>2022-12-08 07:32:34 +0100
commit318a9dfa5f7bd1237d2697ad950697d241b8b49f (patch)
tree94b15166d17955fdacceebc4e7a1ffd2e547e164 /doc/man7
parentMove the description of the core types into their own pages (diff)
downloadopenssl-318a9dfa5f7bd1237d2697ad950697d241b8b49f.tar.xz
openssl-318a9dfa5f7bd1237d2697ad950697d241b8b49f.zip
Replace some boldened types with a corresponding man page link
The types OSSL_DISPATCH, OSSL_ITEM, OSSL_ALGORITHM, OSSL_PARAM, OSSL_CALLBACK, and OSSL_PASSPHRASE_CALLBACK are described in their own manual page, so we change every mention of them to links to those pages. Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/19842)
Diffstat (limited to 'doc/man7')
-rw-r--r--doc/man7/crypto.pod2
-rw-r--r--doc/man7/migration_guide.pod4
-rw-r--r--doc/man7/provider-asym_cipher.pod11
-rw-r--r--doc/man7/provider-base.pod26
-rw-r--r--doc/man7/provider-cipher.pod12
-rw-r--r--doc/man7/provider-decoder.pod22
-rw-r--r--doc/man7/provider-digest.pod12
-rw-r--r--doc/man7/provider-encoder.pod14
-rw-r--r--doc/man7/provider-kdf.pod12
-rw-r--r--doc/man7/provider-kem.pod11
-rw-r--r--doc/man7/provider-keyexch.pod15
-rw-r--r--doc/man7/provider-keymgmt.pod24
-rw-r--r--doc/man7/provider-mac.pod12
-rw-r--r--doc/man7/provider-rand.pod4
-rw-r--r--doc/man7/provider-signature.pod18
-rw-r--r--doc/man7/provider-storemgmt.pod12
-rw-r--r--doc/man7/provider.pod6
17 files changed, 106 insertions, 111 deletions
diff --git a/doc/man7/crypto.pod b/doc/man7/crypto.pod
index e114fb226e..bcbb170007 100644
--- a/doc/man7/crypto.pod
+++ b/doc/man7/crypto.pod
@@ -367,7 +367,7 @@ Most of these follow a common pattern. A "context" object is first created. For
example for a digest operation you would use an B<EVP_MD_CTX>, and for an
encryption/decryption operation you would use an B<EVP_CIPHER_CTX>. The
operation is then initialised ready for use via an "init" function - optionally
-passing in a set of parameters (using the B<OSSL_PARAM> type) to configure how
+passing in a set of parameters (using the L<OSSL_PARAM(3)> type) to configure how
the operation should behave. Next data is fed into the operation in a series of
"update" calls. The operation is finalised using a "final" call which will
typically provide some kind of output. Finally the context is cleaned up and
diff --git a/doc/man7/migration_guide.pod b/doc/man7/migration_guide.pod
index 64901b6388..d8c9b98107 100644
--- a/doc/man7/migration_guide.pod
+++ b/doc/man7/migration_guide.pod
@@ -957,7 +957,7 @@ See also L<crypto(7)/OPENSSL PROVIDERS>.
Implicit and Explicit Fetching is described in detail here
L<crypto(7)/ALGORITHM FETCHING>.
-=head3 Mapping EVP controls and flags to provider B<OSSL_PARAM> parameters
+=head3 Mapping EVP controls and flags to provider L<OSSL_PARAM(3)> parameters
The existing functions for controls (such as L<EVP_CIPHER_CTX_ctrl(3)>) and
manipulating flags (such as L<EVP_MD_CTX_set_flags(3)>)internally use
@@ -1459,7 +1459,7 @@ See L</Deprecated low-level key exchange functions>.
ECDH_KDF_X9_62()
Applications may either set this using the helper function
-L<EVP_PKEY_CTX_set_ecdh_kdf_type(3)> or by setting an B<OSSL_PARAM> using the
+L<EVP_PKEY_CTX_set_ecdh_kdf_type(3)> or by setting an L<OSSL_PARAM(3)> using the
"kdf-type" as shown in L<EVP_KEYEXCH-ECDH(7)/EXAMPLES>
=item *
diff --git a/doc/man7/provider-asym_cipher.pod b/doc/man7/provider-asym_cipher.pod
index e14a1d9019..ac3f627196 100644
--- a/doc/man7/provider-asym_cipher.pod
+++ b/doc/man7/provider-asym_cipher.pod
@@ -54,14 +54,14 @@ L<EVP_PKEY_decrypt(3)> and
other related functions).
All "functions" mentioned here are passed as function pointers between
-F<libcrypto> and the provider in B<OSSL_DISPATCH> arrays via
-B<OSSL_ALGORITHM> arrays that are returned by the provider's
+F<libcrypto> and the provider in L<OSSL_DISPATCH(3)> arrays via
+L<OSSL_ALGORITHM(3)> arrays that are returned by the provider's
provider_query_operation() function
(see L<provider-base(7)/Provider Functions>).
All these "functions" have a corresponding function type definition
named B<OSSL_FUNC_{name}_fn>, and a helper function to retrieve the
-function pointer from an B<OSSL_DISPATCH> element named
+function pointer from an L<OSSL_DISPATCH(3)> element named
B<OSSL_FUNC_{name}>.
For example, the "function" OSSL_FUNC_asym_cipher_newctx() has these:
@@ -69,7 +69,7 @@ For example, the "function" OSSL_FUNC_asym_cipher_newctx() has these:
static ossl_inline OSSL_FUNC_asym_cipher_newctx_fn
OSSL_FUNC_asym_cipher_newctx(const OSSL_DISPATCH *opf);
-B<OSSL_DISPATCH> arrays are indexed by numbers that are provided as
+L<OSSL_DISPATCH(3)> arrays are indexed by numbers that are provided as
macros in L<openssl-core_dispatch.h(7)>, as follows:
OSSL_FUNC_asym_cipher_newctx OSSL_FUNC_ASYM_CIPHER_NEWCTX
@@ -238,10 +238,9 @@ The negotiated TLS protocol version.
=back
OSSL_FUNC_asym_cipher_gettable_ctx_params() and OSSL_FUNC_asym_cipher_settable_ctx_params()
-get a constant B<OSSL_PARAM> array that describes the gettable and settable
+get a constant L<OSSL_PARAM(3)> array that describes the gettable and settable
parameters, i.e. parameters that can be used with OSSL_FUNC_asym_cipherget_ctx_params()
and OSSL_FUNC_asym_cipher_set_ctx_params() respectively.
-See L<OSSL_PARAM(3)> for the use of B<OSSL_PARAM> as parameter descriptor.
=head1 RETURN VALUES
diff --git a/doc/man7/provider-base.pod b/doc/man7/provider-base.pod
index af8baf6dc9..30b460cb29 100644
--- a/doc/man7/provider-base.pod
+++ b/doc/man7/provider-base.pod
@@ -116,13 +116,13 @@ provider-base
=head1 DESCRIPTION
All "functions" mentioned here are passed as function pointers between
-F<libcrypto> and the provider in B<OSSL_DISPATCH> arrays, in the call
+F<libcrypto> and the provider in L<OSSL_DISPATCH(3)> arrays, in the call
of the provider initialization function. See L<provider(7)/Provider>
for a description of the initialization function. They are known as "upcalls".
All these "functions" have a corresponding function type definition
named B<OSSL_FUNC_{name}_fn>, and a helper function to retrieve the
-function pointer from a B<OSSL_DISPATCH> element named
+function pointer from a L<OSSL_DISPATCH(3)> element named
B<OSSL_FUNC_{name}>.
For example, the "function" core_gettable_params() has these:
@@ -131,10 +131,10 @@ For example, the "function" core_gettable_params() has these:
static ossl_inline OSSL_NAME_core_gettable_params_fn
OSSL_FUNC_core_gettable_params(const OSSL_DISPATCH *opf);
-B<OSSL_DISPATCH> arrays are indexed by numbers that are provided as
+L<OSSL_DISPATCH(3)> arrays are indexed by numbers that are provided as
macros in L<openssl-core_dispatch.h(7)>, as follows:
-For I<in> (the B<OSSL_DISPATCH> array passed from F<libcrypto> to the
+For I<in> (the L<OSSL_DISPATCH(3)> array passed from F<libcrypto> to the
provider):
core_gettable_params OSSL_FUNC_CORE_GETTABLE_PARAMS
@@ -182,7 +182,7 @@ provider):
provider_up_ref OSSL_FUNC_PROVIDER_UP_REF
provider_free OSSL_FUNC_PROVIDER_FREE
-For I<*out> (the B<OSSL_DISPATCH> array passed from the provider to
+For I<*out> (the L<OSSL_DISPATCH(3)> array passed from the provider to
F<libcrypto>):
provider_teardown OSSL_FUNC_PROVIDER_TEARDOWN
@@ -197,7 +197,7 @@ F<libcrypto>):
=head2 Core functions
core_gettable_params() returns a constant array of descriptor
-B<OSSL_PARAM>, for parameters that core_get_params() can handle.
+L<OSSL_PARAM(3)>, for parameters that core_get_params() can handle.
core_get_params() retrieves parameters from the core for the given I<handle>.
See L</Core parameters> below for a description of currently known
@@ -288,7 +288,7 @@ BIO_new_file(), BIO_new_mem_buf(), BIO_read_ex(), BIO_write_ex(), BIO_up_ref(),
BIO_free(), BIO_vprintf(), BIO_vsnprintf(), BIO_gets(), BIO_puts(),
BIO_ctrl(), OPENSSL_cleanse() and
OPENSSL_hexstr2buf() correspond exactly to the public functions with
-the same name. As a matter of fact, the pointers in the B<OSSL_DISPATCH>
+the same name. As a matter of fact, the pointers in the L<OSSL_DISPATCH(3)>
array are typically direct pointers to those public functions. Note that the BIO
functions take an B<OSSL_CORE_BIO> type rather than the standard B<BIO>
type. This is to ensure that a provider does not mix BIOs from the core
@@ -370,13 +370,13 @@ from the core's provider store.
It must free the passed I<provctx>.
provider_gettable_params() should return a constant array of
-descriptor B<OSSL_PARAM>, for parameters that provider_get_params()
+descriptor L<OSSL_PARAM(3)>, for parameters that provider_get_params()
can handle.
-provider_get_params() should process the B<OSSL_PARAM> array
+provider_get_params() should process the L<OSSL_PARAM(3)> array
I<params>, setting the values of the parameters it understands.
-provider_query_operation() should return a constant B<OSSL_ALGORITHM>
+provider_query_operation() should return a constant L<OSSL_ALGORITHM(3)>
that corresponds to the given I<operation_id>.
It should indicate if the core may store a reference to this array by
setting I<*no_store> to 0 (core may store a reference) or 1 (core may
@@ -387,13 +387,13 @@ provider_query_operation() is no longer directly required and that the function
pointers have been copied. The I<operation_id> should match that passed to
provider_query_operation() and I<algs> should be its return value.
-provider_get_reason_strings() should return a constant B<OSSL_ITEM>
+provider_get_reason_strings() should return a constant L<OSSL_ITEM(3)>
array that provides reason strings for reason codes the provider may
use when reporting errors using core_put_error().
The provider_get_capabilities() function should call the callback I<cb> passing
-it a set of B<OSSL_PARAM>s and the caller supplied argument I<arg>. The
-B<OSSL_PARAM>s should provide details about the capability with the name given
+it a set of L<OSSL_PARAM(3)>s and the caller supplied argument I<arg>. The
+L<OSSL_PARAM(3)>s should provide details about the capability with the name given
in the I<capability> argument relevant for the provider context I<provctx>. If a
provider supports multiple capabilities with the given name then it may call the
callback multiple times (one for each capability). Capabilities can be useful for
diff --git a/doc/man7/provider-cipher.pod b/doc/man7/provider-cipher.pod
index b5bbb1b91d..429a4173d6 100644
--- a/doc/man7/provider-cipher.pod
+++ b/doc/man7/provider-cipher.pod
@@ -63,14 +63,14 @@ L<EVP_EncryptUpdate(3)> and L<EVP_EncryptFinal(3)> (as well as the decrypt
equivalents and other related functions).
All "functions" mentioned here are passed as function pointers between
-F<libcrypto> and the provider in B<OSSL_DISPATCH> arrays via
-B<OSSL_ALGORITHM> arrays that are returned by the provider's
+F<libcrypto> and the provider in L<OSSL_DISPATCH(3)> arrays via
+L<OSSL_ALGORITHM(3)> arrays that are returned by the provider's
provider_query_operation() function
(see L<provider-base(7)/Provider Functions>).
All these "functions" have a corresponding function type definition
named B<OSSL_FUNC_{name}_fn>, and a helper function to retrieve the
-function pointer from an B<OSSL_DISPATCH> element named
+function pointer from an L<OSSL_DISPATCH(3)> element named
B<OSSL_FUNC_{name}>.
For example, the "function" OSSL_FUNC_cipher_newctx() has these:
@@ -78,7 +78,7 @@ For example, the "function" OSSL_FUNC_cipher_newctx() has these:
static ossl_inline OSSL_FUNC_cipher_newctx_fn
OSSL_FUNC_cipher_newctx(const OSSL_DISPATCH *opf);
-B<OSSL_DISPATCH> arrays are indexed by numbers that are provided as
+L<OSSL_DISPATCH(3)> arrays are indexed by numbers that are provided as
macros in L<openssl-core_dispatch.h(7)>, as follows:
OSSL_FUNC_cipher_newctx OSSL_FUNC_CIPHER_NEWCTX
@@ -193,7 +193,7 @@ the given provider side cipher context I<cctx> and stores them in I<params>.
Passing NULL for I<params> should return true.
OSSL_FUNC_cipher_gettable_params(), OSSL_FUNC_cipher_gettable_ctx_params(),
-and OSSL_FUNC_cipher_settable_ctx_params() all return constant B<OSSL_PARAM>
+and OSSL_FUNC_cipher_settable_ctx_params() all return constant L<OSSL_PARAM(3)>
arrays as descriptors of the parameters that OSSL_FUNC_cipher_get_params(),
OSSL_FUNC_cipher_get_ctx_params(), and OSSL_FUNC_cipher_set_ctx_params()
can handle, respectively. OSSL_FUNC_cipher_gettable_ctx_params() and
@@ -217,7 +217,7 @@ OSSL_FUNC_cipher_get_ctx_params() and OSSL_FUNC_cipher_set_ctx_params() should r
success or 0 on error.
OSSL_FUNC_cipher_gettable_params(), OSSL_FUNC_cipher_gettable_ctx_params() and
-OSSL_FUNC_cipher_settable_ctx_params() should return a constant B<OSSL_PARAM>
+OSSL_FUNC_cipher_settable_ctx_params() should return a constant L<OSSL_PARAM(3)>
array, or NULL if none is offered.
=head1 SEE ALSO
diff --git a/doc/man7/provider-decoder.pod b/doc/man7/provider-decoder.pod
index 2ac56cf1d1..f279955a60 100644
--- a/doc/man7/provider-decoder.pod
+++ b/doc/man7/provider-decoder.pod
@@ -50,7 +50,7 @@ object reference or intermediate decoded data from an encoded form
read from the given B<OSSL_CORE_BIO>. If the caller wants to decode
data from memory, it should provide a L<BIO_s_mem(3)> B<BIO>. The decoded
data or object reference is passed along with eventual metadata
-to the I<metadata_cb> as B<OSSL_PARAM> parameters.
+to the I<metadata_cb> as L<OSSL_PARAM(3)> parameters.
The decoder doesn't need to know more about the B<OSSL_CORE_BIO>
pointer than being able to pass it to the appropriate BIO upcalls (see
@@ -67,14 +67,14 @@ that object into a different provider the OSSL_FUNC_decoder_export_object()
can be called as the final step of the decoding process.
All "functions" mentioned here are passed as function pointers between
-F<libcrypto> and the provider in B<OSSL_DISPATCH> arrays via
-B<OSSL_ALGORITHM> arrays that are returned by the provider's
+F<libcrypto> and the provider in L<OSSL_DISPATCH(3)> arrays via
+L<OSSL_ALGORITHM(3)> arrays that are returned by the provider's
provider_query_operation() function
(see L<provider-base(7)/Provider Functions>).
All these "functions" have a corresponding function type definition
named B<OSSL_FUNC_{name}_fn>, and a helper function to retrieve the
-function pointer from an B<OSSL_DISPATCH> element named
+function pointer from an L<OSSL_DISPATCH(3)> element named
B<OSSL_FUNC_{name}>.
For example, the "function" OSSL_FUNC_decoder_decode() has these:
@@ -86,7 +86,7 @@ For example, the "function" OSSL_FUNC_decoder_decode() has these:
static ossl_inline OSSL_FUNC_decoder_decode_fn
OSSL_FUNC_decoder_decode(const OSSL_DISPATCH *opf);
-B<OSSL_DISPATCH> arrays are indexed by numbers that are provided as
+L<OSSL_DISPATCH(3)> arrays are indexed by numbers that are provided as
macros in L<openssl-core_dispatch.h(7)>, as follows:
OSSL_FUNC_decoder_get_params OSSL_FUNC_DECODER_GET_PARAMS
@@ -202,7 +202,7 @@ from I<params> that it recognises. Unrecognised parameters should be
ignored.
Passing NULL for I<params> should return true.
-OSSL_FUNC_decoder_settable_ctx_params() returns a constant B<OSSL_PARAM>
+OSSL_FUNC_decoder_settable_ctx_params() returns a constant L<OSSL_PARAM(3)>
array describing the parameters that OSSL_FUNC_decoder_set_ctx_params()
can handle.
@@ -217,18 +217,18 @@ exporting the object into that foreign provider if the foreign provider
supports the type of the object and provides an import function.
OSSL_FUNC_decoder_export_object() should export the object of size I<objref_sz>
-referenced by I<objref> as an B<OSSL_PARAM> array and pass that into the
+referenced by I<objref> as an L<OSSL_PARAM(3)> array and pass that into the
I<export_cb> as well as the given I<export_cbarg>.
=head2 Decoding functions
OSSL_FUNC_decoder_decode() should decode the data as read from
the B<OSSL_CORE_BIO> I<in> to produce decoded data or an object to be
-passed as reference in an B<OSSL_PARAM> array along with possible other
-metadata that was decoded from the input. This B<OSSL_PARAM> array is
+passed as reference in an L<OSSL_PARAM(3)> array along with possible other
+metadata that was decoded from the input. This L<OSSL_PARAM(3)> array is
then passed to the I<data_cb> callback. The I<selection> bits,
if relevant, should determine what the input data should contain.
-The decoding functions also take an B<OSSL_PASSPHRASE_CALLBACK> function
+The decoding functions also take an L<OSSL_PASSPHRASE_CALLBACK(3)> function
pointer along with a pointer to application data I<cbarg>, which should be
used when a pass phrase prompt is needed.
@@ -284,7 +284,7 @@ OSSL_FUNC_decoder_set_ctx_params() returns 1, unless a recognised
parameter was invalid or caused an error, for which 0 is returned.
OSSL_FUNC_decoder_settable_ctx_params() returns a pointer to an array of
-constant B<OSSL_PARAM> elements.
+constant L<OSSL_PARAM(3)> elements.
OSSL_FUNC_decoder_does_selection() returns 1 if the decoder implementation
supports any of the I<selection> bits, otherwise 0.
diff --git a/doc/man7/provider-digest.pod b/doc/man7/provider-digest.pod
index 4c90561e31..a3d79a48b3 100644
--- a/doc/man7/provider-digest.pod
+++ b/doc/man7/provider-digest.pod
@@ -55,14 +55,14 @@ them available to applications via the API functions L<EVP_DigestInit_ex(3)>,
L<EVP_DigestUpdate(3)> and L<EVP_DigestFinal(3)> (and other related functions).
All "functions" mentioned here are passed as function pointers between
-F<libcrypto> and the provider in B<OSSL_DISPATCH> arrays via
-B<OSSL_ALGORITHM> arrays that are returned by the provider's
+F<libcrypto> and the provider in L<OSSL_DISPATCH(3)> arrays via
+L<OSSL_ALGORITHM(3)> arrays that are returned by the provider's
provider_query_operation() function
(see L<provider-base(7)/Provider Functions>).
All these "functions" have a corresponding function type definition
named B<OSSL_FUNC_{name}_fn>, and a helper function to retrieve the
-function pointer from an B<OSSL_DISPATCH> element named
+function pointer from an L<OSSL_DISPATCH(3)> element named
B<OSSL_FUNC_{name}>.
For example, the "function" OSSL_FUNC_digest_newctx() has these:
@@ -70,7 +70,7 @@ For example, the "function" OSSL_FUNC_digest_newctx() has these:
static ossl_inline OSSL_FUNC_digest_newctx_fn
OSSL_FUNC_digest_newctx(const OSSL_DISPATCH *opf);
-B<OSSL_DISPATCH> arrays are indexed by numbers that are provided as
+L<OSSL_DISPATCH(3)> arrays are indexed by numbers that are provided as
macros in L<openssl-core_dispatch.h(7)>, as follows:
OSSL_FUNC_digest_newctx OSSL_FUNC_DIGEST_NEWCTX
@@ -158,13 +158,13 @@ OSSL_FUNC_digest_get_ctx_params() gets digest operation details details from
the given provider side digest context I<dctx> and stores them in I<params>.
Passing NULL for I<params> should return true.
-OSSL_FUNC_digest_gettable_params() returns a constant B<OSSL_PARAM> array
+OSSL_FUNC_digest_gettable_params() returns a constant L<OSSL_PARAM(3)> array
containing descriptors of the parameters that OSSL_FUNC_digest_get_params()
can handle.
OSSL_FUNC_digest_gettable_ctx_params() and
OSSL_FUNC_digest_settable_ctx_params() both return constant
-B<OSSL_PARAM> arrays as descriptors of the parameters that
+L<OSSL_PARAM(3)> arrays as descriptors of the parameters that
OSSL_FUNC_digest_get_ctx_params() and OSSL_FUNC_digest_set_ctx_params()
can handle, respectively. The array is based on the current state of
the provider side context if I<dctx> is not NULL and on the provider
diff --git a/doc/man7/provider-encoder.pod b/doc/man7/provider-encoder.pod
index 274f1456ec..f3e9ce5b16 100644
--- a/doc/man7/provider-encoder.pod
+++ b/doc/man7/provider-encoder.pod
@@ -83,14 +83,14 @@ with provider data coming from the same provider, for example keys
with the L<KEYMGMT|provider-keymgmt(7)> provider.
All "functions" mentioned here are passed as function pointers between
-F<libcrypto> and the provider in B<OSSL_DISPATCH> arrays via
-B<OSSL_ALGORITHM> arrays that are returned by the provider's
+F<libcrypto> and the provider in L<OSSL_DISPATCH(3)> arrays via
+L<OSSL_ALGORITHM(3)> arrays that are returned by the provider's
provider_query_operation() function
(see L<provider-base(7)/Provider Functions>).
All these "functions" have a corresponding function type definition
named B<OSSL_FUNC_{name}_fn>, and a helper function to retrieve the
-function pointer from an B<OSSL_DISPATCH> element named
+function pointer from an L<OSSL_DISPATCH(3)> element named
B<OSSL_FUNC_{name}>.
For example, the "function" OSSL_FUNC_encoder_encode() has these:
@@ -103,7 +103,7 @@ For example, the "function" OSSL_FUNC_encoder_encode() has these:
static ossl_inline OSSL_FUNC_encoder_encode_fn
OSSL_FUNC_encoder_encode(const OSSL_DISPATCH *opf);
-B<OSSL_DISPATCH> arrays are indexed by numbers that are provided as
+L<OSSL_DISPATCH(3)> arrays are indexed by numbers that are provided as
macros in L<openssl-core_dispatch.h(7)>, as follows:
OSSL_FUNC_encoder_get_params OSSL_FUNC_ENCODER_GET_PARAMS
@@ -213,7 +213,7 @@ from I<params> that it recognises. Unrecognised parameters should be
ignored.
Passing NULL for I<params> should return true.
-OSSL_FUNC_encoder_settable_ctx_params() returns a constant B<OSSL_PARAM>
+OSSL_FUNC_encoder_settable_ctx_params() returns a constant L<OSSL_PARAM(3)>
array describing the parameters that OSSL_FUNC_encoder_set_ctx_params()
can handle.
@@ -242,7 +242,7 @@ OSSL_FUNC_encoder_encode() should take a provider-native object (in
I<obj_raw>) or an object abstraction (in I<obj_abstract>), and should output
the object in encoded form to the B<OSSL_CORE_BIO>. The I<selection> bits,
if relevant, should determine in greater detail what will be output.
-The encoding functions also take an B<OSSL_PASSPHRASE_CALLBACK> function
+The encoding functions also take an L<OSSL_PASSPHRASE_CALLBACK(3)> function
pointer along with a pointer to application data I<cbarg>, which should be
used when a pass phrase prompt is needed.
@@ -304,7 +304,7 @@ OSSL_FUNC_encoder_set_ctx_params() returns 1, unless a recognised
parameter was invalid or caused an error, for which 0 is returned.
OSSL_FUNC_encoder_settable_ctx_params() returns a pointer to an array of
-constant B<OSSL_PARAM> elements.
+constant L<OSSL_PARAM(3)> elements.
OSSL_FUNC_encoder_does_selection() returns 1 if the encoder implementation
supports any of the I<selection> bits, otherwise 0.
diff --git a/doc/man7/provider-kdf.pod b/doc/man7/provider-kdf.pod
index 58337bf3db..4221f9a0f4 100644
--- a/doc/man7/provider-kdf.pod
+++ b/doc/man7/provider-kdf.pod
@@ -47,14 +47,14 @@ them available to applications via the API functions L<EVP_KDF_CTX_reset(3)>,
and L<EVP_KDF_derive(3)>.
All "functions" mentioned here are passed as function pointers between
-F<libcrypto> and the provider in B<OSSL_DISPATCH> arrays via
-B<OSSL_ALGORITHM> arrays that are returned by the provider's
+F<libcrypto> and the provider in L<OSSL_DISPATCH(3)> arrays via
+L<OSSL_ALGORITHM(3)> arrays that are returned by the provider's
provider_query_operation() function
(see L<provider-base(7)/Provider Functions>).
All these "functions" have a corresponding function type definition
named B<OSSL_FUNC_{name}_fn>, and a helper function to retrieve the
-function pointer from an B<OSSL_DISPATCH> element named
+function pointer from an L<OSSL_DISPATCH(3)> element named
B<OSSL_FUNC_{name}>.
For example, the "function" OSSL_FUNC_kdf_newctx() has these:
@@ -62,7 +62,7 @@ For example, the "function" OSSL_FUNC_kdf_newctx() has these:
static ossl_inline OSSL_FUNC_kdf_newctx_fn
OSSL_FUNC_kdf_newctx(const OSSL_DISPATCH *opf);
-B<OSSL_DISPATCH> array entries are identified by numbers that are provided as
+L<OSSL_DISPATCH(3)> array entries are identified by numbers that are provided as
macros in L<openssl-core_dispatch.h(7)>, as follows:
OSSL_FUNC_kdf_newctx OSSL_FUNC_KDF_NEWCTX
@@ -134,7 +134,7 @@ with the given provider side KDF context I<kctx> and stores them in I<params>.
Passing NULL for I<params> should return true.
OSSL_FUNC_kdf_gettable_params(), OSSL_FUNC_kdf_gettable_ctx_params(),
-and OSSL_FUNC_kdf_settable_ctx_params() all return constant B<OSSL_PARAM>
+and OSSL_FUNC_kdf_settable_ctx_params() all return constant L<OSSL_PARAM(3)>
arrays as descriptors of the parameters that OSSL_FUNC_kdf_get_params(),
OSSL_FUNC_kdf_get_ctx_params(), and OSSL_FUNC_kdf_set_ctx_params()
can handle, respectively. OSSL_FUNC_kdf_gettable_ctx_params() and
@@ -330,7 +330,7 @@ OSSL_FUNC_kdf_get_ctx_params() and OSSL_FUNC_kdf_set_ctx_params() should return
success or 0 on error.
OSSL_FUNC_kdf_gettable_params(), OSSL_FUNC_kdf_gettable_ctx_params() and
-OSSL_FUNC_kdf_settable_ctx_params() should return a constant B<OSSL_PARAM>
+OSSL_FUNC_kdf_settable_ctx_params() should return a constant L<OSSL_PARAM(3)>
array, or NULL if none is offered.
=head1 NOTES
diff --git a/doc/man7/provider-kem.pod b/doc/man7/provider-kem.pod
index 938a25b7e8..a76466ada9 100644
--- a/doc/man7/provider-kem.pod
+++ b/doc/man7/provider-kem.pod
@@ -56,14 +56,14 @@ via the API functions L<EVP_PKEY_encapsulate(3)>,
L<EVP_PKEY_decapsulate(3)> and other related functions.
All "functions" mentioned here are passed as function pointers between
-F<libcrypto> and the provider in B<OSSL_DISPATCH> arrays via
-B<OSSL_ALGORITHM> arrays that are returned by the provider's
+F<libcrypto> and the provider in L<OSSL_DISPATCH(3)> arrays via
+L<OSSL_ALGORITHM(3)> arrays that are returned by the provider's
provider_query_operation() function
(see L<provider-base(7)/Provider Functions>).
All these "functions" have a corresponding function type definition
named B<OSSL_FUNC_{name}_fn>, and a helper function to retrieve the
-function pointer from an B<OSSL_DISPATCH> element named
+function pointer from an L<OSSL_DISPATCH(3)> element named
B<OSSL_FUNC_{name}>.
For example, the "function" OSSL_FUNC_kem_newctx() has these:
@@ -71,7 +71,7 @@ For example, the "function" OSSL_FUNC_kem_newctx() has these:
static ossl_inline OSSL_FUNC_kem_newctx_fn
OSSL_FUNC_kem_newctx(const OSSL_DISPATCH *opf);
-B<OSSL_DISPATCH> arrays are indexed by numbers that are provided as
+L<OSSL_DISPATCH(3)> arrays are indexed by numbers that are provided as
macros in L<openssl-core_dispatch.h(7)>, as follows:
OSSL_FUNC_kem_newctx OSSL_FUNC_KEM_NEWCTX
@@ -199,10 +199,9 @@ Passing NULL for I<params> should return true.
No parameters are currently recognised by built-in asymmetric kem algorithms.
OSSL_FUNC_kem_gettable_ctx_params() and OSSL_FUNC_kem_settable_ctx_params()
-get a constant B<OSSL_PARAM> array that describes the gettable and settable
+get a constant L<OSSL_PARAM(3)> array that describes the gettable and settable
parameters, i.e. parameters that can be used with OSSL_FUNC_kem_get_ctx_params()
and OSSL_FUNC_kem_set_ctx_params() respectively.
-See L<OSSL_PARAM(3)> for the use of B<OSSL_PARAM> as parameter descriptor.
=head1 RETURN VALUES
diff --git a/doc/man7/provider-keyexch.pod b/doc/man7/provider-keyexch.pod
index 48d27988f5..9e146d31c7 100644
--- a/doc/man7/provider-keyexch.pod
+++ b/doc/man7/provider-keyexch.pod
@@ -48,14 +48,14 @@ L<EVP_PKEY_derive(3)> and
other related functions).
All "functions" mentioned here are passed as function pointers between
-F<libcrypto> and the provider in B<OSSL_DISPATCH> arrays via
-B<OSSL_ALGORITHM> arrays that are returned by the provider's
+F<libcrypto> and the provider in L<OSSL_DISPATCH(3)> arrays via
+L<OSSL_ALGORITHM(3)> arrays that are returned by the provider's
provider_query_operation() function
(see L<provider-base(7)/Provider Functions>).
All these "functions" have a corresponding function type definition
named B<OSSL_FUNC_{name}_fn>, and a helper function to retrieve the
-function pointer from an B<OSSL_DISPATCH> element named
+function pointer from an L<OSSL_DISPATCH(3)> element named
B<OSSL_FUNC_{name}>.
For example, the "function" OSSL_FUNC_keyexch_newctx() has these:
@@ -63,7 +63,7 @@ For example, the "function" OSSL_FUNC_keyexch_newctx() has these:
static ossl_inline OSSL_FUNC_keyexch_newctx_fn
OSSL_FUNC_keyexch_newctx(const OSSL_DISPATCH *opf);
-B<OSSL_DISPATCH> arrays are indexed by numbers that are provided as
+L<OSSL_DISPATCH(3)> arrays are indexed by numbers that are provided as
macros in L<openssl-core_dispatch.h(7)>, as follows:
OSSL_FUNC_keyexch_newctx OSSL_FUNC_KEYEXCH_NEWCTX
@@ -146,17 +146,16 @@ given provider side key exchange context I<ctx> into I<params>,
see L</Common Key Exchange parameters>.
Passing NULL for I<params> should return true.
-OSSL_FUNC_keyexch_settable_ctx_params() yields a constant B<OSSL_PARAM> array that
+OSSL_FUNC_keyexch_settable_ctx_params() yields a constant L<OSSL_PARAM(3)> array that
describes the settable parameters, i.e. parameters that can be used with
OP_signature_set_ctx_params().
If OSSL_FUNC_keyexch_settable_ctx_params() is present, OSSL_FUNC_keyexch_set_ctx_params() must
also be present, and vice versa.
-Similarly, OSSL_FUNC_keyexch_gettable_ctx_params() yields a constant B<OSSL_PARAM>
+Similarly, OSSL_FUNC_keyexch_gettable_ctx_params() yields a constant L<OSSL_PARAM(3)>
array that describes the gettable parameters, i.e. parameters that can be
handled by OP_signature_get_ctx_params().
If OSSL_FUNC_keyexch_gettable_ctx_params() is present, OSSL_FUNC_keyexch_get_ctx_params() must
also be present, and vice versa.
-See L<OSSL_PARAM(3)> for the use of B<OSSL_PARAM> as parameter descriptor.
Notice that not all settable parameters are also gettable, and vice versa.
@@ -217,7 +216,7 @@ OSSL_FUNC_keyexch_set_params(), and OSSL_FUNC_keyexch_get_params() should return
or 0 on error.
OSSL_FUNC_keyexch_settable_ctx_params() and OSSL_FUNC_keyexch_gettable_ctx_params() should
-always return a constant B<OSSL_PARAM> array.
+always return a constant L<OSSL_PARAM(3)> array.
=head1 SEE ALSO
diff --git a/doc/man7/provider-keymgmt.pod b/doc/man7/provider-keymgmt.pod
index 17d8d4b338..74516f44d1 100644
--- a/doc/man7/provider-keymgmt.pod
+++ b/doc/man7/provider-keymgmt.pod
@@ -72,14 +72,14 @@ The primary responsibility of the KEYMGMT operation is to hold the
provider side key data for the OpenSSL library EVP_PKEY structure.
All "functions" mentioned here are passed as function pointers between
-F<libcrypto> and the provider in B<OSSL_DISPATCH> arrays via
-B<OSSL_ALGORITHM> arrays that are returned by the provider's
+F<libcrypto> and the provider in L<OSSL_DISPATCH(3)> arrays via
+L<OSSL_ALGORITHM(3)> arrays that are returned by the provider's
provider_query_operation() function
(see L<provider-base(7)/Provider Functions>).
All these "functions" have a corresponding function type definition
named B<OSSL_FUNC_{name}_fn>, and a helper function to retrieve the
-function pointer from a B<OSSL_DISPATCH> element named
+function pointer from a L<OSSL_DISPATCH(3)> element named
B<OSSL_FUNC_{name}>.
For example, the "function" OSSL_FUNC_keymgmt_new() has these:
@@ -87,7 +87,7 @@ For example, the "function" OSSL_FUNC_keymgmt_new() has these:
static ossl_inline OSSL_FUNC_keymgmt_new_fn
OSSL_FUNC_keymgmt_new(const OSSL_DISPATCH *opf);
-B<OSSL_DISPATCH> arrays are indexed by numbers that are provided as
+L<OSSL_DISPATCH(3)> arrays are indexed by numbers that are provided as
macros in L<openssl-core_dispatch.h(7)>, as follows:
OSSL_FUNC_keymgmt_new OSSL_FUNC_KEYMGMT_NEW
@@ -236,7 +236,7 @@ OSSL_FUNC_keymgmt_gen_set_params() should set additional parameters from
I<params> in the key object generation context I<genctx>.
OSSL_FUNC_keymgmt_gen_settable_params() should return a constant array of
-descriptor B<OSSL_PARAM>, for parameters that OSSL_FUNC_keymgmt_gen_set_params()
+descriptor L<OSSL_PARAM(3)>, for parameters that OSSL_FUNC_keymgmt_gen_set_params()
can handle.
OSSL_FUNC_keymgmt_gen() should perform the key object generation itself, and
@@ -264,7 +264,7 @@ OSSL_FUNC_keymgmt_get_params() should extract information data associated
with the given I<keydata>, see L</Common Information Parameters>.
OSSL_FUNC_keymgmt_gettable_params() should return a constant array of
-descriptor B<OSSL_PARAM>, for parameters that OSSL_FUNC_keymgmt_get_params()
+descriptor L<OSSL_PARAM(3)>, for parameters that OSSL_FUNC_keymgmt_get_params()
can handle.
If OSSL_FUNC_keymgmt_gettable_params() is present, OSSL_FUNC_keymgmt_get_params()
@@ -274,7 +274,7 @@ OSSL_FUNC_keymgmt_set_params() should update information data associated
with the given I<keydata>, see L</Common Information Parameters>.
OSSL_FUNC_keymgmt_settable_params() should return a constant array of
-descriptor B<OSSL_PARAM>, for parameters that OSSL_FUNC_keymgmt_set_params()
+descriptor L<OSSL_PARAM(3)>, for parameters that OSSL_FUNC_keymgmt_set_params()
can handle.
If OSSL_FUNC_keymgmt_settable_params() is present, OSSL_FUNC_keymgmt_set_params()
@@ -323,18 +323,18 @@ by the implementation of this function.
=head2 Key Object Import, Export and Duplication Functions
OSSL_FUNC_keymgmt_import() should import data indicated by I<selection> into
-I<keydata> with values taken from the B<OSSL_PARAM> array I<params>.
+I<keydata> with values taken from the L<OSSL_PARAM(3)> array I<params>.
OSSL_FUNC_keymgmt_export() should extract values indicated by I<selection>
-from I<keydata>, create an B<OSSL_PARAM> array with them and call
+from I<keydata>, create an L<OSSL_PARAM(3)> array with them and call
I<param_cb> with that array as well as the given I<cbarg>.
OSSL_FUNC_keymgmt_import_types() should return a constant array of descriptor
-B<OSSL_PARAM> for data indicated by I<selection>, for parameters that
+L<OSSL_PARAM(3)> for data indicated by I<selection>, for parameters that
OSSL_FUNC_keymgmt_import() can handle.
OSSL_FUNC_keymgmt_export_types() should return a constant array of descriptor
-B<OSSL_PARAM> for data indicated by I<selection>, that the
+L<OSSL_PARAM(3)> for data indicated by I<selection>, that the
OSSL_FUNC_keymgmt_export() callback can expect to receive.
OSSL_FUNC_keymgmt_dup() should duplicate data subsets indicated by
@@ -397,7 +397,7 @@ applies.
OSSL_FUNC_keymgmt_gettable_params() and OSSL_FUNC_keymgmt_settable_params()
OSSL_FUNC_keymgmt_import_types(), OSSL_FUNC_keymgmt_export_types()
should
-always return a constant B<OSSL_PARAM> array.
+always return a constant L<OSSL_PARAM(3)> array.
=head1 SEE ALSO
diff --git a/doc/man7/provider-mac.pod b/doc/man7/provider-mac.pod
index 5a1659121e..6d7bd46d29 100644
--- a/doc/man7/provider-mac.pod
+++ b/doc/man7/provider-mac.pod
@@ -48,14 +48,14 @@ them available to applications via the API functions L<EVP_MAC_init(3)>,
L<EVP_MAC_update(3)> and L<EVP_MAC_final(3)>.
All "functions" mentioned here are passed as function pointers between
-F<libcrypto> and the provider in B<OSSL_DISPATCH> arrays via
-B<OSSL_ALGORITHM> arrays that are returned by the provider's
+F<libcrypto> and the provider in L<OSSL_DISPATCH(3)> arrays via
+L<OSSL_ALGORITHM(3)> arrays that are returned by the provider's
provider_query_operation() function
(see L<provider-base(7)/Provider Functions>).
All these "functions" have a corresponding function type definition
named B<OSSL_FUNC_{name}_fn>, and a helper function to retrieve the
-function pointer from an B<OSSL_DISPATCH> element named
+function pointer from an L<OSSL_DISPATCH(3)> element named
B<OSSL_FUNC_{name}>.
For example, the "function" OSSL_FUNC_mac_newctx() has these:
@@ -63,7 +63,7 @@ For example, the "function" OSSL_FUNC_mac_newctx() has these:
static ossl_inline OSSL_FUNC_mac_newctx_fn
OSSL_FUNC_mac_newctx(const OSSL_DISPATCH *opf);
-B<OSSL_DISPATCH> arrays are indexed by numbers that are provided as
+L<OSSL_DISPATCH(3)> arrays are indexed by numbers that are provided as
macros in L<openssl-core_dispatch.h(7)>, as follows:
OSSL_FUNC_mac_newctx OSSL_FUNC_MAC_NEWCTX
@@ -145,7 +145,7 @@ in I<params>.
Passing NULL for I<params> should return true.
OSSL_FUNC_mac_gettable_params(), OSSL_FUNC_mac_gettable_ctx_params(),
-and OSSL_FUNC_mac_settable_ctx_params() all return constant B<OSSL_PARAM>
+and OSSL_FUNC_mac_settable_ctx_params() all return constant L<OSSL_PARAM(3)>
arrays as descriptors of the parameters that OSSL_FUNC_mac_get_params(),
OSSL_FUNC_mac_get_ctx_params(), and OSSL_FUNC_mac_set_ctx_params()
can handle, respectively. OSSL_FUNC_mac_gettable_ctx_params() and
@@ -209,7 +209,7 @@ OSSL_FUNC_mac_get_ctx_params() and OSSL_FUNC_mac_set_ctx_params() should return
success or 0 on error.
OSSL_FUNC_mac_gettable_params(), OSSL_FUNC_mac_gettable_ctx_params() and
-OSSL_FUNC_mac_settable_ctx_params() should return a constant B<OSSL_PARAM>
+OSSL_FUNC_mac_settable_ctx_params() should return a constant L<OSSL_PARAM(3)>
array, or NULL if none is offered.
=head1 SEE ALSO
diff --git a/doc/man7/provider-rand.pod b/doc/man7/provider-rand.pod
index 951f483b60..e115d845dc 100644
--- a/doc/man7/provider-rand.pod
+++ b/doc/man7/provider-rand.pod
@@ -168,7 +168,7 @@ in I<params>.
Passing NULL for I<params> should return true.
OSSL_FUNC_rand_gettable_params(), OSSL_FUNC_rand_gettable_ctx_params(),
-and OSSL_FUNC_rand_settable_ctx_params() all return constant B<OSSL_PARAM>
+and OSSL_FUNC_rand_settable_ctx_params() all return constant L<OSSL_PARAM(3)>
arrays as descriptors of the parameters that OSSL_FUNC_rand_get_params(),
OSSL_FUNC_rand_get_ctx_params(), and OSSL_FUNC_rand_set_ctx_params()
can handle, respectively. OSSL_FUNC_rand_gettable_ctx_params()
@@ -262,7 +262,7 @@ OSSL_FUNC_rand_newctx() should return the newly created
provider side rand context, or NULL on failure.
OSSL_FUNC_rand_gettable_params(), OSSL_FUNC_rand_gettable_ctx_params() and
-OSSL_FUNC_rand_settable_ctx_params() should return a constant B<OSSL_PARAM>
+OSSL_FUNC_rand_settable_ctx_params() should return a constant L<OSSL_PARAM(3)>
array, or NULL if none is offered.
OSSL_FUNC_rand_nonce() returns the size of the generated nonce, or 0 on error.
diff --git a/doc/man7/provider-signature.pod b/doc/man7/provider-signature.pod
index d77979cd8e..022b52ae14 100644
--- a/doc/man7/provider-signature.pod
+++ b/doc/man7/provider-signature.pod
@@ -93,14 +93,14 @@ and L<EVP_PKEY_verify_recover(3)> (as well
as other related functions).
All "functions" mentioned here are passed as function pointers between
-F<libcrypto> and the provider in B<OSSL_DISPATCH> arrays via
-B<OSSL_ALGORITHM> arrays that are returned by the provider's
+F<libcrypto> and the provider in L<OSSL_DISPATCH(3)> arrays via
+L<OSSL_ALGORITHM(3)> arrays that are returned by the provider's
provider_query_operation() function
(see L<provider-base(7)/Provider Functions>).
All these "functions" have a corresponding function type definition
named B<OSSL_FUNC_{name}_fn>, and a helper function to retrieve the
-function pointer from an B<OSSL_DISPATCH> element named
+function pointer from an L<OSSL_DISPATCH(3)> element named
B<OSSL_FUNC_{name}>.
For example, the "function" OSSL_FUNC_signature_newctx() has these:
@@ -108,7 +108,7 @@ For example, the "function" OSSL_FUNC_signature_newctx() has these:
static ossl_inline OSSL_FUNC_signature_newctx_fn
OSSL_FUNC_signature_newctx(const OSSL_DISPATCH *opf);
-B<OSSL_DISPATCH> arrays are indexed by numbers that are provided as
+L<OSSL_DISPATCH(3)> arrays are indexed by numbers that are provided as
macros in L<openssl-core_dispatch.h(7)>, as follows:
OSSL_FUNC_signature_newctx OSSL_FUNC_SIGNATURE_NEWCTX
@@ -388,10 +388,9 @@ supply known values that either pass or fail.
=back
OSSL_FUNC_signature_gettable_ctx_params() and OSSL_FUNC_signature_settable_ctx_params() get a
-constant B<OSSL_PARAM> array that describes the gettable and settable parameters,
+constant L<OSSL_PARAM(3)> array that describes the gettable and settable parameters,
i.e. parameters that can be used with OSSL_FUNC_signature_get_ctx_params() and
OSSL_FUNC_signature_set_ctx_params() respectively.
-See L<OSSL_PARAM(3)> for the use of B<OSSL_PARAM> as parameter descriptor.
=head2 MD parameters
@@ -413,11 +412,10 @@ as those for built-in digest algorithms. See
L<provider-digest(7)/Digest Parameters> for further information.
OSSL_FUNC_signature_gettable_md_ctx_params() and OSSL_FUNC_signature_settable_md_ctx_params()
-get a constant B<OSSL_PARAM> array that describes the gettable and settable
+get a constant L<OSSL_PARAM(3)> array that describes the gettable and settable
digest parameters, i.e. parameters that can be used with
OSSL_FUNC_signature_get_md_ctx_params() and OSSL_FUNC_signature_set_md_ctx_params()
-respectively. See L<OSSL_PARAM(3)> for the use of B<OSSL_PARAM> as parameter
-descriptor.
+respectively.
=head1 RETURN VALUES
@@ -426,7 +424,7 @@ provider side signature, or NULL on failure.
OSSL_FUNC_signature_gettable_ctx_params(), OSSL_FUNC_signature_settable_ctx_params(),
OSSL_FUNC_signature_gettable_md_ctx_params() and OSSL_FUNC_signature_settable_md_ctx_params(),
-return the gettable or settable parameters in a constant B<OSSL_PARAM> array.
+return the gettable or settable parameters in a constant L<OSSL_PARAM(3)> array.
All other functions should return 1 for success or 0 on error.
diff --git a/doc/man7/provider-storemgmt.pod b/doc/man7/provider-storemgmt.pod
index 611f24930c..615ff7ef8e 100644
--- a/doc/man7/provider-storemgmt.pod
+++ b/doc/man7/provider-storemgmt.pod
@@ -44,14 +44,14 @@ OSSL_FUNC_store_export_object() (which exports the object in parameterized
form).
All "functions" mentioned here are passed as function pointers between
-F<libcrypto> and the provider in B<OSSL_DISPATCH> arrays via
-B<OSSL_ALGORITHM> arrays that are returned by the provider's
+F<libcrypto> and the provider in L<OSSL_DISPATCH(3)> arrays via
+L<OSSL_ALGORITHM(3)> arrays that are returned by the provider's
provider_query_operation() function
(see L<provider-base(7)/Provider Functions>).
All these "functions" have a corresponding function type definition named
B<OSSL_FUNC_{name}_fn>, and a helper function to retrieve the function pointer
-from a B<OSSL_DISPATCH> element named B<OSSL_get_{name}>.
+from a L<OSSL_DISPATCH(3)> element named B<OSSL_get_{name}>.
For example, the "function" OSSL_FUNC_store_attach() has these:
typedef void *(OSSL_FUNC_store_attach_fn)(void *provctx,
@@ -59,7 +59,7 @@ For example, the "function" OSSL_FUNC_store_attach() has these:
static ossl_inline OSSL_FUNC_store_attach_fn
OSSL_FUNC_store_attach(const OSSL_DISPATCH *opf);
-B<OSSL_DISPATCH> arrays are indexed by numbers that are provided as macros
+L<OSSL_DISPATCH(3)> arrays are indexed by numbers that are provided as macros
in L<openssl-core_dispatch.h(7)>, as follows:
OSSL_FUNC_store_open OSSL_FUNC_STORE_OPEN
@@ -82,7 +82,7 @@ B<BIO> I<bio> attached. This is an alternative to using a URI to find storage,
supporting L<OSSL_STORE_attach(3)>.
OSSL_FUNC_store_settable_ctx_params() should return a constant array of
-descriptor B<OSSL_PARAM>, for parameters that OSSL_FUNC_store_set_ctx_params()
+descriptor L<OSSL_PARAM(3)>, for parameters that OSSL_FUNC_store_set_ctx_params()
can handle.
OSSL_FUNC_store_set_ctx_params() should set additional parameters, such as what
@@ -111,7 +111,7 @@ exporting the object to that foreign provider if the foreign provider
supports the type of the object and provides an import function.
OSSL_FUNC_store_export_object() should export the object of size I<objref_sz>
-referenced by I<objref> as an B<OSSL_PARAM> array and pass that to the
+referenced by I<objref> as an L<OSSL_PARAM(3)> array and pass that to the
I<export_cb> as well as the given I<export_cbarg>.
=head2 Load Parameters
diff --git a/doc/man7/provider.pod b/doc/man7/provider.pod
index fb092931c9..a061fc4709 100644
--- a/doc/man7/provider.pod
+++ b/doc/man7/provider.pod
@@ -34,8 +34,8 @@ See L<crypto(7)> for further details.
=head2 Provider
A I<provider> offers an initialization function, as a set of base
-functions in the form of an B<OSSL_DISPATCH> array, and by extension,
-a set of B<OSSL_ALGORITHM>s (see L<openssl-core.h(7)>).
+functions in the form of an L<OSSL_DISPATCH(3)> array, and by extension,
+a set of L<OSSL_ALGORITHM(3)>s (see L<openssl-core.h(7)>).
It may be a dynamically loadable module, or may be built-in, in
OpenSSL libraries or in the application.
If it's a dynamically loadable module, the initialization function
@@ -92,7 +92,7 @@ nonzero, signifies that the OpenSSL libraries will not store a
reference to the returned data in their internal store of
implementations.
-The returned B<OSSL_ALGORITHM> is the foundation of any OpenSSL
+The returned L<OSSL_ALGORITHM(3)> is the foundation of any OpenSSL
library API that uses providers for their implementation, most
commonly in the I<fetching> type of functions
(see L<crypto(7)/ALGORITHM FETCHING>).