]> Bertoldi Cybersecurity

alessandro@bertoldicybersecurity.com

Universita' degli Studi di Napoli Federico II

Via Claudio 21 Naples 80125 Italy spromano@unina.it

Applications and Real-Time REGEXT This document proposes an extension to the Registration Data Access Protocol (RDAP) that enables the representation and exchange of structured reliability assessment metadata for registrars and domain names. The extension defines a structured assessment envelope through which an RDAP server can expose assessment results produced by a registry, registrar, or third-party assessor in a common, machine-readable format within RDAP responses. The extension standardizes how assessment results are transported and referenced, not how they are computed. Scoring methodologies, thresholds, criteria, and governance frameworks are intentionally left to the operational and policy layer.

Introduction The domain registration ecosystem relies on registrars as critical intermediaries between domain owners and the global DNS infrastructure. Research has identified recurring systemic vulnerabilities in registrar processes, including credential recovery, identity verification, and email authentication configurations, that represent structural risks affecting large numbers of domains and their owners. These issues have in several cases remained unaddressed for extended periods despite responsible disclosure. The Registration Data Access Protocol (RDAP), defined in , , , , and , was designed as the successor to WHOIS and introduces structured JSON responses, authentication and authorization support, and a well-defined extensibility model. These properties make RDAP a suitable foundation for exposing structured security and reliability metadata in a standardized, interoperable way. This document defines an RDAP extension that provides an envelope for carrying assessment results related to the security posture and reliability of registrars and domain names. The extension standardizes the transport and referencing of such results; it does not define scoring methodologies, thresholds, or enforcement mechanisms. The protocol enables representation; the ecosystem decides how to populate and consume the exposed fields. The proposal is intended as complementary to , which establishes that contact data has been verified. The present extension adds a parallel layer: structured metadata about the security posture of the registrar and the domain itself.

Terminology 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. The following terms are used throughout this document:

Assessment Envelope:

The structured set of fields defined by this extension, representing the result of a security or reliability assessment of a registrar or domain. The envelope carries the result and points to the methodology; it does not define the methodology itself.

Score Scheme:

An identifier or URI that denotes the scoring methodology used to produce an assessment result. The scheme defines the semantics of the score value, its range, and its criteria. Scheme definitions are maintained externally to this document.

Score Issuer:

An opaque identifier for the entity that performed the assessment and produced the score value. The format and resolution of this identifier are defined by the scoreScheme.

Extension Identifier:

The RDAP extension string registered in the IANA RDAP Extensions Registry that identifies this extension.

Motivation and Problem Statement Research has identified recurring systemic vulnerabilities in domain registrar processes that cannot be addressed by conventional technical security controls. These vulnerabilities arise from weaknesses in the interface between digital systems and human processes, and include deficiencies in credential recovery, identity verification, and email authentication configurations. A notable characteristic of these vulnerabilities is their persistence: in several documented cases, exploitable issues remained unresolved for extended periods following responsible disclosure, reflecting diffuse accountability and the absence of structured incentives for timely remediation. These findings suggest that while technical standards such as SPF , DKIM , and DMARC are sound, their adoption and correct configuration cannot be reliably ensured without structured, machine-readable signaling mechanisms. The full technical details of the underlying research are documented in .

Why Protocol-Level Representation Helps Structured representation of assessment metadata at the protocol level offers several complementary benefits relative to existing operational approaches. First, publicly accessible, machine-readable assessment data creates reputational and commercial incentives for registrars and domain owners to adopt and maintain security best practices, analogous to the role of Certificate Transparency in the TLS ecosystem. Second, a standardized RDAP extension enables any registry, registrar, browser, or security tool to consume assessment metadata through a common interface, eliminating dependency on proprietary or registry-specific systems. Third, protocol-level representation does not replace operational scoring or enforcement programs. Rather, it provides a standardized channel through which the outputs of such programs can be expressed and consumed by the broader ecosystem.

Design Principles The following principles guide the design of this extension.

Separation of concerns:

This document defines the structured assessment envelope and extension points. The governance of who computes scores, the specific scoring methodology, any thresholds applied, and any enforcement actions based on scores belong to the operational and policy layer and are intentionally outside the scope of this document.

