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

> On 10 Jul 2021, at 00:00, Job Snijders <job=40fastly.com@dmarc.ietf.org> 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.
> """

This text for 4.2.1 works for me. I think the SHOULD is appropriate because of existing deployment where this restriction was not present. Furthermore, while shortening the lifetime will help to keep the CRLs a bit shorter (in case of Krill 1 previous MFT EE revocation entry instead of 10, bear in mind there might be other entries for ROAs, certs..), I think this gain is marginal. I do not see how the security aspects are changed here, it just saves a small number of cycles.

Furthermore, I fail to see why a version increment of the manifest would be needed in this context. Before discussing the 'how' of such a transition I think the 'why' should be clear.

Kind regards,

Tim

> 
> Kind regards,
> 
> Job
> 
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops