GOpenCNR RPKI certification practice statement

1. Introduction

Overview

GOpenCNR is a registry-run private overlay network. Its registry allocates private IPv6 and IPv4 addresses and ASNs to members, and its hubs route between them. This statement describes the resource public key infrastructure (RPKI) that certifies those resources, so that a router can check that a route into GOpenCNR space comes from the origin the registry names, and that its path fits the provider relations the registry knows. It follows the outline of RFC 7382 and sets out how Gelhaus Solutions, as Tier 0, operates the certification authority.

This is a private RPKI, not part of the RPKI of the Regional Internet Registries. Its trust anchor is GOpenCNR's own, and it certifies nothing but GOpenCNR's own private space:

• the IPv6 root fdc0:0900::/24, inside the unique local range fc00::/7 (RFC 4193);
• the IPv4 pools the registry holds: 10.113.0.0/16, in the private range of RFC 1918, its fallback pools (a second reserved 10.x /16, then 198.18.0.0/15) and the opt-in experimental pool in 240.0.0.0/4, each from the moment the GOpenCNR Community Council has created it;
• the ASN block 4223000000 to 4223009999, inside the range RFC 6996 reserves for private use.

A validator uses GOpenCNR's trust anchor locator (TAL) beside the RIR TALs, never in place of them. Nothing in this RPKI says anything about public address space or public ASNs.

The registry is the truth. Every ROA and every ASPA object is generated from registry state by GOpenCNR's online CA, on every accepted change, and nothing is configured by hand. The trust anchor key signs only in scripted ceremonies, a separate online CA key signs everything else, and every signed object carries a one-time key that is destroyed after its one signature.

Document name and identification

This is the GOpenCNR RPKI certification practice statement. The certificates it governs carry the policy identifier that RFC 6487 requires of every RPKI certificate, id-cp-ipAddr-asNumber (1.3.6.1.5.5.7.14.2), from the RPKI certificate policy of RFC 6484. Where that policy assumes the hierarchy of the Regional Internet Registries, this statement says what GOpenCNR does instead.

Participants

• Trust anchor. Gelhaus Solutions, as Tier 0 of GOpenCNR, holds the trust anchor. Its key signs only in ceremonies (section 5).
• Online CA. One CA below the trust anchor, operated by Tier 0, holds every certified resource and issues everything else: the end-entity (EE) certificates of ROAs, ASPA objects and manifests, its CRLs, and the certificates of delegated CAs.
• Delegated CAs. A holder may ask to run its own CA under the online CA. It then holds that CA's key and signs its own objects for the resources in its certificate.
• Registration. There is no separate registration authority. The GOpenCNR registry is the record of who holds what, and the CA certifies what the registry says. Changes reach the registry signed by the holder, and those that need a person's judgement are decided by Tier 0 under four-eyes (section 3).
• Subscribers. The holders, people and verified organisations, whose allocations, ASNs and route objects are certified, and the holders that run a delegated CA.
• Relying parties. GOpenCNR's hubs, which check every route they import for RPKI and ASPA validity; members' routers, which validate through Tier 0's RTR caches inside the network or through a validator of their own; and anyone who loads the TAL under the TAL and repository terms of use.
• GOpenCSR. The accounts, the signing step, the four-eyes approvals and the one transparency log at csr.gplatform.org/tlog belong to GOpenCSR, and this RPKI relies on them.

Certificate usage

Certificates and signed objects are for two things:

• route origin validation: checking that a route into GOpenCNR space is announced by the ASN its route object names;
• path checks with ASPA: checking that a route's AS path fits the provider relations registered for the ASNs in it.

They are for nothing else. They identify nobody, they say nothing about space outside GOpenCNR, and none of them is a BGPsec router certificate: BGPsec is not used in GOpenCNR.

Policy administration

Gelhaus Solutions, Eichenwald 3, 49624 Löningen, Germany, administers this statement. Questions go to contact@gplatform.org. A suspected key compromise or a wrongly issued object is reported as the GOpenCNR security and disclosure policy describes, to the same address or through GAdvisory.

This statement is one of GOpenCNR's founding network policies. It changes as network policies do under the GOpenCNR charter rider: by motion of the GOpenCNR Registry Council, after public comment, subject to Tier 0's veto on grounds of security or law. Every version is kept in the document archive, and the version in force is the one there with the latest date. The operational values this statement leaves to the published objects (section 4) change without a new version, and every such change is announced in the transparency log.

