Fix new typos found by codespell in documentation

Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21322)

3 files changed, 6 insertions, 6 deletions

diff --git a/doc/designs/fast-param-find.md b/doc/designs/fast-param-find.md
index 02460ce4bd..c69a39aeac 100644
--- a/doc/designs/fast-param-find.md
+++ b/doc/designs/fast-param-find.md
@@ -102,10 +102,10 @@ THe top level attributes are:
   will be appended _[gs]et[_ctx]_params
 - "functions" is the functions to generate.  By default both setters and
   getters but either can be omitted.
-- "prologue" defines some introductory code emited in the generated functions.
+- "prologue" defines some introductory code emitted in the generated functions.
   Function arguments are: `void *vctx, OSSL_PARAM params[]` and this
   can be used to specialise the void pointer or declare locals.
-- "epilogue" defines some post decode code emited in the generated function
+- "epilogue" defines some post decode code emitted in the generated function
 - "params" defines the parameters both gettable and settable
 
 Within the "params" the fields specify each parameter by label.
diff --git a/doc/designs/quic-design/quic-api-ssl-funcs.md b/doc/designs/quic-design/quic-api-ssl-funcs.md
index da0eefaf47..6ff536b845 100644
--- a/doc/designs/quic-design/quic-api-ssl-funcs.md
+++ b/doc/designs/quic-design/quic-api-ssl-funcs.md
@@ -835,7 +835,7 @@ Q&A For TLS-Related Calls
 QUIC always uses AES-128-GCM for Initial packets. At this time the handshake
 layer has not negotiated a ciphersuite so it has no “current” cipher. We could
 return AES-128-GCM here, but it seems reasonable to just return NULL as the
-encryption is mostly for protection against accidential modification and not
+encryption is mostly for protection against accidental modification and not
 “real” encryption. From the perspective of the Handshake layer encryption is not
 active yet. An application using QUIC can always interpret NULL as meaning
 AES-128-GCM is being used if needed as this is implied by using QUIC.
diff --git a/doc/designs/quic-design/quic-api.md b/doc/designs/quic-design/quic-api.md
index 2317f54c44..c3d21514ad 100644
--- a/doc/designs/quic-design/quic-api.md
+++ b/doc/designs/quic-design/quic-api.md
@@ -433,7 +433,7 @@ Should not require any changes.
 | New       | Never         | Yes       | CS            |
 
 Advances the QUIC state machine to the extent feasible, potentially performing
-network I/O. Also compatible with DTLSv1 and supercedes `DTLSv1_handle_timeout`
+network I/O. Also compatible with DTLSv1 and supersedes `DTLSv1_handle_timeout`
 for all use cases.
 
 #### `SSL_get_event_timeout`
@@ -447,7 +447,7 @@ event, if any.
 
 This is similar to the existing `DTLSv1_get_timeout` function, but it is not
 specific to DTLSv1. It is also usable for DTLSv1 and can become a
-protocol-agnostic API for this purpose, superceding `DTLSv1_get_timeout` for all
+protocol-agnostic API for this purpose, superseding `DTLSv1_get_timeout` for all
 use cases.
 
 The design is similar to that of `DTLSv1_get_timeout` and uses a `struct
@@ -1617,7 +1617,7 @@ initial call to `SSL_read` implying use of a remotely-initiated stream. However,
 this would mean we are creating state tracking a remotely-initiated stream
 before the peer has signalled it. This would work in the happy case where the
 client is connected to a compatible server but may result in strange
-inconsistencies of QUIC internal state if a client is accidentially connected to
+inconsistencies of QUIC internal state if a client is accidentally connected to
 an incompatible peer. Since the peer ought to be the authority on the streams it
 creates, this seems like an undesirable approach.