|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
Some additional modest last call comments on draft-ietf-dane-protocol-19... terminological issues ---------------------The "usage" notion has at least five term/phrase variations used in the spec. I found this quite confusing. Here's the variations I find..
usage = usage type = certificate usage = certificate usage type = TLSA UsagesI suggest settling on one or two phrases for most all occurances. I suggest using "certificate usage type" in (almost) all cases, and "usage type" perhaps in cases where the bare term "usage" is presently used. To help out, here's an updated TLSA RDATA Wire Format diagram..
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Usage Type | Selector | Matching Type | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / / Certificate Association Data / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Separately, the term "TLSA certificate association" is used in a few places, and should probably be "TLS certificate association" for consistency.
I also found the term "TLSA association" used on pages 22 & 23, which ought to be "TLS certificate association", yes?
Section 8.1 introduces the somewhat ambiguous term "DANE client", which is contrasted with "common TLS clients" and "current TLS client". Perhaps "TLSA-aware TLS client" is more appropriate here than "DANE client", especially if this protocol is referred to as the "TLSA protocol"?
editorial items --------------- > 1.1. Background of the Problem [ I'd entitle this section "Background and Motivation" ] last para: > DNS-Based Authentication of Named Entities (DANE) offers the option > to use the DNSSEC infrastructure to store and sign keys and > certificates that are used by TLS. If in fact 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", then.. s/TLS/security protocols/ ..in the above-quoted sentence. > 1.2 Securing the Association with a Server's Certificate which association is this section title referring to? (it's ambiguous) Suggested more precise section title: "Securing the Association of Domain Name and TLS Server Certificate" > Currently, the client must extract the domain name from the > certificate and must successfully validate the certificate, including > chaining to a trust anchor.I found the above description unnecessarily imprecise, though recognizing the desire to provide only a brief overview here. A suggested modest rewrite:
Currently, the client must extract the domain name from the certificate and validate it [RFC6125], and must also successfully validate the certificate, including chaining to a CA's trust anchor [RFC5280]. However, as explained above in Section 1.1, essentially any CA may have issued the certificate for the domain name. > 2. The TLSA Resource Record > > The TLSA DNS resource record (RR) is used to associate a certificate > with the domain name where the record is found. suggested clarification.. The TLSA DNS resource record (RR) is used to associate a TLS server certificate or public key with the domain name where the record is found, thus forming a "TLS certificate association". Otherwise, "TLS certificate association" is only tacitly defined. > 2.1.1. The Certificate Usage Field > > > A one-octet value, called "certificate usage" or just "usage", > specifies the provided association that will be used to match the > target certificate from the TLS handshake.In the above, as well as two more instances in the paragraphs following the above, I suggest..
s/target certificate/presented certificate/ ..to be more consistent with RFC6125. > 2.1.4. The Certificate Association Data Field > > > The "certificate association data" to be matched. This field > contains the data to be matched. The 2nd sentence "This field contains the data to be matched." is redundant. > 5. TLSA and DANE Use Cases and Requirements > . > . > . > Combination -- Multiple TLSA records can be published for a given > host name, thus enabling the client to construct multiple TLSA > certificate associations that reflect different DANE assertions. > No support is provided to combine two TLSA certificate > associations in a single operation. > > Roll-over -- TLSA records are processed in the normal manner within > the scope of DNS protocol, including the TTL expiration of the > records. This ensures that clients will not latch onto assertions > made by expired TLSA records, and will be able to transition from > using one DANE public key or certificate usage type to another.suggested rewrite eliminating the not-defined-in-RFC6394 terms "DANE assertion" and "DANE public key"...
Combination -- Multiple TLSA records can be published for a given host name, thus enabling the client to construct multiple different TLS certificate associations. No support is provided to combine two TLS certificate associations in a single operation. Roll-over -- TLSA records are processed in the normal manner within the scope of DNS protocol, including the TTL expiration of the records. This ensures that clients will not latch onto assertions made by expired TLSA records, and will be able to transition from using one TLSA-asserted public key or certificate usage type to another. > 7.2. TLSA Usages > > > This document creates a new registry, "Certificate Usages for TLSA > Resource Records". suggested modest revision for terminological consistency: 7.2. TLSA Certificate Usage Types This document creates a new registry, "TLSA Resource Record Certificate Usage Types" HTH, =JeffH