The _gnutls_x509_verify_certificate fix

[Simon Josefsson]

Sam Varshavchik <mrsam at courier-mta.com> writes:

> Tomas Mraz writes:
>
>> self-signed site certificate. Is there some other method how this could
>> be achieved? If not, then perhaps the test for the self-signed should be
>> performed only when clist_size > 1. Also the test for the clist_size
>> should be first test of the if().
>>
>> The other limitation is that only the last certificate (after removing
>> eventual self-signed cert at the end of the chain) is checked against
>> the trusted list. That means you can not put just an intermediate CA
>> cert into the trusted list to be able to verify the chain.
>>
>> What do you think of these limitations, should they be removed?
>
> Here's how I always thought certificate verifications should work:
>
> 1) The first certificate must be one of your trusted certs
>
> 2) Each one of the following certificates must be signed by the
> previous one, ending with the peer's certificate
>
> It makes no sense to search the trusted list for any intermediate
> certs, neither does it make sense to treat self-signed certs in any
> special way. All of the root, trusted, certs are self-signed certs,
> the above logic works correctly for them.

RFC 3280 section 6 contains one algorithm, and I think we need good
arguments to deviate from it.

I believe it is useful to explicitly trust an intermediate CA
certificate rather than the root CA though: consider if I purchase a CA
certificate from VeriSign: on some environments, I may want to configure
applications to trust my CA (whose private key I control) rather then
VeriSign's.  Opens up for problems with revocation of my CA certificate,
but still...

Generally, I don't think X.509 validation belongs in the same process as
a TLS client or server -- it is complex and mistakes will happen, it is
better to put all X.509 handling (including private key handling) in a
separate process.

/Simon