31 files changed, 593 insertions, 231 deletions

diff --git a/doc/designs/fetching-composite-algorithms.md b/doc/designs/fetching-composite-algorithms.md
index 1e3fa9996876..c381aa7ccb0b 100644
--- a/doc/designs/fetching-composite-algorithms.md
+++ b/doc/designs/fetching-composite-algorithms.md
@@ -20,19 +20,19 @@ Public API - Add variants of `EVP_PKEY_CTX` initializers
 
 As far as this design is concerned, these API sets are affected:
 
-- SIGNATURE (DigestSign and DigestVerify)
+- SIGNATURE
 - ASYM_CIPHER
 - KEYEXCH
 
-The proposal is to add these functions:
+The proposal is to add these initializer functions:
 
 ``` C
-EVP_DigestSignInit_ex2(EVP_PKEY_CTX **pctx,
-                       EVP_SIGNATURE *sig, EVP_PKEY *pkey,
-                       OSSL_LIB_CTX *libctx, const OSSL_PARAM params[]);
-EVP_DigestVerifyInit_ex2(EVP_PKEY_CTX **pctx,
-                         EVP_SIGNATURE *sig, EVP_PKEY *pkey,
-                         OSSL_LIB_CTX *libctx, const OSSL_PARAM params[]);
+int EVP_PKEY_sign_init_ex2(EVP_PKEY_CTX *pctx,
+                           EVP_SIGNATURE *algo, const OSSL_PARAM params[]);
+int EVP_PKEY_verify_init_ex2(EVP_PKEY_CTX *pctx,
+                             EVP_SIGNATURE *algo, const OSSL_PARAM params[]);
+int EVP_PKEY_verify_recover_init_ex2(EVP_PKEY_CTX *pctx,
+                                     EVP_SIGNATURE *algo, const OSSL_PARAM params[]);
 
 int EVP_PKEY_encrypt_init_ex2(EVP_PKEY_CTX *ctx, EVP_ASYM_CIPHER *asymciph,
                               const OSSL_PARAM params[]);
@@ -43,68 +43,12 @@ int EVP_PKEY_derive_init_ex2(EVP_PKEY_CTX *ctx, EVP_KEYEXCH *exchange,
                              const OSSL_PARAM params[]);
 ```
 
-Because `EVP_SIGNATURE`, `EVP_ASYM_CIPHER` and `EVP_KEYEXCH` aren't limited
-to composite algorithms, these functions can be used just as well with
-explicit fetches of simple algorithms, say "RSA".  In that case, the caller
-will need to pass necessary auxiliary parameters through the `OSSL_PARAM` or
-a call to a corresponding `set_params` function.
+Detailed proposal for these APIs will be or are prepared in other design
+documents:
 
-Requirements on the providers
------------------------------
-
-Because it's not immediately obvious from a composite algorithm name what
-key type it requires / supports, at least in code, allowing the use of an
-explicitly fetched implementation of a composite algorithm requires that
-providers cooperate by declaring what key type is required / supported by
-each algorithm.
-
-For non-composite operation algorithms (like "RSA"), this is not necessary,
-see the fallback strategies below.
-
-There are two ways this could be implemented:
-
-1.  through an added provider function that would work like keymgmt's
-    `query_operation_name` function, but would return a key type name
-    instead:
-
-    ``` C
-    # define OSSL_FUNC_SIGNATURE_QUERY_KEY_TYPE         26
-    OSSL_CORE_MAKE_FUNC(const char *, signature_query_key_type, (void))
-
-    # define OSSL_FUNC ASYM_CIPHER_QUERY_KEY_TYPE       12
-    OSSL_CORE_MAKE_FUNC(const char *, asym_cipher_query_key_type, (void))
-
-    # define OSSL_FUNC_KEYEXCH_QUERY_KEY_TYPE           11
-    OSSL_CORE_MAKE_FUNC(const char *, keyexch_query_key_type, (void))
-    ```
-
-2.  through a gettable `OSSL_PARAM`, using the param identity "keytype"
-
-Fallback strategies
--------------------
-
-Because existing providers haven't been updated to declare composite
-algorithms, or to respond to the key type query, some fallback strategies
-will be needed to find out if the `EVP_PKEY` key type is possible to use
-with the fetched algorithm:
-
--   Check if the fetched operation name matches the key type (keymgmt name)
-    of the `EVP_PKEY` that's involved in the operation.  For example, this
-    is useful when someone fetched the `EVP_SIGNATURE` "RSA".
--   Check if the fetched algorithm name matches the name returned by the
-    keymgmt's `query_operation_name` function.  For example, this is useful
-    when someone fetched the `EVP_SIGNATURE` "ECDSA", for which the key type
-    to use is "EC".
--   libcrypto currently has knowledge of some composite algorithm names and
-    what they are composed of, accessible with `OBJ_find_sigid_algs` and
-    similar functionality.  This knowledge is regarded legacy, but can be
-    used to figure out the key type.
-
-If none of these strategies work out, the operation initialization should
-fail.
-
-These strategies have their limitations, but the built-in legacy knowledge
-we currently have in libcrypto should be enough to cover most bases.
+- [Functions for explicitly fetched signature algorithms]
+- [Functions for explicitly fetched asym-cipher algorithms] (not yet designed)
+- [Functions for explicitly fetched keyexch algorithms] (not yet designed)
 
 -----
 
@@ -185,3 +129,7 @@ This is hurtful in multiple ways:
     use the result.
 -   It fails discoverability, for example through the `openssl list`
     command.
+
+<!-- links -->
+[Functions for explicitly fetched signature algorithms]:
+    functions-for-explicitly-fetched-signature-algorithms.md
diff --git a/doc/designs/functions-for-explicitly-fetched-signature-algorithms.md b/doc/designs/functions-for-explicitly-fetched-signature-algorithms.md
new file mode 100644
index 000000000000..cb4df1a40c38
--- /dev/null
+++ b/doc/designs/functions-for-explicitly-fetched-signature-algorithms.md
@@ -0,0 +1,205 @@
+Functions for explicitly fetched PKEY algorithms
+================================================
+
+Quick background
+----------------
+
+There are several proposed designs that end up revolving around the same
+basic need, explicitly fetched signature algorithms.  The following method
+type is affected by this document:
+
+- `EVP_SIGNATURE`
+
+Public API - Add variants of `EVP_PKEY_CTX` functionality
+---------------------------------------------------------
+
+Through OTC discussions, it's been determined that the most suitable APIs to
+touch are the of `EVP_PKEY_` functions.
+Specifically, `EVP_PKEY_sign()`, `EVP_PKEY_verify()`, `EVP_PKEY_verify_recover()`
+and related functions.
+They can be extended to accept an explicitly fetched algorithm of the right
+type, and to be able to incrementally process indefinite length data streams
+when the fetched algorithm permits it (for example, RSA-SHA256).
+
+It must be made clear that the added functionality cannot be used to compose
+an algorithm from different parts.  For example, it's not possible to specify
+a `EVP_SIGNATURE` "RSA" and combine it with a parameter that specifies the
+hash "SHA256" to get the "RSA-SHA256" functionality.  For an `EVP_SIGNATURE`
+"RSA", the input is still expected to be a digest, or some other input that's
+limited to the modulus size of the RSA pkey.
+
+### Making things less confusing with distinct function names
+
+Until now, `EVP_PKEY_sign()` and friends were only expected to act on the
+pre-computed digest of a message (under the condition that proper flags
+and signature md are specified using functions like
+`EVP_PKEY_CTX_set_rsa_padding()` and `EVP_PKEY_CTX_set_signature_md()`),
+or to act as "primitive" [^1] functions (under the condition that proper
+flags are specified, like `RSA_NO_PADDING` for RSA signatures).
+
+This design proposes an extension to also allow full (not pre-hashed)
+messages to be passed, in a streaming style through an *update* and a
+*final* function.
+
+Discussions have revealed that it is potentially confusing to conflate the
+current functionality with streaming style functionality into the same name,
+so this design separates those out with specific init / update / final
+functions for that purpose.  For oneshot functionality, `EVP_PKEY_sign()`
+and `EVP_PKEY_verify()` remain supported.
+
+[^1]: the term "primitive" is borrowed from [PKCS#1](https://www.rfc-editor.org/rfc/rfc8017#section-5)
+
+### Making it possible to verify with an early signature
+
+Some more recent verification algorithms need to obtain the signature
+before processing the data.
+This is particularly important for streaming modes of operation.
+This design proposes a mechanism to accomodate these algorithms
+and modes of operation.
+
+New public API - API Reference
+------------------------------
+
+### For limited input size / oneshot signing with `EVP_SIGNATURE`
+
+``` C
+int EVP_PKEY_sign_init_ex2(EVP_PKEY_CTX *pctx,
+                           EVP_SIGNATURE *algo,
+                           const OSSL_PARAM params[]);
+```
+
+### For signing a stream with `EVP_SIGNATURE`
+
+``` C
+int EVP_PKEY_sign_message_init(EVP_PKEY_CTX *pctx,
+                               EVP_SIGNATURE *algo,
+                               const OSSL_PARAM params[]);
+int EVP_PKEY_sign_message_update(EVP_PKEY_CTX *ctx,
+                                 const unsigned char *in,
+                                 size_t inlen);
+int EVP_PKEY_sign_message_final(EVP_PKEY_CTX *ctx,
+                                unsigned char *sig,
+                                size_t *siglen);
+#define EVP_PKEY_sign_message(ctx,sig,siglen,tbs,tbslen) \
+    EVP_PKEY_sign(ctx,sig,siglen,tbs,tbslen)
+```
+
+### For limited input size / oneshot verification with `EVP_SIGNATURE`
+
+``` C
+int EVP_PKEY_verify_init_ex2(EVP_PKEY_CTX *pctx,
+                             EVP_SIGNATURE *algo,
+                             const OSSL_PARAM params[]);
+```
+
+### For verifying a stream with `EVP_SIGNATURE`
+
+``` C
+/* Initializers */
+int EVP_PKEY_verify_message_init(EVP_PKEY_CTX *pctx,
+                                 EVP_SIGNATURE *algo,
+                                 const OSSL_PARAM params[]);
+/* Signature setter */
+int EVP_PKEY_CTX_set_signature(EVP_PKEY_CTX *pctx,
+                               unsigned char *sig, size_t siglen,
+                               size_t sigsize);
+/* Update and final */
+int EVP_PKEY_verify_message_update(EVP_PKEY_CTX *ctx,
+                                   const unsigned char *in,
+                                   size_t inlen);
+int EVP_PKEY_verify_message_final(EVP_PKEY_CTX *ctx);
+
+#define EVP_PKEY_verify_message(ctx,sig,siglen,tbs,tbslen) \
+    EVP_PKEY_verify(ctx,sig,siglen,tbs,tbslen)
+```
+
+### For verify_recover with `EVP_SIGNATURE`
+
+Preliminary feedback suggests that a streaming interface is uninteresting for
+verify_recover, so we only specify a new init function.
+
+``` C
+/* Initializers */
+int EVP_PKEY_verify_recover_init_ex2(EVP_PKEY_CTX *pctx,
+                                     EVP_SIGNATURE *algo,
+                                     const OSSL_PARAM params[]);
+```
+
+Requirements on the providers
+-----------------------------
+
+Because it's not immediately obvious from a composite algorithm name what
+key type ("RSA", "EC", ...) it requires / supports, at least in code, allowing
+the use of an explicitly fetched implementation of a composite algorithm
+requires that providers cooperate by declaring what key type is required /
+supported by each algorithm.
+
+For non-composite operation algorithms (like "RSA"), this is not necessary,
+see the fallback strategies below.
+
+This is to be implemented through an added provider function that would work
+like keymgmt's `query_operation_name` function, but would return a NULL
+terminated array of key type name instead:
+
+``` C
+# define OSSL_FUNC_SIGNATURE_QUERY_KEY_TYPE         26
+OSSL_CORE_MAKE_FUNC(const char **, signature_query_key_type, (void))
+```
+
+Furthermore, the distinction of intent, i.e. whether the input is expected
+to be a pre-hashed digest or the original message, must be passed on to the
+provider.  Because we already distinguish that with function names in the
+public API, we use the same mapping in the provider interface.
+
+The already existing `signature_sign` and `signature_verify` remain as they
+are, and can be combined with message init calls.
+
+``` C
+# define OSSL_FUNC_SIGNATURE_SIGN_MESSAGE_INIT      27
+# define OSSL_FUNC_SIGNATURE_SIGN_MESSAGE_UPDATE    28
+# define OSSL_FUNC_SIGNATURE_SIGN_MESSAGE_FINAL     29
+OSSL_CORE_MAKE_FUNC(int, signature_sign_message_init,
+                    (void *ctx, void *provkey, const OSSL_PARAM params[]))
+OSSL_CORE_MAKE_FUNC(int, signature_sign_message_update,
+                    (void *ctx, const unsigned char *in, size_t inlen))
+OSSL_CORE_MAKE_FUNC(int, signature_sign_message_final,
+                    (void *ctx, unsigned char *sig, size_t *siglen, size_t sigsize))
+
+# define OSSL_FUNC_SIGNATURE_VERIFY_MESSAGE_INIT    30
+# define OSSL_FUNC_SIGNATURE_VERIFY_MESSAGE_UPDATE  31
+# define OSSL_FUNC_SIGNATURE_VERIFY_MESSAGE_FINAL   32
+OSSL_CORE_MAKE_FUNC(int, signature_verify_message_init,
+                    (void *ctx, void *provkey, const OSSL_PARAM params[]))
+OSSL_CORE_MAKE_FUNC(int, signature_verify_message_update,
+                    (void *ctx, const unsigned char *in, size_t inlen))
+/*
+ * signature_verify_message_final requires that the signature to be verified
+ * against is specified via an OSSL_PARAM.
+ */
+OSSL_CORE_MAKE_FUNC(int, signature_verify_message_final, (void *ctx))
+```
+
+Fallback strategies
+-------------------
+
+Because existing providers haven't been updated to respond to the key type
+query, some fallback strategies will be needed for the init calls that take
+an explicitly fetched `EVP_SIGNATURE` argument (they can at least be used
+for pre-hashed digest operations).  To find out if the `EVP_PKEY` key type
+is possible to use with the explicitly fetched algorithm, the following
+fallback strategies may be used.
+
+-   Check if the fetched operation name matches the key type (keymgmt name)
+    of the `EVP_PKEY` that's involved in the operation.  For example, this
+    is useful when someone fetched the `EVP_SIGNATURE` "RSA".  This requires
+    very little modification, as this is already done with the initializer
+    functions that fetch the algorithm implicitly.
+-   Check if the fetched algorithm name matches the name returned by the
+    keymgmt's `query_operation_name` function.  For example, this is useful
+    when someone fetched the `EVP_SIGNATURE` "ECDSA", for which the key type
+    to use is "EC".  This requires very little modification, as this is
+    already done with the initializer functions that fetch the algorithm
+    implicitly.
+
+If none of these strategies work out, the operation initialization should
+fail.
diff --git a/doc/man1/openssl-pkeyutl.pod.in b/doc/man1/openssl-pkeyutl.pod.in
index 3c59957b8d8a..c5fb8378e8b1 100644
--- a/doc/man1/openssl-pkeyutl.pod.in
+++ b/doc/man1/openssl-pkeyutl.pod.in
@@ -437,10 +437,100 @@ for the B<-pkeyopt> B<digest> option.
 The X25519 and X448 algorithms support key derivation only. Currently there are
 no additional options.
 
+=head2 SLH-DSA ALGORITHMS
+
+The SLH-DSA algorithms (SLH-DSA-SHA2-128s, SLH-DSA-SHA2-128f, SLH-DSA-SHA2-192s, SLH-DSA-SHA2-192f, SLH-DSA-SHA2-256s, SLH-DSA-SHA2-256f) are post-quantum signature algorithms. When using SLH-DSA with pkeyutl, the following options are available:
+
+=over 4
+
+=item B<-sign>
+
+Sign the input data using an SLH-DSA private key. For example:
+
+  $ openssl pkeyutl -sign -in file.txt -inkey slhdsa.pem -out sig
+
+=item B<-verify>
+
+Verify the signature using an SLH-DSA public key. For example:
+
+  $ openssl pkeyutl -verify -in file.txt -inkey slhdsa.pem -sigfile sig
+
+=back
+
+See L<EVP_PKEY-SLH-DSA(7)> and L<EVP_SIGNATURE-SLH-DSA(7)> for additional details about the SLH-DSA algorithm and its implementation.
+
 =head1 ML-DSA-44, ML-DSA-65 AND ML-DSA-87 ALGORITHMS
 
-The B<ML-DSA> algorithms support signing and verification of "raw" messages.
-No preliminary hashing is performed.
+The ML-DSA algorithms are post-quantum signature algorithms that support signing and verification of "raw" messages.
+No preliminary hashing is performed. When using ML-DSA with pkeyutl, the following options are available:
+
+=over 4
+
+=item B<-sign>
+
+Sign the input data using an ML-DSA private key. For example:
+
+  $ openssl pkeyutl -sign -in file.txt -inkey mldsa65.pem -out sig
+
+=item B<-verify>
+
+Verify the signature using an ML-DSA public key. For example:
+
+  $ openssl pkeyutl -verify -in file.txt -inkey mldsa65.pem -sigfile sig
+
+=item B<-pkeyopt> I<opt>:I<value>
+
+Additional options for ML-DSA signing and verification:
+
+=over 4
+
+=item B<message-encoding>:I<value>
+
+Specifies the message encoding mode used for signing. This controls how the input message is processed before signing. Valid values are described in L<EVP_SIGNATURE-ML-DSA(7)>. For example:
+
+  $ openssl pkeyutl -sign -in file.txt -inkey mldsa65.pem -out sig -pkeyopt message-encoding:1
+
+=item B<test-entropy>:I<value>
+
+Specifies a test entropy value for deterministic signing. For example:
+
+  $ openssl pkeyutl -sign -in file.txt -inkey mldsa65.pem -out sig -pkeyopt test-entropy:abcdefghijklmnopqrstuvwxyz012345
+
+=item B<hextest-entropy>:I<value>
+
+Specifies a test entropy value in hex format. For example:
+
+  $ openssl pkeyutl -sign -in file.txt -inkey mldsa65.pem -out sig -pkeyopt hextest-entropy:000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f
+
+=item B<deterministic>:I<value>
+
+Enables deterministic signing. For example:
+
+  $ openssl pkeyutl -sign -in file.txt -inkey mldsa65.pem -out sig -pkeyopt deterministic:1
+
+=item B<mu>:I<value>
+
+Specifies the mu parameter. For example:
+
+  $ echo -n "0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef" >file.txt
+  $ openssl pkeyutl -sign -in file.txt -inkey mldsa65.pem -out sig -pkeyopt mu:1
+
+=back
+
+=item B<context-string>:I<string>
+
+Specifies a context string for both signing and verification operations. The context string must be the same for verification to succeed. For example:
+
+  $ openssl pkeyutl -sign -in file.txt -inkey mldsa65.pem -out sig -pkeyopt context-string:mycontext
+  $ openssl pkeyutl -verify -in file.txt -inkey mldsa65.pem -sigfile sig -pkeyopt context-string:mycontext
+
+=item B<hexcontext-string>:I<string>
+
+Specifies a context string in hex format, allowing binary control values. For example:
+
+  $ openssl pkeyutl -sign -in file.txt -inkey mldsa65.pem -out sig -pkeyopt hexcontext-string:6d79636f6e74657874
+
+=back
 
 The signing operation supports a B<deterministic>:I<bool> option,
 with I<bool> set to C<1> if a deterministic signature is to be generated
@@ -450,7 +540,7 @@ A deterministic result can also be obtained by specifying an explicit
 entropy value via the B<hextest-entropy>:I<value> parameter.
 Deterministic B<ML-DSA> signing should only be used in tests.
 
-See L<EVP_SIGNATURE-ML-DSA(7)> for additional options and detail.
+See L<EVP_SIGNATURE-ML-DSA(7)> for additional details about the ML-DSA algorithms and their implementation.
 
 =head1 ML-KEM-512, ML-KEM-768 AND ML-KEM-1024 ALGORITHMS
 
@@ -549,6 +639,34 @@ Decrypt some data using a private key with OAEP padding using SHA256:
  openssl pkeyutl -decrypt -in file -inkey key.pem -out secret \
     -pkeyopt rsa_padding_mode:oaep -pkeyopt rsa_oaep_md:sha256
 
+Create an ML-DSA key pair and sign data with a specific context string:
+
+  $ openssl genpkey -algorithm ML-DSA-65 -out mldsa65.pem
+  $ openssl pkeyutl -sign -in file.txt -inkey mldsa65.pem -out sig -pkeyopt context-string:example
+
+Verify a signature using ML-DSA with the same context string:
+
+  $ openssl pkeyutl -verify -in file.txt -inkey mldsa65.pem -sigfile sig -pkeyopt context-string:example
+
+Generate an ML-KEM key pair and use it for encapsulation:
+
+  $ openssl genpkey -algorithm ML-KEM-768 -out mlkem768.pem
+  $ openssl pkey -in mlkem768.pem -pubout -out mlkem768_pub.pem
+  $ openssl pkeyutl -encap -inkey mlkem768_pub.pem -pubin -out ciphertext -secret shared_secret.bin
+
+Decapsulate a shared secret using an ML-KEM private key:
+
+  $ openssl pkeyutl -decap -inkey mlkem768.pem -in ciphertext -secret decapsulated_secret.bin
+
+Create an SLH-DSA key pair and sign data:
+
+  $ openssl genpkey -algorithm SLH-DSA-SHA2-128s -out slh-dsa.pem
+  $ openssl pkeyutl -sign -in file.txt -inkey slh-dsa.pem -out sig
+
+Verify a signature using SLH-DSA:
+
+  $ openssl pkeyutl -verify -in file.txt -inkey slh-dsa.pem -sigfile sig
+
 =head1 SEE ALSO
 
 L<openssl(1)>,
diff --git a/doc/man1/openssl-s_client.pod.in b/doc/man1/openssl-s_client.pod.in
index d089bc60d80d..82c5917f6081 100644
--- a/doc/man1/openssl-s_client.pod.in
+++ b/doc/man1/openssl-s_client.pod.in
@@ -507,12 +507,12 @@ by some servers.
 =item B<-ign_eof>
 
 Inhibit shutting down the connection when end of file is reached in the
-input.
+input. This implicitly turns on B<-nocommands> as well.
 
 =item B<-quiet>
 
 Inhibit printing of session and certificate information.  This implicitly
-turns on B<-ign_eof> as well.
+turns on B<-ign_eof> and B<-nocommands> as well.
 
 =item B<-no_ign_eof>
 
diff --git a/doc/man3/CMS_get0_SignerInfos.pod b/doc/man3/CMS_get0_SignerInfos.pod
index 385726ced35f..46dba9cde082 100644
--- a/doc/man3/CMS_get0_SignerInfos.pod
+++ b/doc/man3/CMS_get0_SignerInfos.pod
@@ -38,7 +38,7 @@ CMS_SignerInfo_cert_cmp() compares the certificate B<cert> against the signer
 identifier B<si>. It returns zero if the comparison is successful and non zero
 if not.
 
-CMS_SignerInfo_set1_signer_cert() sets the signers certificate of B<si> to
+CMS_SignerInfo_set1_signer_cert() sets the signer's certificate of B<si> to
 B<signer>.
 
 =head1 NOTES
@@ -80,7 +80,7 @@ L<ERR_get_error(3)>, L<CMS_verify(3)>
 
 =head1 COPYRIGHT
 
-Copyright 2008-2018 The OpenSSL Project Authors. All Rights Reserved.
+Copyright 2008-2025 The OpenSSL Project Authors. All Rights Reserved.
 
 Licensed under the Apache License 2.0 (the "License").  You may not use
 this file except in compliance with the License.  You can obtain a copy
diff --git a/doc/man3/CMS_sign.pod b/doc/man3/CMS_sign.pod
index 3380b1a1dd95..ce4f39f885c2 100644
--- a/doc/man3/CMS_sign.pod
+++ b/doc/man3/CMS_sign.pod
@@ -97,7 +97,7 @@ can be performed by obtaining the streaming ASN1 B<BIO> directly using
 BIO_new_CMS().
 
 If a signer is specified it will use the default digest for the signing
-algorithm. This is B<SHA1> for both RSA and DSA keys.
+algorithm. This is B<SHA256> for both RSA and DSA keys.
 
 If B<signcert> and B<pkey> are NULL then a certificates only CMS structure is
 output.
@@ -136,7 +136,7 @@ certificates in their I<certs> argument and no longer throw an error for them.
 
 =head1 COPYRIGHT
 
-Copyright 2008-2023 The OpenSSL Project Authors. All Rights Reserved.
+Copyright 2008-2025 The OpenSSL Project Authors. All Rights Reserved.
 
 Licensed under the Apache License 2.0 (the "License").  You may not use
 this file except in compliance with the License.  You can obtain a copy
diff --git a/doc/man3/DTLS_set_timer_cb.pod b/doc/man3/DTLS_set_timer_cb.pod
index 5014e77d0fc8..618fd1f6ff0e 100644
--- a/doc/man3/DTLS_set_timer_cb.pod
+++ b/doc/man3/DTLS_set_timer_cb.pod
@@ -20,6 +20,17 @@ This function sets an optional callback function for controlling the
 timeout interval on the DTLS protocol. The callback function will be
 called by DTLS for every new DTLS packet that is sent.
 
+The callback should return the timeout interval in micro seconds.
+
+The I<timer_us> parameter of the callback is the last set timeout
+interval returned. On the first invocation of the callback,
+this value will be 0.
+
+At the beginning of the connection, if no timeout callback has been
+set via DTLS_set_timer_cb(), the default timeout value is 1 second.
+For all subsequent timeouts, the default behavior is to double the
+duration up to a maximum of 1 minute.
+
 =head1 RETURN VALUES
 
 Returns void.
@@ -30,7 +41,7 @@ The DTLS_set_timer_cb() function was added in OpenSSL 1.1.1.
 
 =head1 COPYRIGHT
 
-Copyright 2017 The OpenSSL Project Authors. All Rights Reserved.
+Copyright 2017-2025 The OpenSSL Project Authors. All Rights Reserved.
 
 Licensed under the Apache License 2.0 (the "License").  You may not use
 this file except in compliance with the License.  You can obtain a copy
diff --git a/doc/man3/EVP_PKEY_CTX_new.pod b/doc/man3/EVP_PKEY_CTX_new.pod
index d7ac221f7c19..a15abc2c3e17 100644
--- a/doc/man3/EVP_PKEY_CTX_new.pod
+++ b/doc/man3/EVP_PKEY_CTX_new.pod
@@ -49,8 +49,11 @@ used when no B<EVP_PKEY> structure is associated with the operations,
 for example during parameter generation or key generation for some
 algorithms.
 
-EVP_PKEY_CTX_dup() duplicates the context I<ctx>. It is not supported for a
-keygen operation.
+EVP_PKEY_CTX_dup() duplicates the context I<ctx>.
+It is not supported for a keygen operation.
+It is however possible to duplicate a context freshly created via any of the
+above C<new> functions, provided L<EVP_PKEY_keygen_init(3)> has not yet been
+called on the source context, and then use the copy for key generation.
 
 EVP_PKEY_CTX_free() frees up the context I<ctx>.
 If I<ctx> is NULL, nothing is done.
@@ -122,7 +125,7 @@ added in OpenSSL 3.0.
 
 =head1 COPYRIGHT
 
-Copyright 2006-2021 The OpenSSL Project Authors. All Rights Reserved.
+Copyright 2006-2025 The OpenSSL Project Authors. All Rights Reserved.
 
 Licensed under the Apache License 2.0 (the "License").  You may not use
 this file except in compliance with the License.  You can obtain a copy
diff --git a/doc/man3/EVP_PKEY_encapsulate.pod b/doc/man3/EVP_PKEY_encapsulate.pod
index a82eaded592f..e37599c4c417 100644
--- a/doc/man3/EVP_PKEY_encapsulate.pod
+++ b/doc/man3/EVP_PKEY_encapsulate.pod
@@ -30,14 +30,14 @@ key that is used during encapsulation.
 
 The EVP_PKEY_encapsulate() function performs a public key encapsulation
 operation using I<ctx>.
-The shared secret writen to I<genkey> can be used as an input for key
+The shared secret written to I<genkey> can be used as an input for key
 derivation, typically for various symmetric algorithms.
 Its size is written to I<genkeylen>, which must be initialised to the
 size of the provided buffer.
 
 The ciphertext written to I<wrappedkey> is an encapsulated form, which
 is expected to be only usable by the holder of the private key corresponding
-to wthe public key associated with I<ctx>.
+to the public key associated with I<ctx>.
 This ciphertext is then communicated to the private-key holder, who can use
 L<EVP_PKEY_decapsulate(3)> to securely recover the same shared secret.
 
diff --git a/doc/man3/EVP_PKEY_new.pod b/doc/man3/EVP_PKEY_new.pod
index eccc21aac63f..72d129deff24 100644
--- a/doc/man3/EVP_PKEY_new.pod
+++ b/doc/man3/EVP_PKEY_new.pod
@@ -174,7 +174,7 @@ C<ML-DSA-87>,
 B<ML-KEM-512>,
 B<ML-KEM-768> and
 B<ML-KEM-1024>
-keys, which don't have legacy numeric I<NID> assigments, but their raw form is
+keys, which don't have legacy numeric I<NID> assignments, but their raw form is
 nevertheless available.
 
 
@@ -198,7 +198,7 @@ C<ML-DSA-87>,
 B<ML-KEM-512>,
 B<ML-KEM-768> and
 B<ML-KEM-1024>
-keys, which don't have legacy numeric I<NID> assigments, but their raw form is
+keys, which don't have legacy numeric I<NID> assignments, but their raw form is
 nevertheless available.
 
 EVP_PKEY_new_CMAC_key() works in the same way as EVP_PKEY_new_raw_private_key()
diff --git a/doc/man3/EVP_PKEY_sign.pod b/doc/man3/EVP_PKEY_sign.pod
index b88a9893f52f..300f77889fd8 100644
--- a/doc/man3/EVP_PKEY_sign.pod
+++ b/doc/man3/EVP_PKEY_sign.pod
@@ -40,7 +40,7 @@ signing a pre-computed message digest using the algorithm given by I<algo> and
 the key given through L<EVP_PKEY_CTX_new(3)> or L<EVP_PKEY_CTX_new_from_pkey(3)>.
 A context I<ctx> without a pre-loaded key cannot be used with this function.
 This function provides almost the same functionality as EVP_PKEY_sign_init_ex(),
-but is uniquely intended to be used with a pre-computed messsage digest, and
+but is uniquely intended to be used with a pre-computed message digest, and
 allows pre-determining the exact conditions for that message digest, if a
 composite signature algorithm (such as RSA-SHA256) was fetched.
 Following a call to this function, setting parameters that modifies the digest
@@ -358,7 +358,7 @@ where added in OpenSSL 3.4.
 
 =head1 COPYRIGHT
 
-Copyright 2006-2024 The OpenSSL Project Authors. All Rights Reserved.
+Copyright 2006-2025 The OpenSSL Project Authors. All Rights Reserved.
 
 Licensed under the Apache License 2.0 (the "License").  You may not use
 this file except in compliance with the License.  You can obtain a copy
diff --git a/doc/man3/EVP_RAND.pod b/doc/man3/EVP_RAND.pod
index fdb9ef9dcfd1..b9abd245cd7e 100644
--- a/doc/man3/EVP_RAND.pod
+++ b/doc/man3/EVP_RAND.pod
@@ -152,11 +152,8 @@ operating system.  If I<prediction_resistance> is specified, fresh entropy
 from a live source will be sought.  This call operates as per NIST SP 800-90A
 and SP 800-90C.
 
-EVP_RAND_nonce() creates a nonce in I<out> of maximum length I<outlen>
-bytes from the RAND I<ctx>. The function returns the length of the generated
-nonce. If I<out> is NULL, the length is still returned but no generation
-takes place. This allows a caller to dynamically allocate a buffer of the
-appropriate size.
+EVP_RAND_nonce() creates a nonce in I<out> of length I<outlen>
+bytes from the RAND I<ctx>.
 
 EVP_RAND_enable_locking() enables locking for the RAND I<ctx> and all of
 its parents.  After this I<ctx> will operate in a thread safe manner, albeit
@@ -385,7 +382,7 @@ EVP_RAND_CTX_free() does not return a value.
 
 EVP_RAND_CTX_up_ref() returns 1 on success, 0 on error.
 
-EVP_RAND_nonce() returns the length of the nonce.
+EVP_RAND_nonce() returns 1 on success, 0 on error.
 
 EVP_RAND_get_strength() returns the strength of the random number generator
 in bits.
@@ -417,7 +414,7 @@ The remaining functions were added in OpenSSL 3.0.
 
 =head1 COPYRIGHT
 
-Copyright 2020-2024 The OpenSSL Project Authors. All Rights Reserved.
+Copyright 2020-2025 The OpenSSL Project Authors. All Rights Reserved.
 
 Licensed under the Apache License 2.0 (the "License").  You may not use
 this file except in compliance with the License.  You can obtain a copy
diff --git a/doc/man3/OSSL_CMP_CTX_new.pod b/doc/man3/OSSL_CMP_CTX_new.pod
index 0df0e78367e9..53e8166228da 100644
--- a/doc/man3/OSSL_CMP_CTX_new.pod
+++ b/doc/man3/OSSL_CMP_CTX_new.pod
@@ -106,7 +106,7 @@ OSSL_CMP_CTX_set1_senderNonce
  /* server authentication: */
  int OSSL_CMP_CTX_set1_srvCert(OSSL_CMP_CTX *ctx, X509 *cert);
  int OSSL_CMP_CTX_set1_expected_sender(OSSL_CMP_CTX *ctx,
-                                      const X509_NAME *name);
+                                       const X509_NAME *name);
  #define OSSL_CMP_CTX_set0_trusted OSSL_CMP_CTX_set0_trustedStore
  int OSSL_CMP_CTX_set0_trustedStore(OSSL_CMP_CTX *ctx, X509_STORE *store);
  #define OSSL_CMP_CTX_get0_trusted OSSL_CMP_CTX_get0_trustedStore
@@ -214,147 +214,147 @@ The following options can be set:
 
 =item B<OSSL_CMP_OPT_LOG_VERBOSITY>
 
-        The level of severity needed for actually outputting log messages
-        due to errors, warnings, general info, debugging, etc.
-        Default is OSSL_CMP_LOG_INFO. See also L<OSSL_CMP_log_open(3)>.
+The level of severity needed for actually outputting log messages
+due to errors, warnings, general info, debugging, etc.
+Default is OSSL_CMP_LOG_INFO. See also L<OSSL_CMP_log_open(3)>.
 
 =item B<OSSL_CMP_OPT_KEEP_ALIVE>
 
-        If the given value is 0 then HTTP connections are not kept open
-        after receiving a response, which is the default behavior for HTTP 1.0.
-        If the value is 1 or 2 then persistent connections are requested.
-        If the value is 2 then persistent connections are required,
-        i.e., in case the server does not grant them an error occurs.
-        The default value is 1: prefer to keep the connection open.
+If the given value is 0 then HTTP connections are not kept open
+after receiving a response, which is the default behavior for HTTP 1.0.
+If the value is 1 or 2 then persistent connections are requested.
+If the value is 2 then persistent connections are required,
+i.e., in case the server does not grant them an error occurs.
+The default value is 1: prefer to keep the connection open.
 
 =item B<OSSL_CMP_OPT_MSG_TIMEOUT>
 
