[ "Bcc": Shumon Huque ]
On Tue, Sep 22, 2020 at 07:17:40AM +0000, Christian Renner wrote:
> I am looking for a way to get the mutual client authentication
> certificate from incoming e-mail messages (in particular with
> TLSv1.3+).
1. Postfix does not provide a mechanism for this.
2. A single certificate alone contains no trustworthy information,
one needs the whole chain, anchored at a suitable trust-anchor.
3. The trust-anchor and intermediate CAs need to have meaningful
"jurisdiction" to assert the subject identity.
> With a policy server I am able to get ccert_subject, ccert_issuer and
> ccert_fingerprint
> (http://www.postfix.org/SMTPD_POLICY_README.html#protocol), but I
> would like to get the full certificate and not just its fingerprint.
It is not clear how that would be both trustworthy and useful.
> Increasingly users of large cloud service operators (O365, Google,
> etc.) can authenticate to third parties for value added mail sending
> on the basis of postfix,
What does "on the basis of Postfix" mean? What is "value added
mail sending"?
> but their cloud operator cannot tell them (let alone ahead) with what
> certificate they will authenticate themselves when sending their
> message (to prevent "message insertion").
Is the cloud provider presenting X.509 credentials for each user, or for
the user's organisation (cloud "tenant")?
> So we need to present them the full certificate we observe and they
> will then have to confirm whether we can accept that as “them" ;-)
Who's them? Who's the SMTP client? Who's the SMTP server? Is this an
"on-boarding" process, where the user confirms that the cloud provider
sending on their behalf is presenting the expecting (user? tenant? ...)
certificate?
Who's responsible for keeping such certificates "fresh", are they
managed by the cloud provider, and renewed without action by the
customer? If so, how do you plan to handle that? I see intermittent
outages every time the certificate is updated...
Are the intermediate and root CAs asserting a particular client
identity reasonably expected to be long-term stable? How do
you plan to validate that a given identity is properly issued?
About the only thing that comes to mind that could scale would
client-side DANE, which Shumon Huque (Bcc'd) pinged me about recently,
we need to get back to workign on that draft... This would allow the
customer to publish (via DNSSEC and DANE TLSA RRs) the relevant
trust-anchor (or end-entity cert pin) for validating their SMTP-client
identity.
> Does anyone have an idea how to implement this?
A better definition of "this" is needed before there can be a cogent
answer. The short version is that Postfix does not provide any footguns
in this space at present that would mostly enable doing the
(superficially right) wrong thing...
If there is some robust use-case for exposing client certificate
chains to external agents, perhaps it could at some point be
accommodated, but first it has to make sense.
--
Viktor.
