19 files changed, 125 insertions, 125 deletions
diff --git a/doc/man7/EVP_KDF-HKDF.pod b/doc/man7/EVP_KDF-HKDF.pod
index 4da887c007..6bb65e21e7 100644
--- a/doc/man7/EVP_KDF-HKDF.pod
+++ b/doc/man7/EVP_KDF-HKDF.pod
@@ -63,7 +63,7 @@ derived otherwise an error will occur.
 
 In this mode calling L<EVP_KDF-derive(3)> will just perform the extract
 operation. The value returned will be the intermediate fixed-length pseudorandom
-key K.  The C<keylen> parameter must match the size of K, which can be looked
+key K.  The I<keylen> parameter must match the size of K, which can be looked
 up by calling EVP_KDF_size() after setting the mode and digest.
 
 The digest, key and salt values must be set before a key is derived otherwise
@@ -89,12 +89,12 @@ A context for HKDF can be obtained by calling:
  EVP_KDF *kdf = EVP_KDF_fetch(NULL, "HKDF", NULL);
  EVP_KDF_CTX *kctx = EVP_KDF_CTX_new(kdf);
 
-The output length of an HKDF expand operation is specified via the C<keylen>
+The output length of an HKDF expand operation is specified via the I<keylen>
 parameter to the L<EVP_KDF-derive(3)> function.  When using
-EVP_KDF_HKDF_MODE_EXTRACT_ONLY the C<keylen> parameter must equal the size of
+EVP_KDF_HKDF_MODE_EXTRACT_ONLY the I<keylen> parameter must equal the size of
 the intermediate fixed-length pseudorandom key otherwise an error will occur.
 For that mode, the fixed output size can be looked up by calling EVP_KDF_size()
-after setting the mode and digest on the C<EVP_KDF_CTX>.
+after setting the mode and digest on the B<EVP_KDF_CTX>.
 
 =head1 EXAMPLES
 
diff --git a/doc/man7/EVP_KDF-PBKDF2.pod b/doc/man7/EVP_KDF-PBKDF2.pod
index e18816b544..43d074bdcc 100644
--- a/doc/man7/EVP_KDF-PBKDF2.pod
+++ b/doc/man7/EVP_KDF-PBKDF2.pod
@@ -65,10 +65,10 @@ The value string is expected to be a decimal number 0 or 1.
 =head1 NOTES
 
 A typical application of this algorithm is to derive keying material for an
-encryption algorithm from a password in the B<pass>, a salt in B<salt>,
+encryption algorithm from a password in the "pass", a salt in "salt",
 and an iteration count.
 
-Increasing the B<iter> parameter slows down the algorithm which makes it
+Increasing the "iter" parameter slows down the algorithm which makes it
 harder for an attacker to perform a brute force attack using a large number
 of candidate passwords.
 
diff --git a/doc/man7/EVP_KDF-SCRYPT.pod b/doc/man7/EVP_KDF-SCRYPT.pod
index 940629cb4b..888667e5c3 100644
--- a/doc/man7/EVP_KDF-SCRYPT.pod
+++ b/doc/man7/EVP_KDF-SCRYPT.pod
@@ -69,7 +69,7 @@ A context for scrypt can be obtained by calling:
  EVP_KDF_CTX *kctx = EVP_KDF_CTX_new(kdf);
 
 The output length of an scrypt key derivation is specified via the
-B<keylen> parameter to the L<EVP_KDF-derive(3)> function.
+"keylen" parameter to the L<EVP_KDF-derive(3)> function.
 
 =head1 EXAMPLES
 
diff --git a/doc/man7/EVP_KDF-SS.pod b/doc/man7/EVP_KDF-SS.pod
index fcf423bb45..7ab3a3da63 100644
--- a/doc/man7/EVP_KDF-SS.pod
+++ b/doc/man7/EVP_KDF-SS.pod
@@ -68,7 +68,7 @@ A context for SSKDF can be obtained by calling:
  EVP_KDF *kdf = EVP_KDF_fetch(NULL, "SSKDF", NULL);
  EVP_KDF_CTX *kctx = EVP_KDF_CTX_new(kdf);
 
-The output length of an SSKDF is specified via the C<keylen>
+The output length of an SSKDF is specified via the I<keylen>
 parameter to the L<EVP_KDF-derive(3)> function.
 
 =head1 EXAMPLES