Envelope, not methodology:

The extension standardizes how assessment results are transported and referenced within RDAP. It does not standardize how assessments are performed, what criteria are evaluated, or what thresholds apply.

Extensibility:

The extension is designed to accommodate additional fields without breaking backward compatibility, consistent with RDAP's existing extensibility model.

Interoperability:

The extension is not tied to any specific registry, registrar, or policy framework. Any conformant RDAP server may implement it independently.

Complementarity:

The extension is designed to coexist with and complement , rather than replace or duplicate it.

RDAP Extension: Data Model

Extension Identifier This extension is identified by the string "reliabilityScoring", to be registered in the IANA RDAP Extensions Registry (see ). RDAP responses that include this extension MUST include the extension identifier in the "rdapConformance" array. Consistent with , the extension identifier contains no underscore character, and the JSON member defined by this extension is prefixed with the extension identifier.

Namespacing Approach This extension groups all its fields under a single top-level JSON member named "reliabilityScoring_assessment". The member name is prefixed with the extension identifier, while its child members (scoreScheme, scoreValue, and so on) are not individually prefixed. This follows the guidance in Section 2.5.2 of , which permits a prefixed container object whose children need not be prefixed, and avoids the bare extension identifier pattern disallowed in Section 2.3 of that document. The authors welcome working group feedback on this approach and on the choice of extension identifier.

Assessment Envelope The assessment envelope is the JSON object carried by the "reliabilityScoring_assessment" member. This member MAY appear within entity objects (objectClassName: "entity") and domain objects (objectClassName: "domain"). An entity is considered to represent a registrar when its "roles" array includes the value "registrar" as defined in Section 10.2.4 of . Each field within the envelope is individually OPTIONAL, subject to the constraints stated in the following section. Implementers SHOULD populate only those fields for which they have authoritative data. The envelope carries the result of an external assessment and points to the methodology used. It does not define the methodology, the criteria, or the thresholds.

Field Definitions The fields defined by this extension are described in the following table. Each field is individually OPTIONAL, subject to the constraints stated after the table.

Field	Type	Description
scoreScheme	string (URI or identifier)	Identifies the scoring methodology used to produce the assessment. When expressed as a URI, it MUST conform to . The scheme defines the semantics, range, and criteria of the score. Scheme definitions are maintained externally.
scoreValue	number	The non-negative numeric result of the assessment, as defined by the scoreScheme. If scoreMaxValue is present, scoreValue SHOULD NOT exceed scoreMaxValue unless the scoreScheme explicitly defines otherwise.
scoreMaxValue	number	The non-negative maximum possible value under the scoreScheme. Together with scoreValue, helps consumers interpret the numeric result.
scoreDate	string (date-time)	The date and time at which the assessment was last performed, in the format defined in .
scoreIssuer	string	An opaque identifier for the entity that performed the assessment and issued the score. The format and resolution of this identifier are defined by the scoreScheme; it may be a local name, a URI, or a registered identifier.
evidenceUri	string (URI)	An OPTIONAL URI pointing to supporting documentation, a detailed report, or the full assessment record maintained by the scoreIssuer.

Implementers MUST NOT infer normative meaning from the illustrative field values used in the examples in this document or in . The assessment envelope MUST contain at least one member. If scoreValue or scoreMaxValue is present, scoreScheme MUST also be present, so that the numeric result can be interpreted. If scoreValue is present, scoreDate and scoreIssuer SHOULD also be present. A member for which no value is available is omitted rather than being included with a null value.

Registrar Object Extension The following example illustrates how the assessment envelope MAY appear within an entity object representing a registrar.

Domain Object Extension The following example illustrates how the assessment envelope MAY appear within a domain object.

Relationship to Existing Work

Relationship to draft-loffredo-regext-rdap-verified-contacts The extension establishes that contact data associated with a domain or registrar has been verified. The present extension adds a complementary and orthogonal layer: structured metadata about the security posture of the registrar and the domain itself. The two extensions answer different questions. The verified-contacts extension addresses which contact fields have been verified and how the verification was performed. The reliability-scoring extension addresses what the assessed security posture of the entity managing that domain is. Both are expressible within the RDAP framework and are designed to coexist within the same RDAP response.

