RFC 8183

An Out-of-Band Setup Protocol for Resource Public Key Infrastructure (RPKI) Production Services

📅 published July 2017, from ietf

RFC 8183 💖 (Internet Engineering Task Force, IETF)

Author: R. Austein, Dragon Research Labs Category: Standards Track Date: July 2017 ISSN: 2070-1721 Obsoletes and updates: the header doesn't list any

An Out-of-Band Setup Protocol for Resource Public Key Infrastructure (RPKI) Production Services ✨

Abstract 🎀

Okay so this note describes a simple out-of-band protocol that makes it way easier to set up the RPKI provisioning and publication protocols between two parties 🫶. It's encoded in a small number of XML messages, and you can pass them back and forth by any mutually agreeable means that gives acceptable data integrity and authentication 💅.

This setup protocol is not part of the provisioning or publication protocol. It's really there to make those protocols easier to configure, by setting up relationships and swapping the keying material used to authenticate them 🔐.

Status of This Memo 🌸

This is an Internet Standards Track document, and it's a product of the IETF. It represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check Section 2 of RFC 7841.

You can find the current status of this document, any errata, and how to send feedback at http://www.rfc-editor.org/info/rfc8183.

Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication. Please read these documents carefully, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they are provided without warranty as described in the Simplified BSD License.

Table of Contents 🗺️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
3.  History . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
4.  Overview of the BPKI  . . . . . . . . . . . . . . . . . . . .   4
5.  Protocol Elements . . . . . . . . . . . . . . . . . . . . . .   6
  5.1.  Common Protocol Elements  . . . . . . . . . . . . . . . .   6
  5.2.  Protocol Messages . . . . . . . . . . . . . . . . . . . .   7
    5.2.1.  <child_request/>  . . . . . . . . . . . . . . . . . .   7
    5.2.2.  <parent_response/>  . . . . . . . . . . . . . . . . .   8
    5.2.3.  <publisher_request/>  . . . . . . . . . . . . . . . .  10
    5.2.4.  <repository_response/>  . . . . . . . . . . . . . . .  11
  5.3.  <authorization/>  . . . . . . . . . . . . . . . . . . . .  12
  5.4.  <error/>  . . . . . . . . . . . . . . . . . . . . . . . .  13
6.  Protocol Walk-Through . . . . . . . . . . . . . . . . . . . .  14
7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
8.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  20
  9.1.  Normative References  . . . . . . . . . . . . . . . . . .  20
  9.2.  Informative References  . . . . . . . . . . . . . . . . .  21
Appendix A.  RELAX NG Schema  . . . . . . . . . . . . . . . . . .  22
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  23
Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  23

1. Introduction 💫

This note describes a small XML-based out-of-band protocol. It's used to set up relationships between parents and children in the RPKI provisioning protocol [RFC6492], and between publishers and repositories in the RPKI publication protocol [RFC8181] 🧚.

The basic job of this protocol is public key exchange, in the form of self-signed X.509 certificates. But workshop experience showed it's way simpler for the user if we also bundle the other configuration info needed to bring up a new player into the same messages used for the key exchange 🍓.

The underlying transport is deliberately left unspecified. It might be a USB stick, a web interface secured with conventional HTTPS, PGP-signed email, a T-shirt printed with a Quick Response (QR) code, or a carrier pigeon 🐦. Iconic range, honestly.

Since so much of this protocol is about key exchange, authentication and integrity of that exchange MUST be ensured via external means. Typically, those means will tie directly to a new or existing business relationship 🤝.

2. Terminology 📚

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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

All of the protocols this setup protocol configures have their own terminology for their actors, but in this context that terminology gets kinda confusing 🙃. Everyone in this setup protocol issues certificates, is the subject of other certificates, operates servers, and, in most cases, acts as a client for one protocol or another. So this note uses its own terms for the actors in this protocol 💜.

  • Child: An entity acting in the client ("subject") role of the provisioning protocol defined in [RFC6492].
  • Parent: An entity acting in the server ("issuer") role of the provisioning protocol defined in [RFC6492].
  • Publisher: An entity acting in the client role of the publication protocol defined in [RFC8181].
  • Repository: An entity acting in the server role of the publication protocol defined in [RFC8181].

