Summary

  • RFC 9323, written by Job Snijders, Tom Harrison and Ben Maddison, makes a deliberately narrow claim portable: a validated RPKI Signed Checklist shows that a key authorized for a stated subset of IP address or AS-number resources signed a checklist containing exact file digests.
  • The signature does not establish a natural person's identity, a corporate mandate, the truth or completeness of a file, the legality of a transaction, or a recipient's duty to act. Those decisions remain with the parties that can verify identity, contract, purpose and operational risk.

A signature looking for the right-sized claim

Bring Your Own IP sounds simple in a product menu. A customer asks a cloud or hosting provider to announce address space that the customer already controls. The provider needs evidence that the request is connected to those addresses, while the customer may need to transmit forms, letters or configuration material. Traditional paperwork can be slow and easy to detach from the resource claim it is meant to support.

The same problem appears in physical interconnection. Two autonomous systems can agree to connect, but the receiving party still needs a dependable way to associate a package of files with authority over particular Internet number resources. A scan of a letter may name the right company while saying nothing machine-verifiable about the prefixes or ASNs. A resource certificate can speak about numbers while deliberately saying little about a real-world identity.

The RPKI Signed Checklist, standardized in RFC 9323 in November 2022, joins these two worlds without pretending to merge them. The authors are Job Snijders, Tom Harrison and Ben Maddison. They define a Cryptographic Message Syntax object whose payload names a digest algorithm, at least one Internet number resource, and one or more hashes of external files. The files themselves remain outside the signed object.

That design is less ambitious than a universal document-signing system. It is also more useful. A verifier can ask a precise question: did a key with a valid RPKI path for this resource subset sign a checklist that contains the digest of these exact bytes? The answer can be automated without declaring that the bytes are honest, complete or legally sufficient.

Snijders matters here not because one RFC grants him control over a transaction. The IETF Datatracker records a body of routing-security work, while OpenBSD identifies him among the principal developers of rpki-client and as a maintainer of its portable version. The recurring contribution is a habit of making an operational assertion small enough to validate, implement and challenge.

What sits inside the checklist

An RSC is not a folder with documents embedded in it. Its content contains a sequence of Internet number resources, an object identifier for the chosen digest algorithm, and a sequence of checklist entries. Each entry carries a message digest and may carry a filename. The resource set must contain at least one IP address block or AS identifier.

The resources in the checklist must be a subset of the resources in the end-entity certificate attached to the signed object. The certificate therefore constrains what the signing key can claim. A key authorized for one prefix cannot use an RSC to create cryptographic evidence for an unrelated prefix. Validation must reject a checklist that exceeds the certificate's resource set.

The file hash performs a different task. It commits the signer to an exact byte sequence. Change a date, a comma, an attachment or the encoding and the digest changes. The mechanism can therefore detect substitution or alteration after signing. It does not read the prose, compare it with a contract, test a configuration or decide whether the signer understood the file.

The optional filename is deliberately less absolute than the hash. RFC 9323 uses a constrained portable filename form and supports two verification styles. A filename-aware verifier requires the supplied filename to match the checklist entry as well as the digest. A filename-unaware verifier matches the digest to an entry whose filename is absent. This lets a workflow choose whether the name itself belongs in the attested package.

The distinction prevents a common shortcut. A filename such as authorization.pdf can be helpful to a human, but its label proves nothing about the bytes. Conversely, byte identity can survive renaming when the workflow deliberately uses a filename-free entry. The verifier must know which claim it is checking.

A one-time certificate, not a reusable identity badge

RFC 9323 requires a newly generated key pair and one-time-use end-entity certificate for each RSC. The private key is destroyed after the signed checklist is created. The certificate omits the Subject Information Access extension because the object is not meant to be retrieved from the public RPKI repository system.

This choice limits correlation and reuse. A recipient should not treat the certificate as a standing login credential, a staff badge or a durable company seal. Its purpose is to validate one signed object against the resource certificate hierarchy. The chain may later fail because a certificate expires or is revoked; the generic rules for RPKI signed objects still apply.

The one-time key also makes an important institutional statement. The authority represented by the object is scoped to a resource subset and a checklist. It is not a general power of attorney. If a resource administrator can generate an RSC, that fact does not automatically authorize the same person to sign a lease, accept liability, approve spending or bind a corporation.

RFC 9255 makes this boundary unusually explicit. It warns that RPKI credentials must not be used to authenticate real-world documents or transactions. Access to a resource-management account may belong to a narrow technical administrator. Resource control can therefore be real while the supposed authority over a separate business act is false.

RPKI was never a civil identity system

The original architecture in RFC 6480 binds a public key to IP address blocks or AS numbers. It expressly does not attest the descriptive identity of the certificate subject. This is not a missing feature that an RSC silently repairs. It is a design boundary inherited by the checklist.

A relying party can validate that a certificate path descends from its selected trust anchors and covers the listed resources. It cannot derive from that chain the legal name of the customer, the identity of the employee who clicked a button, beneficial ownership, sanctions status or authority under local company law. Those claims require other evidence.

This distinction can feel inconvenient because many workflows want one green mark. A provider would prefer a single test that says: correct customer, correct resource, correct documents, correct request, safe to deploy. No public-key object can responsibly compress all of those questions unless the institutions issuing and revoking it have actually undertaken each responsibility.

RPKI institutions have undertaken a narrower one. They support a hierarchy for Internet number resources. An RSC can make that resource-linked assertion travel with external bytes. Identity checks, account controls, contracts and local policy remain separate because different parties possess the evidence and bear the consequences.

Validation is a sequence, not a green icon

A recipient first validates the RSC as an RPKI signed object. That includes the Cryptographic Message Syntax envelope, the certificate path, resource constraints and the object-specific rules of RFC 9323. The relying party then hashes each file it has chosen to validate and looks for the required checklist match.

If validation is filename-aware, both the exact filename and digest must match. If it is filename-unaware, the matching checklist element must omit a filename. A recipient can validate fewer files than the checklist lists. RFC 9323 does not make unused entries a fatal error, although it recommends warning the user so a missing attachment or workflow disagreement can be investigated.

This is an excellent example of why a success icon is too coarse. A valid signature may coexist with an incomplete package. A matching digest may belong to a misleading document. A resource set may be valid but broader than the business request. A file may be authentic to the checklist and obsolete for the intended transaction.

RFC 6488 provides the generic signed-object profile and says those checks are necessary but not sufficient. Each content type requires its own semantic validation. RFC 6487 supplies the resource-certificate profile, while RFC 9286 tightens the validation algorithm. Passing the envelope is the beginning of interpretation, not its end.

Even time needs care. A CMS signing-time attribute can be present, but generic RPKI rules do not make its presence or absence determine validity. A business process that needs an authoritative submission time must obtain it from a trusted receipt, transaction log or other appropriate system rather than inventing it from an optional attribute.

The checklist stays out of the global repository

RSCs must not be distributed through the global RPKI repository system. RFC 9323 leaves transport unspecified and mentions channels such as HTTPS, email or removable media. The .sig extension and the assigned content-type identifier help software recognize an object, but neither implies global publication.

The IANA RPKI registry records the Signed Checklist object identifier 1.2.840.113549.1.9.16.1.48 and the .sig filename extension. Those registry entries give implementations common coordinates. They do not create a central inbox, a worldwide acceptance service or a mandatory business workflow.

Keeping the object out of public repositories is operationally sensible. A checklist may refer to customer forms, interconnection materials or other files that belong between named parties. Publishing their digests and resource associations globally could leak relationships or enable correlation without improving route-origin validation.

Out-of-band transport also preserves local control. A provider can define an authenticated upload channel, size limits, allowed file types, malware scanning, retention and review. Another provider can use a different channel. Both can validate the same RSC semantics without surrendering their customer process to a global distributor.

The price is that transport security does not come for free. Email delivery, web accounts and removable media each introduce their own threats. The RSC detects whether supplied bytes match the checklist. It does not prove who operated the transport account, prevent disclosure, scan the attachment or guarantee that the recipient received every intended file.

The receiving party still has a job

