Bug#514807: a proposal for consideration for V1 CA certs in Etch (and Lenny?)

Nikos Mavrogiannopoulos nmav at gnutls.org
Sat Feb 21 11:36:10 UTC 2009

Daniel Kahn Gillmor wrote:
> Thanks for the feedback, Simon.
> On 02/19/2009 05:02 PM, Simon Josefsson wrote:
>> Daniel Kahn Gillmor <dkg at fifthhorseman.net> writes:
>>> 3) default to having GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT be set
>> This is essentially the (untested) patch I proposed earlier.
>>> (this may mean that there is *no way* to turn this flag off --
>>> hopefully people who know gnutls better than myself can say if this is
>>> the case)
>> Applications can still call gnutls_certificate_set_verify_flags to
>> override the default.
> Good point.  I appreciate the clarification.
>> While I was negative initially, I think there are some arguments for
>> this solution: it only enables V1 CAs that the user has _explicitly_
>> marked as trusted.  So the user could be informed through documentation
>> that if he adds V1 CAs as a trusted certs, they may lead to the security
>> problems with V1 certs.
> My understanding is that the security problem is with adding V1
> *end-entity* certificates to the trusted certificate list.  If you do
> so, and we go with option 3, those EE certificates would be able to act
> as certificate authorities because GnuTLS is unable to distinguish the
> two classes of certificate.  But this doesn't indicate any problems with
> adding V1 CA certs, only EE certs, no?  

Indeed it affects end entity certs. I missed the discussion though I
understand it is about V1 CAs and being disabled by default. To be
honest although V1 certificates have been deprecated for more than a
decade CAs still use the V1 format for their certificates
(ca-certificates contains more than 10 of these).

However allowing them by default will make applications that rely on
adding end-entity certificates to the trusted certificate list insecure.
Thus it might be better for applications to explicitly enable this flag
if they do not use end-entity certificates there.


More information about the Pkg-gnutls-maint mailing list