> On Apr 18, 2021, at 10:30 PM, Viktor Dukhovni <postfix-us...@dukhovni.org>
> wrote:
>
> On Sun, Apr 18, 2021 at 08:49:34PM -0400, Demi Marie Obenour wrote:
>
>>>> Each system is issued a certificate for its own domain. Perhaps a
>>>> better example would be email Subject Alternative Names.
>>>
>>> That's not an example (use-case), it is a certificate field. What
>>> is the use-case. With some specificity...
>>
>> If I were to run my own email server (I don’t, but I plan on doing
>> so someday), my preferred means of authentication would be by client
>> certificate. And I would want users to be able to send emails as a
>> specific user if, and only if, I have issued them a certificate with
>> the corresponding email address in the SAN.
>
> Though you didn't quite say it explicitly, it seems that you have in
> mind an MSA (submission) use-case. And you'd like to associate the the
> email addresses that users are allowed to use with their certificates
> (possibly as email address SANs, but see below).
>
>> ... requiring authentication to even connect to the service avoids
>> whole heaps of problems.
>
> That's only true if one neglects many practical details.
>
>> If the user doesn’t present a certificate, they aren’t going to even
>> get an SMTP greeting, much less be able to send mail.
>
> Perhaps true on port 465, but not quite on 587, though of course
> establishing STARTTLS on 587 and getting to "AUTH" can mandate the same
> client cert requirements.
>
>> And that is extremely easy to validate: I just need to ensure that
>> connections with no certificate, or with an invalid certificate, fail
>> during TLS negotiation.
>
> Well, the key question is what's an "invalid certificate"? An no longer
> authorised user may still be in posession of a certificate that has not
> yet expired, and so one way or another you'll need to distinguish
> certificates of authorised users from certificates of formerly
> authorised users.
>
> I'd like to suggest that CRLs are by far the worst way to go about this,
> and that therefore, you'll want a positive mapping (a table of
> authorised certificates, mapping them to notional authorised users).
Trying to get postfix to check an OCSP responder would be *hard*.
Not that most “toy” CA’s (like ca.pl) have a worthwhile one in place.
Since I started this thread, I found *one* possible workaround.
(Remember, dayjob is using puppet).
I am able to use puppet’s collected facts to build an access db,
if that’s something I want to do. We already do something like this where
the services on a running machine establish what a host’s monitoring
profile will be.
For demi, that may be your answer as well — since your CA keeps a
list of what certs it has issued, perhaps pumping those into an access
table of some sort (with a perl script or the like) may be helpful to you.
That said, if what you’re trying to do is use certs to say:
the cert issued to bob.domain.com will only allow sending from b...@domain.com,
then except on your own mail server, nobody is going to be inspecting the
headers
for this.
(That is to say, this isn’t S/MIME).
If the result is that mail is rejected unless this matches, then you’re only
increasing the load on yourself.
-Dan
>
