aboutsummaryrefslogtreecommitdiff
path: root/doc/man7
diff options
context:
space:
mode:
Diffstat (limited to 'doc/man7')
-rw-r--r--doc/man7/EVP_PKEY-EC.pod6
-rw-r--r--doc/man7/EVP_PKEY-RSA.pod2
-rw-r--r--doc/man7/OSSL_PROVIDER-FIPS.pod16
-rw-r--r--doc/man7/crypto.pod2
-rw-r--r--doc/man7/fips_module.pod23
-rw-r--r--doc/man7/life_cycle-pkey.pod6
-rw-r--r--doc/man7/migration_guide.pod8
-rw-r--r--doc/man7/openssl-glossary.pod8
-rw-r--r--doc/man7/provider-kdf.pod4
-rw-r--r--doc/man7/provider-object.pod4
10 files changed, 55 insertions, 24 deletions
diff --git a/doc/man7/EVP_PKEY-EC.pod b/doc/man7/EVP_PKEY-EC.pod
index 4b6dec35862c..3b14e256721b 100644
--- a/doc/man7/EVP_PKEY-EC.pod
+++ b/doc/man7/EVP_PKEY-EC.pod
@@ -15,7 +15,7 @@ The B<EC> keytype is implemented in OpenSSL's default provider.
The normal way of specifying domain parameters for an EC curve is via the
curve name "group". For curves with no curve name, explicit parameters can be
used that specify "field-type", "p", "a", "b", "generator" and "order".
-Explicit parameters are supported for backwards compability reasons, but they
+Explicit parameters are supported for backwards compatibility reasons, but they
are not compliant with multiple standards (including RFC5915) which only allow
named curves.
@@ -70,7 +70,7 @@ I<order> multiplied by the I<cofactor> gives the number of points on the curve.
=item "decoded-from-explicit" (B<OSSL_PKEY_PARAM_EC_DECODED_FROM_EXPLICIT_PARAMS>) <integer>
-Gets a flag indicating wether the key or parameters were decoded from explicit
+Gets a flag indicating whether the key or parameters were decoded from explicit
curve parameters. Set to 1 if so or 0 if a named curve was used.
=item "use-cofactor-flag" (B<OSSL_PKEY_PARAM_USE_COFACTOR_ECDH>) <integer>
@@ -99,7 +99,7 @@ point_conversion_forms please see L<EC_POINT_new(3)>. Valid values are
Sets or Gets the type of group check done when EVP_PKEY_param_check() is called.
Valid values are "default", "named" and "named-nist".
The "named" type checks that the domain parameters match the inbuilt curve parameters,
-"named-nist" is similiar but also checks that the named curve is a nist curve.
+"named-nist" is similar but also checks that the named curve is a nist curve.
The "default" type does domain parameter validation for the OpenSSL default provider,
but is equivalent to "named-nist" for the OpenSSL FIPS provider.
diff --git a/doc/man7/EVP_PKEY-RSA.pod b/doc/man7/EVP_PKEY-RSA.pod
index f1141a364b86..161e9d4d71d1 100644
--- a/doc/man7/EVP_PKEY-RSA.pod
+++ b/doc/man7/EVP_PKEY-RSA.pod
@@ -189,7 +189,7 @@ both return 1 unconditionally.
For RSA keys, L<EVP_PKEY_public_check(3)> conforms to the SP800-56Br1 I<public key
check> when the OpenSSL FIPS provider is used. The OpenSSL default provider
-performs similiar tests but relaxes the keysize restrictions for backwards
+performs similar tests but relaxes the keysize restrictions for backwards
compatibility.
For RSA keys, L<EVP_PKEY_public_check_quick(3)> is the same as
diff --git a/doc/man7/OSSL_PROVIDER-FIPS.pod b/doc/man7/OSSL_PROVIDER-FIPS.pod
index 2f34866d998b..66165bdb0cc3 100644
--- a/doc/man7/OSSL_PROVIDER-FIPS.pod
+++ b/doc/man7/OSSL_PROVIDER-FIPS.pod
@@ -408,6 +408,19 @@ A simple self test callback is shown below for illustrative purposes.
return ret;
}
+=head1 NOTES
+
+Some released versions of OpenSSL do not include a validated
+FIPS provider. To determine which versions have undergone
+the validation process, please refer to the
+L<OpenSSL Downloads page|https://www.openssl.org/source/>. If you
+require FIPS-approved functionality, it is essential to build your FIPS
+provider using one of the validated versions listed there. Normally,
+it is possible to utilize a FIPS provider constructed from one of the
+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.
+
=head1 SEE ALSO
L<openssl-fipsinstall(1)>,
@@ -417,7 +430,8 @@ L<OSSL_SELF_TEST_new(3)>,
L<OSSL_PARAM(3)>,
L<openssl-core.h(7)>,
L<openssl-core_dispatch.h(7)>,
-L<provider(7)>
+L<provider(7)>,
+L<https://www.openssl.org/source/>
=head1 HISTORY
diff --git a/doc/man7/crypto.pod b/doc/man7/crypto.pod
index ea81c91d3aff..c31e10ac29a5 100644
--- a/doc/man7/crypto.pod
+++ b/doc/man7/crypto.pod
@@ -207,7 +207,7 @@ If anything in this step fails, the next step is used as a fallback.
As a fallback, try to fetch the operation type implementation from the same
provider as the original L<EVP_PKEY(3)>'s L<EVP_KEYMGMT(3)>, still using the
-propery string from the B<EVP_PKEY_CTX>.
+property string from the B<EVP_PKEY_CTX>.
=back
diff --git a/doc/man7/fips_module.pod b/doc/man7/fips_module.pod
index b1d67ca61b43..d0861a9dcecc 100644
--- a/doc/man7/fips_module.pod
+++ b/doc/man7/fips_module.pod
@@ -14,6 +14,9 @@ This guide details different ways that OpenSSL can be used in conjunction
with the FIPS module. Which is the correct approach to use will depend on your
own specific circumstances and what you are attempting to achieve.
+For information related to installing the FIPS module see
+L<https://github.com/openssl/openssl/blob/master/README-FIPS.md>.
+
Note that the old functions FIPS_mode() and FIPS_mode_set() are no longer
present so you must remove them from your application if you use them.
@@ -92,7 +95,7 @@ Obviously the include file location above should match the path and name of the
FIPS module config file that you installed earlier.
See L<https://github.com/openssl/openssl/blob/master/README-FIPS.md>.
-For FIPS usage, it is recommened that the B<config_diagnostics> option is
+For FIPS usage, it is recommended that the B<config_diagnostics> option is
enabled to prevent accidental use of non-FIPS validated algorithms via broken
or mistaken configuration. See L<config(5)>.
@@ -456,9 +459,23 @@ use L<EVP_MD_get0_provider(3)>.
To extract the name from the B<OSSL_PROVIDER>, use
L<OSSL_PROVIDER_get0_name(3)>.
+=head1 NOTES
+
+Some released versions of OpenSSL do not include a validated
+FIPS provider. To determine which versions have undergone
+the validation process, please refer to the
+L<OpenSSL Downloads page|https://www.openssl.org/source/>. If you
+require FIPS-approved functionality, it is essential to build your FIPS
+provider using one of the validated versions listed there. Normally,
+it is possible to utilize a FIPS provider constructed from one of the
+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.
+
=head1 SEE ALSO
-L<migration_guide(7)>, L<crypto(7)>, L<fips_config(5)>
+L<migration_guide(7)>, L<crypto(7)>, L<fips_config(5)>,
+L<https://www.openssl.org/source/>
=head1 HISTORY
@@ -467,7 +484,7 @@ in OpenSSL 3.0.
=head1 COPYRIGHT
-Copyright 2021-2022 The OpenSSL Project Authors. All Rights Reserved.
+Copyright 2021-2023 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/life_cycle-pkey.pod b/doc/man7/life_cycle-pkey.pod
index 6768750f4819..a9dc06b934d5 100644
--- a/doc/man7/life_cycle-pkey.pod
+++ b/doc/man7/life_cycle-pkey.pod
@@ -22,7 +22,7 @@ This state represents the PKEY after it has been allocated.
=item decapsulate
This state represents the PKEY when it is ready to perform a private key decapsulation
-opeartion.
+operation.
=item decrypt
@@ -40,7 +40,7 @@ operation.
=item encapsulate
This state represents the PKEY when it is ready to perform a public key encapsulation
-opeartion.
+operation.
=item encrypt
@@ -703,7 +703,7 @@ The provider PKEY interface was introduced in OpenSSL 3.0.
=head1 COPYRIGHT
-Copyright 2021 The OpenSSL Project Authors. All Rights Reserved.
+Copyright 2021-2023 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 9eb4a031aa32..1847e9813cbb 100644
--- a/doc/man7/migration_guide.pod
+++ b/doc/man7/migration_guide.pod
@@ -130,7 +130,7 @@ New algorithms provided via engines will still work.
Engine-backed keys can be loaded via custom B<OSSL_STORE> implementation.
In this case the B<EVP_PKEY> objects created via L<ENGINE_load_private_key(3)>
-will be concidered legacy and will continue to work.
+will be considered legacy and will continue to work.
To ensure the future compatibility, the engines should be turned to providers.
To prefer the provider-based hardware offload, you can specify the default
@@ -641,7 +641,7 @@ set up with the default library context. Use L<X509_new_ex(3)>,
L<X509_CRL_new_ex(3)>, L<X509_REQ_new_ex(3)> and L<X509_PUBKEY_new_ex(3)> if a
library context is required.
-All functions listed below with a I<NAME> have a replacment function I<NAME_ex>
+All functions listed below with a I<NAME> have a replacement function I<NAME_ex>
that takes B<OSSL_LIB_CTX> as an additional argument. Functions that have other
mappings are listed along with the respective name.
@@ -999,7 +999,7 @@ that refer to these categories.
Any accessor that uses an ENGINE is deprecated (such as EVP_PKEY_set1_engine()).
Applications using engines should instead use providers.
-Before providers were added algorithms were overriden by changing the methods
+Before providers were added algorithms were overridden by changing the methods
used by algorithms. All these methods such as RSA_new_method() and RSA_meth_new()
are now deprecated and can be replaced by using providers instead.
@@ -1548,7 +1548,7 @@ See L</Deprecated low-level validation functions>
EC_KEY_set_flags(), EC_KEY_get_flags(), EC_KEY_clear_flags()
-See L<EVP_PKEY-EC(7)/Common EC parameters> which handles flags as seperate
+See L<EVP_PKEY-EC(7)/Common EC parameters> which handles flags as separate
parameters for B<OSSL_PKEY_PARAM_EC_POINT_CONVERSION_FORMAT>,
B<OSSL_PKEY_PARAM_EC_GROUP_CHECK_TYPE>, B<OSSL_PKEY_PARAM_EC_ENCODING>,
B<OSSL_PKEY_PARAM_USE_COFACTOR_ECDH> and
diff --git a/doc/man7/openssl-glossary.pod b/doc/man7/openssl-glossary.pod
index b112b375ac20..54c8de93a058 100644
--- a/doc/man7/openssl-glossary.pod
+++ b/doc/man7/openssl-glossary.pod
@@ -12,7 +12,7 @@ openssl-glossary - An OpenSSL Glossary
=item Algorithm
-Cryptograpic primitives such as the SHA256 digest, or AES encryption are
+Cryptographic primitives such as the SHA256 digest, or AES encryption are
referred to in OpenSSL as "algorithms". There can be more than one
implementation for any given algorithm available for use.
@@ -45,7 +45,7 @@ L<OSSL_DECODER_CTX_new_for_pkey(3)>
=item Default Provider
-An OpenSSL Provider that contains the most commmon OpenSSL algorithm
+An OpenSSL Provider that contains the most common OpenSSL algorithm
implementations. It is loaded by default if no other provider is available. All
the algorithm implementations in the Base Provider are also available in the
Default Provider.
@@ -81,7 +81,7 @@ Fetching is the process of looking through the available algorithm
implementations, applying selection criteria (via a property query string), and
finally choosing the implementation that will be used.
-Also see Explicit Fetching and Implict Fetching.
+Also see Explicit Fetching and Implicit Fetching.
L<crypto(7)>
@@ -221,7 +221,7 @@ This glossary was added in OpenSSL 3.0.
=head1 COPYRIGHT
-Copyright 2020-2021 The OpenSSL Project Authors. All Rights Reserved.
+Copyright 2020-2023 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-kdf.pod b/doc/man7/provider-kdf.pod
index ad80869ebea7..51362a7cccdc 100644
--- a/doc/man7/provider-kdf.pod
+++ b/doc/man7/provider-kdf.pod
@@ -198,7 +198,7 @@ Sets the mode in the associated KDF ctx.
=item "pkcs5" (B<OSSL_KDF_PARAM_PKCS5>) <integer>
-Enables or diables the SP800-132 compliance checks.
+Enables or disables the SP800-132 compliance checks.
A mode of 0 enables the compliance checks.
The checks performed are:
@@ -349,7 +349,7 @@ The provider KDF interface was introduced in OpenSSL 3.0.
=head1 COPYRIGHT
-Copyright 2020-2022 The OpenSSL Project Authors. All Rights Reserved.
+Copyright 2020-2023 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-object.pod b/doc/man7/provider-object.pod
index 1088e035510f..022d14d768fb 100644
--- a/doc/man7/provider-object.pod
+++ b/doc/man7/provider-object.pod
@@ -164,7 +164,7 @@ A human readable text that describes extra details on the object.
=back
-When a provider-native object abtraction is used, it I<must> contain object
+When a provider-native object abstraction is used, it I<must> contain object
data in at least one form (object data I<passed by value>, i.e. the "data"
item, or object data I<passed by reference>, i.e. the "reference" item).
Both may be present at once, in which case the OpenSSL library code that
@@ -184,7 +184,7 @@ introduced in OpenSSL 3.0.
=head1 COPYRIGHT
-Copyright 2020-2021 The OpenSSL Project Authors. All Rights Reserved.
+Copyright 2020-2023 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