21 files changed, 173 insertions, 25 deletions
diff --git a/doc/man7/EVP_KDF-HKDF.pod b/doc/man7/EVP_KDF-HKDF.pod
index 5fc0a73241cc..b563efa5f5d7 100644
--- a/doc/man7/EVP_KDF-HKDF.pod
+++ b/doc/man7/EVP_KDF-HKDF.pod
@@ -15,6 +15,8 @@ and "extracts" from it a fixed-length pseudorandom key K. The second stage
 "expands" the key K into several additional pseudorandom keys (the output
 of the KDF).
 
+The output is considered to be keying material.
+
 =head2 Identity
 
 "HKDF" is the name for this implementation; it
diff --git a/doc/man7/EVP_KDF-KB.pod b/doc/man7/EVP_KDF-KB.pod
index 6e25882d674c..78b81673a5bd 100644
--- a/doc/man7/EVP_KDF-KB.pod
+++ b/doc/man7/EVP_KDF-KB.pod
@@ -10,6 +10,8 @@ The EVP_KDF-KB algorithm implements the Key-Based key derivation function
 (KBKDF).  KBKDF derives a key from repeated application of a keyed MAC to an
 input secret (and other optional values).
 
+The output is considered to be keying material.
+
 =head2 Identity
 
 "KBKDF" is the name for this implementation; it can be used with the
diff --git a/doc/man7/EVP_KDF-PBKDF2.pod b/doc/man7/EVP_KDF-PBKDF2.pod
index e6cadc8b826d..9a90f7583abe 100644
--- a/doc/man7/EVP_KDF-PBKDF2.pod
+++ b/doc/man7/EVP_KDF-PBKDF2.pod
@@ -13,6 +13,8 @@ The EVP_KDF-PBKDF2 algorithm implements the PBKDF2 password-based key
 derivation function, as described in SP800-132; it derives a key from a password
 using a salt and iteration count.
 
+The output is considered to be a cryptographic key.
+
 =head2 Identity
 
 "PBKDF2" is the name for this implementation; it
diff --git a/doc/man7/EVP_KDF-SS.pod b/doc/man7/EVP_KDF-SS.pod
index c8d19691a797..6640703eef1c 100644
--- a/doc/man7/EVP_KDF-SS.pod
+++ b/doc/man7/EVP_KDF-SS.pod
@@ -11,6 +11,8 @@ SSKDF derives a key using input such as a shared secret key (that was generated
 during the execution of a key establishment scheme) and fixedinfo.
 SSKDF is also informally referred to as 'Concat KDF'.
 
+The output is considered to be keying material.
+
 =head2 Auxiliary function
 
 The implementation uses a selectable auxiliary function H, which can be one of:
diff --git a/doc/man7/EVP_KDF-SSHKDF.pod b/doc/man7/EVP_KDF-SSHKDF.pod
index c7a3263f455a..a5b153947558 100644
--- a/doc/man7/EVP_KDF-SSHKDF.pod
+++ b/doc/man7/EVP_KDF-SSHKDF.pod
@@ -15,6 +15,8 @@ Five inputs are required to perform key derivation: The hashing function
 (for example SHA256), the Initial Key, the Exchange Hash, the Session ID,
 and the derivation key type.
 
+The output is considered to be keying material.
+
 =head2 Identity
 
 "SSHKDF" is the name for this implementation; it
diff --git a/doc/man7/EVP_KDF-TLS13_KDF.pod b/doc/man7/EVP_KDF-TLS13_KDF.pod
index d588b121faf5..7fad55ca61f1 100644
--- a/doc/man7/EVP_KDF-TLS13_KDF.pod
+++ b/doc/man7/EVP_KDF-TLS13_KDF.pod
@@ -12,6 +12,8 @@ the B<EVP_KDF> API.
 The EVP_KDF-TLS13_KDF algorithm implements the HKDF key derivation function
 as used by TLS 1.3.
 
+The output is considered to be keying material.
+
 =head2 Identity
 
 "TLS13-KDF" is the name for this implementation; it
diff --git a/doc/man7/EVP_KDF-TLS1_PRF.pod b/doc/man7/EVP_KDF-TLS1_PRF.pod
index 8a60e9731554..90b357e70f0b 100644
--- a/doc/man7/EVP_KDF-TLS1_PRF.pod
+++ b/doc/man7/EVP_KDF-TLS1_PRF.pod
@@ -11,6 +11,8 @@ Support for computing the B<TLS1> PRF through the B<EVP_KDF> API.
 The EVP_KDF-TLS1_PRF algorithm implements the PRF used by TLS versions up to
 and including TLS 1.2.
 
+The output is considered to be keying material.
+
 =head2 Identity
 
 "TLS1-PRF" is the name for this implementation; it
diff --git a/doc/man7/EVP_KDF-X942-ASN1.pod b/doc/man7/EVP_KDF-X942-ASN1.pod
index a5786ab83faa..17464738b511 100644
--- a/doc/man7/EVP_KDF-X942-ASN1.pod
+++ b/doc/man7/EVP_KDF-X942-ASN1.pod
@@ -13,6 +13,8 @@ contains a 32 bit counter as well as optional fields for "partyu-info",
 "partyv-info", "supp-pubinfo" and "supp-privinfo".
 This kdf is used by Cryptographic Message Syntax (CMS).
 
+The output is considered to be keying material.
+
 =head2 Identity
 
 "X942KDF-ASN1" or "X942KDF" is the name for this implementation; it
diff --git a/doc/man7/EVP_KDF-X963.pod b/doc/man7/EVP_KDF-X963.pod
index 3d6f4372cf31..ca2f7c1df0ef 100644
--- a/doc/man7/EVP_KDF-X963.pod
+++ b/doc/man7/EVP_KDF-X963.pod
@@ -10,6 +10,8 @@ The EVP_KDF-X963 algorithm implements the key derivation function (X963KDF).
 X963KDF is used by Cryptographic Message Syntax (CMS) for EC KeyAgreement, to
 derive a key using input such as a shared secret key and shared info.
 
+The output is considered to be keying material.
+
 =head2 Identity
 
 "X963KDF" is the name for this implementation; it
diff --git a/doc/man7/EVP_PKEY-DSA.pod b/doc/man7/EVP_PKEY-DSA.pod
index cdafc0edad5c..54619553f927 100644
--- a/doc/man7/EVP_PKEY-DSA.pod
+++ b/doc/man7/EVP_PKEY-DSA.pod
@@ -104,7 +104,7 @@ The following sections of FIPS186-4:
 =head1 SEE ALSO
 
 L<EVP_PKEY-FFC(7)>,
-L<EVP_SIGNATURE-DSA(7)>
+L<EVP_SIGNATURE-DSA(7)>,
 L<EVP_PKEY(3)>,
 L<provider-keymgmt(7)>,
 L<EVP_KEYMGMT(3)>,
@@ -113,7 +113,7 @@ L<OSSL_PROVIDER-FIPS(7)>
 
 =head1 COPYRIGHT
 
-Copyright 2020-2022 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/man7/EVP_PKEY-FFC.pod b/doc/man7/EVP_PKEY-FFC.pod
index 0b96bc24a614..a28bb84e0a36 100644
--- a/doc/man7/EVP_PKEY-FFC.pod
+++ b/doc/man7/EVP_PKEY-FFC.pod
@@ -213,7 +213,7 @@ The following sections of FIPS186-4:
 L<EVP_PKEY-DSA(7)>,
 L<EVP_PKEY-DH(7)>,
 L<EVP_SIGNATURE-DSA(7)>,
-L<EVP_KEYEXCH-DH(7)>
+L<EVP_KEYEXCH-DH(7)>,
 L<EVP_KEYMGMT(3)>,
 L<EVP_PKEY(3)>,
 L<provider-keymgmt(7)>,
@@ -222,7 +222,7 @@ L<OSSL_PROVIDER-FIPS(7)>,
 
 =head1 COPYRIGHT
 
-Copyright 2020-2022 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/man7/EVP_SIGNATURE-DSA.pod b/doc/man7/EVP_SIGNATURE-DSA.pod
index 5a42d6b1cd22..326a86ee0b42 100644
--- a/doc/man7/EVP_SIGNATURE-DSA.pod
+++ b/doc/man7/EVP_SIGNATURE-DSA.pod
@@ -7,7 +7,9 @@ EVP_SIGNATURE-DSA
 
 =head1 DESCRIPTION
 
-Support for computing DSA signatures.
+Support for computing DSA signatures. The signature produced with
+L<EVP_PKEY_sign(3)> is DER encoded ASN.1 in the form described in
+RFC 3279, section 2.2.2.
 See L<EVP_PKEY-DSA(7)> for information related to DSA keys.
 
 =head2 Signature Parameters
