CAcert Code Development list.

[Michael Tänzer <michael.taenzer AT cacert.org>]

Hi Wytze,

On 24.12.2011 15:38, Wytze van der Raay wrote:
> Op 23-12-2011 15:11, Michael Tänzer schreef:
>> On a side note: The numbers suggest that the server side caching
>> approach proposed in https://bugs.cacert.org/view.php?id=1001 at least
>> does not result in an OCSP load we could not handle (additional ~58
>> requests per minute but probably reduced load on the OCSP server due to
>> the other servers taking some loads) and therefore might be doable.
> 
> I'm not following you here ... where do you get the number 58 from?
> Perhaps I'm missing the clue of your proposed caching algorithm also:
> initially you would want to send signed OCSP responses for ALL valid
> serial numbers to known slave servers -- that's potentially a very
> large number, so there would seem to be a severe startup penalty.
> And after two days of running, all those cached responses will be
> invalid anyway. After that they will be renewed on demand, so then
> the master server load will be even lower than now, won't it??

The caching algorithm:
The master server sends a signed response for all valid certs to all
known slaves every 24 hours. To spread the load the certs should not be
signed all at once just when the master is started but spread throughout
the day. When the master server fails, the slaves can answer all
requests for valid certs with the pre-signed response, requests for
certs where the status are unknown may be responded with a protocol
failure (not nice, but not worse than if the only OCSP server was down).

We currently have 82,807 valid certs in the system. For every valid cert
we need to sign one response per 24 hours. Divided by 24 hours * 60
Minutes this means that the OCSP server needs to sign ~58 responses per
minute.

-- 
Merry Christmas,
Michael Tänzer

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature