Summary

  • A valid RPKI Signed Checklist proves that a party with sufficient control of the issuing resource CA signed a checklist that names a constrained set of AS numbers or IP resources and exact digests of arbitrary digital objects. It does not prove the signer's real-world identity, legal mandate, document truth or completeness of the set.
  • Acceptance therefore needs two independent verdicts after RSC validation: an exact record of which supplied files matched under which filename mode, and an external authority record identifying the actor and the purpose for which that actor may bind the organization.

Imagine an acquisition team reviewing a network-asset transfer. This is an operating exercise, not a report of a real transaction. The seller supplies an address inventory spreadsheet, a compressed equipment schedule and a file with the .sig extension. The verification tool turns green. Both supplied files match entries in an RPKI Signed Checklist. The resource block fits inside the resources carried by the embedded certificate. The signature chain and current revocation check pass.

The checklist contains a third digest, but the corresponding file is not in the package. Under RFC 9323, that difference does not automatically make verification of the two supplied objects fail. The implementation should warn that the checklist has more entries than the set presented for verification. The team notices neither the warning nor its meaning. It records that the signer owns the resources, had authority to execute the transfer and supplied the complete disclosure set.

All three conclusions exceed the proof. The file bytes matched. The authority did not.

A checklist is a scoped assertion over bytes

RFC 9323 defines the RPKI Signed Checklist, or RSC, as a Cryptographic Message Syntax protected RPKI signed object. Its eContent type is id-ct-signedChecklist, assigned object identifier 1.2.840.113549.1.9.16.1.48. The IANA RPKI registry records the object as Signed Checklist and associates it with .sig. Its media type is application/rpki-checklist.

Inside the object are three decision-bearing components. A resource block identifies one or more AS numbers, IP address ranges, or both. A digest-algorithm field says how checklist hashes were calculated. The checklist then carries one or more entries, each with a mandatory hash and an optional portable filename.

The resource assertion is deliberately constrained. The resources in the RSC must be a subset of those in the corresponding RFC 3779 extensions of the embedded end-entity certificate. At least one of the AS or IP fields must be present. The certificate extensions used for the RSC may not contain the inherit form defined by RFC 3779. A validator that cannot prove the subset or finds prohibited inheritance must reject the object.

This construction says something concrete: the signed content came through a key-and-certificate path authorized to speak for at least the specified resource subset. It also places exact file digests under the same signature. It does not transform the resources into a corporate name or the files into verified facts.

Validation is a sequence, not one green bit

Before comparing any supplied file, a relying party validates the RSC itself. The generic template in RFC 6488 requires a DER-encoded CMS SignedData object, the expected signed attributes, exactly one embedded EE certificate whose subject-key identifier matches the signer, a signature verifiable by that public key and a valid certification path to an RPKI trust anchor. The template calls these checks necessary but not sufficient. The object profile supplies the rest.

RFC 9323 adds the RSC syntax, resource-subset and checklist checks, and makes one profile-specific change: the EE certificate must not contain a Subject Information Access extension. The certificate must be valid at the relying party's validation time and must not be revoked. RFC 6488 makes the temporal consequence explicit: a previously valid signed object ceases to be valid when its EE certificate expires or is revoked.

The distinction matters operationally. “Signature correct” can mean only that the mathematical signature verifies. “RSC valid” additionally requires a current path, certificate profile, revocation state, CMS form, RSC form and resource relationship. “Files verified” is a further verdict over the exact bytes presented. “Transaction approved” belongs to another authority altogether.

A good acceptance record preserves every transition rather than flattening them into a badge. It records the RSC hash, eContent OID, EE-certificate fingerprint, chain and trust anchor, validation time, certificate validity, CRL acquisition and result, asserted resource block, certificate resource block, absence of inherit, digest algorithm and object-profile outcome.

Exact bytes still require a matching mode

For every digital object to be verified, the validator calculates the digest over the supplied bytes using the algorithm named by the RSC. That calculation is intentionally indifferent to file meaning. A single changed byte produces another digest; two semantically equivalent text renderings may therefore fail if newline or encoding transformations changed their octets. RFC 9323 recommends putting plain-text objects in a lossless compression envelope to reduce accidental canonicalization in transit.

The optional filename creates two distinct matching modes. If the verifier receives a filename, it should use filename-aware mode. A digest match must exist, and exactly one matching checklist entry must carry that exact filename. A renamed file does not pass merely because another named entry has the same hash.

If the verifier has no filename, it should use filename-unaware mode. Again the digest must match, but exactly one matching entry must omit the filename. A digest appearing only in a named entry does not silently become a nameless match. Implementations may allow the operator to override the mode, which makes the chosen mode part of the evidence that must be retained.