-        Number of seconds a CMP request-response message round trip
-        is allowed to take before a timeout error is returned.
-        A value <= 0 means no limitation (waiting indefinitely).
-        Default is to use the B<OSSL_CMP_OPT_TOTAL_TIMEOUT> setting.
+Number of seconds a CMP request-response message round trip
+is allowed to take before a timeout error is returned.
+A value <= 0 means no limitation (waiting indefinitely).
+Default is to use the B<OSSL_CMP_OPT_TOTAL_TIMEOUT> setting.
 
 =item B<OSSL_CMP_OPT_TOTAL_TIMEOUT>
 
-        Maximum total number of seconds a transaction may take,
-        including polling etc.
-        A value <= 0 means no limitation (waiting indefinitely).
-        Default is 0.
+Maximum total number of seconds a transaction may take,
+including polling etc.
+A value <= 0 means no limitation (waiting indefinitely).
+Default is 0.
 
 =item B<OSSL_CMP_OPT_USE_TLS>
 
-        Use this option to indicate to the HTTP implementation
-        whether TLS is going to be used for the connection (resulting in HTTPS).
-        The value 1 indicates that TLS is used for client-side HTTP connections,
-        which needs to be implemented via a callback function set by
-        OSSL_CMP_CTX_set_http_cb().
-        The value 0 indicates that TLS is not used.
-        Default is -1 for backward compatibility: TLS is used by the client side
-        if and only if OSSL_CMP_CTX_set_http_cb_arg() sets a non-NULL I<arg>.
+Use this option to indicate to the HTTP implementation
+whether TLS is going to be used for the connection (resulting in HTTPS).
+The value 1 indicates that TLS is used for client-side HTTP connections,
+which needs to be implemented via a callback function set by
+OSSL_CMP_CTX_set_http_cb().
+The value 0 indicates that TLS is not used.
+Default is -1 for backward compatibility: TLS is used by the client side
+if and only if OSSL_CMP_CTX_set_http_cb_arg() sets a non-NULL I<arg>.
 
 =item B<OSSL_CMP_OPT_VALIDITY_DAYS>
 
