gnutls-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gnutls fails to use Verisign CA cert without a Basic Constraint


From: Nikos Mavrogiannopoulos
Subject: Re: gnutls fails to use Verisign CA cert without a Basic Constraint
Date: Sat, 10 Jan 2009 15:56:32 +0200

On Sat, 10 Jan 2009 13:05:05 +0100

> Nikos, what do you think?  You wrote the code here, and introduced the
> work-around flags to deal with V1 certs.

X.509 v1 certificates are quite dangerous to use and should be avoided
because of the inherited issues with them (a V1 CA certificate cannot be
distinguished from a V1 server certificate or a V1 person certificate,
thus if one has a V1 server certificate in his trusted certificate list
wouldn't want to trust it as a CA as well).

For these reasons V1, certificates are not trusted to be signers by
default unless the following two flags are set:

1. GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT

This one allows a v1 certificate from the trusted list to be valid as
a CA (here one must know that he should not add V1 server certificates
in his trusted list).

2. GNUTLS_VERIFY_ALLOW_ANY_X509_V1_CA_CRT

This one is quite dangerous. It allows any intermediate V1 certificate
to be used as a signer. This means that if I manage to get a CA to give
me a V1 personal certificate, I can act as a CA if this flag is set.


> For things that aren't documented, I think we can be pragmatic and
> come up with quick fixes and apply them to the v2.6.x branch as
> needed.  But anything that changes documented and intended behaviour
> is not appropriate for our stable branch IMHO.

I didn't follow the issue closely, but I'd be against any change of the
V1 certificate handling unless there is a good reason to do so. V1
certificates should not be used any more.

> > If the code change on you TODO list to stop when an intermediate CA
> > cert is found on the trusted CA list, then this would solve my
> > problem, as the intermediate cert is V3 and has CA:TRUE, and is
> > trusted.
> Yup.  Fixing that would be neat, and could go onto the v2.7.x branch
> which we could release as the next stable branch relatively quickly.

About releasing 2.7, I think we should wait for the TLS 1.2 support to be 
completed or
remove it from the supported list.

regards,
Nikos




reply via email to

[Prev in Thread] Current Thread [Next in Thread]