[gnutls-devel] DANE validation

Peter Williams home_pw at msn.com
Sun Feb 17 21:30:09 CET 2013

out of interest, if a PKIX Chain validation has occurred signaling invalidity of an leaf issuer and THEN an issuer-only (non-PKIX) check is made on the next protocol run, does GNU-TLS regard the issuer as invalidated? 


Who controls - the authenticated DNS zone that may continue to confirm the issuer or the evidence collected from a previous chain validation?



Sent from Windows Mail

From: Nikos Mavrogiannopoulos
Sent: ‎February‎ ‎17‎, ‎2013 ‎11‎:‎40‎ ‎AM
To: Gabor Toth
CC: gnutls-devel
Subject: Re: [gnutls-devel] DANE validation

On Sun, Feb 17, 2013 at 5:09 PM, Gabor Toth <tg at tgbit.net> wrote:
> Hi,
> I've taken a brief look at the DANE validation functionality GnuTLS provides.
> It seems incomplete, even though from the documentation one might assume
> otherwise. Problematic points I found so far:

Hello Gabor,
 What you consider an issue, is intentional. The DANE protocol (which
is supposedly DNS-Based Authentication of Named Entities), tries to
enforce methods of authentication that are unrelated to DNS. The DANE
implementation of gnutls is restricted to the DNS validation aspect
only. If one would like to do PKIX validation he can do it, but not
through the DANE subsystem.

You may see reasoning behind that at:

> - in case of usage 0 & 2, only the direct issuer is checked instead of the
>   whole chain

That's also intentional. What scenario do you have in mind that is not
covered by the current case?

> As described in the RFC[1], PKIX path validation should be performed either using the
> trust anchor specified in the TLSA record (usage 2), or using the system trust
> anchors (usage 0 & 1)

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.

One could of course strictly follow the DANE RFC validation methods if
he needs to.


Gnutls-devel mailing list
Gnutls-devel at lists.gnutls.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20130217/80fb225f/attachment.htm>

More information about the Gnutls-devel mailing list