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

[Russ Housley <[e-mail]>]

> On Jul 9, 2021, at 6:00 PM, Job Snijders <job=[e-mail]> wrote:
> 
> On Fri, Jul 09, 2021 at 02:28:50PM -0400, Stephen Kent wrote:
>>> 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.
>> 
>> I can modify the text to refer to this as a spec for version 1 (vs. 0)
>> manifests, if folks want to adopt this approach to aid transition to more
>> stringent CA and RP requirements.
> 
> I would like to suggest to not deploy the innate 'version' feature
> aspect of RPKI objects, when it concerns the Manifest object, for this
> purpose.
> 
> The community lacks experience with this type of transition mechanism,
> and I suspect some RPs will not be able to parse the eContent when they
> stumble upon a version field, even when it is set to 1. 
> 
> Given that CA's in their SIA currently can't point to two different
> Manifest objects, unless a new accessDescription element for the
> id-ad-rpkiManifest accessMethod is introduced. At that point CAs would
> be doubly publishing Manifests (v0 + v1)... all to reduce some potential
> churn in the CRL space.
> 
> If the objective only is to reduce CRL growth, the paragraph must be
> written in a way that makes it clear it only applies to certificate
> issuers, and is for their own benefit. 
> 
> I propose this text for Section 4.2.1 second paragraph:
> 
> """
>   When signing a manifest, it is RECOMMENDED to use an "one-time-use"
>   keypair. The EE certificate SHOULD 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.
> """

Job:

The point of the version field is to help know what to do when you stumble.

Russ