This doesn't let you alias server certs without also aliasing client
certs, no idae if that would be a problem in practice. The comments
in RFC 6698 suggest that aliasing server certs is rarely useful.
Just on the last point, I couldn't find where in 6698 it says that about
aliases, ...
You're right, it doesn't, but it does say disparaging things about
wildcards which have sort of the same issues.
but RFC 7671 offers two design patterns involving aliases
for server TLSA records that might be common - one for virtual hosting,
and another to alias many server records to a common DANE-TA
issuer.
I'd think DNAMEs would work great for that. Publish one set of records
describing the common issuer, then use a few DNAMEs to point everyone else
at it, e.g. in the client case:
$ORIGIN hostco.example
_submission._client._tcp TLSA ... issuer info ...
_pop3s._client._tcp CNAME _submission._client._tcp
_pop3._client._tcp CNAME _submission._client._tcp
_imaps._client._tcp CNAME _submission._client._tcp
_imap._client._tcp CNAME _submission._client._tcp
_xmpp-client._client._tcp CNAME _submission._client._tcp
then
_client._tcp.bob.example. DNAME _client.tcp.hostco.example.
_client._tcp.carol.example. DNAME _client.tcp.hostco.example.
_client._tcp.ted.example. DNAME _client.tcp.hostco.example.
_client._tcp.alice.example. DNAME _client.tcp.hostco.example.
This has the nice property of creating exactly the records you want, as
opposed to wildcards which match everything whether or not it makes sense.
Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