Definitions

• ASPA (Autonomous System Provider Authorisation): a signed object listing the provider ASNs of a customer ASN.
• CA: a certification authority. Trust anchor: the CA at the top, whose key a relying party trusts directly. TAL: the trust anchor locator, a small file that tells a validator where the trust anchor's certificate is and which key it must carry.
• CRL: a certificate revocation list, signed by the CA that issued the certificates on it.
• EE certificate: the end-entity certificate inside a signed object, for a key that signs that one object.
• Manifest: a signed list of every object a CA currently publishes, each with its hash.
• ROA (Route Origin Authorisation): a signed object stating that an ASN may originate the prefixes in it.
• Route object: the registry's record that a prefix may be announced from an origin ASN.
• RRDP: the RPKI Repository Delta Protocol (RFC 8182), over HTTPS. rsync: the older way of fetching a repository. RTR: the RPKI to Router protocol, through which a cache hands validated data to routers.
• Ceremony identity: the one identity in the key store that may use the trust anchor key.
• Tier 0: the root operator role of GOpenCNR, held by Gelhaus Solutions.

2. Publication and repository responsibilities

• The repository is served from cnr.gplatform.org, over RRDP and over rsync. RRDP is the way to fetch it. rsync is there because the certificate profile still requires rsync addresses in every certificate, and some validators still use them. The repository holds every certificate, ROA, ASPA object, manifest and CRL the trust anchor and the online CA publish.
• When it changes. ROAs and ASPA objects are regenerated on every accepted change to the registry, so the repository changes when the registry does. Manifests and CRLs are reissued as the objects change, and before their next update time when nothing has changed.
• The TAL follows RFC 8630. It is published at cnr.gplatform.org, signed, and shipped inside every release of the GOpenCNR agent, so that a member's router has the anchor before anything validates. It changes only in a ceremony, and every change is announced in the transparency log and shipped in an agent release.
• The same data in other forms. For routers that run no validator, Tier 0 runs RTR caches inside GOpenCNR. The same data is also exported as dn42-style JSON, as an RFC 8416 SLURM file, so that a member that validates the public RPKI can layer GOpenCNR's data on top, and as BIRD ROA tables. These exports carry no signatures of their own: whoever needs proof validates the repository.
• Who writes. Nothing reaches the repository except what the online CA or a ceremony has signed. Nothing is published by hand.
• Who reads. Anyone, free of charge, under the TAL and repository terms of use, which also say how to fetch without burdening others.
• This statement is published at this address and kept, with every earlier version, in the document archive.

3. Identification and authentication

• A certificate names no one. It binds resources to a key. It does not say who holds the key, and relying on it for anything about a person or an organisation is a misuse.
• Holders. Resources are held by GOpenCSR accounts with a verified email address, and by organisations verified under the organisation verification terms. Every holder is screened against the EU consolidated financial sanctions list when it first becomes a holder and every day after: a person by the legal name and country it gives then, an organisation by its verified name and country. Before a holder's first tunnel, GOpenCNR also asks for a vouch, as the GOpenCNR terms set out.
• Every change is signed by the holder. A change to an allocation, an ASN or a route object reaches the registry only with the holder's signature: a passkey assertion over the change's hash, made in GOpenCSR's signing step at csr.gplatform.org, which shows what is being signed, or a signature by an Ed25519 automation key registered under a passkey. The change and its signature are entered in the transparency log, so anyone can check a ROA against the signed change that caused it.
• What is automatic, and what a person decides. Default allocations, ASNs and route objects inside the holder's own space are accepted automatically within policy. Larger allocations, on written justification, closed prefixes, transfers and reclamation are decided by Tier 0 under four-eyes. Pools are created only by motion of the GOpenCNR Community Council. A change is accepted only if every artifact derived from it, ROAs and ASPA objects included, regenerates cleanly.
• Resources from outside are never certified. A dn42 or public ASN that a holder brings is recorded in the registry after proof of holdership. It is never allocated, and never certified here.
• Delegated CAs. A holder asks for one, and the online CA certifies to it the resources the registry holds for that holder, and nothing more.
• Tier 0. Every Tier 0 change is confirmed with a passkey.
• Withdrawal. A holder withdraws a ROA by changing or removing the route object behind it, signed like any other change.

