<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc sortrefs="yes"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-sidrops-rpki-ccr-03" ipr="trust200902" xml:lang="en" sortRefs="true" submissionType="IETF" consensus="true" version="3">
  <front>
    <title abbrev="RPKI Canonical Cache Representation">
      A Profile for Resource Public Key Infrastructure (RPKI) Canonical Cache Representation (CCR)
    </title>
    <author fullname="Job Snijders" initials="J." surname="Snijders">
      <organization abbrev="BSD">BSD Software Development</organization>
      <address>
        <postal>
          <street/>
          <code/>
          <city>Amsterdam</city>
          <country>Netherlands</country>
        </postal>
        <email>job@bsd.nl</email>
        <uri>https://www.bsd.nl</uri>
      </address>
    </author>
    <author fullname="Bart Bakker" initials="B." surname="Bakker">
      <organization>RIPE NCC</organization>
      <address>
        <postal>
          <country>Netherlands</country>
        </postal>
        <email>bbakker@ripe.net</email>
      </address>
    </author>
    <author fullname="Tim Bruijnzeels" initials="T." surname="Bruijnzeels">
      <organization>RIPE NCC</organization>
      <address>
        <postal>
          <country>Netherlands</country>
        </postal>
        <email>tbruijnzeels@ripe.net</email>
      </address>
    </author>
    <author fullname="Theo Buehler" initials="T." surname="Buehler">
      <organization>OpenBSD</organization>
      <address>
        <postal>
          <country>Switzerland</country>
        </postal>
        <email>tb@openbsd.org</email>
      </address>
    </author>
    <date/>
    <area>ops</area>
    <workgroup>SIDROPS</workgroup>
    <keyword>security</keyword>
    <keyword>cryptography</keyword>
    <keyword>X.509</keyword>
    <abstract>
      <t>
        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.
      </t>
    </abstract>
  </front>
  <middle>
    <section anchor="intro">
      <name>Introduction</name>
      <t>
        This document specifies a Canonical Cache Representation (CCR) content type for use with the Resource Public Key Infrastructure (RPKI).
        A validated cache contains all RPKI objects that the Relying Party (RP) has verified to be valid according to the rules for validation (see <xref target="RFC6487"/>, <xref target="RFC6488"/>, <xref target="RFC9286"/>).
        CCR is a data interchange format using Distinguished Encoding Rules (DER, <xref target="X.690"/>) 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 record keeping, validated payload dissemination, and analytics pipelines.
      </t>
      <t>
         The format was primarily designed to support comparative analysis of uniformities and differences among multiple RP instances using different RPKI transport protocols (such as <xref target="RFC5781"/>, <xref target="RFC8182"/>, and <xref target="I-D.ietf-sidrops-rpki-erik-protocol"/>).
      </t>
      <section anchor="requirements">
        <name>Requirements Language</name>
        <t>
          The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.
        </t>
      </section>
    </section>
    <section>
      <name>The Canonical Cache Representation content type</name>
      <t>
        The content of a CCR file is an instance of <tt>ContentInfo</tt>.
      </t>
      <t>
        The <tt>contentType</tt> for a CCR is defined as <tt>id-ct-rpkiCanonicalCacheRepresentation</tt>, with Object Identifier (OID) <tt>1.2.840.113549.1.9.16.1.54</tt>.
      </t>
      <t>
        The <tt>content</tt> field contains an instance of <tt>RpkiCanonicalCacheRepresentation</tt>.
      </t>
    </section>
    <section anchor="content">
      <name>The Canonical Cache Representation content</name>
      <t>
        The content of a Canonical Cache Representation is formally defined as follows:
      </t>
      <sourcecode anchor="ASN.1" type="asn.1" originalSrc="CCR-2025.asn">RpkiCanonicalCacheRepresentation-2025
  { iso(1) member-body(2) us(840) rsadsi(113549)
    pkcs(1) pkcs9(9) smime(16) mod(0) id-mod-rpkiCCR-2025(TBD) }

DEFINITIONS EXPLICIT TAGS ::=
BEGIN

IMPORTS
  CONTENT-TYPE, Digest, DigestAlgorithmIdentifier,
    SubjectKeyIdentifier
  FROM CryptographicMessageSyntax-2010 -- in [RFC6268]
    { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
      pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) }

  ASID, ROAIPAddressFamily
  FROM RPKI-ROA-2023 -- in [RFC9582]
    { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
      pkcs9(9) smime(16) mod(0) id-mod-rpkiROA-2023(75) }

  CertificateSerialNumber, SubjectPublicKeyInfo
  FROM PKIX1Explicit-2009
    { iso(1) identified-organization(3) dod(6) internet(1)
      security(5) mechanisms(5) pkix(7) id-mod(0)
      id-mod-pkix1-explicit-02(51) }

  AccessDescription, KeyIdentifier
  FROM PKIX1Implicit-2009
    { iso(1) identified-organization(3) dod(6) internet(1)
      security(5) mechanisms(5) pkix(7) id-mod(0)
      id-mod-pkix1-implicit-02(59) }
  ;

ContentInfo ::= SEQUENCE {
  contentType      CONTENT-TYPE.&amp;id({ContentSet}),
  content      [0] EXPLICIT
                   CONTENT-TYPE.&amp;Type({ContentSet}{@contentType}) }

ContentSet CONTENT-TYPE ::= {
  ct-rpkiCanonicalCacheRepresentation, ... }

ct-rpkiCanonicalCacheRepresentation CONTENT-TYPE ::=
  { TYPE RpkiCanonicalCacheRepresentation
    IDENTIFIED BY id-ct-rpkiCanonicalCacheRepresentation }

id-ct-rpkiCanonicalCacheRepresentation OBJECT IDENTIFIER ::=
  { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
    pkcs-9(9) id-smime(16) id-ct(1) ccr(54) }

RpkiCanonicalCacheRepresentation ::= SEQUENCE {
  version     [0] INTEGER DEFAULT 0,
  hashAlg         DigestAlgorithmIdentifier,
  producedAt      GeneralizedTime,
  mfts        [1] ManifestState OPTIONAL,
  vrps        [2] ROAPayloadState OPTIONAL,
  vaps        [3] ASPAPayloadState OPTIONAL,
  tas         [4] TrustAnchorState OPTIONAL,
  rks         [5] RouterKeyState OPTIONAL,
  ... }
  -- at least one of mfts, vrps, vaps, tas, or rks MUST be present
  ( WITH COMPONENTS { ..., mfts PRESENT } |
    WITH COMPONENTS { ..., vrps PRESENT } |
    WITH COMPONENTS { ..., vaps PRESENT } |
    WITH COMPONENTS { ..., tas PRESENT } |
    WITH COMPONENTS { ..., rks PRESENT } )

ManifestState ::= SEQUENCE {
  mis               SEQUENCE OF ManifestInstance,
  mostRecentUpdate  GeneralizedTime,
  hash              Digest }

ManifestInstance ::= SEQUENCE {
  hash              Digest,
  size              INTEGER (1000..MAX),
  aki               KeyIdentifier,
  manifestNumber    INTEGER (0..MAX),
  thisUpdate        GeneralizedTime,
  locations         SEQUENCE (SIZE(1..MAX)) OF AccessDescription,
  subordinates      SEQUENCE (SIZE(1..MAX)) OF SubjectKeyIdentifier
                      OPTIONAL }

ROAPayloadState ::= SEQUENCE {
  rps               SEQUENCE OF ROAPayloadSet,
  hash              Digest }

ROAPayloadSet ::= SEQUENCE {
  asID              ASID,
  ipAddrBlocks      SEQUENCE (SIZE(1..2)) OF ROAIPAddressFamily }

ASPAPayloadState ::= SEQUENCE {
  aps               SEQUENCE OF ASPAPayloadSet,
  hash              Digest }

