Security implications of (not using) GNUTLS_VERIFY_DO_NOT_ALLOW_SAME

[Lars Noschinski]

* Nikos Mavrogiannopoulos <nmav at gnutls.org> [10-06-21 13:06]:
> On Mon, Jun 21, 2010 at 12:43 PM, Lars Noschinski
> <lars at public.noschinski.de> wrote:
> 
> >> I don't see any normal situation where this flag is useful.
> >>
> >> I'm not sure the behaviour you see is actually intended, I don't see why
> >> it should reject the chain here.  So it may be a bug...
> >>
> >> The flag _may_ be useful if you have a X.509 Version 1 certificate as a
> >> trust anchor.  You may want to trust a X.509v1 CA for verifying server
> >> certificates signed by the X.509v1 CA, but you definitely do not want to
> >> accept that certificate as the server certificate (because there are no
> >> name restriction extensions).  On the other hand, you shouldn't use
> >> X.509v1 certificates anyway...
> >
> > Just to clarify: Using GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT without
> > GNUTLS_VERIFY_DO_NOT_ALLOW_SAME is a sane choice (if one stills needs to
> > deal with X.509v1 certificates).
> 
> The GNUTLS_VERIFY_DO_NOT_ALLOW_SAME is a flag, to make the trusted
> certificate list, a list that can only certify other keys. That is it
> will not allow a certificate from this list to be used as a server
> certificate. So how it works it depends on your usage of this list. If
> you add end server certificates there maybe
> GNUTLS_VERIFY_DO_NOT_ALLOW_SAME is not a good option for you. But for
> other uses it is quite sensible.

Ok. But in this case, the behaviour I observed seems to be indeed a bug
in gnutls, as my certificate list did not contain the server's
certificate, but only the CA certificates.