On Fri, Apr 19, 2013 at 02:45:32PM -0700, SM wrote:
> At 16:11 17-04-2013, Viktor Dukhovni wrote:
> >Understood, but at least everyone stopped ignoring me. :-)
>
> I am not ignoring you. I read the messages discussing about CNAMEs. :-)
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.
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.
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.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
