Couple of comments on the CRL Branch

Ajay Kumar ajaykumarns at gmail.com
Tue Jul 6 15:13:44 UTC 2010


On Fri, Jul 2, 2010 at 1:16 PM, Bryan Kearney <bkearney at 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 at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/candlepin
>



-- 
with regards
     Ajay Kumar.N.S
http://www.linkedin.com/in/ajaykumarns



More information about the candlepin mailing list