On 11/08/2014 12:16 PM, Viktor Dukhovni wrote: >> 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.
Yeah, but I'm referring to different chains that share most, but not all, of the same certs. So we could have several chains that share two or three certs, but the final cert is different. > 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. The compromise here would be to use the db design but have a certain amount of memory available to cache them so that we don't have to repeatedly fetch the ones with the most usage from the db. > While many of the building blocks for this are already in Postfix, > this is not something I have cycles for at present. That's understandable. Peter
