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

[Job Snijders <[e-mail]>]

Hi,

On Fri, Jul 09, 2021 at 12:39:48PM +0200, Tim Bruijnzeels wrote:
> > On 8 Jul 2021, at 20:09, Job Snijders <job=[e-mail]> wrote:
> > I think the latest changes looked great on paper (and indeed simplify
> > the text significantly), but are not operationally feasible.
> > 
> > Quoting from draft-ietf-sidrops-6486bis-05 section 4.2.1 "Manifest":
> >> Because a "one-time-use" EE certificate is employed to verify a
> >> manifest, the EE certificate MUST have a validity period that
> >> coincides with the interval from thisUpdate to nextUpdate in the
> >> manifest, to prevent needless growth of the CA's CRL.
> > 
> > It appears there are quite some CAs out there where 'nextUpdate' and
> > 'notAfter' are not equivalent, I estimate it would reduce the global VRP
> > count from ~ 263,175 down to ~ 209,931.
> 
> Indeed, I mentioned that Krill is doing it wrong (or well following
> earlier discussions but let's not dwell).
> 
> The fix is in the 0.9.1-dev branch but will take time to be deployed.
> There may also be other CA implementations which are affected by this.
> Though generally speaking hosted CA services could re-issue all their
> objects without the need for users of the service to upgrade.

Other CA implementations also appear impacted. What I meant with 'not
operationally feasible' is that we'd have to wait for all CAs to be
upgraded, then to upgrade all RPs to add the '-05 check', and all this
work would take place merely to decrease CRL traffic.

If we are looking to decrease traffic, I'd first remove XML from RRDP as
that appears a 50% bloat compared to using DER as container :-)

Given the sheer amount of upgrade work, and the particular order 'first
CA' -> 'then RP', I just don't see the current text as feasible.

> > I suspect the best we can do is demand that the EE certificate validity
> > window fully encompasses the Manifest validity window described in the
> > eContent, and merely recommend to align the two...
> 
> It may be appropriate to differentiate between what a CA MUST or
> SHOULD do and what an RP MUST reject.
> 
> What I am after is that I think:
> - a CA SHOULD (not MUST) have a validity period that coincides with the interval from thisUpdate to nextUpdate
> - an RP MUST reject a manifest if:
>     - thisUpdate is after now
>     - nextUpdate is before now
>     - EE not-before is after now
>     - EE not-after is before now

You'll also want to check if nextUpdate is not before thisUpdate!

The below link shows how rpki-client validates thisUpdate and
nextUpdate:

https://github.com/openbsd/src/blob/01ae73c5eb2d059ceb1d1734f72282cefb78d440/usr.sbin/rpki-client/mft.c#L82-L120

> One other note. NTP not being as perfect as we would like, I would
> advise backdating the 'thisUpdate' and not before a tiny bit, say 5
> minutes. 

Can you elaborate on your concern related to NTP and the need for
backdating?

I suspect that in this context it might not be needed to document such a
recommendation given that the WG appears to have agreed that polling
more frequently than once every ten minutes shouldn't happen, and the
publication server usually has some delays here and there in the
pipeline anyway (such as copying newly issued objects into a spool
directory).

Promoting the concept of backdating will probably bite us when we get a
proper Certificate Transparency project on the road. I expect that the
log operators and the certificate issuers will have their clocks synced
well within 5 minutes of slack.

Kind regards,

Job