Re: [Sidrops] mft/ee validity time window alignment issue - Re: I-D Action: draft-ietf-sidrops-6486bis-05.txt

[Job Snijders <[e-mail]>]

On Fri, Jul 09, 2021 at 01:14:15PM +0200, Ties de Kock wrote:
> > Can you elaborate on your concern related to NTP and the need for
> > backdating?
> 
> I would suspect that Tim’s concern is that a certificate is
> effectively published and read by an RP before its validity period
> starts according to the local clock of the RP.
> 
> I have encountered this when using a VM where the clock had drifted.
> 
> I would expect that there is a fair amount of clock drift between RPs
> and issuing at the ‘current’ time gives a risk of objects being
> rejected by (a few) RPs.

I would argue that's the type of problem those few RPs need to overcome
themselves If the RP clock is wrong, the RP clock is wrong, which (in my
opinion) is not something the CA should try to resolve on their side. :-)

Even if the RP rejects some objects (because the RP's clock drifted),
the chances of the RP accepting the objects at the next validation run
are very high, because the RP will come back in 10 to 60 minutes.

Backdating to me seems a practic that'll cause confusion down the road,
and without backdating time-drifted RPs are likely to pick up the
objects a few minutes later anyway. Any log messages about 'not yet
valid objects' might help encourage the RPKI operator to fix their
clock. Masking such error messages through backdating is not entirely
helpful.

Where in WebPKI there might be an incentive for slight backdating (even
though it is consider a bad practise), inherent in the application of
the TLS technology stack there is no requirement 'to try again later',
in the RPKI technology stack we have clear requirements and expectations
about RPs periodically polling the CA repositories. This difference in
application and difference in timing parameters prompts me to caution
against backdating.

Kind regards,

Job