diff --git a/doc/man7/OSSL_PROVIDER-FIPS.pod b/doc/man7/OSSL_PROVIDER-FIPS.pod
index 66165bdb0cc3..eb34a34a152c 100644
--- a/doc/man7/OSSL_PROVIDER-FIPS.pod
+++ b/doc/man7/OSSL_PROVIDER-FIPS.pod
@@ -421,6 +421,19 @@ validated versions alongside F<libcrypto> and F<libssl> compiled from any
 release within the same major release series.  This flexibility enables
 you to address bug fixes and CVEs that fall outside the FIPS boundary.
 
+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)>,
@@ -439,7 +452,7 @@ This functionality 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/man7/migration_guide.pod b/doc/man7/migration_guide.pod
index e5ab29b95370..b223f856d17d 100644
--- a/doc/man7/migration_guide.pod
+++ b/doc/man7/migration_guide.pod
@@ -596,13 +596,13 @@ The code needs to be amended to look like this:
 Support for TLSv1.3 has been added.
 
 This has a number of implications for SSL/TLS applications. See the
-L<TLS1.3 page|https://wiki.openssl.org/index.php/TLS1.3> for further details.
+L<TLS1.3 page|https://github.com/openssl/openssl/wiki/TLS1.3> for further details.
 
 =back
 
 More details about the breaking changes between OpenSSL versions 1.0.2 and 1.1.0
 can be found on the
-L<OpenSSL 1.1.0 Changes page|https://wiki.openssl.org/index.php/OpenSSL_1.1.0_Changes>.
+L<OpenSSL 1.1.0 Changes page|https://github.com/openssl/openssl/wiki/OpenSSL_1.1.0_Changes>.
 
 =head3 Upgrading from the OpenSSL 2.0 FIPS Object Module
 
@@ -2484,7 +2484,7 @@ The migration guide was created for OpenSSL 3.0.
 
 =head1 COPYRIGHT
 
-Copyright 2021-2024 The OpenSSL Project Authors. All Rights Reserved.
+Copyright 2021-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/openssl-env.pod b/doc/man7/openssl-env.pod
index a2443d54d822..c7dbd2277dc6 100644
--- a/doc/man7/openssl-env.pod
+++ b/doc/man7/openssl-env.pod
@@ -51,6 +51,99 @@ See L<OPENSSL_malloc(3)>.
 Specifies the directory from which cryptographic providers are loaded.
 Equivalently, the generic B<-provider-path> command-line option may be used.
 
+=item B<OPENSSL_TRACE>
+
+By default the OpenSSL trace feature is disabled statically.
+To enable it, OpenSSL must be built with tracing support,
+which may be configured like this: C<./config enable-trace>
+
+Unless OpenSSL tracing support is generally disabled,
+enable trace output of specific parts of OpenSSL libraries, by name.
+This output usually makes sense only if you know OpenSSL internals well.
+
+The value of this environment varialble is a comma-separated list of names,
+with the following available:
+
+=over 4
+
+=item B<TRACE>
+
+Traces the OpenSSL trace API itself.
+
+=item B<INIT>
+
+Traces OpenSSL library initialization and cleanup.
+
+=item B<TLS>
+
+Traces the TLS/SSL protocol.
+
+=item B<TLS_CIPHER>
+
+Traces the ciphers used by the TLS/SSL protocol.
+
+=item B<CONF>
+
+Show details about provider and engine configuration.
+
+=item B<ENGINE_TABLE>
+
+The function that is used by RSA, DSA (etc) code to select registered
+ENGINEs, cache defaults and functional references (etc), will generate
+debugging summaries.
+
+=item B<ENGINE_REF_COUNT>
+
+Reference counts in the ENGINE structure will be monitored with a line
+of generated for each change.
+
+=item B<PKCS5V2>
+
+Traces PKCS#5 v2 key generation.
+
+=item B<PKCS12_KEYGEN>
+
+Traces PKCS#12 key generation.
+
+=item B<PKCS12_DECRYPT>
+
+Traces PKCS#12 decryption.
+
+=item B<X509V3_POLICY>
+
+Generates the complete policy tree at various points during X.509 v3
+policy evaluation.
+
+=item B<BN_CTX>
+
+Traces BIGNUM context operations.
+
+=item B<CMP>
+
+Traces CMP client and server activity.
+
+=item B<STORE>
+
+Traces STORE operations.
+
+=item B<DECODER>
+
+Traces decoder operations.
+
+=item B<ENCODER>
+
+Traces encoder operations.
+
+=item B<REF_COUNT>
+
+Traces decrementing certain ASN.1 structure references.
+
+=item B<HTTP>
+
+Traces the HTTP client and server, such as messages being sent and received.
+
+=back
+
 =item B<OPENSSL_WIN32_UTF8>
 
 If set, then L<UI_OpenSSL(3)> returns UTF-8 encoded strings, rather than
