Revalidate certificate tree when objects expire

[erikrozendaal]

Tracks and shows the earliest object expiration time per trust anchor:

Re-validates the trust anchor certificate tree when this time is in the past.

[lolepezy]

It looks a little confusing: any user would think "AfriNic is going to revalidate tomorrow" and that's very different from what is set by all these "interval" settings in the config.

Do I understand correctly that it's actually the time when TA has to be validated again because objects will start to expire?

[lolepezy]

One thing I would want to make sure not going to happen -- if some objects are actually expired, are we going to spin in the loop revalidating the TA all over again?

[lolepezy]

And generally, what is the problem this PR solves?

[erikrozendaal]

It looks a little confusing: any user would think "AfriNic is going to revalidate tomorrow" and that's very different from what is set by all these "interval" settings in the config.

Do I understand correctly that it's actually the time when TA has to be validated again because objects will start to expire?

Yes. Maybe "earliest object expiration"? Valid until? Not valid after?

[erikrozendaal]

One thing I would want to make sure not going to happen -- if some objects are actually expired, are we going to spin in the loop revalidating the TA all over again?

Expired objects are invalid and are not taken into account when determining the nextValidatedNeededAt time. Certification is also throttled. But it could happen that a lot of objects expire one after another resulting in multiple runs, at most one per minute per TA.

[erikrozendaal]

And generally, what is the problem this PR solves?

Currently validated ROA prefixes and router certificates remain valid forever when certificate tree validation isn't run. This could happen when the CA no longer publishes objects. With this process expired objects will no longer be part of the the validation results.

[lolepezy]

And generally, what is the problem this PR solves?

Currently validated ROA prefixes and router certificates remain valid forever when certificate tree validation isn't run. This could happen when the CA no longer publishes objects. With this process expired objects will no longer be part of the the validation results.

Would it help it revalidate TA unconditionally every max(rsync-intrerval, rrdp-interval)? Or something along the lines "do the tree validation every N minutes unless it's already validated less than N minutes ago"?

Why I'm being picky about it: this PR is introducing the dependency of the running schedule on the data coming from somewhere on the internets, thus opening the can of worms of "it's spinning my CPU and I have not idea why"-type of bugs. And since we are going to kill it soon anyway, I would prefer it to be dumb and simple and not employ fancy scheduling strategies.

In principle, the change seems to be fine, except that it's hard to say what can potentially go wrong here.

[lolepezy]

Yes. Maybe "earliest object expiration"? Valid until? Not valid after?

'Earliest object expiration' sounds good to me, yes.

[erikrozendaal]

Why I'm being picky about it: this PR is introducing the dependency of the running schedule on the data coming from somewhere on the internets, thus opening the can of worms of "it's spinning my CPU and I have not idea why"-type of bugs. And since we are going to kill it soon anyway, I would prefer it to be dumb and simple and not employ fancy scheduling strategies.

If there are no more updates than validation jobs will be scheduled at most once a minute (for each trust anchor). However, this also requires many objects with "not valid after" times just one minute apart. And at some point it will end when all objects have expired...

I wanted to avoid running tree validation all the time just in case an object has expired, that's why this job is only triggered when needed.

Normally repository updates will trigger validation long before object expiration happens.