diff --git a/doc/man7/EVP_KDF-SSHKDF.pod b/doc/man7/EVP_KDF-SSHKDF.pod
index bcf3ff5f69..81d6120f0a 100644
--- a/doc/man7/EVP_KDF-SSHKDF.pod
+++ b/doc/man7/EVP_KDF-SSHKDF.pod
@@ -89,7 +89,7 @@ A context for SSHKDF can be obtained by calling:
  EVP_KDF *kdf = EVP_KDF_fetch(NULL, "SSHKDF", NULL);
  EVP_KDF_CTX *kctx = EVP_KDF_CTX_new(kdf);
 
-The output length of the SSHKDF derivation is specified via the C<keylen>
+The output length of the SSHKDF derivation is specified via the I<keylen>
 parameter to the L<EVP_KDF-derive(3)> function.
 Since the SSHKDF output length is variable, calling L<EVP_KDF-size()>
 to obtain the requisite length is not meaningful. The caller must
diff --git a/doc/man7/EVP_KDF-TLS1_PRF.pod b/doc/man7/EVP_KDF-TLS1_PRF.pod
index 0089e07599..d6c736555f 100644
--- a/doc/man7/EVP_KDF-TLS1_PRF.pod
+++ b/doc/man7/EVP_KDF-TLS1_PRF.pod
@@ -28,7 +28,7 @@ The supported parameters are:
 
 These parameters work as described in L<EVP_KDF(3)/PARAMETERS>.
 
-The C<OSSL_KDF_PARAM_DIGEST> parameter is used to set the message digest
+The B<OSSL_KDF_PARAM_DIGEST> parameter is used to set the message digest
 associated with the TLS PRF.
 EVP_md5_sha1() is treated as a special case which uses the
 PRF algorithm using both B<MD5> and B<SHA1> as used in TLS 1.0 and 1.1.
@@ -56,7 +56,7 @@ A context for the TLS PRF can be obtained by calling:
 The digest, secret value and seed must be set before a key is derived otherwise
 an error will occur.
 
-The output length of the PRF is specified by the C<keylen> parameter to the
+The output length of the PRF is specified by the I<keylen> parameter to the
 EVP_KDF_derive() function.
 
 =head1 EXAMPLES
diff --git a/doc/man7/EVP_KDF-X942.pod b/doc/man7/EVP_KDF-X942.pod
index 1a4ab8131a..a45d283c15 100644
--- a/doc/man7/EVP_KDF-X942.pod
+++ b/doc/man7/EVP_KDF-X942.pod
@@ -51,7 +51,7 @@ A context for X942KDF can be obtained by calling:
  EVP_KDF *kdf = EVP_KDF_fetch(NULL, "X942KDF", NULL);
  EVP_KDF_CTX *kctx = EVP_KDF_CTX_new(kdf);
 
-The output length of an X942KDF is specified via the C<keylen>
+The output length of an X942KDF is specified via the I<keylen>
 parameter to the L<EVP_KDF-derive(3)> function.
 
 =head1 EXAMPLES
diff --git a/doc/man7/EVP_KDF-X963.pod b/doc/man7/EVP_KDF-X963.pod
index 62a5378938..427219ee1d 100644
--- a/doc/man7/EVP_KDF-X963.pod
+++ b/doc/man7/EVP_KDF-X963.pod
@@ -48,7 +48,7 @@ A context for X963KDF can be obtained by calling:
  EVP_KDF *kdf = EVP_KDF_fetch(NULL, "X963KDF", NULL);
  EVP_KDF_CTX *kctx = EVP_KDF_CTX_new(kdf);
 
-The output length of an X963KDF is specified via the C<keylen>
+The output length of an X963KDF is specified via the I<keylen>
 parameter to the L<EVP_KDF-derive(3)> function.
 
 =head1 EXAMPLES
diff --git a/doc/man7/Ed25519.pod b/doc/man7/Ed25519.pod
index 8269f2feaa..74bf7c31ee 100644
--- a/doc/man7/Ed25519.pod
+++ b/doc/man7/Ed25519.pod
@@ -25,7 +25,7 @@ The message to sign or verify must be passed using the one-shot
 EVP_DigestSign() and EVP_DigestVerify() functions.
 
 When calling EVP_DigestSignInit() or EVP_DigestVerifyInit(), the
-digest B<type> parameter B<MUST> be set to B<NULL>.
+digest I<type> parameter B<MUST> be set to NULL.
 
 Applications wishing to sign certificates (or other structures such as
 CRLs or certificate requests) using Ed25519 or Ed448 can either use X509_sign()