diff --git a/doc/man7/provider-cipher.pod b/doc/man7/provider-cipher.pod
index eaad3cf2ff02..c5d40a223acf 100644
--- a/doc/man7/provider-cipher.pod
+++ b/doc/man7/provider-cipher.pod
@@ -103,8 +103,8 @@ A cipher algorithm implementation may not implement all of these functions.
 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.
-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
@@ -241,7 +241,7 @@ The provider CIPHER interface was 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/man7/provider-decoder.pod b/doc/man7/provider-decoder.pod
index e968e661f7cf..d19deec4af5b 100644
--- a/doc/man7/provider-decoder.pod
+++ b/doc/man7/provider-decoder.pod
@@ -110,7 +110,9 @@ it decodes. For example, an implementation that decodes an RSA key
 should be named "RSA". Likewise, an implementation that decodes DER data
 from PEM input should be named "DER".
 
-Properties can be used to further specify details about an implementation:
+Properties, as defined in the L<OSSL_ALGORITHM(3)> array element of each
+decoder implementation, can be used to further specify details about an
+implementation:
 
 =over 4
 
@@ -302,7 +304,7 @@ The DECODER interface was 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/man7/provider-encoder.pod b/doc/man7/provider-encoder.pod
index f3e9ce5b1632..dadd33f9b0f6 100644
--- a/doc/man7/provider-encoder.pod
+++ b/doc/man7/provider-encoder.pod
@@ -127,7 +127,9 @@ The name of an implementation should match the type of object it handles.
 For example, an implementation that encodes an RSA key should be named "RSA".
 Likewise, an implementation that further encodes DER should be named "DER".
 
-Properties can be used to further specify details about an implementation:
+Properties, as defined in the L<OSSL_ALGORITHM(3)> array element of each
+decoder implementation, can be used to further specify details about an
+implementation:
 
 =over 4
 
@@ -321,7 +323,7 @@ The ENCODER interface was introduced in OpenSSL 3.0.
 
 =head1 COPYRIGHT
 
-Copyright 2019-2021 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/man7/provider-keymgmt.pod b/doc/man7/provider-keymgmt.pod
index 498ad9c4e107..8596b696c69f 100644
--- a/doc/man7/provider-keymgmt.pod
+++ b/doc/man7/provider-keymgmt.pod
@@ -29,7 +29,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[]);
@@ -442,7 +442,7 @@ The KEYMGMT interface was introduced in OpenSSL 3.0.
 
 =head1 COPYRIGHT
 
-Copyright 2019-2024 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/man7/provider-signature.pod b/doc/man7/provider-signature.pod
index 1a9859eac367..05040ee39914 100644
--- a/doc/man7/provider-signature.pod
+++ b/doc/man7/provider-signature.pod
@@ -284,7 +284,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>
@@ -294,7 +294,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
@@ -318,7 +318,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.
@@ -360,8 +360,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)> relies on this operation and is used by
+many other functions signing ASN.1 structures such as X.509 certificates,
+certificate requests, and CRLs, as well as OCSP, CMP, and CMS messages.
 
 =item "kat" (B<OSSL_SIGNATURE_PARAM_KAT>) <unsigned integer>
 
@@ -421,7 +426,8 @@ All other functions should return 1 for success or 0 on error.
 
 =head1 SEE ALSO
 
-L<provider(7)>
+L<provider(7)>,
+L<ASN1_item_sign_ctx(3)>
 
 =head1 HISTORY
 
@@ -429,7 +435,7 @@ The provider SIGNATURE interface was 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/man7/provider.pod b/doc/man7/provider.pod
index a061fc4709d0..08ac1d02907f 100644
--- a/doc/man7/provider.pod
+++ b/doc/man7/provider.pod
@@ -227,6 +227,18 @@ MODE is only present where applicable.
 Other aliases may exist for example where standards bodies or common practice
 use alternative names or names that OpenSSL has used historically.
 
+=head3 Provider dependencies
+
+Providers may depend for their proper operation on the availability of
+(functionality implemented in) other providers. As there is no mechanism to
+express such dependencies towards the OpenSSL core, provider authors must
+take care that such dependencies are either completely avoided or made visible
+to users, e.g., by documentation and/or defensive programming, e.g.,
+outputting error messages if required external dependencies are not available,
+e.g., when no provider implementing the required functionality has been
+activated. In particular, provider initialization should not depend on other
+providers already having been initialized.
+
 =head1 OPENSSL PROVIDERS
 
 OpenSSL provides a number of its own providers. These are the default, base,