A given entity might act in more than one of these roles. For example, in one of the simplest cases, the child is the same entity as the publisher, while the parent is the same entity as the repository 👑.

3. History 🕰️

The protocol in this document grew out of a series of workshops held starting in 2010. At those workshops it became clear that manual configuration of keying material and service URLs was both error prone and unnecessarily confusing 😭. The basic mechanism and semantics have been essentially unchanged since the earliest versions of the protocol. There were several workshop-driven syntax changes and simplifications before the protocol made its way into the IETF, and a few more simplifications and minor extensions have happened since then ✨.

4. Overview of the BPKI 🔑

Several protocols related to RPKI provisioning use signed Cryptographic Message Syntax (CMS) messages [RFC5652] to authenticate the underlying XML-based protocols. Verifying these CMS messages requires X.509 certificates. The PKI that holds these certificates is distinct from the RPKI and contains no RFC 3779 resources. This document calls it the "Business PKI" (BPKI), to tell it apart from the RPKI. The "B" is a hint that certificate relationships in the BPKI are likely to follow, and become part of, existing contractual relationships between the issuers and subjects of this PKI 💼.

The RPKI provisioning protocol doesn't dictate a particular structure for the BPKI. The only basic requirement is that one party can sign and the other party can verify the CMS messages. That leaves some flexibility, so an Internet registry can reuse an existing PKI as its BPKI if that makes sense in their context 🧩.

To keep this protocol simple, we adopt a somewhat constrained model of the BPKI. The first two operations in this protocol are an exchange of public keys between child and parent, for use in the provisioning protocol. The latter two operations are an exchange of public keys between publisher and repository, for use in the publication protocol. In each of these operations, the sending party includes its public key, in the form of a self-signed X.509 Certification Authority (CA) certificate. The private keys behind the exchanged certificates are not used to sign CMS messages directly. Instead, the exchanged CA certificates are the issuers of the BPKI end-entity (EE) certificates that go into the CMS messages, and they can be used, along with the exchanged certificates, to verify those messages 🫧.

Details of how to tie the exchanged certificates into an implementation's local BPKI are left to the implementation. But the recommended approach is to cross-certify the received public key and subject name under one's own BPKI, using a Basic Constraints extension with cA = TRUE, pathLenConstraint = 0. That marks the cross-certified certificate as a CA certificate which is allowed to issue EE certificates but is not allowed to issue CA certificates. See Section 4.2.1.9 of [RFC5280] for more information about the Basic Constraints extension 🧠.

For example, suppose that Alice and Bob each have their own self-signed BPKI certificates:

Issuer:       CN = Alice CA
Subject:      CN = Alice CA
Public Key:   [Alice CA Public Key]
BasicConstraints: cA = TRUE

Issuer:       CN = Bob CA
Subject:      CN = Bob CA
Public Key:   [Bob CA Public Key]
BasicConstraints: cA = TRUE

Alice sends Bob her self-signed BPKI certificate, and Bob cross certifies its public key and subject name under Bob's own self-signed BPKI certificate:

Issuer:       CN = Bob CA
Subject:      CN = Alice CA
Public Key:   [Alice CA Public Key]
BasicConstraints: cA = TRUE, pathLenConstraint = 0

Later, when Bob receives a CMS message from Alice, Bob can verify it via a trust chain back to Bob's own trust anchor:

Issuer:       CN = Alice CA
Subject:      CN = Alice EE
Public Key:   [Alice EE Public Key]

A complete description of the certificates allowed here is beyond the scope of this document 🙅. It's determined mostly by what's acceptable to the several other protocols this one is setting up. We also expect the requirements to change over time, to track changes in cryptographic algorithms, required key length, and so forth. Finally, since this protocol is restricted to setting up pairwise relationships, all that's really required is that the two parties in a particular conversation agree on what counts as an acceptable certificate 🤍.