ASPAPayloadSet ::= SEQUENCE {
  customerASID      ASID,
  providers         SEQUENCE (SIZE(1..MAX)) OF ASID }

TrustAnchorState ::= SEQUENCE {
  skis              SEQUENCE (SIZE(1..MAX)) OF SubjectKeyIdentifier,
  hash              Digest }

RouterKeyState ::= SEQUENCE {
  rksets            SEQUENCE OF RouterKeySet,
  hash              Digest }

RouterKeySet ::= SEQUENCE {
  asID              ASID,
  routerKeys        SEQUENCE (SIZE(1..MAX)) OF RouterKey }

RouterKey ::= SEQUENCE {
  ski               SubjectKeyIdentifier,
  spki              SubjectPublicKeyInfo }

END
</sourcecode>
      <section>
        <name>version</name>
        <t>
          The <tt>version</tt> field contains the format version for the <tt>RpkiCanonicalCacheRepresentation</tt> structure, in this version of the specification it <bcp14>MUST</bcp14> be 0.
        </t>
      </section>
      <section>
        <name>hashAlg</name>
        <t>
          The <tt>hashAlg</tt> field specifies the algorithm used to construct the message digests.
          This profile uses SHA-256 <xref target="SHS"/>, therefore the OID <bcp14>MUST</bcp14> be <tt>2.16.840.1.101.3.4.2.1</tt>.
        </t>
      </section>
      <section>
        <name>producedAt</name>
        <t>
          The <tt>producedAt</tt> field contains a <tt>GeneralizedTime</tt> and indicates the moment in time the CCR was generated.
        </t>
      </section>
      <section>
        <name>State aspect fields</name>
        <t>
          Each CCR contains one or more fields representing particular aspects of the cache's state.
          Implementers should note the ellipsis extension marker in the <tt>RpkiCanonicalCacheRepresentation</tt> ASN.1 notation and anticipate future changes as new signed object types are standardized.
        </t>
        <t>
          Each state aspect generally consists of a sequence of details extracted from RPKI Objects of a specific type, along with a digest computed by hashing the aforementioned DER-encoded sequence, optionally including some metadata.
        </t>
        <section>
          <name>ManifestState</name>
          <t>
            An instance of <tt>ManifestState</tt> represents the set of valid, current Manifests (<xref target="RFC9286"/>) in the cache.
            It contains three fields: <tt>mis</tt>, <tt>mostRecentUpdate</tt>, and <tt>hash</tt>.
          </t>
          <section>
            <name>ManifestInstance</name>
            <t>
              The <tt>mis</tt> field contains a SEQUENCE of <tt>ManifestInstance</tt>.
              There is one <tt>ManifestInstance</tt> for each current manifest.
              A manifest is nominally current until the time specified in nextUpdate or until a manifest is issued with a greater manifestNumber, whichever comes first (see <xref target="RFC9286" section="4.2.1"/>).
            </t>
            <t>
              A <tt>ManifestInstance</tt> is a structure consisting of the following fields:
            </t>
            <dl>
              <dt><tt>hash</tt></dt>
              <dd>the hash of the represented DER-encoded manifest object</dd>
              <dt><tt>size</tt></dt>
              <dd>the size of the represented DER-encoded manifest object</dd>
              <dt><tt>aki</tt></dt>
              <dd>the manifest issuer's key identifier</dd>
              <dt><tt>manifestNumber</tt></dt>
              <dd>the manifest number contained within the manifest's eContent field</dd>
              <dt><tt>thisUpdate</tt></dt>
              <dd>the thisUpdate contained within the manifest's eContent field</dd>
              <dt><tt>locations</tt></dt>
              <dd>a sequence of <tt>AccessDescription</tt> instances from the manifest's End-Entity certificate's Subject Information Access extension</dd>
              <dt><tt>subordinates</tt></dt>
              <dd>a optional non-empty SEQUENCE of <tt>SubjectKeyIdentifier</tt></dd>
            </dl>
            <t>
              The <tt>subordinates</tt> field represents the keypairs associated with the set of non-revoked, non-expired, validly signed, certification authority (CA) resource certificates subordinate to the manifest issuer.
              Each <tt>SubjectKeyIdentifier</tt> is the 160-bit SHA-1 hash of the value of the DER-encoded ASN.1 bit string of the resource certificate's Subject Public Key, as described in <xref target="RFC6487" section="4.8.2"/>.
              The sequence elements of the <tt>subordinates</tt> field <bcp14>MUST</bcp14> be sorted in ascending order by interpreting each <tt>SubjectKeyIdentifier</tt> value as an unsigned 160-bit integer and <bcp14>MUST</bcp14> be unique with respect to each other.
            </t>
            <t>
              The sequence elements in the <tt>mis</tt> field <bcp14>MUST</bcp14> be sorted in ascending order by <tt>hash</tt> value contained in each instance of <tt>ManifestInstance</tt> and <bcp14>MUST</bcp14> be unique with respect to the other instances of <tt>ManifestInstance</tt>.
            </t>
          </section>
          <section>
            <name>mostRecentUpdate</name>
            <t>
              The <tt>mostRecentUpdate</tt> is a metadata field which contains the most recent <tt>thisUpdate</tt> amongst all current manifests represented by the <tt>ManifestInstance</tt> structures.
              If the <tt>mis</tt> field contains an empty sequence, the <tt>mostRecentUpdate</tt> <bcp14>MUST</bcp14> be set to the POSIX Epoch ("19700101000000Z").
            </t>
          </section>
          <section>
            <name>hash</name>
            <t>
              The <tt>hash</tt> field contains a message digest computed using the <tt>mis</tt> value (encoded in DER format) as input message.
            </t>
          </section>
        </section>
        <section>
          <name>ROAPayloadState</name>
          <t>
            An instance of <tt>ROAPayloadState</tt> contains a field named <tt>rps</tt> which represents the current set of Validated ROA Payloads (<xref target="RFC6811" section="2"/>) encoded as a SEQUENCE of <tt>ROAPayloadSet</tt> instances.
          </t>
          <t>
            The <tt>ROAPayloadSet</tt> structure is modeled after the <tt>RouteOriginAttestation</tt> (<xref target="RFC9582" section="4"/>).
            The <tt>asID</tt> value in each instance of <tt>ROAPayloadSet</tt> <bcp14>MUST</bcp14> be unique with respect to other instances of <tt>ROAPayloadSet</tt>.
            The contents of the <tt>ipAddrBlocks</tt> field <bcp14>MUST</bcp14> appear in canonical form and ordered as defined in <xref target="RFC9582" section="4.3.3"/>.
          </t>
          <t>
            The <tt>hash</tt> field contains a message digest computed using the <tt>rps</tt> value (encoded in DER format) as input message.
          </t>
        </section>
        <section>
          <name>ASPAPayloadState</name>
          <t>
            An instance of <tt>ASPAPayloadState</tt> contains an <tt>aps</tt> field which represents the current set of deduplicated and merged ASPA payloads (<xref target="I-D.ietf-sidrops-aspa-profile"/>) ordered by ascending <tt>customerASID</tt> value encoded as a SEQUENCE of <tt>ASPAPayloadSet</tt> instances.
            The <tt>customerASID</tt> value in each instance of <tt>ASPAPayloadSet</tt> <bcp14>MUST</bcp14> be unique with respect to other instances of <tt>ASPAPayloadSet</tt>.
          </t>
          <t>
            The <tt>ASPAPayloadSet</tt> structure is modeled after the <tt>ProviderASSet</tt> (<xref target="I-D.ietf-sidrops-aspa-profile" section="3.3"/>).
          </t>
          <t>
            The <tt>hash</tt> field contains a message digest computed using the <tt>aps</tt> value (encoded in DER format) as input message.
          </t>
        </section>
        <section>
          <name>TrustAnchorState</name>
          <t>
            An instance of <tt>TrustAnchorState</tt> represents the set of valid Trust Anchor (TA) Certification Authority (CA) resource certificates used by the relying party when producing the CCR.
          </t>
          <t>
            Each <tt>SubjectKeyIdentifier</tt> is the 160-bit SHA-1 hash of the value of the DER-encoded ASN.1 bit string of the TA's Subject Public Key, as described in <xref target="RFC6487" section="4.8.2"/>.
            The <tt>skis</tt> field contains a sequence of Subject Key Identifiers (SKI) sorted in ascending order by interpreting the SKI value as an unsigned 160-bit integer.
          </t>
          <t>
            The <tt>hash</tt> field contains a message digest computed using the <tt>skis</tt> value (encoded in DER format) as input message.
          </t>
        </section>
        <section>
          <name>RouterKeyState</name>
          <t>
            An instance of <tt>RouterKeyState</tt> contains an <tt>rksets</tt> field which represents the current set of valid BGPsec Router Keys <xref target="RFC8205"/> encoded as a SEQUENCE of <tt>RouterKeySet</tt> instances.
            The <tt>asID</tt> value in each instance of <tt>RouterKeySet</tt> <bcp14>MUST</bcp14> be unique with respect to other instances of <tt>RouterKeySet</tt>.
            Instances of <tt>RouterKeySet</tt> are sorted by ascending value of <tt>asID</tt>.
            Instances of <tt>RouterKey</tt> are sorted by ascending value of <tt>ski</tt> by interpreting the SKI value as an unsigned 160-bit integer.
          </t>
          <t>
            The <tt>hash</tt> field contains a message digest computed using the <tt>rks</tt> value (encoded in DER format) as input message.
          </t>
        </section>
      </section>
    </section>
    <section>
      <name>Operational Considerations</name>
      <t>
        Comparing the ManifestState <tt>mostRecentUpdate</tt> timestamp value with the <tt>producedAt</tt> timestamp might help offer insight into the timing and propagation delays of the RPKI supply chain.
      </t>
      <t>
        CCR content compresses very well due to the fairly repetitive nature of content in certain fields, consistent ordering, and the absence of public keys.
        Readers and writers of CCR data are <bcp14>RECOMMENDED</bcp14> to support data compression using Gzip (<xref target="RFC1952"/>).
      </t>
      <section>
        <name>Verifying CCR file integrity</name>
        <t>
          The integrity of a CCR object can be checked by confirming whether the hash values embedded inside state aspects match the computed hash value of the respective state aspect payload structure.
        </t>
      </section>
    </section>
    <section anchor="security">
      <name>Security Considerations</name>
      <t>
        CCR objects are not signed objects.
      </t>
    </section>
    <section anchor="iana">
      <name>IANA Considerations</name>
      <section>
        <name>SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1)</name>
        <t>
          IANA has allocated the following in the "SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1)" registry:
        </t>
        <table anchor="cms-content-type" align="center">
          <name/>
          <thead>
            <tr>
              <th rowspan="1" colspan="1">Decimal</th>
              <th rowspan="1" colspan="1">Description</th>
              <th rowspan="1" colspan="1">References</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td>54</td>
              <td>id-ct-rpkiCanonicalCacheRepresentation</td>
              <td>draft-ietf-sidrops-rpki-ccr</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section>
        <name>RPKI Repository Name Schemes</name>
        <t>
          IANA is requested to add the Canonical Cache Representation file extension to the "RPKI Repository Name Schemes" registry <xref target="RFC6481"/> as follows:
        </t>
        <table anchor="rpki-repository-name-schemes" align="center">
          <name/>
          <thead>
            <tr>
              <th rowspan="1" colspan="1">Filename Extension</th>
              <th rowspan="1" colspan="1">RPKI Object</th>
              <th rowspan="1" colspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td>.ccr</td>
              <td>Canonical Cache Representation</td>
              <td>draft-ietf-sidrops-rpki-ccr</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section>
        <name>SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)</name>
        <t>
          IANA is requested to allocate the following in the "SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)" registry:
        </t>
        <table anchor="smi-security-identifier" align="center">
          <name/>
          <thead>
            <tr>
              <th rowspan="1" colspan="1">Decimal</th>
              <th rowspan="1" colspan="1">Description</th>
              <th rowspan="1" colspan="1">References</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td>TBD</td>
              <td>id-mod-rpkiCCR-2025</td>
              <td>draft-ietf-sidrops-rpki-ccr</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section>
        <name>Media Types</name>
        <t>
          IANA is requested to register the media types "application/rpki-ccr" and "application/rpki-ccr+gz" in the "Media Types" registry as follows:
        </t>
        <section>
          <name>Canonical Cache Representation Media Type</name>
          <dl spacing="compact">
            <dt>Type name:</dt>
            <dd>application</dd>
            <dt>Subtype name:</dt>
            <dd>rpki-ccr</dd>
            <dt>Required parameters:</dt>
            <dd>N/A</dd>
            <dt>Optional parameters:</dt>
            <dd>N/A</dd>
            <dt>Encoding considerations:</dt>
            <dd>binary</dd>
            <dt>Security considerations:</dt>
            <dd>This media type contains no active content.</dd>
            <dt>Interoperability considerations:</dt>
            <dd>N/A</dd>
            <dt>Published specification:</dt>
            <dd>draft-ietf-sidrops-rpki-ccr</dd>
            <dt>Applications that use this media type:</dt>
            <dd>RPKI operators</dd>
            <dt>Fragment identifier considerations:</dt>
            <dd>N/A</dd>
            <dt>Additional information:</dt>
            <dd>
              <dl spacing="compact">
                <dt><br/></dt>
                <dd/>
                <dt>Content:</dt>
                <dd>This media type is a RPKI Canonical Cache Representation object, as defined in draft-ietf-sidrops-rpki-ccr.</dd>
                <dt>Magic number(s):</dt>
                <dd>N/A</dd>
                <dt>File extension(s):</dt>
                <dd>.ccr</dd>
                <dt>Macintosh file type code(s):</dt>
                <dd>N/A</dd>
              </dl>
            </dd>
            <dt>Person &amp; email address to contact for further information:</dt>
            <dd>Job Snijders (job@bsd.nl)</dd>
            <dt>Intended usage:</dt>
            <dd>COMMON</dd>
            <dt>Restrictions on usage:</dt>
            <dd>N/A</dd>
            <dt>Author:</dt>
            <dd>Job Snijders (job@bsd.nl)</dd>
            <dt>Change controller:</dt>
            <dd>IETF</dd>
          </dl>
          <dl spacing="compact">
            <dt><br/></dt>
            <dd/>
            <dt>Type name:</dt>
            <dd>application</dd>
            <dt>Subtype name:</dt>
            <dd>rpki-ccr+gz</dd>
            <dt>Content:</dt>
            <dd>This media type is a Gzip compressed RPKI Canonical Cache Representation object, as defined in draft-ietf-sidrops-rpki-ccr.</dd>
            <dt>Magic number(s):</dt>
            <dd>N/A</dd>
            <dt>File extension(s):</dt>
            <dd>.ccr.gz</dd>
            <dt>References:</dt>
            <dd>RFC1952, RFC6713</dd>
            <dt>Encoding considerations:</dt>
            <dd>gzip is a binary encoding</dd>
          </dl>
        </section>
      </section>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC6481" target="https://www.rfc-editor.org/info/rfc6481" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6481.xml">
          <front>
            <title>A Profile for Resource Certificate Repository Structure</title>
            <author fullname="G. Huston" initials="G." surname="Huston"/>
            <author fullname="R. Loomans" initials="R." surname="Loomans"/>
            <author fullname="G. Michaelson" initials="G." surname="Michaelson"/>
            <date month="February" year="2012"/>
            <abstract>
              <t>This document defines a profile for the structure of the Resource Public Key Infrastructure (RPKI) distributed repository. Each individual repository publication point is a directory that contains files that correspond to X.509/PKIX Resource Certificates, Certificate Revocation Lists and signed objects. This profile defines the object (file) naming scheme, the contents of repository publication points (directories), and a suggested internal structure of a local repository cache that is intended to facilitate synchronization across a distributed collection of repository publication points and to facilitate certification path construction. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6481"/>
          <seriesInfo name="DOI" value="10.17487/RFC6481"/>
        </reference>
        <reference anchor="RFC6487" target="https://www.rfc-editor.org/info/rfc6487" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6487.xml">
          <front>
            <title>A Profile for X.509 PKIX Resource Certificates</title>
            <author fullname="G. Huston" initials="G." surname="Huston"/>
            <author fullname="G. Michaelson" initials="G." surname="Michaelson"/>
            <author fullname="R. Loomans" initials="R." surname="Loomans"/>
            <date month="February" year="2012"/>
            <abstract>
              <t>This document defines a standard profile for X.509 certificates for the purpose of supporting validation of assertions of "right-of-use" of Internet Number Resources (INRs). The certificates issued under this profile are used to convey the issuer's authorization of the subject to be regarded as the current holder of a "right-of-use" of the INRs that are described in the certificate. This document contains the normative specification of Certificate and Certificate Revocation List (CRL) syntax in the Resource Public Key Infrastructure (RPKI). This document also specifies profiles for the format of certificate requests and specifies the Relying Party RPKI certificate path validation procedure. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6487"/>
          <seriesInfo name="DOI" value="10.17487/RFC6487"/>
        </reference>
        <reference anchor="RFC6488" target="https://www.rfc-editor.org/info/rfc6488" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6488.xml">
          <front>
            <title>Signed Object Template for the Resource Public Key Infrastructure (RPKI)</title>
            <author fullname="M. Lepinski" initials="M." surname="Lepinski"/>
            <author fullname="A. Chi" initials="A." surname="Chi"/>
            <author fullname="S. Kent" initials="S." surname="Kent"/>
            <date month="February" year="2012"/>
            <abstract>
              <t>This document defines a generic profile for signed objects used in the Resource Public Key Infrastructure (RPKI). These RPKI signed objects make use of Cryptographic Message Syntax (CMS) as a standard encapsulation format. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6488"/>
          <seriesInfo name="DOI" value="10.17487/RFC6488"/>
        </reference>
        <reference anchor="RFC6811" target="https://www.rfc-editor.org/info/rfc6811" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6811.xml">
          <front>
            <title>BGP Prefix Origin Validation</title>
            <author fullname="P. Mohapatra" initials="P." surname="Mohapatra"/>
            <author fullname="J. Scudder" initials="J." surname="Scudder"/>
            <author fullname="D. Ward" initials="D." surname="Ward"/>
            <author fullname="R. Bush" initials="R." surname="Bush"/>
            <author fullname="R. Austein" initials="R." surname="Austein"/>
            <date month="January" year="2013"/>
            <abstract>
              <t>To help reduce well-known threats against BGP including prefix mis- announcing and monkey-in-the-middle attacks, one of the security requirements is the ability to validate the origination Autonomous System (AS) of BGP routes. More specifically, one needs to validate that the AS number claiming to originate an address prefix (as derived from the AS_PATH attribute of the BGP route) is in fact authorized by the prefix holder to do so. This document describes a simple validation mechanism to partially satisfy this requirement. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6811"/>
          <seriesInfo name="DOI" value="10.17487/RFC6811"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC9286" target="https://www.rfc-editor.org/info/rfc9286" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9286.xml">
          <front>
            <title>Manifests for the Resource Public Key Infrastructure (RPKI)</title>
            <author fullname="R. Austein" initials="R." surname="Austein"/>
            <author fullname="G. Huston" initials="G." surname="Huston"/>
            <author fullname="S. Kent" initials="S." surname="Kent"/>
            <author fullname="M. Lepinski" initials="M." surname="Lepinski"/>
            <date month="June" year="2022"/>
            <abstract>
              <t>This document defines a "manifest" for use in the Resource Public Key Infrastructure (RPKI). A manifest is a signed object (file) that contains a listing of all the signed objects (files) in the repository publication point (directory) associated with an authority responsible for publishing in the repository. For each certificate, Certificate Revocation List (CRL), or other type of signed objects issued by the authority that are published at this repository publication point, the manifest contains both the name of the file containing the object and a hash of the file content. Manifests are intended to enable a relying party (RP) to detect certain forms of attacks against a repository. Specifically, if an RP checks a manifest's contents against the signed objects retrieved from a repository publication point, then the RP can detect replay attacks, and unauthorized in-flight modification or deletion of signed objects. This document obsoletes RFC 6486.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9286"/>
          <seriesInfo name="DOI" value="10.17487/RFC9286"/>
        </reference>
        <reference anchor="RFC9582" target="https://www.rfc-editor.org/info/rfc9582" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9582.xml">
          <front>
            <title>A Profile for Route Origin Authorizations (ROAs)</title>
            <author fullname="J. Snijders" initials="J." surname="Snijders"/>
            <author fullname="B. Maddison" initials="B." surname="Maddison"/>
            <author fullname="M. Lepinski" initials="M." surname="Lepinski"/>
            <author fullname="D. Kong" initials="D." surname="Kong"/>
            <author fullname="S. Kent" initials="S." surname="Kent"/>
            <date month="May" year="2024"/>
            <abstract>
              <t>This document defines a standard profile for Route Origin Authorizations (ROAs). A ROA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate routes to one or more prefixes within the address block. This document obsoletes RFC 6482.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9582"/>
          <seriesInfo name="DOI" value="10.17487/RFC9582"/>
        </reference>
        <reference anchor="I-D.ietf-sidrops-aspa-profile" target="https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-aspa-profile-24" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-sidrops-aspa-profile.xml">
          <front>
            <title>A Profile for Autonomous System Provider Authorization</title>
            <author fullname="Job Snijders" initials="J." surname="Snijders">
              <organization>BSD Software Development</organization>
            </author>
            <author fullname="Alexander Azimov" initials="A." surname="Azimov">
              <organization>Yandex</organization>
            </author>
            <author fullname="Eugene Uskov" initials="E." surname="Uskov">
              <organization>JetLend</organization>
            </author>
            <author fullname="Randy Bush" initials="R." surname="Bush">
              <organization>Internet Initiative Japan</organization>
            </author>
            <author fullname="Russ Housley" initials="R." surname="Housley">
              <organization>Vigil Security, LLC</organization>
            </author>
            <author fullname="Ben Maddison" initials="B." surname="Maddison">
              <organization>Workonline</organization>
            </author>
            <date day="31" month="March" year="2026"/>
            <abstract>
              <t>This document defines a Cryptographic Message Syntax (CMS) protected content type for Autonomous System Provider Authorization (ASPA) objects for use with the Resource Public Key Infrastructure (RPKI). An ASPA is a digitally signed object through which the issuer (the holder of an Autonomous System identifier), can authorize one or more other Autonomous Systems (ASes) as its transit providers. When validated, an ASPA's eContent can be used for detection and mitigation of route leaks.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-sidrops-aspa-profile-24"/>
        </reference>
        <reference anchor="SHS" target="https://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf">
          <front>
            <title>Secure Hash Standard</title>
            <author>
              <organization>National Institute of Standards and Technology</organization>
            </author>
            <date month="March" year="2012"/>
          </front>
        </reference>
        <reference anchor="X.690" target="https://www.itu.int/rec/T-REC-X.690-202102-I/en">
          <front>
            <title>Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title>
            <author>
              <organization showOnFrontPage="true">ITU-T</organization>
            </author>
            <date month="February" year="2021"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="X.690"/>
          <seriesInfo name="ISO/IEC" value="8825-1:2021"/>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="I-D.ietf-sidrops-rpki-erik-protocol" target="https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-erik-protocol-04" xml:base="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-sidrops-rpki-erik-protocol.xml">
          <front>
            <title>The Erik Synchronization Protocol for use with the Resource Public Key Infrastructure (RPKI)</title>
            <author fullname="Job Snijders" initials="J." surname="Snijders">
              <organization>BSD Software Development</organization>
            </author>
            <author fullname="Tim Bruijnzeels" initials="T." surname="Bruijnzeels">
              <organization>RIPE NCC</organization>
            </author>
            <author fullname="Tom Harrison" initials="T." surname="Harrison">
              <organization>APNIC</organization>
            </author>
            <author fullname="Wataru Ohgai" initials="W." surname="Ohgai">
              <organization>JPNIC</organization>
            </author>
            <date day="17" month="March" year="2026"/>
            <abstract>
              <t>This document specifies the Erik Synchronization Protocol for use with the Resource Public Key Infrastructure (RPKI). Erik Synchronization can be characterized as a data replication system using Merkle trees, a content-addressable naming scheme, concurrency control using monotonically increasing sequence numbers, and HTTP transport. Relying Parties can combine information retrieved via Erik Synchronization with other RPKI transport protocols. The protocol's design is intended to be efficient, fast, easy to implement, and robust in the face of partitions or faults in the network.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-sidrops-rpki-erik-protocol-04"/>
        </reference>
        <reference anchor="RFC1952" target="https://www.rfc-editor.org/info/rfc1952" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1952.xml">
          <front>
            <title>GZIP file format specification version 4.3</title>
            <author fullname="P. Deutsch" initials="P." surname="Deutsch"/>
            <date month="May" year="1996"/>
            <abstract>
              <t>This specification defines a lossless compressed data format that is compatible with the widely used GZIP utility. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="1952"/>
          <seriesInfo name="DOI" value="10.17487/RFC1952"/>
        </reference>
        <reference anchor="RFC5781" target="https://www.rfc-editor.org/info/rfc5781" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5781.xml">
          <front>
            <title>The rsync URI Scheme</title>
            <author fullname="S. Weiler" initials="S." surname="Weiler"/>
            <author fullname="D. Ward" initials="D." surname="Ward"/>
            <author fullname="R. Housley" initials="R." surname="Housley"/>
            <date month="February" year="2010"/>
            <abstract>
              <t>This document specifies the rsync Uniform Resource Identifier (URI) scheme. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5781"/>
          <seriesInfo name="DOI" value="10.17487/RFC5781"/>
        </reference>
        <reference anchor="RFC8182" target="https://www.rfc-editor.org/info/rfc8182" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8182.xml">
          <front>
            <title>The RPKI Repository Delta Protocol (RRDP)</title>
            <author fullname="T. Bruijnzeels" initials="T." surname="Bruijnzeels"/>
            <author fullname="O. Muravskiy" initials="O." surname="Muravskiy"/>
            <author fullname="B. Weber" initials="B." surname="Weber"/>
            <author fullname="R. Austein" initials="R." surname="Austein"/>
            <date month="July" year="2017"/>
            <abstract>
              <t>In the Resource Public Key Infrastructure (RPKI), Certificate Authorities (CAs) publish certificates, including end-entity certificates, Certificate Revocation Lists (CRLs), and RPKI signed objects to repositories. Relying Parties retrieve the published information from those repositories. This document specifies a new RPKI Repository Delta Protocol (RRDP) for this purpose. RRDP was specifically designed for scaling. It relies on an Update Notification File which lists the current Snapshot and Delta Files that can be retrieved using HTTPS (HTTP over Transport Layer Security (TLS)), and it enables the use of Content Distribution Networks (CDNs) or other caching infrastructures for the retrieval of these files.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8182"/>
          <seriesInfo name="DOI" value="10.17487/RFC8182"/>
        </reference>
        <reference anchor="RFC8205" target="https://www.rfc-editor.org/info/rfc8205" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8205.xml">
          <front>
            <title>BGPsec Protocol Specification</title>
            <author fullname="M. Lepinski" initials="M." role="editor" surname="Lepinski"/>
            <author fullname="K. Sriram" initials="K." role="editor" surname="Sriram"/>
            <date month="September" year="2017"/>
            <abstract>
              <t>This document describes BGPsec, an extension to the Border Gateway Protocol (BGP) that provides security for the path of Autonomous Systems (ASes) through which a BGP UPDATE message passes. BGPsec is implemented via an optional non-transitive BGP path attribute that carries digital signatures produced by each AS that propagates the UPDATE message. The digital signatures provide confidence that every AS on the path of ASes listed in the UPDATE message has explicitly authorized the advertisement of the route.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8205"/>
          <seriesInfo name="DOI" value="10.17487/RFC8205"/>
        </reference>
        <reference anchor="rpki-client" target="https://www.rpki-client.org/">
          <front>
            <title>rpki-client</title>
            <author fullname="Claudio Jeker"/>
            <author fullname="Kristaps Dzonsons"/>
            <author fullname="Theo Buehler"/>
            <author fullname="Job Snijders"/>
            <date month="December" year="2025"/>
          </front>
        </reference>
        <reference anchor="rpkitouch" target="https://www.github.com/job/rpkitouch">
          <front>
            <title>rpki-client</title>
            <author fullname="Job Snijders"/>
            <date month="December" year="2025"/>
          </front>
        </reference>
        <reference anchor="rpki-commons" target="https://github.com/RIPE-NCC/rpki-commons">
          <front>
            <title>rpki-commons</title>
            <author fullname="RIPE NCC"/>
            <date month="April" year="2026"/>
          </front>
        </reference>
      </references>
    </references>
    <section anchor="acknowledgements">
      <name>Acknowledgements</name>
      <t>
        The authors wish to thank
        <contact fullname="Russ Housley"/>
        and
        <contact fullname="Luuk Hendriks"/>
        for their generous feedback on this specification.
      </t>
    </section>
    <section title="Example CCR">
      <t>
        The below is a Base64-encoded example CCR object.
        For a more elaborate example based on the global RPKI, see the URL in <xref target="implementation"/>.
      </t>
      <sourcecode anchor="tv-base64" type="txt" originalSrc="testvector.b64">MIIP/wYLKoZIhvcNAQkQATaggg/uMIIP6jALBglghkgBZQMEAgEYDzIwMjYwNDExMDgwN
