Summary

  • AFRINIC’s RPKI practice statement says a PKCS#10 signature proves possession of a request key, while BPKI authenticates an authorized representative and links the request to a member database record.
  • A resource certificate is issued only for a requested resource set that is a subset of the member’s recorded holdings, yet the public certificate does not attest the member’s organizational or individual identity.
  • A valid ROA authorizes an ASN to originate specified prefixes; only a separate BGP observation can show what origin was actually announced at a particular time and vantage point.
  • AFRINIC could make the chain auditable with a privacy-safe resource-authorization provenance receipt that exposes versions, digests and decisions rather than identity documents or portal secrets.

A meaningless name can be the correct name

Open an RPKI resource certificate expecting the subject field to answer “which company is this?” and the certificate can look evasive. The Common Name may be generated by the issuer and mean nothing to a human reader. Under AFRINIC’s Certification Practice Statement, that is not an accidental omission. The document says subscriber names need not be meaningful because the certificates support authorization for routing security, not identification.

The distinction is unusually explicit. The CPS says that, except for registries, certificates in this PKI do not attest the organizational identity of resource holders. They do not attest an individual’s identity either. AFRINIC’s Resource Certification page makes the same public point: resource certificates are not identity certificates. They serve specialised applications concerned with the right to use an IP address or autonomous-system number.

That narrow purpose is protective. A relying party can validate resource authority without requiring a public certificate to repeat a company name, a person’s name or a copy of an identity document. The certificate is less useful as a badge, but more precise as a machine-verifiable authorization object.

Seven propositions, not one proof

The CPS describes a sequence whose parts are easy to collapse when the final result is simply called “valid.” Each part answers a different question.

  1. Private-key possession. The certificate request uses PKCS#10 and is signed with the private key corresponding to the requested public key. That proves control of the request key at that moment. It does not, by itself, prove a name, role, membership or resource entitlement.
  2. Representative authentication. Only an individual holding an AFRINIC BPKI certificate may request an RPKI certificate. The BPKI credential authenticates the requester for the registry workflow.
  3. Member-record linkage. The CPS says that the BPKI certificate links the request to AFRINIC’s member database, which maintains resource-allocation records. The public resource certificate need not reproduce this link in human-readable form.
  4. Resource-set authority. AFRINIC matches the requested resources against the member record. It issues the RPKI certificate only if the request is a subset of the resources recorded for that member.
  5. Resource-certificate validity. The resulting certificate binds a public key to IP-address and/or AS-number resources. RFC 6487 requires resource extensions and a certification path in which an issuer’s resources encompass the child’s resources.
  6. Route-origin authorization. A ROA is another signed object. The current profile, RFC 9582, says that an address-block holder authorizes an AS to originate routes for specified prefixes and optional maximum lengths.
  7. Observed routing. A BGP route is an observation of a prefix, origin and path from a particular feed, router or collector at a particular time. RFC 6811 compares the route-derived origin with validated ROA payloads; it does not make the ROA itself an observation of the live network.

Every link can be valid without becoming the next one. A correct PKCS#10 signature does not appoint the signer as a member representative. A valid BPKI credential does not enlarge the member’s recorded resource set. A valid resource certificate does not authorize any particular origin until a ROA does so. A valid ROA does not prove that the route is being announced, selected, reachable or safe along its entire AS path.

BPKI is the private join behind the public object

This design can be misread in two opposite ways. One mistake is to treat the public resource certificate as if it identified the legal person behind every resource. The other is to see no organization name and conclude that AFRINIC did no identity or authority work.

The CPS supports neither conclusion. It places the representative and member linkage in BPKI and the member database. BPKI identifies individuals who represent members; it authenticates issuance, re-key and revocation requests. The resource-subset check then constrains what the request can produce. The RPKI certificate publishes the authorization outcome needed by relying parties, not the private evidence used to admit the request.

That is also consistent with RFC 6480. The architecture says RPKI provides authorization rather than authentication and instructs issuers not to use descriptive subject names as identity assertions. It recommends names that can link back to existing records. The external certificate and the internal record are therefore related by design but have different audiences.

The member database should still be described carefully. It is AFRINIC’s operational record of allocations and assignments. Matching a request to that record can support an issuance decision. It does not turn the record into a court judgment about corporate authority, a deed to an asset or proof that every external registry has reconciled the same facts.

A ROA authorizes a relationship; BGP reports an event

The separation continues after certificate issuance. A member can use the relevant private key and end-entity certificate chain to sign a ROA. The ROA contains an origin ASN, one or more prefixes and, where specified, a maximum length. Validation shows that the signed object and its resource chain meet the rules applied by the relying party.

RFC 9582 is direct about the boundary: the PKI used for ROA validation supplies authorization, not authentication or non-repudiation. The object means the stated ASN is permitted to originate routes for the stated prefixes. It does not say that the ASN is doing so now.

An origin-validation system obtains that second fact from a route. It derives an origin ASN from the received AS path and compares the route prefix and origin with validated ROA payloads. The familiar Valid, Invalid and NotFound labels describe the comparison. They are inputs to local policy, not universal routing commands. The mechanism does not validate the whole AS path.

This is why a screenshot reading “valid” is incomplete evidence. To reproduce the result, an operator needs both sides: the RPKI data set, trust-anchor and validation time, and the BGP observation source, time, prefix and derived origin. AFRINIC’s Trust Anchor Locator page identifies the configured entry point for validating AFRINIC’s hierarchy, but the answer still depends on what repository objects and route observations were available to the relying party.

A privacy-safe resource-authorization provenance receipt

The useful improvement is not to put a company registration file into every resource certificate. AFRINIC could instead make the issuance and downstream authorization chain exportable as a typed receipt. This is an editorial proposal, not a reported AFRINIC commitment.

For the registry-side decision, the receipt could include:

  • the request time and fingerprint of the requested public key;
  • a non-secret BPKI credential reference or representative-role identifier, plus the authentication result;
  • a version or digest of the relevant member record and resource-holdings snapshot;
  • the requested IP and AS resource set, the set against which it was checked, and the subset decision;
  • the issued certificate’s serial number, Subject Key Identifier, resource extensions and validity interval; and
  • publication-point, manifest, CRL and trust-anchor references sufficient to reconstruct validation.

For a ROA, append the end-entity certificate reference, origin ASN, prefixes, maximum lengths, signed-object digest and validation result. When the receipt is used to explain an origin-validation result, attach a distinct observation section: BGP source, observation time, prefix, observed origin, vantage or collector identifier, and the exact comparison outcome.

These fields should be separable. A member may retain the full receipt inside its account while publishing only certificate and ROA references. An auditor could receive record digests and decision codes without receiving identity-document images, private contact details or credentials. A public dispute could cite a receipt digest and a supersession link rather than exposing the underlying member file.

The receipt should also state what it does not prove. A BPKI reference is not a public identity certificate. A member-record digest is not a legal-title decision. A certificate validation is not a statement about current routing. A ROA validation is not a path-safety verdict. A BGP observation is not a claim of global visibility.

Sources