Suppose a customer sends a valid RSC covering a prefix and a set of BYOIP onboarding documents. The provider has learned something important: the checklist was signed through a key authorized under the selected RPKI trust model for that resource subset, and the received files match the listed digests.

The provider has not yet learned whether the submitter is the customer named in its account system, whether that person may bind the company, whether another organization has a contractual interest, whether the request violates law or policy, whether the prefix is already in use elsewhere, or whether the intended announcement is operationally safe.

Those checks are not bureaucratic leftovers that cryptography should eliminate. They are different assertions. Customer identity belongs to account verification. Corporate mandate belongs to delegation and legal evidence. Transaction purpose belongs to the contract. Route safety belongs to deployment planning, filtering, monitoring and rollback. Resource status may need current registry and routing observations beyond the signed package.

A good workflow therefore records several independent results instead of one overloaded verdict. RSC valid can be true while identity pending remains open. Files match can be true while business approval denied is final. Resource subset valid can be true while an operational conflict blocks deployment. The separation makes automation safer because software cannot accidentally promote one proof into universal authorization.

Thin automation is stronger automation

The temptation in security automation is to erase judgment. If the signature validates, the system might immediately accept the request and configure the network. That saves time until the signature answers a narrower question than the code assumes.

RSC supports a better pattern. Automate the deterministic checks completely: syntax, certificate path, resource containment, signature, digest and optional filename. Preserve exact failure reasons. Then hand the result to the business and operational controls that own the remaining claims. Human review is not always necessary, but explicit policy is.

This is thin coordination. The standard defines a common object and common validation semantics. It does not dictate how every cloud, exchange, carrier or enterprise should assess customers. Parties can interoperate on the narrow evidence while retaining responsibility for local acceptance.

The boundary also makes disputes easier to diagnose. If bytes do not match, the failure sits in packaging or transport. If the resource subset is unauthorized, it sits in the certificate path or checklist. If identity fails, it sits in the customer process. If deployment is unsafe, it sits in network policy. A universal green badge would conceal these causes.

Adoption should be measured, not imagined

The existence of an RFC and an IANA assignment does not prove universal implementation. The RIPE NCC RPKI quarterly plan lists RSC API support as planned for the third quarter of 2026 following community requests. It describes a later user interface as conditional on demand and available capacity.

That record is valuable precisely because it is modest. It shows an implementation path and community interest. It does not establish that every RIR, provider, validator or customer system can already create, exchange and validate RSCs. A deployment assessment must inspect actual APIs, software versions, error handling and recipient policy.

Adoption also requires more than object generation. A useful service must manage one-time keys safely, assemble correct resource subsets, produce predictable filenames, transport packages securely, expose validation detail and prevent an application from converting valid checklist into approved transaction without the additional controls.

Implementers should test revocation and expiry, missing attachments, duplicate or renamed files, unsupported digest algorithms, partial verification and resource transfers. They should also test the organizational edge case emphasized by RFC 9255: the person who can operate the RPKI account may be the wrong person to authorize the commercial action.

A person defined by bounded mechanisms

Snijders's public technical record extends beyond this one object. The Datatracker connects him with routing-security specifications, and OpenBSD credits his work on a validator designed to fetch and validate RPKI material with a constrained operating model. A MENOG profile likewise places him in the routing and peering community.

The useful biographical inference is not a claim about private motive. It is visible in the mechanisms: precise formats, narrow authority, testable validation and reluctance to let a certificate claim more than its hierarchy can support. RFC 9323 does not make trust disappear. It makes one link in the trust chain inspectable.

That is why the checklist's refusal to sign “truth” is an achievement rather than a defect. Truth about a business document depends on facts, context, authorship, authority and time. A digest knows only bytes. An RPKI certificate knows only a key's relationship to number resources under a trust model. Combining them can prove a useful statement without fabricating the rest.

The result gives providers better evidence and resource holders a portable way to attach that evidence to documents. It leaves the final decision where the liability and operational consequences reside. On a distributed Internet, a standard that knows when to stop can coordinate more safely than one that tries to become a government.

Sources