Postfix DANE support for Certificate Usage = 0/1?
ietf-dane at dukhovni.org
Tue Feb 24 00:56:11 CET 2015
On Mon, Feb 23, 2015 at 11:23:07PM +0000, Kevin San Diego wrote:
> The "no added security" bit makes some sense in the context of a compromised
> DNS environment, but this doesn't really address how an organization who
> currently utilizes public CA-certs is supposed to intermix their existing
> TLS SMTP client usage with self-signed/DNS-hosted certs in a TLSA record.
You can designate any CA as a DANE-TA(2) trust anchor. It need
not be your own. Any record you might have published with usage
PKIX-TA(0) can be published instead as DANE-TA(2), with the following
* The server certificate MUST include the TLSA base domain as
one of the DNS subjectAltNames.
* Servers MUST send the trust-anchor certificate in their TLS
ServerHello message along with the leaf certificate and any
* Some Windows software (Schannel limitation?) reputedly cannot
be configured to include the root CA in the server's TLS
HELLO. In that case you need to use an intermediate CA as
your DANE-TA(2) trust-anchor.
> By stating usage mode 0 & 1 should be considered unusable, it seems to me
> that a company would need to choose between sticking with their current
> legacy opportunistic/site-specific forced TLS and moving to the DANE-EE
Not true. Public CA certificates work even better when you don't
require the clients a-priori to trust the same CA you do business
Also, you can take any leaf certificate (or the underlying public
key) issued by a public CA, and publish a DANE-EE(3) association
The two models coexist seamlessly, and many existing DANE SMTP
sites use certificates from a public CA.
spodhuis.org. IN MX 10 mx.spodhuis.org.
_25._tcp.mx.spodhuis.org. IN TLSA 2 0 1 ea99063a0a3bda9727032cf82da238698b90ba729300703d3956943635f96488
Subject = CN=mx.spodhuis.org,O=GlobNIX Systems,C=US
Issuer = CN=GlobNIX Certificate Authority 4,OU=Certification Authority,O=GlobNIX Systems,ST=Pennsylvania,C=US
More information about the dane-users