That said, in practice, the certificates exchanged by this protocol at the time this document was written are what a reader familiar with the technology would probably expect. That means RSA keys in the 2048-4096 bit range, SHA-2 digests, and a few common X.509v3 extensions (mainly Basic Constraints, Authority Key Identifier, and Subject Key Identifier) 🌈. Since the most likely usage is cross-certification, where the recipient checks the self-signature, pulls out the subject name and public key, and discards the rest of the incoming certificate, the practical value of esoteric X.509v3 extensions is pretty limited 💅.

5. Protocol Elements ✨

Okay bestie, every message in this protocol is its own distinct XML element, and they all live in the http://www.hactrn.net/uris/rpki/rpki-setup/ XML namespace. 💖

The outermost XML element of each message has a version attribute. This doc describes version 1 🎀

Appendix A is a [RELAX-NG] schema for this protocol. The schema is normative, so if it disagrees with the text below, the schema wins. The schema is authoritative 👑

Since "1" is currently the only value allowed for the version attribute in the schema, an incorrect protocol version can be caught either by checking the version attribute directly or as a schema validation error. Two ways to catch the same mistake, iconic 🧚

5.1. Common Protocol Elements

Most messages contain, among other things, a self-signed BPKI X.509 certificate. These certificates are represented as XML elements whose text value is the Base64 text ([RFC4648], Section 4, with line breaks within the Base64 text permitted but not required) encoding the DER representation of the X.509 certificate. 🔐

A number of attributes contain "handles". A handle in this protocol is a text string in the US-ASCII character set made of letters, digits, and the special characters "/", "-", and "_". This protocol places no special semantics on the structure of these handles, although implementations might. Handles are protocol elements, not necessarily meaningful to humans, so a restricted character set makes more sense than the complicated rules you'd need for internationalized text. Simple is slay ✨

Most messages allow an optional "tag" attribute. This is an opaque cookie supplied by the client in a particular exchange and echoed by the server. The intent is to make it easier to match a response the client receives with an outstanding request. It's like a little name tag so nobody gets mixed up 🎀

5.2. Protocol Messages

The core of this protocol is four message types. They cover the basic request and response semantics needed to configure an RPKI engine to talk to its parent and its repository, via the provisioning and publication protocols respectively. The whole squad, honestly 💅

5.2.1. <child_request/>

The <child_request/> message is an initial setup request from a provisioning protocol child to its provisioning protocol parent. It's the "hi, I'm new here" message 🦋

Fields in the <child_request/> message:

  • version: The version attribute specifies the protocol version. This note describes protocol version 1.
  • tag: The child MAY include a "tag" attribute in the request message. 🌸
  • child_handle: The child_handle attribute is what the child calls itself. This is just a hint from the child to the parent, and the parent need not honor it.
  • child_bpki_ta: The <child_bpki_ta/> element is the child's BPKI identity, a self-signed X.509 BPKI certificate, encoded in Base64.

This CA certificate will be the issuer of the BPKI EE certificates corresponding to private keys that the child will use when sending provisioning protocol messages to the parent. Main character energy for this cert, no cap 👑

<child_request
    xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/"
    version="1"
    child_handle="Bob">
  <child_bpki_ta>
    R29kIGlzIHJlYWwgdW5sZXNzIGRlY2xhcmVkIGludGVnZXI=
  </child_bpki_ta>
</child_request>

5.2.2. <parent_response/>

The <parent_response/> message is a response from a provisioning protocol parent to a provisioning protocol child that had previously sent a <child_request/> message. It's the parent saying "okay bestie, you're in" 💖

Fields in the <parent_response/> message:

  • version: The version attribute specifies the protocol version. This note describes protocol version 1.
  • tag: If the <child_request/> message included a "tag" attribute, the parent MUST include an identical "tag" attribute in the <parent_response/> message. If the request did not include a tag attribute, the response MUST NOT include a tag attribute either. Matching tags, or no tags at all, that's the rule 🎀
  • service_uri: The service_uri attribute contains an HTTP or HTTPS URL [RFC7230] that the child should contact for up-down [RFC6492] service.
  • child_handle: The child_handle attribute is the parent's name for the child. This MAY match the child_handle from the <child_request/> message. If they do not match, the parent wins, because the parent gets to dictate the names in the provisioning protocol. This value is the sender field in provisioning protocol request messages and the recipient field in provisioning protocol response messages. The parent is literally the boss of names 💅
  • parent_handle: The parent_handle attribute is the parent's name for itself. This value is the recipient field in provisioning protocol request messages and the sender field in provisioning protocol response messages.
  • parent_bpki_ta: The <parent_bpki_ta/> element is the parent's BPKI identity, a self-signed X.509 BPKI certificate.

