[gnutls-devel] DANE validation

[peter williams]

If you go back to the granddaddy specs of rfc 1421/1422, the world was envisioned as a local store of verification keys, including the public variety. A cert chain basically acted to update the ( file ) store , introducing new keys into the mib or marking others. A public key verified by one cert chain could be "marked" by another chain for example. For all if matters, the file can be trusted zone on your windows dns server, if thats the way you swing, signed using a dnsec verification key known only to the public key using apps that leverage this embodiment of the security mib (vs a file in the unix home directory)

This was a user centric Concept (consistent with the NIST "privacy enhancing" semantics expected for personal crypto in the late 1970s/1980s). You keep your file, given hints from authorities. Your app was yours however, and not the controlled item that other (nsa, doe) philosophies used limiting your app to being a mere remote-enforcement node in their network, controlled centrally and without your discretion.

Im not sure which side of the fence dane sits. I think its the latter, pretending to deliver the culture the former. It seems to undermine it however, by laying all the tracks for reducing appz to remote enforcement of policy set by 10 (dns vectored) authorities regulated formally by icann (which is just a proxy for dept of commerce).

Nikos Mavrogiannopoulos <n.mavrogiannopoulos at gmail.com> wrote:

>If I understood correctly your question, the answer is no because there is no state kept between verifications.
>
>Regards,
>Nikos 
>
>Peter Williams <home_pw at msn.com> wrote:
>
>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:
>http://nmav.gnutls.org/2012/10/some-thoughts-on-dane-protocol.html
>
>> - 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.
>
>regards,
>Nikos
>
>_______________________________________________
>Gnutls-devel mailing list
>Gnutls-devel at lists.gnutls.org
>http://lists.gnupg.org/mailman/listinfo/gnutls-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20130220/640f69bf/attachment.htm>