Hi Victor,
At 21:14 19-04-2013, Viktor Dukhovni wrote:
Thanks, any feedback on the CNAME thread then?
6698 Section 3:
3. The base domain name is appended to the result of step 2 to
complete the prepared domain name. The base domain name is the
fully qualified DNS domain name [RFC1035] of the TLS server, with
the additional restriction that every label MUST meet the rules
of [RFC0952]. The latter restriction means that, if the query is
for an internationalized domain name, it MUST use the A-label
form as defined in [RFC5890].
There is no normative text telling applications what the phrase:
"the base domain name" means, it could well be the domain name
obtained after the application securely chases CNAME RRs, especially
with SRV and MX RRs where we're not supposed to have CNAME targets,
so resolving targets to underlying hosts avoids working with CNAMEs.
I'll say that I do not see a definition of "base domain name".
Similarly A.2 merely highlights the DNS semantics of CNAMEs with
respect to child nodes, it also does not contain any normative text
about what "base domain name" is to be chosen by the verifier.
Yes.
My argument is that both the verifier and the server operator
benefit from cleaner/simpler key management if "base domain name"
means the target host after resolving any DNSSEC validated CNAME
RRs. This is an opportunity for DANE to reduce the key-management
burden of TLS virtual hosting, don't miss the opportunity.
If this view has no positive support here, at the very least expect
some implementation variability. Mine will perhaps not be the only
implementation that looks for TLSA RRs post CNAME expansion.
There is significant CNAME usage for virtual hosting to avoid or
reduce operational issues. Sometimes the usage can be in
contradiction with what is specified in a RFC.
I read a message where Section 5.1 of some RFC was mentioned [1]. As
my quick reaction was "ok" I didn't comment about that. If it is
possible to reduce the key-management burden I am all for it. I
prefer to discuss about a specific application protocol instead of
taking a wider approach as it may not be clear what the
all-encompassing solution should be.
Regards,
-sm
1. http://www.ietf.org/mail-archive/web/dane/current/msg05586.html
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
