Bug#514807: Regression in libgnutls security update

[Simon Josefsson]

Daniel Kahn Gillmor <dkg at fifthhorseman.net> writes:

> One option, of course, is to change the interface of GnuTLS to cleanly
> separate out trusted peer certificates from trusted CA certificates in
> the API.  This would permit users to specify how they intend to use a
> given V1 cert.  Of course, this would also require an API change,
> potentially an soname bump, etc.  In the absence of such a change, i
> think it's safer to strongly deprecate V1 certificates (as has been
> documented for years, if not enforcced), and let applications which
> choose to treat the trusted certificate list solely as a CA store
> specify so explicitly with GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT.

Agreed.  V1 certificates should be deprecated.  I believe the best we
can achieve is to have a flag that allows callers to ignore the security
problem and accept V1 CAs.  But we have that, and have had it for a long
time.  The defaults should be secure.

I just added in GnuTLS v2.7.x a priority string flag for this, so if
applications are enhanced to use the priority string functionality (not
many do yet), users will be able to set the flag easily.  See NEWS:

** gnutls-cli: No longer accepts V1 CAs by default during X.509 chain verify.
Use --priority NORMAL:%VERIFY_ALLOW_X509_V1_CA_CRT to permit V1 CAs to
be used for chain verification.
...
** libgnutls: New priority strings %VERIFY_ALLOW_SIGN_RSA_MD5
** and %VERIFY_ALLOW_X509_V1_CA_CRT.
They can be used to override the default certificate chain validation
behaviour.

/Simon