Registration Data Access Protocol (RDAP) Extension for Resource Public Key Infrastructure (RPKI) Registration Data
ARIN
jasdips@arin.net
ICANN
andy@hxr.us
Applications and Real-Time Area (ART)
Registration Protocols Extensions (regext)
The Resource Public Key Infrastructure (RPKI) is used to secure inter-domain routing on the internet. This document
defines a new Registration Data Access Protocol (RDAP) extension with identifier "rpki1", for accessing the RPKI
registration data in the Internet Number Registry System (INRS) for the Route Origin Authorization (ROA), Autonomous
System Provider Authorization (ASPA), and X.509 Resource Certificate RPKI profiles through RDAP. The INRS is composed of
Regional Internet Registries (RIRs), National Internet Registries (NIRs), and Local Internet Registries (LIRs).
Introduction
The network operators are increasingly deploying the Resource Public Key Infrastructure (RPKI) to secure
inter-domain routing on the internet. RPKI enables Internet Number Resource (INR) holders to
cryptographically assert about their registered IP addresses and autonomous system numbers to prevent route hijacks and
leaks. To that end, RPKI defines the following profiles:
- Route Origin Authorization (ROA) where a Classless Inter-Domain Routing (CIDR) address block
holder cryptographically asserts about the origin autonomous system (AS) for routing that CIDR address
block.
- Autonomous System Provider Authorization (ASPA) where an autonomous system number
(ASN) holder cryptographically asserts about the provider ASes for that ASN.
- X.509 Resource Certificate where the issuer grants the subject a right-of-use for the listed IP
addresses and/or autonomous system numbers.
This document defines a new RDAP extension with identifier "rpki1", for accessing the RPKI registration data in the
Internet Number Registry System (INRS) for the aforementioned RPKI profiles through RDAP. The INRS is composed of
Regional Internet Registries (RIRs), National Internet Registries (NIRs), and Local Internet Registries (LIRs).
The motivation here is that such RDAP data could complement the existing RPKI diagnostic tools (e.g., ,
, etc.) when troubleshooting a route hijack or leak, by conveniently providing access to
registration information from a registry's database beside what is inherently available from an RPKI profile object.
There is registration metadata that is often needed for troubleshooting that does not appear in an RPKI profile object
or its verified payload but could be looked up or searched using RDAP; such as:
- When did the initial version of a ROA get published?
- Was a ROA created in conjunction with an Internet Routing Registry (IRR) route?
- Which IRR routes are related with a ROA?
- Which ROAs are associated with an IP network?
- Which ROAs are associated with an origin AS?
- Which ASPAs are associated with a provider AS?
- Which X.509 resource certificates are associated with an organization?
- Which organization is registered as the authoritative source for an RPKI profile object?
Furthermore, correlating registered RPKI data with registered IP networks and autonomous system numbers would also give
access to the latter's contact information through RDAP entity objects, which should aid troubleshooting.
In addition to troubleshooting, serving RPKI metadata over RDAP offers a convenience to network operators
through a simple lookup mechanism. As is demonstrated in , constructing custom RDAP scripts is
relatively easy and beneficial to network operators for the purposes of reporting. Though not RDAP-based, systems such
as and have shown the utility of an approach that allows users to explore the RPKI hierarchy in a
visual fashion, without interacting with the signed objects directly.
For these purposes, this specification defines RDAP object classes, as well as lookup and search path segments, for the
ROA, ASPA, and X.509 resource certificate registration data.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",
"NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14
when, and only when, they appear in all capitals, as shown here.
Indentation and whitespace in examples are provided only to illustrate element relationships, and are not a required
feature of this specification.
"..." in examples is used as shorthand for elements defined outside of this document, as well as to abbreviate elements
that are too long.
Extension
This document defines a new RDAP extension with identifier "rpki1", for accessing the RPKI registration data in the INRS
for the ROA, ASPA, and X.509 Resource Certificate RPKI profiles through RDAP.
A server that supports the functionality specified in this document MUST include the "rpki1" string literal in the
"rdapConformance" array () for any lookup or search response containing an RDAP object per the
object class definition in , , or , as well as
in the help response. Here is an elided example for this inclusion:
This extension adheres to the guidelines in .
The "1" in "rpki1" denotes version 1 of this extension. New versions of this extension will use different extension
identifiers.
What It Is Not
This RDAP extension MUST NOT be used to directly influence internet routing. Neither RDAP nor this extension define the
necessary security properties or distribution mechanisms required to securely add, remove, or modify internet routes.
In The Future
In the future, if the RDAP data for the RPKI profiles supported in this document needs to evolve and/or additional RPKI
profiles need to be made accessible through RDAP, a new RDAP extension must be defined, adhering to the guidelines in
.
Common Data Members
The RDAP object classes for RPKI (, , ) can
contain one or more of the following common members:
- "handle" -- a string representing the registry-unique identifier of an RPKI object registration
- "name" -- a string representing the identifier assigned to an RPKI object registration by the registration holder
- "digests" -- an array of objects representing hashes that entirely cover an RPKI object; such an object can contain
the following members:
- "digest" -- a hexadecimal string representing the hash that entirely covers an RPKI object
- "digestAlgorithm" -- a string literal representing the algorithm used to generate the hash that entirely covers an
RPKI object, with possible values of "SHA-256" and "SHA-512" for this version of the specification
- "notValidBefore" -- a string that contains the time and date in Zulu (Z) format with UTC offset of 00:00
, representing the not-valid-before date of an X.509 resource certificate for an RPKI object
()
- "notValidAfter" -- a string that contains the time and date in Zulu (Z) format with UTC offset of 00:00 ,
representing the not-valid-after date of an X.509 resource certificate for an RPKI object ()
- "publicationUri" -- a URI string pointing to the location of an RPKI object within an RPKI repository;
the URI scheme is "rsync", per
- "notificationUri" -- an HTTPS URI string pointing to the location of the RPKI Repository Delta Protocol (RRDP) update
notification file for an RPKI repository ()
- "entities" -- an array of entity objects (), including the organization (entity) registered as
the authoritative source for an RPKI object
- "rpkiType" -- a string literal representing various combinations of an RPKI repository and a Certification Authority
(CA), with the following possible values:
- "hosted" -- both the repository and CA are operated by a registry for an organization with allocated resources
- "delegated" -- both the repository and CA are operated by an organization with resources allocated by a registry
- "hybrid" -- the repository is operated by a registry for an organization with allocated resources whereas the CA
is operated by the organization itself
The purpose of an object with "digest" and "digestAlgorithm" members is to enable an RDAP server to present a message
digest (hash) for an entire RPKI object, thereby providing RDAP clients with an exact reference to the underlying RPKI
object. This can help with analysis, research, and/or debugging.
For a CA that implements RRDP , the update notification file location is expected to be set in each X.509
resource certificate it issues (). Consequently, the "notificationUri" data should help inform
about the RPKI repository and/or CA operated downstream from a registry by an organization with resources allocated by
that registry.
Route Origin Authorization
Object Class
The Route Origin Authorization (ROA) object class can contain the following members:
- "objectClassName" -- the string "rpki1_roa"
- "handle" -- see
- "name" -- see
- "digests" -- see
- "roaIps" -- an array of objects representing CIDR address blocks within a ROA; such an object can contain the
following members:
- "ip" -- a string representing an IPv4 or IPv6 CIDR address block with the "<CIDR prefix>/<CIDR length>" format
()
- "maxLength" -- a number representing the maximum prefix length of the CIDR address block that the origin AS is
authorized to advertise; up to 32 for IPv4 and up to 128 for IPv6 ()
- "originAutnum" -- an unsigned 32-bit integer representing the origin autonomous system number ()
- "notValidBefore" -- see
- "notValidAfter" -- see
- "publicationUri" -- see
- "notificationUri" -- see
- "entities" -- see
- "rpkiType" -- see
- "events" -- see
- "links" -- "self" link, and "related" links for IP network and IRR (when defined) objects ()
- "remarks" -- see
Here is an elided example of a ROA object:
Lookup
The resource type path segment for exact or closest match lookup of a ROA object is "rpki1_roa".
The following lookup path segments are defined for a ROA object:
Syntax: rpki1_roa/handle/<handle>
Syntax: rpki1_roa/ip/<IP address>
Syntax: rpki1_roa/ip/<CIDR prefix>/<CIDR length>
Syntax: rpki1_roa/digest/<digest algorithm>/<digest>
The /ip syntax mirrors the syntax for IP networks found in .
A lookup query for ROA information by handle is specified using this form:
rpki1_roa/handle/XXXX
XXXX is a string representing the "handle" property of a ROA, as described in . The following URL
would be used to find information for a ROA that exactly matches the "8a848ab0729f0f4f0173ba2013bc5eb3" handle:
A lookup query for ROA information by IP address is specified using this form:
rpki1_roa/ip/YYYY
YYYY is a string representing an IPv4 or IPv6 address. The following URL would be used to find information for the
most-specific ROA matching the "192.0.2.0" IP address:
Similarly, for the "2001:db8::" IP address:
A lookup query for ROA information by CIDR is specified using this form:
rpki1_roa/ip/YYYY/ZZZZ
YYYY/ZZZZ is a string representing the "ip" property of a CIDR address block within a ROA, as described in
. The following URL would be used to find information for the most-specific ROA matching the
"192.0.2.0/25" CIDR:
Similarly, for the "2001:db8::/64" CIDR:
A lookup query for ROA information by digest is specified using this form:
rpki1_roa/digest/BBBB/CCCC
BBBB is a string representing the "digestAlgorithm" property, and CCCC is a string representing the "digest" property,
as described in . The following URL would be used to find information for a ROA matching the
"7f83b1657ff1fc53b92dc18148a1d65dfc2d4b1fa3d677284addd200126d9069" SHA-256 digest:
In the "links" array of a ROA object, the context URI ("value" member) of each link should be the lookup URL by its
handle, and if that's not available, then the lookup URL by one of its IP addresses.
Search
The resource type path segment for searching ROA objects is "rpki1_roas".
The following search path segments are defined for ROA objects:
Syntax: rpki1_roas?name=<name search pattern>
Syntax: rpki1_roas?originAutnum=<autonomous system number>
Searches for ROA information by name are specified using this form:
rpki1_roas?name=XXXX
XXXX is a search pattern per , representing the "name" property of a ROA, as described in
. The following URL would be used to find information for ROA names matching the "ROA-*" pattern:
Searches for ROA information by origin autonomous system number are specified using this form:
rpki1_roas?originAutnum=BBBB
BBBB is an autonomous system number representing the "originAutnum" property of a ROA, as described in
. The following URL would be used to find information for ROAs with origin autonomous system number
65536:
Search Results
The ROA search results are returned in the "rpki1_roaSearchResults" member, which is an array of ROA objects
().
Here is an elided example of the search results when finding information for ROAs with origin autonomous system number
65536:
Reverse Search
By Entity
Per , if a server receives a reverse search query with a searchable resource type of "rpki1_roas",
a related resource type of "entity", and an entity property of "fn", "handle", "email" or "role", then the reverse
search will be performed on the ROA objects from its data store by the given entity property.
and include registration of entries for ROA searches in
the IANA "RDAP Reverse Search" and "RDAP Reverse Search Mapping" registries when the related resource type is "entity".
When an entity object has associated ROA objects, a related reverse search link could be included in its returned data.
For example:
By IP Network
An IP network object can span multiple ROA objects, and vice versa. Their relationship is affected by IP address
transfers and splits in a registry. It would be useful to find all the ROA objects associated with an IP network object.
To that end, per , if a server receives a reverse search query with a searchable resource type of
"rpki1_roas", a related resource type of "ip", and an IP network property of "handle", then the reverse search will be
performed on the ROA objects from its data store by the given IP network property.
and include registration of entries for ROA searches in
the IANA "RDAP Reverse Search" and "RDAP Reverse Search Mapping" registries when the related resource type is "ip".
When an IP network object has associated ROA objects, a related reverse search link could be included in its returned
data. For example:
Autonomous System Provider Authorization
Object Class
The Autonomous System Provider Authorization (ASPA) object class can contain the following members:
- "objectClassName" -- the string "rpki1_aspa"
- "handle" -- see
- "name" -- see
- "digests" -- see
- "customerAutnum" -- an unsigned 32-bit integer representing an autonomous system number of the registration holder
(called customer per ASPA terminology) ()
- "providerAutnums" -- an array of unsigned 32-bit integers, each representing the autonomous system number of an AS
that is authorized as a provider ()
- "notValidBefore" -- see
- "notValidAfter" -- see
- "publicationUri" -- see
- "notificationUri" -- see
- "entities" -- see
- "rpkiType" -- see
- "events" -- see
- "links" -- "self" link, and "related" links for autonomous system number and IRR (when defined) objects
()
- "remarks" -- see
Here is an elided example of an ASPA object:
Lookup
The resource type path segment for exact match lookup of an ASPA object is "rpki1_aspa".
The following lookup path segments are defined for an ASPA object:
Syntax: rpki1_aspa/handle/<handle>
Syntax: rpki1_aspa/autnum/<autonomous system number>
Syntax: rpki1_aspa/digest/<digest algorithm>/<digest>
The /autnum syntax mirrors the syntax for autonomous system numbers found in .
A lookup query for ASPA information by handle is specified using this form:
rpki1_aspa/handle/XXXX
XXXX is a string representing the "handle" property of an ASPA, as described in . The following URL
would be used to find information for an ASPA that exactly matches the "47ab80ed8693f25d0187d93a07db4484" handle:
A lookup query for ASPA information by customer autonomous system number is specified using this form:
rpki1_aspa/autnum/YYYY
YYYY is an autonomous system number representing the "customerAutnum" property of an ASPA, as described in
. The following URL would be used to find information for an ASPA with customer autonomous system
number 65536:
A lookup query for ASPA information by digest is specified using this form:
rpki1_aspa/digest/BBBB/CCCC
BBBB is a string representing the "digestAlgorithm" property, and CCCC is a string representing the "digest" property,
as described in . The following URL would be used to find information for an ASPA matching the
"f83b1657ff1fc53b92dc18148a1d65dfc2d4b1fa3d677284addd200126d90697" SHA-256 digest:
In the "links" array of an ASPA object, the context URI ("value" member) of each link should be the lookup URL by its
handle, and if that's not available, then the lookup URL by its customer autonomous system number.
Search
The resource type path segment for searching ASPA objects is "rpki1_aspas".
The following search path segments are defined for ASPA objects:
Syntax: rpki1_aspas?name=<name search pattern>
Syntax: rpki1_aspas?providerAutnum=<provider autonomous system number>
Searches for ASPA information by name are specified using this form:
rpki1_aspas?name=XXXX
XXXX is a search pattern per , representing the "name" property of an ASPA, as described in
. The following URL would be used to find information for ASPA names matching the "ASPA-*" pattern:
Searches for ASPA information by provider autonomous system number are specified using this form:
rpki1_aspas?providerAutnum=YYYY
YYYY is an autonomous system number within the "providerAutnums" property of an ASPA, as described in
. The following URL would be used to find information for ASPAs with provider autonomous system
number 65542:
Search Results
The ASPA search results are returned in the "rpki1_aspaSearchResults" member, which is an array of ASPA objects
().
Here is an elided example of the search results when finding information for ASPAs with provider autonomous system
number 65542:
Reverse Search
By Entity
Per , if a server receives a reverse search query with a searchable resource type of
"rpki1_aspas", a related resource type of "entity", and an entity property of "fn", "handle", "email" or "role", then
the reverse search will be performed on the ASPA objects from its data store by the given entity property.
and include registration of entries for ASPA searches in
the IANA "RDAP Reverse Search" and "RDAP Reverse Search Mapping" registries when the related resource type is "entity".
When an entity object has associated ASPA objects, a related reverse search link could be included in its returned data.
For example:
By Autonomous System Number
An autonomous system number object for an ASN range can span multiple ASPA objects. However, an ASPA object can only be
linked to a single autonomous system number object. It would be useful to find all the ASPA objects associated with an
autonomous system number object. To that end, per , if a server receives a reverse search query
with a searchable resource type of "rpki1_aspas", a related resource type of "autnum", and an autonomous system number
property of "handle", then the reverse search will be performed on the ASPA objects from its data store by the given
autonomous system number property.
and include registration of entries for ASPA searches in
the IANA "RDAP Reverse Search" and "RDAP Reverse Search Mapping" registries when the related resource type is "autnum".
When an autonomous system number object has associated ASPA objects, a related reverse search link could be included in
its returned data. For example:
X.509 Resource Certificate
Object Class
The X.509 resource certificate object class can contain the following members:
- "objectClassName" -- the string "rpki1_x509ResourceCert"
- "handle" -- see
- "digests" -- see
- "serialNumber" -- a string representing the unique identifier for the certificate ()
- "issuer" -- a string representing the CA that issued the certificate ()
- "signatureAlgorithm" -- a string representing the algorithm used by the CA to sign the certificate
()
- "subject" -- a string representing the identity of the subject the certificate is issued to ()
- "subjectPublicKeyInfo" -- an object representing the subject's public key information (), with
the following members:
- "publicKeyAlgorithm" -- a string representing the algorithm for the public key
- "publicKey" -- a string representation of the public key
- "subjectKeyIdentifier" -- a string, typically Base64-encoded, representing the unique identifier for the subject's
public key ()
- "ips" -- an array of strings, each representing an IPv4 or IPv6 CIDR address block with the
"<CIDR prefix>/<CIDR length>" format ()
- "autnums" -- an array of unsigned 32-bit integers, each representing an autonomous system number
()
- "notValidBefore" -- see
- "notValidAfter" -- see
- "publicationUri" -- see
- "notificationUri" -- see
- "entities" -- see
- "rpkiType" -- see
- "events" -- see
- "links" -- "self" link, "related" links for IP network and/or autonomous system number objects
(), and "rdap-help" link (see )
- "remarks" -- see
The following types of certificates can be represented using this object class:
- a CA certificate () that a registry issues to an organization (the subject) for its allocated
IP addresses and/or autonomous system numbers, authorizing the organization CA to issue end-entity certificates
()
- a BGPSec router certificate where an ASN(s) holder cryptographically asserts that a router (the subject)
holding the corresponding private key is authorized to emit secure route advertisements on behalf of the AS(es)
specified in the certificate
Here is an elided example of an X.509 resource certificate object for a CA certificate:
Here is an elided example of an X.509 resource certificate object for a BGPSec router certificate:
Lookup
The resource type path segment for exact match lookup of an X.509 resource certificate object is
"rpki1_x509ResourceCert".
The following lookup path segments are defined for an X.509 resource certificate object:
Syntax: rpki1_x509ResourceCert/handle/<handle>
Syntax: rpki1_x509ResourceCert/digest/<digest algorithm>/<digest>
A lookup query for X.509 resource certificate information by handle is specified using this form:
rpki1_x509ResourceCert/handle/XXXX
XXXX is a string representing the "handle" property of an X.509 resource certificate, as described in
. The following URL would be used to find information for an X.509 resource
certificate that exactly matches the "ABCD" handle:
A lookup query for X.509 resource certificate information by digest is specified using this form:
rpki1_x509ResourceCert/digest/BBBB/CCCC
BBBB is a string representing the "digestAlgorithm" property, and CCCC is a string representing the "digest" property,
as described in . The following URL would be used to find information for an X.509 resource
certificate matching the "83b1657ff1fc53b92dc18148a1d65dfc2d4b1fa3d677284addd200126d90697f" SHA-256 digest:
Search
The resource type path segment for searching X.509 resource certificate objects is "rpki1_x509ResourceCerts".
The following search path segments are defined for X.509 resource certificate objects:
Syntax: rpki1_x509ResourceCerts?issuer=<issuer search pattern>
Syntax: rpki1_x509ResourceCerts?subject=<subject search pattern>
Syntax: rpki1_x509ResourceCerts?subjectKeyIdentifier=<subject key identifier>
Syntax: rpki1_x509ResourceCerts?ip=<IP address>
Syntax: rpki1_x509ResourceCerts?cidr=<CIDR>
Syntax: rpki1_x509ResourceCerts?autnum=<autonomous system number>
Searches for X.509 resource certificate information by certificate issuer are specified using this form:
rpki1_x509ResourceCerts?issuer=YYYY
YYYY is a search pattern per , representing the "issuer" property of an X.509 resource
certificate object, as described in . The following URL would be used to find
information for X.509 resource certificate objects with issuer matching the "CN=ISP-*" pattern:
Searches for X.509 resource certificate information by certificate subject are specified using this form:
rpki1_x509ResourceCerts?subject=ZZZZ
ZZZZ is a search pattern per , representing the "subject" property of an X.509 resource
certificate object, as described in . The following URL would be used to find
information for X.509 resource certificate objects with subject matching the "CN=ISP-BGPSEC-ROUTE*" pattern:
Searches for X.509 resource certificate information by subject key identifier are specified using this form:
rpki1_x509ResourceCerts?subjectKeyIdentifier=BBBB
BBBB is a string representing the "subjectKeyIdentifier" property of an X.509 resource certificate object, as described
in . The following URL would be used to find an X.509 resource certificate object with
subject key identifier matching the "iOcGgxqXDa7mYv78fR+sGBKMtWJqItSLfaIYJDKYi8A=" string:
Searches for X.509 resource certificate information by an IP address are specified using this form:
rpki1_x509ResourceCerts?ip=CCCC
CCCC is a string representing an IPv4 or IPv6 address. The following URL would be used to find information for X.509
resource certificate objects with the "ips" member encompassing the "192.0.2.0" IP address:
Similarly, for the "2001:db8::" IP address:
Searches for X.509 resource certificate information by a CIDR are specified using this form:
rpki1_x509ResourceCerts?cidr=CCCC/DDDD
CCCC/DDDD is a string representing an IPv4 or IPv6 CIDR, with CCCC as the CIDR prefix and DDDD as the CIDR length. The
following URL would be used to find information for X.509 resource certificate objects with the "ips" member
encompassing the "192.0.2.0/25" CIDR:
Similarly, for the "2001:db8::/64" CIDR:
Searches for X.509 resource certificate information by an autonomous system number are specified using this form:
rpki1_x509ResourceCerts?autnum=EEEE
EEEE is an autonomous system number within the "autnums" property of an X.509 resource certificate object, as described
in . The following URL would be used to find information for X.509 resource
certificate objects with the "autnums" member including autonomous system number 65536:
Search Results
The X.509 resource certificate search results are returned in the "rpki1_x509ResourceCertSearchResults" member, which is
an array of X.509 resource certificate objects ().
Here is an elided example of the search results when finding information for X.509 resource certificate objects with
issuer matching the "CN=ISP-*" pattern:
Reverse Search
By Entity
Per , if a server receives a reverse search query with a searchable resource type of
"rpki1_x509ResourceCerts", a related resource type of "entity", and an entity property of "fn", "handle", "email" or
"role", then the reverse search will be performed on the X.509 resource certificate objects from its data store by the
given entity property.
and include registration of entries for X.509 resource
certificate searches in the IANA "RDAP Reverse Search" and "RDAP Reverse Search Mapping" registries when the related
resource type is "entity".
When an entity object has associated X.509 resource certificate objects, a related reverse search link could be included
in its returned data. For example:
By IP Network
It would be useful to find all the X.509 resource certificate objects associated with an IP network object. To that
end, per , if a server receives a reverse search query with a searchable resource type of
"rpki1_x509ResourceCerts", a related resource type of "ip", and an IP network property of "handle", then the reverse
search will be performed on the X.509 resource certificate objects from its data store by the given IP network property.
and include registration of entries for X.509 resource
certificate searches in the IANA "RDAP Reverse Search" and "RDAP Reverse Search Mapping" registries when the related
resource type is "ip".
When an IP network object has associated X.509 resource certificate objects, a related reverse search link could be
included in its returned data. For example:
By Autonomous System Number
It would be useful to find all the X.509 resource certificate objects associated with an autonomous system number
object. To that end, per , if a server receives a reverse search query with a searchable resource
type of "rpki1_x509ResourceCerts", a related resource type of "autnum", and an autonomous system number property of
"handle", then the reverse search will be performed on the X.509 resource certificate objects from its data store by the
given autonomous system number property.
and include registration of entries for X.509 resource
certificate searches in the IANA "RDAP Reverse Search" and "RDAP Reverse Search Mapping" registries when the related
resource type is "autnum".
When an autonomous system number object has associated X.509 resource certificate objects, a related reverse search link
could be included in its returned data. For example:
RDAP for Delegated and Hybrid RPKI
For delegated and hybrid RPKI (see "rpkiTypes" in ), a registry may ask an organization with
allocated resources to provide the base URL for its RDAP service. If the RDAP base URL is provided, then in the X.509
resource certificate object () for that organization's CA certificate, the registry
MUST include a link object () with the "rel" member set to "rdap-help" and the "href" member set
to the help URL () for that RDAP service by appending the "help" path segment to the provided
base URL. RDAP clients can then parse the base RDAP URL from the "href" value of such a link object and use the "ips"
and "autnums" values from the X.509 resource certificate object to form ROA and ASPA lookup queries for that
organization's RDAP service.
"rdap-help" is a new link relation type for RDAP help data (see ), enabling an RDAP client to
distinguish the help URL from other related URLs.
Here is an elided example of an X.509 resource certificate object for a delegated CA certificate with a "rdap-help"
link object:
In this example, note how the authority component (domain) in the "value" URL differs from that in the "href" URL for
the "rdap-help" link object, with the former for the registry's RDAP service and the latter for that organization's RDAP
service.
Security Considerations
This document does not introduce any new security considerations past those already discussed in the RDAP protocol
specifications (, ).
explains why this RDAP extension MUST NOT be used to directly influence internet routing.
IANA Considerations
RDAP Extensions Registry
IANA is requested to register the following values in the "RDAP Extensions" registry at :
- Extension identifier: rpki1
- Registry operator: Any
- Published specification: This document.
- Contact: IETF iesg@ietf.org
- Intended usage: This extension describes version 1 of a method to access the RPKI registration data through RDAP.
Link Relations Registry
IANA is requested to register the following value in the "Link Relations" registry at :
- Relation Name: rdap-help
- Description: Refers to a resource with RDAP help information related to the link context.
- Reference: This document.
Acknowledgements
Job Snijders, Ties de Kock, Mark Kosters, Tim Bruijnzeels, Bart Bakker, Frank Hill, Tobias Fiebig, Q Misell, and Rüdiger
Volk from the RPKI community provided valuable feedback for this document.
Change History
(Remove this section before publication.)
Changes from 00 to 01
- Adhering to the guidelines in .
- Highlighted other RDAP search scenarios that could help with RPKI troubleshooting.
- Be more explicit about what this extension is not. (Feedback from Tobias Fiebig during IETF 122 SIDROPS presentation.)
- How/when to evolve this extension in the future.
- Renamed the "autnum" member as "customerAutnum" in the ASPA RDAP object class to better match the "CustomerASID" field
from the ASPA RPKI profile.
Changes from 01 to 02
- Generate a message digest that covers an entire RPKI object. (Feedback from Job Snijders during IETF 122 SIDROPS
presentation.)
- Expound on RDAP for delegated and hybrid RPKI. (Feedback from Q Misell and Rüdiger Volk during IETF 122 SIDROPS
presentation.)
Changes from 02 to 03
- De-conflict lookup path segments.
- More useful reverse searches.
- Include RPKI-related reverse search links in returned data for an entity, an IP network, or an autonomous system
number.
- No need for search by handle when lookup by handle is available.
References
Normative References
Informative References
RPKI Portal
Cloudflare
JDR
NLNet Labs
Link Relations
IANA
NIST RPKI Monitor
NIST
RDAP Extensions
IANA
RDAP Guide
Newton, A.
RDAP Reverse Search
IANA
RDAP Reverse Search Mapping
IANA
Routinator
NLNet Labs