Re: [Sidrops] Benjamin Kaduk's Discuss on draft-ietf-sidrops-6486bis-09: (with DISCUSS and COMMENT)

[Ben Maddison <[e-mail]>]

Hi Rob,

On 03/20, Rob Austein wrote:
> On Thu, 17 Mar 2022 10:40:37 -0400, Job Snijders wrote:
> ...
> > > > > NEW Section 4.2.1:
> > > > >    Because a "one-time-use" EE certificate is employed to verify a
> > > > >    manifest, the EE certificate MUST be issued with a validity period
> > > > >    that coincides with the interval from thisUpdate to nextUpdate in the
> > > > >    manifest, to prevent needless growth of the CA's CRL.
> ...
> > CA operators are free to set the Manifest's eContent nextUpdate and the
> > CRLs nextUpdate as far into the future as they wish, each CA needs to
> > make a trade-off about how they schedule on-call on the weekends. CA
> > operators can nowadays rely on RP implementations only permitting the
> > narrowest validity window transitively concluded from the entire chain.
> 
> Except that you're changing the semantics of nextUpdate from "stale"
> to "hard failure", which is dangerously wrong and is not what the
> semantics were intended to be by the original authors before you took
> up the pen.

tl;dr: I think -10 accurately reflects the consensus in the WG.

One of the primary motivations for this document was, from it's
inception, to clarify that a Manifest with nextUpdate in the past is
stale *and should result in a failed fetch*.
This is set out in section 6.3:

    If the current time is later than nextUpdate, then the manifest is
    stale; this is a failed fetch and RP MUST proceed to Section 6.6;

Then, in section 6.6:

    Termination of processing means that the RP SHOULD continue to use
    cached versions of the objects associated with this CA instance,
    until such time as they become stale or they can be replaced by
    objects from a successful fetch.

Both sentences have been present since -00.

Thus, an RP that encounters a manifest with nextUpdate in the past will
attempt to fall back to its local cache.
If the manifest (if any) in the cache also has nextUpdate in the past
then it is discarded, and its associated repository is not processed
further.

Clearly an RP will similarly refuse to process a manifest whose signing
EE cert has a notAfter in the past.

Thus, for all practical purposes, the terms "stale" and "expired" are
synonymous when applied to manifests. The time at which that happens is
the *earlier of either nextUpdate or notAfter*.

The text of 4.2.1 is merely incidental to all of this. It is there for
no reason other than to limit CRL growth.

Cheers,

Ben