diff --git a/doc/man7/RAND_DRBG.pod b/doc/man7/RAND_DRBG.pod
index 467a544db3..8b91505000 100644
--- a/doc/man7/RAND_DRBG.pod
+++ b/doc/man7/RAND_DRBG.pod
@@ -239,7 +239,7 @@ pulls the necessary entropy from its source automatically.
 However, both calls are permitted, and do reseed the RNG.
 
 RAND_add() can be used to add both kinds of random input, depending on the
-value of the B<randomness> argument:
+value of the I<randomness> argument:
 
 =over 4
 
@@ -267,7 +267,7 @@ from the trusted entropy sources.
 NOTE: Manual reseeding is *not allowed* in FIPS mode, because
 [NIST SP-800-90Ar1] mandates that entropy *shall not* be provided by
 the consuming application for instantiation (Section 9.1) or
-reseeding (Section 9.2). For that reason, the B<randomness>
+reseeding (Section 9.2). For that reason, the I<randomness>
 argument is ignored and the random bytes provided by the L<RAND_add(3)> and
 L<RAND_seed(3)> calls are treated as additional data.
 
diff --git a/doc/man7/bio.pod b/doc/man7/bio.pod
index bc1fb1e45e..1d3276b730 100644
--- a/doc/man7/bio.pod
+++ b/doc/man7/bio.pod
@@ -47,7 +47,7 @@ in a memory leak.
 Calling BIO_free_all() on a single BIO has the same effect as calling
 BIO_free() on it other than the discarded return value.
 
-Normally the B<type> argument is supplied by a function which returns a
+Normally the I<type> argument is supplied by a function which returns a
 pointer to a BIO_METHOD. There is a naming convention for such functions:
 a source/sink BIO is normally called BIO_s_*() and a filter BIO
 BIO_f_*();
diff --git a/doc/man7/crypto.pod b/doc/man7/crypto.pod
index 0e8008b332..aa6b6405ba 100644
--- a/doc/man7/crypto.pod
+++ b/doc/man7/crypto.pod
@@ -10,13 +10,13 @@ See the individual manual pages for details.
 
 =head1 DESCRIPTION
 
-The OpenSSL B<crypto> library implements a wide range of cryptographic
-algorithms used in various Internet standards. The services provided
-by this library are used by the OpenSSL implementations of SSL, TLS
+The OpenSSL crypto library (C<libcrypto>) implements a wide range of
+cryptographic algorithms used in various Internet standards. The services
+provided by this library are used by the OpenSSL implementations of SSL, TLS
 and S/MIME, and they have also been used to implement SSH, OpenPGP, and
 other cryptographic standards.
 
-B<libcrypto> consists of a number of sub-libraries that implement the
+C<libcrypto> consists of a number of sub-libraries that implement the
 individual algorithms.
 
 The functionality includes symmetric encryption, public key
@@ -34,11 +34,11 @@ B<0> and B<1>. For example the functions:
 
 The B<0> version uses the supplied structure pointer directly
 in the parent and it will be freed up when the parent is freed.
-In the above example B<crl> would be freed but B<rev> would not.
+In the above example I<crl> would be freed but I<rev> would not.
 
 The B<1> function uses a copy of the supplied structure pointer
 (or in some cases increases its link count) in the parent and
-so both (B<x> and B<obj> above) should be freed up.
+so both (I<x> and I<obj> above) should be freed up.
 
 =head1 RETURN VALUES
 
diff --git a/doc/man7/openssl-core.h.pod b/doc/man7/openssl-core.h.pod
index 737293d701..a7f209b104 100644
--- a/doc/man7/openssl-core.h.pod
+++ b/doc/man7/openssl-core.h.pod
@@ -20,14 +20,14 @@ The types are:
 
 =over 4
 
-=item C<OSSL_DISPATCH>
+=item B<OSSL_DISPATCH>
 
 This type is a tuple of function identity and function pointer.
 Arrays of this type are passed between the OpenSSL libraries and the
 providers to describe what functionality one side provides to the
 other.
 Arrays of this type must be terminated with a tuple having function
-identity zero and function pointer C<NULL>.
+identity zero and function pointer NULL.
 
 The available function identities and corresponding function
 signatures are defined by L<openssl-core_numbers.h(7)>.
@@ -38,41 +38,41 @@ This ensures that providers built with one OpenSSL version in mind
 will work together with any other OpenSSL version that supports this
 mechanism.
 
-=item C<OSSL_ITEM>
+=item B<OSSL_ITEM>
 
 This type is a tuple of integer and pointer.
 It's a generic type used as a generic descriptor, its exact meaning
 being defined by how it's used.
 Arrays of this type are passed between the OpenSSL libraries and the
 providers, and must be terminated with a tuple where the integer is