-        Number of days new certificates are asked to be valid for.
+Number of days new certificates are asked to be valid for.
 
 =item B<OSSL_CMP_OPT_SUBJECTALTNAME_NODEFAULT>
 
-        Do not take default Subject Alternative Names
-        from the reference certificate.
+Do not take default Subject Alternative Names
+from the reference certificate.
 
 =item B<OSSL_CMP_OPT_SUBJECTALTNAME_CRITICAL>
 
-        Demand that the given Subject Alternative Names are flagged as critical.
+Demand that the given Subject Alternative Names are flagged as critical.
 
 =item B<OSSL_CMP_OPT_POLICIES_CRITICAL>
 
-        Demand that the given policies are flagged as critical.
+Demand that the given policies are flagged as critical.
 
 =item B<OSSL_CMP_OPT_POPO_METHOD>
 
-        Select the proof of possession method to use. Possible values are:
+Select the proof of possession method to use. Possible values are:
 
-            OSSL_CRMF_POPO_NONE       - ProofOfPossession field omitted,
-                                        which implies central key generation
-            OSSL_CRMF_POPO_RAVERIFIED - assert that the RA has already
-                                        verified the PoPo
-            OSSL_CRMF_POPO_SIGNATURE  - sign a value with private key,
-                                        which is the default.
-            OSSL_CRMF_POPO_KEYENC     - decrypt the encrypted certificate
-                                        ("indirect method")
+    OSSL_CRMF_POPO_NONE       - ProofOfPossession field omitted,
+                                which implies central key generation
+    OSSL_CRMF_POPO_RAVERIFIED - assert that the RA has already
+                                verified the PoPo
+    OSSL_CRMF_POPO_SIGNATURE  - sign a value with private key,
+                                which is the default.
+    OSSL_CRMF_POPO_KEYENC     - decrypt the encrypted certificate
+                                ("indirect method")
 
-        Note that a signature-based POPO can only be produced if a private key
-        is provided as the newPkey or client's pkey component of the CMP context.
+Note that a signature-based POPO can only be produced if a private key
+is provided as the newPkey or client's pkey component of the CMP context.
 
 =item B<OSSL_CMP_OPT_DIGEST_ALGNID>
 
-        The NID of the digest algorithm to be used in RFC 4210's MSG_SIG_ALG
-        for signature-based message protection and Proof-of-Possession (POPO).
-        Default is SHA256.
+The NID of the digest algorithm to be used in RFC 4210's MSG_SIG_ALG
+for signature-based message protection and Proof-of-Possession (POPO).
+Default is SHA256.
 
 =item B<OSSL_CMP_OPT_OWF_ALGNID>
-        The NID of the digest algorithm to be used as one-way function (OWF)
-        for MAC-based message protection with password-based MAC (PBM).
-        See RFC 4210 section 5.1.3.1 for details.
-        Default is SHA256.
+The NID of the digest algorithm to be used as one-way function (OWF)
+for MAC-based message protection with password-based MAC (PBM).
+See RFC 4210 section 5.1.3.1 for details.
+Default is SHA256.
 
 =item B<OSSL_CMP_OPT_MAC_ALGNID>
-        The NID of the MAC algorithm to be used for message protection with PBM.
-        Default is HMAC-SHA1 as per RFC 4210.
+The NID of the MAC algorithm to be used for message protection with PBM.
+Default is HMAC-SHA1 as per RFC 4210.
 
 =item B<OSSL_CMP_OPT_REVOCATION_REASON>
 
-        The reason code to be included in a Revocation Request (RR);
-        values: 0..10 (RFC 5210, 5.3.1) or -1 for none, which is the default.
+The reason code to be included in a Revocation Request (RR);
+values: 0..10 (RFC 5210, 5.3.1) or -1 for none, which is the default.
 
 =item B<OSSL_CMP_OPT_IMPLICIT_CONFIRM>
 
-        Request server to enable implicit confirm mode, where the client
-        does not need to send confirmation upon receiving the
-        certificate. If the server does not enable implicit confirmation
-        in the return message, then confirmation is sent anyway.
+Request server to enable implicit confirm mode, where the client
+does not need to send confirmation upon receiving the
+certificate. If the server does not enable implicit confirmation
+in the return message, then confirmation is sent anyway.
 
 =item B<OSSL_CMP_OPT_DISABLE_CONFIRM>
 
-        Do not confirm enrolled certificates, to cope with broken servers
-        not supporting implicit confirmation correctly.
+Do not confirm enrolled certificates, to cope with broken servers
+not supporting implicit confirmation correctly.
 B<WARNING:> This setting leads to unspecified behavior and it is meant
 exclusively to allow interoperability with server implementations violating
 RFC 4210.
 
 =item B<OSSL_CMP_OPT_UNPROTECTED_SEND>
 
-        Send request or response messages without CMP-level protection.
+Send request or response messages without CMP-level protection.
 
 =item B<OSSL_CMP_OPT_UNPROTECTED_ERRORS>
 
-        Accept unprotected error responses which are either explicitly
-        unprotected or where protection verification failed. Applies to regular
-        error messages as well as certificate responses (IP/CP/KUP) and
-        revocation responses (RP) with rejection.
+Accept unprotected error responses which are either explicitly
+unprotected or where protection verification failed. Applies to regular
+error messages as well as certificate responses (IP/CP/KUP) and
+revocation responses (RP) with rejection.
 B<WARNING:> This setting leads to unspecified behavior and it is meant
 exclusively to allow interoperability with server implementations violating
 RFC 4210.
 
 =item B<OSSL_CMP_OPT_IGNORE_KEYUSAGE>
 
-        Ignore key usage restrictions in the signer's certificate when
-        validating signature-based protection in received CMP messages.
-        Else, 'digitalSignature' must be allowed by CMP signer certificates.
+Ignore key usage restrictions in the signer's certificate when
+validating signature-based protection in received CMP messages.
+Else, 'digitalSignature' must be allowed by CMP signer certificates.
 
 =item B<OSSL_CMP_OPT_PERMIT_TA_IN_EXTRACERTS_FOR_IR>
 
-        Allow retrieving a trust anchor from extraCerts and using that
-        to validate the certificate chain of an IP message.
-        This is a quirk option added to support 3GPP TS 33.310.
+Allow retrieving a trust anchor from extraCerts and using that
+to validate the certificate chain of an IP message.
+This is a quirk option added to support 3GPP TS 33.310.
 
-        Note that using this option is dangerous as the certificate obtained
-        this way has not been authenticated (at least not at CMP level).
-        Taking it over as a trust anchor implements trust-on-first-use (TOFU).
+Note that using this option is dangerous as the certificate obtained
+this way has not been authenticated (at least not at CMP level).
+Taking it over as a trust anchor implements trust-on-first-use (TOFU).
 
 =item B<OSSL_CMP_OPT_NO_CACHE_EXTRACERTS>
 
-        Do not cache certificates received in the extraCerts CMP message field.
-        Otherwise they are stored to potentially help validate further messages.
+Do not cache certificates received in the extraCerts CMP message field.
+Otherwise they are stored to potentially help validate further messages.
 
 =back
 
diff --git a/doc/man3/OSSL_CRMF_MSG_get0_tmpl.pod b/doc/man3/OSSL_CRMF_MSG_get0_tmpl.pod
index 6c095c0ee0e8..0f700c118f55 100644
--- a/doc/man3/OSSL_CRMF_MSG_get0_tmpl.pod
+++ b/doc/man3/OSSL_CRMF_MSG_get0_tmpl.pod
@@ -109,7 +109,7 @@ On success, the function verifies the decrypted data as signed data,
 using the trust store I<ts> and any untrusted certificates in I<extra>.
 Doing so, it checks for the purpose "CMP Key Generation Authority" (cmKGA).
 
-OSSL_CRMF_ENCRYPTEDKEY_init_envdata() returns I<OSSL_CRMF_ENCRYPTEDKEY>, intialized with 
+OSSL_CRMF_ENCRYPTEDKEY_init_envdata() returns I<OSSL_CRMF_ENCRYPTEDKEY>, initialized with
 the enveloped data I<envdata>.
 
 OSSL_CRMF_ENCRYPTEDVALUE_decrypt() decrypts the encrypted value in the given
diff --git a/doc/man3/OSSL_PARAM.pod b/doc/man3/OSSL_PARAM.pod
index 22fd0f0d7dd7..8a50db2b94d4 100644
--- a/doc/man3/OSSL_PARAM.pod
+++ b/doc/man3/OSSL_PARAM.pod
@@ -356,7 +356,7 @@ could fill in the parameters like this:
 
 =head1 SEE ALSO
 
-L<openssl-core.h(7)>, L<OSSL_PARAM_get_int(3)>, L<OSSL_PARAM_dup(3)>
+L<openssl-core.h(7)>, L<OSSL_PARAM_get_int(3)>, L<OSSL_PARAM_dup(3)>, L<OSSL_PARAM_construct_utf8_string(3)>
 
 =head1 HISTORY
 
@@ -364,7 +364,7 @@ B<OSSL_PARAM> was added in OpenSSL 3.0.
 
 =head1 COPYRIGHT
 
