On Fri, Mar 01, 2013 at 06:28:05PM -0500, James Cloos wrote:
> 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 don't think that selector "1" vs. "0" ought to substantively
influence the semantics of the certificate, even we intuit that
the domain owner is fervently trying the world of CAs behind him.
However, I do believe that the same (subject name checking) policy
should apply for both certificate usage "3" and "1".
> [I had more to write; but have to cut this short and run.... -JimC]
Looking forward to additional comments. In particular, is 6698
sufficiently clear, and was merely misconstrued by the dane-srv
draft? Or does 6698 itself need clarification in section 4 to
avoid similar confusion in implementations and future related
standards?
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
