The Erik Synchronization Protocol for use with the Resource Public Key Infrastructure (RPKI)

The Erik Synchronization Protocol for use with the Resource Public Key Infrastructure (RPKI) BSD Software Development

Amsterdam The Netherlands job@bsd.nl https://www.bsd.nl/

RIPE NCC

The Netherlands tim@ripe.net

APNIC

AU tomh@apnic.net

JPNIC

JP alt@nic.ad.jp

Operations and Management Area (OPS) SIDROPS Data synchronization 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.

Introduction 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 ( and ). 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.

Background The notion of cache-to-cache data replication of unvalidated data was documented in .

Validated caches may also be created and maintained from other validated caches. Network operators SHOULD take maximum advantage of this feature to minimize load on the global distributed RPKI database. Of course, the recipient relying parties should re-validate the data.

Historic records show that experiments have been performed in this space using, for example, peer-to-peer file sharing technology (see ), but no standardised and widely-deployed mechanism for cache-to-cache replication emerged since then. The authors hope that the Erik Synchronization protocol might be suitable to fill this gap and improve propagation speed of validly signed repository data as well as help reduce load on the global RPKI.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Related Work The reader is assumed to be familiar with the terms and concepts described in "" , "" , "" , "" , "" .

Glossary This section describes the terminology and abbreviations used in this document. Though the definitions might not be clear on a first read, later on the terms will be introduce with more detail.

Erik relay: An intermediate between CA publication repositories and Relying Parties.
FQDN: The fully qualified domain name of a RPKI repository instance referenced in an end-entity certificate's Subject Information Access (SIA) extension's id-ad-signedObject accessDescription.
Hash: A message digest calculated for an object using the SHA-256 algorithm.
ErikIndex: The relay's Merkle root for a given FQDN. An ErikIndex is an ordered listing of ErikPartition object hashes.
ErikPartition: An ordered listing of the manifest objects' hashes, manifestNumber values, thisUpdate values, and their certificates' SIA extension values.

Informal Overview Erik Synchronisation is an architecture to reliably distribute RPKI repository data from cache to cache using so-called Erik relays. Relays maintain a validated cache themselves and can be clients of other relays. While this property suggests that a group of relays should converge to the exact same state, the distributed nature of the RPKI prevents relays from achieving strict synchronization. In this synchronization protocol, Merkle trees are used to determine whether differences exist between client and relay. Merkle trees are hierarchical data structures: the hash value of each node is computed recursively by hashing the concatenated hash values of the node's children. The hash of the ErikIndex represents the entire dataset related to a given FQDN. If the ErikIndex hash is not the same between two replicas, the relay provides the client with hashes of smaller and smaller portions of the to-be-replicated dataset until the exact list of out-of-sync or missing objects is identified. Sequence numbers are then used to determine whether these differences are relevant enough for the client to fetch. All data, except for ErikIndex objects, is fetched using static addresses derived from object hashes. This approach reduces unnecessary data transfer between caches which contain mostly similar data. The client starts by making an inventory of its local state and then querying an Erik relay for the relay's current ErikIndex for a given FQDN. If the ErikIndex is different compared to the previous run (or compared to the ErikIndex derived from locally cached objects). After having acquired the current ErikIndex, clients can determine which ErikPartitions need to be fetched. The client then can compare the manifestNumber sequence number and thisUpdate for each manifest listed in the ErikPartition, and proceed to fetch (purportedly) newer versions of manifests of interest. Whenever a relay has manifests with a lower sequence number on offer, the client can ignore those. The client now has sufficient information to proceed to fetch any missing Certificates, Signed objects, and CRLs. With the information contained within manifests, clients can fetch addressed by content (by hash) and store by name (or some other scheme).

Erik Synchronization Data Structure Definitions The messages used in this protocol to construct and determine synchronization states are encoded following Distinguished Encoding Rules (DER) . ErikIndex and ErikPartition objects are formally defined as follows. RpkiErikSynchronization-2025 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) mod(0) id-mod-rpkiErikSynchronization-2025(TBD) } DEFINITIONS EXPLICIT TAGS ::= BEGIN -- EXPORTS ALL -- IMPORTS CONTENT-TYPE, Digest, DigestAlgorithmIdentifier 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) } AccessDescription, KeyIdentifier FROM PKIX1Implicit-2009 -- in [RFC5912] { 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.&id({ContentSet}), content [0] EXPLICIT CONTENT-TYPE.&Type({ContentSet}{@contentType}) } ContentSet CONTENT-TYPE ::= { ct-rpkiErikIndex | ct-rpkiErikPartition, ... } ct-rpkiErikIndex CONTENT-TYPE ::= { TYPE ErikIndex IDENTIFIED BY id-ct-rpkiErikIndex } id-ct-rpkiErikIndex OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) id-smime(16) id-ct(1) erikindex(55) } ct-rpkiErikPartition CONTENT-TYPE ::= { TYPE ErikPartition IDENTIFIED BY id-ct-rpkiErikPartition } id-ct-rpkiErikPartition OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) id-smime(16) id-ct(1) erikpartition(56) } ErikIndex ::= SEQUENCE { version [0] INTEGER DEFAULT 0, indexScope IA5String, indexTime GeneralizedTime, hashAlg DigestAlgorithmIdentifier, partitionList SEQUENCE (SIZE(1..ub-Partitions)) OF PartitionRef } ub-Partitions INTEGER ::= 256 PartitionRef ::= SEQUENCE { hash Digest, size INTEGER (100..MAX) } ErikPartition ::= SEQUENCE { version [0] INTEGER DEFAULT 0, partitionTime GeneralizedTime, hashAlg DigestAlgorithmIdentifier, manifestList SEQUENCE (SIZE(1..MAX)) OF ManifestRef } ManifestRef ::= SEQUENCE { hash Digest, size INTEGER (1000..MAX), aki KeyIdentifier, manifestNumber INTEGER (0..MAX), thisUpdate GeneralizedTime, locations SEQUENCE (SIZE(1..MAX)) OF AccessDescription } END

General Syntax At the top level the content of an Erik object is an instance of ContentInfo.

contentType The contentType is an OID specifying the type of payload in the object, in this profile either id-ct-rpkiErikIndex or id-ct-rpkiErikPartition.

content The content field contains an instance of ErikIndex or ErikPartition.

ErikIndex An ErikIndex represents all current manifest objects available under a given FQDN and thus the complete state of the repository as it is known to the relay.

The version number of the ErikIndex object MUST be 0.

The indexScope field contains the fully qualified domain name of the Signed Object location of the manifests referenced through this particular ErikIndex. The FQDN MUST be in the "preferred name syntax", as specified by and modified by .

The indexTime is the most recent partitionTime value among the ErikPartitions referenced from the ErikIndex at hand. Use of the most recent partitionTime value (rather than the local system's notion of "now") provides idempotency for distributed system implementations. The field's value is a rough indication when the ErikIndex was generated and can be used for troubleshooting and measurement purposes. For the purposes of this profile, GeneralizedTime values MUST be expressed UTC (Zulu) and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ), even where the number of seconds is zero. GeneralizedTime values MUST NOT include fractional seconds. See .

This field contains the OID of the hash algorithm used to hash the ErikPartitions. The hash algorithm used MUST conform to the RPKI Algorithms and Key Size Profile specification .

This field is a sequence of PartitionRef instances. There is one PartitionRef for each current ErikPartition. Each PartitionRef is a tuple consisting of the hash of the partition object and the size of the partition object. Information elements are unique with respect to one another and sorted in ascending order of the hash.

ErikPartition An ErikPartition represents the set of manifest objects under a given FQDN which have the same first octet of the Authority Key Identifier (AKI) in common with each other. Each ErikPartition is an ordered listing of ManifestRef instances which contain the manifest objects' hashes, object sizes, AKI, manifestNumber values, thisUpdate values, and their respective end-entity certificates' SIA extension values. Using the first octet of the AKI as the partition key facilitates even and deterministic distribution of ManifestRefs across ErikPartitions.

The version number of the ErikPartition object MUST be 0.

The partitionTime is the most recent thisUpdate value among the manifests referenced from the ErikPartition at hand. Use of the most recent manifest thisUpdate value (rather than the local system's notion of "now") provides idempotency for distributed system implementations. The field's value is a rough indication when the ErikPartition was generated and can be used for troubleshooting and measurement purposes. For the purposes of this profile, GeneralizedTime values MUST be expressed UTC (Zulu) and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ), even where the number of seconds is zero. GeneralizedTime values MUST NOT include fractional seconds. See .

This field contains the OID of the hash algorithm used to hash the manifest objects referenced in this ErikPartition. The hash algorithm used MUST conform to the RPKI Algorithms and Key Size Profile specification .

This field is a sequence of ManifestRef instances. There is one ManifestRef 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 ). A ManifestRef is a structure consisting of the hash of the manifest object, the size of the manifest object, the manifest issuer's key identifier, the manifestNumber, and the thisUpdate contained within the object, and a sequence of AccessDescription instances from the manifest's End-Entity certificate's Subject Information Access extension. Information elements are unique with respect to one another and sorted in ascending order of the hash.

Client-side Processing Clients start by acquiring and processing an ErikIndex, which represents the relay's current Merkle tree head for a given FQDN. A client MUST verify the requested FQDN exactly matches the indexScope value in the ErikIndex, and if not proceed to use a different relay. Then, clients can decide whether or not to fetch ErikPartition objects listed on the ErikIndex, for instance, by checking whether the object associated with the hash was already fetched at some point in the client's past. Before using a ErikPartition, the client MUST verify that all URIs in the accessLocations in the id-ad-signedObject accessMethod instances in the ErikPartition are encompassed in the requested indexScope. A client can then decide whether or not to fetch a given manifest object, by comparing the manifestNumber and thisUpdate with what's locally cached and what's offered by the remote relay. A client can compute which products listed in the manifest's fileList need to be fetched from one relay or another in order to achieve a successful fetch. A client MUST verify that the URI in the accessLocation in one of the id-ad-signedObject accessMethod instances in the manifest's Subject Information Access (SIA) is encompassed in the requested indexScope. As there is no concept of 'sessions' (like in RRDP), clients can interchangeably use different Erik relays. When one Erik relay generates a HTTP error, the client can try fetching the requested object from another Erik relay. To improve reliability, clients should alternate among different relays in successive query and fetch attempts. Clients SHOULD use HTTPS, unless the local system is unable to establish TLS connections to any of its configured Erik relays.

Querying an Erik Relay

This specification uses "Named Information" identifiers mapped to .well-known HTTP/HTTPS URLs for object retrieval, as described in . For example, issuance #54 of ripe-ncc-ta.mft has the following SHA256 digest: c2d0427bc5a32c42eea1ab5663d592b1fc29c7d4ef16ab0b5e1d631d039dcc21. To fetch the aforementioned object from an relay hosted at relay.example.net, a client would access the following HTTP URL: https://relay.example.net/.well-known/ni/sha-256/wtBCe8WjLELuoatWY9WSsfwpx9TvFqsLXh1jHQOdzCE Responses to requests for paths starting with /.well-known/ni/ are immutable.

The URIs to fetch ErikIndex objects can be constructed using the following Well-Known URI template with the relay's hostname as authority, the erik keyword as suffix, the string /index/, followed by a FQDN as parameter, i.e.: https://{relay_hostname}/.well-known/erik/index/{FQDN}. As an example, the URI to fetch an ErikIndex for the rpki.ripe.net FQDN from a relay at relay.example.net would be: https://relay.example.net/.well-known/erik/index/rpki.ripe.net. A client MAY use the If-Modified-Since HTTP header when fetching ErikIndex objects. Responses to requests for paths starting with /.well-known/erik/index/ are mutable.

Prefetching Objects in Bulk Object prefetching is a bulk distribution mechanism for data that clients might need in the near future. Prefetching is useful for efficiently bootstrapping empty caches and for clients to catch up on recently discovered objects with a single bulk request. This section outlines the general structure of prefetch request responses and defines various .well-known/erik/ endpoints.

