Bug#514807: Regression in libgnutls security update

[Simon Josefsson]

Florian Weimer <fw at deneb.enyo.de> writes:

> Simon, could we make the harmless variant (X.509v1 certificate set as
> trusted is accepted as a root CA, but intermediate X.509v1
> certificates aren't accepted) the default in etch?

It is possible to allow V1 certs to be used as roots when validating
certificates by default, see untested patch below.  I wouldn't agree
that it is harmless: if there is a V1 end-entity certificate in the
trusted cert list, it will be usable as a CA certificate as well.

It may be that the practical problems are more important than the
potential security problem here, which would argue for using the patch.
I'm not the best person to judge that.  If the patch is used, some
documentation is needed to alert users that they should not put V1 end
entity certificates in their trusted ca list.  I wouldn't want to see
security incidents because of this trade-off.

RFC 5280 has discussion about this:

      (k)  If certificate i is a version 3 certificate, verify that the
           basicConstraints extension is present and that cA is set to
           TRUE.  (If certificate i is a version 1 or version 2
           certificate, then the application MUST either verify that
           certificate i is a CA certificate through out-of-band means
           or reject the certificate.  Conforming implementations may
           choose to reject all version 1 and version 2 intermediate
           certificates.)

GnuTLS has no way to provide this out-of-band knowledge that a V1
certificate is a CA or not.

/Simon

diff --git a/lib/gnutls_cert.c b/lib/gnutls_cert.c
index 7872f20..fe7ad22 100644
--- a/lib/gnutls_cert.c
+++ b/lib/gnutls_cert.c
@@ -280,6 +280,7 @@ gnutls_certificate_allocate_credentials (gnutls_certificate_credentials_t *
 
   (*res)->verify_bits = DEFAULT_VERIFY_BITS;
   (*res)->verify_depth = DEFAULT_VERIFY_DEPTH;
+  (*res)->verify_flags = GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT;
 
   return 0;
 }