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.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
