On Fri, Jul 11, 2014 at 11:10:37AM +0200, BlueStar88 wrote:
> Postfix in fact does already host-certificate checks in both
> directions/roles, which results in "Trusted TLS connections
> established from/to ..." in the optimum case.
What would the server do differently with a client certificate than
without? You want access control based on a client name? Which
name? (Certificates can have many subjectAlternativeName values).
> Inbound-wise (smtpd) I'm able to set "none", "may" and "encrypt"
> as "smtpd_tls_security_level".
The server has no secure reference identity for the client, and thus
cannot perform PKIX name checks. Therefore "secure", "verify" and
"dane" are not applicable. The "check_cccert_access" feature can
do access control based on client certificate fingerprints.
> What exactly is the point on having a complete certificate check
> on inbound connections and being not able to make any use of it?
Not much, I generally recommend an empty CA list. However, you
can use CAs with:
http://www.postfix.org/postconf.5.html#smtpd_tls_req_ccert
http://www.postfix.org/postconf.5.html#permit_tls_all_clientcerts
> Many large email providers and commercial organisations have a
> provable host certificate in their MTA's client-role in place, just
> waiting to make a strict use of, if someone likes to.
SMTP is not like HTTPS, and CA issued certificates are of little
use in SMTP:
http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-10#section-1.3
> My proposal is to extend the ability to set the same strictness
> schemes to inbound connections as well.
What concretely would you do? Wishful thinking is all well and good,
but reality means that a design has to work and deliver some benefits
to justify its costs.
> I'd like to setup a Trusted-only MTA for a special domain. My
> strong wish is, that both directions are validated at the
> verify/secure/fingerprint level by myself, to have a sort of basic
> proven integrity from my perspective as result.
You can use check_ccert_access, provided you're provisioning the
keys on both ends.
--
Viktor.