DMxWqGCC9kwggvVMIILnjCB0QQgAAA2wRwPsxllQz3CGSuUSNg95LD7ve8TkQG8oJfZf/
QCAgfOBBRGOHxWszH/hLwQ2KyQ4eLBbxcjRQICGLIYDzIwMjYwNDEwMjMwMTUxWjB+MHw
GCCsGAQUFBzALhnByc3luYzovL3Jwa2kucmlwZS5uZXQvcmVwb3NpdG9yeS9ERUZBVUxU
LzQ4LzFiNDBmZi1iMWUxLTQ5NTEtOTE2NS0yM2JiMzlhODM0ODEvMS9Samg4VnJNeF80U
zhFTmlza09IaXdXOFhJMFUubWZ0MIIBOwQgAAFxGHgJjLarAoLN6aV4ByTazpqHNrQ4xD
jc5eXRQrYCAgk4BBTA1zPgXUwFbjp+lDMtxGvoAUhoigIUAQ0Mn0MoWEPsKztq6RnIjIf
zkgAYDzIwMjYwNDEwMjIwMDAzWjCB1TCB0gYIKwYBBQUHMAuGgcVyc3luYzovL3Jwa2ku
YXJpbi5uZXQvcmVwb3NpdG9yeS9hcmluLXJwa2ktdGEvNWU0YTIzZWEtZTgwYS00MDNlL
WIwOGMtMjE3MWRhMjE1N2QzLzg3MWRhNDBmLTc5M2EtNGE0NS1hMGE5LTk3ODE0ODMyMW
EwNy9hMTIwYjVkNC1kYTU2LTQ5YjEtOGFlMS03OTg3YTZhZmRlOTkvYTEyMGI1ZDQtZGE
1Ni00OWIxLThhZTEtNzk4N2E2YWZkZTk5Lm1mdDCCATsEIAAFujQiTYR4XP+wPQa3rvHa
Z9sVxQu9TikQPbvcSrGUAgIJOAQUrhIoBf2wm/Wx39wUmFrEDwf0PoUCFAENDJ9DKFhLn
OZ6Otp9FmCbky+PGA8yMDI2MDQxMTAzMDAwM1owgdUwgdIGCCsGAQUFBzALhoHFcnN5bm
M6Ly9ycGtpLmFyaW4ubmV0L3JlcG9zaXRvcnkvYXJpbi1ycGtpLXRhLzVlNGEyM2VhLWU
4MGEtNDAzZS1iMDhjLTIxNzFkYTIxNTdkMy84NWUwNmVhZi0zN2E3LTQ1ODgtYWJlYS1l
NDkwOWVmMWI0ZTIvYjJjNThiYTktMzM5My00ZjRjLWFiZTEtYjIzMWEzZWEyNzAwL2IyY
zU4YmE5LTMzOTMtNGY0Yy1hYmUxLWIyMzFhM2VhMjcwMC5tZnQwgdEEIAAGt84u5ZglXr
x63YwuEZbT7Vu8lb+MPP+inyrftREGAgIHzgQUFrGYtu469o3rwjR6Xpj3Efsw8osCAgW
2GA8yMDI2MDQxMTAzMDIxM1owfjB8BggrBgEFBQcwC4ZwcnN5bmM6Ly9ycGtpLnJpcGUu
bmV0L3JlcG9zaXRvcnkvREVGQVVMVC8zYS8yMmFlMTQtZTQ1ZS00ZWVlLWJkMDctNDQ4M
mFkYTIzMmUzLzEvRnJHWXR1NDY5bzNyd2pSNlhwajNFZnN3OG9zLm1mdDCCATsEIAAHY6
f9bYuKrhs+7nHfxGf4NvKaoK3bCDdhaB7CPzv7AgIJiwQUAnJUlPp8gUJ+xZ8HE/O5sGj
ryMICFAENDJ9DKFhCdi5c30h0SNvj1lMGGA8yMDI2MDQxMDIzMDAwM1owgdUwgdIGCCsG
AQUFBzALhoHFcnN5bmM6Ly9ycGtpLmFyaW4ubmV0L3JlcG9zaXRvcnkvYXJpbi1ycGtpL
XRhLzVlNGEyM2VhLWU4MGEtNDAzZS1iMDhjLTIxNzFkYTIxNTdkMy81YjdmYjEyMi1kZm
RmLTRjMGMtYjkwZC0zYmM3YTVmZWI4MmIvZmRjMzM2NWEtMThlYS00Njk2LWFkOGMtNmI
2NmEzZTE1MmI3L2ZkYzMzNjVhLTE4ZWEtNDY5Ni1hZDhjLTZiNjZhM2UxNTJiNy5tZnQw
gdEEIAAIAYHbABeU9ubNQzM6b+nZlZJPxfMnuoFMasNkPlFrAgIHhAQUONY8X84e8J5L8
s/JS7JQn9X/UJwCAgbkGA8yMDI2MDQxMTA2MDExOVowfjB8BggrBgEFBQcwC4ZwcnN5bm
M6Ly9ycGtpLnJpcGUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC9iZi9lZTNkNzMtOTcyOS0
0ZGE0LThiYzctNjdjNDQyZDZhODUwLzEvT05ZOFg4NGU4SjVMOHNfSlM3SlFuOVhfVUp3
Lm1mdDCB0QQgAAgGTG8qcTnrJ+s3v2qwsYhicint7+AAzZvEBKS0/CgCAggYBBRz4Veyk
Yytyopan7xm6Xdgim314QICGLsYDzIwMjYwNDExMDQwMDIwWjB+MHwGCCsGAQUFBzALhn
Byc3luYzovL3Jwa2kucmlwZS5uZXQvcmVwb3NpdG9yeS9ERUZBVUxULzc5L2JiY2Q1My1
jNGY4LTQyNDUtYmI5MC0wMGExNTRiOGVjYjEvMS9jLUZYc3BHTXJjcUtXcC04WnVsM1lJ
cHQ5ZUUubWZ0MIIBOwQgAAxlL+UgVK9Dx4hdFmtC1Io4cnNXa+WSktfxHNDM2dQCAgk4B
BSebvQFHAvG2whHV6ijen1ZKa7QMwIUAQ0Mn0MoWEfYv17xDpMYoOXHJXMYDzIwMjYwND
EwMTgwMDAzWjCB1TCB0gYIKwYBBQUHMAuGgcVyc3luYzovL3Jwa2kuYXJpbi5uZXQvcmV
wb3NpdG9yeS9hcmluLXJwa2ktdGEvNWU0YTIzZWEtZTgwYS00MDNlLWIwOGMtMjE3MWRh
MjE1N2QzLzY5ZmQwMTU2LWJiMWYtNDhiNi1iZjMyLWM5NDkyMjg2ZjE5NS9hZmIzNTExY
i1mMWI2LTQ0YWQtOWMzNi1mNjU3NmE1NDAwZGYvYWZiMzUxMWItZjFiNi00NGFkLTljMz
YtZjY1NzZhNTQwMGRmLm1mdDCB0QQgABHMuie2PQZfMvLKOxKMHfjD1eaPqk9g7ApjxVq
RekoCAgfOBBTad/oQDWzSiOVEx8tMfU0Yh5B57QICA0QYDzIwMjYwNDExMDAwMTAwWjB+
MHwGCCsGAQUFBzALhnByc3luYzovL3Jwa2kucmlwZS5uZXQvcmVwb3NpdG9yeS9ERUZBV
UxUL2RjL2UzMWFkNS1lZjc0LTQwYTQtOWEwZC1kZjg3MmZiMjY5Y2YvMS8ybmY2RUExcz
BvamxSTWZMVEgxTkdJZVFlZTAubWZ0MIIBOwQgABRkjCfKzkq+VljmLDPOTrRzb9XCSHS
4+MdJ85h48CkCAgk4BBROQoyVjC53vymSTEMHykx6r8ysjwIUAQ0Mn0MoWEV8jtR6N+Vu
HCt5JiEYDzIwMjYwNDExMDgwMDAzWjCB1TCB0gYIKwYBBQUHMAuGgcVyc3luYzovL3Jwa
2kuYXJpbi5uZXQvcmVwb3NpdG9yeS9hcmluLXJwa2ktdGEvNWU0YTIzZWEtZTgwYS00MD
NlLWIwOGMtMjE3MWRhMjE1N2QzLzRhYjdhZTRkLWJkN2ItNGIzMy05YTg4LTViMjJkMmE
4MzM3ZC8wMjJkMDI2OS03ZDU2LTQ1Y2MtODE2Ny1iMWU3YWIxM2YxZjQvMDIyZDAyNjkt
N2Q1Ni00NWNjLTgxNjctYjFlN2FiMTNmMWY0Lm1mdDCCATsEIAAZpDK5Kgx6uUVKrKMks
brMn/uM9zx0ScgmSrNPAeccAgII6AQU1rp+M1W1y/Z0A5I2TKkhN5JBwCcCFAENDJ9DKF
hBD/Z3xJ0CPoX7w2cfGA8yMDI2MDQxMDE1MDAwM1owgdUwgdIGCCsGAQUFBzALhoHFcnN
5bmM6Ly9ycGtpLmFyaW4ubmV0L3JlcG9zaXRvcnkvYXJpbi1ycGtpLXRhLzVlNGEyM2Vh
LWU4MGEtNDAzZS1iMDhjLTIxNzFkYTIxNTdkMy8yYTI0Njk0Ny0yZDYyLTRhNmMtYmEwN
S04NzE4N2YwMDk5YjIvMGE5NGI0NjAtNzQ0MS00OTVlLTkzNTgtNDc1ZWE3OTVlY2M2Lz
BhOTRiNDYwLTc0NDEtNDk1ZS05MzU4LTQ3NWVhNzk1ZWNjNi5tZnQYDzIwMjYwNDExMDg
wMDAzWgQg8bXskzbWa1oCoQYF1VnbQskxegvOO2eyS67YnkY29wiiggHeMIIB2jCCAbQw
ZAIBBzBfMEgEAgABMEIwCQMEAMAjXgIBIDAJAwQAwEMrAgEgMAkDBADCIEUCASAwCQMEA
cIg2gIBIDAJAwQAwiKKAgEgMAkDBAHCPVwCASAwEwQCAAIwDTALAwUDKgs7QAICAIAwgZ
sCAiBbMIGUMHYEAgABMHAwBgMEAFvQIjAGAwQDXo7wMAYDBABejvAwBgMEAF6O8TAGAwQ
AXo7yMAYDBABejvQwBgMEAF6O9TAGAwQAXo72MAYDBABejvcwBgMEArk04DAGAwQAuTTg
MAYDBAC5NOEwBgMEALk04jAGAwQAuTTjMBoEAgACMBQwCQMHACABBngGiDAHAwUAKgIIm
DCBrQICPMowgaYwVwQCAAEwUTAGAwQAQ931MAYDBACl/uEwCQMEAKX+/wIBIDAGAwQAwJ
OoMAkDBAHGOgICARgwCQMEAcwCHgIBGDAGAwQA0RgBMAYDBADRGAUwBgMEANEYCTBLBAI
AAjBFMAwDBwEgAQQYFE4CAUAwCQMHACABBnwgjDAJAwcAIAEHKBgIMAkDBwAmB/rgAkUw
CQMHACoOskAAADAJAwcAKg6yQAEYBCDVgBpTRcCqvEdOUPi7RvmGw9gjloOw3NcNAwoUR
IMRAqOBmTCBljByMA0CAVAwCAICDRwCAhk9MAkCAgCuMAMCAQAwDgICAQswCAICL2ECAj
cXMB4CAgIpMBgCAgCuAgICLwICAqgCAgUTAgILYgICDPgwJgICAi8wIAICAK4CAgIBAgI
CKQICBRMCAgy5AgINHAICUeUCAlNIBCDITE9K2lIl7SnJRAygGi8R4SNruWCIgolWRu/4
xhoJjaRSMFAwLAQUE9TyT5qfzZjbNvkwYxgIyI85dLwEFOhVKx/W0aT35ATG2OVoDR68F
j/DBCCh5sjSpR+H93+2tYuqk5GZkBARAKhhAP7h+HKGR+agDKWCARkwggEVMIHwMIHtAg
I8yjCB5jBxBBRdQlDi2B1ESNiinvzpHSn/B17J4jBZMBMGByqGSM49AgEGCCqGSM49AwE
HA0IABIBXI0P4P/ywEHqwB9jKafhrnKAwBgW4SKg998DT7F8ZwBm/prWe10K1TvQ0OlJQ
EobYoOfkHxCqU7RYIqn4gBUwcQQUvoibVdC3Nzl9dcSfSFuFj6mK0R8wWTATBgcqhkjOP
QIBBggqhkjOPQMBBwNCAATgXEmvSfZu7HW5fUS+X5BbBli8hp0+Mu4VfabGoq4AZSEqev
tUssOCsT76X2nl4faRZM1UA3bYVRTd1v9EqkTbBCC6X7RJzvtroA82Enliou6m6Gf+hRK
73a3pxuS4vBbB0g==
</sourcecode>
      <t>
        It decodes as follows:
      </t>
      <sourcecode anchor="tv-decode" type="txt" originalSrc="testvector.decode.fold">=============== NOTE: '\' line wrapping per RFC 8792 ================

