On Fri, Aug 02, 2019 at 03:18:39PM -0700, Jim Fenton wrote: > On 8/2/19 3:06 PM, Benjamin Kaduk via Datatracker wrote: > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Thank you for resolving my Discuss points! > > > > I do think the added text in Section 4.2.1 about DNS-ID/CN-ID should > > probably be clarified that it only applies to the RFC 6125 procedures and > > not the RFC 7672 ones. > > > Thanks for your review. > > Since RFC 7672 (section 1.1, definition of "Reference identifier") calls > out the use of use of CN-ID if no DNS-ID (subjectAltName of type > dNSName) is present, I don't really see a conflict between the wording > in the draft and 7672. Or is the concern that we shouldn't be allowing > the use of CN-ID if DNS-ID is present?
I could be mistaken, but my understanding was that for DANE, the "reference identifier" (compared against the DNS-ID/CN-ID) was not necessarily going to be the result of an MX lookup (or A record fallback). So I wasn't concerned about the DNS-ID/CN-ID part per se, but the other part of the added text -- that was just a convenient way to refer to the chunk that changed. > I have always thought that the "alternative" nature of subjectAltName > means that those names are allowed to be used in addition to commonName, > but I guess that isn't really the way things work. It's a natural assumption! I guess that the commonName was defined without the benefit of many years of deployment experience (and without knowledge of the craziness that the modern Internet has become!), so it's just not well suited for (many of) the situations we work in anymore. The subjectAltName is more flexible and has survived the disruption better. (Not that I was around for the start of it, of course...) -Ben _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
