Re: CCR ASPA parser missing upper-bound check on provider count

Hi Daniel,

This is AI slop. Your message contains hallucinations and misrepresents
the risks and technologies involved.

On Wed, Apr 08, 2026 at 10:57:46PM -0400, Daniel Anderson wrote:
> parse_aspa_providers() in ccr.c validates the lower bound of the provider
> count but does NOT enforce the upper bound against MAX_ASPA_PROVIDERS.

Correct, this is by design.

> Buggy code in ccr.c, lines 1281-1295:

It is not buggy code.

> The standalone ASPA parser in aspa.c correctly checks both bounds
> (lines 61-70):

Exactly.

> The CCR (Compact Certificate Revocation) parser is a newer addition that
> did not replicate the upper-bound guard present in the original ASPA parser.

You have dreamt up the expansion of that acronym. That is not at all
what CCR means. Did you even read the CCR specification?

> Impact:
>   The attack is directly reachable: an attacker who controls an RPKI
>   repository can publish a crafted CCR object that triggers this path
>   during normal rpki-client operation.

Nonsense. CCR objects are not published via RPKI repositories. CCR
objects are not ingested via RPKI repositories. Even if a RPKI
repository were to contain a '.ccr' file, this RP implementation would
ignore that object because CCR objects are not published via RPKI
repositories.

CCR are an experimental debugging facility. Setting maximum values like
you propose does not help operators.

- Job