diff --git a/doc/cha-auth.texi b/doc/cha-auth.texi
index 4079985..e32ec33 100644
--- a/doc/cha-auth.texi
+++ b/doc/cha-auth.texi
@@ -3,12 +3,12 @@
 @cindex authentication methods
 
 The initial key exchange of the TLS protocol performs authentication
-of the peers. In typical scenarios the server is authenticated to
+of the peers.  In typical scenarios the server is authenticated to
 the client, and optionally the client to the server.
 
 While many associate TLS with X.509 certificates and public key
 authentication, the protocol supports various authentication methods,
-including pre-shared keys, and passwords. In this chapter a description
+including pre-shared keys, and passwords.  In this chapter a description
 of the existing authentication methods is provided, as well as some
 guidance on which use-cases each method can be used at.
 
@@ -34,20 +34,20 @@ methods in @acronym{GnuTLS} in various scenarios.
 @subsection Two peers with an out-of-band channel
 
 Let's consider two peers need to communicate over an untrusted channel
-(the Internet), but have an out-of-band channel available. The latter
+(the Internet), but have an out-of-band channel available.  The latter
 channel is considered safe from eavesdropping and message modification and thus
-can be used for an initial bootstrapping of the protocol. The options 
+can be used for an initial bootstrapping of the protocol.  The options 
 available are:
 @itemize
-@item Pre-shared keys (see @ref{PSK authentication}). The server and a
+@item Pre-shared keys (see @ref{PSK authentication}).  The server and a
 client communicate a shared randomly generated key over the trusted
 channel and use it to negotiate further sessions over the untrusted channel.
 
-@item Passwords (see @ref{SRP authentication}). The client communicates
+@item Passwords (see @ref{SRP authentication}).  The client communicates
 to the server his username and password of choice and uses it to
 negotiate further sessions over the untrusted channel.
 
-@item Public keys (see @ref{Certificate authentication}). The client 
+@item Public keys (see @ref{Certificate authentication}).  The client 
 and the server exchange their public keys (or fingerprints of them)
 over the trusted channel. 
 On future sessions over the untrusted channel they verify the key
@@ -56,7 +56,7 @@ authentication}).
 @end itemize
 
 Provided that the out-of-band channel is trusted all of the above provide
-a similar level of protection. An out-of-band channel may be the initial
+a similar level of protection.  An out-of-band channel may be the initial
 bootstrapping of a user's PC in a corporate environment, in-person
 communication, communication over an alternative network (e.g. the phone
 network), etc.
@@ -64,9 +64,9 @@ network), etc.
 @subsection Two peers without an out-of-band channel
 
 When an out-of-band channel is not available a peer cannot be reliably
-authenticated. What can be done, however, is to allow some form of
+authenticated.  What can be done, however, is to allow some form of
 registration of users connecting for the first time and ensure that their
-keys remain the same after that initial connection. This is termed
+keys remain the same after that initial connection.  This is termed
 key continuity or trust on first use (TOFU).
 
 The available option is to use public key authentication (see @ref{Certificate authentication}). 
@@ -89,25 +89,25 @@ The client and the server obtain certificates that associate their identity
 and public keys using a digital signature by the trusted party and use 
 them to on the subsequent communications with each other. 
 Each party verifies the peer's certificate using the trusted third party's 
-signature. The parameters of the third party's signature are present
+signature.  The parameters of the third party's signature are present
 in its certificate which must be available to all communicating parties.
 
 While the above is the typical authentication method for servers in the
 Internet by using the commercial CAs, the users that act as clients in the
-protocol rarely possess such certificates. In that case a hybrid method
+protocol rarely possess such certificates.  In that case a hybrid method
 can be used where the server is authenticated by the client using the
 commercial CAs and the client is authenticated based on some information
-the client provided over the initial server-authenticated channel. The
+the client provided over the initial server-authenticated channel.  The
 available options are:
 @itemize
-@item Passwords (see @ref{SRP authentication}). The client communicates
+@item Passwords (see @ref{SRP authentication}).  The client communicates
 to the server his username and password of choice on the initial
 server-authenticated connection and uses it to negotiate further sessions. 
 This is possible because the SRP protocol allows for the server to be 
 authenticated using a certificate and the client using the
 password.
 
-@item Public keys (see @ref{Certificate authentication}). The client 
+@item Public keys (see @ref{Certificate authentication}).  The client 
 sends its public key to the server (or a fingerprint of it) over the
 initial server-authenticated connection. 
 On future sessions the client verifies the server using the third party
diff --git a/doc/cha-cert-auth.texi b/doc/cha-cert-auth.texi
index ac0def0..099d065 100644
--- a/doc/cha-cert-auth.texi
+++ b/doc/cha-cert-auth.texi
@@ -4,7 +4,7 @@
 
 The most known authentication method of @acronym{TLS} are certificates.
 The PKIX @xcite{PKIX} public key infrastructure is daily used by anyone
-using a browser today. @acronym{GnuTLS} supports both 
+using a browser today.  @acronym{GnuTLS} supports both 
 @acronym{X.509} certificates @xcite{PKIX} and @acronym{OpenPGP}
 certificates using a common API.
 
@@ -22,28 +22,28 @@ The certificate must allow the key to be used for encryption.
 
 @item DHE_@-RSA @tab
 The RSA algorithm is used to sign ephemeral Diffie-Hellman parameters
-which are sent to the peer. The key in the certificate must allow the
-key to be used for signing. Note that key exchange algorithms which
+which are sent to the peer.  The key in the certificate must allow the
+key to be used for signing.  Note that key exchange algorithms which
 use ephemeral Diffie-Hellman parameters, offer perfect forward
-secrecy. That means that even if the private key used for signing is
+secrecy.  That means that even if the private key used for signing is
 compromised, it cannot be used to reveal past session data.
 
 @item ECDHE_@-RSA @tab
 The RSA algorithm is used to sign ephemeral elliptic curve Diffie-Hellman 
-parameters which are sent to the peer. The key in the certificate must allow 
-the key to be used for signing. It also offers perfect forward
-secrecy. That means that even if the private key used for signing is
+parameters which are sent to the peer.  The key in the certificate must allow 
+the key to be used for signing.  It also offers perfect forward
+secrecy.  That means that even if the private key used for signing is
 compromised, it cannot be used to reveal past session data.
 
 @item DHE_@-DSS @tab
 The DSA algorithm is used to sign ephemeral Diffie-Hellman parameters
-which are sent to the peer. The certificate must contain DSA
-parameters to use this key exchange algorithm. DSA is the algorithm
+which are sent to the peer.  The certificate must contain DSA
+parameters to use this key exchange algorithm.  DSA is the algorithm
 of the Digital Signature Standard (DSS).
 
 @item ECDHE_@-ECDSA @tab
 The Elliptic curve DSA algorithm is used to sign ephemeral elliptic
-curve Diffie-Hellman parameters which are sent to the peer. The 
+curve Diffie-Hellman parameters which are sent to the peer.  The 
 certificate must contain ECDSA parameters (i.e., EC and marked for signing) 
 to use this key exchange algorithm. 
 
@@ -62,7 +62,7 @@ to use this key exchange algorithm.
 @subsection @acronym{X.509} certificates
 @cindex X.509 certificates
 
-The @acronym{X.509} protocols rely on a hierarchical trust model. In
+The @acronym{X.509} protocols rely on a hierarchical trust model.  In
 this trust model Certification Authorities (CAs) are used to certify
 entities.  Usually more than one certification authorities exist, and
 certification authorities may certify other authorities to issue
@@ -73,7 +73,7 @@ certificates as well, following a hierarchical model.
 @caption{An example of the X.509 hierarchical trust model.}
 @end float
 
-One needs to trust one or more CAs for his secure communications. In
+One needs to trust one or more CAs for his secure communications.  In
 that case only the certificates issued by the trusted authorities are
 acceptable.  The framework is illustrated on @ref{fig-x509}.
 
@@ -128,7 +128,7 @@ The extensions are fields only present in version 3 certificates.
 The certificate's @emph{subject or issuer name} is not just a single
 string.  It is a Distinguished name and in the @acronym{ASN.1}
 notation is a sequence of several object identifiers with their corresponding
-values. Some of available OIDs to be used in an @acronym{X.509}
+values.  Some of available OIDs to be used in an @acronym{X.509}
 distinguished name are defined in @file{gnutls/x509.h}.
 
 The @emph{Version} field in a certificate has values either 1 or 3 for
@@ -145,7 +145,7 @@ In @acronym{GnuTLS} the @acronym{X.509} certificate structures are
 handled using the @code{gnutls_x509_crt_t} type and the corresponding
 private keys with the @code{gnutls_x509_privkey_t} type.  All the
 available functions for @acronym{X.509} certificate handling have
-their prototypes in @file{gnutls/x509.h}. An example program to
+their prototypes in @file{gnutls/x509.h}.  An example program to
 demonstrate the @acronym{X.509} parsing capabilities can be found in
 @ref{ex-x509-info}.
 
@@ -153,11 +153,11 @@ demonstrate the @acronym{X.509} parsing capabilities can be found in
 @subsubsection Importing an X.509 certificate
 
 The certificate structure should be initialized using @funcref{gnutls_x509_crt_init}, and 
-a certificate structure can be imported using @funcref{gnutls_x509_crt_import}. 
+a certificate structure can be imported using @funcref{gnutls_x509_crt_import}.
 
 @showfuncC{gnutls_x509_crt_init,gnutls_x509_crt_import,gnutls_x509_crt_deinit}
 
-In several functions an array of certificates is required. To assist in initialization
+In several functions an array of certificates is required.  To assist in initialization
 and import the following two functions are provided.
 
 @showfuncB{gnutls_x509_crt_list_import,gnutls_x509_crt_list_import2}
@@ -171,11 +171,11 @@ exist for the CRL structure @code{gnutls_x509_crl_t}.
 @cindex X.509 distinguished name
 
 The ``subject'' of an X.509 certificate is not described by
-a single name, but rather with a distinguished name. This in
+a single name, but rather with a distinguished name.  This in
 X.509 terminology is a list of strings each associated an object
-identifier. To make things simple GnuTLS provides @funcref{gnutls_x509_crt_get_dn2}
+identifier.  To make things simple GnuTLS provides @funcref{gnutls_x509_crt_get_dn2}
 which follows the rules in @xcite{RFC4514} and returns a single
-string. Access to each string by individual object identifiers
+string.  Access to each string by individual object identifiers
 can be accessed using @funcref{gnutls_x509_crt_get_dn_by_oid}.
 
 @showfuncdesc{gnutls_x509_crt_get_dn2}
@@ -199,11 +199,11 @@ to the contents of the distinguished name structure.
 
 X.509 version 3 certificates include a list of extensions that can
 be used to obtain additional information on the subject or the issuer
-of the certificate. Those may be e-mail addresses, flags that indicate whether the
+of the certificate.  Those may be e-mail addresses, flags that indicate whether the
 belongs to a CA etc.  All the supported @acronym{X.509} version 3
 extensions are shown in @ref{tab:x509-ext}.
 
-The certificate extensions access is split into two parts. The first
+The certificate extensions access is split into two parts.  The first
 requires to retrieve the extension, and the second is the parsing part.
 
 To enumerate and retrieve the DER-encoded extension data available in a certificate the following
@@ -212,7 +212,7 @@ two functions are available.
 
 After a supported DER-encoded extension is retrieved it can be parsed using the APIs in @code{x509-ext.h}.
 Complex extensions may require initializing an intermediate structure that holds the
-parsed extension data. Examples of simple parsing functions are shown below.
+parsed extension data.  Examples of simple parsing functions are shown below.
 @showfuncD{gnutls_x509_ext_import_basic_constraints,gnutls_x509_ext_export_basic_constraints,gnutls_x509_ext_import_key_usage,gnutls_x509_ext_export_key_usage}
 
 More complex extensions, such as Name Constraints, require an intermediate structure, in that
@@ -268,7 +268,7 @@ This extension is set to indicate the certificate policy as object
 identifier and may contain a descriptive string or URL.
 
 @item Authority key identifier @tab 2.5.29.35 @tab
-An identifier of the key of the issuer of the certificate. That is
+An identifier of the key of the issuer of the certificate.  That is
 used to distinguish between different keys of the same issuer.
 
 @item Extended key usage @tab 2.5.29.37 @tab
@@ -288,7 +288,7 @@ lengths of proxy chains.  Proxy Certificates are specified in
 @end float
 
 Note, that there are also direct APIs to access extensions that may
-be simpler to use for non-complex extensions. They are available
+be simpler to use for non-complex extensions.  They are available
 in @code{x509.h} and some examples are listed below.
 @showfuncD{gnutls_x509_crt_get_basic_constraints,gnutls_x509_crt_set_basic_constraints,gnutls_x509_crt_get_key_usage,gnutls_x509_crt_set_key_usage}
 
@@ -296,10 +296,10 @@ in @code{x509.h} and some examples are listed below.
 @node X.509 public and private keys
 @subsubsection Accessing public and private keys
 
-Each X.509 certificate contains a public key that corresponds to a private key. To
+Each X.509 certificate contains a public key that corresponds to a private key.  To
 get a unique identifier of the public key the @funcref{gnutls_x509_crt_get_key_id}
-function is provided. To export the public key or its parameters you may need
-to convert the X.509 structure to a @code{gnutls_pubkey_t}. See 
+function is provided.  To export the public key or its parameters you may need
+to convert the X.509 structure to a @code{gnutls_pubkey_t}.  See 
 @ref{Abstract public keys} for more information.
 
 @showfuncdesc{gnutls_x509_crt_get_key_id}
@@ -313,7 +313,7 @@ The private key parameters may be directly accessed by using one of the followin
 @cindex verifying certificate paths
 
 Verifying certificate paths is important in @acronym{X.509}
-authentication. For this purpose the following functions are
+authentication.  For this purpose the following functions are
 provided.
 
 @showfuncdesc{gnutls_x509_trust_list_add_cas}
@@ -330,7 +330,7 @@ provided.
 The verification function will verify a given certificate chain against a list of certificate
 authorities and certificate revocation lists, and output
 a bit-wise OR of elements of the @code{gnutls_@-certificate_@-status_t} 
-enumeration shown in @ref{gnutls_certificate_status_t}. The @code{GNUTLS_@-CERT_@-INVALID} flag
+enumeration shown in @ref{gnutls_certificate_status_t}.  The @code{GNUTLS_@-CERT_@-INVALID} flag
 is always set on a verification error and more detailed flags will also be set when appropriate.
 
 @showenumdesc{gnutls_certificate_status_t,The @code{gnutls_@-certificate_@-status_t} enumeration.}
