gnutls-commit
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[SCM] GNU gnutls branch, master, updated. gnutls_2_11_6-72-gfb94366


From: Nikos Mavrogiannopoulos
Subject: [SCM] GNU gnutls branch, master, updated. gnutls_2_11_6-72-gfb94366
Date: Tue, 01 Feb 2011 18:18:41 +0000

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU gnutls".

http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=fb94366036929f33471a680fe9fa304132b37c4b

The branch, master has been updated
       via  fb94366036929f33471a680fe9fa304132b37c4b (commit)
      from  1750efbbd46e4141985cb4561df521591366e16f (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit fb94366036929f33471a680fe9fa304132b37c4b
Author: Nikos Mavrogiannopoulos <address@hidden>
Date:   Tue Feb 1 19:18:30 2011 +0100

    Documented the new verification functions.

-----------------------------------------------------------------------

Summary of changes:
 doc/cha-cert-auth.texi   |   48 ++++++++++++++++++++++++++++++++++++++-------
 doc/cha-gtls-app.texi    |   13 +++++++----
 doc/examples/ex-verify.c |    3 +-
 3 files changed, 49 insertions(+), 15 deletions(-)

diff --git a/doc/cha-cert-auth.texi b/doc/cha-cert-auth.texi
index 9c1955c..08f1e1c 100644
--- a/doc/cha-cert-auth.texi
+++ b/doc/cha-cert-auth.texi
@@ -132,13 +132,45 @@ section @ref{ex:x509-info}.
 @cindex Verifying certificate paths
 
 Verifying certificate paths is important in @acronym{X.509}
-authentication. For this purpose the function
address@hidden is provided. The output of this function
-is the bitwise OR of the elements of the
address@hidden enumeration.  A detailed
-description of these elements can be found in figure below.  The
-function @ref{gnutls_certificate_verify_peers2} is equivalent to the
-previous one, and will verify the peer's certificate in a TLS session.
+authentication. For this purpose the following functions are
+provided.
+
address@hidden @code
+
address@hidden @ref{gnutls_x509_trust_list_init}:
+A function to initialize a list that will hold trusted
+certificate authorities and certificate revocation lists.
+
address@hidden @ref{gnutls_x509_trust_list_deinit}:
+Deinitializes the list.
+
address@hidden @ref{gnutls_x509_trust_list_add_cas}:
+Adds certificate authorities to the list.
+
address@hidden @ref{gnutls_x509_trust_list_add_crls}:
+Adds certificate revocation lists.
+
address@hidden @ref{gnutls_x509_trust_list_verify_crt}:
+Verifies a certificate chain using the previously setup trusted
+list. A callback can be specified that will provide information
+about the verification procedure (and detailed reasons of failure).
+
address@hidden table
+
+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} 
+enumeration.  A detailed description of these elements can be found 
+in figure below.  An example of these functions in use can be found
+in @ref{ex:verify2}.
+
+When operating in the context of a TLS session, the trusted certificate
+authority list has been set via the
address@hidden and @ref{gnutls_certificate_set_x509_crl_file},
+thus it is not required to setup a trusted list as above.
+Convenience functions such as @ref{gnutls_certificate_verify_peers2} 
+are equivalent and will verify the peer's certificate chain
+in a TLS session.
 
 @table @code
 
@@ -166,7 +198,7 @@ MD5.  These algorithms have been broken and should not be 
trusted.
 @end table
 
 There is also to possibility to pass some input to the verification
-functions in the form of flags. For @ref{gnutls_x509_crt_verify} the
+functions in the form of flags. For @ref{gnutls_x509_trust_list_verify_crt} the
 flags are passed straightforward, but
 @ref{gnutls_certificate_verify_peers2} depends on the flags set by
 calling @ref{gnutls_certificate_set_verify_flags}.  All the available
diff --git a/doc/cha-gtls-app.texi b/doc/cha-gtls-app.texi
index 6196473..2f0707d 100644
--- a/doc/cha-gtls-app.texi
+++ b/doc/cha-gtls-app.texi
@@ -234,11 +234,6 @@ treat the connection as being a secure one.
 
 @verbatiminclude examples/ex-rfc2818.c
 
-Another example is listed below which uses the high level verification
-functions.
-
address@hidden examples/ex-verify.c
-
 @node Using a callback to select the certificate to use
 @subsection Using a Callback to Select the Certificate to Use
 
@@ -249,6 +244,14 @@ certificate selection callback.
 
 @verbatiminclude examples/ex-cert-select.c
 
address@hidden Verifying a certificate
address@hidden Verifying a Certificate
address@hidden:verify2}
+
+An example is listed below which uses the high level verification
+functions to verify a given certificate list.
+
address@hidden examples/ex-verify.c
 
 @node Client using a PKCS #11 token with TLS
 @subsection Using a @acronym{PKCS #11} token with TLS
diff --git a/doc/examples/ex-verify.c b/doc/examples/ex-verify.c
index f71039a..433210c 100644
--- a/doc/examples/ex-verify.c
+++ b/doc/examples/ex-verify.c
@@ -29,8 +29,7 @@ static int print_details_func(gnutls_x509_crt_t cert,
  * also check if the hostname matches.
  */
 void
-verify_certificate_chain (gnutls_session_t session,
-                          const char *hostname,
+verify_certificate_chain (const char *hostname,
                           const gnutls_datum_t * cert_chain,
                           int cert_chain_length)
 {


hooks/post-receive
-- 
GNU gnutls



reply via email to

[Prev in Thread] Current Thread [Next in Thread]