-Copyright 2019-2023 The OpenSSL Project Authors. All Rights Reserved.
+Copyright 2019-2025 The OpenSSL Project Authors. All Rights Reserved.
 
 Licensed under the Apache License 2.0 (the "License").  You may not use
 this file except in compliance with the License.  You can obtain a copy
diff --git a/doc/man3/OSSL_PARAM_int.pod b/doc/man3/OSSL_PARAM_int.pod
index dae0de083a62..a2bcd535b014 100644
--- a/doc/man3/OSSL_PARAM_int.pod
+++ b/doc/man3/OSSL_PARAM_int.pod
@@ -392,6 +392,29 @@ could fill in the parameters like this:
     if ((p = OSSL_PARAM_locate(params, "cookie")) != NULL)
         OSSL_PARAM_set_utf8_ptr(p, "cookie value");
 
+=head2 Example 3
+
+This example shows a special case where
+I<-Wincompatible-pointer-types-discards-qualifiers> may be set during
+compilation. The value for I<buf> cannot be a I<const char *> type string. An
+alternative in this case would be to use B<OSSL_PARAM> macro abbreviated calls
+rather than the specific callers which allows you to define the sha1 argument
+as a standard character array (I<char[]>).
+
+For example, this code:
+
+    OSSL_PARAM params[2];
+    params[0] = OSSL_PARAM_construct_utf8_string("digest", "SHA1", 0);
+    params[1] = OSSL_PARAM_construct_end();
+
+Can be made compatible with the following version:
+
+    char sha1[] = "SHA1"; /* sha1 is defined as char[] in this case */
+    OSSL_PARAM params[2];
+
+    params[0] = OSSL_PARAM_construct_utf8_string("digest", sha1, 0);
+    params[1] = OSSL_PARAM_construct_end();
+
 =head1 SEE ALSO
 
 L<openssl-core.h(7)>, L<OSSL_PARAM(3)>
@@ -402,7 +425,7 @@ These APIs were introduced in OpenSSL 3.0.
 
 =head1 COPYRIGHT
 
-Copyright 2019-2023 The OpenSSL Project Authors. All Rights Reserved.
+Copyright 2019-2025 The OpenSSL Project Authors. All Rights Reserved.
 
 Licensed under the Apache License 2.0 (the "License").  You may not use
 this file except in compliance with the License.  You can obtain a copy
diff --git a/doc/man3/PKCS7_sign.pod b/doc/man3/PKCS7_sign.pod
index 1d997045fe14..5c55aa191def 100644
--- a/doc/man3/PKCS7_sign.pod
+++ b/doc/man3/PKCS7_sign.pod
@@ -80,7 +80,7 @@ can be performed by obtaining the streaming ASN1 B<BIO> directly using
 BIO_new_PKCS7().
 
 If a signer is specified it will use the default digest for the signing
-algorithm. This is B<SHA1> for both RSA and DSA keys.
+algorithm. This is B<SHA256> for both RSA and DSA keys.
 
 The I<certs>, I<signcert> and I<pkey> parameters can all be
 NULL if the B<PKCS7_PARTIAL> flag is set. One or more signers can be added
@@ -122,7 +122,7 @@ The B<PKCS7_STREAM> flag was added in OpenSSL 1.0.0.
 
 =head1 COPYRIGHT
 
-Copyright 2002-2023 The OpenSSL Project Authors. All Rights Reserved.
+Copyright 2002-2025 The OpenSSL Project Authors. All Rights Reserved.
 
 Licensed under the Apache License 2.0 (the "License").  You may not use
 this file except in compliance with the License.  You can obtain a copy
diff --git a/doc/man3/SSL_CONF_cmd.pod b/doc/man3/SSL_CONF_cmd.pod
index e2c1e6984703..9338ffc01ddf 100644
--- a/doc/man3/SSL_CONF_cmd.pod
+++ b/doc/man3/SSL_CONF_cmd.pod
@@ -74,7 +74,7 @@ B<SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION>.
 
 =item B<-no_renegotiation>
 
-Disables all attempts at renegotiation in TLSv1.2 and earlier, same as setting
+Disables all attempts at renegotiation in (D)TLSv1.2 and earlier, same as setting
 B<SSL_OP_NO_RENEGOTIATION>.
 
 =item B<-no_resumption_on_reneg>
diff --git a/doc/man3/SSL_CTX_set_min_proto_version.pod b/doc/man3/SSL_CTX_set_min_proto_version.pod
index 9a2da37ab729..d9b61dcce9fd 100644
--- a/doc/man3/SSL_CTX_set_min_proto_version.pod
+++ b/doc/man3/SSL_CTX_set_min_proto_version.pod
@@ -31,9 +31,10 @@ L<SSL_CTX_set_options(3)> that also make it possible to disable
 specific protocol versions.
 Use these functions instead of disabling specific protocol versions.
 
-Setting the minimum or maximum version to 0, will enable protocol
+Setting the minimum or maximum version to 0 (default), will enable protocol
 versions down to the lowest version, or up to the highest version
-supported by the library, respectively.
+supported by the library, respectively. The supported versions might be
+controlled by system configuration.
 
 Getters return 0 in case B<ctx> or B<ssl> have been configured to
 automatically use the lowest or highest version supported by the library.
@@ -67,7 +68,7 @@ were added in OpenSSL 1.1.1.
 
 =head1 COPYRIGHT
 
-Copyright 2016-2023 The OpenSSL Project Authors. All Rights Reserved.
+Copyright 2016-2025 The OpenSSL Project Authors. All Rights Reserved.
 
 Licensed under the Apache License 2.0 (the "License").  You may not use
 this file except in compliance with the License.  You can obtain a copy
diff --git a/doc/man3/SSL_CTX_set_options.pod b/doc/man3/SSL_CTX_set_options.pod
index a6c922ecf92c..fa344337b5f8 100644
--- a/doc/man3/SSL_CTX_set_options.pod
+++ b/doc/man3/SSL_CTX_set_options.pod
@@ -286,7 +286,7 @@ Do not query the MTU. Only affects DTLS connections.
 
 =item SSL_OP_NO_RENEGOTIATION
 
-Disable all renegotiation in TLSv1.2 and earlier. Do not send HelloRequest
+Disable all renegotiation in (D)TLSv1.2 and earlier. Do not send HelloRequest
 messages, and ignore renegotiation requests via ClientHello.
 
 =item SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION
@@ -542,7 +542,7 @@ whether these macros are defined or not.
 
 =head1 COPYRIGHT
 
-Copyright 2001-2023 The OpenSSL Project Authors. All Rights Reserved.
+Copyright 2001-2025 The OpenSSL Project Authors. All Rights Reserved.
 
 Licensed under the Apache License 2.0 (the "License").  You may not use
 this file except in compliance with the License.  You can obtain a copy
diff --git a/doc/man3/SSL_key_update.pod b/doc/man3/SSL_key_update.pod
index 6238e67649e0..6f9f9b92365c 100644
--- a/doc/man3/SSL_key_update.pod
+++ b/doc/man3/SSL_key_update.pod
@@ -53,7 +53,9 @@ such as SSL_read_ex() or SSL_write_ex() takes place on the connection a check
 will be performed to confirm that it is a suitable time to start a
 renegotiation. If so, then it will be initiated immediately. OpenSSL will not
 attempt to resume any session associated with the connection in the new
-handshake.
+handshake. Note that some servers will respond to reneogitation attempts with
+a "no_renegotiation" alert. An OpenSSL will immediately fail the connection in
+this case.
 
 When called from the client side, SSL_renegotiate_abbreviated() works in the
 same was as SSL_renegotiate() except that OpenSSL will attempt to resume the
@@ -118,7 +120,7 @@ OpenSSL 1.1.1.
 
 =head1 COPYRIGHT
 
-Copyright 2017-2023 The OpenSSL Project Authors. All Rights Reserved.
+Copyright 2017-2025 The OpenSSL Project Authors. All Rights Reserved.
 
 Licensed under the Apache License 2.0 (the "License").  You may not use
 this file except in compliance with the License.  You can obtain a copy
diff --git a/doc/man3/SSL_new_listener.pod b/doc/man3/SSL_new_listener.pod
index b830bd11bd17..291c103381e7 100644
--- a/doc/man3/SSL_new_listener.pod
+++ b/doc/man3/SSL_new_listener.pod
@@ -130,6 +130,14 @@ connection is created and returned on success. If no incoming connection is
 available and the listener SSL object is configured in nonblocking mode, NULL is
 returned.
 
+The new SSL object returned from SSL_accept_connection() may or may not have
+completed its handshake at the point it is returned. Optionally, you may use the
+function L<SSL_is_init_finished(3)> to determine this. You may call the
+functions L<SSL_accept(3)>, L<SSL_do_handshake(3)> or L<SSL_handle_events(3)> to
+progress the state of the SSL object towards handshake completion. Other "I/O"
+functions may also implicitly progress the state of the handshake such as
+L<SSL_poll(3)>, L<SSL_read(3)> and L<SSL_write(3)>.
+
 The B<SSL_ACCEPT_CONNECTION_NO_BLOCK> flag may be specified to
 SSL_accept_connection(). If specified, the call does not block even if the
 listener SSL object is configured in blocking mode.
diff --git a/doc/man3/SSL_set1_host.pod b/doc/man3/SSL_set1_host.pod
index c91a075a6a60..b65116a53f5f 100644
--- a/doc/man3/SSL_set1_host.pod
+++ b/doc/man3/SSL_set1_host.pod
@@ -9,8 +9,8 @@ SSL server verification parameters
 
  #include <openssl/ssl.h>
 