4. Certificate life-cycle operational requirements

• No application. Holders do not apply for ROAs. The online CA issues a ROA because the registry holds a route object, and withdraws it because the registry no longer does. A delegated CA is the one certificate a holder asks for.
• ROAs. One ROA per origin ASN, covering every prefix the registry's route objects let that ASN originate, each exactly as registered and without maxLength (RFC 9319). A more specific prefix is valid only with a route object of its own. For a member without BGP, the route object names the hub's ASN as origin, and the ROA follows it.
• Closed prefixes. A closed prefix's ROA is published like any other: its prefix, holder handle and origin ASN are public like those of any prefix. Only its reachability is closed. Who belongs to its audience, and the routes to it, stay private and are never in the repository.
• ASPA objects. One for each ASN in GOpenCNR's block that has provider relations in the registry: the hubs its member uses and the transit members it names. The member's agent keeps those relations in step with the hubs it actually uses.
• Issuance. On every accepted change, the online CA regenerates the objects the change affects, signs each with a new EE key, and publishes them with a new manifest and, where something was revoked, a new CRL. The CA reads the registry through versioned read-only views and cannot change it.
• Delegated CAs. The child certificate carries only the resources the registry holds for the holder, and is reissued when they change. The holder operates the delegated CA's key and its signed objects, and answers for them.
• Renewal and re-keying. Objects are re-signed before they expire, each time with a new EE key. An EE key is never reused and never renewed. The keys of the trust anchor and the online CA change only in a ceremony (section 5).
• Validity periods and intervals. This statement fixes no validity period for certificates and no interval for CRLs and manifests. The values in force are those in the published certificates, CRLs and manifests themselves, which every validator reads, and every change to them is announced in the transparency log.
• Revocation. A certificate is revoked, and listed on its issuer's CRL until it expires, when:
• the route object, provider relation or delegation behind it ends or changes, including when space is transferred, returned or reclaimed;
• its key is, or may be, compromised;
• it was issued wrongly;
• a court or a competent authority orders it.

A withdrawn object leaves the repository and the manifest with the publication that withdraws it.

• No suspension. An RPKI object is published and valid, or withdrawn and revoked; there is no state in between. Sanctions against a holder act at the hubs, which filter straight from the registry. Where a sanction ends a holder's route objects or reclaims its space, the ROAs follow.
• Status is published only through CRLs and manifests. There is no OCSP.
• Stale data. A hub whose RPKI data cannot be refreshed keeps its last good set, raises an alert, and never starts accepting origins it cannot validate.
• No key escrow. No key of this RPKI is deposited with anybody. The trust anchor key and the online CA key exist only in the key store, and an EE key only for its one signature.

5. Facility, management and operational controls

• Where things run. The online CA runs in GOpenCNR's control plane, on a server rented from IONOS SE in Germany, which also serves the repository. The keys are not there: the trust anchor key and the online CA key are held in HashiCorp Vault on our own hardware in Germany, reached over WireGuard.
• The key store is the one that holds GOpenCDR's DNSSEC keys, under the same controls: keys are non-exportable, with plaintext backup disabled, and every signature is made inside it; it keeps two audit devices; credentials are bound to network addresses; and no standing root token exists. GOpenCNR's keys are its own, used under one policy and one identity per service.
• The trust anchor key is fenced. An access rule in the key store lets only the ceremony identity sign with it. No running service can use it, the online CA included.
• Ceremonies. The trust anchor key is used only in scripted ceremonies: to issue or reissue the online CA's certificate, for example when the set of certified pools changes; to reissue the trust anchor's own CRL and manifest; and to replace a key. A ceremony runs only once a second authorised Tier 0 person, its witness, has approved it under four-eyes in the database, with a passkey. While Tier 0 is one person, four-eyes runs in solo mode, and an approval given alone is flagged "decided alone". The minutes of every ceremony are entered in the transparency log, which names people only by account identifier.
• The online CA key is used only by GOpenCNR's RPKI service, through its own identity in the key store.
• One-time EE keys are the written exception to the rule that keys never leave the key store. Each is made in memory by the RPKI service, used for exactly one signature, and destroyed. Its trust comes from the EE certificate the online CA signs inside the key store, not from where the key was made.
• People. Tier 0's root roles are held by people of Gelhaus Solutions, and every Tier 0 change is confirmed with a passkey.
• Records. Every change writes an audit record, which is never changed or deleted, and every registry change is in the transparency log with its holder's signature. Key registrations and revocations, ceremonies, pool actions and sanctions are entries in the log too.
• Backups. The registry database and the repository are backed up every night to Proxmox Backup Server on our own hardware in Germany and kept for 90 days, and restoring them is rehearsed in a drill.
• Monitoring. Two independent validators, rpki-client and Routinator, fetch the repository continuously. Tier 0 is alerted when they disagree, when the repository goes stale and when a publication fails.
• Compromise. If a key of this RPKI may be compromised, Tier 0 acts at once under its emergency procedure, which may only suspend or tighten. The certificate for the compromised key is revoked and a new key is made in a ceremony. A new trust anchor key means a new TAL, announced in the transparency log and shipped in an agent release. The event, and what was done about it, is published in the transparency log. Written runbooks cover the trust anchor ceremony, a key compromise and an outage of the key store.
• When the key store cannot be reached, nothing new is signed. What is published stays published until it expires, and the hubs keep their last good set.