-zero and the pointer C<NULL>.
+zero and the pointer NULL.
 
-=item C<OSSL_ALGORITHM>
+=item B<OSSL_ALGORITHM>
 
 This type is a tuple of an algorithm name (string), a property
-definition (string) and a dispatch table (array of C<OSSL_DISPATCH>).
+definition (string) and a dispatch table (array of B<OSSL_DISPATCH>).
 Arrays of this type are passed on demand from the providers to the
 OpenSSL libraries to describe what algorithms the providers provide
 implementations of, and with what properties.
 Arrays of this type must be terminated with a tuple having function
-identity zero and function pointer C<NULL>.
+identity zero and function pointer NULL.
 
 The algorithm names and property definitions are defined by the
 providers.
 
-=item C<OSSL_PARAM>
+=item B<OSSL_PARAM>
 
 This type is a structure that allows passing arbitrary object data
 between two parties that have no or very little shared knowledge about
 their respective internal structures for that object. 
 It's normally passed in arrays, where the array is terminated with an
-element where all fields are zero (for non-pointers) or C<NULL> (for
+element where all fields are zero (for non-pointers) or NULL (for
 pointers).
 
 These arrays can be used to set parameters for some object, to request
 parameters, and to describe parameters.
 
-C<OSSL_PARAM> is further described in L<OSSL_PARAM(3)>
+B<OSSL_PARAM> is further described in L<OSSL_PARAM(3)>
 
 =back
 
diff --git a/doc/man7/ossl_store-file.pod b/doc/man7/ossl_store-file.pod
index c517503eb7..d6ea27bedf 100644
--- a/doc/man7/ossl_store-file.pod
+++ b/doc/man7/ossl_store-file.pod
@@ -46,7 +46,7 @@ only).
 =head1 NOTES
 
 When needed, the 'file' scheme loader will require a pass phrase by
-using the C<UI_METHOD> that was passed via OSSL_STORE_open().
+using the B<UI_METHOD> that was passed via OSSL_STORE_open().
 This pass phrase is expected to be UTF-8 encoded, anything else will
 give an undefined result.
 The files made accessible through this loader are expected to be
diff --git a/doc/man7/provider-cipher.pod b/doc/man7/provider-cipher.pod
index 89cf07be0c..c8377d6835 100644
--- a/doc/man7/provider-cipher.pod
+++ b/doc/man7/provider-cipher.pod
@@ -111,65 +111,65 @@ OP_cipher_newctx() should create and return a pointer to a provider side
 structure for holding context information during a cipher operation.
 A pointer to this context will be passed back in a number of the other cipher
 operation function calls.
-The parameter B<provctx> is the provider context generated during provider
+The parameter I<provctx> is the provider context generated during provider
 initialisation (see L<provider(3)>).
 
 OP_cipher_freectx() is passed a pointer to the provider side cipher context in
-the B<cctx> parameter.
+the I<cctx> parameter.
 This function should free any resources associated with that context.
 
 OP_cipher_dupctx() should duplicate the provider side cipher context in the
-B<cctx> parameter and return the duplicate copy.
+I<cctx> parameter and return the duplicate copy.
 
 =head2 Encryption/Decryption Functions
 
 OP_cipher_encrypt_init() initialises a cipher operation for encryption given a
-newly created provider side cipher context in the B<cctx> parameter.
-The key to be used is given in B<key> which is B<keylen> bytes long.
-The IV to be used is given in B<iv> which is B<ivlen> bytes long.
+newly created provider side cipher context in the I<cctx> parameter.
+The key to be used is given in I<key> which is I<keylen> bytes long.
+The IV to be used is given in I<iv> which is I<ivlen> bytes long.
 
 OP_cipher_decrypt_init() is the same as OP_cipher_encrypt_init() except that it
 initialises the context for a decryption operation.
 
 OP_cipher_update() is called to supply data to be encrypted/decrypted as part of
 a previously initialised cipher operation.
-The B<cctx> parameter contains a pointer to a previously initialised provider
+The I<cctx> parameter contains a pointer to a previously initialised provider
 side context.