General Structure of Prefetch Responses In this protocol, a Prefetch Response (PR) is simply a concatenated sequence of zero or more DER-encoded objects in gzip compressed form. Because DER-encoded objects are self-delimiting, no marker is used between the objects and there is no end-of-sequence indicator. A Prefetch Response is non-deterministic: objects contained within the PR may appear in arbitrary order or in duplicate. A PR may contain RPKI signed objects, ErikIndex objects, and ErikPartition objects. The set of objects in a PR need not be self-consistent or complete from the perspective of top-down validation. PRs merely serve to reduce network traffic by prefill unvalidated cache areas. Different prefetching strategies have different trade-offs in terms of coverage and accuracy. On the one hand aggressive prefetching might waste bandwidth (i.e. clients download data they might not end up using, or data they had already cached), on the other hand, sending many individual requests for each and every object increases network overhead and latency. As a rule of thumb: FQDN Snapshots are useful for clients with no prior state and Time-trimmed Tail Queues are useful in the steady state (when synchronizing every few minutes). For efficiency, relay implementations are RECOMMENDED to combine as many DER-encoded objects into as few gzip members as possible (see for information on gzip members).

Prefetching FQDN Snapshots A snapshot contains all RPKI & Erik objects a relay associated with a given FQDN as of the time of the snapshot's production. Snapshots are not necessarily produced in lockstep with updates to the relay's merkle trees, therefore clients MUST perform a tree comparison after fetching a snapshot. As an example, the URI to fetch a snapshot for the rpki.ripe.net FQDN from a relay at relay.example.net would be: https://relay.example.net/.well-known/erik/snapshot/rpki.ripe.net. Responses to requests for paths starting with /.well-known/erik/snapshot/ are mutable. Relays MUST NOT include ErikIndex and ErikPartition objects in snapshots. See for an example how to construct a FQDN snapshot.

Prefetching Time-trimmed Tail Queues A relay's time-trimmed tail queues are buffers that contains all RPKI & ErikPartition objects that relay discovered in the last 5 and 10 minutes, respectively. Such buffers are not necessarily produced in lockstep with updates to the relay's merkle trees, therefore clients MUST perform a tree comparison after fetching a tail queue buffer. As an example, the URI to fetch the 5 minute tail from a relay at relay.example.net would be: https://relay.example.net/.well-known/erik/tail/5min. Responses to requests for paths starting with /.well-known/erik/tail/ are mutable. Relays MUST NOT include ErikIndex objects in time-trimmed tail queue buffers. See for an example how to pre-calculate Prefetch Responses using a time-trimmed tail queue concept.

Transport Error Detection and Handling The client MUST calculate the hashes of fetched objects and verify they are the same as the expected hashes (which are embedded in the URIs through which the objects were retrieved). If there is a hash mismatch, the client may try fetching the object from a different Erik relay or treat this as a failed fetch (see ) and try again at a later point in time in a next validation run.

Setting Up an Erik Relay Erik relays can be operated by any party, without permission from or coordination with publication point operators or CAs. Relays are made accessible via either HTTP or HTTPS or both. Relays generate and make accessible ErikIndexes and ErikPartitions derived from their current validation state, the client then cherry-picks which objects (if any) it wishes to fetch. In turn, relays fetch fresh data from other relays, or from CA-designated publication points accessible via Rsync () and RRDP ().

Comparison with other RPKI transport protocols Ignoring obvious mechanical "on the wire" differences between Erik, Rsync, and RRDP; there are a number of concept differences between the protocols. Rsync and RRDP can be described as "general purpose" synchronisation protocols: they could be used to transfer any arbitrary set of files, on the other hand the Erik protocol is RPKI-specific: part of its signaling layer are RPKI manifest objects, which RPs require as recourse for validation anyway. This property by itself causes a small deduplication in the data to be transferred.

Comparison with Rsync In Rsync, the server and the client construct and transfer a full listing of all available objects, and then transfer objects as necessary. In effect, this allows clients to 'jump' to the latest repository state, regardless of the state of the local cache. A major downside of Rsync is that the list of files itself can become a burden to transfer. As of June 2025, in order to merely establish whether a client is synchronized or not with the RIPE NCC repository at rpki.ripe.net, as much as 5.8 megabytes of data are exchanged without exchanging any RPKI data. Experimentation suggests that when synchronizing once an hour, Erik consumes less network traffic than Rsync generally would consume which, in turn, is less network traffic than RRDP would.

Comparison with RRDP The key concept in RRDP is that the client downloads a "journal", containing all add/update/delete operations and replays this journal to arrive at the current repository state. A major downside of RRDP is that (depending on the RRDP polling interval) clients end up downloading data which has become outdated. Imagine a hypothetical CA which issues and revokes a ROA every 10 minutes and a client that synchronizes every 60 minutes; in effect the client must fetch 5 outdated states, wasting bandwidth. Experimentation suggests that when synchronizing every 15 minutes, Erik consumes less network traffic than RRDP generally would consume which, in turn, is less network traffic than Rsync would consume.

Garbage Collection In contrast to RRDP, the Erik protocol has no concept of server-specific "stateful" sessions that persist across polling attempts. This obviates the need for withdraw instructions as part of the protocol exchange: clients can simply delete objects that are no longer referenced from their current validation state and refetch them later on if needed.

Operational Considerations

Scaling considerations As of July 2025, the global Internet's RPKI churn rate appears to be 2 new objects per second. The ecosystem is estimated to be composed of ~ 5000 RPKI cache instances and ~ 50 repository servers. Assuming 10 minute fetching intervals and 150 metadata requests per synchronization run (for exchange of Merkle tree data), an Erik relay serving all the Internet's RPKI cache instances would probably need to be able to sustain serving an average of at least 11,000 HTTP requests per second. This order of magnitude in terms of scaling requirements can easily be handled by a single commodity server.

HTTP Compression Using gzip compression on average tends to yield a 20% reduction in RPKI object size when fetching individual objects, therefore it is RECOMMENDED for clients and relays to offer support for compressed content coding, as described in . Prefetch responses () are always in gzip compressed form. Using a previous version of a RPKI object as a compression dictionary for a newer version enables delivery of a delta-compressed version of the changes, usually resulting in significantly smaller responses than what can be achieved by compression alone. Clients can facilitate delta compression by sending an Available-Dictionary request header, using a previously fetched version of the RPKI object as the dictionary. It is RECOMMENDED for clients and relays to make use of Compression Dictionary Transport ().

Security Considerations This document makes no changes to RPKI certificate validation procedures. Paraphrasing : The RPKI relies on object, not server or transport, trust. That is, the Regional Internet Registry root trust anchors are distributed through some out-of-band means, and can then be used by each relying party to validate certificate chains and Signed Objects. The inter-cache relationships are based on this object security model; hence, any cache-to-cache transport is assumed to be unreliable at times. See for more security considerations. To avoid certain forms of replay attack, clients MUST verify purported indexScope, ManifestRef location values, and manifest Subject Information Access (SIA) extensions match the expected FQDN. Byzantine events or faults in relay-to-client communication can be overcome by the client rotating requests for objects among different Erik relays.

IANA Considerations

The IANA is requested to add an item to the "SMI Security for S/MIME Module Identifier" registry as follows:

The IANA has allocated for this specification in the "SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1)" registry as follows: Upon publication of this document, IANA is requested to reference the RFC publication instead of this draft.

IANA is requested to assign an URI Suffix for Erik Synchronization in the Well-Known URIs registry as follows.

URI Suffix: erik
Reference:: [this draft]
Status:: permanent
Change Controller:: IETF
Related Information: -

Protocol Registries Request at Github See https://github.com/protocol-registries/well-known-uris/issues/67 for a copy of this request.

Media Types IANA is requested to register the media types "application/rpki-erikindex" and "application/rpki-erikpartition" in the "Media Types" registry as follows.

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.

Interoperability considerations:

N/A

Published specification:

draft-ietf-sidrops-erik-protocol

Applications that use this media type:

RPKI operators

Fragment identifier considerations:

N/A

Additional information:


Content:: This media type is a RPKI ErikIndex object, as defined in draft-ietf-sidrops-erik-protocol.
Magic number(s):: N/A
File extension(s):: N/A
Macintosh file type code(s):: N/A

Person & email address to contact for further information:

Job Snijders (job@bsd.nl)

Intended usage:

COMMON

Restrictions on usage:

N/A

Author:

Job Snijders (job@bsd.nl)

Change controller:

IETF

ErikPartition Media Type

Type name:

application

Subtype name:

rpki-erikpartition

Required parameters:

N/A

Optional parameters:

N/A

Encoding considerations:

binary

Security considerations:

This media type contains no active content.

Interoperability considerations:

N/A

Published specification:

draft-ietf-sidrops-erik-protocol

Applications that use this media type:

RPKI operators

Fragment identifier considerations:

N/A

Additional information:


Content:: This media type is a RPKI ErikPartition object, as defined in draft-ietf-sidrops-erik-protocol.
Magic number(s):: N/A
File extension(s):: N/A
Macintosh file type code(s):: N/A

Person & email address to contact for further information:

Job Snijders (job@bsd.nl)

Intended usage:

COMMON

Restrictions on usage:

N/A

Author:

Job Snijders (job@bsd.nl)

Change controller:

IETF

References Normative References Domain names - concepts and facilities This RFC is the revised basic definition of The Domain Name System. It obsoletes RFC-882. This memo describes the domain style names and their used for host address look up and electronic mail forwarding. It discusses the clients and servers in the domain name system and the protocol used between them. Requirements for Internet Hosts - Application and Support This RFC is an official specification for the Internet community. It incorporates by reference, amends, corrects, and supplements the primary protocol standards documents relating to hosts. [STANDARDS-TRACK] GZIP file format specification version 4.3 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. Key words for use in RFCs to Indicate Requirement Levels 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. Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] The Resource Public Key Infrastructure (RPKI) to Router Protocol In order to verifiably validate the origin Autonomous Systems of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data from a trusted cache. This document describes a protocol to deliver validated prefix origin data to routers. [STANDARDS-TRACK] Naming Things with Hashes This document defines a set of ways to identify a thing (a digital object in this case) using the output from a hash function. It specifies a new URI scheme for this purpose, a way to map these to HTTP URLs, and binary and human-speakable formats for these names. The various formats are designed to support, but not require, a strong link to the referenced object, such that the referenced object may be authenticated to the same degree as the reference to it. The reason for this work is to standardise current uses of hash outputs in URLs and to support new information-centric applications and other uses of hash outputs in protocols. The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure This document specifies the algorithms, algorithms' parameters, asymmetric key formats, asymmetric key size, and signature format for the Resource Public Key Infrastructure (RPKI) subscribers that generate digital signatures on certificates, Certificate Revocation Lists (CRLs), Cryptographic Message Syntax (CMS) signed objects and certification requests as well as for the relying parties (RPs) that verify these digital signatures. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words 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. HTTP Semantics The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. Manifests for the Resource Public Key Infrastructure (RPKI) 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. Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER) ITU-T Informative References A Digital Signature Based on a Conventional Encryption Function Advances in Cryptology -- CRYPTO '87 Proceedings Lecture Notes in Computer Science, Vol. 293 RPKI Over BitTorrent Maintenance of duplicate databases The Twelve Networking Truths This memo documents the fundamental truths of networking for the Internet community. This memo does not specify a standard, except in the sense that all standards must implicitly follow the fundamental truths. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. The rsync URI Scheme 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. An Infrastructure to Support Secure Internet Routing This document describes an architecture for an infrastructure to support improved security of Internet routing. The foundation of this architecture is a Resource Public Key Infrastructure (RPKI) that represents the allocation hierarchy of IP address space and Autonomous System (AS) numbers; and a distributed repository system for storing and disseminating the data objects that comprise the RPKI, as well as other signed objects necessary for improved routing security. As an initial application of this architecture, the document describes how a legitimate holder of IP address space can explicitly and verifiably authorize one or more ASes to originate routes to that address space. Such verifiable authorizations could be used, for example, to more securely construct BGP route filters. This document is not an Internet Standards Track specification; it is published for informational purposes. Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI) Deployment of BGP origin validation that is based on the Resource Public Key Infrastructure (RPKI) has many operational considerations. This document attempts to collect and present those that are most critical. It is expected to evolve as RPKI-based origin validation continues to be deployed and the dynamics are better understood. The RPKI Repository Delta Protocol (RRDP) 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. Compression Dictionary Transport This document specifies a mechanism for dictionary-based compression in the Hypertext Transfer Protocol (HTTP). By utilizing this technique, clients and servers can reduce the size of transmitted data, leading to improved performance and reduced bandwidth consumption. This document extends existing HTTP compression methods and provides guidelines for the delivery and use of compression dictionaries within the HTTP protocol. rpkitouch rpki-erik-demo APNIC

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. 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".

Experimental Erik Relay Services A few experimental Erik relays are available, each running on slightly different schedules. Client implementers are encouraged to round-robin between these instances to observe results.