This certificate is the issuer of the BPKI EE certificates corresponding to private keys that the parent will use to sign provisioning protocol messages to the child. 🧚

  • offer: If an <offer/> element is present, the parent is offering publication service to the child. The <offer/> element, if present, is empty. Just vibes, no content 🦋
  • referral: If <referral/> elements are present, they suggest third-party publication services which the child might use, and contain:
    • referrer: A referrer attribute, containing the handle by which the publication repository knows the parent.
    • contact_uri: An optional contact_uri attribute that the child may be able to follow for more information.
    • Authorization token: The text of the <referral/> element is the Base64 encoding of a signed authorization token granting the child the right to use a portion of the parent's namespace at the publication repository in question. See Section 5.3 for details on the authorization token. 🔥

A parent is unlikely to need to send both <offer> and <referral> elements, but strictly speaking they are not mutually exclusive. So a parent that really needs to say it both offers repository service to its child and is also willing to refer its child to one or more other repository servers can do exactly that. Multitasking parent era 🌈

<parent_response
    xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/"
    version="1"
    service_uri="http://a.example/up-down/Alice/Bob-42"
    child_handle="Bob-42"
    parent_handle="Alice">
  <parent_bpki_ta>
    WW91IGNhbiBoYWNrIGFueXRoaW5nIHlvdSB3YW50IHdpdGggVEVDTyBhbmQgRERU
  </parent_bpki_ta>
  <offer/>
</parent_response>
<parent_response
    xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/"
    version="1"
    service_uri="http://bob.example/up-down/Bob/Carol"
    child_handle="Carol"
    parent_handle="Bob">
  <parent_bpki_ta>
    R29kIGlzIHJlYWwgdW5sZXNzIGRlY2xhcmVkIGludGVnZXI=
  </parent_bpki_ta>
  <referral
      referrer="Alice/Bob-42">
    R28sIGxlbW1pbmdzLCBnbyE=
  </referral>
</parent_response>

5.2.3. <publisher_request/>

The <publisher_request/> message is a setup request from a publisher to a repository. Generally, this won't happen until after the publisher has set up the provisioning protocol through a <child_request/> / <parent_response/> exchange. In particular, the <referral> sub-element here needs an <authorization/> token provided by the provisioning protocol exchange. So the order matters, the glow-up has steps 🍓

Fields in the <publisher_request/> message:

  • version: The version attribute specifies the protocol version. This note describes protocol version 1.
  • tag: The publisher MAY include a "tag" attribute in the request message. 🌸
  • publisher_handle: The publisher_handle attribute is the publisher's name for itself. This is just a hint; the repository need not honor it.
  • publisher_bpki_ta: The <publisher_bpki_ta/> element is the publisher's BPKI identity, a self-signed X.509 BPKI certificate. This certificate is the issuer of the BPKI EE certificates corresponding to private keys that the publisher will use to sign publication protocol messages to the repository. 💜
  • referral: If a <referral/> element is present, it contains:
    • referrer: A referrer attribute containing the publication handle of the referring parent.
    • Authorization token: The text of the <referral/> element is the Base64 encoding of a signed authorization token granting the publisher the right to use a portion of its parent's namespace at this repository. See Section 5.3 for details on the authorization token.

These fields are copies of values that a parent provided to the child in the <parent_response/> message (see Section 5.2.2). The referrer attribute is present to help the repository look up the corresponding certificate. Note that the repository operator makes the final decision on whether to grant publication service to the prospective publisher. The <referral/> element just conveys a parent's grant of permission to use a portion of that parent's namespace. The repo gets the final say, periodt 💅

