[ 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