On Tue, Mar 05, 2013 at 08:00:08PM +0000, Viktor Dukhovni wrote: > > This is a flippant response.
I don't. > Sure, the client can chooose to not > implement DANE, or choose to misimplement it by adding 1 mod 4 to > each cert usage and to take the bitwise complement of each digest > value. Or any other number of crazy things. That's not my point. My point is rather that you seem to want the server to be the boss here, and I don't think that's reasonable. > The semantic validity of such RRs is moot if client implementations > (guided or perhaps misguided by RFCs) reject the target EE certificate. I don't think it's misguided. The point of this feature in the specification is for the server operator to be able to declare, "Oh, and by the way, the certificate I offer you in the DNS is the one you ought to be validating according to the traditional CA certificate chain, not other ones." At that point, the client gets either to use traditional CA validation without TLSA, or to use TLSA to perform additional validation beyond what would be done with the traditional CA chain. > If such RRs, when intentionally created by domain owners, are to > be given the chance to be useful For the use case, they're not useful. If you want this additional use case, why not create a new type? > We can attempt to more completely mimmic legacy public CA PKI > certificate validation and remove the choice I advocate, but that > would be unfortunate, since it would needlessly only serve to limit > the choices available to domain owners. It's not needless. It's part of the design of this feature. > Is it reasonable to continue to advocate my interpretation based > on logic and consideration of security models? Or is it the group's > view that structural similarity to existing legacy CA PKI practices > trumps logical analysis? I think it's wonderful when people present false dichotomies in their arguments in the form of rhetorical questions, but it doesn't make the position any more reasonable, no. Best, A -- Andrew Sullivan [email protected] _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