<publisher_request
    xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/"
    version="1"
    tag="A0001"
    publisher_handle="Bob">
  <publisher_bpki_ta>
    R29kIGlzIHJlYWwgdW5sZXNzIGRlY2xhcmVkIGludGVnZXI=
  </publisher_bpki_ta>
</publisher_request>

5.2.4. <repository_response/> 🎀

okay so the <repository_response/> message is the repository's reply 💌 to a publisher that already sent a <publisher_request/> message. it's giving "thanks for asking, here's everything you need" 🌸

Fields in the <repository_response/> message:

  • version: The version attribute specifies the protocol version. This note describes protocol version 1. ✨
  • tag: If the <publisher_request/> message included a "tag" attribute, the repository MUST include an identical "tag" attribute in the <repository_response/> message. If the request did not include a tag attribute, the response MUST NOT include a tag attribute either. 🫶 this one is super picky, so double check it!!
  • service_uri: The service_uri attribute contains an HTTP or HTTPS URL [RFC7230] that the publisher should contact for publication service [RFC8181]. 🦋
  • publisher_handle: The publisher_handle attribute is the repository's name for the publisher. This may or may not match the publisher_handle attribute in the publisher's <publisher_request/> message. 🙈 different names are totally allowed, lowkey.
  • sia_base: The sia_base attribute is the rsync:// URI for the base of the publication space allocated to the publisher. 📂
  • rrdp_notification_uri: The optional rrdp_notification_uri attribute is the URI for the RPKI Repository Delta Protocol (RRDP) notification file covering the publication space allocated to the publisher [RFC8182]. 🌈
  • repository_bpki_ta: The <repository_bpki_ta/> element is the repository's BPKI identity, a self-signed X.509 BPKI certificate. 🔐
<repository_response
    xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/"
    version="1"
    tag="A0001"
    service_uri="http://a.example/publication/Alice/Bob-42"
    publisher_handle="Alice/Bob-42"
    sia_base="rsync://a.example/rpki/Alice/Bob-42/"
    rrdp_notification_uri="https://rpki.example/rrdp/notify.xml">
  <repository_bpki_ta>
    WW91IGNhbiBoYWNrIGFueXRoaW5nIHlvdSB3YW50IHdpdGggVEVDTyBhbmQgRERU
  </repository_bpki_ta>
</repository_response>

5.3. <authorization/> 🧚

okay the <authorization/> element is its own separate message 💅. it gets signed with CMS, and then it rides along as the Base64 content of <referral/> elements in other messages. so it's basically a permission slip that travels inside other messages 💜

The eContentType for the signed CMS message is id-ct-xml [RFC6492].

Fields in the <authorization/> element:

  • version: The version attribute specifies the protocol version. This note describes protocol version 1. ✨
  • authorized_sia_base: The value of the authorized_sia_base attribute is the rsync:// URI of the base of the namespace which the referrer is delegating. 🗂️
  • BPKI TA: The text of the <authorization/> element is the identity of the entity to whom the referrer is delegating the portion of the namespace named in the authorized_sia_base attribute, represented as a Base64-encoded self-signed X.509 BPKI certificate. 🎁 so this is who gets the keys to the kingdom, bestie 👑
<authorization
    xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/"
    version="1"
    authorized_sia_base="rsync://a.example/rpki/Alice/Bob-42/Carol/">
  SSd2ZSBoYWQgZnVuIGJlZm9yZS4gIFRoaXMgaXNuJ3QgaXQu
</authorization>

5.4. <error/> 💀

the <error/> element is an optional message 🙈 you can send it back in response to any of the core protocol messages from Section 5.2.

whether an <error/> element is the right move for signalling errors back to the sender depends on details of the implementation, and those details are outside this specification 🌸. for example, if this protocol is wrapped in a web portal where a human uploads and downloads messages through forms, a human-readable error message might be more fitting 💖. on the flip side, a portal built for a robot client might totally want to use an <error/> message 🤖. same vibe for non-web stuff like email or a USB stick. the main question is whether the implementation expects a human or a program to handle the error ✨

