Re: [dane] terminology question

[Viktor Dukhovni <[e-mail]>]

On Tue, Dec 03, 2013 at 05:17:12PM -0700, Peter Saint-Andre wrote:

> In particular, RFC 6125 uses the term "source domain" to refer to the
> fully qualified domain name that a TLS client expects to find in the
> certificate (or, in DANE, potentially the key) that is presented by
> the TLS server. RFC 6125 also uses the term "derived domain" to refer
> to a domain name (or host name) that the client has derived from the
> source domain in an automated fashion (e.g., via a DNS SRV record).
> 
> As far as I can determine, draft-ogud-dane-vocabulary uses the terms
> "Query [Name]" and "Final [Name]" for something like "source domain"
> and "derived domain". However, draft-ogud-dane-vocabulary also uses
> the terms "Service Specification Records" and "Service Address
> Records" in a way that might be similar, although I confess that I
> don't really grok draft-ogud-dane-vocabulary in fullness and the
> latter two terms are unclear to me.
> 
> Naming is hard, and I hope we can get it right.

With DANE the name the client expects to find in a peer certificate
is the "TLSA base domain".  Thus if the TLSA records were found via:

	_25._tcp.mx.example.com. IN TLSA 3 1 1 {blob}

(even if that was an alias for some other location in DNS) the
"TLSA base domain" is "mx.example.com" and with usages other than
3, that's basically what one looks for in the peer certificate.

At least for SMTP, there is an additional twist, because when the
TLSA base is the result of an MX lookup:

	example.com.	IN MX 0 mx.example.com.

the DANE SMTP draft (in agreement with the expired SRV draft)
specifies that "example.com" is also an acceptable name in the peer
certificate.  This allows sites with pre-DANE "UCC" certificates
that only match the email domain, to be acceptable to both DANE
and non-DANE clients.

Thus a DANE SMTP client will admit either the original domain or
the MX hostname as a valid SMTP server name.

All that said, I am not directly answering your question.  Just
pointing out that the "TLSA base domain" is the natural analogue
of the actual (derived?) domain used for peer verification, except
that with DANE the "derivation" process is always DNSSEC validated.

With SMTP (and perhaps if we stay with the spirit of the expired
SRV draft) when the TLSA base domain differs from the "source
domain" (e.g. envelope recipient domain) it would be also be a
valid peername.

-- 
	Viktor.