RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 2 records.

Status: Verified (1)

RFC 9286, "Manifests for the Resource Public Key Infrastructure (RPKI)", June 2022

Source of RFC: sidrops (ops)

Errata ID: 7118
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML

Reported By: Job Snijders
Date Reported: 2022-09-03
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2022-09-06

Section Appendix A says:

fileList           SEQUENCE SIZE (0..MAX) OF FileAndHash

It should say:

fileList           SEQUENCE SIZE (1..MAX) OF FileAndHash

Notes:

Section 7 specifies " A CA's manifest will always contain at least one entry"; therefor, a fileList sequence of size 0 is invalid.

Status: Reported (1)

RFC 9286, "Manifests for the Resource Public Key Infrastructure (RPKI)", June 2022

Source of RFC: sidrops (ops)

Errata ID: 7243
Status: Reported
Type: Technical
Publication Format(s) : TEXT, PDF, HTML

Reported By: Ties de Kock
Date Reported: 2022-11-07

Section 4.2.1. Manifest says:

   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.

It should say:

    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.

Report New Errata



Advanced Search