[RPKI] transcient differences between rpki-client and routinator

[Martin Hoffmann]

Claudio Jeker wrote:
>
> The reason why rpki-client did not accept this ROA is because the CRL
> is bad:
> 
> rpki-client:
> repository.lacnic.net/rpki/lacnic/8bb5ab6a-b91f-439b-bdfb-eb3c43470d36/17ccf2e528990c3d8b0172b3372656083e3ddf4f.crl:
> bad message digest

Ah, right. Routinator doesn’t check the manifest hash of a CRL.
 
> Also why does routinator not fail for this ROA? I find it dangerous
> to fail open in such a case. It mostly disables revocation.

Initially, this was an oversight on my part. Job made a good point
about consistency between different implementations, so I will fix it.

However, I believe this is not a problem because there is no gain from
using CRLs in RPKI. The purpose of the CRL is to protect against replay
of revoked certificates or, in RPKI, revoked published objects. But
because these objects are registered with their hash in the manifest,
one would also need to replay an old manifest, which would then contain
the hash of the old CRL and one could replay that, too.

Also, there is a weird circular dependency. The manifest’s EE
certificate points to a CRL which I need to check in order for the
manifest to be valid, but this CRL is not valid unless its hash on the
very same manifest is valid.

The upshot is that, unless I am missing something, you can’t revoke a
manifest with the CRL that is delivered with itself and, transitively,
any object that is mentioned on the manifest.

If that were true, then CRLs only serve to make the system more
brittle, increased its overhead, and make it harder to implement
because of the requirement to revoke everything all the time.

But, this indeed is probably a discussion for SIDROPS and, as said, I’ll
fix Routinator for now.

Kind regards,
Martin