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 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 Index calculated from the locally cached objects). With the ErikIndex in hand, the client can determine which ErikPartition are missing and fetch accordingly. 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 In this synchronization protocol the signal layer makes use of DER-encoded messages . Design note: DER encoding was selected for its canonical properties and because RPKI cache implementations already support ASN.1 encoding. 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) } ; EncapsulatedContentInfo ::= SEQUENCE { eContentType CONTENT-TYPE.&id({ContentSet}), eContent [0] EXPLICIT OCTET STRING (CONTAINING CONTENT-TYPE.&Type({ContentSet}{@eContentType})) OPTIONAL } 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 The content of an Erik object is an instance of EncapsulatedContentInfo.

eContentType The eContentType is an OID specifying the type of payload in this object.

eContent The eContent is the payload of the Erik object encapsulated in an OCTET STRING.

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 this ErikIndex. The field's value roughly indicates 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 . Design note: using the most recent partitionTime, rather than the local system's notion of "now", helps reduce churn in distributed systems.

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 a subset of manifest objects available under a given FQDN. Each ErikPartition is an ordered listing of the manifest objects' hashes, manifestNumber values, thisUpdate values, and their end-entity certificates' SIA extension values.

The version number of the ErikPartition object MUST be 0.

The partitionTime is the most recent thisUpdate value among the manifests contained within this ErikPartition. The field's value roughly indicates 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 . Design note: using the most recent manifest thisUpdate value, rather than the local system's notion of "now", helps reduce churn in distributed systems.

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 fetching an ErikIndex, which is 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.

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

The URIs to fetch ErikIndex objects can be constructed using the following Well-Known URI template with the erik keyword as suffix and the FQDN as parameter: https://{relay_host}/.well-known/erik/index/{FQDN}. For 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.

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 (). Design notes: a decision must be made on a deterministic "manifest-to-partition" assignment scheme. Job's proof-of-concept relay (see ) uses the first few octets of the the Manifest's AKI as a stable partition assignment scheme. Other strategies could be to assign manifests to ErikPartitions based on the "hour-of-day" of the CMS signing timestamp, or the first few octets of the SHA-256 of the manifest object.

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.

Open Questions

Which of the possible deterministic manifest-to-partition assignment strategies yield the best results? AKI?
Are deterministic and cheap Snapshots possible? If so, what is the best archive format for Snapshots? The ustar/gzip combo might not easily yield deterministic results across different implementations.
Is the concept of Differentials/Deltas needed in Erik Synchronization?
What will be the upper bound for the number of partitions? (ub-Partitions)

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, therefore it is RECOMMENDED for clients and relays to offer support for compressed content coding, as described in . 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.

An URI Suffix in the Well-Known URIs registry specific to Erik synchronization will be requested. See https://github.com/protocol-registries/well-known-uris/issues/67 for the request. The proposed suffix is erik.

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] 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

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". 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, Montreal, Osaka, São Paulo, 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

