An experimental single TA for the RIR with restrictions aligned to delegated-nro-latest

This web is updated daily with the OpenSSL .cnf format for each RIR, which expresses their complete holdings as declared in the NRO nro-delegated-stats file (published by the RIPE NCC) of the given day. The complete holdings are defined as all the IPv4, IPv6 and ASN listed as reserved, allocated or assigned to that named RIR, which includes as-yet undelegated resources

Some resources such as the documentation prefixes which are marked as reserved in IANA, the multicast ranges, and undelegated (by IANA) ranges such as and are not included since they do not show as vesting with any RIR and so should not appear in the products of that RIR's X.509 RPKI signed products. They are present in the NRO statistics file denoted as "iana" rather than an RIR.

This is represented in the rfc3779 format which maximally compresses to either a prefix, or a range depending on the start-end pairs of addresses in question (not all resources have been delegated to the RIR in ways which can be maximally compressed to prefixes only, in rfc3779). This rfc3779 format data is then represented in the OpenSSL configuration notation which will permit an X.509 RPKI CA to sign certicates with those resources as listed X509 Extensions.

Prior day's files can be found under the archive in YYYY/MM/DD subdirectories.

An example NRO single TA

Using this information, a self-signed trust anchor has been created which is named CN=example-nro-ta in both Issuer and Subject fields of the certificate.

The certificate has the union of all listed internet number resources in each of the RIR, and therefore is the superset of all of the listed more-specific per RIR states. There is no 0/0 or 0::/0 claim in this certificate: it only lists resources which are delegated into the RIR system.

This certificate signs over instances of each of the RIR operational certificates. The operational certificates are the more-specific states which lie under the existing RIR 0/0 and 0::/0 TA for each RIR, and using an openssl facility to generate an X509 Certificate Signing Request (CSR) from a valid certificate, the TA keypair is used to sign over these operational certificates, changing the Issuer to the new CN=example-nro-ta but leaving the Subject and subject information access for each CA unchanged. This means that it finds the .mft manifest files, and the rsync and rrdp repository paths, unchanged from the issuing RIR, and can therefore validate all products found there, signed over by the RIR keypair.

This means that a top-down walk of the signed products of this example NRO TA certificate will find the daughter RIR objects, re-issued by it but with the same public key signed, such that their grand-daughter products can be validated in a tree-walk. No re-signing beyond the intermediate Operational CA certificates for the RIR is required. No instance of all resources claim exists in this hierarchy.

The TAL file for this TA is as follows:



this should be valid in any current RPKI validator such as rpki-client

As a logistical simplification this CA's repository is rsync only at this time, no RRDP service has been published for the products.

OpenSSL Code modifications

To generate the daughter certificates from a CSR, generated from the real certificates as published, it is necessary to run a development version of OpenSSL 3.3 which has the ability to specify the Issuer name. Older versions of the OpenSSL apps/x509.c app use the Subject name as Issuer name, making the certificate created a self-signed certificate by name.

example invokation

A scripted process to generate the RIPE NCC operational certificate as a child of the NRO self signed certificate:

fetch the cert:

$ rsync --no-motd rsync:// ripe.cer
$ ls -lan ripe.cer
-rw-r--r--  1 1000  0  1259 Jan 16 18:41 ripe.cer

extract the pubkey:

/usr/local/src/openssl/apps/openssl x509 -in ripe.cer -pubkey -out ripe.pem

convert cert to csr:

/usr/local/src/openssl/apps/openssl x509 -x509toreq -in ripe.cer -force_pubkey ./ripe.pem -key ca/ca/private/ca.key -out ripe.csr

sign over their 3779:

/usr/local/src/openssl/apps/openssl x509 \
    -new \
    -set_issuer '/CN=example-nro-ta' \
    -set_subject '/CN=2a7dd1d787d793e4c8af56e197d4eed92af6ba13' \
    -extfile ./ripe.cnf \
    -extensions signing_ca_ext \
    -out newripe.pem \
    -days 1 \
    -force_pubkey ripe.pem \
    -key ca/ca/private/ca.key

and here is the OpenSSL .cnf for the RIPE certificate which invokes the list of RIPE resources as shown above:

[ signing_ca_ext ]
keyUsage                = critical,keyCertSign,cRLSign
basicConstraints        = critical,CA:true
subjectKeyIdentifier    = hash
authorityKeyIdentifier  = keyid:always
certificatePolicies     = critical,@pqs
authorityInfoAccess     = caIssuers;URI:rsync://
crlDistributionPoints   = URI:rsync://
subjectInfoAccess       = caRepository;URI:rsync://,rpkiManifest;URI:rsync://
sbgp-autonomousSysNum   = critical, @asnum-section
sbgp-ipAddrBlock        = critical, @ipaddr-section
.include                = /usr/local/www/data/labs/docs/nro-ta/ripe.cnf