An Out-of-Band Setup Protocol for Resource Public Key Infrastructure (RPKI) Production Services
Extracted elements (24)
Handles are restricted to a simple ASCII character set (letters, digits, '/', '-', '_') rather than supporting internationalized text because handles are protocol elements, not human-readable labels, making simplicity more valuable than internationalization.
The BPKI (Business PKI) is entirely separate from the RPKI: it holds X.509 certificates used to authenticate CMS-wrapped provisioning and publication protocol messages, contains no RFC 3779 resources, and is likely to follow existing contractual relationships between parties.
The private keys corresponding to the exchanged BPKI CA certificates are not used to sign CMS messages directly; instead those CA certificates issue BPKI EE certificates included in CMS wrappers. This separation allows the static self-signed CA certificates exchanged during setup to remain long-lived while EE certificates can be rotated.
The recommended BPKI integration approach is to cross-certify a received self-signed public key under one's own BPKI using BasicConstraints cA=TRUE, pathLenConstraint=0, which permits the cross-certified cert to issue EE certificates but not further CA certificates. This keeps the BPKI structure simple while allowing CMS message verification.
The underlying transport for the setup protocol is deliberately unspecified. Messages may be exchanged via USB stick, HTTPS web interface, PGP-signed email, a QR code on a T-shirt, or a carrier pigeon — any means providing acceptable data integrity and authentication is acceptable.
Workshop experience showed that bundling service URLs and other configuration information into the same XML messages used for key exchange significantly simplifies setup compared to separate manual configuration steps.
The parent's child_handle in the <parent_response/> need not match the child's suggested child_handle. When they differ, the parent's value governs, because the parent dictates the names used in the provisioning protocol (sender/recipient fields in RFC 6492).
The publication referral chain is theoretically extensible indefinitely (a child can refer its own child to an ancestor's repository), but this has not been implemented or tested. The protocol deliberately ignores perverse cases such as restricting re-referral.
If the <child_request/> (or <publisher_request/>) message included a 'tag' attribute, the responder MUST include an identical 'tag' attribute in the response; if the request did not include a tag attribute, the response MUST NOT include a tag attribute.
Since the basic function of this protocol is key exchange, authentication and integrity of the key exchange MUST be ensured via external means deliberately left unspecified in this protocol.
The RELAX NG schema in Appendix A is normative: in the event of any disagreement between the schema and the textual description in the document body, the schema is authoritative.
A <referral/> element in <parent_response/> carries a 'referrer' attribute (the parent's handle at the repository), an optional 'contact_uri', and a Base64-encoded CMS-signed <authorization/> token granting the child permission to use a portion of the parent's publication namespace.
All messages use the XML namespace 'http://www.hactrn.net/uris/rpki/rpki-setup/' and carry a 'version' attribute; this document defines version 1. An incorrect version can be detected by direct attribute check or RELAX NG schema validation failure.
The <authorization/> element is a standalone XML message signed with CMS (eContentType id-ct-xml from RFC 6492). It carries an 'authorized_sia_base' rsync:// URI and the BPKI trust anchor of the authorized entity as Base64 text. It is embedded as the Base64 content of <referral/> elements.
The <child_request/> message carries the child's preferred handle (child_handle) and its self-signed BPKI CA certificate (<child_bpki_ta/>). It initiates the provisioning protocol relationship from child to parent.
The <error/> element is an optional response to any core message, carrying a 'reason' attribute with one of three codes: 'syntax-error', 'authentication-failure', or 'refused'. The body is a verbatim copy of the offending message.
The <parent_response/> message returns the provisioning service_uri, the parent's name for the child (child_handle), the parent's own handle (parent_handle), and the parent's self-signed BPKI CA certificate (<parent_bpki_ta/>). It may also include an <offer/> (direct publication service) or one or more <referral/> elements (third-party publication service).
The <publisher_request/> message carries the publisher's suggested handle (publisher_handle), its BPKI CA certificate (<publisher_bpki_ta/>), and optionally a <referral/> element (with referrer attribute and Base64 authorization token) received from a provisioning protocol parent.
The <repository_response/> message returns the publication service_uri, the repository's name for the publisher (publisher_handle), the rsync:// sia_base URI for the allocated publication space, an optional rrdp_notification_uri for RRDP coverage, and the repository's BPKI CA certificate (<repository_bpki_ta/>).
The protocol itself provides no authentication or integrity mechanism for the XML message exchange. These properties MUST be provided entirely by external means, which will typically tie directly to a new or existing business relationship between the parties.
A 'handle' attribute is a US-ASCII string of letters, digits, '/', '-', and '_', with a maximum length of 255 characters. Handles are protocol elements with no mandated semantic structure, and the restricted character set avoids the complexity of internationalized text rules.
An optional 'tag' attribute may be included in client request messages; it is an opaque xsd:token of maximum length 1024 characters. The server echoes it back unchanged to help the client correlate responses to outstanding requests.
BPKI X.509 certificates are carried as XML text nodes containing the Base64 encoding (RFC 4648 Section 4, line breaks permitted but not required) of the DER representation of the certificate. The schema limits this to maxLength=512000 base64Binary characters.
The authorization token is a CMS SignedData object using eContentType id-ct-xml, with the signer's BPKI EE certificate in the CMS wrapper. Recipients verify the CMS signature against the referrer's BPKI CA certificate and confirm the enclosed BPKI TA matches the prospective publisher's identity.