Fields in the <error/> message:

  • version: The version attribute specifies the protocol version. This note describes protocol version 1. ✨
  • reason: The reason attribute contains a code indicating what was wrong with the message. This version of the protocol defines the following codes:
    • syntax-error: Receiver could not parse the offending message. 🫠
    • authentication-failure: Receiver could not authenticate the offending message. 🔒
    • refused: Receiver refused to perform the requested action. 🚫
  • Offending message: The <error/> element contains a verbatim copy of the message to which this error applies. 🪞 it's giving receipts, literally
<error
    xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/"
    version="1"
    reason="refused">
  <child_request
      xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/"
      version="1"
      child_handle="Carol">
    <child_bpki_ta>
      SSd2ZSBoYWQgZnVuIGJlZm9yZS4gIFRoaXMgaXNuJ3QgaXQu
    </child_bpki_ta>
  </child_request>
</error>

6. Protocol Walk-Through ✨

okay bestie, this section walks through a few simple examples of the protocol in use, and it stars our old faves Alice, Bob, and Carol 💖. Alice is the root of an RPKI tree 🌳. Bob wants address and Autonomous System Number (ASN) resources from Alice, and then Carol wants some of those resources from Bob 🙈. Alice offers publication service, and all three of them use it 🫶.

Alice, Bob, and Carol each generate their own self-signed BPKI certificate 🎀.

Bob builds a <child_request/> message and sends it to Alice 💌:

<child_request
    xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/"
    version="1"
    child_handle="Bob">
  <child_bpki_ta>
    R29kIGlzIHJlYWwgdW5sZXNzIGRlY2xhcmVkIGludGVnZXI=
  </child_bpki_ta>
</child_request>
  • Bob's preferred handle is "Bob", so he uses that for child_handle 🍓.
  • <child_bpki_ta/> is Bob's self-signed BPKI certificate 🔐.

Alice replies with a <parent_response/> message 💅. Alice already has 41 other children named Bob, so she calls this one "Bob-42" 💀. Her provisioning protocol server uses a RESTful URL scheme, so it can find the expected validation context for the provisioning protocol CMS message just by looking at the URL. That's why the service URL she gives Bob includes both her name and Bob's 🧚. Alice also offers publication service. She doesn't have to do this, since she could leave it out and let Bob find publication service on his own, but Alice is being extra helpful to her customer Bob 🌸. Bob doesn't have to accept the offer, but he's allowed to ✨.

<parent_response
    xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/"
    version="1"
    service_uri="http://a.example/up-down/Alice/Bob-42"
    child_handle="Bob-42"
    parent_handle="Alice">
  <parent_bpki_ta>
    WW91IGNhbiBoYWNrIGFueXRoaW5nIHlvdSB3YW50IHdpdGggVEVDTyBhbmQgRERU
  </parent_bpki_ta>
  <offer/>
</parent_response>
  • <parent_bpki_ta/> is Alice's own self-signed BPKI certificate 👑.

Bob takes the <parent_response/> from Alice and pulls out the fields his RPKI engine needs to know about: child_handle, parent_handle, service_uri, and <parent_bpki_ta/> 📝. He also sees the repository offer, decides to take Alice up on it, and builds a <publisher_request/> message to match 🦋:

<publisher_request
    xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/"
    version="1"
    tag="A0001"
    publisher_handle="Bob">
  <publisher_bpki_ta>
    R29kIGlzIHJlYWwgdW5sZXNzIGRlY2xhcmVkIGludGVnZXI=
  </publisher_bpki_ta>
</publisher_request>

Alice gets Bob's request to use her publication service, honors the offer she made, and sends back a <repository_response/> 🥹. She recognizes Bob as one of her own children, because she has already seen his self-signed BPKI certificate. So she allocates publication space to him under her own publication space 🗂️. That way, relying parties who rsync her products will pick up Bob's products automatically, with no extra fetch operation needed ✨.

<repository_response
    xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/"
    version="1"
    tag="A0001"
    service_uri="http://a.example/publication/Alice/Bob-42"
    publisher_handle="Alice/Bob-42"
    sia_base="rsync://a.example/rpki/Alice/Bob-42/"
    rrdp_notification_uri="https://rpki.example/rrdp/notify.xml">
  <repository_bpki_ta>
    WW91IGNhbiBoYWNrIGFueXRoaW5nIHlvdSB3YW50IHdpdGggVEVDTyBhbmQgRERU
  </repository_bpki_ta>
