Viktor Dukhovni wrote: > Matt Miller wrote: >> >>> DANE-EE(3) CU records need to have meaningful semantics for the >>> publisher. For example for a publisher to use the same >>> certificate for many SRV hosts or without worrying about using a >>> matching name, the use of non-use of name checks must be specified >>> precisely. >>> >>> Therefore I would suggest that the "MAY be ignored" in the second >>> paragraph of section 5, should be changed to "MUST be ignored". >>> Otherwise, the published TLSA records have unknown semantics. >> >> Thank you for the feedback, Viktor. These comments make sense to me. >> We'll try to get an update out before the cutoff to address them. > > Thanks. You could mention that both name checks and key usage are > effectively handled by the TLSA record for DANE-EE(3).
I'm sorry, but this simply isn't true today, I do not believe that this is (nor should be) the intention of DANE, and I'm strongly opposed to changing that part of the implementations. DANE it self is about an alternative means to establish (a chain of) trust to a peer entity, and the usage type 3 only overrides the server endpoint identification that was originally described in rfc2818 section 3.1 http://tools.ietf.org/html/rfc2818#section-3 and is described in a more elaborate fashion in rfc6125 http://tools.ietf.org/html/rfc6125 DANE does NOT invalidate the keyUsage checks and requirements that are normally part of TLS itself and described here: http://tools.ietf.org/html/rfc5246#page-56 There are a number of TLS protocol stacks that will check the KeyUsage of X.509 certificates that are conveyed through TLS certificate handshake messages, independent of how the application caller decides to perform server endpoint identification and how the application caller determines its trust. -Martin _______________________________________________ dane mailing list dane@ietf.org https://www.ietf.org/mailman/listinfo/dane
