On Mar 4, 2013, at 6:25 PM, Viktor Dukhovni <[email protected]> wrote:
> On Mon, Mar 04, 2013 at 08:25:00PM -0500, Jim Schaad wrote: > >> For types 0, 1 and 2 - the DANE check is in addition to ALL existing PKI >> checks. > > So the client validates two separate cryptographically signed name > bindings (DNSSEC and EE cert contents), just to maximize the odds > of failure? Why? What is gained by such checks? The asserting party doesn't have to worry about a rogue CA. BTW: you probably misunderstood Jim's shorthand for type 2: there are no PKI checks because it is a trust anchor. > Does the group believe that in practice most TLS applications do > CRL and/or OCSP checks and it is operationally easier to publish > a timely revocation via a public CA than to maintain sensibly short > RRSIG time limits and update one's own DNS when a key is lost? > > If this is not the case, then why doubt the DANE binding? I'm not sure anyone suggested trusting the DANE binding. > [ One data point if you like: though Postfix has supported TLS for > a decade, it doesn't and won't have CRL or OCSP support, but it > will soon have DANE support. ] > >> For type 3 - I would agree that no PKI checks are to be done. That would >> include the name matching check. > > Thanks, I hope this is the consensus view of the working group. Nothing in the RFC indicates that the relying party would do name binding for type 3, I hope. --Paul Hoffman _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
