more updates

diff --git a/doc/cha-cert-auth.texi b/doc/cha-cert-auth.texi
index f51c7890d43531753e1ae4ab821d86a92bb58e16..c918c7b9dfa8ef6db72ad09429c5cd42eda1063b 100644 (file)
--- a/doc/cha-cert-auth.texi
+++ b/doc/cha-cert-auth.texi
@@ -146,8 +146,8 @@ Verifying certificate paths is important in @acronym{X.509}
 authentication. For this purpose the following functions are
 provided.
 
-@showfuncdesc{gnutls_x509_trust_list_init}
-@showfuncdesc{gnutls_x509_trust_list_deinit}
+@showfuncB{gnutls_x509_trust_list_init,gnutls_x509_trust_list_deinit}
+
 @showfuncdesc{gnutls_x509_trust_list_add_cas}
 @showfuncdesc{gnutls_x509_trust_list_add_named_crt}
 @showfuncdesc{gnutls_x509_trust_list_add_crls}
@@ -156,7 +156,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} 
+a bit-wise OR of elements of the @code{gnutls_\-certificate_\-status_t} 
 enumeration. 
 A detailed description of these elements can be found 
 in @ref{tab:cert-verify}. An example of certificate verification is shown in @ref{ex:verify2}.
@@ -285,7 +285,9 @@ are not currently supported.
 
 A certificate request can be generated by
 associating it with a private key, setting the
-subject's information and self signing it.
+subject's information and finally self signing it.
+The last step ensures that the requester is in
+possession of the private key.
 
 @showfuncdesc{gnutls_x509_crq_set_version}
 @showfuncdesc{gnutls_x509_crq_set_dn_by_oid}
@@ -302,7 +304,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}
@@ -675,7 +677,7 @@ the following functions.
 
 @subsection Operations
 The abstract key types can be used to access signing and
-signature verification operations on the underlying keys.
+signature verification operations with the underlying keys.
 
 @showfuncdesc{gnutls_pubkey_verify_data2}
 @showfuncdesc{gnutls_pubkey_verify_hash}

diff --git a/doc/cha-intro-tls.texi b/doc/cha-intro-tls.texi
index a27c21784e2db28168952fa6f3f1d965158d25fd..7ab0361cb0395fab7478af18db045d8b7e5d4d21 100644 (file)
--- a/doc/cha-intro-tls.texi
+++ b/doc/cha-intro-tls.texi
@@ -344,9 +344,7 @@ the initial key exchange, and the authentication of the two peers.
 This is fully controlled by the application layer, thus your program
 has to set up the required parameters. The main handshake function
 is @funcref{gnutls_handshake}. In the next paragraphs we elaborate on 
-controlling of the handshake protocol, i.e., the ciphersuite negotiation.
-
-@showfuncA{gnutls_handshake}
+the handshake protocol, i.e., the ciphersuite negotiation.
 
 
 @menu