CRL revocation dates in the future

[botovq]

I noticed that about 10-15% of revoked certificates in CRLs in my repository have revocation dates in the future (usually between now and some time before end of 2023). This is puzzling since RFC 5280, 5.1.2.6 clearly says: "The date on which the revocation occurred [...]", see also crl.rs in the rpki crate.

I believe this to be a consequence of #62 where the revocation_date member of commons::api::Revocation was renamed to expires. The crl_to_entries() method of Revocations takes the notAfter time of a cert, mft,... and places it as revocationDate in a CRL list. The idea seems to be that a cert has to be revoked as long as it isn't expired - see the purge() method.

[timbru]

Good catch, this is a bug indeed, caused by a misinterpretation on my part. Thank you for reporting this!

Fortunately the RPKI has additional protection by way of the manifests which say which objects are current. But even though this cannot lead to revoked objects being accepted by current RPKI validators, I agree that this needs to be fixed.

A very quick hack would be to use the date of CRL issuance instead. This is not correct but still better than using the expiry date. This is a fix I can do very quickly and include in the coming 0.9.5 release.

The actual revocation data currently isn't tracked - it can be fixed but it will involves changes in logic and a data migration to process historic data to get the real correct dates.

[timbru]

Will be in release 0.10.0