The checklist's uniqueness rules support that result. Among entries with filenames, each filename must be unique. Among entries without filenames, each digest must be unique. Those rules prevent certain ambiguous matches inside a valid object; they do not tell an organization whether it asked for the right files.

Verification of a subset is not proof of completeness

RFC 9323 makes an easily missed point: not all checklist entries necessarily need to be used in a verification operation. If an RSC lists five objects and a user supplies three, the three can verify. The larger checklist should cause a warning, allowing corrective action if needed, but the unused entries do not automatically invalidate the matches.

That behaviour is sensible for a reusable attestation. One recipient may possess only the configuration bundle relevant to its task; another may validate an archive object without unpacking every associated file. The protocol cannot know the relying party's business purpose.

The same flexibility creates an acceptance hazard. A tool can answer “Did these bytes appear in this signed checklist?” It cannot answer “Did the counterparty disclose everything material to this acquisition?” Completeness is not a property of a hash list in the abstract. It is a requirement defined by a contract, regulatory rule, operating procedure or evidence request.

The acquisition team therefore needs a manifest of required disclosure categories that exists outside the RSC: address title and registration records, liabilities, customer assignments, revocation commitments, equipment ownership, security incidents, access credentials and whatever the transaction actually requires. The RSC can bind delivered files to resource-scoped control. The external checklist defines what must be delivered.

The identity gap is intentional

The strongest warning appears in RFC 9323's security considerations. RSC data are self-asserted. A relying party must not assume anything about the signer beyond sufficient control of the issuing CA to create the object. The parent CA did not verify the checklist data.

RFC 9255 explains why this is not a minor certificate omission. The “I” in RPKI stands for Infrastructure, not Identity. Resource certificates authorize assertions concerning Internet Number Resources; they are not designed to authenticate the real-world holders of those resources or the people operating their CA accounts.

In many hosted RPKI arrangements the resource holder does not possess the signing private key directly. It authenticates to a CA service, which causes the object to be created. The credential holder may be an owner, an employee with narrow network-administration duties, a vendor or an attacker. Even an honest resource administrator may have no authority to sell an asset, approve a bank transfer or bind the corporation.

RFC 6487 reinforces the boundary at the certificate layer. Issuer and subject names are not intended to describe identity. A valid path can establish delegated resource scope while leaving the human and corporate identity question unanswered.

An accepting organization must therefore consult an exogenous authority. Depending on the decision, that may include a registry record, a corporate registry, board resolution, notarized mandate, contract, court order, procurement delegation, known-customer authentication or another independent source. The relevant question is not merely “Who is this?” It is “Who is this, and may this actor make this exact assertion for this exact purpose now?”

Distribution, revocation and time leave further gaps

RSC objects are not distributed through the public RPKI repository system. They move out of band between parties. A third party without the object may not know that it exists. A serial-number gap among published EE certificates or an unfamiliar certificate serial on a CRL cannot establish that an RSC was created; many other unpublished, withdrawn or never-published explanations remain possible.

Out-of-band delivery makes provenance part of the acceptance record. A copy obtained from a counterparty portal, a signed email exchange and an anonymous file drop can contain identical bytes, but they provide different evidence about who presented the object and for what transaction. Channel provenance still does not replace RPKI validation, and RPKI validation does not replace channel provenance.

The EE-certificate lifecycle creates a second control. RFC 6487 describes the normal one-to-one relationship between an EE certificate and a signed object: revoking the certificate effectively revokes that object. RFC 9323 expects a one-time-use EE certificate for an RSC. A CA can technically sign multiple RSCs with the same key pair, but those objects cannot then be revoked individually. Reuse converts one revocation switch into a coupled decision across otherwise distinct assertions.

Time is also narrower than it looks. RFC 9589 now requires a CMS signing-time attribute in RPKI signed objects and forbids the older binary-signing-time attribute. It imposes no requirement that the signing-time value be correct and says it does not reliably identify when the signature was produced. The relying party may record the value, but it cannot use it as a trusted transaction timestamp. Validation time, certificate validity, CRL state and external chronology remain separate evidence.

A defensible acceptance record

The result of an RSC review should read less like a certificate badge and more like a chain of custody. It should identify the exact RSC bytes and delivery channel; the certificate and CRL state at a named validation time; the resource subset; every supplied object hash and filename; the matching mode and unique entry; every checklist entry not presented; every warning shown; the external identity source; the actor's transaction-specific mandate; and the downstream decision actually made.

It should also record what was not established. The files may be authentic copies of what the resource-scoped signer listed while their factual contents remain false. Every supplied file may match while a material file was never listed. A named organization may control the resources while the authenticated employee lacks signing authority. The actor may have had authority yesterday and lost it after a resource transfer or board change.

Those are not reasons to distrust RSC. They are reasons to use it for the proof it can make. A precise instrument becomes dangerous only when an acceptance system silently grants it powers its designers withheld.

Sources