More intelligent path finding

Nikos Mavrogiannopoulos nmav at
Thu Nov 13 19:29:30 CET 2008

Martin von Gagern wrote:
> Hi again.
> While looking at _gnutls_x509_verify_certificate I realized that I
> personally would have implemented this whole verification process a bit
> differently. I'm not a regular reader of the gnutls-devel list, but I
> have the feeling that some recent posts might go in the same direction.
> I'd have the function called with a single certificate to verify, a list
> of untrusted certificates to be used for the chain, and a list of
> trusted certificates to be used as the root. The verification process
> would look for the issuer of the current certificate first in the list
> of trusted certificates. If it finds one, verify and return result. If
> not, look for the issuer in the list of untrusted certificates. If it
> finds one, verify that next (recursively), if not we don't have enough
> material for a chain.
> This process would have two benefits. The order in which the
> intermediate certificates are submitted wouldn't matter any more. And
> you could also add some intermediate certificate to the list of trusted
> certificates, in order to trust a subtree of the hierarchy, and the
> server could still continue to submit its whole chain. E.g. a server A
> could submit the chain [A, B, C, D, E], with E as a self-signed root.
> When you only want to trust certificates from C, you would add that to
> your list of trusted CAs, never mind that it's not self signed, and
> GnuTLS would accept A after verifying two signatures, A-B and B-C.

> So much for my suggestion. I would assume that this should be fairly
> easy to implement. I don't know whether I will find the time for this in
> the forseeable future, though, especially as I still haven't read large
> parts of the GnuTLS codebase. So I offer this for discussion, and leave
> it for you to comment, maybe even implement, or wait until I find the
> time and motivation.

Hello Martin,
 Indeed we are discussing possibility of updating the included
verification procedure. My opinion would be to leave the current
implementation of gnutls_certificate_verify_peers2() as it is now, and
enhance the X.509 library with more flexibility in verification.

My thoughs in API would be:

add in
enum certificate_verify_flags { GNUTLS_VERIFY_LIST_UNORDERED,

When GNUTLS_VERIFY_LIST_UNORDERED is specified then the chain is
constructed on the fly by using the algorithm you propose.

The flag GNUTLS_VERIFY_RFC5280 should use the verification discussed in
rfc5280. However this algorithm is complex and there are many things
that can go wrong when implementing it.

One could enhance the verification function as:

struct {
	gnutls_x509_crt_t crt;
	unsigned int verification_status;
	verify_chain * issuer;
} verify_chain;

This structure will be used to notify the caller about the constructed
chain and about the verification status of this certificate verified by
the issuer.

gnutls_x509_crt_list_verify2 (const gnutls_x509_crt_t * cert_list,
                             int cert_list_length,

                             const gnutls_x509_crt_t * CA_list,
                             int CA_list_length,

                             const gnutls_x509_crl_t * CRL_list,
                             int CRL_list_length,

			     unsigned int flags,
			     time_t now, /* current time */
			     verify_chain *chain,
			     unsigned int max_chain_size, /* require the caller to allocate
chain */
                             unsigned int *verify)

Said, that. I'm unable to work on something like that in the near future.


More information about the Gnutls-devel mailing list