http://relay.rpki-servers.org/: Dublin, Osaka, Sydney - anycasted distributed computing cluster
http://dub.rpki-servers.org/: Dublin, Ireland, - distributed computing cluster (6 machines, NFS backend)
http://atl.rpki-servers.org/: Atlanta, USA, - distributed computing cluster (2 machines, NFS backend)
http://miso.sobornost.net/: Amsterdam, NL, single node
http://nyc.rpki-servers.org/: New York, USA, - single node
http://fnllwqoupfrhso6643whm6lpkgsftjtc6crpehmyz2o7pffirnqy7rad.onion/: Erik relay service via Tor

Software An experimental Erik static content generator was developed by Job Snijders in the form of using C. An experimental Erik client and server were developed by Tom Harrison from APNIC in the form of using Perl.

Example objects Included in this section are an ErikIndex for rpki.ripe.net and an ErikPartition referenced from the aforementioned ErikIndex, both Base64 encoded.

Example ErikIndex This object was retrieved from http://miso.sobornost.net/.well-known/erik/index/rpki.ripe.net. MIIoRgYLKoZIhvcNAQkQATeggig1MIIoMRYNcnBraS5yaXBlLm5ldBgPMjAyNjAxMDgyM zIwNTRaMAsGCWCGSAFlAwQCATCCKAAwJgQgteOE8pPUend8kUR6qmLyVUJW58GNqxuv9u J7hNLi8kYCAkJ4MCYEIHaraMXmjcDabOQIkh+26R7qgymR+xJGjAAAnB7iDzekAgJIRjA mBCD7A2eyMRTOhBOw+K1awbIDfSIWDqEfx2wwnH/ssOcaDgICQNEwJgQg6r3dpoqqtP18 48s1V2ll7e6xQ1bOLleJ5dW6QHh4r6cCAkrBMCYEICMCi/TwPWOH4JqX3dvNAmS8+m8a8 uCfcpHckqhKzq49AgI+VzAmBCBdf+oy9h6oYy7Ni1FLcjE/FT55ZAVKbphxoAd6uAu5CQ ICThMwJgQgxYjeLOzCuVG37kP7lx6tE0tzp9M6U/NxS0p0a+5ZIb4CAkNOMCYEIBd1/77 YpybBiJDIW41tx6qFg3HD7zUg9oKrqWTI6F6JAgJLljAmBCAsmgS1P20sDJfK8jzBye8a gUStHxjRT6Vjvawtm5HhHgICS5YwJgQgzlGoWkadYriQpcBRR9tn+opJ0x9OsSa9RSk+x Jb2fWsCAk4SMCYEILYFTuRIifKf922SiNtmPnVVHLNnun2RSe2vFvhSeoDsAgI7BzAmBC CMkyd1oQFMenpKU88Dg7TEP8w0sxH20rnPAroelJbTKQICSRowJgQgDByPsQbQE9DcyeK Lu27VICKrtBMkJk/OygYTvvVZyKACAj5TMCYEIHMAxD5xBnppLv2EuLnuRbktX9f58Zyu OWZw4Bj5En1TAgJNPzAmBCDkEwmCGqAjsZPkfUm5i0tmDua7rEHvJcYa95fS68ZQuwICR PYwJgQgqiRd4u6+mbQLT7maVQnu6k/2k2X8a9sW57/6+OehXigCAkGjMCYEIE4SnNsvI4 rlXxOR5ZEe/Pwvt6bjnSaoCif7ab5Hbjv+AgJGnDAmBCBmKBJTmC3J/Sj7NnFWZk7Q234 riaaXykvRD20oty0ZqgICRp8wJgQg5Fgfag3shlS+jmdPySCaGbL3MRLHtjqK4esqnimO 2VUCAkT1MCYEIHrthfZ3L6haWgUGgunM4WPYaN3CB9Fi5kHjfq0MO9bRAgJGnjAmBCBGj seJNUXkpN6OMKV2CEBvsqi7SWSsIe69xCg8pY6a0AICM5IwJgQgF0ORPc6Z4wjWPrk0I2 GNZUI5Ydq2i94ujoa6LpOKR5oCAkhHMCYEIDogoD9JqhB/qYYJ0lk0Ot2oVWe0KAku6dR A0PDhp5twAgJLlTAmBCBRp1q9Jjh8HPtrCdJuoHlZSmJesaMH4gmCgbbSzRLwqgICUjUw JgQg2x86JI1NWZ0Isw2G81u/TFIacQcMUP5KY+7oBwLnAusCAjlcMCYEIN6ald+lseUkl fTphACppwLpSg/sO0o/vpFtbj3Rji5pAgJSMjAmBCBU7TRmN2Ol5MsO4N6KRl/2BAQhpI EAmx5ointD8kXkHwICUjQwJgQgae2HBmn6vf2fJT/y7XbnuWo6NUXN3nYDT3g/zsGT9M0 CAkQjMCYEIL2OHInTlcfJctbeu0VfAzY/KFwFPhttEozeCqAVq8ldAgJOEjAmBCDAl869 bttF9BYGOwK/kkf7npDCinlMpu3jejhVg77aVwICSewwJgQgdV5dr99Mesm82uSSaTr5f laqjDpG48S+asnR74SKitwCAkxpMCYEIK3vJ8icN4xK9gqlg9ad3kiz/hUfIP4ebZo8wV TDBIubAgJJGzAmBCAYmoT9JryRbijv5nnKOc9nq9DxN9J1K98QKcgzaMvD5wICSe4wJgQ gfcDoA5zq2u3IJjQW+dLoe7PsrhYewA4VkR3qjFt4e78CAjytMCYEIKWjW2RIbdezwJGI YVw6LfRpcPjs1V+A8+joGG3aT/NoAgI9gjAmBCBpdyBWzebD4iGbFSVavuuoVvfp89943 RBgifoXP6gxhwICU90wJgQgq8PPWUFcKSmRSWxExdOiJKGC1ER3PAWLc2GQHL7R85ICAj 2DMCYEIO3d1sApCGkBXz/06+eCwygPBTa/IaCEYxSXgc/UfcQ1AgJFyDAmBCCSk5WYxB4 hU6doIMpLrfI9vKZlGyWKLUQGpqpyVZn81wICQacwJgQgf/kA9qoqMY3k2D8rzCN7YBvh 6N8aPXo3uYYB4kw+yXUCAlI1MCYEIOcHtxPyWHA/qgkca09niQc0bQJMBUM6Pt6GTCvzx sFyAgI9gjAmBCA0Qg1uJakxAqpuGUq+Kw/7HIpqiWpzm+ej0rcSzu7ujwICWn4wJgQg61 JIv53XhGq0AA9B12oCQ+s1JvOoM6oU4DX9txhJj2QCAjyJMCYEIOIPL03mqDvKULLGm7G h81QqgGKvR7bFrTiKDtKTMXsdAgI9gTAmBCDl0+OCKZRKXXw+zrqoBJRZcjT3RbhQ3jXa k0ETShkX7QICO9owJgQgl8Hqw9QFeGH69AdgpwBw+0Ul08iSBGCGC36vfeG5kYsCAjsGM CYEILWPQn2IZLnWpVryPboErGugOso6VpmyxkrvrCfeYiMIAgJGnTAmBCA6LZX3QfyOiZ v5dXllXBMENaFNn5hwG6QYkk1il4dlKAICTucwJgQgvKcMhYPi4NdxvYa9HBSZ6SONWgY AadPHtVxQYwq61VICAkdzMCYEIMeorZamZ7UWPcViw8Voj8eeHpID1LcYMdbOZozX7Bd2 AgI/KTAmBCDPQMe0Evnwn1NrrYNZPPZXloPO7Z1vF5m5J2NraaNUjAICS5YwJgQg5Zmpf uETw3YjQIpIFSSrqtKcxlVR04jYLTqFSGTTvRcCAj5VMCYEIPRrKLcHW6zTeJCWXquLqp SHz9OcNORMFkbw4HhAchc/AgJLljAmBCBp2AI4s92ufELx1TMCSlUjastbar5/bXLQ7l2 9xzi83QICP/4wJgQgvFOEtAchlJaDaym9hOU63BQ48+cpY5CtzBtL/90ZgQwCAkrCMCYE IDs8UFQ9qbtwcHs2cYpjEyGWrhv3Ai5C1oKRUUx526BnAgI+VzAmBCC7SbJIm5/2L6znj g6FvqgWRsFRi2TO8fw3r20XA5p6HgICSEcwJgQgh7yY3te3gI0LKK+l3vA3XbbvEN97X0 Mbae/+rwtVQSYCAkhFMCYEIKaVKX9r+hEBLo/v1n1wFj2q+UUWewcrjIt+yov3isdLAgJ GnDAmBCBDkUOMPLGnT0K8zu1YXpnbUm2M98F4QvKh1rfw4dyuvQICQ00wJgQg9M7/tmwh nE92zsVYz/S8FWbpCCfciGMlfNPdu1MFQ2wCAkDRMCYEIGjYKfRU3i3BQoKN0nFHq5zuB Cg3/qh7POEtoI8e1WTZAgI//zAmBCC2JMivUXv3/zIsUiEkXyBohgyzf03HTaik2EyJrI q9uAICTGowJgQg4h1xw2qVNaDfMH8SfbB4w5Fyps/cMYmBuYxWeT4zRHkCAjbiMCYEIM/ 8ZhZ3CbuEGwBuTFAEbnP9nBPoGSNtAg92MH5F2ikdAgJO5TAmBCDdIeMvdsibEFcMMDnw vGBadMXSLM3YQOfcriBNzgN2UgICTGYwJgQgllY7gmnDjFFvmpDMKrqYKDshKYKcpKYvI CWvB8C/B+YCAkkZMCYEIAIQEQ7SkajiaEjZFxsmf0KworoXAjV4XXaZ+hqKjhDLAgJFyj AmBCCTZe0oogg10rpxb9RThmOPxVeBzywrslOoVrWwjXvzVgICTGswJgQg7mGTp/zvlRJ btFyXIekSQ6HQ58tfSpkot3HmzoFLD+cCAjleMCYEIFmaxCT52zYoJHpd1dt2zPPYZD0y izbyV9MnitmLQ3MgAgJIQzAmBCACNx3IoeoqeqclIcXFSLmRHKQA2x9lsUcChkQDUO93Y gICQ08wJgQgurGtxGxiz9efkspthtOoyyMojRsXXbMadlAEpuAOdzYCAj8rMCYEIGP/gT JbZBCFCtbEzBCsmf9rSe+Ec9W14loYdo4LnzBfAgJJGjAmBCCQRnyclxcMJ42wDovHo2S jazfcg7d5ir3kK0dfCZQZMgICP/4wJgQggeYSilmj9A5COVGCvujFMa3BNvJn1JNzbd2C O7sXq/QCAkafMCYEIL7l0nzPqj6mFyzSMfcN9W33Pc7cYjRJVbwsLQ6jx5hyAgJO5jAmB CBAUHuJhjtDBF7EBYqUf8yxdFHLE2HKuNanb1i/hkSwaAICRPYwJgQgzFnz5ckeEYWFQG kPhX4b05boAuo0ZOgo2icxLW7fTyUCAk09MCYEIMMCMTiOMgi9TO8HQUW6012+X/lwnAn uVsZdHDQGGEm/AgI//jAmBCBVzs23DRHsMUoMF48qIjnbuvggLBSZh9vNMA4DonV5EgIC RcowJgQgB/budfyslLESuj91pUDFEdU/UA6oNjORbWYL2lqCj5sCAj2AMCYEIIJfegBmy EQJdTVGQf8JvNoAXkC0OwoLimbZAf/c5onVAgJJGjAmBCCPiXNTbCqHbBMS840cT2BDdP pPK5KRlPmLaPtsOliSbQICVy4wJgQgKke+YEYEGccTsCwQ4qosckkOEOtpLdYH/e/yOk+ wyVUCAkxpMCYEIDsO9ouxgT6ZDTZ/2bfabpoQjUTlFlrVK5EoTwjBhszBAgJBpjAmBCCm RG8jmSGhz6qX04UyMO7sXE9dHwdZo/ouzvcCzi+WEgICMeswJgQglruzQ8bh7Kyt8uqdU RlJ3nJ6DIYeKOZ/iv6bzMHvJvICAlI3MCYEIP5HU9JnOUWo0uP/il8IyWlsS2oh2YEOpW seOq7ncDUjAgJMazAmBCCnowTNTOXdmORzq4MNkc81HHVo8QRswrDoJP+ZxmxUEQICQac wJgQgp0y7WiuZPFoiK30xAPD7p6UHDwVYVX16ptfn3xB1a54CAkNPMCYEIIxtpX4DFbOC M2/b9v9SijhehnvTUvqg4LTgRU3bx9iKAgJA0zAmBCDF7fDp6ceTkPS6QisrUBSapQX3b EX7yDWpcZN86cRLrQICO9owJgQg1CQ4vdZezesq8ySPTCt5ZNv6UIBa+uubuUFhMUkhhd kCAkQhMCYEIPc/PBxijzP1QKlIhoEbynPyplNcWNKOxD1sKxJ3s+kIAgJJGzAmBCB6Ci1 A3Dd2J/7RQKZSCKttO/6UZ8I80FRtt+E41bB+hAICQNIwJgQgnI7yJ7eaz4lKHbuQH0rv TCLrjD6mMvxRRt3Gj79qZxsCAk4TMCYEIC185VSnjtR6lPTGbJTUjek9GxHkMgkUb8qaE liMfXk/AgJGnDAmBCBF11WiXA+oi6JUeBpmKzJzplr0h6aTVk4Ap0rGUv6YjQICRCEwJg QgUHkoaa053NIb6rBjXeCKaEWa3lRWwRqlYDZopKZBCUoCAj//MCYEIOfQKLO6T2FsUw0 +REFT5ST8h23c0Us+qcfCwP3ASMm2AgJBpjAmBCADKyjXhHu/uR06mEl/3u9w412q9ILN 2LMrz6fHsocZgAICQacwJgQgvHDCqBL+Cd9NkUo2cHtIJo3hJLbXyTTjNd4s6dyYVqECA k4SMCYEICStmRJXJw+3RykPvfaJhfksPK10pkw74lr2qDpbwFeHAgJFyzAmBCA31pSCS3 abFXDVq3h5m15hI3mYABLtXwvURK5hhvswdwICTGowJgQgrWr/41cm9u63f8W/mQeLaL+ ExKTLX0vbBxZesryuNiICAlZZMCYEIEoCT8CNeyJuV+h0LnQYHoiKcHSRSQQisiSFjZ1f bxykAgI4iTAmBCDiHzWMfdC2XqK1XPEO6adAHZ4IHRiJck8XYTVjd5kK5gICTT0wJgQgu Sco5nBYFs3gheoNYZs4IM00QCbpWRlDpFCm06jTgO0CAkadMCYEIC/Z5qEkYIUZwOfWQJ adgLZ9IaG/ZJIKvPsuUqA4DSH7AgJE8TAmBCDMRT7YgJF8aeHYiBvTwU+9pwWWg9R94ut XV3PlzWnpUQICN7YwJgQgK5JsQ/pyQfwKf9JEcRjlGj3lgimLRzam43LwDdWYjj4CAk+6 MCYEIBYx/6j+5NoqnT2HXPLMVz0UBN08uKsJNJ0KmRnEYKu8AgJPujAmBCC9ScwKn4Kfi imLQys1ccbxGF/ivq1EsxkoWfDmzTlwrQICOV4wJgQgyPitIFGHuqCiE/5BmqBrCxFdlg RG/6SC5YuGrTo54yUCAk+6MCYEIKsjT+PpckG+SNAIP/OTFlmbXP5RlppvHWcTqMd9UsA PAgI/KTAmBCCNWpEuR/O/dg1MC8XoBrYvi074JMCzDlw7/IsTirw0qQICTucwJgQgHC9l aJvEL6SdsD/y50JuXTAVNnuDQ8/n6gOem+sZ6nUCAkJ5MCYEIBATmzo5nsK44W1XVu29N zevnFGIhVWdUjbPLvw5z2l9AgJA0jAmBCA415eRHersYxqQa0SXtcpX+wBONb0duIX9GL goRfD54AICUI0wJgQgJ9o4m5ihjDz2PeOAVmLW1MnSqUFcQMJ1pUfy0ha3b1oCAkNOMCY EIICJz1R1pVw0ZN+D87tpVjg3rXMCliQfd3zBgrmi+o4IAgJOETAmBCCcH3nFpvyHDBBr rem23RAV1/I8aaPEKze7GjjP7Jou6gICQnkwJgQg0CAOOY0UIm6LdiwIJdpJx6Gp5oZT/ CALU3uC9mdY9+ECAkQjMCYEICDQbujoaiLogH5KZZCB0O+mk9vfNy3WUhtGhEcmD+4UAg I+VjAmBCA1Vq83/WkWjUk/0z4MSS7Ehp1hxGDw4zXe9R+saEWhtQICR3IwJgQgJHOn34h 41MGfHCji+eBnReWI/SwtOXVikuJ/LURjc9MCAkDTMCYEIAGZsMkSrwRb+Az5doOSAITP AWw71Vs2b4AS4zkQqF6jAgIxFjAmBCBnBCS94dydJj0/+9CQ/90q6nwHDQcY0o2XCDO58 2b/oAICOV0wJgQg9HMP84oTzEJLHxN8NYe9aUcfYObxSS/R/I9ybijMGjwCAjvbMCYEIF sR5FJEysleE+a8x1JHYraPdTNJZO9WlkcmFSDi2ybeAgI9gzAmBCCvO+Pfmnb6hxV9jQa rbbZyXcwmStbzUNLt7Z2XgB8ThQICTT4wJgQgHqJSm08hTubeocg5lSGN7s8JyoX/MCwV KwPaM1S7HLACAkT2MCYEIF8hcOz0I/OGcxn5BHAduTfsostzbGtFiv0GaefP8/dJAgJFy zAmBCB/8EMy4qiSVib453clxhnB0eFZuXQjyCECtt9+kIhT9AICQaYwJgQgS3lRDpPpty eaCOTeKbjpr0M0Wg2JYpdPkNZCkz50x8MCAkJ5MCYEIBuLhTXGwbyyAepysM3KsAociO4 qyJGFhVn69COeXCWfAgJHcjAmBCDU+5SF71OwTQXLM9XTwigbYfPgND+pRyqsW8TM5Ezt EAICP/8wJgQgl7Jo7POs5oYrjesPf+WS0KF4yMIa8JDw3/1hLxK8UxACAk+4MCYEIHulo rKSwLycSnr8Y8ytEBZ6rlJAiwnQF7zcH8EExg9XAgJA0zAmBCAu24La6Fb0ESnhiSkoBE c33SSf5SJgUNcBVAYchjDHhwICO9swJgQg/QA7DeqcyHs3YQN3nYPhCWuSVQm0c7zYoqJ e5VYMYwECAkrCMCYEIK8r5WrsWvSFugmdT6T8Xso9Si23P8sWh+6McBFaEv5MAgJLlzAm BCDyd/TBCJVSTJIxeBZXnsjczukCkDN4oAevoURN+bVr9QICSe4wJgQgO671WYmnyGDGx BEXbfi7aaXTXq6HIw/RGaMeBrLO+jwCAjiLMCYEIJiT0vxYQZtZVY0CdOfgGr+ZHwReJL 9FBX3c6UyDUks7AgI3tjAmBCAMfOg0g9vSHei8oi3YREkv9KWDqyJK9q2B5xIkHTS78AI CTT8wJgQgz3+Xr1jzpHJ6Z8tCSAyifouWa+YUWXCJkZafqER/ISMCAkuXMCYEINvi+QH+ ihPR4qKykN7FjfhfhLEJzDj+CB9wVc4VBBTMAgI72zAmBCCGqyNIqULLk3DHO5YsIIk6Q PtNmt3WyIF8Pb9PNjO88AICQaYwJgQgo08PeHFONB2JpC8+76tcnkgzUM8phHdJjyDWOS uBA3gCAkhHMCYEIFC9Q2eKNfjpJxoyiEO914BqjQKee7sqAjkOEp+DZgfOAgJBpzAmBCA Jcn+vmdgPTAeDvDdLT3s4BwC74pj01Hybmre+6OzW9AICOwYwJgQgX8tZ5evtpTUH4xpl Hilwmvyu+lxSmuUFvdRM4/oglpACAk4PMCYEIKw/PXt4GnX7tsC0g9FSOfswPKcSLBtUx Bog10sg5SaFAgJJ7zAmBCAM5qGBqSmY5V5qP89DQm/QN8F+HYHJxIJEWo8yDjlL1QICP/ 8wJgQg4Im8hmLgxk5AOT2icXMnds2EKQ2xASb1qDqOspbzacoCAj8qMCYEINSMY+eQXlt fmOBLg0PxRNAPl87T+sIge2NKTgze0EDuAgJEIjAmBCBlqehaAgJSlpSnZ/5qt730Y1/R AalrxsgfQ6kTvIZdwQICT7swJgQgXzjEPbigCsa7K0D2Qpgg3ail1ATyskzRQpsLF6fqi 3sCAkntMCYEIKhSAlCG3xVLkNszRi6W2G06iHPEz7YJobZc/IePpV7PAgJBpjAmBCAJ3k RgiX8r7KR4/NJ1FOmi/1TsnaOjPq59d06pBTfMRwICQnowJgQgscxbufrbZeOOPwxXGE4 XnyaggXcz3Iw5lR5g+/0KnxUCAjsFMCYEIG1QyGSS9YE+rgnFDXpG4gVqSphxIey9EsXo mI6s/CJBAgJHcTAmBCBXoKnU7MAQCUtqxm73Uu660ApL5ZosjEQtF0yEORjJagICT7owJ gQg8vAOROTRVH7vK72BdfYTHy2QuXEkOB7X1qmoN8/SKT0CAkadMCYEII8taUtzUfvfca DrIjrrzNzGbo60TqoaN3Q2uLgKhU9uAgJA0jAmBCA8Jsi9rBUN1R3cJKEATddc1d2wHuv aNrtR32zoye7ZMAICQaYwJgQgfEHGwDMQtsrp+sI9rnvOnAmY+xz1XzyRh8t3Q7otUIcC AkNOMCYEIGdd1tErxsuk6+YQFyc08X80DVrlUsCgGrnf/N7GMnajAgI//TAmBCArr/RhU xkeBxnfEo95YODmLW/B1LonMxwGCox2COYRzAICSEIwJgQgEweJtvNQL9bjf2iQ9AW+yp JHzOHqhKf7acEDKCernEYCAkGnMCYEIFt7DobpP6uC036RRjyIAgQQ/42jtrOR++MD4QY fbpd7AgJLljAmBCDr33bhYRLCqHfzhqVA9h0OEUHFpMgGdfuD6YxUdv6AxgICQ08wJgQg 6kyL6peOm+TBOBPVME8CAqB+ANHfBiQXmFG8Rv/TiYECAkhFMCYEIPH1EhAhYbq5kHXdp rO2X9WrNqmml2Rs3wI5Q8tfecZ9AgJVhjAmBCC26nQBMIR6buqJ1zPG12wKCsV01mglKE EXyMLiXiSvaAICPyswJgQg7xLqvkJLJgC4mqBnbzktogFz0Cgf6Mj065Z+melcod4CAku VMCYEIAzWDR+QpUqlkBwLYXdI1j+1S+atzi3FUjI6UpY0zrDkAgJEIjAmBCBSDmLoPTTp o2lThHrqC+EKh+d3oZYyINVkIF+UB2nS4wICPlcwJgQgFcOQIlwmcVYCKL8pT8vW2u7EC ays8aVCMsNOQ4nMiqYCAlCMMCYEIBIYL0TPWI30bVJi6DloMw6BjsEzHdHgpY578GqFqJ ENAgJPuTAmBCAtdStaax5m+bf0CkFCW4ahYk9h/bXYThkbAqjd/vrqlgICQnUwJgQgvQS sn+BQYX8KlSqdWXRWw8JcJWMoWCUBb72YWX+8GlsCAkXJMCYEIE55GSoKFsJUZO5w6slR nNn6Sg/7qGmF72JrQP54PR/FAgJA0jAmBCAvRh8/FWBFDyzhzx9DlT3EURcCuFG2bkmmS uEKVca4ngICTT8wJgQg/3HwZWX3kCvSIgP353RrzmQHmNpLuDYnhJFgOe4VFnUCAkQhMC YEICFmgQIz17HiFDtOzyzTGBbjW+J8zWIIEnhJDglbK/QBAgJA0zAmBCAG1OHcH22DLxF OKmutn3iwIaB7y4p71vHkJTkfJvlCawICSe8wJgQgVXaF+fl946I23YBM2yugiNBAOOgU KIMSNqjexcts4W0CAkNNMCYEIEn17fqWUHl/Ut0396kcdMPes4P0Ilumc9GACGdzPxSdA gJBpjAmBCCKnq9O/mbcRISAeDyhs0Fj8uUuYtyZVFiWeuNEgQduKgICSe4wJgQgFSyVT0 sZ+KAZuPm5O/NLFAVmwJfj0Jh1fDK/sIjt9PkCAkXKMCYEIAjRw4V9a1Oy808Uj/6hFDv HrZGtZzwcjlAgWmBa4lglAgJSNzAmBCDbhYX9msQB07vzhPv3+ZimS53DuyP1PkU9++WU fREZZQICRPYwJgQg9eFpbDRspxIpYM5opguFlrRZMoLNlMaDgJZuPtmvxJ0CAjyvMCYEI BDUK87HsfP++Nj7DP5JT1Ku+4pKLsObbZMnUtIEtz95AgJBpzAmBCBAkEDWSeCipOcgg9 gushL67+tk6gHb0fxuDbXrVq+r3wICSsIwJgQghxxpeO0zW++6xbLY+i2QNRl6Kho0o6g 3k1vRgyKMCgsCAj2CMCYEIF+D1twA/l9ygIBXNq5TlGzw6DjpFmVGmjw6CE0sG3GMAgJF yjAmBCBRZOPIg7jm8bxv9tZLQJldOPiLfnvxLPf8YY9yXDzpmgICQnswJgQglQD4UBUMC T5hNDMVNooytw52WqZGHvksHPJBU5QjGPUCAkNOMCYEIMspqi8R4vx0YcZrVCmoiKBaQ3 dgISYdD2o0yWcG3ULFAgJKwjAmBCBT6JKpPDGqs6qGA4Mkom6+zZp/dOCEMOPamYSLIsI 5vAICTGswJgQgvzO4UiG1l+t3BxPhCyDBdUj/dGegABaXn9U528y3FBoCAjiIMCYEIEdi vwkozmgnX0g+45qzbq8I4GuTRGX3qaHk77f/D82gAgJKwTAmBCCWWHiS9m1FuFJ5saDtj 2/VUCmNm+QP9piNW6NTTzFC9AICR3IwJgQgzNVM/wCeeYiJoOKGJBMHIKftFtjL8mw85r kXhTpARZQCAkT2MCYEIIf+dxLYN1WtEUUH6pknbxrdqSDYAjmV6rlaqGulZJhWAgJJGjA mBCC6JIVZAn4XmVimESDDCezTQiCnTe/ToMjCqwsnyf2lhwICQnowJgQgj91577YttW8J GjfyAWGQNmM61KlR57o7zKu7QQYlwX4CAlFgMCYEIAhVWwYn5y3bziyHlaPrX5QTq6AWp /6y9zn8IdSNf+XUAgJEIzAmBCAhvg0yHLZdJ0Oi4gAoz6H1+IIGiXplUFbbZ5MeU233Sw ICR3MwJgQgsaAWfywlBudRzWhmRwRl/+O7SPDX0FrldY6JPm71zRkCAkJ7MCYEIOmgadk Hv93OoPy0zoX7wG+ZoX76OjLQtVUz2k7UIQHIAgI+VDAmBCD8L1cC9aPe9b5Fo1efCR6a +/94EioZJG0NF/tk/3gHAgICQNIwJgQgzbSJuYykxcB4D/KCrmbGDVC7+Tmon++UW/FsY SZECFwCAkNNMCYEIENgVDzKBFO96u84ktfYN7nVDGTdaRIzkxc/Z+syC2TPAgJEIjAmBC CqqalHwNPiA2dukhMmKylGLq4Emj1CzBY+rPMYzAGNFQICSsMwJgQgPxuwJb1hJeTUKYF Wlq9lmaKXkXArUIHXBSBCQgpfTHkCAkJ6MCYEIGZTSrHvZ2TJ03ZwVdu6meXVk6hBoHei RLgYj4RfAo7iAgJVhDAmBCAT4X4YtJQLqZqvilWETxZ3WRkB/MXzPDzErEcQZVzpagICO 9owJgQgnlYBrq/ADKOxSLwWZ6jsZ+nbv2ytWqnEUYI/CArG79gCAk4SMCYEICxORErcH/ 5qrlBu2QusFm74gtkBmiVee31VXbcFgir5AgI2DzAmBCAB2Ar/cFcjmNmZNcpszjRYO1z xHjL3rKKD6QbHkXvuAQICRPUwJgQg+URpogPr6tZneDVkkkRsrLoJz+s5vlZUrjwn6ewS Ci4CAknvMCYEIGD8A/+EQeRfLSj0SBVjapGsr4no0q6VP04qAo61FGeEAgJSNzAmBCBjn fmnQ8Blq8pEldKJH/5N032PRKvu5+4plXaixvZp0QICQ00wJgQgIYutojOYLEnkTLsoI0 OsT1Ar4f6qdY5vp2p9MhDxmXACAkQhMCYEIJxd3o0dh+NGQkzBs3MaJdt41OKeTkgv+sB KvfSmGwZTAgJA0jAmBCBhLW9KsT3LhN7Ludd/vzGkQaZiAkuVhWKCRUdAyYLh3QICP/0w JgQgzXb8SwnjAJnNj5ZFe10JVZe1s2bye+zmxCfzVhOm5HYCAkXLMCYEIFImRd4H/v2g0 tNA5hdzQJQnKwN6U0/e4iuyJ4HjEA/0AgJRIDAmBCBn5tUk0D0D3lUgZMIc/qupQ/y9U6 /hDkr1Td/vSCuaKQICQacwJgQgGHOrmZ+52gwLIkj3DIHkz9zwCzBrHGVJ3de52oeeDiE CAjozMCYEIP3rfr6Bxvdy/Sikb8tVO8ASb1wPr9q1a3JB2Irbm8IXAgI6MjAmBCBwoQKg FCYLRx7NBruVMNqC4LrGm+r63aFYZVVVNiTkoAICOtowJgQgy/J2VVix3tYZ+nf/Q5eVc BLod++R2HHKUqaccejU6RwCAkJ5MCYEIO2fBhl8+PH3wtE3wnXe5c78MeTEZyl/kyyiiW J/EOQCAgJDTjAmBCBVBCrBYolj8pBdjPN/+2MCjWAvWXR0IZreSSz1Flv2hgICQ08wJgQ gcPcgpSFhOXx2bp6EZIh1O/TQawqa92f6cfHB+frK4dACAj//MCYEIJOXUMlFlj1pyJna g/1/RS0Tsc1a5zCB7G2aAKvcwGcDAgI7BzAmBCDRyTSvv0GkOx4DalLdBFw+29Y7HbUDT 3DhYUa8iudmHAICPyowJgQgv8z+XZ6YU/qi0+CrEn2zPPgH0vJhV5obNo05/L6MGsMCAj vbMCYEIDizLsIr8vm7kQ4TpfMScQTyk3ueWKEevGNQqSZ2nJNbAgI7BjAmBCDzNuvUQSg QI5283uMmyemP9B+BD+zXJmCdq4NC5/e0DgICQ04wJgQgoH+CnPLGmqvTv2FP+WtrZJtT yHEmI5Qh8iETVIMwDVoCAkJ7MCYEII4Zkl3ibkXtoi9/tCcRwHIzMe4dk93NsX77x6+3K lqLAgI9gTAmBCDm+6tqUlS/87xVMVBRxUxDwlrLmF3z/vpfGWa3/b3VmAICQskwJgQg9E kg0mb6OcwZAuPIvglyhcee9OMkh7wPUl0c92doyJ8CAjSmMCYEIIs0cuOLf9fZ4BAqVjI QWllmUUGh8t1nsIc9WZiNBbj+AgJHxzAmBCCCqfNU2Q3p2OzvbV49ppqLGySFilfujV0o R0Ml0/tCtgICQsowJgQgj8fmavD/fbTWl/IPjS3DUeNuGq1fS+oBDaGljgXcdGACAkkaM CYEIIixhEaYKjuSUm3DEmeLoJY5ew6+OXlzMgmajVOgK+LAAgI5XTAmBCBbu1540vVhbe m1AFpnhqpZQCFeN4J37O3Ttj+t+C8YXQICPlYwJgQgYX4PVaUu5ZlKcoLWh/wKkXcdAeh iAl/aE8CzteMupVkCAkT0

