On Jun 8, 2012, at 04:43, Tony Finch wrote: > Peter Saint-Andre <[email protected]> wrote: > >>>> What is the point of omitting the name check in this case? >>>> Alternatively, what is the point of including the name check in >>>> the other DANE cases? My drafts say that name checks should >>>> still be performed in the usual way, the idea being that DANE >>>> leads to additional verification code paths rather than >>>> completely distinct code paths. >>>> >>> >>> My thinking was, if we got to this point, then the name in the >>> certificate was no longer material. The delegation by the source >>> domain to the derived domain was already proved, and this check >>> simply added a technicality to fail on. >> >> Agreed. > > Yes this is a valid argument and I agree. However I also think consistency > is important. Why would some TLSA usages require name matches and others > not? Why disable a check done by existing code rather than just adding > checks? >
For Usage 3, the TLS client was effectively told what to match in totality. I see this check as overly burdensome on deployments, and not very burdensome on implementers. - m&m Matt Miller - <[email protected]> Cisco Systems, Inc.
smime.p7s
Description: S/MIME cryptographic signature
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
