On 5. 3. 2013, at 6:59, Viktor Dukhovni <[email protected]> wrote: > On Tue, Mar 05, 2013 at 05:14:32AM +0100, Martin Rex wrote: > >> Paul Hoffman wrote: >>> 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. > > Yes, of course, with 0/2. With 1, the asserting party told the > client *exactly* which certificate to expect. That's it game over. > With the EE certificate pinned-down, who cares about the name > asserted by the CA. What concrete threat does the name check avert?
The '1' was deliberately designed, so it _is_ compatible with existing CA model and existing applications (DANE-aware and non-DANE-aware). If you don't like that just use type 3. (Or type <n> when bare TLS certificates are out.) If you want to be compatible with DANE, I would suggest to implement the protocol as is, pretty please. (On the other hand, the existing MTA implementations don't give a damn about existing standards, so it will be status quo anyway.) O. -- Ondřej Surý -- Chief Science Officer ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:[email protected] http://nic.cz/ tel:+420.222745110 fax:+420.222745112 -------------------------------------------
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
