>>>>> "VD" == Viktor Dukhovni <[email protected]> writes:
VD> On Fri, May 30, 2014 at 03:02:22PM -0400, James Cloos wrote: >> A 3 0 0 tlsa will work as well as a 3 1 x. The client can pull the spki >> out on its own. VD> Not true. When the server presents only the SPKI (no certificate VD> wrapped around it), the client cannot magically reconstruct the VD> enclosing certificate. Yes true. When the server presents the SPKI, and the tlsa has the whole cert, the client can extract the spki from the tlsa-provided cert and compare them. That is no different from the case where the server presents a whole cert but the tlsa match type is 1. Either way the client needs to know how to extract an SPKI from a cert. >> It is not that *all* tlsas need to be limited just because the server >> supports the oob methods. Rather, *at least one* of the published tlsas >> must be usable (3-0-0 or 3-1-x and secure in this case) and match. VD> Not true. If the server's "3 1 x" RRs reflect only keys that were VD> active in the past, or only keys that will be active in the future, VD> while the currently active certificate key matches other TLSA RRs VD> ((usage, selector) != (DANE-EE(3), SPKI(1)) then the client loses VD> if it negotiates "oob public key" and server only presents a leaf VD> SPKI instead of a leaf cert. That is irrelevant. Config errors like that will happen w/o oob just as much as with. And clients need to decline then, too. The fact that an oob client which expects to use tlsa to validate the spki needs a tlsa which works with that should be noted, but we (the wg) don't need to do any more than mention it. -JimC -- James Cloos <[email protected]> OpenPGP: 0x997A9F17ED7DAEA6 _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
