CVSROOT: /cvs
Module name: src
Changes by: j...@cvs.openbsd.org 2025/08/23 03:13:14
Modified files:
usr.sbin/rpki-client: Makefile extern.h main.c mft.c
output-bgpd.c output-bird.c output-json.c
output.c rpki-asn1.h rpki-client.8
Added files:
usr.sbin/rpki-client: ccr.c
Log message:
Add Canonical Cache Representation output
Canonical Cache Representation (CCR for short) is a lean DER-encoded
output that represents various aspects of the state of the RPKI
validated cache. CCR primarily exists to support and improve RPKI
analysis, diagnostic, and monitoring functions.
The CCR file format is described in ASN.1 notation in ccr.c. The format
description will likely later on move into an internet-draft. The format
is still subject to change.
How CCR works at a high level: each current RPKI Manifest represents the
current state of a given Certification Authority's caRepository.
Therefor, the hash of the Manifest object's file contents indirectly
represents the caRepository contents. In turn, a hash calculated over a
list of all those aforementioned hashes represents the entire
on-the-wire form of the validated cache.
The CCR file also contains a deduplicated & merged representation of all
validated ROA + ASPA payloads. This is the same data a BGP router would
ingest after sending a "Reset Query" to a RTR server. A hash over all
VRPs/VAPs represents the current _effective_ state of the RPKI. Being
able to easily differentiate between 'routine' changes in the ecosystem
(CRL resigning) and changes that might impact route decision making
seems useful.
with / OK tb@
