More intelligent path finding

[Nikos Mavrogiannopoulos]

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,
GNUTLS_VERIFY_RFC5280 }

/*
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.
*/

int
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.


regards,
Nikos