From: Alexander Hoogerhuis (alexhboxed.no)
Date: Tue Jul 11 2006 - 01:00:39 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Victor Duchovni wrote:
> On Tue, Jul 11, 2006 at 07:40:17AM +0200, Alexander Hoogerhuis wrote:
>
>>> The typical approach on an MSA that wants to relay with TLS credentials,
>>> is to to issue all certs from a private label, CA, trust only that CA,
>>> and allow relaying for all clients with certs from a trusted CA.
>>>
>> The solution you describe would bar a server from serving both TLS
>> clients signed by a local CA for relaying and accepting TLS conenctions
>> from other servers though?
>
> Not at all. You can ask for certificates, and ignore the untrusted ones.
> Do note, however, that asking for certificates causes interoperability
> issues with some senders. Best practice is to run an MSA on port 587
> and only ask for certificates there.
>

Noted, I knew of it, but that way is abviously nicer.

>> Or do I get it right that what you say would allow you to order a
>> certfiicate from a public CA, use my domain in the subject CN email
>> adress and then relay through my machine?
>
> That is what I suspect.
>

Kinda helps thinking when I am typing, that's how I figured it out. ;)

>> If that is the case, would it
>> be possible (and safe) to have a mechianism that would list the CAs
>> whose clients would be allowed to relay locally (so I can only list my
>> private CA, and those who I trust for relaying), making the overhead a
>> onetime per CA to be trusted and not a per user operation?
>
> This is what I am suggesting, but once you have such a CA, you can ignore
> the DN. Just relay for any client whose public key you certified.
>

But that would mean back to today's solution; keeping track of
fingerprints if keeping the MSA inline with server to server traffic on
tcp/25, which isn't all that big of an issue all in all now that I think
this through. :)

-A

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]