File:                   example.ccr
Hash identifier:        u8u0JbdDaij8cplt6kTaIyQFSzvgexIKuEsLhBzGhQI=
CCR produced at:        Sat 11 Apr 2026 08:04:31 +0000
Manifest state hash:    8bXskzbWa1oCoQYF1VnbQskxegvOO2eyS67YnkY29wg=
Manifest last update:   Sat 11 Apr 2026 08:00:03 +0000
Manifest instances:
                        hash:AAA2wRwPsxllQz3CGSuUSNg95LD7ve8TkQG8oJf\
Zf/Q= size:1998 aki:46387C56B331FF84BC10D8AC90E1E2C16F172345 seqnum:\
18B2 thisupdate:1775862111 sia:rsync://rpki.ripe.net/repository/DEFA\
ULT/48/1b40ff-b1e1-4951-9165-23bb39a83481/1/Rjh8VrMx_4S8ENiskOHiwW8X\
I0U.mft
                        hash:AAFxGHgJjLarAoLN6aV4ByTazpqHNrQ4xDjc5eX\
RQrY= size:2360 aki:C0D733E05D4C056E3A7E94332DC46BE80148688A seqnum:\
010D0C9F43285843EC2B3B6AE919C88C87F39200 thisupdate:1775858403 sia:r\
sync://rpki.arin.net/repository/arin-rpki-ta/5e4a23ea-e80a-403e-b08c\
-2171da2157d3/871da40f-793a-4a45-a0a9-978148321a07/a120b5d4-da56-49b\
1-8ae1-7987a6afde99/a120b5d4-da56-49b1-8ae1-7987a6afde99.mft
                        hash:AAW6NCJNhHhc/7A9Breu8dpn2xXFC71OKRA9u9x\
