Found 2 records.

Status: Verified (1)

RFC 8182, "The RPKI Repository Delta Protocol (RRDP)", July 2017

Errata ID: 7239
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Job Snijders
Date Reported: 2022-11-04
Verifier Name: John Scudder
Date Verified: 2023-02-08

Section 3.2 says:

Certificate Authorities that use RRDP MUST include an instance of an
SIA AccessDescription extension in resource certificates they
produce, in addition to the ones defined in [RFC6487]:

It should say:

Certificate Authorities that use RRDP MUST include an instance of an
SIA AccessDescription extension in CA resource certificates they
produce, in addition to the ones defined in [RFC6487]:

Notes:

Between draft-ietf-sidr-delta-protocol-04 and draft-ietf-sidr-delta-protocol-05 a bit of text was removed (perhaps because it was considered redundant). But, unfortunately that snippet helped establish important context as to what types of certificates are expected to contain the id-ad-rpkiNotify accessMethod inside the Subject Information Access extension. The text that was removed:

"""
Relying Parties that do not support this delta protocol MUST MUST NOT
reject a CA certificate merely because it has an SIA extension
containing this new kind of AccessDescription.
"""

From the removed text is is clear that id-ad-rpkiNotify was only expected to show up on CA certificates. However, without the above text, Section 3.2 of RFC 8182 is somewhat ambiguous whether 'resource certificates' is inclusive of EE certificates or not.

RFC 6487 Section 4.8.8.2 sets expectations that only id-ad-signedObject is expected to show up in the SIA of EE certificates "Other AccessMethods MUST NOT be used for an EE certificates's SIA."

The ambiguity in RFC8182 led to one RIR including id-ad-rpkiNotify in the SIA of the EE certificate of all signed objects they produce (such as ROAs). The RIR indicated they'll work to remove id-ad-rpkiNotify from all EE certificates their CA implementation produces.

It should be noted that the presence of id-ad-rpkiNotify in EE certificates is superfluous; Relying Parties can't use the rpkiNotify accessMethod in EE certificates for any purpose in the validation decision tree.

(Verifying this Errata does not block a future transition from rsync to https; as RFC6487 Section 4.8.8.2 leaves room for additional instances of id-ad-signedObject with non-rsync URIs)

Status: Held for Document Update (1)

RFC 8182, "The RPKI Repository Delta Protocol (RRDP)", July 2017

Errata ID: 6919
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Ties de Kock
Date Reported: 2022-04-04
Held for Document Update by: Alvaro Retana
Date Held: 2022-04-18

Section 3.4.2 says:

   o  When a Relying Party encounters a "withdraw" element, or a
      "publish" element where an object is replaced, in a delta that it
      retrieves from a Repository Server, it MUST verify that the object
      to be withdrawn or replaced was retrieved from this same
      Repository Server before applying the appropriate action.  Failing
      to do so will leave the Relying Party vulnerable to malicious
      Repository Servers instructing it to delete or change arbitrary
      objects.

It should say:

   o  When a Relying Party encounters a "withdraw" element, or a
      "publish" element where an object is replaced, in a delta that it
      retrieves from a Repository Server, it MUST verify that the object
      to be withdrawn or replaced was retrieved from this same
      Repository Server before applying the appropriate action.  Failing
      to do so will leave the Relying Party vulnerable to malicious
      Repository Servers instructing it to delete or change arbitrary
      objects.

   o  For a "publish" or "withdraw" element, the hash MUST be present
      if the publication operation is overwriting an existing object,
      and it MUST NOT be present if this publication operation is writing
      to a new URI where no prior object exists.  Presence of an object
      when no "hash" attribute has been specified is an error, as is
      absence of an object or an incorrect hash value when a "hash"
      attribute has been specified. In this situation this file MUST be
      rejected.

Notes:

Text taken from RFC8181. For <publish> elements in RRDP deltas, the same process described in RFC8181 applies; "the hash of a publish MUST match to overwrite the existing file"

(This gap in the specification was independently spotted by C.J. around the same time)

Report New Errata