Corrected typos.

5 files changed, 33 insertions, 34 deletions

diff --git a/doc/cha-cert-auth.texi b/doc/cha-cert-auth.texi
index 6b4daf5211..ce3e733c67 100644
--- a/doc/cha-cert-auth.texi
+++ b/doc/cha-cert-auth.texi
@@ -157,7 +157,7 @@ provided.
 
 The verification function will verify a given certificate chain against a list of certificate
 authorities and certificate revocation lists, and output
-a bitwise OR of elements of the @code{gnutls_certificate_status_t} 
+a bit-wise OR of elements of the @code{gnutls_certificate_status_t} 
 enumeration. It is also possible to have a set of certificates that
 are trusted for a particular server but not to authorize other certificates.
 This purpose is served by the functions @funcref{gnutls_x509_trust_list_add_named_crt} and @funcref{gnutls_x509_trust_list_verify_named_crt}.
@@ -215,7 +215,7 @@ flags are part of the enumeration
 @headitem Flag @tab Description
 @item GNUTLS_VERIFY_\-DISABLE_CA_SIGN @tab
 If set a signer does not have to be a certificate authority. This
-flag should normaly be disabled, unless you know what this means.
+flag should normally be disabled, unless you know what this means.
 
 @item GNUTLS_VERIFY_\-ALLOW_X509_V1_CA_CRT @tab
 Allow only trusted CA certificates that have version 1.  This is
@@ -307,7 +307,7 @@ below.
 The @acronym{OpenPGP} key authentication relies on a distributed trust
 model, called the ``web of trust''. The ``web of trust'' uses a
 decentralized system of trusted introducers, which are the same as a
-CA. @acronym{OpenPGP} allows anyone to sign anyone's else public
+CA. @acronym{OpenPGP} allows anyone to sign anyone else's public
 key. When Alice signs Bob's key, she is introducing Bob's key to
 anyone who trusts Alice. If someone trusts Alice to introduce keys,
 then Alice is a trusted introducer in the mind of that observer.