Example ErikPartition This object was retrieved from https://miso.sobornost.net/.well-known/ni/sha-256/AZmwyRKvBFv4DPl2g5IAhM8BbDvVWzZvgBLjORCoXqM. MIIxEgYLKoZIhvcNAQkQATiggjEBMIIw/RgPMjAyNjAxMDgyMzAyMDhaMAsGCWCGSAFlA wQCATCCMNswgdEEIAFg/0CdwFaUyfP3EyK5RmO+SHjEkYpJ03VcFje02/uaAgIIpQQUfz 4LJ7jk15j5K53hV/HaWkPNSeUCAhH4GA8yMDI2MDEwODE5MDA1NVowfjB8BggrBgEFBQc wC4ZwcnN5bmM6Ly9ycGtpLnJpcGUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC81Zi9hMGM5 YWMtM2E0Ny00ZDZjLWFhMTUtYTQyZWM4Nzc2ZmJiLzEvZno0TEo3amsxNWo1SzUzaFZfS GFXa1BOU2VVLm1mdDCB0QQgBNUfbUn0GcyCLtIB6SMWn3PzeAvWEckmuoPOieKTqQgCAg ilBBR/ytid8b+Zo28pDMPvDx57TQJ1MwICF5cYDzIwMjYwMTA4MjAwMTExWjB+MHwGCCs GAQUFBzALhnByc3luYzovL3Jwa2kucmlwZS5uZXQvcmVwb3NpdG9yeS9ERUZBVUxULzU1 LzlmOGIxNi0yODRmLTQ1MTItYjNkYy0wMTVkOWYxYjRiNTAvMS9mOHJZbmZHX21hTnZLU XpEN3c4ZWUwMENkVE0ubWZ0MIHRBCAHXXSuVDo4xIJcp05FZytpg4kjD/qhya82XREhZN cQDgICB84EFH9RIoN0dC31RKqTBYxaO9PRZCGZAgIPKxgPMjAyNjAxMDgxODAxMzBaMH4 wfAYIKwYBBQUHMAuGcHJzeW5jOi8vcnBraS5yaXBlLm5ldC9yZXBvc2l0b3J5L0RFRkFV TFQvMGEvOTM4NWFhLTFiNzktNGEwMi1hMDkyLTAxZWIwMzY4NGYwOS8xL2YxRWlnM1IwT GZWRXFwTUZqRm83MDlGa0laay5tZnQwgdEEIAfribv7yIvTN0Wj8JLMcqQVV5J/DDGHUE cOrsmff15rAgIHzgQUf5LfdhDwSPQ79EwzbUHGwRV+8OICAhdPGA8yMDI2MDEwODIzMDE wMFowfjB8BggrBgEFBQcwC4ZwcnN5bmM6Ly9ycGtpLnJpcGUubmV0L3JlcG9zaXRvcnkv REVGQVVMVC8xNy81OGJlMTgtMmYzNS00YzZhLWFhNmEtN2Y3MmY0NGI4OTgyLzEvZjVMZ mRoRHdTUFE3OUV3emJVSEd3UlYtOE9JLm1mdDCB0QQgDIjUjD6duUu0FKQv9y05IBRfVc l4+Kd1b9mDDIns65ICAghgBBR/UAd9LdimehrotqvWu7NIkCiluwICF8IYDzIwMjYwMTA 4MjIwMTMwWjB+MHwGCCsGAQUFBzALhnByc3luYzovL3Jwa2kucmlwZS5uZXQvcmVwb3Np dG9yeS9ERUZBVUxULzVjL2MxYzFjZS1lYTU5LTRkY2YtYmNjYy0zZTdjYWRkODhjNzAvM S9mMUFIZlMzWXBub2E2TGFyMXJ1elNKQW9wYnMubWZ0MIHRBCAaaM1Znthus6ISP96g3J D81Tog+3zOPZGZ8AuZHf8H9QICB84EFH/j1jtKW0BLX/g8vysVJaMEd/ZcAgIE/BgPMjA yNjAxMDgyMDAxMDlaMH4wfAYIKwYBBQUHMAuGcHJzeW5jOi8vcnBraS5yaXBlLm5ldC9y ZXBvc2l0b3J5L0RFRkFVTFQvZjYvODFhNjcyLWZlOTgtNGQzZi05YjgzLTJjYjdhM2I2Z TQyZi8xL2YtUFdPMHBiUUV0Zi1EeV9LeFVsb3dSMzlsdy5tZnQwgdEEIB+2rs4fnNPglk dC0Oxj3YrmH7gcOCVQjNglyUOdsjI5AgIHzgQUfzP8QNLgMzu8e96rK9hZlUMBwPECAgc FGA8yMDI2MDEwODIzMDExMVowfjB8BggrBgEFBQcwC4ZwcnN5bmM6Ly9ycGtpLnJpcGUu bmV0L3JlcG9zaXRvcnkvREVGQVVMVC9iNC82NWJmMWQtZWMxZC00MGU2LTg0OWQtNzk3O TBkNjZkN2QzLzEvZnpQOFFOTGdNenU4ZTk2cks5aFpsVU1Cd1BFLm1mdDCB0QQgI6Umay dl8dJpPFLj+98hCRWwWetbdCBsDVGbXzToe9sCAgfOBBR/KjK6QhloDc3Vj2EB5ceuwVQ KcwICF7sYDzIwMjYwMTA4MTYwMjA4WjB+MHwGCCsGAQUFBzALhnByc3luYzovL3Jwa2ku cmlwZS5uZXQvcmVwb3NpdG9yeS9ERUZBVUxULzU1LzE0M2U5ZS05NmU2LTQ3NGUtYWQyY y0yMmU2ZGY0NTg0YWYvMS9meW95dWtJWmFBM04xWTloQWVYSHJzRlVDbk0ubWZ0MIHQBC AwH+fHKOlH39wY9R5xHxHmhMnb6GSHhpnVmpCHVeA8FwICB4MEFH8QnrYwNX69ximBGmL mKxhXpxMqAgFQGA8yMDI2MDEwODIzMDE0NFowfjB8BggrBgEFBQcwC4ZwcnN5bmM6Ly9y cGtpLnJpcGUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC8xOC85NTAzMGUtYzVjYi00NWJmL WEzZDktZjhiNjNkZWRlNTZjLzEvZnhDZXRqQTFmcjNHS1lFYVl1WXJHRmVuRXlvLm1mdD CB0QQgMrEX8b0WrGlFZa/aGJQ1O81LoLp9UO84CBaveQjgEJ0CAgfOBBR/VoneSnznaL8 6tdn4VG6FbMsZNgICF7sYDzIwMjYwMTA4MTYwMTMwWjB+MHwGCCsGAQUFBzALhnByc3lu YzovL3Jwa2kucmlwZS5uZXQvcmVwb3NpdG9yeS9ERUZBVUxULzc3LzY0ZDUwNS0yMjA0L TRkY2EtYTk1ZS04YjUzNzI1ODRhY2QvMS9mMWFKM2twODUyaV9PclhaLUZSdWhXekxHVF kubWZ0MIHRBCAzPSRrimqT6CeNH3o60zUEaMS3WUawEw4OZIl6p9RoIQICB84EFH8Yitq 1tVIIHsrIIcmwkDlIc7MVAgISKxgPMjAyNjAxMDgyMTAxMTdaMH4wfAYIKwYBBQUHMAuG cHJzeW5jOi8vcnBraS5yaXBlLm5ldC9yZXBvc2l0b3J5L0RFRkFVTFQvOTAvYTY1NTIyL WY3YzUtNDg3Yi1iN2I4LTJlNDYxNDE0MWFhNC8xL2Z4aUsyclcxVWdnZXlzZ2h5YkNRT1 VoenN4VS5tZnQwgdEEIDZuHlY6ZmzvFkBtLu2X4/vNQhnzQRDO3eUq5luTSA9lAgIHzgQ Uf/F65Ue58mQeYFd/5VPdtvdJoIcCAgT7GA8yMDI2MDEwODE2MDE0MVowfjB8BggrBgEF BQcwC4ZwcnN5bmM6Ly9ycGtpLnJpcGUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC9hNS8xY mMwZjktYmQ3Yy00ZjdhLWE0MDQtYTQzZmYyNWQ0NDdkLzEvZl9GNjVVZTU4bVFlWUZkXz VWUGR0dmRKb0ljLm1mdDCB0QQgO/APpgOd1ACqy0+8SO9WRmhqT9DddrWoyeDqQzL7bd8 CAghfBBR/VvKJSMgy8tQ0u0TV3g6hImAbBQICF7sYDzIwMjYwMTA4MTUwMTEwWjB+MHwG CCsGAQUFBzALhnByc3luYzovL3Jwa2kucmlwZS5uZXQvcmVwb3NpdG9yeS9ERUZBVUxUL zNhLzIxZmJjYS04MGUwLTRiOGMtODYyMi00ZTg2YWQ2NGY3NzQvMS9mMWJ5aVVqSU12TF VOTHRFMWQ0T29TSmdHd1UubWZ0MIHRBCBBea4tF3JE2mv6g3bWSBcOn1ws0Gw1yJcVg8W bXTnL3wICB4QEFH83coPXwjWpPce9K4MXsnSPKF/3AgIArBgPMjAyNjAxMDgyMDAxMTJa MH4wfAYIKwYBBQUHMAuGcHJzeW5jOi8vcnBraS5yaXBlLm5ldC9yZXBvc2l0b3J5L0RFR kFVTFQvOTIvMGZhZGZjLWY0OWItNDNlOC1iNjIxLTgzMWUyOTQ0ZjhmYS8xL2Z6ZHlnOW ZDTmFrOXg3MHJneGV5ZEk4b1hfYy5tZnQwgdEEIELKBg9HoXTnEUmtGFfoSdAVlwNlZSY G4PMsqnmb19iSAgIHzgQUf/yCWF32m3yUsWphky/8i24zUVYCAhOTGA8yMDI2MDEwODIz MDEwN1owfjB8BggrBgEFBQcwC4ZwcnN5bmM6Ly9ycGtpLnJpcGUubmV0L3JlcG9zaXRvc nkvREVGQVVMVC9lNC81MzFkMmItZTE3MC00OWE1LTg0MDQtOTJmNzNmNTZmYzYyLzEvZl 95Q1dGMzJtM3lVc1dwaGt5XzhpMjR6VVZZLm1mdDCB0QQgQxrKR0GQ5PFg8dSnJkqQgNX gqJJzOfyMohP7WhCW3Q8CAgqPBBR/a9GmsEYlxXHYMPh4scAjgkdAjAICBl8YDzIwMjYw MTA4MTcwMTAwWjB+MHwGCCsGAQUFBzALhnByc3luYzovL3Jwa2kucmlwZS5uZXQvcmVwb 3NpdG9yeS9ERUZBVUxULzQ4L2JjNjZkNy01N2FiLTQ3NWQtOTZiYS04OWI2YzMyMzE1Yz IvMS9mMnZScHJCR0pjVngyREQ0ZUxIQUk0SkhRSXcubWZ0MIHRBCBGDFHS/6xyUhCj8Zl 1U1kS9wP0gzCFREdGetcG3cLKMgICB84EFH8xKwnR9pDyVwC9Xc8HyRgMXpZjAgIA5BgP MjAyNjAxMDgyMTAxMzJaMH4wfAYIKwYBBQUHMAuGcHJzeW5jOi8vcnBraS5yaXBlLm5ld C9yZXBvc2l0b3J5L0RFRkFVTFQvYmMvMjlkYWM5LTlhMTUtNDY2MS1hZjc4LTE1MjJlMj k2NGZjZS8xL2Z6RXJDZEgya1BKWEFMMWR6d2ZKR0F4ZWxtTS5tZnQwgdEEIEoZODFpg9Q Alydw6JYDtmG9KPMwOH50lZUGXPzouWz/AgIHzgQUf1i8CGQS9NLFT6BwLZLOJUls5HkC AhU0GA8yMDI2MDEwODIzMDEwNlowfjB8BggrBgEFBQcwC4ZwcnN5bmM6Ly9ycGtpLnJpc GUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC9jYy81MzA5MzMtNTkxNS00ZmYyLWIxZjktNT AxMGQwNWY5OWE4LzEvZjFpOENHUVM5TkxGVDZCd0xaTE9KVWxzNUhrLm1mdDCB0QQgSpT Mk6O4NitlrWxkqmsUQoq7nb6KWB07+LKbVl4Ywz8CAgfOBBR/HVjWLd1+R68hlv11S7P/ JnmJKgICF7gYDzIwMjYwMTA4MTcwMTA1WjB+MHwGCCsGAQUFBzALhnByc3luYzovL3Jwa 2kucmlwZS5uZXQvcmVwb3NpdG9yeS9ERUZBVUxULzQ2LzI5MGE2MC03OTJmLTQ0NzUtYT lmNC1lM2I5ZTBiYWU2YWIvMS9meDFZMWkzZGZrZXZJWmI5ZFV1el95WjVpU28ubWZ0MIH RBCBUQl7ggC2lGraIQxbw+rir1iII4x8LWg5ys/sm6mvySQICB84EFH/WLkLAjhYBxFce DYijSaBQnepeAgITQxgPMjAyNjAxMDgxNzAxMTNaMH4wfAYIKwYBBQUHMAuGcHJzeW5jO i8vcnBraS5yaXBlLm5ldC9yZXBvc2l0b3J5L0RFRkFVTFQvNzgvYjkzNGVlLWM0YmEtND M5MS04MGIwLWU3NWE1ZWE4OWZkMS8xL2Y5WXVRc0NPRmdIRVZ4NE5pS05Kb0ZDZDZsNC5 tZnQwgdEEIFoFa8a2/eSlNTOkJE9qPttQcC6+bFpdBs9LUTO56tvYAgIHzgQUf+aLEiNL 1wNDAbyWsTiq4neGCj4CAgYnGA8yMDI2MDEwODIwMDEwN1owfjB8BggrBgEFBQcwC4Zwc nN5bmM6Ly9ycGtpLnJpcGUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC84Yi80YTExMTEtOG YzYy00ZWRmLWI3N2MtMmZhMjYzMWJjMzFjLzEvZi1hTEVpTkwxd05EQWJ5V3NUaXE0bmV HQ2o0Lm1mdDCB0QQgXnHaL4UZ+iFqZDwh8JKjKcmmeBOmCNz543yoQiwlMn8CAgfOBBR/ qBajM40ydBzU//j0ndssyDj9xQICBSsYDzIwMjYwMTA4MTkwMjAxWjB+MHwGCCsGAQUFB zALhnByc3luYzovL3Jwa2kucmlwZS5uZXQvcmVwb3NpdG9yeS9ERUZBVUxULzUzL2E0NT I4YS05MGU2LTRkOTEtYTUyYy1mMDcxN2VhNDg1YzYvMS9mNmdXb3pPTk1uUWMxUF80OUo zYkxNZzRfY1UubWZ0MIHRBCBlBtj8cbMdXpx/CKEWYwvo+YZAZmIOEaiK+HcvU9/M3AIC CBgEFH8WgCjsDatmimfVv29TWMqr4zeoAgIMKhgPMjAyNjAxMDgyMTAxMjhaMH4wfAYIK wYBBQUHMAuGcHJzeW5jOi8vcnBraS5yaXBlLm5ldC9yZXBvc2l0b3J5L0RFRkFVTFQvY2 MvYjE1Mjg2LWZkNGQtNDlmZS1hNjllLTdmYWRmNTBhMmUzNy8xL2Z4YUFLT3dOcTJhS1o 5V19iMU5ZeXF2ak42Zy5tZnQwgdEEIGd7MqCU/xUEGZqKrH1XkqfN3RqCtG/L1V9L8DQY A1S1AgIHzgQUf7UOfTt/0olM+3DklGCLMgzCFcECAgDQGA8yMDI2MDEwODE3MDEzNFowf jB8BggrBgEFBQcwC4ZwcnN5bmM6Ly9ycGtpLnJpcGUubmV0L3JlcG9zaXRvcnkvREVGQV VMVC85Ni9hOTE4Y2ItMjA0NC00ZjFjLTk3MDAtOTM2MDFhMzRmNjJmLzEvZjdVT2ZUdF8 wb2xNLTNEa2xHQ0xNZ3pDRmNFLm1mdDCB0QQgbJNFg5mgBHtCC8IDP0ZxfJZsrSOBp8KO JRHb520LtpECAgfOBBR/dzTf6hIGV0EuqGfdvHuE0TK/eAICEGkYDzIwMjYwMTA4MTcwM TIxWjB+MHwGCCsGAQUFBzALhnByc3luYzovL3Jwa2kucmlwZS5uZXQvcmVwb3NpdG9yeS 9ERUZBVUxULzdlLzY4MDMyNC1lZTFmLTQwZjItODhkZi0xOTY5MzE5NjJkM2MvMS9mM2M wMy1vU0JsZEJMcWhuM2J4N2hORXl2M2cubWZ0MIHRBCBt7xqIdeziNrWHHxep3FfwH0OP q5nSVE8fGBb8WLTWAwICB4QEFH8UzoEDt4XzUEvEsy8fTJtwzj9/AgIQdxgPMjAyNjAxM DgxOTAxMDFaMH4wfAYIKwYBBQUHMAuGcHJzeW5jOi8vcnBraS5yaXBlLm5ldC9yZXBvc2 l0b3J5L0RFRkFVTFQvYjYvZjY5ZGJlLWUwNzUtNDQzOC1iNTNiLWY2MTYwZmExZmIwMi8 xL2Z4VE9nUU8zaGZOUVM4U3pMeDlNbTNET1AzOC5tZnQwgdEEIG6nUCjrFXJF2aB9FoMk 5WimDuz4GdU4rL+jK6x7dQe8AgIHzgQUf/sBFcSs3dG0rcQHN4Byas/AGvkCAgzEGA8yM DI2MDEwODE5MDExMVowfjB8BggrBgEFBQcwC4ZwcnN5bmM6Ly9ycGtpLnJpcGUubmV0L3 JlcG9zaXRvcnkvREVGQVVMVC82MS81MjY4ZmMtY2ZlZS00YWE4LTk3YmYtY2JlMDIwNjY 1ZWZlLzEvZl9zQkZjU3MzZEcwcmNRSE40Qnlhc19BR3ZrLm1mdDCB0QQgb+o8m06Q9iU6 EnPhdWx7hQf34aX7u8+BtkN6WDmO8JcCAgfOBBR/tD3iN/0LaihziSMJIdJaLC7RqAICF 00YDzIwMjYwMTA4MjAwMTI1WjB+MHwGCCsGAQUFBzALhnByc3luYzovL3Jwa2kucmlwZS 5uZXQvcmVwb3NpdG9yeS9ERUZBVUxULzA5L2Q0ZDEyYS1hYjRlLTRkYmEtOTVkZS1iYzY zNzEzMGRlNmUvMS9mN1E5NGpmOUMyb29jNGtqQ1NIU1dpd3UwYWcubWZ0MIHRBCBzrSMA 19fNkYVSPFrfNwuIQW6pxyA/3xBmt+lL5h5xdAICB84EFH+F6ZA1Q5fjbAypA6DGIMdwn v3NAgID6hgPMjAyNjAxMDgyMzAyMDhaMH4wfAYIKwYBBQUHMAuGcHJzeW5jOi8vcnBraS 5yaXBlLm5ldC9yZXBvc2l0b3J5L0RFRkFVTFQvNWUvNGFlMTc1LTU1ZDAtNDg0ZC04ZDE xLThjOWQ1ODIzYmFkOS8xL2Y0WHBrRFZEbC1Oc0RLa0RvTVlneDNDZV9jMC5tZnQwgdEE IHWhirnnIDJ5n+WI2Xvk54oI9JbIb2bvBy3fY7npA/trAgIHzgQUfzE2D/wa/V8dpm2BQ E5GY1EtSWcCAhVEGA8yMDI2MDEwODE4MDE1MVowfjB8BggrBgEFBQcwC4ZwcnN5bmM6Ly 9ycGtpLnJpcGUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC8yZC9mZWY1ZGQtMzhlZS00YmM 1LTgyZmYtNTg0ZDc4YTI1ZjhjLzEvZnpFMkRfd2FfVjhkcG0yQlFFNUdZMUV0U1djLm1m dDCB0QQge+535dV/T4fBendUeAcDJiibStHT0H8cdANzm3c00sQCAgeEBBR/iyGDWJg6f XolOKnam6HzSU1xqwICAeAYDzIwMjYwMTA4MTYwMTA3WjB+MHwGCCsGAQUFBzALhnByc3 luYzovL3Jwa2kucmlwZS5uZXQvcmVwb3NpdG9yeS9ERUZBVUxUL2Q5Lzc2Y2QwMy1lYWE yLTQ5NjUtOTRlZi05OGRiYjY0MDJjZGQvMS9mNHNoZzFpWU9uMTZKVGlwMnB1aDgwbE5j YXMubWZ0MIHRBCCASGa4GEb+lTv/4fJr94UgLuaT+ISjkIKKdEKkHovxHwICB84EFH/uP zggc/LD5PzP/KOExbDNgmwmAgIDjBgPMjAyNjAxMDgxNzAxMTdaMH4wfAYIKwYBBQUHMA uGcHJzeW5jOi8vcnBraS5yaXBlLm5ldC9yZXBvc2l0b3J5L0RFRkFVTFQvYTcvOGNjZWJ mLWY5ZmEtNGM0Ni1hZWU4LWNjYmZhNzM0MjRhNy8xL2YtNF9PQ0J6OHNQa19NXzhvNFRG c00yQ2JDWS5tZnQwgdEEIIEq59M4+de5vhL+AIB9ZhUCn4d3FMAGscEdEk2Nqb90AgIHz gQUfxFBauOSnfN79mpFnNOspjiR6UYCAhe3GA8yMDI2MDEwODIyMDEyOFowfjB8BggrBg EFBQcwC4ZwcnN5bmM6Ly9ycGtpLnJpcGUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC8yZi8 2YjIyZTgtM2RjZC00NGRkLTk1MTQtNjc1NmY3YjBjMGRiLzEvZnhGQmF1T1NuZk43OW1w Rm5OT3NwamlSNlVZLm1mdDCB0QQgg/TeGB1EpvVQgaiS8VooOlY3CODqmdkfZl+6QeaG9 IcCAgeEBBR/F7b5MjmdWFCT0YczlOv+Gyn5jAICDzsYDzIwMjYwMTA4MTYwMTUzWjB+MH wGCCsGAQUFBzALhnByc3luYzovL3Jwa2kucmlwZS5uZXQvcmVwb3NpdG9yeS9ERUZBVUx ULzMxL2NjMDIwMC1iYjJjLTQ1ZjYtYWM3NS04Mjc1NzdkZjhlZGMvMS9meGUyLVRJNW5W aFFrOUdITTVUcl9oc3AtWXcubWZ0MIHRBCCGMyVTGVLFMFffgmebFSD+ivU3zQMIPxNpC ZMyZaCMUAICB84EFH8+CHSJ7iOpQk1T+sIW7kuOASgOAgIXThgPMjAyNjAxMDgyMDAxMz RaMH4wfAYIKwYBBQUHMAuGcHJzeW5jOi8vcnBraS5yaXBlLm5ldC9yZXBvc2l0b3J5L0R FRkFVTFQvYzYvYzJjOTlkLWNmOTEtNGRmYi05NGRlLWE3YzYzZDU2MmU1Ni8xL2Z6NElk SW51STZsQ1RWUDZ3aGJ1UzQ0QktBNC5tZnQwgdEEII5DEJkg54e32y2/B1WOyDyahzCEf aERNpKcSA9PZdtHAgIHzgQUf+/r0V+8ZRSHrK9nQk9Hg9Q+tCACAhe3GA8yMDI2MDEwOD IxMDIwNFowfjB8BggrBgEFBQcwC4ZwcnN5bmM6Ly9ycGtpLnJpcGUubmV0L3JlcG9zaXR vcnkvREVGQVVMVC85YS8yNmVmNjMtYjcyZi00YjNjLThkZmMtMmJjODQ1MTkyMjdhLzEv Zi1fcjBWLThaUlNIcks5blFrOUhnOVEtdENBLm1mdDCB0QQgj2n88kmDKSPaKWTt2cg1P qjq2c7bnts/AV3HJWXqqjkCAgeEBBR/mRjKtvHzXvG15YPLKDnpt0ixWAICFI8YDzIwMj YwMTA4MTkwMTU0WjB+MHwGCCsGAQUFBzALhnByc3luYzovL3Jwa2kucmlwZS5uZXQvcmV wb3NpdG9yeS9ERUZBVUxULzI2L2RmODJmYS0xMThkLTQyMTktYmExNi0xYTk2ODNjOWQ2 Y2IvMS9mNWtZeXJieDgxN3h0ZVdEeXlnNTZiZElzVmcubWZ0MIHRBCCSkQuN9PCn151nB GBrBmHej5rw8dfvnsEEW+nAvyfMjgICB4QEFH9R3x306IZ+QeXn+S3n+dH6DBVNAgIMoB gPMjAyNjAxMDgyMTAxMTlaMH4wfAYIKwYBBQUHMAuGcHJzeW5jOi8vcnBraS5yaXBlLm5 ldC9yZXBvc2l0b3J5L0RFRkFVTFQvZmEvNWU3MzFmLTUyOGItNGUwMi1hZDY4LTZkOTAz NWFmMTUzNS8xL2YxSGZIZlRvaG41QjVlZjVMZWY1MGZvTUZVMC5tZnQwgdEEIJdpko2c2 K9OwfCs7d25CWOpQ5QfTp8v4Ini0HEfstxvAgIHhAQUfwdXwzGYHgQrdHE3NSfQ9koTVr QCAhNeGA8yMDI2MDEwODE5MDEzM1owfjB8BggrBgEFBQcwC4ZwcnN5bmM6Ly9ycGtpLnJ pcGUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC83OC80Zjk2ZjktNTY5Zi00MzNjLWI5YTgt NmEyNjEyZDQwZjUwLzEvZndkWHd6R1lIZ1FyZEhFM05TZlE5a29UVnJRLm1mdDCB0QQgn bFHY5o1eFI/JXrcZzLyJ1TdH3Z3csXzRZinE0Y5cCsCAgfOBBR/TVkcI60saUd9f3odTO jrzulZbAICBhQYDzIwMjYwMTA4MTUwMTM1WjB+MHwGCCsGAQUFBzALhnByc3luYzovL3J wa2kucmlwZS5uZXQvcmVwb3NpdG9yeS9ERUZBVUxULzNlLzBkNjdhMi1iYzM2LTRiOTMt YjYwNC1kNGY1YzkyZDkwOTUvMS9mMDFaSENPdExHbEhmWDk2SFV6bzY4N3BXV3cubWZ0M IHRBCCnjXO+nhFRAnet66plShQY9ijeKIn2Jjn8FzzN7RbFMwICCBgEFH8DofjDNP2/S3 je8MWS/wSQ3fSwAgIXcxgPMjAyNjAxMDgyMTAyMDBaMH4wfAYIKwYBBQUHMAuGcHJzeW5 jOi8vcnBraS5yaXBlLm5ldC9yZXBvc2l0b3J5L0RFRkFVTFQvNjYvM2ZlMWEwLWM2ZmQt NGJjNC1hYWUxLTllZTAwNjk0MmI0Yi8xL2Z3T2gtTU0wX2I5TGVON3d4WkxfQkpEZDlMQ S5tZnQwgdEEILygQ8fZPYY0mQD8zM4wMnIkkXbFYZks+kKXtCavjvupAgIHzgQUf0OdlC Qm/Gc7J5zJirNf29fql/UCAhNTGA8yMDI2MDEwODE5MDE1N1owfjB8BggrBgEFBQcwC4Z wcnN5bmM6Ly9ycGtpLnJpcGUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC8yYS82OWEwOWYt NTgwOS00NjU2LWIzNTUtMTQ2ZjI1NGFjMTMxLzEvZjBPZGxDUW1fR2M3SjV6SmlyTmYyO WZxbF9VLm1mdDCB0QQgvgX58HkrAY/LuflVMbJZ7LzrWFSoZlhjbgUohc4JjkACAgfOBB R/QtJ8IdqGx+n79Erg5WyY89L4CwICD1gYDzIwMjYwMTA4MTYwMjAzWjB+MHwGCCsGAQU FBzALhnByc3luYzovL3Jwa2kucmlwZS5uZXQvcmVwb3NpdG9yeS9ERUZBVUxUL2E5Lzk4 YjAyNC05ZDhmLTQ4NjktYTJhOS0wYWZiN2MzZmJmMzAvMS9mMExTZkNIYWhzZnAtX1JLN E9Wc21QUFMtQXMubWZ0MIHRBCC+S/81Xud1PzUBFp/H1MiaahJK+jQve1DYEWEVia39uA ICB84EFH/JVqUrc1BKTx/zRUcZkpen9d6dAgILbhgPMjAyNjAxMDgxNzAxMDlaMH4wfAY IKwYBBQUHMAuGcHJzeW5jOi8vcnBraS5yaXBlLm5ldC9yZXBvc2l0b3J5L0RFRkFVTFQv YWEvNzFhYjY5LTY5NjUtNGI3MC05NjhkLWJiNTdhNGVmNzE1My8xL2Y4bFdwU3R6VUVwU EhfTkZSeG1TbDZmMTNwMC5tZnQwgdEEIL9qHDGaKh1R04cdIJLYSjtKeclEypWTBTqgxV 51LzV0AgIIpwQUf1FerQle7ZrEyrxatK0LWGfZ8BsCAhfRGA8yMDI2MDEwODIzMDE0OVo wfjB8BggrBgEFBQcwC4ZwcnN5bmM6Ly9ycGtpLnJpcGUubmV0L3JlcG9zaXRvcnkvREVG QVVMVC9hNy81YzJhNTktNjAyNS00MDBlLWFiMjgtZjBhNjI0ZDQwOTEyLzEvZjFGZXJRb GU3WnJFeXJ4YXRLMExXR2ZaOEJzLm1mdDCB0QQgv39HKTjopic782oac6tVyAIMW0PaCG eYBa2nvVCuDKYCAggYBBR/4OdZNU6DzBkyA4EQneItoPGnAAICF8EYDzIwMjYwMTA4MTg wMTUyWjB+MHwGCCsGAQUFBzALhnByc3luYzovL3Jwa2kucmlwZS5uZXQvcmVwb3NpdG9y eS9ERUZBVUxULzRjLzBjNzI0My0xZmZiLTQ5ZDItYjVjMS1iNDAyZThhMWQ5MzQvMS9mL URuV1RWT2c4d1pNZ09CRUozaUxhRHhwd0EubWZ0MIHRBCC/mDUwr8XbN8QR3vi4bpdyNf prvcn9Z/t23XZndp12IQICB4QEFH9za4igJATUMEvdrV/1UEpoM+e3AgIXtxgPMjAyNjA xMDgxOTAxMjVaMH4wfAYIKwYBBQUHMAuGcHJzeW5jOi8vcnBraS5yaXBlLm5ldC9yZXBv c2l0b3J5L0RFRkFVTFQvOTkvMGYyNWNlLWI5NzctNDg1My05ZWMzLTllNTZjYjU0ZmVmN y8xL2YzTnJpS0FrQk5Rd1M5MnRYX1ZRU21nejU3Yy5tZnQwgdEEIMzFRfxAeVWe8poS1U kK08BGZ3h9a4zX7Upp1hcBuxHYAgIIXwQUfyuobfeHiI9vhZKoBqb/6jBGwHoCAhe/GA8 yMDI2MDEwODIwMDExOFowfjB8BggrBgEFBQcwC4ZwcnN5bmM6Ly9ycGtpLnJpcGUubmV0 L3JlcG9zaXRvcnkvREVGQVVMVC82MC81ZTY3ODYtNjM3Ny00MjI0LWJhMDYtZGM0NzY5Z WZmMWY1LzEvZnl1b2JmZUhpSTl2aFpLb0JxYl82akJHd0hvLm1mdDCB0QQgzZTr9egKcv XVZQaiAvwJv7MZS6kvoBECP7s1InpsFaICAgfOBBR/0YpqSZEMwzHckRFK5ZtxhdXzDQI CF7wYDzIwMjYwMTA4MTkwMjAzWjB+MHwGCCsGAQUFBzALhnByc3luYzovL3Jwa2kucmlw ZS5uZXQvcmVwb3NpdG9yeS9ERUZBVUxUL2JhLzA5NDdmMi0yMmNhLTQ3Y2ItODlhZC0zZ TUwYTVmMDE5OTgvMS9mOUdLYWttUkRNTXgzSkVSU3VXYmNZWFY4dzAubWZ0MIHRBCDOHe e/kR7uuSXgV8NAdqOlT3rD5l6+8gKpPOsQAIockAICB84EFH9K5X7m4KnFEB/BSoelM0F Qu6tGAgIHCxgPMjAyNjAxMDgyMTAxNThaMH4wfAYIKwYBBQUHMAuGcHJzeW5jOi8vcnBr aS5yaXBlLm5ldC9yZXBvc2l0b3J5L0RFRkFVTFQvMmIvMTFmYTQ0LTg4NzktNGQxOS1iN DY4LTViNWQ5OGY1MzYxZS8xL2YwcmxmdWJncWNVUUg4RktoNlV6UVZDN3EwWS5tZnQwgd EEINQB8UTqGOQVuKymbJF9l032P1avGA5HYUZOzZBlJUOpAgIHzgQUf2qOXVXCSYqCY2+ Z+PyeMZ4Hdx4CAhC8GA8yMDI2MDEwODIxMDE1NlowfjB8BggrBgEFBQcwC4ZwcnN5bmM6 Ly9ycGtpLnJpcGUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC83NC8yN2ZjZTEtMTFjZS00Y TMyLWE2NDktZTA3NmI1MTcyMWFkLzEvZjJxT1hWWENTWXFDWTItWi1QeWVNWjRIZHg0Lm 1mdDCB0QQg1SElzrrX16Q+poOs2aDApHsXvKrqfpGpM/emj5l2WlUCAgfOBBR/HQ4ymL7 Tp/Ofs7JE7ZGL9sTXvwICFZEYDzIwMjYwMTA4MjAwMTMyWjB+MHwGCCsGAQUFBzALhnBy c3luYzovL3Jwa2kucmlwZS5uZXQvcmVwb3NpdG9yeS9ERUZBVUxUL2Y3L2U2NTA2ZS03N jg1LTQ4ZTctYTU4My0yMWFmM2RlZThlZTkvMS9meDBPTXBpLTA2ZnpuN095Uk8yUmlfYk UxNzgubWZ0MIHRBCDZ3cCnM1f1TWqRljN/6JJMPxp4i98OoQ/iByRh11U2bAICB84EFH8 11a5Bf0XuhQXXbOqhs0xFg5SgAgIQlRgPMjAyNjAxMDgxNzAxMDVaMH4wfAYIKwYBBQUH MAuGcHJzeW5jOi8vcnBraS5yaXBlLm5ldC9yZXBvc2l0b3J5L0RFRkFVTFQvZTYvYzU0N jdiLTM5NjItNGI3NC1hZTBkLTM0NDczYmM5MWQ4MC8xL2Z6WFZya0ZfUmU2RkJkZHM2cU d6VEVXRGxLQS5tZnQwgdEEINySvZqi93Y/d9zNNx6gq0dxUhmQuVj1t4LKdJ+XtT5eAgI HhAQUf35evW+kacXjcL/BBsTUqtHh25QCAhAjGA8yMDI2MDEwODIxMDExNFowfjB8Bggr BgEFBQcwC4ZwcnN5bmM6Ly9ycGtpLnJpcGUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC8yM y9jM2U4ZWQtNTk3YS00ODVhLTk0YTMtOTgyY2ZiMzU5YWVlLzEvZjM1ZXZXLWthY1hqY0 xfQkJzVFVxdEhoMjVRLm1mdDCB0QQg4BXwVc2t3CYGZHmeWUo+F2MGbMmIsMpazuR20W1 ttMgCAgfOBBR/m0z9ybDZ48MeDruB5vGxy73J5AICDZsYDzIwMjYwMTA4MjMwMTAwWjB+ MHwGCCsGAQUFBzALhnByc3luYzovL3Jwa2kucmlwZS5uZXQvcmVwb3NpdG9yeS9ERUZBV UxULzViLzgyNDZlYi04NDY5LTQyZGYtYTA4Zi05MGM0MjFmNTVhZGIvMS9mNXRNX2Ntdz JlUERIZzY3Z2VieHNjdTl5ZVEubWZ0MIHRBCDju+/+aQNhL3xABcZCmQwPlJsSt9PVczu iI1LEhh0V9gICB4QEFH8pZlevjQDCX9dfVuzIoos1FQV1AgIQ8BgPMjAyNjAxMDgyMjAx MzJaMH4wfAYIKwYBBQUHMAuGcHJzeW5jOi8vcnBraS5yaXBlLm5ldC9yZXBvc2l0b3J5L 0RFRkFVTFQvZDAvZTgwYjMzLTNiZWUtNDZlYy1iMzVkLWJhZjk1YTUwNmQxOS8xL2Z5bG 1WNi1OQU1KZjExOVc3TWlpaXpVVkJYVS5tZnQwgdEEIOhXNpfSOMASGctVcKbvN/OB6ql 5D1pQacHPcCY/ZHiyAgIIGAQUf/G4HP5quxGOl+AyW2Yur5hPL2oCAg4nGA8yMDI2MDEw ODE4MDExNFowfjB8BggrBgEFBQcwC4ZwcnN5bmM6Ly9ycGtpLnJpcGUubmV0L3JlcG9za XRvcnkvREVGQVVMVC83NS8xODZhMTgtNWQ3Zi00M2VkLWIwNmEtY2VhN2ViMzUwNTM3Lz EvZl9HNEhQNXF1eEdPbC1BeVcyWXVyNWhQTDJvLm1mdDCB0QQg7ofzO61BsU/Hy5uia4R YPFpIBkpqq5VsbWs8rtg3Ff8CAgfOBBR/F4+vZAHi83FuMXZFad9zHfWPIgICEi4YDzIw MjYwMTA4MTUwMTA4WjB+MHwGCCsGAQUFBzALhnByc3luYzovL3Jwa2kucmlwZS5uZXQvc mVwb3NpdG9yeS9ERUZBVUxULzY2LzFiNzk2OC1jYTRkLTQ1ZjQtYjY3MS0yZTdmNzg0OD ljZDMvMS9meGVQcjJRQjR2TnhiakYyUlduZmN4MzFqeUkubWZ0MIHRBCDu2djmK3gbyPB qskEsLEV+na+Ot0G2TJurk/7Nc14YQQICB84EFH8km5VEYgaD+Us4inVRpopkk+0SAgID 6xgPMjAyNjAxMDgxODAxNDBaMH4wfAYIKwYBBQUHMAuGcHJzeW5jOi8vcnBraS5yaXBlL m5ldC9yZXBvc2l0b3J5L0RFRkFVTFQvOGIvN2FhMDRlLTQ4MDctNDk4OC05MTAzLTg0Mj M5N2UzMDY0My8xL2Z5U2JsVVJpQm9QNVN6aUtkVkdtaW1TVDdSSS5tZnQ=

