Bug#514807: Regression in libgnutls security update

[Simon Josefsson]

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

> * Simon Josefsson:
>
>> What are the possible channels to communicate to etch users that they
>> will get (intentional) errors from gnutls if they have 1) a V1
>> certificate in their certificate chains, or 2) have a RSA-MD2/MD5
>> signature in non-trusted certificates in their chain?  Perhaps a wiki
>> page will help to explain the issue better than this bug report e-mail
>> thread can do.
>
> There doesn't seem to be industry consensus that X.509v1 root
> certificates are a bad idea.  This means that users have little
> leverage against CAs and server operators when confronted with
> problematic certificates.

Doesn't the same hold for RSA-MD5 signatures?  I'm not sure industry
consensus is a good measure here.  What we are relying on here is this
part of RFC 5280:

      (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 doesn't have any API to provide this out-of-band information, so
we simply reject version 1 certificates (unless a flag is set).

Hm.  It is interesting that it says 'intermediate certificates' in the
last sentence.  I think this is mistaken, the part of the algorithm
applies to root certificates as well as end-entity certificates too.

> Furthermore, arguments based on the age of those certificates and the
> resulting deficiencies are not that convincing because most root
> certificates share one or more of those flaws.  The whole system is a
> mess and has little to do with security (whatever it is).  The lack of
> accountability and transparency (who owns which root certificates?)
> and the disregard for cryptographic best practices (on key sizes and
> rollovers) is quite stunning.

I completely agree.

/Simon