</repository_response>

Bob should now have everything he needs to talk to Alice for both provisioning and publication 🎉.

Now for the more interesting case: Bob's child, Carol 🧁. Carol wants her resources from Bob, and like Bob, she doesn't really want to run a publication service 🙅‍♀️. Bob doesn't have a publication service of his own, but he can refer Carol to Alice. He also gives Carol permission to use a portion of the namespace that Alice gave him 💜.

Carol's <child_request/> to Bob looks super similar to Bob's earlier request to Alice 👯‍♀️:

<child_request
    xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/"
    version="1"
    child_handle="Carol">
  <child_bpki_ta>
    SSd2ZSBoYWQgZnVuIGJlZm9yZS4gIFRoaXMgaXNuJ3QgaXQu
  </child_bpki_ta>
</child_request>

Bob's <parent_response/> to Carol also looks a lot like Alice's response to Bob. The difference is that Bob includes a <referral/> element instead of an <offer/> element 🔁. Carol is an only child, so Bob leaves her name alone 🫧:

<parent_response
    xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/"
    version="1"
    service_uri="http://bob.example/up-down/Bob/Carol"
    child_handle="Carol"
    parent_handle="Bob">
  <parent_bpki_ta>
    R29kIGlzIHJlYWwgdW5sZXNzIGRlY2xhcmVkIGludGVnZXI=
  </parent_bpki_ta>
  <referral
      referrer="Alice/Bob-42">
    R28sIGxlbW1pbmdzLCBnbyE=
  </referral>
</parent_response>

Bob's response has a <referral/> element with a referrer attribute of "Alice/Bob-42", since that's Bob's name in Alice's repository 🗺️. The Base64-encoded authorization token is an <authorization/> element inside a CMS message. You can verify it against Bob's self-signed BPKI certificate, using a BPKI EE certificate that's included in the CMS wrapper 🔍. The text of the <authorization/> element is Carol's self-signed BPKI certificate. Bob's signature over this element shows his permission for Carol to use the indicated portion of Bob's publication space ✍️.

<authorization
    xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/"
    version="1"
    authorized_sia_base="rsync://a.example/rpki/Alice/Bob-42/Carol/">
  SSd2ZSBoYWQgZnVuIGJlZm9yZS4gIFRoaXMgaXNuJ3QgaXQu
</authorization>

Carol doesn't want to run a publication service, so she shows Bob's referral to Alice and hopes Alice will let her use Alice's publication service 🤞. Carol builds a <publisher_request/> message that includes the referral information she got from Bob, and sends it all to Alice 📦:

<publisher_request
    xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/"
    version="1"
    tag="A0002"
    publisher_handle="Carol">
  <publisher_bpki_ta>
    SSd2ZSBoYWQgZnVuIGJlZm9yZS4gIFRoaXMgaXNuJ3QgaXQu
  </publisher_bpki_ta>
  <referral
      referrer="Alice/Bob-42">
    R28sIGxlbW1pbmdzLCBnbyE=
  </referral>
</publisher_request>

Alice sees the signed authorization token that Bob gave Carol, checks its signature, and unpacks it 🔎. When the signature checks out and the BPKI trust anchor (TA) inside it matches Carol's, Alice knows Bob is willing to let Carol use part of Bob's namespace 🥰. Because of that, Alice is willing to give Carol publication service in the subtree Bob set aside for this purpose. So she sends back a <repository_response/> 🎀:

<repository_response
    xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/"
    version="1"
    tag="A0002"
    service_uri="http://a.example/publication/Alice/Bob-42/Carol"
    publisher_handle="Alice/Bob-42/Carol"
    sia_base="rsync://a.example/rpki/Alice/Bob-42/Carol/">
  <repository_bpki_ta>
    WW91IGNhbiBoYWNrIGFueXRoaW5nIHlvdSB3YW50IHdpdGggVEVDTyBhbmQgRERU
  </repository_bpki_ta>
</repository_response>

Once Carol gets this response, she should be good to go 🚀.

