]> git.ipfire.org Git - thirdparty/gnutls.git/commitdiff
Corrected some things in documentation. Got from Debian bug tracking system, Reported...
authorNikos Mavrogiannopoulos <nmav@gnutls.org>
Thu, 30 Oct 2003 18:39:03 +0000 (18:39 +0000)
committerNikos Mavrogiannopoulos <nmav@gnutls.org>
Thu, 30 Oct 2003 18:39:03 +0000 (18:39 +0000)
doc/tex/auth.tex
doc/tex/handshake.tex
doc/tex/howto.tex

index b2588938b3db6b7c55ea51d7445a2f2500078a9d..b5d028bfcb3ba4e47a036639e8b3afc6587660bd 100644 (file)
@@ -29,8 +29,9 @@ the key to be used for signing. Note that key exchange algorithms which use
 Ephemeral Diffie Hellman parameters, offer perfect forward secrecy.
 \\
 \hline
-DHE\_DSS & The DSS\footnote{DSS stands for Digital Signature Standard} algorithm is used to sign Ephemeral Diffie Hellman
-parameters which are sent to the peer. 
+DHE\_DSS & The DSS algorithm is used to sign Ephemeral Diffie Hellman
+parameters which are sent to the peer. DSS stands for Digital Signature
+Standard.
 \\
 \hline
 \end{tabular}
index e34889aa0762215e0f801d3c3f73dd544fc876f8..3b1a8305cc821e3a0030c38b8a4fdec453edce10 100644 (file)
@@ -39,10 +39,9 @@ In the case of ciphersuites that use certificate authentication, the
 authentication\index{Certificate authentication!Client} of the client is
 optional in \tls{}. A server may request a certificate from the client -- using the
 \printfunc{gnutls_certificate_server_set_request}{gnutls\_certificate\_server\_set\_request}
-function. If a certificate is to be requested by the client, at the handshake
-procedure, the server will send an extra packet,
-than contains a list of acceptable certificate signers, and indicates the
-request of a certificate. The client may then send a certificate, signed
+function. If a certificate is to be requested from the client during the handshake,
+the server will send a certificate request message that contains
+a list of acceptable certificate signers. The client may then send a certificate, signed
 by one of the server's acceptable signers. In \gnutls{} the server's acceptable
 signers list is constructed using the trusted CA certificates in the
 credentials structure.
index 73d8d4e2e5da6a66999537c22c3b06d658e782c1..19997ace22a54e893d24c1f82ca61368a75dd7a3 100644 (file)
@@ -7,10 +7,11 @@ over simple custom made application protocols.
 The discussion below mainly refers to the \emph{TCP/IP} transport layer
 but may be extended to other ones too.
 
-\section{The traditional way}
+\section{Separate ports}
 
 Traditionally \ssl{} was used in application protocols by assigning 
-a new port number for the secure services. That way two ports were assigned, one for the
+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
@@ -34,7 +35,7 @@ unnecessary complication. Due to the fact that there is a limitation on
 the available privileged ports, this approach was soon obsoleted.
 
 
-\section{A different approach}
+\section{Upward negotiation}
 Other application protocols\footnote{See LDAP, IMAP etc.}
 use a different approach to enable the secure layer.
 They use something called the ``TLS upgrade'' method. This method