KsZQ= size:2360 aki:AE122805FDB09BF5B1DFDC14985AC40F07F43E85 seqnum:\
010D0C9F4328584B9CE67A3ADA7D16609B932F8F thisupdate:1775876403 sia:r\
sync://rpki.arin.net/repository/arin-rpki-ta/5e4a23ea-e80a-403e-b08c\
-2171da2157d3/85e06eaf-37a7-4588-abea-e4909ef1b4e2/b2c58ba9-3393-4f4\
c-abe1-b231a3ea2700/b2c58ba9-3393-4f4c-abe1-b231a3ea2700.mft
                        hash:AAa3zi7lmCVevHrdjC4RltPtW7yVv4w8/6KfKt+\
1EQY= size:1998 aki:16B198B6EE3AF68DEBC2347A5E98F711FB30F28B seqnum:\
05B6 thisupdate:1775876533 sia:rsync://rpki.ripe.net/repository/DEFA\
ULT/3a/22ae14-e45e-4eee-bd07-4482ada232e3/1/FrGYtu469o3rwjR6Xpj3Efsw\
8os.mft
                        hash:AAdjp/1ti4quGz7ucd/EZ/g28pqgrdsIN2FoHsI\
/O/s= size:2443 aki:02725494FA7C81427EC59F0713F3B9B068EBC8C2 seqnum:\
010D0C9F43285842762E5CDF487448DBE3D65306 thisupdate:1775862003 sia:r\
sync://rpki.arin.net/repository/arin-rpki-ta/5e4a23ea-e80a-403e-b08c\
-2171da2157d3/5b7fb122-dfdf-4c0c-b90d-3bc7a5feb82b/fdc3365a-18ea-469\
6-ad8c-6b66a3e152b7/fdc3365a-18ea-4696-ad8c-6b66a3e152b7.mft
                        hash:AAgBgdsAF5T25s1DMzpv6dmVkk/F8ye6gUxqw2Q\
