On Fri, Jul 2, 2010 at 1:16 PM, Bryan Kearney bkearney@redhat.com wrote:
- First time I have seen a Dto object in the code base. What caused us
to need it?
Not me! :D
- Who calls the ctor on CertificateRevocationListTask? How does the
parameters get set?
HighlanderJobFactory takes care of configuring the tasks as well as injecting dependencies into the task objects.
- Reading in the entire CRL into memory scares me :) If we assume a
serial number is a long of average length stored as a string, then it is 10 bytes. Add another 18 bytes for the time stamp as a string, and then you get 28 bytes per entry. A million entitlements would get us roughly a 26 meg file. Is there a way to stream this? Perhaps read in each record from the CRL and the process it into the new file?
I had the same concern and I concur with you 100%. I have gone through some of the approaches below.
1. Streaming api is not provided by bouncycastle(AFAIK). I think streaming api would have done lot of help to us considering the fact that the number of revoked certificates does not go down. 2. However, we can reduce our memory consumption by creating 'delta CRL' . As the name suggests, delta CRL contains only 'new serial numbers' when compared to the 'base CRL'. Base CRL is usually a big CRL containing as much as possible serial number entries and delta CRL are generated every day or perhaps even sooner. From what I gathered, 'base CRL' is generated at the beginning of every week and delta is generated every day(or sooner). So this cycle is repeated every week. If you look at it, even though delta crl help us reduce our memory consumption, as time passes on, the number of delta crl files tend to increase and we would have to generate the base CRL once in few weeks/some_interval. But when we generate this base CRL, we would have to load all the serial numbers from the database into the memory. Once again we are back to the same memory issue! 3. CRL can also be generated by partitioning them based on some logic say 1000 serials per cert. Later on, when removing old/expired serials, we iterate over each certificate and update. This will reduce our memory consumption and keep the code clean. However, the number of certificates generated would be large and the logic to generate new crl would be confusing as well.(when do we generate a new crl? everyday? or generate a new crl only if the current crl has exceeded 1000 entries...).
Also in general another concern with splitting crl is how its being handled by the servers and whether they support it. I gathered all of these from the internet/security books. I am sure people having real experience with the crl stuff would have more practical knowledge as well as better approaches.
- Related to this, lets turn down the logging :)
I introduced logging for testing purpose. I will turn them down to trace level.
- The logic for deleting the old certificates is to delete those that
expired yesterday certs. Are there any rules about how long a cert needs to be in a CRL?
- Does the CRL need to be signed?
- Have we tried loading the CRL into apache or an ocspd daemon to see it
will work?
-- bk
candlepin mailing list candlepin@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/candlepin