[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: The _gnutls_x509_verify_certificate fix
From: |
Simon Josefsson |
Subject: |
Re: The _gnutls_x509_verify_certificate fix |
Date: |
Tue, 11 Nov 2008 16:51:45 +0100 |
User-agent: |
Gnus/5.110011 (No Gnus v0.11) Emacs/22.2 (gnu/linux) |
Sam Varshavchik <address@hidden> 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
- Re: The _gnutls_x509_verify_certificate fix, (continued)
- Re: The _gnutls_x509_verify_certificate fix, Simon Josefsson, 2008/11/11
- Re: The _gnutls_x509_verify_certificate fix, Simon Josefsson, 2008/11/11
- Re: The _gnutls_x509_verify_certificate fix, Tomas Mraz, 2008/11/11
- Re: The _gnutls_x509_verify_certificate fix, Simon Josefsson, 2008/11/11
- Re: The _gnutls_x509_verify_certificate fix, Andreas Metzler, 2008/11/11
- Re: The _gnutls_x509_verify_certificate fix, Simon Josefsson, 2008/11/11
- Re: The _gnutls_x509_verify_certificate fix, Simon Josefsson, 2008/11/12
- Re: The _gnutls_x509_verify_certificate fix, Andreas Metzler, 2008/11/12
Re: The _gnutls_x509_verify_certificate fix, Sam Varshavchik, 2008/11/10
- Re: The _gnutls_x509_verify_certificate fix, Werner Koch, 2008/11/11
- Re: The _gnutls_x509_verify_certificate fix,
Simon Josefsson <=
- supporting out-of-process certificate validation [was: Re: The _gnutls_x509_verify_certificate fix], Daniel Kahn Gillmor, 2008/11/11
- Re: supporting out-of-process certificate validation, Simon Josefsson, 2008/11/12
- Re: supporting out-of-process certificate validation, Werner Koch, 2008/11/12
- Re: supporting out-of-process certificate validation, Simon Josefsson, 2008/11/12
- Re: supporting out-of-process certificate validation, Werner Koch, 2008/11/12
trusted intermediate CAs [was: Re: The _gnutls_x509_verify_certificate fix], Daniel Kahn Gillmor, 2008/11/11
Re: trusted intermediate CAs, Simon Josefsson, 2008/11/12
Re: trusted intermediate CAs, Daniel Kahn Gillmor, 2008/11/12
Re: trusted intermediate CAs, Nikos Mavrogiannopoulos, 2008/11/12
Re: trusted intermediate CAs, Daniel Kahn Gillmor, 2008/11/12