A Publication Protocol for the Resource Public Key Infrastructure (RPKI)
Extracted elements (27)
Consolidated RPKI publication repositories are operationally useful because they save every participant from maintaining a 24x7 service and allow relying parties to retrieve objects from a smaller number of repositories, improving speed and reliability.
The authentication and message integrity architecture reuses the Business PKI (BPKI) infrastructure from RFC 6492 because the participants are the same CA engines; this allows reuse of existing BPKI infrastructure and avoids introducing a new PKI.
The <publish/> and <withdraw/> PDUs use a generic common message format specifically to allow the protocol to accommodate new types of RPKI objects without requiring changes to the publication protocol itself.
The Standards Track version preserves the original XML namespace and protocol version scheme (version 4) to maintain backwards compatibility with running code implemented against older versions of the specification.
The CMS encapsulation used by the publication protocol is identical to that specified in Section 3.1 of RFC 6492, using CMS OID 1.2.840.113549.1.7.2, enabling reuse of existing implementations.
The publication protocol itself is not visible to relying parties; they see only the public interface of the publication server, which is an rsync or RRDP (RFC 8182) server.
A <list/> query MUST be the only PDU in a query message — it may not be combined with any <publish/> or <withdraw/> queries.
An implementation that understands only version 4 MUST reject messages with a different protocol version attribute, signaling the error as described in Section 2.4.
For <withdraw/> PDUs, the 'hash' attribute MUST be present. For <publish/> PDUs overwriting an existing object, the hash MUST be present; when writing to a new URI, the hash MUST NOT be present.
Presence of an existing object when no 'hash' attribute has been specified, absence of an object when a hash is specified, or an incorrect hash value MUST be reported using the <report_error/> PDU.
Processing of a query message is handled atomically: either the entire query succeeds or none of it does. When a query contains multiple PDUs, failure of any PDU may require the server to roll back actions triggered by earlier PDUs.
The 'tag' attribute of a <report_error/> PDU associated with a <publish/> or <withdraw/> PDU MUST be set to the same value as the 'tag' attribute of the PDU that generated the error.
A query PDU may be one of three types: <publish/>, <withdraw/>, or <list/>. A reply PDU may be one of three types: <success/>, <list/>, or <report_error/>.
Defined error codes are: xml_error, permission_failure, bad_cms_signature, object_already_present, no_object_present, no_object_matching_hash, consistency_problem, and other_error. The <report_error/> element may contain optional <error_text/> and <failed_pdu/> sub-elements.
Errors are handled at two levels: HTTP 4xx/5xx codes for errors that prevent decoding a query or encoding a response, and XML <report_error/> PDUs (CMS-signed) for all other errors, which can be archived as an audit trail.
The hash attribute in <publish/> and <withdraw/> PDUs is a SHA-256 digest of the existing repository object, encoded as a hexadecimal string. SHA-256 was chosen to simplify comparison with RPKI manifest hashes.
The <list/> operation allows the client to request a complete listing of objects the server believes the client has published; the reply contains zero or more PDUs each conveying the URI and hash of one published object. It is intended primarily for synchronization recovery.
The outermost XML element is a <msg> with 'version' and 'type' attributes (either 'query' or 'reply'). This document specifies version 4, using namespace http://www.hactrn.net/uris/rpki/publication-spec/.
The <publish/> and <withdraw/> PDUs include a mandatory 'tag' attribute to facilitate bulk operations; a CA engine MAY use any syntactically legal value (including empty string) for the tag if it has no use for tagging.
The RPKI publication protocol uses XML messages wrapped in CMS-signed messages, carried over HTTP. Clients initiate an HTTP POST with content type 'application/rpki-publication'; the server responds with the same content type.
IANA registered the 'application/rpki-publication' media type for use with HTTP in the RPKI publication protocol, with no required or optional parameters and binary encoding considerations.
Because each protocol message is wrapped in a CMS signed message providing integrity and authentication at the application layer, HTTPS transport is not strictly required; use of HTTP vs. HTTPS is a private matter between repository operator and clients, though individual operators may prefer HTTPS as policy.
Compromise of a publication server through mismanagement of BPKI private keys could enable a denial-of-service attack on the RPKI by allowing an attacker to delete (withdraw) RPKI objects, leading to routing changes or failures.
The RPKI publication protocol uses a separate Business PKI (BPKI) to authenticate its CMS-signed messages, entirely distinct from the RPKI used to authenticate the published objects. The protocol does not validate whether published objects are valid in the RPKI.
The SHA-256 hashes in <publish/> and <withdraw/> PDUs are not security-sensitive because those PDUs are protected by CMS signatures; the primary reason to change the digest algorithm would be to track a change in the RPKI manifest digest algorithm, which would require incrementing the protocol version.
The <publish/> PDU carries a 'tag' attribute (xsd:token, maxLength 1024), a 'uri' attribute (xsd:anyURI, maxLength 4096), an optional 'hash' attribute (hexadecimal string), and a Base64-encoded DER body. The <withdraw/> PDU carries tag, uri, and a required hash attribute.
The RELAX NG schema is normative: in the event of disagreement between the schema and the document text, the schema is authoritative. The schema defines version as the fixed string '4' and error codes as an enumeration.