- int SSL_set1_host(SSL *s, const char *hostname);
- int SSL_add1_host(SSL *s, const char *hostname);
+ int SSL_set1_host(SSL *s, const char *host);
+ int SSL_add1_host(SSL *s, const char *host);
  void SSL_set_hostflags(SSL *s, unsigned int flags);
  const char *SSL_get0_peername(SSL *s);
 
@@ -18,29 +18,36 @@ SSL server verification parameters
 
 These functions configure server hostname checks in the SSL client.
 
-SSL_set1_host() sets the expected DNS hostname to B<name> clearing
-any previously specified hostname.  If B<name> is NULL
-or the empty string, the list of hostnames is cleared and name
-checks are not performed on the peer certificate.  When a nonempty
-B<name> is specified, certificate verification automatically checks
-the peer hostname via L<X509_check_host(3)> with B<flags> as specified
+SSL_set1_host() sets in the verification parameters of I<s>
+the expected DNS hostname or IP address to I<host>,
+clearing any previously specified IP address and hostnames.
+If I<host> is NULL or the empty string, IP address
+and hostname checks are not performed on the peer certificate.
+When a nonempty I<host> is specified, certificate verification automatically
+checks the peer hostname via L<X509_check_host(3)> with I<flags> as specified
 via SSL_set_hostflags().  Clients that enable DANE TLSA authentication
 via L<SSL_dane_enable(3)> should leave it to that function to set
 the primary reference identifier of the peer, and should not call
 SSL_set1_host().
 
-SSL_add1_host() adds B<name> as an additional reference identifier
-that can match the peer's certificate.  Any previous names set via
-SSL_set1_host() or SSL_add1_host() are retained, no change is made
-if B<name> is NULL or empty.  When multiple names are configured,
-the peer is considered verified when any name matches.  This function
-is required for DANE TLSA in the presence of service name indirection
-via CNAME, MX or SRV records as specified in RFC7671, RFC7672 or
-RFC7673.
+SSL_add1_host() adds I<host> as an additional reference identifier
+that can match the peer's certificate.  Any previous hostnames
+set via SSL_set1_host() or SSL_add1_host() are retained.
+Adding an IP address is allowed only if no IP address has been set before.
+No change is made if I<host> is NULL or empty.
+When an IP address and/or multiple hostnames are configured,
+the peer is considered verified when any of these matches.
+This function is required for DANE TLSA in the presence of service name indirection
+via CNAME, MX or SRV records as specified in RFCs 7671, 7672, and 7673.
 
-SSL_set_hostflags() sets the B<flags> that will be passed to
+TLS clients are recommended to use SSL_set1_host() or SSL_add1_host()
+for server hostname or IP address validation,
+as well as L<SSL_set_tlsext_host_name(3)> for Server Name Indication (SNI),
+which may be crucial also for correct routing of the connection request.
+
+SSL_set_hostflags() sets the I<flags> that will be passed to
 L<X509_check_host(3)> when name checks are applicable, by default
-the B<flags> value is 0.  See L<X509_check_host(3)> for the list
+the I<flags> value is 0.  See L<X509_check_host(3)> for the list
 of available flags and their meaning.
 
 SSL_get0_peername() returns the DNS hostname or subject CommonName
@@ -51,13 +58,13 @@ of the reference identifiers configured via SSL_set1_host() or
 SSL_add1_host() starts with ".", which indicates a parent domain prefix
 rather than a fixed name, the matched peer name may be a sub-domain
 of the reference identifier.  The returned string is allocated by
-the library and is no longer valid once the associated B<ssl> handle
+the library and is no longer valid once the associated I<ssl> handle
 is cleared or freed, or a renegotiation takes place.  Applications
 must not free the return value.
 
 SSL clients are advised to use these functions in preference to
 explicitly calling L<X509_check_host(3)>.  Hostname checks may be out
-of scope with the RFC7671 DANE-EE(3) certificate usage, and the
+of scope with the RFC 7671 DANE-EE(3) certificate usage, and the
 internal check will be suppressed as appropriate when DANE is
 enabled.
 
@@ -66,8 +73,10 @@ enabled.
 SSL_set1_host() and SSL_add1_host() return 1 for success and 0 for
 failure.
 
+SSL_set_hostflags() returns nothing at all.
+
 SSL_get0_peername() returns NULL if peername verification is not
-applicable (as with RFC7671 DANE-EE(3)), or no trusted peername was
+applicable (as with RFC 7671 DANE-EE(3)), or no trusted peername was
 matched.  Otherwise, it returns the matched peername.  To determine
 whether verification succeeded call L<SSL_get_verify_result(3)>.
 
@@ -99,9 +108,8 @@ the lifetime of the SSL connection.
 =head1 SEE ALSO
 
 L<ssl(7)>,
-L<X509_check_host(3)>,
-L<SSL_get_verify_result(3)>.
-L<SSL_dane_enable(3)>.
+L<X509_check_host(3)>, L<SSL_set_tlsext_host_name(3)>,
+L<SSL_get_verify_result(3)>, L<SSL_dane_enable(3)>
 
 =head1 HISTORY
 
@@ -109,7 +117,7 @@ These functions were added in OpenSSL 1.1.0.
 
 =head1 COPYRIGHT
 
-Copyright 2016-2020 The OpenSSL Project Authors. All Rights Reserved.
+Copyright 2016-2025 The OpenSSL Project Authors. All Rights Reserved.
 
 Licensed under the Apache License 2.0 (the "License").  You may not use
 this file except in compliance with the License.  You can obtain a copy
diff --git a/doc/man3/SSL_set_quic_tls_cbs.pod b/doc/man3/SSL_set_quic_tls_cbs.pod
index 618cc29bc74d..75d217bdeaa6 100644
--- a/doc/man3/SSL_set_quic_tls_cbs.pod
+++ b/doc/man3/SSL_set_quic_tls_cbs.pod
@@ -110,7 +110,7 @@ ever be read by OpenSSL.
 
 The OSSL_FUNC_SSL_QUIC_TLS_yield_secret_fn callback (function id
 B<OSSL_FUNC_SSL_QUIC_TLS_YIELD_SECRET>) is called when a new secret has been
-established. The I<prot_level> argument identies the TLS protection level and
+established. The I<prot_level> argument identities the TLS protection level and
 will be one of B<OSSL_RECORD_PROTECTION_LEVEL_NONE>,
 B<OSSL_RECORD_PROTECTION_LEVEL_EARLY>, B<OSSL_RECORD_PROTECTION_LEVEL_HANDSHAKE>
 or B<OSSL_RECORD_PROTECTION_LEVEL_APPLICATION>. The I<direction> will either be
diff --git a/doc/man3/X509_STORE_CTX_new.pod b/doc/man3/X509_STORE_CTX_new.pod
index c219cee9d621..76cb7000c289 100644
--- a/doc/man3/X509_STORE_CTX_new.pod
+++ b/doc/man3/X509_STORE_CTX_new.pod
@@ -85,7 +85,7 @@ If I<ctx> is NULL nothing is done.
 X509_STORE_CTX_init() sets up I<ctx> for a subsequent verification operation.
 
 X509_STORE_CTX_init() initializes the internal state and resources of the
-given I<ctx>. Among others, it sets the verification parameters associcated
+given I<ctx>. Among others, it sets the verification parameters associated
 with the method name C<default>, which includes the C<any> purpose,
 and takes over callback function pointers from I<trust_store> (unless NULL).
 It must be called before each call to L<X509_verify_cert(3)> or
@@ -319,7 +319,7 @@ There is no need to call X509_STORE_CTX_cleanup() explicitly since OpenSSL 3.0.
 
 =head1 COPYRIGHT
 
-Copyright 2009-2024 The OpenSSL Project Authors. All Rights Reserved.
+Copyright 2009-2025 The OpenSSL Project Authors. All Rights Reserved.
 
 Licensed under the Apache License 2.0 (the "License").  You may not use
 this file except in compliance with the License.  You can obtain a copy
diff --git a/doc/man3/X509_check_purpose.pod b/doc/man3/X509_check_purpose.pod
index 4e152be8fa5d..59440dc013d7 100644
--- a/doc/man3/X509_check_purpose.pod
+++ b/doc/man3/X509_check_purpose.pod
@@ -80,7 +80,7 @@ Unless the id stays the same for an existing entry, I<id> must be fresh,
 which can be achieved by using the result of X509_PURPOSE_get_unused_id().
 The function also sets in the entry the trust id I<trust>, the given I<flags>,
 the purpose (long) name I<name>, the short name I<sname>, the purpose checking
-funktion I<ck> of type B<int (*) (const X509_PURPOSE *, const X509 *, int)>,
+function I<ck> of type B<int (*) (const X509_PURPOSE *, const X509 *, int)>,
 and its user data I<arg> which may be retrieved via the B<X509_PURPOSE> pointer.
 
 X509_PURPOSE_cleanup() removes all purposes that are not pre-defined.
diff --git a/doc/man7/OSSL_PROVIDER-FIPS.pod b/doc/man7/OSSL_PROVIDER-FIPS.pod
index 20d35fada87f..571a1e99e089 100644
--- a/doc/man7/OSSL_PROVIDER-FIPS.pod
+++ b/doc/man7/OSSL_PROVIDER-FIPS.pod
@@ -573,6 +573,19 @@ want to operate in a FIPS approved manner.  The algorithms are:
 
 =back
 