+UWs= size:1924 aki:38D63C5FCE1EF09E4BF2CFC94BB2509FD5FF509C seqnum:\
06E4 thisupdate:1775887279 sia:rsync://rpki.ripe.net/repository/DEFA\
ULT/bf/ee3d73-9729-4da4-8bc7-67c442d6a850/1/ONY8X84e8J5L8s_JS7JQn9X_\
UJw.mft
                        hash:AAgGTG8qcTnrJ+s3v2qwsYhicint7+AAzZvEBKS\
0/Cg= size:2072 aki:73E157B2918CADCA8A5A9FBC66E977608A6DF5E1 seqnum:\
18BB thisupdate:1775880020 sia:rsync://rpki.ripe.net/repository/DEFA\
ULT/79/bbcd53-c4f8-4245-bb90-00a154b8ecb1/1/c-FXspGMrcqKWp-8Zul3YIpt\
9eE.mft
                        hash:AAxlL+UgVK9Dx4hdFmtC1Io4cnNXa+WSktfxHND\
M2dQ= size:2360 aki:9E6EF4051C0BC6DB084757A8A37A7D5929AED033 seqnum:\
010D0C9F43285847D8BF5EF10E9318A0E5C72573 thisupdate:1775844003 sia:r\
sync://rpki.arin.net/repository/arin-rpki-ta/5e4a23ea-e80a-403e-b08c\
-2171da2157d3/69fd0156-bb1f-48b6-bf32-c9492286f195/afb3511b-f1b6-44a\
d-9c36-f6576a5400df/afb3511b-f1b6-44ad-9c36-f6576a5400df.mft
                        hash:ABHMuie2PQZfMvLKOxKMHfjD1eaPqk9g7ApjxVq\
