> On Feb 5, 2017, at 6:49 PM, Jaime Hablutzel Egoavil <hablutz...@gmail.com>
> wrote:
>
> Here is one valid use case, the mail service operator
> doesn't manage or participate in the certificate issuance
> itself but he expects that his users get their certificates
> from a commercial CA, e.g. Symantec (which he trusts for
> validating emails and including them in subject DNs), but
> at the same time, this mail service operator doesn't want
> to allow authentication for all of the Symantec issued
> certificates but only some, e.g. the ones with a given
> domain in the "emailaddress" subject attribute. In this
> case the policy server would need the "emailaddress"
> attribute to decide.
That would be a fragile and risky policy. You'd be placing
relay access control for your MSAs in the hands of an external
CA. Your configuration would have to be carefully tuned to
exclude trust of all the other CAs.
How is an external CA better positioned to authenticate your
users than your own servers?
That said, the real obstacle the complexity of X.509v3 certs.
Giving users raw certificate chain to decode and validate is
a disservice. Consider, for example:
https://tools.ietf.org/html/draft-ietf-lamps-eai-addresses-06
users may be tempted to start processing "SmtpUtf8Name" SubjectAltName
elements in certificates, but their TLS toolkit might not know these
exist, and may not have applied name constraints. The domain in the
user's email address may have to be converted from A-labels to U-labels
to comply with the specification, the verifier must not forget to ensure
that the chain is actually trusted...
I am not inclined to just dump raw sewage (X.509) on the user's lap
and ask them to deal with the mess.
It may make more sense to export the list of validated subjectAltName
values, that are known to have been understood (suitable constraints
applied) by the OpenSSL software, where the certificate chain has been
verified... This is still risky, but a more reasonable UI for Postfix
administrators.
--
Viktor.
