On Sat, Nov 08, 2014 at 12:05:05PM +1300, Peter wrote:
> On 11/08/2014 04:29 AM, Viktor Dukhovni wrote:
> > In Postfix side, we'd probably need a key + chain database to
> > support SNI, I don't think it is wise to expose keypairs to
> > post-chroot privilege-reduced SMTP servers, or to have tlsmgr(8)
> > proxy access to keypairs for such servers.
>
> You've considered a lot here that I haven't. Any particular reason,
> though, why it's bad to put the keys in the chroot?
The problem is not the chroot, it is that the process running in
the chroot jail is running as the untrusted "postfix" user, not
as "root".
> One thing to consider here is that a user might have the same chain
> (with the exception of the final cert) for most, or all of his certs.
> As an example, say I get rapidssl certs for all 10 of my domains. The
> current rapidssl chain is four certs long, so we would have to hold a
> total of 30 certs in memory (we don't hold the root Equifax cert) if we
> hold the entire chain for each cert, but we only, actually, have 12
> unique certs, so we've more than doubled the amount of space needed to
> hold those.
Yes, having multiple names resolve to the same chain could be part
of the design.
The alternative is to pre-load all the chains into memory at startup,
and avoid the database, but I'd prefer to have a design that scales
to tens of thousands of chains if need be, and a database can
provide access to the chains dynamically.
While many of the building blocks for this are already in Postfix,
this is not something I have cycles for at present.
--
Viktor.