-OP_cipher_update() should encrypt/decrypt B<inl> bytes of data at the location
-pointed to by B<in>.
-The encrypted data should be stored in B<out> and the amount of data written to
-B<*outl> which should not exceed B<outsize> bytes.
+OP_cipher_update() should encrypt/decrypt I<inl> bytes of data at the location
+pointed to by I<in>.
+The encrypted data should be stored in I<out> and the amount of data written to
+I<*outl> which should not exceed I<outsize> bytes.
 OP_cipher_update() may be called multiple times for a single cipher operation.
 It is the responsibility of the cipher implementation to handle input lengths
 that are not multiples of the block length.
 In such cases a cipher implementation will typically cache partial blocks of
 input data until a complete block is obtained.
-B<out> may be the same location as B<in> but it should not partially overlap.
-The same expectations apply to B<outsize> as documented for
+I<out> may be the same location as I<in> but it should not partially overlap.
+The same expectations apply to I<outsize> as documented for
 L<EVP_EncryptUpdate(3)> and L<EVP_DecryptUpdate(3)>.
 
 OP_cipher_final() completes an encryption or decryption started through previous
 OP_cipher_encrypt_init() or OP_cipher_decrypt_init(), and OP_cipher_update()
 calls.
-The B<cctx> parameter contains a pointer to the provider side context.
-Any final encryption/decryption output should be written to B<out> and the
-amount of data written to B<*outl> which should not exceed B<outsize> bytes.
-The same expectations apply to B<outsize> as documented for
+The I<cctx> parameter contains a pointer to the provider side context.
+Any final encryption/decryption output should be written to I<out> and the
+amount of data written to I<*outl> which should not exceed I<outsize> bytes.
+The same expectations apply to I<outsize> as documented for
 L<EVP_EncryptFinal(3)> and L<EVP_DecryptFinal(3)>.
 
 OP_cipher_cipher() performs encryption/decryption using the provider side cipher
-context in the B<cctx> parameter that should have been previously initialised via
+context in the I<cctx> parameter that should have been previously initialised via
 a call to OP_cipher_encrypt_init() or OP_cipher_decrypt_init.
 This should call the raw underlying cipher function without any padding.
 This will be invoked in the provider as a result of the application calling
 L<EVP_Cipher(3)>.
 The application is responsible for ensuring that the input is a multiple of the
 block length.
-The data to be encrypted/decrypted will be in B<in>, and it will be B<inl> bytes
+The data to be encrypted/decrypted will be in I<in>, and it will be I<inl> bytes
 in length.
-The output from the encryption/decryption should be stored in B<out> and the
-amount of data stored should be put in B<*outl> which should be no more than
-B<outsize> bytes.
+The output from the encryption/decryption should be stored in I<out> and the
+amount of data stored should be put in I<*outl> which should be no more than
+I<outsize> bytes.
 
 =head2 Cipher Parameters
 
@@ -177,14 +177,14 @@ See L<OSSL_PARAM(3)> for further details on the parameters structure used by
 these functions.
 
 OP_cipher_get_params() gets details of the algorithm implementation
-and stores them in B<params>.
+and stores them in I<params>.
 
 OP_cipher_set_ctx_params() sets cipher operation parameters for the
-provider side cipher context B<cctx> to B<params>.
+provider side cipher context I<cctx> to I<params>.
 Any parameter settings are additional to any that were previously set.
 
 OP_cipher_get_ctx_params() gets cipher operation details details from
-the given provider side cipher context B<cctx> and stores them in B<params>.
+the given provider side cipher context I<cctx> and stores them in I<params>.
 
 OP_cipher_gettable_params(), OP_cipher_gettable_ctx_params(), and
 OP_cipher_settable_ctx_params() all return constant B<OSSL_PARAM> arrays
@@ -306,7 +306,7 @@ beginning of the output buffer, do "in place" encryption of the payload and
 write that to the output buffer, and finally add the tag onto the end of the
 output buffer.
 
-Whether encrypting or decrypting the value written to B<*outl> in the
+Whether encrypting or decrypting the value written to I<*outl> in the
 OP_cipher_cipher call should be the length of the payload excluding the explicit
 IV length and the tag length.
 
diff --git a/doc/man7/provider-digest.pod b/doc/man7/provider-digest.pod
index ff388da100..089c0e2082 100644
--- a/doc/man7/provider-digest.pod
+++ b/doc/man7/provider-digest.pod
@@ -99,43 +99,43 @@ OP_digest_newctx() should create and return a pointer to a provider side
 structure for holding context information during a digest operation.
 A pointer to this context will be passed back in a number of the other digest
 operation function calls.
-The parameter B<provctx> is the provider context generated during provider
+The parameter I<provctx> is the provider context generated during provider
 initialisation (see L<provider(3)>).
 
 OP_digest_freectx() is passed a pointer to the provider side digest context in