An experimental Erik static content generator was developed by Job Snijders in the form of using C.

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/rpki.ripe.net. MIIoSAYLKoZIhvcNAQkQATeggig3BIIoMzCCKC8WDXJwa2kucmlwZS5uZXQYDzIwMjUxM jAyMTA0OTQ4WgYJYIZIAWUDBAIBMIIoADAmBCDLPQS+BEMR5/k+VqCStUokMYXOriW2Du YPTXhGuD3q3wICPZYwJgQgwlY1EG7f5W2l7esjg8zvh4OSH3mEvf0R0Vk0Nu/FNvkCAkW QMCYEIJ5sldkWmXH8WqdwcqCjWgCAHGO+csZ1Z0M/DLSRlGWbAgI+ZTAmBCDQMhQDUY0A tI0yab95wpOekpHO0ohKIjYOTTtWQ5MjVwICRl0wJgQgCSczNOep4UZs1zgKjgEUfy4n+ Lt2q/0ae3MXxayJqSACAjzNMCYEICScxxhNA422P1ixrpjqeXBxMu4aaVzsJRswbr/4jp rrAgJL8TAmBCD89DufanWBskoIDl/9JHi9Si1nlVHpL1voMzTRfVi5tQICQMgwJgQgUQi roMWezWX3bZfmj6mZ9seGDNoYUSe3TGs8pu0kp1MCAki/MCYEIIC3F0uA3RvYCLXNsnxf LgfwBadm19t/a+zdn2kAXMgEAgJKWDAmBCA71fzRZoa5ZNS7YZqFu1K/ce5NXUdEwkGSM 7hGlgSS/wICSlkwJgQgLINxwbUPOzmYs57mJRpwL6LRnnhIoAbaKIIj95HG2eMCAjpnMC YEIPJOBKm1l6lSmeSA08MIQ/F5sKW2em1QlBmS39ZSIUNeAgJHKDAmBCD4ud337DM7zbD hUyvk+lcH7DM3ZDP+41UXnhSUgYqg/wICOZ0wJgQgk4IS/59oVYy6u2snvNBnjnxJVm/r eqJJoc1evuvxfHICAkpZMCYEICpdbc0rxiH+33FC3wZV6EuGPjDKy6nYqeDIDA0dRpUpA gJDKzAmBCBREWPGHXwjb4L5wA4+WfFwpZw5WHYu/esm5gvZqMh/swICPMwwJgQg9RbRtS WscmO1H+9birDeQPqjjhllFte2FHajdOj1A+cCAkJhMCYEIMCCJYNoCiS3HXHDtq4xGp8 uYDE/xz4bbAO4bwSnnLyEAgJFkTAmBCCEgZwchVDMZS/pzvUkGov3o0+39BkKcJPunwHV sq476wICQZQwJgQgBGIZWDkNQpZkOa0eD6BSwkvolP/AJw/A311oyvOGEXUCAkP4MCYEI FOtigW3sRv7apfmjXMU/98TtDj6yMc/RYdpJm0Fd8vbAgIxpDAmBCBhDapgT42X+yfsn9 esviI99SSyYOIP8Rbx9n5G87vNKwICRY8wJgQg1pW35b6HYu+U17pSH5gUt0Osrbz+Tg5 qwNZlezvgZfACAkjBMCYEIEkKKE1Ic+kEV7dH5tnsn6byIHXVRnGY7te0NtXf7qEwAgJP ITAmBCCxmBlkbyflk0lOVmagNnZKoiZTm4EVQt4iN4J6jBxInwICNmowJgQgkdhrbw7Uz A8SbEnZNsbEvdkCPxqEEUtiSZSzeRCP0DcCAky7MCYEILO3T1eY7WHJRQmkheD8FtOXlD 5zgH/U2vvWU3S8WnQlAgJOUTAmBCC6RLBWGgEhRVycwJgaUhAGs6SWgkz+Tfn1LADn8qJ A/AICQ/kwJgQgnstvn8RQM++YOJ+Hc+Tq2VLaID/7jyQRm2nkcWxqcC8CAkskMCYEILT2 DFwyJ43PzJqGR88ETRLfH1W2uhwAJ0DeIHmC2EzPAgJGWTAmBCCYG3Ver1Z0ilotL9Tnz 5MYmCXK2+E6hX8X8wsRB0DZ0QICSYswJgQgRozFaBkI7cN7wmpk5NqiQtG+KC5IIPaUnF UeQrIb4GkCAkcoMCYEIPBjnA3JhaiTdEW+OIXToWiziXHNmrC1kSnxjkiZ84yyAgJGXTA mBCAQruf4rgz2DLzWXzUmZkpuaHyGiQcCUR2zAsrBDsyshwICOmYwJgQgUsVU5FeHifx6 XmEcOYlB11aFikVQsRgm/CXu6L7Ri+ACAjpnMCYEIDU3pHZL5KsxrSh+pWu8xz/iU3NeQ HDD1gaIKLDu71etAgJP6zAmBCByJmxkmOh2xM2iulqF+bgkL7B2GZoBI5tGa4qnQ1Qs6Q ICPM0wJgQgDAZIYMMIyM7EVTeqHnFehbDl2dfsd2JeSAvze8h1DDsCAkGSMCYEIASg5TH iOIsCA4TIyvP/3VDYvxa1I7jipkXj+FFufc8nAgJBlTAmBCAJlttvcW33qcB+SE96uC4J CNtv6YrW7fLwlkND49Ch6gICTyEwJgQgjkPin8Zx3xRQvVTLDI7PiZgvThdVmltUv8pCX mkDCFwCAjs1MCYEIKqwbw3roJ9qE95izXmO1zDVc9KZb5XdGksdNlv1MwvrAgJXGDAmBC BYBVT6y9cqNSC+5Gu000vkMpZvvLMgTuzJ/BJMEqgYRQICPKUwJgQgaPL69AnEywa8gW1 DRyIFBiMqKxKvhXExwGwiVYy3ePkCAj2VMCYEIID68c3di63IqfsC6OqD9edaXdzxZDid pT8vW4DhpMuEAgI6aDAmBCBumuNw5h1oDRKWurgalA9DG/aJvhEZoeAQwg6lRnyG/QICO AQwJgQgt3xwRTIgnW8O+ULQTPI7z2LDgM03FxfRQ4lHcotEMnICAkMtMCYEIIzRCANsKd u1W8AOuZ8vWBZs2sJcilWELvU4Kr6v42zdAgJL8TAmBCDDvzk9JcpGPTZbaknn1VgC8sG i75zjgRa7xAmpDGUSFAICRlswJgQgrDIilsWciW7KPuTh3kkHass55OEFSZLxU8V9Weov +uECAj5hMCYEIEagNMKITBGhdaxwyQEpG7Hyt/+wZ5vV6lvDHPqJgEFsAgJIvzAmBCANS W1K5fZD6T2mMPJ34pA5tyIerfepicF4KbR3i/biDAICOmgwJgQg9QTrVWSzgsLTZJ+kfr 2hTwfHwFtyk1MY5eJiQIj64tcCAki/MCYEIEtgvqig8o3dAmn8aP2Fifg59dQ0L/I97is 3IJLFz4ciAgI8zDAmBCBF9ZmDmwaRiOJAcKhszUoPPWBgCSOfwl/7TXxYAy84LgICSlkw JgQgPSJ4YIZUPV1s+iXFz31lWP58iJBwBfzeSiRhKkDCj1cCAj2ZMCYEIAQZ52tjUKFcd w6CZL0BatjqxYXeEzgkS0ctra53vpilAgJFkTAmBCBW99Spa4aD/b15yDxn+NrCTd05ZW fvAEJdJsCSCIzReQICRMQwJgQgkFEctwlUTy0/rLJ9HFlSIfmm4u1SfH5byNxTIdq0ba8 CAkP3MCYEIKEn/SEG+NrbSXVVszg1OUqJhp/7yxQ7XaXqSs5ntoiDAgI/MTAmBCC7UoWk S9KK+0xMKbMN90X74GTbZ8FGhBmOFgoDJsH5fAICPMowJgQgBeKDMjOj6m0Db6bSBVziu GQVbX6ggxVhPgUoEAudwmcCAj2YMCYEIPCuJtYZ0XqSCcWlciMZqerJEqQqbwnyPK6Gj5 oSHi3HAgJL8DAmBCC8FPDFwVFa0ue+Ga2qDFPXAxKQoQ5Dx5LViSLA8H+yEwICOAQwJgQ gxquSz1m2On+sj8U3b4LuFCXYQO3f12OKKAcUrQJJX7ECAkskMCYEIJrIuE8n+2rFZVBT diS7Fk4EeJRe+xbkrOEt2Ofp90pfAgJIvjAmBCCdViQs6Rl+dDBNZ++ZqQDVnB6QqnZI9 lL8yAby96ZEhQICRZAwJgQgBQBbnKFIiCz6nWT0+dcX7q1kRRU6mQnRQn0Agt46NB4CAk MrMCYEIMl+Gr2J66EP/KcHkk4IBHYKDj/6U7jDd/1R8PC7LbO1AgJLJTAmBCCdrVc8tfd LPKyU6B0afSgLQ6gsONsx2PtFEpInwlRsBwICNmwwJgQgmW67+LZvxB0gmoqU7ufdhg2o Gh1kfUfgDGrePe7/b6ECAkTEMCYEIPEAe2BAUrLpgcI9lsnfEhmd0SipsuJUAUiqBl4gg +/6AgJAyTAmBCCQ6Ifex5ACWM6v08/ZynSnSOUAXwHGwyDVrfTkhqP9gQICPM0wJgQgfH LpNTVDUVqb+6e+BAprAtciDp4jsXvoens2CTBKcdACAkWRMCYEIG2MPlfpXo0JVkh1+G2 +VSmRDyYQk9qjLyXhOSubSKlkAgI+ZTAmBCBpgiDKz8VfFYos/EiIcoAea1/s3HVcVQ/0 PpA1Sh0pZAICRY8wJgQgeWF2nZdWGVSLZY7EpUMRlKIJtZ06RQNKGGWicTBnE2UCAk2IM CYEIGfOKXB2wDjfUf5oImfyVbjZTigjuXZ2XkNT7THpE8x5AgJExDAmBCDr7QYR/atfOe wk5AqRBdV5n69uE5ioPIWZK5OFoo/qmQICSlgwJgQgumKpDlv4ZzrHr6zkTYAPPGn4kMy bHxfwRUdi1wew0SACAjzNMCYEIMnx3vC1MilfOgmyMCIx7W3HWpBIDAqC5Zqs8cDubzRu AgJCXzAmBCCPI9LUV66NK/KxyKnj+iGY2o54zlTB4qFKk627/IuAKQICOmgwJgQgvgpxv ghCJ9MzM7CNGzCK6jNwcYfGjsHIcJhC43lMNOECAkZdMCYEIK8XFgHZQlrwBGpMLe3+GE bHDMKHSN5apQ2Pa6UWKZEmAgJTGzAmBCAjXaj7jjiNd9n/vSNc3DXKtsyHgcLpOq8qpV6 z8+3z9gICSYswJgQgA696Menu7atoEjDWjL0ibZB9LM/qqyB+kqumuWV9EagCAkDJMCYE IG7n4ZVrfuMTOBw1us70bpgZND/EYY8CL6TE5e8l7UiqAgIxpDAmBCCwUKbGCdGF/uSb/ ls9w9j4XsUAcOxXOist/eVbWHoZagICT+owJgQgtVkpLddMj2GaBlldGk06i1D3mcKRmO Z+a2IlTEXTKOsCAkmLMCYEINF2RK2PNlV8nEYEXmwXHeIJYnAeSLs5/+UtcnNZUUrkAgI /MDAmBCAdhflZvTg7PLmCfsPihGE9YNeJ96yCuA2xrCgPN7FkdAICQmEwJgQgc5JaLiKE gMXuaFiL9PEGwnbEfcL/URJmSak5qxg5XQMCAj/9MCYEIM8GaoAYs0BM1AnvqGFR5EYjz IDZgA3Wq03+d06Q5uGGAgI5nTAmBCDNGx7E/UbPs1Sv08i5j4+f9SIAzaKUMZESELLAms 1XSgICQMkwJgQgopQcABPwDMwkMU0hTfNE1/LEmg3Vaho03WQVoGhrIqICAkf1MCYEIJR 3ccHNn6DmWxTaFiGDM+h6SRQlqufxbAL0EvhZKaYWAgI+ZDAmBCAJDVskResmE6tdqonH ZkIz9AXQ+AL1+0nufxW/GO0p2wICS/EwJgQg7KZMa4tUPSJj6Tu/U7vG7i4nP6Q52ouvG 2Ip0dEJTM4CAkGVMCYEIB/tw7R9GzpTQm6E61OjM16ScU8AcOiusPkwSKiEQlLKAgJD9j AmBCCVm/BA+9wO2p5SEULkGYn4B7sJJ9T4qbEiHvPUBNf27QICPmYwJgQgZiRlmPIpTQC eEJq2pTmOexaVqaf0AzqdyJTGQz7cy0MCAj/8MCYEIBZVXPkjproRqcVwRr+LQe2xKrhi LyKFvqxcRJq7igciAgI//TAmBCD6pKFc7xD60HVzqgRcFjZhayqk+zBG8h13hwsgR5oTe AICSyMwJgQgyZjGXGxdkwDSKAe9e6A937+WGD4ogNQ4k2mU8AHOOJgCAkZbMCYEIC2tKP BNppo/aS3E59VTCQIzOVRbntQ4LIsIQ2J3ZVI3AgJLIzAmBCA1FNkn9bvD45WNH7KH8XZ gfM6J0IZhim5J6dw3t9I1EQICUYUwJgQgHwCRAkZbYZ5E9gpkp2bDXPpSfbjXLdk3Hb8C m6LPslICAjTUMCYEII+qKOPkyWJYYPIo92JNI0UkAaR2rDXndvfW6OyBIG4NAgJLIzAmB CAkJJLvqC9+aQpy1fKaW3ReQmfmcQS/AwX0LEVEpd1ghAICQywwJgQgqYnDAib6Z/3BQf oyIjwEBZ6qPgm5ugLK6eT+Ob1h3hMCAj8wMCYEIGn1zLGBd5q/n1lNchgV4GkmT5cBiaX oBoRjGnbIz5SJAgI3ODAmBCD2ev+0Cuv0ftSn8zq3DyaXUC47NyXywwbkKH+XQWPGUQIC TYcwJgQgbZXv20BACbftVBs0hgSQog0I4j6C5Hrcv8sPVnPCp3YCAky6MCYEIAlp75xUR Xn+DWf6/GbALvSNBMnWaKD+e5Hg4ne29DjlAgI2azAmBCDjT0ThjwuaSMvENNy6XsVacR T+eeyTw2QsOI6SCqJ+UQICTLkwJgQglcvBbW/a9mkYDFEQSbNuFz1F1yh3aj/Zd5mALUU J0CgCAjwBMCYEIEkqxaZ10DA5dcZBYxNkEkePCToSVvK0S5Kxp9XNCQcgAgJNiDAmBCBV NDuqWcQO7bxRpS9d/pAKCVXh91DsZGGqsyIQWu1ZZgICQMkwJgQgdLbebeGz669U8dE+N Qey0QK5J0JJTK8e2EuuuCILWs4CAj8xMCYEIDX2V+NkstLIo8dMBgfhzCpAfZvjhMO0UJ lYLOd9UxmUAgJMvDAmBCA/T4NXC+Zg1FwZliBNAUTEvksubsBj+j3f5h3wLJoUAAICQZQ wJgQgx5KAKYFvfJ3RrQVCfC3pch9lqWC64JEuUq3miGQkkDsCAkpXMCYEICguELpRR7oz wvuve35oiG0EvrqEiGory9SdUwosUMauAgJAyDAmBCD9DovOqJG20d1vx8KkSGoOzmcCO IycrJizGmXd/RTgwQICQZUwJgQgMdZWAbZQVCDxSWnedwXFq++b6pDrVvjyf1wkToSBVN 0CAjwAMCYEIP5zkpkQwRo1FH/fPNmFi87M8mR1vHBSdBNSuB+G6usJAgJEwzAmBCBTGYV 9gClXN0KwEe2fnsXcHODeXeNxkRcW4f7bfyQhSwICQMgwJgQgtt4hiX0Qy/Z8DVemvLOi DfDXrt2kRDrWRFHFB9aDUgACAi8+MCYEIGDR7kdy6DnyoWs5VLEjkQkzm2IvLisLYGH4r JgwNvGaAgI4ATAmBCCInuNZlbjqMzpg+ENB8NDx1G/dRncrJ7AnME4Gl8vWPwICOZswJg Qgm5t1h509U0uQsYdE72F2unnMmBOC5/N54AxD3IIsE+8CAj2ZMCYEIBL4Rp4HzFLsfvS CsqqqQv8oUjM0056Gkn/cqr1T1sEtAgJL8DAmBCA3VZnxWlrJ8yGDRaxOtnCspwQiDmkN jyTmKxIJ5V/LOAICQmEwJgQgYTZVzUsoiNGrPReaxUT6ZuShz1efsYswKzeUDYn9qrwCA kP4MCYEIOZHMCSkKEZQ3cUttoWcEmXz7zBJJ7G27i6NNK6/3SUpAgI/MDAmBCBXH/BGz2 fzMNsDM3XhLrgO/DRhCjVGYPjL/ArDSsF6SwICPy8wJgQghhu6FHXVlsR94hM0+pl+jSa nJX0JO/MoDUK8heK5cA0CAkP4MCYEIBWkH8qZOZByicQGpnUr91wsNQjly0p2iO9lVH7s Qgf9AgI/MTAmBCAUc1me7ntJeuvBaQvji9bLo58XlUhza8bkBpz7u/FudwICSyUwJgQgR 6kdpy6OZGlS2luxDS1bpxxTgys8L3L8RI04thJTIFwCAj/9MCYEIDGbZ1cVACFVyHsYxM F4hkPT7pWLlYvdPD77AE786VXbAgI5mzAmBCAIjmS25AUQD5YUb8+1/tMVr7JCCnfJoEL ne0gr0C8cNQICR/MwJgQgMgnLU6OuNL/KOsiGtmfer58M6V+a8Y5zUaB7P9xkmXwCAki+ MCYEIJwzgyhH02y3lKF8h2fnvIzx5t4NjdAoc9IJfGcmov30AgJIvzAmBCCcoPOEg0Ohk nCrTAyLlsNe7v9J1d60SyMd3bnaz6fH/gICOAMwJgQgo0wEjRIkOiE2zduUaCiJ/Ht3hn GpV3wbcTiGkZUMNIICAjWfMCYEINg1c4AHdYgSVW/GyIbBH3E9HLylQzwHS4smg8oof94 GAgJMvTAmBCBv5H/rhXpFekueNGO+DaZJOlG5eXfOBCnHU+y2Rh3VpQICSL8wJgQgzHjf JLT7SQR43GiNxIB4rNCQwpQEmd16KEQrayQvOnICAjppMCYEIKZeDtGFQEIG9mSgStoiu WCObEygoSXkmVK6mMbJ1njKAgI/MDAmBCAacUW8i6aGxqcYL4ZlLb1ZZIkZpBHAqlmW96 ywOqrEdAICRZEwJgQgus/T56q64pop70fUPShKCAZlIIxsSpOXKO4kiRk43a0CAj8xMCY EICW7MOc1eh3OSW4sziPjxiGwBus7f5h0t9yJ70s8IADJAgI40TAmBCB49B9SCmyQ+EBG TmUCCp74L0dEs7L9kWNuXr+mM3pkJwICSyAwJgQgT4/8uxHcci0PzHmHXe40FDqnfSnpz IKNLVmWOr/F5qgCAkjAMCYEIFBHNoHM98kbpQTa8FTRtmclkOL0qlRlnBqX/20L5naaAg I9lzAmBCBHUSb5G84JCTCvNaBrubbv6q0j1Yk9rdWMbnQN2s9TSgICPZgwJgQgMoRJ6uR /Vp3cyYQ8CsPKcuNHhvWgc4w5+Joc0Wf9yEUCAkJgMCYEICW5SA3vHsF8/E4bq2L7kQ5i k2LiWOnf8kO72589QMmfAgJOVDAmBCD0U8quD8lT1jf635qwVir3LPj+RK4NInJaBag/2 dwUSwICRZAwJgQgioix5GFZgsG9q3z1EifwG11F76y4qBXIjea+4SZQPJcCAj5kMCYEIB VAe13ynujG/+Zz6gHIcyEGi6L8EH9t5edey6K3o83wAgI/+zAmBCBlewO5NxEh59x+vJq eNWejGYX45xsNXE1UesVD54SdtwICOAQwJgQgH+GokoJV2dLdjv3N6eAejNxGfLP28b2v valBTVaGKpgCAkP3MCYEILzQABi+ItTcozKEeaflmfCgkIJyB0lhLPbWtJunuUoaAgJL8 TAmBCA1L3QZ/ctkYe7k72yl4hrcMtWcCGTotwP29FbD7aiYdgICRMQwJgQgSPuHGaWVdK DWfilVP4Gb4I7Apfx7yEpJ66MHQH8mGy8CAj5kMCYEIF4rjGJz1iieFSwTxAnB+yD9nME bvEpkLupEnHakP7MzAgI+ZTAmBCAHCmdhz9jjnymkzJVMcZYROpptYyX+xftxdQEpxtjC 7wICQMkwJgQgQChJM5OLPC+aFsaqjDn52nssWS7MX8PjP/IM9IlX5Y8CAjzNMCYEIJV2v MHqDP82+Opv5pA652XNfa+pamj+Z9cG3Uk1Z8fMAgJDKjAmBCBm5FIRsOUYTdMdqzwMc0 PKeOCAydGb9O07a90XcpT7LwICP/0wJgQglJwagCfvu0iaX/dOsG8iPG7ZMot3DzIjflF hDQFC/VMCAkmLMCYEIM1HAnx6AZowJsatYy3D9AiP0It+hCNjFr6Kny19OYphAgJAyTAm BCAlabHoS4BSkVBQz1sFMu32KhEjCps9hXPSL81qBSDD3gICRMQwJgQgJo8WXxsumRYWE Rk97KM/HCb1lvjKCJ9capU2OcoDu9YCAlMcMCYEIM/DwKkhy3H4m+T//BmNHCehY8nA9v 9MFpS8ToXraFbjAgI9mDAmBCA9nS4jENyxBcu0yfoi01mfyXFGmVbKkfwaJBk1fQVcmQI CSMEwJgQgUy4poeSrFRP/4xid33xZhBVvqkt0Nkyfje1BTafgXpwCAkDIMCYEIMSfAQaf ygak/g9wl+Fnz5wRwXeuif9QVpMy76BLyvKhAgI8zDAmBCAKmTW2z9LpV14WIRwvu0L7H Gr3g+jxIZE+EwVczdgSxQICS/EwJgQgJls6yaOcKxeOm4rHGSQqRaqyouAMQLpVGKg8jt poOJICAky7MCYEIPiMYhaEzQ9hpFKUt9dxwiN6lrsG0chnld0+cz4kkCXYAgI8zDAmBCB 9YDJ4A24F+fUqMdyDUywwhHBf0rr/hnZdyzmNTx+mdAICQl8wJgQgiBzCDLlq2XqoeG+7 5YcnvSc/MzuAvltFmn00QNhEANcCAj8vMCYEIFfdvTpsKEr9AMknFJZSDOgaC/qg+R5w7 MZmOz0G+wgHAgJLIzAmBCAhmdCwm2PFeK9+cTo3hRMWOBdQ7wubLTRzQ2KBEnRy3wICQM gwJgQgRvD2zanOaAFz5qmQoUFrn0w3x98zg05FXkHCEk0s6ssCAj8xMCYEICNKvRcXjvw MVSEgYV2TQozroI5YQU6F+RVarK6gRIHsAgJH9TAmBCBlkhKRdMykBXS5AktOWK9kFwtg KqZ4eXCt/3LFdr+4HwICQMYwJgQgR2H7pi48hwvG6Vaxa7earK7l3qzd0Kftr9n8cBBLB 6MCAj5hMCYEIAEGn9WevNQeGJk0lqiBYGp8FdsS0C4RfrZ5rzW8496lAgJGWjAmBCDHqk aaxPrEEE7ziSp4KOobiszrN9obQHjGmY/mB9qIcwICQmEwJgQgSG4ckizAIV2HyiUIH2b AYgD9akr2ffbgyL3wvlzL1isCAlGDMCYEIFIHsiWrb/pl5KBK+8eLbHZaW+mR2DedlySm /HWU+zY/AgJCYDAmBCCFvlGY8Pkx45g2hMPex5wanXE3xcupWKuWQMUR4KHLMwICOzUwJ gQgt14YDDtCnxbPTGMOWrsiASCpDSzRu8R9K2m79ztPII4CAj8wMCYEIGIngPL567LeTW vM4QCvyNr4+1kVVkU9A3ZahQg3tm/QAgJH9DAmBCBE81BID1d1VcGJ6L3kUfU4J004iGa IWTAYq6enu2cXiwICPZgwJgQgZhjyOe0KsN9FJXC9fhWvgJFlT/ybLQlPM/hkTtsPvI0C AkWOMCYEIIG/AwfTXiHFYkPx1J7meEAcMN0gti352scmJ4M8WBsFAgI//TAmBCByQvBRt JUNK63suuV0XBjhWqbmT2ukz8XArV/0oKpT5wICP/0wJgQgCJ1oWH+zFCvk2uuxvSqEN8 gor0zu1tuv4TIQwci1TfQCAkmNMCYEIBQqL+QN2/Mk/l/kHKJDNFq90GurZWwrre3QNKt FP7i1AgJJjTAmBCDWt0iCseN/ybhYS99r5T0vOCYKSOSf1q8/F5sINOmtAgICNAkwJgQg s8qn6Xe/OKnjI9ITHnfrc/Yus2/3ixebx/fpEzpnabUCAkf1MCYEIGNeqYuZNidh6wZfP DGDZivYPQPJaYIEwVPhlVJC1HZWAgJEwzAmBCAeHZ1EX3BbR5CdwrFxQQAs/wrAdx+v1c wt0szchCg1RQICQywwJgQgffD67rN8L3ILw3a0KmgGVbHJvTb43Iy6c0X0hkf/nB0CAkc mMCYEIEqa4ij2geU+QQfuEFcRxojmbO6HuIsN45RSv6pCb8XQAgJAyTAmBCAc1Rm3/gOg JEd01R+tYfs7PRo8zTYroF7Dnl+vq7dqBAICTyEwJgQgnEZv4dk8MEP2jBzDOAtQDjdn8 JYdegubXlK5oNFrxzkCAkMsMCYEILzWd/V6/Kl/5bgKmT3vMGsKHAAZ3Be0pqe5JGf6Pm hIAgJFkTAmBCBrSAeD/mIL9nUug2pSGQkY/H2Ksfv8l8igTG2jURG+EQICQZUwJgQgv3F 4VnI7R/vTyewzrl3tBu4t+KYhwA9I9lZQICG17vwCAjv/MCYEIOzaLHqLuRi5CAHyT93i OYgCjc/w02kfoBC3zMZQd5/vAgI9mDAmBCAjAhzfasoBO8TekxFWVaBsTNM57xON+Nn03 C8ug+RNFgICQl4wJgQg4ZkVLSga+phmzGb++WSA7I4kI7p77tHDGxgKrJBjIjACAkMsMC YEIJ+V96HqzGtmWbgCpN0u3umds3hdNxqJgXzgnLGImORNAgJH8zAmBCBuK5cHy+L9l7N SM3HZLp66iJMq8zWzOXZwHIwmqoql3gICP/wwJgQgT6GStdV/Gh6jnsy6Z8VNko7LKzTa BdEjyUnJt5N5i9cCAk/tMCYEIEZLAiFrg8UKxYw6c0HYoftPPEbwKvulprVsIfGoBauyA gI7MzAmBCBkL/UjTRk6ssWT5GyuF/IBwESy1bF8wDbk7ZBuNzGvOQICSlcwJgQg8MmH2i 2h60fS8crhl+BpykHwOPuECtLdTFWNkO5PNX0CAjWfMCYEIPumvBGRd95pybOOYiUCajl wr5F4BC+l8vi7Qwm30t2zAgJAxzAmBCAiCFqPM72Yu1JyXQZm7/JCiKA+ABoOq4Vy0vrK 9NiXlwICR/QwJgQgEDS/zNykfeldHIRjFlbSv/vQENImU746xGwE0+FEWh4CAk8gMCYEI IcWwmcymTwLrGV61QwPPKj6bmTwbo1PpGgBBax7d0BVAgI/LzAmBCCa+Ib1IcQ3HxhVNO 8CbEYH8A6cBh3rZgo1WRU15bTW5QICP/0wJgQgJgN+bz4Y0Tdnzx85kj0LH7tvlGRpy4x ItxuBma2uDZYCAj/8MCYEIA7+I1vMO4ZkoI4PkJIxPajKbvq1RHhhAtBVWQ+jSz8jAgI9 mDAmBCAKHZqmHuvUNTjVKKyF/6KCeXJYfVbwwZatxqiirySWjQICQ/gwJgQgCVJpXR6EE /cLCrY/dxjl31tAgSfd99c85iBAT9qHL3wCAk7dMCYEINKcNGpfUzhHE6e9FNViLij+pa N0NBkc3wFeVc5z3fPKAgJCYTAmBCB999DeJhZ/jh25jyfT7BaXu8z9x2Y7ZL45w5aveCf XzwICONAwJgQgQ6ePpqQM3J/tAWJNRDVE+zwB6Gq6V9/rFPjRjnThqr4CAjc5MCYEIMw0 LxAX97O+HokACVnfRItxQD5tBlWDdTiuq+mlq3bYAgI4pDAmBCDVIrIsPDyNl4SmB82F6 0uQUh57qUTnlU6V3spkvm2CeQICPmMwJgQg8KC7wuciQ4D/m0XEGKMWijhMlO3+ei29SJ 1V2tJ0y1wCAkDHMCYEIG+IWuA4NGyjFmlYOvNqzEjcrruBEzFNNI6DiQhIWspDAgJCYDA mBCDxylx/b/WSaYilR7IZ0vQ1woUY9UUKntZY4uNaIluUkAICPZgwJgQgS+M7K6tuebac VxFjX1DFet5nMfv2b+CqPzksp9jG1rQCAjjRMCYEIIZLqVrG5MlUrIUEYGVpml0m2tDSQ qawo4W0FTopXtoxAgI8zDAmBCB+EkohX4QKN6YwqvF4ATN1zF2R6iDhhrBEeoJKse3zGg ICOZ0wJgQgzfBErimweC0BtIKQiMpcuQoftSHe10oYJW6Tm3JiazACAjgFMCYEIKbo/K2 jeb/5vj6f2alhOHCdH1qEsTAgolSnDRi034kiAgJAyDAmBCAWxL531lZDXoxwixMRpbZ8 1MVJMM8Vcg0q7Ps5jjPSIQICP/swJgQgXR6DxJycXEuGwdsnjGEuubANEJbdDc2n/roP9 V1+JTQCAjpoMCYEIL+P2i+gcHBt8UW7/kXh4jiQF91hPoVAhkblnvkKbNJiAgI/fjAmBC Bkt3eqIMLPhKo2jYgJ8wefmzDS5nNzsGZh1cWfaLcs4gICNeQwJgQgQ1aPgjz3HjRbjkA mhF7PmIzFD+ad3wC3b281PvzoLT8CAkOAMCYEIOg7kghxKqfHlBeiil8xXgMGSWcFg1XW CyoF7f9lYFT0AgJASzAmBCBm5L2At89Js1RA6PPD3fxIoCXPcEC3iS2J3ZagaPs1OgICR Y4wJgQgsiapUbHJXC77xeNTpbGJIhA8brJPJsg1U45j8NNApoICAjc3MCYEID4T1N6vnr wctWDGvGUb0sKYM5VCRrRx2lHR22St2VapAgI+YjAmBCCZMsTFB07NQg5WSQ9wK8Up8Sp iapWo1TnICYqfLYlAXwICRMQ=