6. Technical security controls

• Algorithm. RSA keys of 2048 bits with the public exponent 65537, signing with SHA-256, as RFC 7935 requires for every certificate, CRL and signed object in the RPKI. SHA-1 appears only in key identifiers, as the profile prescribes, and never in a signature.
• Key generation. The trust anchor key and the online CA key are generated and held in Vault Transit as non-exportable keys. EE keys are generated in memory for their one signature.
• One role, one key. The trust anchor key, the online CA key, and a fresh key for every signed object. The bundles that configure agents and hubs are signed with a different key again, which has no part in the RPKI.
• No private key of the trust anchor or the online CA exists outside the key store.
• Hosts. The control plane runs under systemd with an nftables baseline and keeps its clock with NTS. The CA is built against a written threat model, because a forged ROA reroutes traffic.
• Network. The repository is public and read-only. The key store is reachable only over WireGuard, from named hosts.

7. Certificate, CRL and manifest profiles

• Resource certificates follow RFC 6487, with the IP address and AS number extensions of RFC 3779. Every CA certificate names its rsync repository, its manifest and its RRDP notification address (RFC 8182), and every certificate names its issuer and its CRL with rsync addresses, as RFC 6487 requires.
• The trust anchor certificate is self-signed and carries the whole certified resource set of section 1. The online CA's certificate carries the same set.
• EE certificates: one per signed object, each for a key used once.
• ROAs follow RFC 9582: one per origin ASN, every prefix without maxLength.
• ASPA objects follow the IETF profile (draft-ietf-sidrops-aspa-profile): a customer ASN and the provider ASNs registered for it.
• Manifests follow RFC 9286: one per CA, listing every current object with its hash, each manifest signed with its own one-time EE key.
• CRLs follow the profile of RFC 6487, one per CA.
• Signed objects use the CMS profile of RFC 6488.

8. Compliance audit and other assessments

No outside auditor audits this CA. It is checked continuously, and in public:

• two independent validators fetch and validate the repository continuously, and any disagreement or staleness alerts Tier 0;
• every route object behind a ROA is a holder-signed change in the transparency log, and a public monitor checks every logged change against the holder's registered keys and alerts the holder to anything it did not sign;
• holders are told of every change to their objects, Tier 0's included;
• anybody can run a validator against the repository with the published TAL and compare what it finds with the registry.

A finding is handled as a security report under the GOpenCNR security and disclosure policy.

9. Other business and legal matters

• Fees. None. Certification, the repository and the TAL are free.
• What is public. Everything in the repository, the TAL and this statement. The repository holds prefixes, ASNs, keys and signatures. It never holds an endpoint address, an email address or the members of an audience.
• Privacy. What GOpenCNR processes about holders is in the GOpenCNR privacy notice. Fetching the repository is logged like any request to our servers, and request logs are deleted after 14 days.
• No warranty. No warranty is given to holders or relying parties, and no service level applies. A relying party decides for itself what its validator and its routers do when data is missing or stale.
• Liability. Certification is given away. For what is given away, liability is limited to intent and gross negligence (Section 521 BGB), and otherwise it is as the general terms of service set it out.
• Changes to this statement are made as section 1 describes, and every version is kept in the document archive.
• Law. German law applies. Nothing in this statement overrides the law, a court order, or the rights holders have under the GOpenCNR terms.