Re: [Ejbca-develop] Expired certificates entries being included in two CRLs issued beyond the certificate validity period

[Tomas G. <to...@pr...>]

Hi Jaime,

To be fair, the intent of RFC5280 is to make sure that a revocation
entry is included in at least one CRL, not exactly one. To protect users.

There are several ways where an entry is included in more than one CRL
with EJBCA. Another way is for example when you revoke more than 10K
records at a time, as EJBCA will only archive max 10K records each time
in order to protect against too long CRL generation times.

Anyhow, back to the questions below. Just using "now" misses the point
that delta CRLs can be used, and a revocation entry must be included in
the base CRL. This could probably be fixed by checking if it is a delta
CRL that is being generated...

Another corner case is when a certificate expired during CRL generation.
Large CRLs can take a long time to be generated, and is a certificate
expired between the listing of certificates to include on the CRL and
the actual completion of the CRL generation.

Another thing to think about with EJBCA is that you always have to
consider huge scale distributed systems, where databases are clustered
and CRL generation nodes can be spread out, and CRLs can be more than
hundred MB.
One thing we found out is that if anything can go wrong, it will
eventually when there are thousands of installations of that sort. Due
to this, the current code is the "safest" one I can think of to ensure
that each revocation is definitely at least on one base CRL.

It can be one two yes, but the likelihood that it will be missed is low.
(if generating delta CRLs it will be on only one base CRL).

Due to the above I don't plan to change this as it is hard to feel
absolutely safe with a small fix, and also with any complicated fix.
(Of course, parsing the last CRL looking for records is not an option
due to the time it can take on large CRLs)

Cheers,
Tomas

On 2019-07-20 02:36, Jaime Hablutzel wrote:
> From RFC 5280, "3.3. Revocation":
> 
>     An entry MUST NOT be removed
>     from the CRL until it appears on one regularly scheduled CRL issued
>     beyond the revoked certificate’s validity period.
> 
> 
> But, if you look carefully at the following code
> from org.ejbca.core.ejb.crl.PublishingCrlSessionBean#internalCreateCRL (r32721):
> 
> for (final RevokedCertInfo revokedCertInfo : revokedCertificates) {
>     ...
>     if ( !keepexpiredcertsoncrl && revokedCertInfo.getExpireDate() !=
> null && *revokedCertInfo.getExpireDate().before(lastCrlCreationDate)* ) {
>         ...
>         noConflictCertificateStoreSession.setStatus(archiveAdmin,
> revokedCertInfo.getCertificateFingerprint(),
> CertificateConstants.CERT_ARCHIVED);
>     } else {
>         ...
>     }
> }
> final byte[] crlBytes = generateAndStoreCRL(admin, ca,
> crlPartitionIndex, revokedCertificates, lastBaseCrlInfo, false);
> 
> You can see that the highlighted snippet won't become true until it is
> executed for a second time after a given certificate has expired,
> producing that expired certificate entries get into two CRLs instead of
> only one.
> 
> So, is there are reason to keep that code like that instead of replacing
> it with something like the following:
> 
> if ( !keepexpiredcertsoncrl && revokedCertInfo.getExpireDate() != null
> && *revokedCertInfo.getExpireDate().before(now)* ) {
> 
> Which would allow to include the expired certificate entries in only one
> CRL beyond the certificate validity period, providing this way a more
> precise RFC 5280 implementation?.
> 
> PS: The previous is not a production ready patch as it could have side
> effects that haven't been checked in detail.
> 
> -- 
> Jaime Hablutzel -  +51 994690880
> 
> 
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>