Reko= size:1998 aki:DA77FA100D6CD288E544C7CB4C7D4D18879079ED seqnum:\
0344 thisupdate:1775865660 sia:rsync://rpki.ripe.net/repository/DEFA\
ULT/dc/e31ad5-ef74-40a4-9a0d-df872fb269cf/1/2nf6EA1s0ojlRMfLTH1NGIeQ\
ee0.mft
                        hash:ABRkjCfKzkq+VljmLDPOTrRzb9XCSHS4+MdJ85h\
48Ck= size:2360 aki:4E428C958C2E77BF29924C4307CA4C7AAFCCAC8F seqnum:\
010D0C9F432858457C8ED47A37E56E1C2B792621 thisupdate:1775894403 sia:r\
sync://rpki.arin.net/repository/arin-rpki-ta/5e4a23ea-e80a-403e-b08c\
-2171da2157d3/4ab7ae4d-bd7b-4b33-9a88-5b22d2a8337d/022d0269-7d56-45c\
c-8167-b1e7ab13f1f4/022d0269-7d56-45cc-8167-b1e7ab13f1f4.mft
                        hash:ABmkMrkqDHq5RUqsoySxusyf+4z3PHRJyCZKs08\
B5xw= size:2280 aki:D6BA7E3355B5CBF6740392364CA921379241C027 seqnum:\
010D0C9F432858410FF677C49D023E85FBC3671F thisupdate:1775833203 sia:r\
sync://rpki.arin.net/repository/arin-rpki-ta/5e4a23ea-e80a-403e-b08c\
-2171da2157d3/2a246947-2d62-4a6c-ba05-87187f0099b2/0a94b460-7441-495\
e-9358-475ea795ecc6/0a94b460-7441-495e-9358-475ea795ecc6.mft
ROA payload state hash: 1YAaU0XAqrxHTlD4u0b5hsPYI5aDsNzXDQMKFESDEQI=
ROA payload entries:
                        192.35.94.0/24-32 AS 7
                        192.67.43.0/24-32 AS 7
                        194.32.69.0/24-32 AS 7
                        194.32.218.0/23-32 AS 7
                        194.34.138.0/24-32 AS 7
                        194.61.92.0/23-32 AS 7
                        2a0b:3b40::/29-128 AS 7
                        91.208.34.0/24 AS 8283
                        94.142.240.0/21 AS 8283
                        94.142.240.0/24 AS 8283
                        94.142.241.0/24 AS 8283
                        94.142.242.0/24 AS 8283
                        94.142.244.0/24 AS 8283
                        94.142.245.0/24 AS 8283
                        94.142.246.0/24 AS 8283
                        94.142.247.0/24 AS 8283
                        185.52.224.0/22 AS 8283
                        185.52.224.0/24 AS 8283
                        185.52.225.0/24 AS 8283
                        185.52.226.0/24 AS 8283
                        185.52.227.0/24 AS 8283
                        2001:678:688::/48 AS 8283
                        2a02:898::/32 AS 8283
                        67.221.245.0/24 AS 15562
                        165.254.225.0/24 AS 15562
                        165.254.255.0/24-32 AS 15562
                        192.147.168.0/24 AS 15562
                        198.58.2.0/23-24 AS 15562
                        204.2.30.0/23-24 AS 15562
                        209.24.1.0/24 AS 15562
                        209.24.5.0/24 AS 15562
                        209.24.9.0/24 AS 15562
                        2001:418:144e::/47-64 AS 15562
                        2001:67c:208c::/48 AS 15562
                        2001:728:1808::/48 AS 15562
                        2607:fae0:245::/48 AS 15562
                        2a0e:b240::/48 AS 15562
                        2a0e:b240:118::/48 AS 15562
