>>>>> "VD" == Viktor Dukhovni <[email protected]> writes:
VD> Given an explicit binding in the DNS for a specified service end-point VD> to a unique certificate (in full or by subject-publickey-info), it would VD> seem rather unnatural to apply subject name checks to the certificate so VD> bound. The binding in the DNS should ideally obviate any need for similar VD> (potentially conflicting) bindings inside the certificate. Thanks for bringing that up. I seem to have glazed over at that point when I read draft-ietf-dane-srv-*. It is an interesting issue. The target for the SRV/MX TLSAs is for the server to have a single name and a single matching cert; this issue will not occur in that case and I expect that and a desire to minimise code paths are why the draft has that language. But even so, a type 3 shouldn't require any verification beyond checking that the TLSA matches as it specifies. Especially with selector 1. [I had more to write; but have to cut this short and run.... -JimC] -JimC -- James Cloos <[email protected]> OpenPGP: 1024D/ED7DAEA6 _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