Example ErikPartition This object was retrieved from http://miso.sobornost.net/.well-known/ni/sha-256/tt4hiX0Qy_Z8DVemvLOiDfDXrt2kRDrWRFHFB9aDUgA. MIIvOgYLKoZIhvcNAQkQATiggi8pBIIvJTCCLyEYDzIwMjUxMjAyMTAwMTQzWgYJYIZIA WUDBAIBMIIvATCByQQgAMX+7iIIqxeNVkiTc4Ii2ZeOPl8Rl7vxWNXZ/Q+Ff9kCAggYBB R/8bgc/mq7EY6X4DJbZi6vmE8vagICDcIYDzIwMjUxMjAyMDMwMTE3WjB2MHQGCCsGAQU FBzALhmhycGtpLnJpcGUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC83NS8xODZhMTgtNWQ3 Zi00M2VkLWIwNmEtY2VhN2ViMzUwNTM3LzEvZl9HNEhQNXF1eEdPbC1BeVcyWXVyNWhQT DJvLm1mdDCByQQgBG6CUhPUabKPjnLg9qh7lZtS60gM8tjCgWkIWl5AMVICAgfOBBR/yV alK3NQSk8f80VHGZKXp/XenQICCwoYDzIwMjUxMjAyMDgwMTMwWjB2MHQGCCsGAQUFBzA LhmhycGtpLnJpcGUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC9hYS83MWFiNjktNjk2NS00 YjcwLTk2OGQtYmI1N2E0ZWY3MTUzLzEvZjhsV3BTdHpVRXBQSF9ORlJ4bVNsNmYxM3AwL m1mdDCByQQgCDh5YK7waRs7uM3lMJ7vLIA4w4WYfuAx7+PBQ0ecCcoCAgfOBBR//IJYXf abfJSxamGTL/yLbjNRVgICEy4YDzIwMjUxMjAyMDcwMzA0WjB2MHQGCCsGAQUFBzALhmh ycGtpLnJpcGUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC9lNC81MzFkMmItZTE3MC00OWE1 LTg0MDQtOTJmNzNmNTZmYzYyLzEvZl95Q1dGMzJtM3lVc1dwaGt5XzhpMjR6VVZZLm1md DCByQQgCuO3xDB6RqovsRJRjfibhDYcNEcUtqqAWtszXxK6zUUCAgfOBBR/HVjWLd1+R6 8hlv11S7P/JnmJKgICF1QYDzIwMjUxMjAyMDcwMjUwWjB2MHQGCCsGAQUFBzALhmhycGt pLnJpcGUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC80Ni8yOTBhNjAtNzkyZi00NDc1LWE5 ZjQtZTNiOWUwYmFlNmFiLzEvZngxWTFpM2Rma2V2SVpiOWRVdXpfeVo1aVNvLm1mdDCBy QQgDPy278mvBB/Ad+R7gB9u6BCoXVxKglAPftFt+Hic168CAgfOBBR/1i5CwI4WAcRXHg 2Io0mgUJ3qXgICEt4YDzIwMjUxMjAyMDMwMTA2WjB2MHQGCCsGAQUFBzALhmhycGtpLnJ pcGUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC83OC9iOTM0ZWUtYzRiYS00MzkxLTgwYjAt ZTc1YTVlYTg5ZmQxLzEvZjlZdVFzQ09GZ0hFVng0TmlLTkpvRkNkNmw0Lm1mdDCByQQgD 8LuWSLexcmNKKD6MS1emGR3lMlPttDxWq8DU61EzZECAgfOBBR/7j84IHPyw+T8z/yjhM WwzYJsJgICAycYDzIwMjUxMjAyMDUwMTAyWjB2MHQGCCsGAQUFBzALhmhycGtpLnJpcGU ubmV0L3JlcG9zaXRvcnkvREVGQVVMVC9hNy84Y2NlYmYtZjlmYS00YzQ2LWFlZTgtY2Ni ZmE3MzQyNGE3LzEvZi00X09DQno4c1BrX01fOG80VEZzTTJDYkNZLm1mdDCByQQgEZtfE 5VMnpFveqR56eAGpgGjQdDqghADYYfCZEDblIYCAgfOBBR/+wEVxKzd0bStxAc3gHJqz8 Aa+QICDGAYDzIwMjUxMjAyMDkwMTMzWjB2MHQGCCsGAQUFBzALhmhycGtpLnJpcGUubmV 0L3JlcG9zaXRvcnkvREVGQVVMVC82MS81MjY4ZmMtY2ZlZS00YWE4LTk3YmYtY2JlMDIw NjY1ZWZlLzEvZl9zQkZjU3MzZEcwcmNRSE40Qnlhc19BR3ZrLm1mdDCByQQgF/Vd2aD0K oOkqhBrD8ZnsmD9wpVMor+/Dc/Ng+h6NN8CAgqPBBR/a9GmsEYlxXHYMPh4scAjgkdAjA ICBfsYDzIwMjUxMjAyMDkwMTMzWjB2MHQGCCsGAQUFBzALhmhycGtpLnJpcGUubmV0L3J lcG9zaXRvcnkvREVGQVVMVC80OC9iYzY2ZDctNTdhYi00NzVkLTk2YmEtODliNmMzMjMx NWMyLzEvZjJ2UnByQkdKY1Z4MkRENGVMSEFJNEpIUUl3Lm1mdDCByQQgIZBP41uwLyfqJ yMStBiVsyOdBIKdVOUvnvxRsDs9yHsCAgfOBBR/kt92EPBI9Dv0TDNtQcbBFX7w4gICFu kYDzIwMjUxMjAyMDIwMTA1WjB2MHQGCCsGAQUFBzALhmhycGtpLnJpcGUubmV0L3JlcG9 zaXRvcnkvREVGQVVMVC8xNy81OGJlMTgtMmYzNS00YzZhLWFhNmEtN2Y3MmY0NGI4OTgy LzEvZjVMZmRoRHdTUFE3OUV3emJVSEd3UlYtOE9JLm1mdDCByQQgJMbj6N3sZETMeSxxm xgcMTCtQdd3WkskVtzzgQ0nfCMCAgfOBBR/5osSI0vXA0MBvJaxOKrid4YKPgICBcIYDz IwMjUxMjAyMDYwMDU5WjB2MHQGCCsGAQUFBzALhmhycGtpLnJpcGUubmV0L3JlcG9zaXR vcnkvREVGQVVMVC84Yi80YTExMTEtOGYzYy00ZWRmLWI3N2MtMmZhMjYzMWJjMzFjLzEv Zi1hTEVpTkwxd05EQWJ5V3NUaXE0bmVHQ2o0Lm1mdDCByAQgJ9MKT5HNNxRaHePV8odvL EkLusUbGYiIZOEEMgwddnkCAgfNBBR/MSsJ0faQ8lcAvV3PB8kYDF6WYwIBfxgPMjAyNT EyMDIwNTAwNTNaMHYwdAYIKwYBBQUHMAuGaHJwa2kucmlwZS5uZXQvcmVwb3NpdG9yeS9 ERUZBVUxUL2JjLzI5ZGFjOS05YTE1LTQ2NjEtYWY3OC0xNTIyZTI5NjRmY2UvMS9mekVy Q2RIMmtQSlhBTDFkendmSkdBeGVsbU0ubWZ0MIHJBCAoLWmQKZmBpUUFVPsy7MnU21sKo DdeXKXgthCvY5eXDAICCBgEFH8WgCjsDatmimfVv29TWMqr4zeoAgILxRgPMjAyNTEyMD IwMzAwNTdaMHYwdAYIKwYBBQUHMAuGaHJwa2kucmlwZS5uZXQvcmVwb3NpdG9yeS9ERUZ BVUxUL2NjL2IxNTI4Ni1mZDRkLTQ5ZmUtYTY5ZS03ZmFkZjUwYTJlMzcvMS9meGFBS093 TnEyYUtaOVdfYjFOWXlxdmpONmcubWZ0MIHJBCAqkkSMUp64n/LjY9EkJcPzsfhP+AYMS NcuvRqiEAatDQICB84EFH9C0nwh2obH6fv0SuDlbJjz0vgLAgIO9BgPMjAyNTEyMDIwNz AxNTNaMHYwdAYIKwYBBQUHMAuGaHJwa2kucmlwZS5uZXQvcmVwb3NpdG9yeS9ERUZBVUx UL2E5Lzk4YjAyNC05ZDhmLTQ4NjktYTJhOS0wYWZiN2MzZmJmMzAvMS9mMExTZkNIYWhz ZnAtX1JLNE9Wc21QUFMtQXMubWZ0MIHJBCAxvg2dc4tSHXnXSH98bnAN5Z5QI1bL2wPfY wPxnY5jYgICB4QEFH8HV8MxmB4EK3RxNzUn0PZKE1a0AgIS+hgPMjAyNTEyMDIwNzAyMz ZaMHYwdAYIKwYBBQUHMAuGaHJwa2kucmlwZS5uZXQvcmVwb3NpdG9yeS9ERUZBVUxULzc 4LzRmOTZmOS01NjlmLTQzM2MtYjlhOC02YTI2MTJkNDBmNTAvMS9md2RYd3pHWUhnUXJk SEUzTlNmUTlrb1RWclEubWZ0MIHJBCBHafQUxF3NA6JUdDgiSC70WRe/dWegE3gl9ScEJ XNBLQICB4QEFH8UzoEDt4XzUEvEsy8fTJtwzj9/AgIQExgPMjAyNTEyMDIwNzAyNDBaMH YwdAYIKwYBBQUHMAuGaHJwa2kucmlwZS5uZXQvcmVwb3NpdG9yeS9ERUZBVUxUL2I2L2Y 2OWRiZS1lMDc1LTQ0MzgtYjUzYi1mNjE2MGZhMWZiMDIvMS9meFRPZ1FPM2hmTlFTOFN6 THg5TW0zRE9QMzgubWZ0MIHJBCBMXnhom4Q63Nb1rZ8HxdMTILHHfBqyzb6ZsYsOE3c0Q QICB84EFH9YvAhkEvTSxU+gcC2SziVJbOR5AgIUzxgPMjAyNTEyMDIwMzAxMTVaMHYwdA YIKwYBBQUHMAuGaHJwa2kucmlwZS5uZXQvcmVwb3NpdG9yeS9ERUZBVUxUL2NjLzUzMDk zMy01OTE1LTRmZjItYjFmOS01MDEwZDA1Zjk5YTgvMS9mMWk4Q0dRUzlOTEZUNkJ3TFpM T0pVbHM1SGsubWZ0MIHJBCBVoKCYkcR6TZPnwUOJSheDpJeCBPoNggLGJBXo2RLlagICB 84EFH8km5VEYgaD+Us4inVRpopkk+0SAgIDhhgPMjAyNTEyMDIwNDAxNDJaMHYwdAYIKw YBBQUHMAuGaHJwa2kucmlwZS5uZXQvcmVwb3NpdG9yeS9ERUZBVUxULzhiLzdhYTA0ZS0 0ODA3LTQ5ODgtOTEwMy04NDIzOTdlMzA2NDMvMS9meVNibFVSaUJvUDVTemlLZFZHbWlt U1Q3UkkubWZ0MIHJBCBa9ki/mAoG9Kp9PlJCfKUt1zVeXLxBcagsdgiFWR6x1gICB4QEF H9R3x306IZ+QeXn+S3n+dH6DBVNAgIMPBgPMjAyNTEyMDIwOTAxNTVaMHYwdAYIKwYBBQ UHMAuGaHJwa2kucmlwZS5uZXQvcmVwb3NpdG9yeS9ERUZBVUxUL2ZhLzVlNzMxZi01Mjh iLTRlMDItYWQ2OC02ZDkwMzVhZjE1MzUvMS9mMUhmSGZUb2huNUI1ZWY1TGVmNTBmb01G VTAubWZ0MIHJBCBcx9Q+329FqMvH7W3YJZEcYgT1x6dycJKWN4NKALbs5AICB84EFH+oF qMzjTJ0HNT/+PSd2yzIOP3FAgIExxgPMjAyNTEyMDIwODAxMzNaMHYwdAYIKwYBBQUHMA uGaHJwa2kucmlwZS5uZXQvcmVwb3NpdG9yeS9ERUZBVUxULzUzL2E0NTI4YS05MGU2LTR kOTEtYTUyYy1mMDcxN2VhNDg1YzYvMS9mNmdXb3pPTk1uUWMxUF80OUozYkxNZzRfY1Uu bWZ0MIHJBCBjkxk8YV5Ap12jk7mtGtaL50jbsxZ14vP55xR8k7n+7gICCBgEFH/g51k1T oPMGTIDgRCd4i2g8acAAgIXXBgPMjAyNTEyMDIwNDAxMDVaMHYwdAYIKwYBBQUHMAuGaH Jwa2kucmlwZS5uZXQvcmVwb3NpdG9yeS9ERUZBVUxULzRjLzBjNzI0My0xZmZiLTQ5ZDI tYjVjMS1iNDAyZThhMWQ5MzQvMS9mLURuV1RWT2c4d1pNZ09CRUozaUxhRHhwd0EubWZ0 MIHIBCBrOdTt95AUso/5Cc59i8OxF/vRYkGC0X2AnFNU6JrXtwICB4MEFH83coPXwjWpP ce9K4MXsnSPKF/3AgFIGA8yMDI1MTIwMjA4MDExN1owdjB0BggrBgEFBQcwC4ZocnBraS 5yaXBlLm5ldC9yZXBvc2l0b3J5L0RFRkFVTFQvOTIvMGZhZGZjLWY0OWItNDNlOC1iNjI xLTgzMWUyOTQ0ZjhmYS8xL2Z6ZHlnOWZDTmFrOXg3MHJneGV5ZEk4b1hfYy5tZnQwgcgE IHCg18vDg8nOH0Imktf6/dShb7OzmCXQcHjpTUUndYB6AgIHzQQUf7UOfTt/0olM+3Dkl GCLMgzCFcECAWsYDzIwMjUxMjAyMDUwMTE3WjB2MHQGCCsGAQUFBzALhmhycGtpLnJpcG UubmV0L3JlcG9zaXRvcnkvREVGQVVMVC85Ni9hOTE4Y2ItMjA0NC00ZjFjLTk3MDAtOTM 2MDFhMzRmNjJmLzEvZjdVT2ZUdF8wb2xNLTNEa2xHQ0xNZ3pDRmNFLm1mdDCByQQgg3B2 jopDFhv5lafmlABTEXT3PdDmycUF0vvVv4qsm48CAgfOBBR/hemQNUOX42wMqQOgxiDHc J79zQICA4UYDzIwMjUxMjAyMDkwMDUwWjB2MHQGCCsGAQUFBzALhmhycGtpLnJpcGUubm V0L3JlcG9zaXRvcnkvREVGQVVMVC81ZS80YWUxNzUtNTVkMC00ODRkLThkMTEtOGM5ZDU 4MjNiYWQ5LzEvZjRYcGtEVkRsLU5zREtrRG9NWWd4M0NlX2MwLm1mdDCByQQgh/LB2/IW n5WpvgaEitBCvTJiIvxsqYuCCw9TwetLEIUCAgilBBR/ytid8b+Zo28pDMPvDx57TQJ1M wICFzIYDzIwMjUxMjAyMDIwMTE5WjB2MHQGCCsGAQUFBzALhmhycGtpLnJpcGUubmV0L3 JlcG9zaXRvcnkvREVGQVVMVC81NS85ZjhiMTYtMjg0Zi00NTEyLWIzZGMtMDE1ZDlmMWI 0YjUwLzEvZjhyWW5mR19tYU52S1F6RDd3OGVlMDBDZFRNLm1mdDCByQQgiTSCNydCsyhC BravLWid2StVCdr22al/Txn7WYytr/sCAgfOBBR/USKDdHQt9USqkwWMWjvT0WQhmQICD scYDzIwMjUxMjAyMDgwMTA4WjB2MHQGCCsGAQUFBzALhmhycGtpLnJpcGUubmV0L3JlcG 9zaXRvcnkvREVGQVVMVC8wYS85Mzg1YWEtMWI3OS00YTAyLWEwOTItMDFlYjAzNjg0ZjA 5LzEvZjFFaWczUjBMZlZFcXBNRmpGbzcwOUZrSVprLm1mdDCByQQgiyd2cr50asT5E+FU NZ9DjcRJf3pHTAz95YHtdMi5DCYCAghgBBR/K6ht94eIj2+FkqgGpv/qMEbAegICF1oYD zIwMjUxMjAyMDIwMDQ4WjB2MHQGCCsGAQUFBzALhmhycGtpLnJpcGUubmV0L3JlcG9zaX RvcnkvREVGQVVMVC82MC81ZTY3ODYtNjM3Ny00MjI0LWJhMDYtZGM0NzY5ZWZmMWY1LzE vZnl1b2JmZUhpSTl2aFpLb0JxYl82akJHd0hvLm1mdDCByQQgi/dW04+DLp3y4iuTHFPh j/3BX08nco/eS6+SHJ90UhYCAgfOBBR/M/xA0uAzO7x73qsr2FmVQwHA8QICBqAYDzIwM jUxMjAyMDgwMTA0WjB2MHQGCCsGAQUFBzALhmhycGtpLnJpcGUubmV0L3JlcG9zaXRvcn kvREVGQVVMVC9iNC82NWJmMWQtZWMxZC00MGU2LTg0OWQtNzk3OTBkNjZkN2QzLzEvZnp QOFFOTGdNenU4ZTk2cks5aFpsVU1Cd1BFLm1mdDCByQQgjjrmZwAwYmO/XutpgFS0pvq5 QMhKV6OTKQvKyhvTjqsCAghfBBR/UAd9LdimehrotqvWu7NIkCiluwICF10YDzIwMjUxM jAyMDQwMTM4WjB2MHQGCCsGAQUFBzALhmhycGtpLnJpcGUubmV0L3JlcG9zaXRvcnkvRE VGQVVMVC81Yy9jMWMxY2UtZWE1OS00ZGNmLWJjY2MtM2U3Y2FkZDg4YzcwLzEvZjFBSGZ TM1lwbm9hNkxhcjFydXpTSkFvcGJzLm1mdDCByQQgl4ztfWjMtuBGsCMqqkuxgOjZblNP eMjdPs33YQUyMjQCAgfOBBR/m0z9ybDZ48MeDruB5vGxy73J5AICDTYYDzIwMjUxMjAyM DUwMTM2WjB2MHQGCCsGAQUFBzALhmhycGtpLnJpcGUubmV0L3JlcG9zaXRvcnkvREVGQV VMVC81Yi84MjQ2ZWItODQ2OS00MmRmLWEwOGYtOTBjNDIxZjU1YWRiLzEvZjV0TV9jbXc yZVBESGc2N2dlYnhzY3U5eWVRLm1mdDCByQQgmNJYdWjP733EBq/xGMRqAp/gY9LnHDad 7m80HqWA/JkCAgfOBBR/7+vRX7xlFIesr2dCT0eD1D60IAICF1IYDzIwMjUxMjAyMDYwM DUyWjB2MHQGCCsGAQUFBzALhmhycGtpLnJpcGUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC 85YS8yNmVmNjMtYjcyZi00YjNjLThkZmMtMmJjODQ1MTkyMjdhLzEvZi1fcjBWLThaUlN Icks5blFrOUhnOVEtdENBLm1mdDCByQQgmf2cQA1kGrnfMdRK1Koho+7W4tb/MHBvZN5N 79kZDpYCAgfOBBR/GIratbVSCB7KyCHJsJA5SHOzFQICEcYYDzIwMjUxMjAyMDQwMTU2W jB2MHQGCCsGAQUFBzALhmhycGtpLnJpcGUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC85MC 9hNjU1MjItZjdjNS00ODdiLWI3YjgtMmU0NjE0MTQxYWE0LzEvZnhpSzJyVzFVZ2dleXN naHliQ1FPVWh6c3hVLm1mdDCByQQgnX4AuwUIq4FJ3l8BlaqYALo6B1lge5GaMpP0IHzk N7ICAgfOBBR/HQ4ymL7Tp/Ofs7JE7ZGL9sTXvwICFSwYDzIwMjUxMjAyMDIwMDUxWjB2M HQGCCsGAQUFBzALhmhycGtpLnJpcGUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC9mNy9lNj UwNmUtNzY4NS00OGU3LWE1ODMtMjFhZjNkZWU4ZWU5LzEvZngwT01waS0wNmZ6bjdPeVJ PMlJpX2JFMTc4Lm1mdDCByQQgnnFg3v7hRWsuutSKC2INQPtmzp51AjNERmUHmoCZysMC AgfOBBR/Q52UJCb8ZzsnnMmKs1/b1+qX9QICEu4YDzIwMjUxMjAyMDIwMTMzWjB2MHQGC CsGAQUFBzALhmhycGtpLnJpcGUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC8yYS82OWEwOW YtNTgwOS00NjU2LWIzNTUtMTQ2ZjI1NGFjMTMxLzEvZjBPZGxDUW1fR2M3SjV6SmlyTmY yOWZxbF9VLm1mdDCByQQgo2KuxR/yaVX9kbBmOWrM9IuOj/OFzh+WdnrubtXzD50CAgfO BBR/902r1OsaoRRxROFbAmaemC/eTQICBwIYDzIwMjUxMjAyMDgwMTM0WjB2MHQGCCsGA QUFBzALhmhycGtpLnJpcGUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC83ZC8wZmJiZjUtYz gzZC00Yjk3LTljZWEtMDU1YzQ5YWM2ODI4LzEvZl9kTnE5VHJHcUVVY1VUaFd3Sm1ucGd 2M2swLm1mdDCByQQgpb4yUfq+e3Kb+SPcaxTW3wnwczVSZyeJi+hWEqAPOhQCAgfOBBR/ EUFq45Kd83v2akWc06ymOJHpRgICF1IYDzIwMjUxMjAyMDMwMTMyWjB2MHQGCCsGAQUFB zALhmhycGtpLnJpcGUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC8yZi82YjIyZTgtM2RjZC 00NGRkLTk1MTQtNjc1NmY3YjBjMGRiLzEvZnhGQmF1T1NuZk43OW1wRm5OT3NwamlSNlV ZLm1mdDCByQQgraMaZyixFyPaeEX9BytWmTMWCApJR3jyqT2KBAAPsTcCAgeEBBR/KWZX r40Awl/XX1bsyKKLNRUFdQICEIwYDzIwMjUxMjAyMTAwMDUwWjB2MHQGCCsGAQUFBzALh mhycGtpLnJpcGUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC9kMC9lODBiMzMtM2JlZS00Nm VjLWIzNWQtYmFmOTVhNTA2ZDE5LzEvZnlsbVY2LU5BTUpmMTE5VzdNaWlpelVWQlhVLm1 mdDCByQQgthWUYRf3Ko4EDRFnDpxIwSWg/NrI3yUIjKlwU5BLpPICAgfOBBR/49Y7SltA S1/4PL8rFSWjBHf2XAICBJgYDzIwMjUxMjAyMDkwMDU3WjB2MHQGCCsGAQUFBzALhmhyc GtpLnJpcGUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC9mNi84MWE2NzItZmU5OC00ZDNmLT liODMtMmNiN2EzYjZlNDJmLzEvZi1QV08wcGJRRXRmLUR5X0t4VWxvd1IzOWx3Lm1mdDC ByQQgttAYBOj1CvqqXCRlvKYvnkRKJvkeu17lTnZ1uvrsQNMCAgilBBR/PgsnuOTXmPkr neFX8dpaQ81J5QICEZMYDzIwMjUxMjAyMDUwMTI3WjB2MHQGCCsGAQUFBzALhmhycGtpL nJpcGUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC81Zi9hMGM5YWMtM2E0Ny00ZDZjLWFhMT UtYTQyZWM4Nzc2ZmJiLzEvZno0TEo3amsxNWo1SzUzaFZfSGFXa1BOU2VVLm1mdDCByQQ gt2qjoeqXioD1axDs6VbSwWBexTd9dSFuvNYOwhe3JvsCAgfOBBR/F4+vZAHi83FuMXZF ad9zHfWPIgICEcoYDzIwMjUxMjAyMDkwMTI1WjB2MHQGCCsGAQUFBzALhmhycGtpLnJpc GUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC82Ni8xYjc5NjgtY2E0ZC00NWY0LWI2NzEtMm U3Zjc4NDg5Y2QzLzEvZnhlUHIyUUI0dk54YmpGMlJXbmZjeDMxanlJLm1mdDCByQQguh2 qFxQSPsbZLwh4b8ErTSkC6ghcVw9rEzfnKxbQCoYCAgeEBBR/c2uIoCQE1DBL3a1f9VBK aDPntwICF1MYDzIwMjUxMjAyMDcwMDU5WjB2MHQGCCsGAQUFBzALhmhycGtpLnJpcGUub mV0L3JlcG9zaXRvcnkvREVGQVVMVC85OS8wZjI1Y2UtYjk3Ny00ODUzLTllYzMtOWU1Nm NiNTRmZWY3LzEvZjNOcmlLQWtCTlF3UzkydFhfVlFTbWd6NTdjLm1mdDCByQQgwE4bjYQ oN32V63OzjC/yXNs7paWki0kXw36lIuOc+g8CAgeEBBR/F7b5MjmdWFCT0YczlOv+Gyn5 jAICDtcYDzIwMjUxMjAyMDQwMTM0WjB2MHQGCCsGAQUFBzALhmhycGtpLnJpcGUubmV0L 3JlcG9zaXRvcnkvREVGQVVMVC8zMS9jYzAyMDAtYmIyYy00NWY2LWFjNzUtODI3NTc3ZG Y4ZWRjLzEvZnhlMi1USTVuVmhRazlHSE01VHJfaHNwLVl3Lm1mdDCByQQgxRmFCzil0Q6 95LB2b9TNATvFoS66n9hVIdaw4zsL6ccCAghfBBR/VvKJSMgy8tQ0u0TV3g6hImAbBQIC F1cYDzIwMjUxMjAyMDcwMjEzWjB2MHQGCCsGAQUFBzALhmhycGtpLnJpcGUubmV0L3Jlc G9zaXRvcnkvREVGQVVMVC8zYS8yMWZiY2EtODBlMC00YjhjLTg2MjItNGU4NmFkNjRmNz c0LzEvZjFieWlVaklNdkxVTkx0RTFkNE9vU0pnR3dVLm1mdDCByQQgxYali50YrOH/GXe 0+ytDfMDd8wTOFa8xYbUrKuG5P4sCAgeEBBR/SuV+5uCpxRAfwUqHpTNBULurRgICBqUY DzIwMjUxMjAyMDIwMTE2WjB2MHQGCCsGAQUFBzALhmhycGtpLnJpcGUubmV0L3JlcG9za XRvcnkvREVGQVVMVC8yYi8xMWZhNDQtODg3OS00ZDE5LWI0NjgtNWI1ZDk4ZjUzNjFlLz EvZjBybGZ1YmdxY1VRSDhGS2g2VXpRVkM3cTBZLm1mdDCByQQgyXd1nRRvk6rtEdWX/rm J2iyj7r86rfNSnJ1UnIS8YyICAgfOBBR/tD3iN/0LaihziSMJIdJaLC7RqAICFugYDzIw MjUxMjAyMDUwMTI0WjB2MHQGCCsGAQUFBzALhmhycGtpLnJpcGUubmV0L3JlcG9zaXRvc nkvREVGQVVMVC8wOS9kNGQxMmEtYWI0ZS00ZGJhLTk1ZGUtYmM2MzcxMzBkZTZlLzEvZj dROTRqZjlDMm9vYzRrakNTSFNXaXd1MGFnLm1mdDCByQQgyaagRnEcy8cfA9Gycczrwed Mb9AXeaEFBEYipCTRFnYCAgfOBBR/MTYP/Br9Xx2mbYFATkZjUS1JZwICFN8YDzIwMjUx MjAyMDUwMTI1WjB2MHQGCCsGAQUFBzALhmhycGtpLnJpcGUubmV0L3JlcG9zaXRvcnkvR EVGQVVMVC8yZC9mZWY1ZGQtMzhlZS00YmM1LTgyZmYtNTg0ZDc4YTI1ZjhjLzEvZnpFMk Rfd2FfVjhkcG0yQlFFNUdZMUV0U1djLm1mdDCByQQgzCDlP8WVMADx2mHkfcEMYBAv2xX 5nxxCKq3jGqqnQqkCAgfOBBR/dzTf6hIGV0EuqGfdvHuE0TK/eAICEAQYDzIwMjUxMjAy MDcwMjE2WjB2MHQGCCsGAQUFBzALhmhycGtpLnJpcGUubmV0L3JlcG9zaXRvcnkvREVGQ VVMVC83ZS82ODAzMjQtZWUxZi00MGYyLTg4ZGYtMTk2OTMxOTYyZDNjLzEvZjNjMDMtb1 NCbGRCTHFobjNieDdoTkV5djNnLm1mdDCByQQgzf5YvEOPZX+mp3dluVc0p6gck4cqBkM jM9mp6pdKk50CAgfOBBR/8XrlR7nyZB5gV3/lU92290mghwICBJUYDzIwMjUxMjAyMDUw MTAxWjB2MHQGCCsGAQUFBzALhmhycGtpLnJpcGUubmV0L3JlcG9zaXRvcnkvREVGQVVMV C9hNS8xYmMwZjktYmQ3Yy00ZjdhLWE0MDQtYTQzZmYyNWQ0NDdkLzEvZl9GNjVVZTU4bV FlWUZkXzVWUGR0dmRKb0ljLm1mdDCByQQg2WWHA7kZ1lFtufHhoKOWQJnNNOqe1dZiREa kbo6PnDQCAgfOBBR/TVkcI60saUd9f3odTOjrzulZbAICBbAYDzIwMjUxMjAyMDUwMDUx WjB2MHQGCCsGAQUFBzALhmhycGtpLnJpcGUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC8zZ S8wZDY3YTItYmMzNi00YjkzLWI2MDQtZDRmNWM5MmQ5MDk1LzEvZjAxWkhDT3RMR2xIZl g5NkhVem82ODdwV1d3Lm1mdDCByQQg2wZZFXRyyeT6Hr9UPTqG+kndFcQa7iQ8lvSNn2t w1EYCAggYBBR/A6H4wzT9v0t43vDFkv8EkN30sAICFw4YDzIwMjUxMjAyMDMwMTEzWjB2 MHQGCCsGAQUFBzALhmhycGtpLnJpcGUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC82Ni8zZ mUxYTAtYzZmZC00YmM0LWFhZTEtOWVlMDA2OTQyYjRiLzEvZndPaC1NTTBfYjlMZU43d3 haTF9CSkRkOUxBLm1mdDCByQQg5bw010O3isxfFbAcf68+pxZ5hotesydvvAjQWM0t5EE CAgfOBBR/Pgh0ie4jqUJNU/rCFu5LjgEoDgICFukYDzIwMjUxMjAyMDIwMTExWjB2MHQG CCsGAQUFBzALhmhycGtpLnJpcGUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC9jNi9jMmM5O WQtY2Y5MS00ZGZiLTk0ZGUtYTdjNjNkNTYyZTU2LzEvZno0SWRJbnVJNmxDVFZQNndoYn VTNDRCS0E0Lm1mdDCByQQg52O9fl2mAURiPvp/D/Lxg/qD94CMaHg1gP34sh6wpiACAgf OBBR/NdWuQX9F7oUF12zqobNMRYOUoAICEDEYDzIwMjUxMjAyMDcwMjE3WjB2MHQGCCsG AQUFBzALhmhycGtpLnJpcGUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC9lNi9jNTQ2N2ItM zk2Mi00Yjc0LWFlMGQtMzQ0NzNiYzkxZDgwLzEvZnpYVnJrRl9SZTZGQmRkczZxR3pURV dEbEtBLm1mdDCByQQg6so+VkKUIuwqe5qDv/wZ5Mt2jbINjE8muOBTc6lTIkACAgfOBBR /ao5dVcJJioJjb5n4/J4xngd3HgICEFgYDzIwMjUxMjAyMTAwMTQzWjB2MHQGCCsGAQUF BzALhmhycGtpLnJpcGUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC83NC8yN2ZjZTEtMTFjZ S00YTMyLWE2NDktZTA3NmI1MTcyMWFkLzEvZjJxT1hWWENTWXFDWTItWi1QeWVNWjRIZH g0Lm1mdDCByQQg7uUYDdaLWVx3C5NJxoSM8VliwnFEyUkZN8jWlrPCKDcCAgeEBBR/mRj KtvHzXvG15YPLKDnpt0ixWAICFCsYDzIwMjUxMjAyMDcwMjU4WjB2MHQGCCsGAQUFBzAL hmhycGtpLnJpcGUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC8yNi9kZjgyZmEtMTE4ZC00M jE5LWJhMTYtMWE5NjgzYzlkNmNiLzEvZjVrWXlyYng4MTd4dGVXRHl5ZzU2YmRJc1ZnLm 1mdDCByQQg7yfMJqn5pi7RM/A+RAbW8DpFIvpu6jcm+KCoB1tbaHkCAgeEBBR/iyGDWJg 6fXolOKnam6HzSU1xqwICAXwYDzIwMjUxMjAyMDQwMTU1WjB2MHQGCCsGAQUFBzALhmhy cGtpLnJpcGUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC9kOS83NmNkMDMtZWFhMi00OTY1L Tk0ZWYtOThkYmI2NDAyY2RkLzEvZjRzaGcxaVlPbjE2SlRpcDJwdWg4MGxOY2FzLm1mdD CByQQg76JcDN7fp3hgATQ70hlg9N95dWMEMjDUwl4LVJXyeJQCAgeEBBR/fl69b6RpxeN wv8EGxNSq0eHblAICD78YDzIwMjUxMjAyMDkwMDUxWjB2MHQGCCsGAQUFBzALhmhycGtp LnJpcGUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC8yMy9jM2U4ZWQtNTk3YS00ODVhLTk0Y TMtOTgyY2ZiMzU5YWVlLzEvZjM1ZXZXLWthY1hqY0xfQkJzVFVxdEhoMjVRLm1mdDCByQ Qg8nARwXE9Yjvm1l2w8HIxTfh+ukj7kz6ZWpLDErCzzcMCAgfOBBR/KjK6QhloDc3Vj2E B5ceuwVQKcwICF1cYDzIwMjUxMjAyMDcwMTQ3WjB2MHQGCCsGAQUFBzALhmhycGtpLnJp cGUubmV0L3JlcG9zaXRvcnkvREVGQVVMVC81NS8xNDNlOWUtOTZlNi00NzRlLWFkMmMtM jJlNmRmNDU4NGFmLzEvZnlveXVrSVphQTNOMVk5aEFlWEhyc0ZVQ25NLm1mdDCByQQg9a VdJNGRAi9S4ulD3UwiO5jZP+rvST2Rgy2AlEYwXwICAgilBBR/UV6tCV7tmsTKvFq0rQt YZ9nwGwICF2wYDzIwMjUxMjAyMDkwMTA3WjB2MHQGCCsGAQUFBzALhmhycGtpLnJpcGUu bmV0L3JlcG9zaXRvcnkvREVGQVVMVC9hNy81YzJhNTktNjAyNS00MDBlLWFiMjgtZjBhN jI0ZDQwOTEyLzEvZjFGZXJRbGU3WnJFeXJ4YXRLMExXR2ZaOEJzLm1mdDCByQQg+OfbRJ 5zLGiJD6PTAGFKK4J4ynf+/NV2x1xibYY3d20CAgfOBBR/0YpqSZEMwzHckRFK5ZtxhdX zDQICF1cYDzIwMjUxMjAyMDcwMTAzWjB2MHQGCCsGAQUFBzALhmhycGtpLnJpcGUubmV0 L3JlcG9zaXRvcnkvREVGQVVMVC9iYS8wOTQ3ZjItMjJjYS00N2NiLTg5YWQtM2U1MGE1Z jAxOTk4LzEvZjlHS2FrbVJETU14M0pFUlN1V2JjWVhWOHcwLm1mdDCByQQg/WXtWO4Uk0 axqFIkXli0D/e08zs5A0d2bWZbmwgnrJsCAgfOBBR/VoneSnznaL86tdn4VG6FbMsZNgI CF1YYDzIwMjUxMjAyMDMwMTA1WjB2MHQGCCsGAQUFBzALhmhycGtpLnJpcGUubmV0L3Jl cG9zaXRvcnkvREVGQVVMVC83Ny82NGQ1MDUtMjIwNC00ZGNhLWE5NWUtOGI1MzcyNTg0Y WNkLzEvZjFhSjNrcDg1MmlfT3JYWi1GUnVoV3pMR1RZLm1mdA==

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.