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

[Rob Austein <[e-mail]>]

Apologies for jumping in late here, I've been distracted by $dayjob
(which has not been RPKI for many years now) and only just saw this.

I fear that I must object, strongly, to Job's proposed change:

> > ----- section 4: Manifest Definition ----
> > 
> > OLD section 4.2.1 second paragraph:
> >    Because a "one-time-use" EE certificate is employed to verify a
> >    manifest, it is RECOMMENDED that the EE certificate 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.
> > 
> > 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.
> > 
> > ----- Section 5: Manifest Generation ----
> > 
> > OLD Section 5.1 last paragraph:
> >        It is RECOMMENDED that the validity interval of the EE
> >        certificate exactly match the thisUpdate and nextUpdate times of
> >        the manifest.
> >        Note: An RP MUST verify all mandated syntactic constraints, i.e.,
> >        constraints imposed on a CA via a "MUST".
> > 
> > NEW section 5.1:
> >        The validity interval of the EE certificate MUST exactly match
> >        the thisUpdate and nextUpdate times specified in the manifest's
> >        eContent. (An RP MUST NOT consider misalignment of the validity
> >        interval misalignment in and of itself to be an error.)

This business of pinning the manifiest EE certificate's validity
period to the manifest's thisUpdate/nextUpdate interval has always
been a bad idea, I've objected to it in the WG before, and we have a
long sad history of operational disasters resulting from
implementations that followed that recommendation.

The typical failure mode (demonstrated at least once each by three of
the RIRs) is to pick a thisUpdate/nextUpdate cycle on the order of a
day or so (reasonable), then go home for a long weekend, during which
something breaks and no new updates occur.

The manifest thisUpdate/nextUpdate semantics are (deliberately) very
much like the CRL semantics: failure to issue a new manifest by the
nextUpdate time does not automatically invalidate all the existing
data, it's just a hint that something might be wrong.  Think of it as
a staleness indication.  Slightly stale, log a warning but no big
deal (yet).  Gets stale enough, maybe you don't want to eat that.

Certificate expiration, on the other hand, is a hard failure.  When a
manifest's EE certificate expires without being replaced, the data
listed in the manifest is just gone.

So when an RIR does this with the manifest directly under their root
certificate, a large portion of the total database goes away.  Oops.

Manifests only have EE certificates because they're a patch on the
side of X.509.  If X.509 had allowed us to sign manifests using the CA
certificate, as with CRLs, we would have done that.  But it doesn't,
so we have the manifest EE certificates, OK, but that's no reason to
kill large portions of the database every time an operator near the
root of the tree says "oops".

All of this has been discussed before, and should be both in WG
archives and in notes from face to face meetings (probably both the
SIDR and SIDROPS WGs, not a new topic).

My own RPKI CA implementation uses the validity interval of the parent
CA certificate as the validity interval of the manifest EE
certificate, and has for about fifteen years now.  I'm not aware of
any operational problems that have arisen as a result.

Yes, there's a potential issue of a CRL getting too long, but if it
happens at all, it happens at a predictable rate, and one can always
rekey if it's really becoming big enough to be a problem.

Job's proposed change makes the bad idea a requirement rather than
just bad advice, hence my objection.