ASPA payload state hash:yExPStpSJe0pyUQMoBovEeEja7lgiIKJVkbv+MYaCY0=
ASPA payload entries:
                        customer: 80 providers: 3356, 6461
                        customer: 174 providers: 0
                        customer: 267 providers: 12129, 14103
                        customer: 553 providers: 174, 559, 680, 1299\
, 2914, 3320
                        customer: 559 providers: 174, 513, 553, 1299\
, 3257, 3356, 20965, 21320
Trust anchor state hash:oebI0qUfh/d/trWLqpORmZAQEQCoYQD+4fhyhkfmoAw=
Trust anchor keyids:    13D4F24F9A9FCD98DB36F930631808C88F3974BC, E8\
552B1FD6D1A4F7E404C6D8E5680D1EBC163FC3
Router key state hash:  ul+0Sc77a6APNhJ5YqLupuhn/oUSu92t6cbkuLwWwdI=
Router keys:
                        asid:15562 ski:5D4250E2D81D4448D8A29EFCE91D2\
9FF075EC9E2 pubkey:MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEgFcjQ/g//LAQe\
rAH2Mpp+GucoDAGBbhIqD33wNPsXxnAGb+mtZ7XQrVO9DQ6UlAShtig5+QfEKpTtFgiq\
fiAFQ==
                        asid:15562 ski:BE889B55D0B737397D75C49F485B8\
58FA98AD11F pubkey:MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE4FxJr0n2bux1u\
X1Evl+QWwZYvIadPjLuFX2mxqKuAGUhKnr7VLLDgrE++l9p5eH2kWTNVAN22FUU3db/R\
KpE2w==
Validation:             N/A
</sourcecode>
    </section>
    <section removeInRFC="true" anchor="implementation">
      <name>Implementation status</name>
      <t>
        This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in RFC 7942.
        The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs.
        Please note that the listing of any individual implementation here does not imply endorsement by the IETF.
        Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors.
        This is not intended as, and must not be construed to be, a catalog of available implementations or their features.
        Readers are advised to note that other implementations may exist.
      </t>
      <t>
        According to RFC 7942, "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature.
        It is up to the individual working groups to use this information as they see fit".
      </t>
      <ul>
        <li>
          Example .ccr files were created by Job Snijders.
          A current example CCR (regenerated every few minutes) is available here:
<![CDATA[
https://console.rpki-client.org/rpki.ccr
]]>
        </li>
        <li>
          A CCR serializer and deserializer implementation based on <xref target="rpki-client"/> was provided by Job Snijders and Theo Buehler.
        </li>
        <li>
          Another CCR serializer and deserializer implementation based on <xref target="rpkitouch"/> was provided by Job Snijders.
        </li>
        <li>
          A CCR encoding and decoding implementation in Java library <xref target="rpki-commons"/> was provided by RIPE NCC.
        </li>
      </ul>
    </section>
  </back>
</rfc>