@@ -404,7 +404,7 @@ shared cryptographic keys and certificates in a uniform way, as in @ref{fig:pkcs
 
 @subsection Initialization
 To allow all the  @acronym{GnuTLS} applications to access @acronym{PKCS} #11 tokens
-it is adviceable to use @code{/etc/pkcs11/modules/mymodule.conf}. This file has the following
+it is advisable to use @code{/etc/pkcs11/modules/mymodule.conf}. This file has the following
 format:
 
 @smallexample
diff --git a/doc/cha-gtls-app.texi b/doc/cha-gtls-app.texi
index 6c4f21e511..a7a8fd3655 100644
--- a/doc/cha-gtls-app.texi
+++ b/doc/cha-gtls-app.texi
@@ -50,7 +50,7 @@ done by calling @funcref{gnutls_global_deinit}.
 The extra functionality of the @acronym{GnuTLS-extra} library is
 available after calling @funcref{gnutls_global_init_extra}.
 
-In order to take advantage of the internationalisation features in
+In order to take advantage of the internationalization features in
 GnuTLS, such as translated error messages, the application must set
 the current locale using @code{setlocale} before initializing GnuTLS.
 
@@ -61,7 +61,7 @@ It is often desirable to check that the version of `gnutls' used is
 indeed one which fits all requirements.  Even with binary
 compatibility new features may have been introduced but due to problem
 with the dynamic linker an old version is actually used.  So you may
-want to check that the version is okay right after program startup.
+want to check that the version is okay right after program start-up.
 See the function @funcref{gnutls_check_version}.
 
 @node Debugging and auditing
@@ -114,7 +114,7 @@ the path to the library files has to be added to the library search
 path (via the @option{-L} option).  For this, the option
 @option{--libs} to @command{pkg-config gnutls} can be used.  For
 convenience, this option also outputs all other options that are
-required to link the program with the libarary (for instance, the
+required to link the program with the library (for instance, the
 @samp{-ltasn1} option).  The example shows how to link @file{foo.o}
 with the library to a program @command{foo}.
 
@@ -475,7 +475,7 @@ Note that it must be run after a successful TLS handshake.
 To ease @acronym{GnuTLS}' integration with existing applications, a
 compatibility layer with the widely used OpenSSL library is included
 in the @code{gnutls-openssl} library. This compatibility layer is not
-complete and it is not intended to completely reimplement the OpenSSL
+complete and it is not intended to completely re-implement the OpenSSL
 API with @acronym{GnuTLS}.  It only provides limited source-level
 compatibility. There is currently no attempt to make it
 binary-compatible with OpenSSL.
diff --git a/doc/cha-intro-tls.texi b/doc/cha-intro-tls.texi
index 7c446e86d6..2aaec03163 100644
--- a/doc/cha-intro-tls.texi
+++ b/doc/cha-intro-tls.texi
@@ -187,7 +187,7 @@ This mode combines message authentication and encryption and can
 be extremely fast on CPUs that support hardware acceleration.
 
 @item CAMELLIA_CBC @tab
-This is an 128-bit block cipher developed by Mitsubish and NTT. It
+This is an 128-bit block cipher developed by Mitsubishi and NTT. It
 is one of the approved ciphers of the European NESSIE and Japanese
 CRYPTREC projects.
 
@@ -227,7 +227,7 @@ GCM, is in use.
 The TLS record layer also supports compression.  The algorithms
 implemented in @acronym{GnuTLS} can be found in the table below.
 The included algorithms perform really good when text, or other
-compressible data are to be transfered, but offer nothing on already
+compressible data are to be transferred, but offer nothing on already
 compressed data, such as compressed images, zipped archives etc.
 These compression algorithms, may be useful in high bandwidth TLS
 tunnels, and in cases where network usage has to be minimized. It
@@ -317,7 +317,7 @@ protocol and the application protocol does not have to cope with them
 application protocol solely (e.g. @code{GNUTLS_A_USER_CANCELLED}).  An
 alert signal includes a level indication which may be either fatal or
 warning. Fatal alerts always terminate the current connection, and
-prevent future renegotiations using the current session ID. All alert
+prevent future re-negotiations using the current session ID. All alert
 messages are summarized in @ref{tab:alerts}.
 
 
@@ -524,7 +524,7 @@ completely.  Do not use unless you know what you are doing.
 Testing purposes only.
 
 @item %UNSAFE_RENEGOTIATION @tab
-will allow handshakes and rehandshakes
+will allow handshakes and re-handshakes
 without the safe renegotiation extension.  Note that for clients
 this mode is insecure (you may be under attack), and for servers it
 will allow insecure clients to connect (which could be fooled by an
@@ -533,7 +533,7 @@ maximum compatibility.
 
 @item %PARTIAL_RENEGOTIATION @tab
 will allow initial handshakes to proceed,
-but not rehandshakes.  This leaves the client vulnerable to attack,
+but not re-handshakes.  This leaves the client vulnerable to attack,
 and servers will be compatible with non-upgraded clients for
 initial handshakes.  This is currently the default for clients and
 servers, for compatibility reasons.
@@ -541,7 +541,7 @@ servers, for compatibility reasons.
 @item %SAFE_RENEGOTIATION @tab
 will enforce safe renegotiation.  Clients and
 servers will refuse to talk to an insecure peer.  Currently this
-causes operability problems, but is required for full protection.
+causes interoperability problems, but is required for full protection.
 
 @item %SSL3_RECORD_VERSION @tab
 will use SSL3.0 record version in client hello.
@@ -579,7 +579,7 @@ by the server. That is the ones set using the following functions.
 @showfuncdesc{gnutls_certificate_server_set_request}
 
 In cases where the server supports a large number of certificate authorities
-it makes sense not to advertize all of the names to save bandwidth. That can
+it makes sense not to advertise all of the names to save bandwidth. That can
 be controlled using the function @funcref{gnutls_certificate_send_x509_rdn_sequence}. 
 This however will have the side-effect of not restricting the client to certificates
 signed by server's acceptable signers.
@@ -744,7 +744,7 @@ resume functions, @ref{resume}.
 TLS gives the option to two communicating parties to renegotiate
 and update their security parameters. One useful example of this feature
 was for a client to initially connect using anonymous negotiation to a
-server, and the renegotiate using some authenticated ciphersuite. This occured
+server, and the renegotiate using some authenticated ciphersuite. This occurred
 to avoid having the client sending its credentials in the clear.
 
 However this renegotiation, as initially designed would not ensure that
@@ -794,14 +794,14 @@ negotiated.
 
 Note that permitting clients to connect to servers when the safe
 renegotiation extension is not enabled, is open up for attacks.
-Changing this default behaviour would prevent interoperability against
+Changing this default behavior would prevent interoperability against
 the majority of deployed servers out there.  We will reconsider this
-default behaviour in the future when more servers have been upgraded.
+default behavior in the future when more servers have been upgraded.
 Note that it is easy to configure clients to always require the safe
 renegotiation extension from servers (see below on the
 @code{%SAFE_RENEGOTIATION} priority string).
 
-To modify the default behaviour, we have introduced some new priority
+To modify the default behavior, we have introduced some new priority
 strings.  The priority strings can be used by applications
 (@funcref{gnutls_priority_set}) and end users (e.g., @code{--priority}
 parameter to @code{gnutls-cli} and @code{gnutls-serv}).
@@ -811,7 +811,7 @@ The @code{%UNSAFE_RENEGOTIATION} priority string permits
 negotiated. The default behavior is @code{%PARTIAL_RENEGOTIATION} that will
 prevent renegotiation with clients and servers not supporting the
 extension. This is secure for servers but leaves clients vulnerable
-to some attacks, but this is a tradeoff between security and compatibility
+to some attacks, but this is a trade-off between security and compatibility
 with old servers. The @code{%SAFE_RENEGOTIATION} priority string makes
 clients and servers require the extension for every handshake. The latter
 is the most secure option for clients, at the cost of not being able
@@ -845,7 +845,7 @@ can be used both by clients and servers.
 
 In TLS, since a lot of algorithms are involved, it is not easy to set
 a consistent security level.  For this reason in @ref{tab:key-sizes} we
-present some correspondance between key sizes of symmetric algorithms
+present some correspondence between key sizes of symmetric algorithms
 and public key algorithms based on @xcite{ECRYPT}. 
 Those can be used to generate certificates with
 appropriate key sizes as well as select parameters for Diffie-Hellman and SRP
@@ -900,7 +900,7 @@ A mapping to @code{gnutls_sec_param_t} value is given for each security paramete
 the next column, and finally a brief description of the level.
 
 Note however that the values suggested here are nothing more than an
-educated guess that is valid today. There are no guarrantees that an
+educated guess that is valid today. There are no guarantees that an
 algorithm will remain unbreakable or that these values will remain
 constant in time. There could be scientific breakthroughs that cannot
 be predicted or total failure of the current public key systems by
diff --git a/doc/cha-library.texi b/doc/cha-library.texi
index 4568acb0c9..44b41ae149 100644
--- a/doc/cha-library.texi
+++ b/doc/cha-library.texi
@@ -35,7 +35,7 @@ include:
 
 @acronym{GnuTLS} consists of three independent parts, namely the ``TLS
 protocol part'', the ``Certificate part'', and the ``Cryptographic
-backend'' part.  The `TLS protocol part' is the actual protocol
+back-end'' part.  The `TLS protocol part' is the actual protocol
 implementation, and is entirely implemented within the
 @acronym{GnuTLS} library.  The `Certificate part' consists of the
 certificate parsing, and verification functions which is partially
@@ -43,7 +43,7 @@ implemented in the @acronym{GnuTLS} library.  The
 libtasn1@footnote{@url{ftp://ftp.gnupg.org/gcrypt/alpha/gnutls/libtasn1/}},
 a library which offers @acronym{ASN.1} parsing capabilities, is used
 for the @acronym{X.509} certificate parsing functions.  
-The ``Cryptographic backend'' is provided by nettle@footnote{@url{http://www.lysator.liu.se/~nisse/nettle/}}
+The ``Cryptographic back-end'' is provided by nettle@footnote{@url{http://www.lysator.liu.se/~nisse/nettle/}}
 library.
 In order to ease integration in embedded systems, parts of the
 @acronym{GnuTLS} library can be disabled at compile time. That way a
@@ -96,9 +96,9 @@ to the transport layer functions, in order to communicate with the
 peer.  Every session has a unique session ID shared with the peer.
 
 Since TLS sessions can be resumed, servers would probably need a
-database backend to hold the session's parameters.  Every
+database back-end to hold the session's parameters.  Every
 @acronym{GnuTLS} session after a successful handshake calls the
-appropriate backend function (see @ref{resume}, for information on
+appropriate back-end function (see @ref{resume}, for information on
 initialization) to store the newly negotiated session. The session
 database is examined by the server just after having received the
 client hello@footnote{The first message in a @acronym{TLS} handshake},
@@ -152,10 +152,10 @@ information.
 @section Thread safety
 
 Although the @acronym{GnuTLS} library is thread safe by design, some
-parts of the cryptographic backend, such as the random generator, are not.
+parts of the cryptographic back-end, such as the random generator, are not.
 Applications can either call @funcref{gnutls_global_init} which will use the default
 operating system provided locks (i.e. @code{pthreads} on GNU/Linux and
-@code{CriticalSection} on Windows), or specify manualy the locking system using 
+@code{CriticalSection} on Windows), or specify manually the locking system using 
 the function @funcref{gnutls_global_set_mutex} before calling @funcref{gnutls_global_init}. 
 Setting manually mutexes is recommended
 only to applications that have full control of the underlying libraries. If this
diff --git a/doc/cha-preface.texi b/doc/cha-preface.texi
index 20ea7f8765..9e78177652 100644
--- a/doc/cha-preface.texi
+++ b/doc/cha-preface.texi
@@ -9,18 +9,17 @@ Even if @acronym{GnuTLS} is a typical library software, it operates
 over several security and cryptographic protocols which require the
 programmer to make careful and correct usage of them. Otherwise it
 is likely to only obtain a false sense of security.
-The terms of Security and 
-network security terms are very general even if restricted to computer
-software, and cannot be offered by a single cryptographic
+The term of security is very broad even if restricted to computer
+software, and cannot be confined to a single cryptographic
 library.  For that reason, do not consider any program secure just
 because it uses @acronym{GnuTLS}; there are several ways to compromise
 a program or a communication line and @acronym{GnuTLS} only helps with
 some of them.
 
 Although this document tries to be self contained, basic network
-programming and PKI knowlegde is assumed in most of it. A good
-introduction to networking can be found in @xcite{STEVENS} and for
-Public Key Infrastructure in @xcite{GUTPKI}.
+programming and public key infrastructure (PKI) knowledge is assumed 
+in most of it. A good introduction to networking can be found 
+in @xcite{STEVENS} and for public key infrastructure in @xcite{GUTPKI}.
 
 Updated versions of the @acronym{GnuTLS} software and this document
 will be available from @url{http://www.gnutls.org/} and