Re: [Sidrops] mft version field issue (Was: I-D Action: draft-ietf-sidrops-6486bis-05.txt)

[Job Snijders <[e-mail]>]

On Sat, Jul 10, 2021 at 02:56:47PM -0400, Stephen Kent wrote:
> In the IETF we usually employ a version number change to facilitate a
> transition to a new format, or to accommodate a change in the rules for
> processing an existing object. If RP software can't deal with a change of
> version number for an object, the RP software is seriously deficient.

If you mean by "RP software can't deal with a change of version" that
the RP crashes (or worse), indeed, I agree, of course.

What I meant with "the RP cannot parse the eContent", is that the RP
applies its validation procedure - expecting the version to 0, and if
the version is not 0 the RP considers the Manifest invalid, and thus all
subordinate products are lost from the RPs view.

A change of version number (going from 0 to 1) will mean RPs will reject
'version 1' manifests upon discovery. In your other message you
acknowledge that Manifests with an unexpected version field (or
unexpected contents) should be considered invalid.

> > 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.
> 
> I agree that a CA cannot point to two different manifests at the same time,
> using existing the existing SIA format. However, that does not mean that
> it's impossible to transition to a new manifest format. The CA  key rollover
> procedure, described in RFC 6489 describes a process which would allow a
> phased transition of a new manifest format.

I fail to see how a CA key rollover strategy can be applied to the
situation at hand, to facilitate introducing a new 'version' number in
the eContent.

When a CA 'refreshes' and starts pointing to a newly created manifest
object (version 1), any deployed RP unaware of what 'version 1' means
will discover and subsequently invalidate the Manifest.

To me it seems that 'version' is not backwards compatible for older RPs,
because it was not specified to be backwards compatible.

How can a CA cater to both last year's RPs (which all expect version 0),
and next year's RPs which support both v0 and v1? I fail to see the
migration path.

Kind regards,

Job

ps. to illustrate the point of the decision tree I'm looking at, see
below, all test & branch paths lead to 'goto out', which means the RP
will consider the manifest invalid. The introduction of a 'version 1'
object will cause older RPs to lose sight of the subordinate products.
This is not attractive to CAs, who generally wish to pass validation by
as many RPs as possible.

mft_version = ASN1_INTEGER_get(tt->value.integer);
if (mft_version == 0) {
	warnx("%s: RFC 6486 section 4.2.1 and X.690, 11.5: not"
	    " expecting version field for version 0", p->fn);
	goto out;
} else {
	warnx("%s: RFC 6486 section 4.2.1 unexpected version: "
	    "%ld", p->fn, mft_version);
	goto out;
}