Summary

  • OpenBSD 8.0, released on 20 October, says rpki-client now properly applies trust-anchor constraints to BGPsec Router certificates.
  • The local fence can limit which resource certificates one relying party accepts. It cannot stop a trust anchor publishing an object or make every other validator enforce the same boundary.

The fence has a new gate

The change is one line in the OpenBSD 8.0 release notes: “Properly apply constraints to rpki-client(8) BGPsec Router certs.” The detailed changelog repeats it. The release landed on 20 October, six days before this report.

The line matters because one certificate class can sit outside a policy file that otherwise looks complete. A BGPsec Router certificate carries the resources and key associated with a router’s use of BGPsec. The OpenBSD note says the constraint check now reaches that certificate class correctly. Its public entry gives no affected-version range or incident detail; it records a code correction to BGPsec certificate handling.

This is the operational edge of a broader SIDROPS proposal, “Constraining RPKI Trust Anchors”. The current -02 draft asks relying parties (RPs) to configure the resource space they expect a trust anchor (TA) to sign for. It checks the IP and autonomous-system resources listed in an end-entity certificate against that local boundary. A certificate outside the allowed space is rejected for that RP’s validation of the signed object.

“All resources” is a large permission slip

The draft says all five Regional Internet Registries list all resources beneath their TA certificates in normal operations. That broad statement helps avoid invalidation when registries pass through temporary inconsistencies, especially around resource transfers. It also means a relying party can see a TA certificate authorizing more space than the registry currently holds.

The proposed local constraint file gives the RP a second decision point. Each file is tied to a TA by the matching .tal filename. Operators can allow prefixes, address ranges and AS numbers, then carve out exceptions with deny entries. Deny wins over allow; resources with no allow entry are denied by default. The design avoids making an operator list the entire Internet just to exclude one range.

That last convenience comes with a blunt failure mode. A malformed constraint file must be rejected as a whole, and the RP must not check EE certificates against it. The constraint layer then supplies no fence for that TA until the file is corrected. This turns syntax, packaging and update ownership into security controls, not housekeeping.

The draft scopes the check to objects with explicit IP or AS resource extensions, including ROAs, ASPAs, RSCs and BGPsec Router certificates. Signed TALs and Manifests use inherited resources; the draft places them outside this check. A local rule narrows one RP’s certificate-validation boundary. Router route selection follows the data feed and local routing policy.

Code arrived before the standards finish line

The -02 remains an active Internet-Draft. Datatracker records a SIDROPS state of “Waiting for Write-Up Revised I-D Needed – Issue raised by WGLC.” The document says its implementation appendix will be removed before publication as an RFC.

The appendix reports that rpki-client implemented the approach in C and enabled it by default since 2023; it also lists Rust and Go implementations. The authors report that all three produced the same results on OpenBSD fixtures. IETF says it did not verify the supplied implementation information, so the comparison remains contributor-reported evidence from a shared test set. The current OpenBSD manual documents per-TA .constraints files and local allow/deny checks.

The correction makes version-by-version and object-type coverage central to rollout. A feature label alone cannot establish that every intended certificate path receives the rule.

Six months is a long time for a small file

The draft tells maintainers distributing constraint files through operating-system or third-party package releases to assume a six-month delay before users update. Registry policy and resource holdings can change; local fences must keep up with the scope they claim to enforce. A stale allowlist can reject newly legitimate resources. A stale or missing policy can leave an RP accepting more than its operator intended.

The NRO’s 2026–2028 strategy lists delivery of a Trust Anchor Constraints document among planned RPKI work. Its RPKI Program had already named a community consultation on trust-anchor configuration as a 2025 objective. That gives the proposal an institutional path. OpenBSD 8.0 supplies a different kind of evidence: this is a live validator feature with a fresh certificate-class correction.

The practical question for a network operator is whether the local file expresses the intended scope, survives package updates, parses cleanly and reaches every signed-object certificate type in use. OpenBSD’s release note has made the last item harder to leave implicit.

Sources