[Sidrops] Re: Mike Bishop's No Objection on draft-ietf-sidrops-manifest-numbers-08: (with COMMENT)

[Job Snijders <[e-mail]>]

Dear Mike, all,

Mike - thank you for the review. 

On Tue, Jan 13, 2026 at 04:36:02PM +1000, Tom Harrison wrote:
> On Wed, Aug 20, 2025 at 01:21:01PM -0700, Mike Bishop via Datatracker wrote:
> > With regard to the SHOULD NOT change filenames, I will note that one
> > common versioning approach in some areas is to give every version a
> > unique filename which will never change (immutable), such that all
> > prior versions can be retrieved if needed. Thus, I can conceive of a
> > CA that chooses to change the filename with each new manifest, such
> > that the old manifests remain available for comparison purposes. If
> > the filename is no longer considered a security mechanism, it's
> > unclear that this deployment pattern needs to be discouraged.
> 
> On this topic, all known CA implementations use stable filenames for
> manifests, and most follow the guidance in
> https://www.rfc-editor.org/rfc/rfc6481.html#section-2.2 about using a
> value derived from the public key of the CA.  We think that the chance
> of there being a CA using an alternative approach is sufficiently low
> that it's not necessary to expand on this point in the document.

I'd like to add a small elaboration here -

The practical reason "stable filenames" are used is that Manifests are
referenced from the issuer's CA certificate BY NAME.

The implication is that in a scheme where a new filename is used for
each new manifest, the parent certificate would also need to be reissued
to update this named reference... (and its parent's parent manifest & CA
certificate, recursively until the Trust Anchor itself).

In other words, "unstable manifest filenames" as a general practise
would negatively impact the RPKI's scalability.

Kind regards,

Job