generate the same CRL when tehere is no revoke/unrevoke

[hudecof]

if the CRL generation is triggered twice and there was no revoke/unrevoke command two different CRL file are generated. The only diffs are validity and serial.

5,6c5,6
<         Last Update: Feb 21 10:00:01 2015 GMT
<         Next Update: Feb 28 11:00:01 2015 GMT

---
>         Last Update: Feb 22 10:05:01 2015 GMT
>         Next Update: Mar  1 11:05:01 2015 GMT
9c9
<                 12606

---
>                 12619

It would be good to generate new CRL only on revoke/unrevoke action or the validity period

[reaperhulk]

I'm reluctant to have generate_crl attempt to have any intelligence as there are many reasons why you may want to re-generate a CRL even if nothing has changed. (generate_crl doesn't track whether there's an extant CRL right now either).

Do you think this is something that belongs in r509 or would it be okay to just write a small wrapper that caches and parses your CRL to prevent regeneration in your case?

[hudecof]

I understand why you do not want an intelligent in generate_crl. Maybe this is not the right place to put this intelligent into. But I think that such a behavior should implement in r509,because only the r509 has full overview about the certificates status /access to the redis db/.
We are using r509-ca-http as frontend. The revoke/unrevoke api calls returns the new crl, so this use case could be considered as partially closed. There is still the end of the validity use case.

we heavy rely on the crl, since we have about 1500 users and they change quite fast.

[reaperhulk]

Ah I see. Yes, the revoke and unrevoke endpoints in r509-ca-http will generate a new CRL. We could create a "lazy_generate" endpoint on r509-ca-http that would cache the CRL and only generate a new one when it's within <lazy_generate_time> of expiry.