-the B<dctx> parameter.
+the I<dctx> parameter.
 This function should free any resources associated with that context.
 
 OP_digest_dupctx() should duplicate the provider side digest context in the
-B<dctx> parameter and return the duplicate copy.
+I<dctx> parameter and return the duplicate copy.
 
 =head2 Digest Generation Functions
 
 OP_digest_init() initialises a digest operation given a newly created
-provider side digest context in the B<dctx> parameter.
+provider side digest context in the I<dctx> parameter.
 
 OP_digest_update() is called to supply data to be digested as part of a
 previously initialised digest operation.
-The B<dctx> parameter contains a pointer to a previously initialised provider
+The I<dctx> parameter contains a pointer to a previously initialised provider
 side context.
-OP_digest_update() should digest B<inl> bytes of data at the location pointed to
-by B<in>.
+OP_digest_update() should digest I<inl> bytes of data at the location pointed to
+by I<in>.
 OP_digest_update() may be called multiple times for a single digest operation.
 
 OP_digest_final() generates a digest started through previous OP_digest_init()
 and OP_digest_update() calls.
-The B<dctx> parameter contains a pointer to the provider side context.
-The digest should be written to B<*out> and the length of the digest to
-B<*outl>.
-The digest should not exceed B<outsz> bytes.
+The I<dctx> parameter contains a pointer to the provider side context.
+The digest should be written to I<*out> and the length of the digest to
+I<*outl>.
+The digest should not exceed I<outsz> bytes.
 
 OP_digest_digest() is a "oneshot" digest function.
 No provider side digest context is used.
 Instead the provider context that was created during provider initialisation is
-passed in the B<provctx> parameter (see L<provider(3)>).
-B<inl> bytes at B<in> should be digested and the result should be stored at
-B<out>. The length of the digest should be stored in B<*outl> which should not
-exceed B<outsz> bytes.
+passed in the I<provctx> parameter (see L<provider(3)>).
+I<inl> bytes at I<in> should be digested and the result should be stored at
+I<out>. The length of the digest should be stored in I<*outl> which should not
+exceed I<outsz> bytes.
 
 =head2 Digest Parameters
 
@@ -143,14 +143,14 @@ See L<OSSL_PARAM(3)> for further details on the parameters structure used by
 these functions.
 
 OP_digest_get_params() gets details of the algorithm implementation
-and stores them in B<params>.
+and stores them in I<params>.
 
 OP_digest_set_ctx_params() sets digest operation parameters for the
-provider side digest context B<dctx> to B<params>.
+provider side digest context I<dctx> to I<params>.
 Any parameter settings are additional to any that were previously set.
 
 OP_digest_get_ctx_params() gets digest operation details details from
-the given provider side digest context B<dctx> and stores them in B<params>.
+the given provider side digest context I<dctx> and stores them in I<params>.
 
 OP_digest_gettable_params(), OP_digest_gettable_ctx_params(), and
 OP_digest_settable_ctx_params() all return constant B<OSSL_PARAM> arrays
@@ -218,13 +218,13 @@ B<unsigned long int>.
 =head2 Digest Context Parameters
 
 OP_digest_set_ctx_params() sets digest parameters associated with the
-given provider side digest context B<dctx> to B<params>.
+given provider side digest context I<dctx> to I<params>.
 Any parameter settings are additional to any that were previously set.
 See L<OSSL_PARAM(3)> for further details on the parameters structure.
 
 OP_digest_get_ctx_params() gets details of currently set parameters
-values associated with the give provider side digest context B<dctx>
-and stores them in B<params>.
+values associated with the give provider side digest context I<dctx>
+and stores them in I<params>.
 See L<OSSL_PARAM(3)> for further details on the parameters structure.
 
 Parameters currently recognised by built-in digests are as follows. Not all
diff --git a/doc/man7/provider-keyexch.pod b/doc/man7/provider-keyexch.pod
index 358e16a0df..c4cb021185 100644
--- a/doc/man7/provider-keyexch.pod
+++ b/doc/man7/provider-keyexch.pod
@@ -87,27 +87,27 @@ OP_keyexch_newctx() should create and return a pointer to a provider side
 structure for holding context information during a key exchange operation.
 A pointer to this context will be passed back in a number of the other key
 exchange operation function calls.
-The paramater B<provctx> is the provider context generated during provider
+The paramater I<provctx> is the provider context generated during provider
 initialisation (see L<provider(3)>).
 
 OP_keyexch_freectx() is passed a pointer to the provider side key exchange
