Bug#514807: Regression in libgnutls security update
simon at josefsson.org
Thu Feb 12 10:40:28 UTC 2009
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
GnuTLS has no way to provide this out-of-band knowledge that a V1
certificate is a CA or not.
diff --git a/lib/gnutls_cert.c b/lib/gnutls_cert.c
index 7872f20..fe7ad22 100644
@@ -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;
More information about the Pkg-gnutls-maint