More intelligent path finding

[Martin von Gagern]

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 far for my own ideas. I already included them in some private
correspondence with Simon, and he mentioned that this might cause DoS
issues, and that a DoS-proof setup should theoretically start at the
trusted root. As an alternative, one could find the path as described
above by simply looking at the distinguished names (and maybe some other
elements used to distinguish certificates over time?) and verify the
whole path the classical way once it's been found.

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.

Greetings,
 Martin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20081111/615d7298/attachment.pgp>