On Fri, May 30, 2014 at 07:43:06PM -0400, James Cloos wrote:
> 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.
It is not a configuration error, rather a valid transition state,
that clients must support. With DANE, I don't expect clients to
be statically configured for each "oob public key" destination.
Rather, clients will be capable of "oob public key" support, and
of DANE, and will use the two in combination when it makes sense.
Thus, if a client sees only "3 1 X" or "3 0 0" TLSA RRs, and using
DANE for authentication, it can go ahead and use "oob public key".
If the TLSA records don't include any of the above, or are mixed,
the client must not negotiate "oob public key".
The idea is that clients will offer "oob public key" when possible,
which might lead to wide-scale use of the extenion. Otherwise, it
is just a curiousity.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
