On Fri, May 30, 2014 at 02:50:17PM -0400, Paul Wouters wrote:
> > * This is the obvious part of how to use "oob public key" with
> > DANE, and need hardly be explained. The non-obvious part is the
> > need to only signal "oob public key" support in the client
> > when server's TLSA RRs contain *only* "DANE-EE(3) SPKI(1) ?"
> > records.
>
> This is the third time you mention this and the third time I have to ask
> you why.
That is, the third time you've failed to understand. :-(
The context as stated before, is clients for which "oob" means DANE
auth, and the restriction is for that case only.
> Please
> try and explain why you are trying to add restrictions on the set of
> TLSA records to support "oob public key" (which can happen on its own,
> along with regular full cert support, with or without DANE)
Clients for which DANE auth is the authentication mechanism MUST
NOT exclude any "usable" TLSA RRs from the potential set of matching
records by negotiating "oob public key" which is only compatible
with "3 1 X". The reason, as before, is that there is no a-priori
way to determine which subset of the TLSA RRs is sufficient to
authenticate the server.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