+You can load the FIPS provider into multiple library contexts as any other
+provider. However the following restriction applies. The FIPS provider cannot
+be used by multiple copies of OpenSSL libcrypto in a single process.
+
+As the provider saves core callbacks to the libcrypto obtained in the
+OSSL_provider_init() call to global data it will fail if subsequent
+invocations of its OSSL_provider_init() function yield different addresses
+of these callbacks than in the initial call. This happens when different
+copies of libcrypto are present in the memory of the process and both try
+to load the same FIPS provider. A workaround is to have a different copy
+of the FIPS provider loaded for each of the libcrypto instances in the
+process.
+
 =head1 SEE ALSO
 
 L<openssl-fipsinstall(1)>,
diff --git a/doc/man7/ossl-guide-tls-introduction.pod b/doc/man7/ossl-guide-tls-introduction.pod
index 19aabfbbb7a3..5789524324d1 100644
--- a/doc/man7/ossl-guide-tls-introduction.pod
+++ b/doc/man7/ossl-guide-tls-introduction.pod
@@ -74,7 +74,7 @@ TLSv1.2 is chosen.
 =head1 CERTIFICATES
 
 In order for a client to establish a connection to a server it must authenticate
-the identify of that server, i.e. it needs to confirm that the server is really
+the identity of that server, i.e. it needs to confirm that the server is really
 the server that it claims to be and not some imposter. In order to do this the
 server will send to the client a digital certificate (also commonly referred to
 as an X.509 certificate). The certificate contains various information about the
@@ -311,7 +311,7 @@ L<ossl-guide-tls-server-block(7)>, L<ossl-guide-quic-introduction(7)>
 
 =head1 COPYRIGHT
 
-Copyright 2023-2024 The OpenSSL Project Authors. All Rights Reserved.
+Copyright 2023-2025 The OpenSSL Project Authors. All Rights Reserved.
 
 Licensed under the Apache License 2.0 (the "License").  You may not use
 this file except in compliance with the License.  You can obtain a copy
diff --git a/doc/man7/provider-cipher.pod b/doc/man7/provider-cipher.pod
index 93fdcfb1c0fa..679c35e0f9ba 100644
--- a/doc/man7/provider-cipher.pod
+++ b/doc/man7/provider-cipher.pod
@@ -134,8 +134,8 @@ In order to be a consistent set of functions there must at least be a complete
 set of "encrypt" functions, or a complete set of "decrypt" functions, or a
 single "cipher" function. Similarly, there can be a complete set of pipeline
 "encrypt" functions, and/or a complete set of pipeline "decrypt" functions.
-In all cases both the OSSL_FUNC_cipher_newctx and OSSL_FUNC_cipher_freectx functions must be
-present.
+In all cases the OSSL_FUNC_cipher_get_params and both OSSL_FUNC_cipher_newctx
+and OSSL_FUNC_cipher_freectx functions must be present.
 All other functions are optional.
 
 =head2 Context Management Functions
diff --git a/doc/man7/provider-keymgmt.pod b/doc/man7/provider-keymgmt.pod
index f8235ac8a0af..420b7cdbfcda 100644
--- a/doc/man7/provider-keymgmt.pod
+++ b/doc/man7/provider-keymgmt.pod
@@ -32,7 +32,7 @@ provider-keymgmt - The KEYMGMT library E<lt>-E<gt> provider functions
  void OSSL_FUNC_keymgmt_gen_cleanup(void *genctx);
 
  /* Key loading by object reference, also a constructor */
- void *OSSL_FUNC_keymgmt_load(const void *reference, size_t *reference_sz);
+ void *OSSL_FUNC_keymgmt_load(const void *reference, size_t reference_sz);
 
  /* Key object information */
  int OSSL_FUNC_keymgmt_get_params(void *keydata, OSSL_PARAM params[]);
diff --git a/doc/man7/provider-signature.pod b/doc/man7/provider-signature.pod
index 203223cd6bde..61202b523640 100644
--- a/doc/man7/provider-signature.pod
+++ b/doc/man7/provider-signature.pod
@@ -107,8 +107,7 @@ for further information.
 The signature (OSSL_OP_SIGNATURE) operation enables providers to implement
 signature algorithms and make them available to applications via the API
 functions L<EVP_PKEY_sign(3)>, L<EVP_PKEY_verify(3)>,
-and L<EVP_PKEY_verify_recover(3)> (as well
-as other related functions).
+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 L<OSSL_DISPATCH(3)> arrays via
@@ -201,10 +200,22 @@ set of "signature" functions, i.e. at least one of:
 
 =back
 
-OSSL_FUNC_signature_set_ctx_params and OSSL_FUNC_signature_settable_ctx_params are optional,
-but if one of them is present then the other one must also be present. The same
-applies to OSSL_FUNC_signature_get_ctx_params and OSSL_FUNC_signature_gettable_ctx_params, as
-well as the "md_params" functions. The OSSL_FUNC_signature_dupctx function is optional.
+The OSSL_FUNC_signature_set_ctx_params() and
+OSSL_FUNC_signature_settable_ctx_params() functions are optional,
+but if one of them is provided then the other one must also be provided.
+The same applies to the OSSL_FUNC_signature_get_ctx_params() and
+OSSL_FUNC_signature_gettable_ctx_params() functions,
+as well as the "md_params" functions.
+
+The OSSL_FUNC_signature_dupctx() function is optional.
+It is not yet used by OpenSSL.
+
+The OSSL_FUNC_signature_query_key_types() function is optional.
+When present, it should return a NULL-terminated array of strings
+indicating the key types supported by the provider for signature operations.
+Otherwise the signature algorithm name must match the given key
+or match the default signature algorithm name of the key,
+both checked using L<EVP_SIGNATURE_is_a(3)>.
 
 A signature algorithm must also implement some mechanism for generating,
 loading or importing keys via the key management (OSSL_OP_KEYMGMT) operation.
@@ -378,7 +389,7 @@ should be written to I<*siglen>. If I<sig> is NULL then the maximum length of
 the signature should be written to I<*siglen>.
 
 OSSL_FUNC_signature_digest_sign() implements a "one shot" digest sign operation
-previously started through OSSL_FUNC_signature_digeset_sign_init(). A previously
+previously started through OSSL_FUNC_signature_digest_sign_init(). A previously
 initialised signature context is passed in the I<ctx> parameter. The data to be
 signed is in I<tbs> which should be I<tbslen> bytes long. Unless I<sig> is NULL,
 the signature should be written to the location pointed to by the I<sig>
@@ -388,7 +399,7 @@ length of the signature should be written to I<*siglen>.
 
 =head2 Digest Verify Functions
 
-OSSL_FUNC_signature_digeset_verify_init() initialises a context for verifying given a
+OSSL_FUNC_signature_digest_verify_init() initialises a context for verifying given a
 provider side verification context in the I<ctx> parameter, and a pointer to a
 provider key object in the I<provkey> parameter.
 The I<params>, if not NULL, should be set on the context in a manner similar to
@@ -412,7 +423,7 @@ verification context is passed in the I<ctx> parameter. The signature to be
 verified is in I<sig> which is I<siglen> bytes long.
 
 OSSL_FUNC_signature_digest_verify() implements a "one shot" digest verify operation
-previously started through OSSL_FUNC_signature_digeset_verify_init(). A previously
+previously started through OSSL_FUNC_signature_digest_verify_init(). A previously
 initialised verification context is passed in the I<ctx> parameter. The data to be
 verified is in I<tbs> which should be I<tbslen> bytes long. The signature to be
 verified is in I<sig> which is I<siglen> bytes long.
@@ -470,8 +481,13 @@ The length of the "digest-size" parameter should not exceed that of a B<size_t>.
 
 =item "algorithm-id" (B<OSSL_SIGNATURE_PARAM_ALGORITHM_ID>) <octet string>
 
-Gets the DER encoded AlgorithmIdentifier that corresponds to the combination of
-signature algorithm and digest algorithm for the signature operation.
+Gets the DER-encoded AlgorithmIdentifier for the signature operation.
+This typically corresponds to the combination of a digest algorithm
+with a purely asymmetric signature algorithm, such as SHA256WithECDSA.
+
+The L<ASN1_item_sign_ctx(3)> function relies on this operation and is used by
+many other functions that sign ASN.1 structures such as X.509 certificates,
+certificate requests, and CRLs, as well as OCSP, CMP, and CMS messages.
 
 =item "nonce-type" (B<OSSL_SIGNATURE_PARAM_NONCE_TYPE>) <unsigned integer>
 
@@ -599,11 +615,20 @@ OSSL_FUNC_signature_gettable_ctx_params(), OSSL_FUNC_signature_settable_ctx_para
 OSSL_FUNC_signature_gettable_md_ctx_params() and OSSL_FUNC_signature_settable_md_ctx_params(),
 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.
+OSSL_FUNC_signature_query_key_types() should return a NULL-terminated array of strings.
+
+All verification functions should return 1 for success,
+0 for a non-matching signature, and a negative value for operation failure.
+
+All other functions should return 1 for success
+and 0 or a negative value for failure.
 
 =head1 SEE ALSO
 
-L<provider(7)>
+L<provider(7)>, L<provider-base(7)/Provider Functions>,
+L<OSSL_PARAM(3)>, L<OSSL_DISPATCH(3)>, L<OSSL_ALGORITHM(3)>,
+L<EVP_PKEY_sign(3)>, L<EVP_PKEY_verify(3)>, L<EVP_PKEY_verify_recover(3)>,
+L<EVP_SIGNATURE_is_a(3)>, L<ASN1_item_sign_ctx(3)>
 
 =head1 HISTORY