Producing a FQDN Snapshot The following terminal transcript illustrates how one could prepare a Prefetch Response for rpki.ripe.net using common command line utilities. $ cd /var/cache/rpki-client/rpki.ripe.net/ $ export TMP="$(mktemp)" $ find . -type f | xargs -r cat -- | gzip > "${TMP}" $ mv "${TMP}" /var/www/htdocs/erik/snapshot/rpki.ripe.net $ unset TMP $ cd /var/www/htdocs/erik/snapshot/ $ ls -nl rpki.ripe.net -rw-r--r-- 1 1000 0 98392415 Dec 12 15:59 rpki.ripe.net $ file rpki.ripe.net rpki.ripe.net: gzip compressed data, from Unix $ gzcat rpki.ripe.net | openssl asn1parse -inform DER | grep -c :d=0 109880

Producing a Time-Trimmed Tail Queue The following terminal transcript is an overly simplistic illustration how one could prepare the 5min and 10min time-trimmed tail queue Prefetch Responses using common command line utilities. $ cd /var/cache/rpki-client/ $ export TMP="$(mktemp)" $ find * -mmin -5 -type f | xargs -r cat -- | gzip > "${TMP}" $ mv "${TMP}" /var/www/htdocs/erik/tail/5min $ find * -mmin -10 -type f | xargs -r cat -- | gzip > "${TMP}" $ mv "${TMP}" /var/www/htdocs/erik/tail/10min $ unset TMP $ cd /var/www/htdocs/erik/tail/ $ ls -nl 10min 5min -rw-r--r-- 1 1000 0 946037 Dec 12 20:02 10min -rw-r--r-- 1 1000 0 642883 Dec 12 20:02 5min $ gzcat 5min | openssl asn1parse -inform DER | grep -c :d=0 206 $ gzcat 10min | openssl asn1parse -inform DER | grep -c :d=0 398

Acknowledgements The authors wish to thank , , , , , , and , for the lovely conversations that led to this proposal. The authors wish to thank and for their review of the ASN.1 notation. This protocol is named after Erik Bais, who passed away in 2024, as a small token of appreciation for his friendship.