@@ -345,7 +345,7 @@ This purpose is served by the functions @funcref{gnutls_x509_trust_list_add_name
 @cindex verifying certificate paths
 @tindex gnutls_certificate_verify_flags
 
-When operating in the context of a TLS session, the trusted certificate
+When operating in the context of a @acronym{TLS session, the trusted certificate
 authority list may also be set using:
 @showfuncD{gnutls_certificate_set_x509_trust_file,gnutls_certificate_set_x509_trust_dir,gnutls_certificate_set_x509_crl_file,gnutls_certificate_set_x509_system_trust}
 
@@ -356,7 +356,7 @@ to use the system trust storage (see @funcref{gnutls_certificate_set_x509_system
 
 Unlike the previous section it is not required to setup a trusted list, and 
 the function @funcref{gnutls_certificate_verify_peers3} 
-is used to verify the peer's certificate chain and identity. The reported
+is used to verify the peer's certificate chain and identity.  The reported
 verification status is identical to the verification functions described 
 in the previous section.
 Note that in certain cases it is required to check the marked purpose of
@@ -364,7 +364,7 @@ the end certificate (e.g. @code{GNUTLS_KP_TLS_WWW_SERVER}); in these cases
 the more advanced @funcref{gnutls_certificate_verify_peers} should be used instead.
 
 There is also the possibility to pass some input to the verification
-functions in the form of flags. For @funcref{gnutls_x509_trust_list_verify_crt2} the
+functions in the form of flags.  For @funcref{gnutls_x509_trust_list_verify_crt2} the
 flags are passed directly, but for
 @funcref{gnutls_certificate_verify_peers3}, the flags are set using
 @funcref{gnutls_certificate_set_verify_flags}.  All the available
@@ -378,9 +378,9 @@ flags are part of the enumeration
 @cindex verifying certificate with pkcs11
 
 Some systems provide a system wide trusted certificate storage accessible using
-the PKCS #11 API. That is, the trusted certificates are queried and accessed using the
+the PKCS #11 API.  That is, the trusted certificates are queried and accessed using the
 PKCS #11 API, and trusted certificate properties, such as purpose, are marked using
-attached extensions. One example is the p11-kit trust module@footnote{see @url{http://p11-glue.freedesktop.org/trust-module.html}.}.
+attached extensions.  One example is the p11-kit trust module@footnote{see @url{http://p11-glue.freedesktop.org/trust-module.html}.}.
 
 These special PKCS #11 modules can be used for GnuTLS certificate verification if marked as trust 
 policy modules, i.e., with @code{trust-policy: yes} in the p11-kit module file.
@@ -388,8 +388,8 @@ The way to use them is by specifying to the file verification function (e.g., @f
 a pkcs11 URL, or simply @code{pkcs11:} to use all the marked with trust policy modules.
 
 The trust modules of p11-kit assign a purpose to trusted authorities using the extended
-key usage object identifiers. The common purposes are shown in @ref{tab:purposes}. Note
-that typically according to @xcite{RFC5280} the extended key usage object identifiers apply to end certificates. Their
+key usage object identifiers.  The common purposes are shown in @ref{tab:purposes}.  Note
+that typically according to @xcite{RFC5280} the extended key usage object identifiers apply to end certificates.  Their
 application to CA certificates is an extension used by the trust modules.
 
 @float Table,tab:purposes
@@ -399,32 +399,32 @@ application to CA certificates is an extension used by the trust modules.
 
 @item GNUTLS_KP_TLS_WWW_SERVER @tab
 1.3.6.1.5.5.7.3.1 @tab
-The certificate is to be used for TLS WWW authentication. When in a CA certificate, it
+The certificate is to be used for TLS WWW authentication.  When in a CA certificate, it
 indicates that the CA is allowed to sign certificates for TLS WWW authentication.
 
 @item GNUTLS_KP_TLS_WWW_CLIENT @tab
 1.3.6.1.5.5.7.3.2 @tab
-The certificate is to be used for TLS WWW client authentication. When in a CA certificate, it
+The certificate is to be used for TLS WWW client authentication.  When in a CA certificate, it
 indicates that the CA is allowed to sign certificates for TLS WWW client authentication.
 
 @item GNUTLS_KP_CODE_SIGNING @tab
 1.3.6.1.5.5.7.3.3 @tab
-The certificate is to be used for code signing. When in a CA certificate, it
+The certificate is to be used for code signing.  When in a CA certificate, it
 indicates that the CA is allowed to sign certificates for code signing.
 
 @item GNUTLS_KP_EMAIL_PROTECTION @tab
 1.3.6.1.5.5.7.3.4 @tab
-The certificate is to be used for email protection. When in a CA certificate, it
+The certificate is to be used for email protection.  When in a CA certificate, it
 indicates that the CA is allowed to sign certificates for email users.
 
 @item GNUTLS_KP_OCSP_SIGNING @tab
 1.3.6.1.5.5.7.3.9 @tab
-The certificate is to be used for signing OCSP responses. When in a CA certificate, it
+The certificate is to be used for signing OCSP responses.  When in a CA certificate, it
 indicates that the CA is allowed to sign certificates which sign OCSP reponses.
 
 @item GNUTLS_KP_ANY @tab
 2.5.29.37.0 @tab
-The certificate is to be used for any purpose. When in a CA certificate, it
+The certificate is to be used for any purpose.  When in a CA certificate, it
 indicates that the CA is allowed to sign any kind of certificates.
 
 @end multitable
@@ -432,7 +432,7 @@ indicates that the CA is allowed to sign any kind of certificates.
 @end float
 
 With such modules, it is recommended to use the verification functions @funcref{gnutls_x509_trust_list_verify_crt2},
-or @funcref{gnutls_certificate_verify_peers}, which allow to explicitly specify the key purpose. The
+or @funcref{gnutls_certificate_verify_peers}, which allow to explicitly specify the key purpose.  The
 other verification functions which do not allow setting a purpose, would operate as if
 @code{GNUTLS_KP_TLS_WWW_SERVER} was requested from the trusted authorities.
 
@@ -441,11 +441,11 @@ other verification functions which do not allow setting a purpose, would operate
 @cindex OpenPGP certificates
 
 The @acronym{OpenPGP} key authentication relies on a distributed trust
-model, called the ``web of trust''. The ``web of trust'' uses a
+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 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,
+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.
 For example in @ref{fig-openpgp}, David trusts Alice to be an introducer and Alice
 signed Bob's key thus Dave trusts Bob's key to be the real one.
@@ -455,16 +455,16 @@ signed Bob's key thus Dave trusts Bob's key to be the real one.
 @caption{An example of the OpenPGP trust model.}
 @end float
 
-There are some key points that are important in that model. In the
+There are some key points that are important in that model.  In the
 example Alice has to sign Bob's key, only if she is sure that the key
-belongs to Bob. Otherwise she may also make Dave falsely believe that
-this is Bob's key. Dave has also the responsibility to know who to
+belongs to Bob.  Otherwise she may also make Dave falsely believe that
+this is Bob's key.  Dave has also the responsibility to know who to
 trust.  This model is similar to real life relations.
 
-Just see how Charlie behaves in the previous example. Although he has
+Just see how Charlie behaves in the previous example.  Although he has
 signed Bob's key - because he knows, somehow, that it belongs to Bob -
-he does not trust Bob to be an introducer. Charlie decided to trust
-only Kevin, for some reason. A reason could be that Bob is lazy
+he does not trust Bob to be an introducer.  Charlie decided to trust
+only Kevin, for some reason.  A reason could be that Bob is lazy
 enough, and signs other people's keys without being sure that they
 belong to the actual owner.
 
@@ -477,7 +477,7 @@ belong to the actual owner.
 The field that indicates the version of the OpenPGP structure.
 
 @item user ID @tab
-An RFC 2822 string that identifies the owner of the key. There may be
+An RFC 2822 string that identifies the owner of the key.  There may be
 multiple user identifiers in a key.
 
 @item public key @tab
@@ -487,7 +487,7 @@ The main public key of the certificate.
 The expiration time of the main public key.
 
 @item public subkey @tab
-An additional public key of the certificate. There may be multiple subkeys
+An additional public key of the certificate.  There may be multiple subkeys
 in a certificate.
 
 @item public subkey expiration @tab
@@ -504,7 +504,7 @@ In @acronym{GnuTLS} the @acronym{OpenPGP} certificate structures
 @xcite{RFC2440} are handled using the @code{gnutls_openpgp_crt_t} type.
 A typical certificate contains the user ID, which is an RFC 2822
 mail and name address, a public key, possibly a number of additional
-public keys (called subkeys), and a number of signatures. The various
+public keys (called subkeys), and a number of signatures.  The various
 fields are shown in @ref{tab:openpgp-certificate}.
 
 The additional subkeys may provide key for various different purposes,
@@ -537,7 +537,7 @@ A DSA public key that is marked for authentication.
 @end float
 
 The corresponding private keys are stored in the
-@code{gnutls_openpgp_privkey_t} type. All the prototypes for the key
+@code{gnutls_openpgp_privkey_t} type.  All the prototypes for the key
 handling functions can be found in @file{gnutls/openpgp.h}.
 
 @subsubsection Verifying an @acronym{OpenPGP} certificate
@@ -552,9 +552,9 @@ recommended.
 In GnuTLS there is a verification function for OpenPGP certificates,
 the @funcref{gnutls_openpgp_crt_verify_ring}.  This checks an
 @acronym{OpenPGP} key against a given set of public keys (keyring) and
-returns the key status. The key verification status is the same as in
+returns the key status.  The key verification status is the same as in
 @acronym{X.509} certificates, although the meaning and interpretation
-are different. For example an @acronym{OpenPGP} key may be valid, if
+are different.  For example an @acronym{OpenPGP} key may be valid, if
 the self signature is ok, even if no signers were found.  The meaning
 of verification status flags is the same as in the @acronym{X.509} certificates
 (see @ref{gnutls_certificate_verify_flags}).
@@ -566,7 +566,7 @@ of verification status flags is the same as in the @acronym{X.509} certificates
 @subsubsection Verifying a certificate in the context of a TLS session
 
 Similarly with X.509 certificates, one needs to specify
-the OpenPGP keyring file in the credentials structure. The certificates
+the OpenPGP keyring file in the credentials structure.  The certificates
 in this file will be  used by @funcref{gnutls_certificate_verify_peers3}
 to verify the signatures in the certificate sent by the peer.
 
@@ -579,9 +579,9 @@ to verify the signatures in the certificate sent by the peer.
 The verification of X.509 certificates in the HTTPS and other Internet protocols is typically 
 done by loading a trusted list of commercial Certificate Authorities
 (see @funcref{gnutls_certificate_set_x509_system_trust}), and using them as trusted anchors.
-However, there are several examples (eg. the Diginotar incident) where one of these
-authorities was compromised. This risk can be mitigated by using in addition to CA certificate verification,
-other verification methods. In this section we list the available in GnuTLS methods.
+However, there are several examples (e.g. the Diginotar incident) where one of these
+authorities was compromised.  This risk can be mitigated by using in addition to CA certificate verification,
+other verification methods.  In this section we list the available in GnuTLS methods.
 
 @menu
 * Verifying a certificate using trust on first use authentication::
@@ -596,13 +596,13 @@ other verification methods. In this section we list the available in GnuTLS meth
 @cindex Key pinning
 
 It is possible to use a trust on first use (TOFU) authentication 
-method in GnuTLS. That is the concept used by the SSH programs, where the 
+method in GnuTLS.  That is the concept used by the SSH programs, where the 
 public key of the peer is not verified, or verified in an out-of-bound way,
 but subsequent connections to the same peer require the public key to 
 remain the same.  Such a system in combination with the typical CA 
 verification of a certificate, and OCSP revocation checks,
 can help to provide multiple factor verification, where a single point of
-failure is not enough to compromise the system. For example a server compromise
+failure is not enough to compromise the system.  For example a server compromise
 may be detected using OCSP, and a CA compromise can be detected using
 the trust on first use method.
 Such a hybrid system with X.509 and trust on first use authentication is 
@@ -617,12 +617,12 @@ See @ref{Certificate verification} on how to use the available functionality.
 @cindex DNSSEC
 
 The DANE protocol is a protocol that can be used to verify TLS certificates
-using the DNS (or better DNSSEC) protocols. The DNS security extensions (DNSSEC)
+using the DNS (or better DNSSEC) protocols.  The DNS security extensions (DNSSEC)
 provide an alternative public key infrastructure to the commercial CAs that
-are typically used to sign TLS certificates. The DANE protocol takes advantage
-of the DNSSEC infrastructure to verify TLS certificates. This can be 
+are typically used to sign TLS certificates.  The DANE protocol takes advantage
+of the DNSSEC infrastructure to verify TLS certificates.  This can be 
 in addition to the verification by CA infrastructure or 
-may even replace it where DNSSEC is fully deployed. Note however, that DNSSEC deployment is
+may even replace it where DNSSEC is fully deployed.  Note however, that DNSSEC deployment is
 fairly new and it would be better to use it as an additional verification
 method rather than the only one.
 
@@ -633,7 +633,7 @@ See @ref{Certificate verification} for information on how to use the library.
 Note however, that the DANE RFC mandates the verification methods
 one should use in addition to the validation via DNSSEC TLSA entries.
 GnuTLS doesn't follow that RFC requirement, and the term DANE verification
-in this manual refers to the TLSA entry verification. In GnuTLS any 
+in this manual refers to the TLSA entry verification.  In GnuTLS any 
 other verification methods can be used (e.g., PKIX or TOFU) on top of
 DANE.
 
@@ -648,12 +648,12 @@ of the algorithms used.
 Digital signatures work by using somebody's secret key to sign some
 arbitrary data.  Then anybody else could use the public key of that
 person to verify the signature.  Since the data may be arbitrary it is
-not suitable input to a cryptographic digital signature algorithm. For
+not suitable input to a cryptographic digital signature algorithm.  For
 this reason and also for performance cryptographic hash algorithms are
-used to preprocess the input to the signature algorithm. This works as
+used to preprocess the input to the signature algorithm.  This works as
 long as it is difficult enough to generate two different messages with
-the same hash algorithm output. In that case the same signature could
-be used as a proof for both messages. Nobody wants to sign an innocent
+the same hash algorithm output.  In that case the same signature could
+be used as a proof for both messages.  Nobody wants to sign an innocent
 message of donating 1 euro to Greenpeace and find out that he
 donated 1.000.000 euros to Bad Inc.
 
@@ -675,10 +675,10 @@ That means that it is impossible to calculate random @math{x} and
 @end enumerate
 
 The last two requirements in the list are the most important in
-digital signatures. These protect against somebody who would like to
-generate two messages with the same hash output. When an algorithm is
+digital signatures.  These protect against somebody who would like to
+generate two messages with the same hash output.  When an algorithm is
 considered broken usually it means that the Collision resistance of
-the algorithm is less than brute force. Using the birthday paradox the
+the algorithm is less than brute force.  Using the birthday paradox the
 brute force attack takes
 @iftex
 @math{2^{(\rm{hash\ size}) / 2}}
@@ -686,7 +686,7 @@ brute force attack takes
 @ifnottex
 @math{2^{((hash size) / 2)}}
 @end ifnottex
-operations. Today colliding certificates using the MD5 hash algorithm
+operations.  Today colliding certificates using the MD5 hash algorithm
 have been generated as shown in @xcite{WEGER}.
 
 There has been cryptographic results for the SHA-1 hash algorithms as
@@ -717,7 +717,7 @@ This section will give help on how to achieve that.
 
 It is important to know that you do not have to enable any of
 the flags discussed here to be able to use trusted root CA
-certificates self-signed using @code{RSA-MD2} or @code{RSA-MD5}. The
+certificates self-signed using @code{RSA-MD2} or @code{RSA-MD5}.  The
 certificates in the trusted list are considered trusted irrespective
 of the signature.
 
diff --git a/doc/cha-cert-auth2.texi b/doc/cha-cert-auth2.texi
index a6482a8..00d7870 100644
--- a/doc/cha-cert-auth2.texi
+++ b/doc/cha-cert-auth2.texi
@@ -3,7 +3,7 @@
 @cindex certificate authentication
 
 Certificates are not the only structures involved in a public key
-infrastructure. Several other structures that are used for certificate
+infrastructure.  Several other structures that are used for certificate
 requests, encrypted private keys, revocation lists, GnuTLS abstract key
 structures, etc., are discussed in this chapter.
 
@@ -25,8 +25,8 @@ structures, etc., are discussed in this chapter.
 A certificate request is a structure, which contain information about
 an applicant of a certificate service.  It usually contains a private
 key, a distinguished name and secondary data such as a challenge
-password. @acronym{GnuTLS} supports the requests defined in
-@acronym{PKCS} #10 @xcite{RFC2986}. Other formats of certificate requests
+password.  @acronym{GnuTLS} supports the requests defined in
+@acronym{PKCS} #10 @xcite{RFC2986}.  Other formats of certificate requests
 are not currently supported.
 
 A certificate request can be generated by
@@ -38,7 +38,7 @@ possession of the private key.
 @showfuncF{gnutls_x509_crq_set_version,gnutls_x509_crq_set_dn,gnutls_x509_crq_set_dn_by_oid,gnutls_x509_crq_set_key_usage,gnutls_x509_crq_set_key_purpose_oid,gnutls_x509_crq_set_basic_constraints}
 
 The @funcref{gnutls_x509_crq_set_key} and @funcref{gnutls_x509_crq_sign2} 
-functions associate the request with a private key and sign it. If a 
+functions associate the request with a private key and sign it.  If a 
 request is to be signed with a key residing in a PKCS #11 token it is recommended to use
 the signing functions shown in @ref{Abstract key types}.
 
@@ -46,7 +46,7 @@ the signing functions shown in @ref{Abstract key types}.
 @showfuncdesc{gnutls_x509_crq_sign2}
 
 The following example is about generating a certificate request, and a
-private key. A certificate request can be later be processed by a CA
+private key.  A certificate request can be later be processed by a CA
 which should return a signed certificate.
 
 @anchor{ex-crq}
@@ -59,7 +59,7 @@ which should return a signed certificate.
 
 A certificate revocation list (CRL) is a structure issued by an authority
 periodically containing a list of revoked certificates serial numbers.
-The CRL structure is signed with the issuing authorities' keys. A typical
+The CRL structure is signed with the issuing authorities' keys.  A typical
 CRL contains the fields as shown in @ref{tab:crl}.
 Certificate revocation lists are used to complement the expiration date of a certificate,
 in order to account for other reasons of revocation, such as compromised keys, etc.
@@ -105,7 +105,7 @@ The basic CRL structure functions follow.
 @subsubheading Reading a CRL
 
 The most important function that extracts the certificate revocation
-information from a CRL is @funcref{gnutls_x509_crl_get_crt_serial}. Other
+information from a CRL is @funcref{gnutls_x509_crl_get_crt_serial}.  Other
 functions that return other fields of the CRL structure are also provided.
 
 @showfuncdesc{gnutls_x509_crl_get_crt_serial}
@@ -120,7 +120,7 @@ The following functions can be used to generate a CRL.
 @showfuncC{gnutls_x509_crl_set_crt,gnutls_x509_crl_set_next_update,gnutls_x509_crl_set_this_update}
 
 The @funcref{gnutls_x509_crl_sign2} and @funcref{gnutls_x509_crl_privkey_sign} 
-functions sign the revocation list with a private key. The latter function
+functions sign the revocation list with a private key.  The latter function
 can be used to sign with a key residing in a PKCS #11 token.
 
 @showfuncdesc{gnutls_x509_crl_sign2}
@@ -162,7 +162,7 @@ out the address of the OCSP server.  The OCSP server address can be
 provided by the local user in manual configuration or may be stored
 in the certificate that is being checked.  When stored in a certificate
 the OCSP server is in the extension field called the Authority Information 
-Access (AIA). The following function
+Access (AIA).  The following function
 extracts this information from a certificate.
 
 @showfuncA{gnutls_x509_crt_get_authority_info_access}
@@ -211,7 +211,7 @@ requests are the following.
 @showfuncE{gnutls_ocsp_req_init,gnutls_ocsp_req_deinit,gnutls_ocsp_req_import,gnutls_ocsp_req_export,gnutls_ocsp_req_print}
 
 To generate an OCSP request the issuer name hash, issuer key hash, and 
-the checked certificate's serial number are required. There are two
+the checked certificate's serial number are required.  There are two
 interfaces available for setting those in an OCSP request.
 The is a low-level function when you have the
 issuer name hash, issuer key hash, and certificate serial number in
@@ -224,7 +224,7 @@ request.
 
 Each OCSP request may contain a number of extensions.  Extensions are
 identified by an Object Identifier (OID) and an opaque data buffer
-whose syntax and semantics is implied by the OID. You can extract or
+whose syntax and semantics is implied by the OID.  You can extract or
 set those extensions using the following functions.
 
 @showfuncB{gnutls_ocsp_req_get_extension,gnutls_ocsp_req_set_extension}
@@ -237,8 +237,8 @@ attacker will not be able to give a stale response for the same nonce.
 
 @showfuncC{gnutls_ocsp_req_get_nonce,gnutls_ocsp_req_set_nonce,gnutls_ocsp_req_randomize_nonce}
 
-The OCSP response structures is a complex structure. A simplified overview
-of it is in @ref{tab:ocsp-response}. Note that a response may contain 
+The OCSP response structures is a complex structure.  A simplified overview
+of it is in @ref{tab:ocsp-response}.  Note that a response may contain 
 information on multiple certificates.
 
 @float Table,tab:ocsp-response
@@ -296,7 +296,7 @@ below.
 @showenumdesc{gnutls_x509_crl_reason_t,The revocation reasons}
 
 Note, that the OCSP response needs to be verified against some set of trust
-anchors before it can be relied upon. It is also important to check
+anchors before it can be relied upon.  It is also important to check
 whether the received OCSP response corresponds to the certificate being checked.
 
 @showfuncC{gnutls_ocsp_resp_verify,gnutls_ocsp_resp_verify_direct,gnutls_ocsp_resp_check_crt}
@@ -309,14 +309,14 @@ Transferring or storing private keys in plain may not be a
 good idea, since any compromise is irreparable.
 Storing the keys in hardware security modules (see @ref{Smart cards and HSMs})
 could solve the storage problem but it is not always practical
-or efficient enough. This section describes ways to store and
+or efficient enough.  This section describes ways to store and
 transfer encrypted private keys.
 
 There are methods for key encryption, namely the
 PKCS #8, PKCS #12 and OpenSSL's custom encrypted private key formats. 
 The PKCS #8 and the OpenSSL's method allow encryption of the private key, 
 while the PKCS #12 method allows, in addition, the bundling of accompanying 
-data into the structure. That is typically the corresponding certificate, as 
+data into the structure.  That is typically the corresponding certificate, as 
 well as a trusted CA certificate.
 
 @subsubheading High level functionality
@@ -335,10 +335,10 @@ they can be directly imported using @funcref{gnutls_certificate_set_x509_key_fil
 @cindex PKCS #8
 
 PKCS #8 keys can be imported and exported as normal private keys using
-the functions below. An addition to the normal import functions, are
-a password and a flags argument. The flags can be any element of the @code{gnutls_pkcs_encrypt_flags_t}
-enumeration. Note however, that GnuTLS only supports the PKCS #5 PBES2
-encryption scheme. Keys encrypted with the obsolete PBES1 scheme cannot 
+the functions below.  An addition to the normal import functions, are
+a password and a flags argument.  The flags can be any element of the @code{gnutls_pkcs_encrypt_flags_t}
+enumeration.  Note however, that GnuTLS only supports the PKCS #5 PBES2
+encryption scheme.  Keys encrypted with the obsolete PBES1 scheme cannot 
 be decrypted.
 
 @showfuncC{gnutls_x509_privkey_import_pkcs8,gnutls_x509_privkey_export_pkcs8,gnutls_x509_privkey_export2_pkcs8}
@@ -349,20 +349,20 @@ be decrypted.
 @cindex PKCS #12
 
 A @acronym{PKCS} #12 structure @xcite{PKCS12} usually contains a user's
-private keys and certificates. It is commonly used in browsers to
-export and import the user's identities. A file containing such a key can 
+private keys and certificates.  It is commonly used in browsers to
+export and import the user's identities.  A file containing such a key can 
 be directly imported to a certificate credentials structure by using 
 @funcref{gnutls_certificate_set_x509_simple_pkcs12_file}.
 
 In @acronym{GnuTLS} the @acronym{PKCS} #12 structures are handled
-using the @code{gnutls_pkcs12_t} type. This is an abstract type that
+using the @code{gnutls_pkcs12_t} type.  This is an abstract type that
 may hold several @code{gnutls_pkcs12_bag_t} types.  The bag types are
 the holders of the actual data, which may be certificates, private
 keys or encrypted data.  A bag of type encrypted should be decrypted
 in order for its data to be accessed.
 
 To reduce the complexity in parsing the structures the simple 
-helper function @funcref{gnutls_pkcs12_simple_parse} is provided. For more
+helper function @funcref{gnutls_pkcs12_simple_parse} is provided.  For more
 advanced uses, manual parsing of the structure is required using the
 functions below.
 
@@ -371,7 +371,7 @@ functions below.
 @showfuncdesc{gnutls_pkcs12_simple_parse}
 @showfuncC{gnutls_pkcs12_bag_get_data,gnutls_pkcs12_bag_get_key_id,gnutls_pkcs12_bag_get_friendly_name}
 
-The functions below are used to generate a PKCS #12 structure. An example
+The functions below are used to generate a PKCS #12 structure.  An example
 of their usage is shown at @ref{PKCS12 structure generation example}.
 
 @showfuncC{gnutls_pkcs12_set_bag,gnutls_pkcs12_bag_encrypt,gnutls_pkcs12_generate_mac}
@@ -380,8 +380,8 @@ of their usage is shown at @ref{PKCS12 structure generation example}.
 @subsubheading OpenSSL encrypted keys
 @cindex OpenSSL encrypted keys
 Unfortunately the structures discussed in the previous sections are
-not the only structures that may hold an encrypted private key. For example
-the OpenSSL library offers a custom key encryption method. Those structures
+not the only structures that may hold an encrypted private key.  For example
+the OpenSSL library offers a custom key encryption method.  Those structures
 are also supported in GnuTLS with @funcref{gnutls_x509_privkey_import_openssl}.
 
 @showfuncdesc{gnutls_x509_privkey_import_openssl}
diff --git a/doc/cha-crypto.texi b/doc/cha-crypto.texi
index 24b1b4d..958f228 100644
--- a/doc/cha-crypto.texi
+++ b/doc/cha-crypto.texi
@@ -2,10 +2,10 @@
 @chapter Using GnuTLS as a cryptographic library
 
 @acronym{GnuTLS} is not a low-level cryptographic library, i.e., 
-it does not provide access to basic cryptographic primitives. However
+it does not provide access to basic cryptographic primitives.  However
 it abstracts the internal cryptographic back-end (see @ref{Cryptographic Backend}),
 providing symmetric crypto, hash and HMAC algorithms, as well access
-to the random number generation. For a low-level crypto API the usage of nettle
+to the random number generation.  For a low-level crypto API the usage of nettle
 @footnote{See @uref{http://www.lysator.liu.se/~nisse/nettle/}.} library is recommended.
 
 @menu
@@ -21,7 +21,7 @@ to the random number generation. For a low-level crypto API the usage of nettle
 @cindex symmetric cryptography
 
 The available functions to access symmetric crypto algorithms operations
-are shown below. The supported algorithms are the algorithms required by the TLS protocol.
+are shown below.  The supported algorithms are the algorithms required by the TLS protocol.
 They are listed in @ref{tab:ciphers}.
 
 @showfuncE{gnutls_cipher_init,gnutls_cipher_encrypt2,gnutls_cipher_decrypt2,gnutls_cipher_set_iv,gnutls_cipher_deinit}
@@ -36,7 +36,7 @@ functions are provided to set the associated data and retrieve the authenticatio
 @cindex public key algorithms
 
 Public key cryptography algorithms such as RSA, DSA and ECDSA, can be
-accessed using the abstract key API in @ref{Abstract key types}. This
+accessed using the abstract key API in @ref{Abstract key types}.  This
 is a high level API with the advantage of transparently handling keys
 in memory and keys present in smart cards.
 
@@ -46,11 +46,11 @@ in memory and keys present in smart cards.
 @cindex HMAC functions
 
 The available operations to access hash functions and hash-MAC (HMAC) algorithms
-are shown below. HMAC algorithms provided keyed hash functionality. They supported HMAC algorithms are listed in @ref{tab:macs}.
+are shown below.  HMAC algorithms provided keyed hash functionality.  They supported HMAC algorithms are listed in @ref{tab:macs}.
 
 @showfuncF{gnutls_hmac_init,gnutls_hmac,gnutls_hmac_output,gnutls_hmac_deinit,gnutls_hmac_get_len,gnutls_hmac_fast}
 
-The available functions to access hash functions are shown below. The supported hash functions
+The available functions to access hash functions are shown below.  The supported hash functions
 are the same as the HMAC algorithms.
 
 @showfuncF{gnutls_hash_init,gnutls_hash,gnutls_hash_output,gnutls_hash_deinit,gnutls_hash_get_len,gnutls_hash_fast}
@@ -61,7 +61,7 @@ are the same as the HMAC algorithms.
 @cindex random numbers
 
 Access to the random number generator is provided using the @funcref{gnutls_rnd}
-function. It allows obtaining random data of various levels.
+function.  It allows obtaining random data of various levels.
 
 @showenumdesc{gnutls_rnd_level_t,The random number levels.}
 @showfuncdesc{gnutls_rnd}
diff --git a/doc/cha-functions.texi b/doc/cha-functions.texi
index da86cc4..8cac3c8 100644
--- a/doc/cha-functions.texi
+++ b/doc/cha-functions.texi
@@ -97,7 +97,7 @@ Their prototypes lie in @file{gnutls/abstract.h}.
 @section DANE API
 
 The following functions are to be used for DANE certificate verification.
-Their prototypes lie in @file{gnutls/dane.h}. Note that you need to link
+Their prototypes lie in @file{gnutls/dane.h}.  Note that you need to link
 with the @code{libgnutls-dane} library to use them.
 
 @include dane-api.texi
@@ -113,7 +113,7 @@ Their prototypes lie in @file{gnutls/crypto.h}.
 @node Compatibility API
 @section Compatibility API
 
-The following functions are carried over from old GnuTLS released. They might be removed at a later version.
+The following functions are carried over from old GnuTLS released.  They might be removed at a later version.
 Their prototypes lie in @file{gnutls/compat.h}.
 
 @include compat-api.texi
diff --git a/doc/cha-gtls-app.texi b/doc/cha-gtls-app.texi
index 805c0b5..56f0ee9 100644
--- a/doc/cha-gtls-app.texi
+++ b/doc/cha-gtls-app.texi
@@ -19,9 +19,9 @@
 @node Introduction to the library
 @section Introduction
 
-This chapter tries to explain the basic functionality of the current GnuTLS
-library. Note that there may be additional functionality not discussed here
-but included in the library. Checking the header files in @file{/usr/include/gnutls/}
+This chapter tries to explain the basic functionality of the current @acronym{GnuTLS}
+library.  Note that there may be additional functionality not discussed here
+but included in the library.  Checking the header files in @file{/usr/include/gnutls/}
 and the manpages is recommended.
 
 @menu
@@ -37,7 +37,7 @@ and the manpages is recommended.
 @subsection General idea
 
 A brief description of how @acronym{GnuTLS} sessions operate is shown
-at @ref{fig-gnutls-design}. This section will become more clear when it
+at @ref{fig-gnutls-design}.  This section will become more clear when it
 is completely read.
 As shown in the figure, there is a read-only global state that is
 initialized once by the global initialization function.  This global
@@ -55,14 +55,14 @@ finished using @acronym{GnuTLS}.
 @end float
 
 The credentials structures are used by the authentication methods, such
-as certificate authentication. They store certificates, privates keys,
+as certificate authentication.  They store certificates, privates keys,
 and other information that is needed to prove the identity to the peer,
-and/or verify the indentity of the peer. The information stored in
+and/or verify the indentity of the peer.  The information stored in
 the credentials structures is initialized once and then can be 
 shared by many @acronym{TLS} sessions.
 
 A @acronym{GnuTLS} session contains all the required information
-to handle one secure connection. The session communicates with the
+to handle one secure connection.  The session communicates with the
 peers using the provided functions of the transport layer.
 Every session has a unique session ID shared with the peer.
 
@@ -70,7 +70,7 @@ Since TLS sessions can be resumed, servers need a
 database back-end to hold the session's parameters.  Every
 @acronym{GnuTLS} session after a successful handshake calls the
 appropriate back-end function (see @ref{resume})
-to store the newly negotiated session. The session
+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},
 and if the session ID sent by the client, matches a stored session,
@@ -83,15 +83,15 @@ resumed one, and will share the same session ID with the previous one.
 In @acronym{GnuTLS} most functions return an integer type as a result.
 In almost all cases a zero or a positive number means success, and a
 negative number indicates failure, or a situation that some action has
-to be taken. Thus negative error codes may be fatal or not.
+to be taken.  Thus negative error codes may be fatal or not.
 
 Fatal errors terminate the connection immediately and further sends
 and receives will be disallowed.  Such an example is
-@code{GNUTLS_@-E_@-DECRYPTION_@-FAILED}. Non-fatal errors may warn about
+@code{GNUTLS_@-E_@-DECRYPTION_@-FAILED}.  Non-fatal errors may warn about
 something, i.e., a warning alert was received, or indicate the some
-action has to be taken. This is the case with the error code
+action has to be taken.  This is the case with the error code
 @code{GNUTLS_@-E_@-REHANDSHAKE} returned by @funcref{gnutls_record_recv}.
-This error code indicates that the server requests a re-handshake. The
+This error code indicates that the server requests a re-handshake.  The
 client may ignore this request, or may reply with an alert.  You can
 test if an error code is a fatal one by using the
 @funcref{gnutls_error_is_fatal}.
@@ -99,7 +99,7 @@ All errors can be converted to a descriptive string using @funcref{gnutls_strerr
 
 If any non fatal errors, that require an action, are to be returned by
 a function, these error codes will be documented in the function's
-reference. For example the error codes @code{GNUTLS_@-E_@-WARNING_@-ALERT_@-RECEIVED} and @code{GNUTLS_@-E_@-FATAL_@-ALERT_@-RECEIVED}
+reference.  For example the error codes @code{GNUTLS_@-E_@-WARNING_@-ALERT_@-RECEIVED} and @code{GNUTLS_@-E_@-FATAL_@-ALERT_@-RECEIVED}
 that may returned when receiving data, should be handled by notifying the
 user of the alert (as explained in @ref{Handling alerts}).
 See @ref{Error codes}, for a description of the available error codes.
@@ -108,11 +108,11 @@ See @ref{Error codes}, for a description of the available error codes.
 @subsection Common types
 
 All strings that are to provided as input to @acronym{GnuTLS} functions
-should be in UTF-8 unless otherwise specified. Output strings are also
+should be in UTF-8 unless otherwise specified.  Output strings are also
 in UTF-8 format unless otherwise specified.
 
 When data of a fixed size are provided to @acronym{GnuTLS} functions then
-the helper structure @code{gnutls_datum_t} is often used. Its definition is
+the helper structure @code{gnutls_datum_t} is often used.  Its definition is
 shown below.
 @verbatim
   typedef struct
@@ -123,7 +123,7 @@ shown below.
 @end verbatim
 
 Other functions that require data for scattered read use a structure similar
-to @code{struct iovec} typically used by @funcintref{readv}. It is shown
+to @code{struct iovec} typically used by @funcintref{readv}.  It is shown
 below.
 @verbatim
   typedef struct
@@ -140,14 +140,14 @@ below.
 In many cases things may not go as expected and further information,
 to assist debugging, from @acronym{GnuTLS} is desired. 
 Those are the cases where the @funcref{gnutls_global_set_log_level} and
-@funcref{gnutls_global_set_log_function} are to be used. Those will print
+@funcref{gnutls_global_set_log_function} are to be used.  Those will print
 verbose information on the @acronym{GnuTLS} functions internal flow.
 
 @showfuncB{gnutls_global_set_log_level,gnutls_global_set_log_function}
 
 Alternatively the environment variable @code{GNUTLS_DEBUG_LEVEL} can be
 set to a logging level and GnuTLS will output debugging output to standard
-error. Other available environment variables are shown in @ref{tab:environment}.
+error.  Other available environment variables are shown in @ref{tab:environment}.
 
 @float Table,tab:environment
 @multitable @columnfractions .30 .70
@@ -159,9 +159,9 @@ error. Other available environment variables are shown in @ref{tab:environment}.
 
 @item @code{GNUTLS_CPUID_OVERRIDE}
 @tab That environment variable can be used to
-explicitly enable/disable the use of certain CPU capabilities. Note that CPU
+explicitly enable/disable the use of certain CPU capabilities.  Note that CPU
 detection cannot be overriden, i.e., VIA options cannot be enabled on an Intel
-CPU. The currently available options are:
+CPU.  The currently available options are:
 @itemize
 @item 0x1: Disable all run-time detected optimizations
 @item 0x2: Enable AES-NI
@@ -181,11 +181,11 @@ CPU. The currently available options are:
 
 
 When debugging is not required, important issues, such as detected
-attacks on the protocol still need to be logged. This is provided
+attacks on the protocol still need to be logged.  This is provided
 by the logging function set by
-@funcref{gnutls_global_set_audit_log_function}. The provided function
+@funcref{gnutls_global_set_audit_log_function}.  The provided function
 will receive an message and the corresponding
-TLS session. The session information might be used to derive IP addresses
+TLS session.  The session information might be used to derive IP addresses
 or other information about the peer involved.
 
 @showfuncdesc{gnutls_global_set_audit_log_function}
@@ -196,18 +196,18 @@ or other information about the peer involved.
 
 The @acronym{GnuTLS} library is thread safe by design, meaning that
 objects of the library such as TLS sessions, can be safely divided across
-threads as long as a single thread accesses a single object. This is
+threads as long as a single thread accesses a single object.  This is
 sufficient to support a server which handles several sessions per thread.
 If, however, an object needs to be shared across threads then access must be 
-protected with a mutex. Read-only access to objects, for example the
+protected with a mutex.  Read-only access to objects, for example the
 credentials holding structures, is also thread-safe. 
 
 The random generator of the cryptographic back-end, utilizes mutex locks (e.g., pthreads on GNU/Linux and CriticalSection on Windows)
-which are setup by @acronym{GnuTLS} on library initialization. Prior to version 3.3.0
-they were setup by calling @funcref{gnutls_global_init}. On special systems
+which are setup by @acronym{GnuTLS} on library initialization.  Prior to version 3.3.0
+they were setup by calling @funcref{gnutls_global_init}.  On special systems
 you could manually specify the locking system using
 the function @funcref{gnutls_global_set_mutex} before calling any other
-GnuTLS function. Setting mutexes manually is not recommended.
+GnuTLS function.  Setting mutexes manually is not recommended.
 An example of non-native thread usage is shown below.
 
 @example
@@ -230,7 +230,7 @@ int main()
 @cindex callback functions
 
 There are several cases where @acronym{GnuTLS} may need out of
-band input from your program. This is now implemented using some
+band input from your program.  This is now implemented using some
 callback functions, which your program is expected to register.
 
 An example of this type of functions are the push and pull callbacks
@@ -240,7 +240,7 @@ data to the transport layer.
 @showfuncB{gnutls_transport_set_push_function,gnutls_transport_set_pull_function}
 
 Other callback functions may require more complicated input and data
-to be allocated. Such an example is 
+to be allocated.  Such an example is 
 @funcref{gnutls_srp_set_server_credentials_function}.
 All callbacks should allocate and free memory using 
 @funcintref{gnutls_malloc} and @funcintref{gnutls_free}.
@@ -250,7 +250,7 @@ All callbacks should allocate and free memory using
 @section Preparation
 
 To use @acronym{GnuTLS}, you have to perform some changes to your
-sources and your build system. The necessary changes are explained in
+sources and your build system.  The necessary changes are explained in
 the following subsections.
 
 @menu
diff --git a/doc/cha-library.texi b/doc/cha-library.texi
index cb65d68..f90b3ea 100644
--- a/doc/cha-library.texi
+++ b/doc/cha-library.texi
@@ -2,7 +2,7 @@
 @chapter Introduction to GnuTLS
 
 In brief @acronym{GnuTLS} can be described as a library which offers an API
-to access secure communication protocols. These protocols provide
+to access secure communication protocols.  These protocols provide
 privacy over insecure lines, and were designed to prevent
 eavesdropping, tampering, or message forgery.
 
@@ -10,7 +10,7 @@ Technically @acronym{GnuTLS} is a portable ANSI C based library which
 implements the protocols ranging from SSL 3.0 to TLS 1.2 (see @ref{Introduction to TLS}, 
 for a detailed description of the protocols), accompanied
 with the required framework for authentication and public key
-infrastructure.  Important features of the @acronym{GnuTLS} library
+infrastructure.   Important features of the @acronym{GnuTLS} library
 include:
 
 @itemize
@@ -31,7 +31,7 @@ include:
 
 The @acronym{GnuTLS} library consists of three independent parts, namely the ``TLS
 protocol part'', the ``Certificate part'', and the ``Cryptographic
-back-end'' 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 and it uses
@@ -81,7 +81,7 @@ libtasn1 in other programs), you can get it from
 
 The compression library, @code{libz}, the PKCS #11 helper library @code{p11-kit}, as well
 as the TPM library @code{trousers}, are 
-optional dependencies. You may get libz from @url{http://www.zlib.net/}, 
+optional dependencies.  You may get libz from @url{http://www.zlib.net/}, 
 p11-kit from @url{http://p11-glue.freedesktop.org/} and trousers from
 @url{http://trousers.sourceforge.net/}.
 
@@ -116,10 +116,10 @@ For the complete list, refer to the output from @code{configure --help}.
 @section Overview
 In this document we present an overview of the supported security protocols in @ref{Introduction to TLS}, and 
 continue by providing more information on the certificate authentication in @ref{Certificate authentication},
-and shared-key as well anonymous authentication in @ref{Shared-key and anonymous authentication}. We
+and shared-key as well anonymous authentication in @ref{Shared-key and anonymous authentication}.  We
 elaborate on certificate authentication by demonstrating advanced usage of the API in @ref{More on certificate authentication}.
 The core of the TLS library is presented in @ref{How to use GnuTLS in applications} and example
 applications are listed in @ref{GnuTLS application examples}.
 In @ref{Other included programs} the usage of few included programs that
-may assist debugging is presented. The last chapter is @ref{Internal architecture of GnuTLS} that
+may assist debugging is presented.  The last chapter is @ref{Internal architecture of GnuTLS} that
 provides a short introduction to GnuTLS' internal architecture.
diff --git a/doc/sec-tls-app.texi b/doc/sec-tls-app.texi
index 89a10e7..02d3ad0 100644
--- a/doc/sec-tls-app.texi
+++ b/doc/sec-tls-app.texi
@@ -1,7 +1,7 @@
 @node How to use TLS in application protocols
 @section How to use @acronym{TLS} in application protocols
 
-This chapter is intended to provide some hints on how to use the
+This chapter is intended to provide some hints on how to use
 @acronym{TLS} over simple custom made application protocols.  The
 discussion below mainly refers to the @acronym{TCP/IP} transport layer
 but may be extended to other ones too.
@@ -15,15 +15,15 @@ but may be extended to other ones too.
 @subsection Separate ports
 
 Traditionally @acronym{SSL} was used in application protocols by
-assigning a new port number for the secure services. That way two
-separate ports were assigned, one for the non secure sessions, and one
-for the secured ones. This has the benefit that if a user requests a
-secure session then the client will try to connect to the secure port
-and fail otherwise. The only possible attack with this method is a
-denial of service one. The most famous example of this method is the
-famous ``HTTP over TLS'' or @acronym{HTTPS} protocol @xcite{RFC2818}.
-
-Despite its wide use, this method is not as good as it seems.  This
+assigning a new port number for the secure services.  By doing this two
+separate ports were assigned, one for the non-secure sessions, and one
+for the secure sessions.  This method ensures that if a user requests a
+secure session then the client will attempt to connect to the secure port
+and fail otherwise.  The only possible attack with this method is to perform
+a denial of service attack.  The most famous example of this method is
+``HTTP over TLS'' or @acronym{HTTPS} protocol @xcite{RFC2818}.
+
+Despite its wide use, this method has several subtle issues.  This
 approach starts the @acronym{TLS} Handshake procedure just after the
 client connects on the ---so called--- secure port.  That way the
 @acronym{TLS} protocol does not know anything about the client, and
@@ -34,22 +34,22 @@ connected to YYY server'' before the Handshake starts, so the server
 cannot possibly know which certificate to use.
 
 Other than that it requires two separate ports to run a single
-service, which is unnecessary complication. Due to the fact that there
-is a limitation on the available privileged ports, this approach was
-soon obsoleted.
+service, which is unnecessarily complicated.  Due to the fact that there
+is a limitation on the available privileged ports (ports lower than 1024),
+this approach was soon deprecated in favor of the upward negotiation.
 
 @node Upward negotiation
 @subsection Upward negotiation
 
-Other application protocols@footnote{See LDAP, IMAP etc.}  use a
-different approach to enable the secure layer.  They use something
-often called as the ``TLS upgrade'' method. This method is quite tricky but it
-is more flexible. The idea is to extend the application protocol to
+Other application protocols@footnote{See LDAP, IMAP etc.} use a
+different approach to enable the secure layer.  They use a method
+often called the ``TLS upgrade'' method.  This method is quite tricky but it
+is more flexible.  The idea is to extend the application protocol to
 have a ``STARTTLS'' request, whose purpose it to start the TLS
 protocols just after the client requests it.  This approach
-does not require any extra port to be reserved.
-There is even an extension to HTTP protocol to support 
-that method @xcite{RFC2817}.
+does not require any extra ports to be reserved.
+There is even an extension to the HTTP protocol to support 
+this method @xcite{RFC2817}.
 
 The tricky part, in this method, is that the ``STARTTLS'' request is
 sent in the clear, thus is vulnerable to modifications.  A typical
@@ -92,12 +92,13 @@ SERVER: SORRY I DON'T HAVE THIS CAPABILITY
 CLIENT: HERE ARE SOME CONFIDENTIAL DATA
 @end quotation
 
-As you can see above the client was fooled, and was dummy enough to
-send the confidential data in the clear.
+As you can see above the client was fooled, and was na@"ive enough to
+send the confidential data in the clear, despite the server telling the
+client that it does not support ``STARTTLS''.
 
-How to avoid the above attack? As you may have already noticed this
-one is easy to avoid. The client has to ask the user before it
-connects whether the user requests @acronym{TLS} or not. If the user
+How do we avoid the above attack? As you may have already noticed this
+situation is easy to avoid.  The client has to ask the user before it
+connects whether the user requests @acronym{TLS} or not.  If the user
 answered that he certainly wants the secure layer the last
 conversation should be:
 
@@ -121,7 +122,7 @@ CLIENT: BYE
 
 This method, if implemented properly, is far better than the
 traditional method, and the security properties remain the same, since
-only denial of service is possible. The benefit is that the server may
+only denial of service is possible.  The benefit is that the server may
 request additional data before the @acronym{TLS} Handshake protocol
 starts, in order to send the correct certificate, use the correct
 password file, or anything else!
