CRL timestamp

[talcher]

Hello the EJBCA team,

I have a script which automatically generates CRL. The trigger is: "search for the latest revoked certificate in the database; if it is not in the CRL, create a new one."
To create a new CRL, I use the CLI tool: ejbca/bin/ejbca.sh ca createcrl.

What happened:

• certificate A was revoked at 14h18'35''
• at 14h20'01'', my script ran ejbca/bin/ejbca.sh ca createcrl
• the timestamp of the CRL is 14h20'36''
• certificate B is marked as revoked with the timestamp 14h20'09'' in the database: its serial number is not in the CRL. Maybe the createcrl command locks the database and the status change was registered later than 14h20'09'': I do not know
• at the next execution of my script, this serial number is added in the CRL.

I would have expected the timestamp of the CRL to be earlier than 14h20'09'', since certificate B's serial number is not in the CRL. Let's say 14h20'01'' when my script called the createcrl command.

What's your opinion on the matter?

Best regards,

talcher

[primetomas]

EJBCA will make a query to the database to list all certificates that are revoked. Although the transaction behavior can be database dependent, it makes sense that it will not pick up the one updated after the list transaction started. After this database listing the CRL itself is assembled and signed. This can also take some time, and the final timestamp on the CRL is when the actual CRL is finished, or almost finished as the timestamp is part of the signature so it's when the CRL was assembled, but before it's signed.

So it does make sense as it follows transaction logic imho.

[talcher]

Thanks, Tomas, for your answer.

I agree with you: the transaction logic is complied with.
However, I tend to think that this logic would be even more abode by, if the final timestamp were the time when the transaction actually started. That would somehow consider the whole process of generating a LCR as a single "transaction". That would mean:

1. keep in memory the current timestamp
2. do the databse-listing transaction
3. assemble the CRL with the saved timestamp
4. sign the CRL.

=> by so doing, any certificate whose status would change to "revoked" after action one would remain absent from the LCR - strict database-focused transaction logic - and the LCR's lastupdate would be prior to this status change - extended CRL-focused transaction logic.

Does it make any sense?

[primetomas]

While I see the logic I do not think it's a practical approach. It would become very difficult to handle all corner cases, we need to keep it a bit simple. It's already complex with expiration, removal from CRL, delta and partitioned CRLs.
CRLs can both take a long time to generate, and they can be short lived. If it's specified that a CRL validity time should be say 4 hours, making the CRL available shorter time because the timestamp is done 15 minutes before it was published may look bad (and I'm sure there is some compliance rule somewhere that forbids it). There are just to many corner cases, and too many uncertainties already (CRL generation time for example) to add any more uncertainties.

If you need minute granularity of revocation information I suggest OCSP as a better alternative.

The idea of generating a CRL for each revocation (that some schemes have) was really never designed for high volume environments. If a revocation event happens after a CRL was already started, you just have to queue another CRL generation after that.
I think that makes for a simple logic on the CRL generation side, because when you triggered a CRL generation is at least well known.

[talcher]

Thank you, Tomas, for your answer.