Relationship to PIR Abuse Intervention Program PIR's Abuse Intervention Program (AIP) and Quality Performance Index (QPI) represent an example of a registry-specific operational assessment program. This document does not standardize such a program; it defines a generic RDAP representation that could carry outputs produced by programs such as PIR/QPI or other assessment frameworks. An operational scoring system such as PIR/QPI could, in principle, expose its outputs through the envelope defined in this document, enabling broader interoperability without modifying its internal methodology.

Relationship to RDAP Core Specifications This extension is designed to be fully conformant with the RDAP core specifications . It uses the JSON response format defined in , the extensibility model provided in , and the security framework of . Query formats follow and service discovery follows .

Security Considerations The fields defined in this extension are informational. They do not constitute enforcement mechanisms and MUST NOT be interpreted as authoritative security certifications.

Score integrity:

This document does not define an interface for creating or modifying assessment metadata. Any administrative or provisioning interface used for that purpose MUST authenticate and authorize the submitting entity and MUST provide appropriate integrity and confidentiality protection. Without authentication of the scoring entity, assessment metadata is susceptible to manipulation.

Gaming and abuse:

Any publicly visible scoring system creates incentives for gaming. The governance framework, which is outside the scope of this document, SHOULD address verification, audit, and revocation mechanisms.

False assurance:

Consumers of assessment metadata MUST NOT treat scores as equivalent to security certifications. A high score value does not guarantee the absence of vulnerabilities. Consumers SHOULD treat scores as one signal among many and SHOULD NOT make high-stakes trust decisions based solely on RDAP assessment fields.

Staleness:

Scores reflect the state at the time indicated by the "scoreDate" field. Consumers SHOULD check the freshness of assessment data and SHOULD treat scores that have not been updated recently with appropriate skepticism. Implementers MAY define an expiration policy based on the scoreScheme.

Scheme trust:

The reliability of assessment data depends on the trustworthiness of both the scoreIssuer and the scoreScheme. Consumers SHOULD establish out-of-band trust in the scoreIssuer before acting on assessment data.

Evidence URI:

The resource identified by evidenceUri is maintained by the scoreIssuer and is outside the control of the RDAP server. Its content may change over time, may be subject to access control, and may become unavailable. Consumers SHOULD NOT assume that the evidence resource is publicly accessible or immutable.

Privacy Considerations The fields defined in this extension describe security posture at the registrar and domain level and are not intended to expose personal data. They are designed to be compatible with the access control framework defined in . Implementers MUST ensure that the presence or absence of assessment metadata does not inadvertently reveal information about the identity of natural persons. The separation between assessment metadata, which is designed to be publicly accessible where server policy and applicable access controls permit, and contact data, which is subject to access control per , MUST be maintained in conformant implementations. This extension is intended to be compatible with applicable data protection regulations, including the General Data Protection Regulation and equivalent frameworks. The evidenceUri field, if populated, SHOULD NOT point to resources that expose personal data or operationally sensitive details beyond what is necessary for the consumer to understand the assessment result.

IANA Considerations This document requests the registration of the following entry in the IANA RDAP Extensions Registry:

Extension identifier:

reliabilityScoring

Registry operator:

Any

Published specification:

this document

Contact:

