The use of OCSP-stapling should be considered, allowing
for fast revocation of certificates (which would otherwise
-be limited by the DNS TTL on the TLSA records).
+be limited by the DNS TTL on the TLSA records). However,
+this is likely to only be usable with DANE_TA. NOTE: the
+default of requesting OCSP for all hosts is modified iff
+DANE is in use, to:
+
+ hosts_request_ocsp = ${if or { {= {0}{$tls_out_tlsa_usage}} \
+ {= {4}{$tls_out_tlsa_usage}} } \
+ {*}{}}
+
+The (new) variable $tls_out_tlsa_usage is a bitfield with
+numbered bits set for TLSA record usage codes.
+The zero above means DANE was not in use,
+the four means that only DANE_TA usage TLSA records were
+found. If the definition of hosts_require_ocsp or
+hosts_request_ocsp includes the string "tls_out_tlsa_usage",
+they are re-expanded in time to control the OCSP request.
+
+This modification of hosts_request_ocsp is only done if
+it has the default value of "*".
For client-side DANE there are two new smtp transport options,
tls_verify_certificates
tls_crl
tls_verify_cert_hostnames
- hosts_require_ocsp (might rethink those two)
- hosts_request_ocsp
Currently dnssec_request_domains must be active (need to think about that)
and dnssec_require_domains is ignored.
+If verification was successful using DANE then the "CV" item
+in the delivery log line will show as "CV=dane".
+
+There is a new variable $tls_out_dane which will have "yes" if
+verification succeeded using DANE and "no" otherwise (only useful
+in combination with EXPERIMENTAL_TPDA), and a new variable
+$tls_out_tlsa_usage (detailed above).
+
--------------------------------------------------------------
End of file