Re: [Sidrops] [Technical Errata Reported] RFC9286 (7243)

[Job Snijders <[e-mail]>]

Dear all,

I would recommend this errata be marked Verified.

When the specification was authored, I don't think it occurred to anyone
that subscribers might end up hammering the APIs of CA implementations
prompting issuers to issue more the frequently than once per second.

Although it seems somewhat unlikely for Relying Parties to see multiple
manifests issued within the same second (subsequent updates to the same
location probably coalesce); however, if an RP is faced with multiple
valid manifests with identical validity windows, the monotonically
increasing manifestNumber remains the strong tie-breaker.

The Errata's suggestion to substitute 'MUST be more recent' with "MUST
be current time" combined with "must be equal or more recent" to me
seems to be in spirit with the objective of adhering to a linear forward
progression of time when issuing products.

Kind regards,

Job

On Mon, Nov 07, 2022 at 08:35:22AM -0800, RFC Errata System wrote:
> The following errata report has been submitted for RFC9286,
> "Manifests for the Resource Public Key Infrastructure (RPKI)".
> 
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7243
> 
> --------------------------------------
> Type: Technical
> Reported by: Ties de Kock <[e-mail]>
> 
> Section: 4.2.1.  Manifest
> 
> Original Text
> -------------
>    thisUpdate:
>       This field contains the time when the manifest was created.  This
>       field has the same format constraints as specified in [RFC5280]
>       for the CRL field of the same name.  The issuer MUST ensure that
>       the value of this field is more recent than any previously
>       generated manifest.  Each RP MUST verify that this field value is
>       greater (more recent) than the most recent manifest it has
>       validated.  If this field in a purported "new" manifest is smaller
>       (less recent) than previously validated manifests, the RP SHOULD
>       use locally cached versions of objects, as described in
>       Section 6.6.
> 
> Corrected Text
> --------------
>     thisUpdate:
>       This field contains the time when the manifest was created. This
>       field has the same format constraints as specified in [RFC5280]
>       for the CRL field of the same name. The issuer MUST ensure that
>       the value of this field is equal to the current time and higher or
>       equal to the thisUpdate of any previously generated manifest. Each
>       RP MUST verify that this field value is greater or equal to (as,
>       or more recent) than the most recent manifest it has validated.
>       Suppose this field in a purported "new" manifest is smaller (less
>       recent) than previously validated manifests. In that case, the RP
>       SHOULD use locally cached versions of objects, as described in
>       Section 6.6.
> 
> 
> 
> Notes
> -----
> First of all: The previous text was not explicit that thisUpdate MUST contain the current time.
> 
> Second, in practice (e.g. multiple calls to a synchronous API) multiple manifests can be issued with the same thisUpdate. Under the previous text this would technically be misissuance. The propose text allows multiple manifests to be issued in the same second.
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> RFC9286 (draft-ietf-sidrops-6486bis-11)
> --------------------------------------
> Title               : Manifests for the Resource Public Key Infrastructure (RPKI)
> Publication Date    : June 2022
> Author(s)           : R. Austein, G. Huston, S. Kent, M. Lepinski
> Category            : PROPOSED STANDARD
> Source              : SIDR Operations
> Area                : Operations and Management
> Stream              : IETF
> Verifying Party     : IESG
> 
> _______________________________________________
> Sidrops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidrops