[Sidrops] Re: new idea: Canonical Cache Representation (draft-spaghetti-sidrops-rpki-ccr-00)

[Russ Housley <[e-mail]>]

Job:

Interesting approach.  The OID can be allocated under https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#security-smime-1

Russ

> On Sep 11, 2025, at 6:36 AM, Job Snijders <[e-mail]> wrote:
> 
> Dear all,
> 
> While working on the Erik Synchronisation protocol, it came to us that
> having a standardized way to represent (parts of) a cache's internal
> validation state would be a nifty way to help analyse whether RPs using
> Rsync, RRDP, Erik, or a mix of those (eventually) arrive at similar or
> dissimilar outcomes. The result of those discussions is a format named
> "Canonical Cache Representation" (CCR).
> 
> CCR is an *unsigned* data interchange format. It does not replace any
> currently existing components in the RPKI technology stack, it does not
> change anything to the validation procedures.
> 
> I'm also starting to suspect that the CCR format might be a very
> economic alternative to the 450-megabyte--per-piece rpkiviews.org
> tarballs I'm currently publishing. A PoC archive of historic CCRs is
> available here: https://miso.sobornost.net/rpki/ccr/ This PoC archive
> also is intended to help other implementers test their software.
> 
> I'm not 100% sure which IANA registry the OID assignment should come
> from, perhaps Russ can shed a light on that? Until then, I've assigned a
> PEN number for use in this phase of the standardization process.
> 
> Generation and decoding functionality for CCR objects has been
> implemented in rpki-client, so there is running code to look at!
> https://github.com/openbsd/src/blob/master/usr.sbin/rpki-client/ccr.c
> 
> As far as I know, at the moment a common approach to compare caches is
> to use the 'rtrmon' software package - or compare JSON/CSV outputs, but
> this has as downside the complication of another protocol (RTR) being
> inserted in the analytics pipeline, and also visibility into the
> 'physical' state (aka, the Manifests) is lost. CCR might help here.
> 
> I think it would be very useful (and kinda awesome!) if multiple
> different cache implementations could be compared using the CCR format!
> 
> Your feedback, comments, questions, and use-cases are most welcome!!!
> 
> Kind regards,
> 
> Job
> 
> ----- Forwarded message from [e-mail] -----
> 
> Date: Thu, 11 Sep 2025 02:08:23 -0700
> From: [e-mail]
> To: Bart Bakker <[e-mail]>, Job Snijders <[e-mail]>, Tim
> 	Bruijnzeels <[e-mail]>
> Subject: New Version Notification for draft-spaghetti-sidrops-rpki-ccr-00.txt
> 
> A new version of Internet-Draft draft-spaghetti-sidrops-rpki-ccr-00.txt has
> been successfully submitted by Job Snijders and posted to the
> IETF repository.
> 
> Name:     draft-spaghetti-sidrops-rpki-ccr
> Revision: 00
> Title:    A Profile for Resource Public Key Infrastructure (RPKI) Canonical Cache Representation (CCR)
> Date:     2025-09-11
> Group:    Individual Submission
> Pages:    14
> URL:      https://www.ietf.org/archive/id/draft-spaghetti-sidrops-rpki-ccr-00.txt
> Status:   https://datatracker.ietf.org/doc/draft-spaghetti-sidrops-rpki-ccr/
> HTML:     https://www.ietf.org/archive/id/draft-spaghetti-sidrops-rpki-ccr-00.html
> HTMLized: https://datatracker.ietf.org/doc/html/draft-spaghetti-sidrops-rpki-ccr
> 
> 
> Abstract:
> 
>   This document specifies a Canonical Cache Representation (CCR)
>   content type for use with the Resource Public Key Infrastructure
>   (RPKI).  CCR is a DER-encoded data interchange format which can be
>   used to represent various aspects of the state of a validated cache
>   at a particular point in time.  The CCR profile is a compact and
>   versatile format well-suited for a diverse set of applications such
>   as audit trail keeping, validated payload dissemination, and
>   analytics pipelines.
> 
> 
> 
> The IETF Secretariat
> 
> 
> 
> ----- End forwarded message -----
> 
> _______________________________________________
> Sidrops mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]