[Sidrops] Re: I-D Action: draft-ietf-sidrops-rpki-erik-protocol-06.txt

[Job Snijders <[e-mail]>]

On Thu, Aug 13, 2026 at 08:41:40PM +0400, Loganaden Velvindron wrote:
> For section 12.4.1 ErikIndex Media Type
> 
>    Type name:  application
>    Subtype name:  rpki-erikindex
>    Required parameters:  N/A
>    Optional parameters:  N/A
>    Encoding considerations:  binary
>    Security considerations:  This media type contains no active content.
> 
> I'm a bit worried about the security considerations as Erik objects contain
> untrusted metadata.

As a reminder - Publication Point operations and CA operations are
separate functions in the RPKI performed by separate entities. All
publication point metadata are unsigned (what key could they possibly be
signed with?).

> I would suggest improving the security considerations using the
> following instead: Erik objects are untrusted metadata and can cause
> clients to fetch additional objects or consume resources [see Security
> Section]

The above characterisation seems imperfect. It is not 'untrusted'
data, it is just unsigned data. But nitpicking aside, trusted data or
not, _all_ RPKI objects can cause clients to fetch additional objects
and consume resources, specifically CA certificates and Manifests.

An RRDP server can list many and large Delta files. An Rsync server can
send lots of data. This is the nature of fetching data across trust
boundaries.

At least in the Erik protocol the RP can validate the signature on
Manifest objects *before* proceeding to spending resources fetchingnthe
listed objects, whereas in RRDP this is not even possible. In this
sense, part of the Erik metadata _is_ signed data, because Manifests now
serve an additional purpose as layer in the transport.

The security considerations already state: "This document makes no
changes to RPKI certificate validation procedures." and importantly
"any cache-to-cache transport is assumed to be unreliable". The
security considerations of RFC 8182 apply, which is why that section is
referenced from the Erik internet-draft.

>From what I understand the main objective of the Media Type registration
security considerations is to indicate whether the content is active
(i.e., 'executable') or not. It is not intended to be an in-depth
analysis of the application use-case of the media type.

Kind regards,

Job