Alessandro Bertoldi (alessandro@bertoldicybersecurity.com)

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar. A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] This document is one of a collection that together describes the Registration Data Access Protocol (RDAP). It describes how RDAP is transported using the Hypertext Transfer Protocol (HTTP). RDAP is a successor protocol to the very old WHOIS protocol. The purpose of this document is to clarify the use of standard HTTP mechanisms for this application. The Registration Data Access Protocol (RDAP) provides "RESTful" web services to retrieve registration metadata from Domain Name and Regional Internet Registries. This document describes information security services, including access control, authentication, authorization, availability, data confidentiality, and data integrity for RDAP. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes uniform patterns to construct HTTP URLs that may be used to retrieve registration information from registries (including both Regional Internet Registries (RIRs) and Domain Name Registries (DNRs)) using "RESTful" web access patterns. These uniform patterns define the query syntax for the Registration Data Access Protocol (RDAP). This document obsoletes RFC 7482. This document describes JSON data structures representing registration information maintained by Regional Internet Registries (RIRs) and Domain Name Registries (DNRs). These data structures are used to form Registration Data Access Protocol (RDAP) query responses. This document obsoletes RFC 7483. This document specifies a method to find which Registration Data Access Protocol (RDAP) server is authoritative to answer queries for a requested scope, such as domain names, IP addresses, or Autonomous System numbers. This document obsoletes RFC 7484. Informative References ICANN ARIN APNIC This document describes and clarifies the usage of extensions in RDAP. IIT-CNR/Registro.it IIT-CNR/Registro.it VeriSign, Inc. DENIC eG This document describes an extension to the Registration Data Access Protocol (RDAP) that allows the inclusion of verification status information for contact fields such as email addresses and phone numbers. The goal is to improve data quality and trustworthiness of RDAP responses by indicating which pieces of contact data have been verified and how. The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS-TRACK] DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay, or one of their agents. DKIM separates the question of the identity of the Signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature. This memo obsoletes RFC 4871 and RFC 5672. [STANDARDS-TRACK] Email on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the "MAIL FROM" of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby ADministrative Management Domains (ADMDs) can explicitly authorize the hosts that are allowed to use their domain names, and a receiving host can check such authorization. This document obsoletes RFC 4408. Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling. Originators of Internet Mail need to be able to associate reliable and authenticated domain identifiers with messages, communicate policies about messages that use those identifiers, and report about mail using those identifiers. These abilities have several benefits: Receivers can provide feedback to Domain Owners about the use of their domains; this feedback can provide valuable insight about the management of internal operations and the presence of external domain name abuse. DMARC does not produce or encourage elevated delivery privilege of authenticated email. DMARC is a mechanism for policy distribution that enables increasingly strict handling of messages that fail authentication checks, ranging from no action, through altered delivery, up to message rejection. European Parliament and Council of the European Union Public Interest Registry

Acknowledgments The authors thank Pawel Kowalik, Mario Loffredo, Maurizio Martinelli, James Gould, and James Galvin for their early engagement and feedback during IETF 125.

Example RDAP Responses The examples in this appendix are provided for illustrative purposes only. Score values, scheme identifiers, and issuer names are fictional.

Domain Lookup with Assessment

Registrar Entity Lookup with Assessment

Domain Lookup without Assessment When no assessment metadata is conveyed, the "reliabilityScoring_assessment" member is omitted. Its absence MUST NOT be interpreted as evidence that the object has not been assessed. For example:

Illustrative Scoring Dimensions This appendix describes possible dimensions that an operational scoring program might evaluate when producing assessment results to be carried by the envelope defined in this document. This content is entirely non-normative. Nothing in this appendix constrains implementers or defines mandatory evaluation criteria. The intent is to demonstrate that the envelope model is expressive enough to carry results from real-world assessment programs, including those derived from existing empirical research on registrar security posture .

Possible Registrar Assessment Dimensions An operational program might evaluate registrars across dimensions such as: the strength of customer identity verification procedures; the adoption and enforcement of multi-factor authentication for customer-facing and internal systems; the possession of recognized information security certifications such as ISO/IEC 27001 or ISO/IEC 27701 ; the correctness of email authentication configurations including SPF , DKIM , and DMARC on registrar-operated domains; the existence of documented security policies; and the regularity of cybersecurity training programs for staff.

Possible Domain Assessment Dimensions An operational program might evaluate individual domains across dimensions such as: the strength of owner identity verification at registration or renewal; the level of SSL/TLS certificate used; the correctness of SPF, DKIM, and DMARC configurations; the implementation of DNSSEC ; and the absence of the domain from monitored abuse blacklists over a defined observation period.

Note on Existing Operational Programs Existing programs such as PIR's Quality Performance Index focus on observable abuse outcomes and operational metrics within a single registry context. The assessment dimensions described above focus on structural security posture. The envelope defined in this document is agnostic to the methodology and could carry results from either type of program.