[dane] Certificate usage 2 and TLS server certificate_list?

[Viktor Dukhovni <[e-mail]>]

On Mon, Apr 08, 2013 at 10:38:30PM +0000, Viktor Dukhovni wrote:

Does either RFC 6698, or draft-ietf-dane-srv mandate (or it is too
obvious to state in either standard) that:

  - Servers with "IN TLSA 2 x [12]" associations are obligated to include
    the full TA cert in their TLS "certificate_list".

  - It is correct to read "IN TLSA 2 1 0" as validating chains "signed by"
    (not known whether issued by) the TA, when the TA cert itself is not
    available in the peer's chain.  Or, per the previous question, is the
    TA cert is required, and the issue is moot.

Related Postfix documentation:

    http://vdukhovni.github.io/postfix/TLS_README.html#client_tls_dane

	..., the Postfix SMTP client does not assume that the remote
	SMTP server will necessarily be configured to present the certificate
	of any trusted CA in its TLS protocol certificate_list. Therefore,
	support for trust-anchor certificate and public-key digests is
	disabled by default, see tls_dane_trust_anchor_digest_enable for
	details. While undigested trust-anchor certificates in TLSA records
	are supported, publishing complete certificates in DNS is unwise given
	the resulting excessively large DNS record sizes.  Therefore, in its
	default configuration the Postfix SMTP client essentially supports
	only certificate usages "1" and "3" (with "1" treated as though it
	were "3").

    http://vdukhovni.github.io/postfix/postconf.5.html#tls_dane_trust_anchor_digest_enable

    tls_dane_trust_anchor_digest_enable (default: empty)

	RFC 6698 trust-anchor digest support in the Postfix TLS library.
	Specify zero or more of the following options, separated by comma or
	whitespace.  Option names are case-insensitive.

	ca-constraint
	    Enable support for RFC 6698 (DANE TLSA) DNS records that contain
	    digests of trust-anchors with certificate usage "0". These are
	    often public root CAs, and server operators may expect that
	    clients will have the corresponding root certificate in their
	    CAfile or CApath. Most SSL/TLS servers do not send public root CA
	    certificate in their certificate chain, so if Postfix does not
	    have the CA certificate locally, there is no way to associate the
	    digest with the trust chain from the server. These TLSA records
	    are fragile, and only work when you have a complete (whatever that
	    means) set of public CAs in your CAfile or CApath. Enable this
	    with caution if at all.

	trust-anchor-assertion
	    Enable support for RFC 6698 (DANE TLSA) DNS records that contain
	    digests of trust-anchors with certificate usage "2". In this case
	    the certificate usage should compel the server operator to
	    configure the server to include the trust-anchor certificate in
	    the server's SSL HELO certificate trust chain.  Problems are less
	    likely here, and most administrators choosing non-public CAs
	    should in any case publish TLSA records for leaf certificates
	    (certificate usage "3"). These TLSA records are somewhat less
	    fragile than "ca-constraint" TLSA records, but are also not
	    enabled by default. Having a complete CAfile or CApath may not
	    help in this case, you are at the mercy of the remote server
	    administrator's competence. Enable this with caution if at all.

-- 
 	Viktor.