In theory, the publication referral mechanism can keep going indefinitely. For example, Carol can refer her child Dave to Alice for publication service, and it should all work 🌀. In practice, that hasn't been implemented yet, let alone tested 😅. To keep the protocol relatively simple, we've deliberately ignored tricky cases, such as Bob being willing to refer Carol to Alice but not wanting Carol to be allowed to refer Dave to Alice 🙃.

Any RPKI operator is free to run their own publication service if they feel the need, and a child doesn't have to accept any particular <offer/> or <referral/> 🫶. In general, having fewer, larger publication repositories is probably good for overall system performance. That's because it tends to reduce the number of distinct repositories each relying party has to fetch from 📉. But deciding where to publish is up to the individual RPKI CA operators, and it's out of scope for this protocol 🤷‍♀️.

7. IANA Considerations 🌷

this document does not require any IANA actions, so there's nothing for IANA to do here 🙌.

8. Security Considerations 🔐

okay, this part is SERIOUS 😭. As mentioned in Section 1, the basic function of this protocol is exchanging public keys to be used as BPKI trust anchors. The integrity and authentication of these exchanges MUST be ensured through external mechanisms that this protocol deliberately leaves unspecified 🚨. So don't skip that part, bestie 💀.

9. References 📚

9.1. Normative References 📚✨

okay so these are the docs the spec needs you to have read first, bestie 🧚 no skipping!!

9.2. Informative References 🌸

these ones are more like bonus reading. helpful for context, but the spec doesn't need them to make sense 💅

Appendix A. RELAX NG Schema 🎀

okay this is the big one, the RELAX NG schema describing all the protocol elements we just walked through 🦋 it's the source of truth!! and I mean it: this schema is normative 🔥 so if it ever disagrees with what the text says above, the schema wins. no debate, periodt 💅

default namespace = "http://www.hactrn.net/uris/rpki/rpki-setup/"

version = "1"

base64  = xsd:base64Binary { maxLength="512000" }
handle  = xsd:string { maxLength="255" pattern="[\-_A-Za-z0-9/]*" }
uri     = xsd:anyURI { maxLength="4096" }
any     = element * { attribute * { text }*, ( any | text )* }
tag     = xsd:token { maxLength="1024" }

authorization_token = base64
bpki_ta = base64

start |= element child_request {
  attribute version { version },
  attribute child_handle { handle },
  attribute tag { tag }?,
  element child_bpki_ta { bpki_ta }
}

start |= element parent_response {
  attribute version { version },
  attribute service_uri { uri },
  attribute child_handle { handle },
  attribute parent_handle { handle },
  attribute tag { tag }?,
  element parent_bpki_ta { bpki_ta },
  element offer { empty }?,
  element referral {
    attribute referrer { handle },
    attribute contact_uri { uri }?,
    authorization_token
  }*
}

start |= element publisher_request {
  attribute version { version },
  attribute publisher_handle { handle },
  attribute tag { tag }?,
  element publisher_bpki_ta { bpki_ta },
  element referral {

    attribute referrer { handle },
    authorization_token
  }*
}

start |= element repository_response {
  attribute version { version },
  attribute service_uri { uri },
  attribute publisher_handle { handle },
  attribute sia_base { uri },
  attribute rrdp_notification_uri { uri }?,
  attribute tag { tag }?,
  element repository_bpki_ta { bpki_ta }
}

start |= element authorization {
  attribute version { version },
  attribute authorized_sia_base { uri },
  bpki_ta
}

start |= element error {
  attribute version { version },
  attribute reason {
    "syntax-error" |
    "authentication-failure" |
    "refused"
  },
  any?
}

Acknowledgements 🫶

huge thank-yous to the squad who helped make this happen: Byron Ellacott, George Michaelson, Leif Johansson, Matsuzaki Yoshinobu, Michael Elkins, Randy Bush, Seiichi Kawamura, and Tim Bruijnzeels 💖 and to anybody else who helped along the way but whose name the author has temporarily forgotten 😭 we see you, bestie 🌈

Author's Address 🦋

Rob Austein Dragon Research Labs

Email: sra@hactrn.net

📦 where this page comes from