- Certificate Revocation List (CRL)¶
A list of digital certificates that have been revoked by the issuing Certificate Authority (CA) before their scheduled expiration date and should no longer be trusted. Each entry in a Certificate Revocation List includes the serial number of the revoked certificate and the revocation date. The CRL file is signed by the CA to prevent tampering. The RPKI CRL profile is defined in RFC 6487.
- Ghostbusters Record (GBR)¶
An RPKI object described in RFC 6493 that contains human contact information that may be verified (indirectly) by a CA certificate. The data in the record are those of a severely profiled vCard. Note that support for publication of GBR records is not widely implemented yet. As a result, Routinator will validate the object, but not produce any output for it.
A manifest is a signed object that contains a listing of all the signed objects in the repository publication point associated with an authority responsible for publishing in the repository. Refer to RFC 6486 for more information.
- Maximum Prefix Length (MaxLength)¶
The most specific announcement of an IP prefix an Autonomous System is authorised to do according to the published ROA.
- Publication Point¶
A directory within a repository that contains all the objects published by a single CA.
The RPKI repository system consists of multiple distributed and delegated repository publication points. Each repository publication point is associated with one or more RPKI certificates’ publication points.
- Resource Public Key Infrastructure (RPKI)¶
RPKI proves the association between specific IP address blocks or Autonomous System Numbers (ASNs) and the holders of those Internet number resources. The certificates are proof of the resource holder’s right of use of their resources and can be validated cryptographically. RPKI is based on an X.509 certificate profile defined in RFC 3779. Using RPKI to support secure Internet routing is described in RFC 6480.
- Route Origin Attestation (ROA)¶
A cryptographically signed object that contains a statement authorising a single Autonomous System Number (ASN) to originate one or more IP prefixes, along with their maximum prefix length. A ROA can only be created by the legitimate holder of the IP prefixes contained within it.
- Route Origin Validation (ROV)¶
A mechanism by which route advertisements can be authenticated as originating from an expected, authorised Autonomous System (AS).
- RPKI Relying Parties¶
Those who want to use a Public Key Infrastructure (PKI) to validate digitally signed attestations.
- RPKI Repository Delta Protocol (RRDP)¶
Described in RFC 8182, RRDP is a repository access protocol based on Update Notification, Snapshot, and Delta Files that a Relying Party can retrieve over the HTTPS protocol.
- RPKI-to-Router (RPKI-RTR)¶
The RPKI to Router protocol provides a simple but reliable mechanism for routers to receive RPKI prefix origin data from a trusted cache. It is standardised in RFC 6810 (v0) and RFC 8210 (v1).
- Stale Object¶
In RPKI, manifests and CRLs can be stale if the time given in their
next-updatefield is in the past, indicating that an update to the object was scheduled but didn’t happen. This can be because of an operational issue at the issuer or an attacker trying to replay old objects.
- Trust Anchor (TA)¶
Each of the five Regional Internet Registries (RIRs) publishes a trust anchor that includes all resources (a ‘0/0’ self-signed X.509 CA certificate). They issue a child certificate containing all the resources that are held and managed by the RIR.
- Trust Anchor Locator (TAL)¶
The Trust Anchor Locator (TAL) is used to retrieve and verify the authenticity of a trust anchor. Specified in RFC 8630, a TAL contains one or more URIs pointing to the RIR root certificate, as well as the public key of the trust anchor in DER format, encoded in Base64. The TAL is constant so long as the trust anchor’s public key and its location do not change.
- Unsafe VRPs¶
If the address prefix of a VRP overlaps with any resources assigned to a CA that has been rejected because if failed to validate completely, the VRP is said to be unsafe since using it may lead to legitimate routes being flagged as RPKI Invalid.
- Validated ROA Payload (VRP)¶
RPKI Relying Party software performs cryptographic verification on all published ROAs. If everything checks out, the software will produce one or more validated ROA payloads (VRPs) for each ROA, depending on how many IP prefixes are contained with in it. Each VRP is a tuple of an ASN, a single prefix and its maximum prefix length. If verification fails, the ROA is discarded and it’ll be like no statement was ever made.