[gnutls-devel] DANE validation

[Nikos Mavrogiannopoulos]

On Sun, Feb 17, 2013 at 10:20 PM, Gabor Toth <tg at tgbit.net> wrote:

>> That's also intentional. What scenario do you have in mind that is not
>> covered by the current case?
> The RFC does not limit it to the immediate issuer, for instance a TLSA record
> could contain a root CA certificate instead of an immediate issuer, which is not
> checked by the current implementation.

Yes but I see the RFC behavior as open to abuse. One needs only to
make a path that would finish on the CA in question, which is much
easier than getting an actual certificate from that CA for that name.
If there is patch that enables the behavior you mention (but only when
an additional flag is specified), I'd add it.

>> In gnutls DANE validation is independent to other certificate
>> validation methods. One can do PKIX validation, DANE (as DNS-based),
>> TOFU (trust on first use) or any combination of them.
> In this case the documentation should explicitly mention that PKIX path
> validation is not performed and should be done separately to avoid confusion.

Indeed, that should be fixed.

>> One could of course strictly follow the DANE RFC validation methods if
>> he needs to.
> The current API does not make it easy to do that. In case of usage 2, the trust
> anchor specified in the TLSA record should be used for PKIX path validation. In
> this case dane_verify_crt() could return the index of the certificate in the
> chain that matched as trust anchor, so that PKIX path validation could be
> performed up to that certificate in the chain, possibly using
> gnutls_x509_crt_verify() with the returned trust anchor as the CA_list argument.

Thanks for reporting these. It looks like a limitation I didn't see.
I'll try to see what can be done about it.

regards,
Nikos