-context in the B<ctx> parameter.
+context in the I<ctx> parameter.
 This function should free any resources associated with that context.
 
 OP_keyexch_dupctx() should duplicate the provider side key exchange context in
-the B<ctx> parameter and return the duplicate copy.
+the I<ctx> parameter and return the duplicate copy.
 
 =head2 Shared Secret Derivation Functions
 
 OP_keyexch_init() initialises a key exchange operation given a provider side key
-exchange context in the B<ctx> paramter, and a pointer to a provider key object
-in the B<provkey> parameter. The key object should have been previously
+exchange context in the I<ctx> paramter, and a pointer to a provider key object
+in the I<provkey> parameter. The key object should have been previously
 generated, loaded or imported into the provider using the key management
 (OSSL_OP_KEYMGMT) operation (see provider-keymgmt(7)>.
 
 OP_keyexch_set_peer() is called to supply the peer's public key (in the
-B<provkey> parameter) to be used when deriving the shared secret.
-It is also passed a previously initialised key exchange context in the B<ctx>
+I<provkey> parameter) to be used when deriving the shared secret.
+It is also passed a previously initialised key exchange context in the I<ctx>
 parameter.
 The key object should have been previously generated, loaded or imported into
 the provider using the key management (OSSL_OP_KEYMGMT) operation (see
@@ -115,13 +115,13 @@ provider-keymgmt(7)>.
 
 OP_keyexch_derive() performs the actual key exchange itself by deriving a shared
 secret.
-A previously initialised key exchange context is passed in the B<ctx>
+A previously initialised key exchange context is passed in the I<ctx>
 parameter.
-The derived secret should be written to the location B<secret> which should not
-exceed B<outlen> bytes.
-The length of the shared secret should be written to B<*secretlen>.
-If B<secret> is NULL then the maximum length of the shared secret should be
-written to B<*secretlen>.
+The derived secret should be written to the location I<secret> which should not
+exceed I<outlen> bytes.
+The length of the shared secret should be written to I<*secretlen>.
+If I<secret> is NULL then the maximum length of the shared secret should be
+written to I<*secretlen>.
 
 =head2 Key Exchange Parameters
 
@@ -129,7 +129,7 @@ See L<OSSL_PARAM(3)> for further details on the parameters structure used by
 the OP_keyexch_set_params() function.
 
 OP_keyexch_set_ctx_params() sets key exchange parameters associated with the
-given provider side key exchange context B<ctx> to B<params>.
+given provider side key exchange context I<ctx> to I<params>.
 Any parameter settings are additional to any that were previously set.
 
 Parameters currently recognised by built-in key exchange algorithms are as
diff --git a/doc/man7/provider-signature.pod b/doc/man7/provider-signature.pod
index 777b991cc6..73d573a9f2 100644
--- a/doc/man7/provider-signature.pod
+++ b/doc/man7/provider-signature.pod
@@ -111,70 +111,70 @@ OP_signature_newctx() should create and return a pointer to a provider side
 structure for holding context information during a signature operation.
 A pointer to this context will be passed back in a number of the other signature
 operation function calls.
-The parameter B<provctx> is the provider context generated during provider
+The parameter I<provctx> is the provider context generated during provider
 initialisation (see L<provider(3)>).
 
 OP_signature_freectx() is passed a pointer to the provider side signature
-context in the B<ctx> parameter.
+context in the I<ctx> parameter.
 This function should free any resources associated with that context.
 
 OP_signature_dupctx() should duplicate the provider side signature context in
-the B<ctx> parameter and return the duplicate copy.
+the I<ctx> parameter and return the duplicate copy.
 
 =head2 Signing Functions
 
 OP_signature_sign_init() initialises a context for signing given a provider side
-signature context in the B<ctx> parameter, and a pointer to a provider key object
-in the B<provkey> parameter.
+signature context in the I<ctx> parameter, and a pointer to a provider key object
+in the I<provkey> parameter.
 The key object should have been previously generated, loaded or imported into
 the provider using the key management (OSSL_OP_KEYMGMT) operation (see
 provider-keymgmt(7)>.
 
 OP_signature_sign() performs the actual signing itself.
-A previously initialised signature context is passed in the B<ctx>
+A previously initialised signature context is passed in the I<ctx>
 parameter.
-The data to be signed is pointed to be the B<tbs> parameter which is B<tbslen>
+The data to be signed is pointed to be the I<tbs> parameter which is I<tbslen>
 bytes long.
-Unless B<sig> is NULL, the signature should be written to the location pointed
-to by the B<sig> parameter and it should not exceed B<sigsize> bytes in length.
-The length of the signature should be written to B<*siglen>.
-If B<sig> is NULL then the maximum length of the signature should be written to
-B<*siglen>.
+Unless I<sig> is NULL, the signature should be written to the location pointed
+to by the I<sig> parameter and it should not exceed I<sigsize> bytes in length.
+The length of the signature should be written to I<*siglen>.
+If I<sig> is NULL then the maximum length of the signature should be written to
+I<*siglen>.
 
 =head2 Verify Functions
 
 OP_signature_verify_init() initialises a context for verifying a signature given
-a provider side signature context in the B<ctx> parameter, and a pointer to a
-provider key object in the B<provkey> parameter.
+a provider side signature context in the I<ctx> parameter, and a pointer to a
+provider key object in the I<provkey> parameter.
 The key object should have been previously generated, loaded or imported into
 the provider using the key management (OSSL_OP_KEYMGMT) operation (see
 provider-keymgmt(7)>.
 
 OP_signature_verify() performs the actual verification itself.
-A previously initialised signature context is passed in the B<ctx> parameter.
-The data that the signature covers is pointed to be the B<tbs> parameter which
-is B<tbslen> bytes long.
-The signature is pointed to by the B<sig> parameter which is B<siglen> bytes
+A previously initialised signature context is passed in the I<ctx> parameter.
+The data that the signature covers is pointed to be the I<tbs> parameter which
+is I<tbslen> bytes long.
+The signature is pointed to by the I<sig> parameter which is I<siglen> bytes
 long.
 
 =head2 Verify Recover Functions
 
 OP_signature_verify_recover_init() initialises a context for recovering the
-signed data given a provider side signature context in the B<ctx> parameter, and
-a pointer to a provider key object in the B<provkey> parameter.
+signed data given a provider side signature context in the I<ctx> parameter, and
+a pointer to a provider key object in the I<provkey> parameter.
 The key object should have been previously generated, loaded or imported into
 the provider using the key management (OSSL_OP_KEYMGMT) operation (see
 provider-keymgmt(7)>.
 
 OP_signature_verify_recover() performs the actual verify recover itself.
-A previously initialised signature context is passed in the B<ctx> parameter.
-The signature is pointed to by the B<sig> parameter which is B<siglen> bytes
+A previously initialised signature context is passed in the I<ctx> parameter.
+The signature is pointed to by the I<sig> parameter which is I<siglen> bytes
 long.
-Unless B<rout> is NULL, the recovered data should be written to the location
-pointed to by B<rout> which should not exceed B<routsize> bytes in length.
-The length of the recovered data should be written to B<*routlen>.
-If B<rout> is B<NULL> then the maximum size of the output buffer is written to
-the B<routlen> parameter.
+Unless I<rout> is NULL, the recovered data should be written to the location
+pointed to by I<rout> which should not exceed I<routsize> bytes in length.
+The length of the recovered data should be written to I<*routlen>.
+If I<rout> is NULL then the maximum size of the output buffer is written to
+the I<routlen> parameter.
 
 =head2 Signature Parameters
 
@@ -182,9 +182,9 @@ See L<OSSL_PARAM(3)> for further details on the parameters structure used by
 the OP_signature_get_ctx_params() and OP_signature_set_ctx_params() functions.
 
 OP_signature_get_ctx_params() gets signature parameters associated with the
-given provider side signature context B<ctx> and stored them in B<params>.
+given provider side signature context I<ctx> and stored them in I<params>.
 OP_signature_set_ctx_params() sets the signature parameters associated with the
-given provider side signature context B<ctx> to B<params>.
+given provider side signature context I<ctx> to I<params>.
 Any parameter settings are additional to any that were previously set.
 
 Parameters currently recognised by built-in signature algorithms are as
diff --git a/doc/man7/provider.pod b/doc/man7/provider.pod
index f92d111e95..c6e7d10fd8 100644
--- a/doc/man7/provider.pod
+++ b/doc/man7/provider.pod
@@ -150,7 +150,7 @@ L<provider-kdf(7)>
 =item Key Exchange
 
 In the OpenSSL libraries, the corresponding method object is
-B<EVP_KEYEXCh>.
+B<EVP_KEYEXCH>.
 The number for this operation is B<OSSL_OP_KEYEXCH>.
 The functions the provider can offer are described in
 L<provider-keyexch(7)>