+1 The name should reflect the final product, not the path taken to get there. If people were to use these records then they would see them in the DNS zone and see them listed as TLSA and look for an RFC with that name. Only the people who were involved in the group would know that DANE and TLSA are the same thing. On Tue, Apr 24, 2012 at 6:23 PM, =JeffH <Jeff.Hodges@xxxxxxxxxxxxxxxxx> wrote: > [ these are excerpts from a current thread on dane@ that I'm now denoting as > an IETF-wide Last Call comment ] > > Paul Hoffman replied on Fri, 20 Apr 2012 13:57:28 -0700: >> >> On Apr 20, 2012, at 10:50 AM, =JeffH wrote: >> >>> Various specs are going to have need to refer to the DANE protocol >>> specification a well as describe the notion of domain names that map to >>> TLSA records describing certificate associations. >>> >>> In working on such language in draft-ietf-websec-strict-transport-sec, >>> here's the terms I'm using at this time and their (contextual) meaning.. >>> >>> DANE protocol >>> The protocol specified in draft-ietf-dane-protocol (RFC# tbd). >>> >> >> There is an issue here that we haven't dealt with, which is that "DANE >> protocol" doesn't really make sense because we might be adding additional >> protocols for certificate associations for things other than TLS. For your >> doc, you should be saying "TLSA protocol", not "DANE protocol" because >> HSTS >> is specific to TLS. (More below.) > > > After further perusal of draft-ietf-dane-protocol-19, if I understand > correctly, the term "DANE" (and its expansion) names a class of Secure > DNS-based cert/key-to-domain-name associations, and protocols for particular > instances will nominally be assigned their own names, where a case-in-point > is the "TLSA Protocol", yes=? > > i.e. we could define another separate spec for mapping Foo protocol's > keys/certs to DNS RRs, and call 'em FOOA, and then in following this naming > approach, refer to the protocol of using them while establishing Foo > connections as the "FOOA protocol", yes? > > > > Paul Hoffman further explained on Sat, 21 Apr 2012 13:38:38 -0700: >> >> On Apr 20, 2012, at 3:34 PM, =JeffH wrote: >>> >>> Paul Hoffman replied on Fri, 20 Apr 2012 13:57:28 -0700: >>> >>> > On Apr 20, 2012, at 10:50 AM, =JeffH wrote: >>> > >>> > There is an issue here that we haven't dealt with, which is that "DANE >>> > protocol" doesn't really make sense because we might be adding >>> > additional >>> > protocols for certificate associations for things other than TLS. >>> >>> Yep. "DANE" is a working group name. But, I was working from the >>> specification name per the present spec. >>> >>> > ... >>> > Proposal for [-dane-protocol] spec: >>> > >>> > The protocol in this document can generally be referred to as the "TLSA >>> > protocol". >>> >>> So as a practical matter, if we wish to refer to this particular spec as >>> defining the "TLSA protocol", then perhaps the spec title should reflect >>> that such that the RFC Index is searchable for that "TLSA" term. >> >> The WG already decided against that (unfortunately). > > > I agree it is unfortunate and respectfully suggest that this decision be > revisited. > > Many (most?) people have been referring to the protocol being worked on by > the working group (which is now draft-ietf-dane-protocol) as "the DANE > protocol" or simply "DANE" for as long as the WG has been formed, /plus/, > the present title of spec is.. > > The DNS-Based Authentication of Named Entities (DANE) Protocol for > Transport Layer Security (TLS) > > > I think it will just continue to unnecessarily sow confusion if the term > "TLSA" doesn't somehow get into the spec title and thus into the various RFC > indexes (whether or not the suggested statement above explicitly naming the > protocol "TLSA protocol" is added to the spec (I think it should be added)). > > > Ways to accomplish addressing the spec title issue could be.. > > TLSA: The DNS-Based Authentication of Named Entities (DANE) Protocol for > Transport Layer Security (TLS) > > > ..or.. > > The DNS-Based Authentication of Named Entities (DANE) Protocol for > Transport Layer Security (TLS): TLSA > > > HTH, > > =JeffH > > > > _______________________________________________ > dane mailing list > dane@xxxxxxxx > https://www.ietf.org/mailman/listinfo/dane -- Website: http://hallambaker.com/