]> Independent

United States k.s.swaminathan@live.com

Applications and Real-Time Individual Submission dka public key distribution email identifiers This document specifies the Domain Key Authority (DKA) framework, a DNS-anchored public-key distribution mechanism for the email-address namespace. The framework enables an Internet domain to designate an authoritative key service that verifies, stores, and distributes selector-scoped public keys for email-address identifiers under that domain. A Fallback DKA (fDKA) provides coverage for identifiers whose domains have not deployed a DKA, addressing the bootstrapping problem that has hindered comparable proposals. The result is a decentralized, deterministic, and application-agnostic framework for verified public-key discovery that supports incremental deployment and cryptographic agility. About This Document Status information for this document may be found at .

Introduction Email addresses are widely used as identifiers for individuals and automated agents on the Internet. Beyond email communication, they serve as login identifiers for banking, government services, e-commerce, social media, healthcare portals, and enterprise applications. Despite this ubiquity, there is no commonly adopted mechanism by which a public key can be associated with an email address and discovered in a consistent, interoperable manner. Such a mechanism could enable end-to-end encrypted email without proprietary infrastructure, digitally signed messages with stronger origin assurance, passwordless authentication in which a relying party verifies possession of a private key rather than a shared secret, and secure key distribution for messaging systems and related protocols. Infrastructure frameworks that depend on per-domain deployment for initial utility face a well-known bootstrapping challenge: applications lack incentive to implement the framework until enough domains have deployed, and domains lack incentive to deploy until enough applications create demand. A successful framework must address this bootstrapping problem to achieve practical deployment. Over the past three decades, several systems have addressed parts of this problem. Each contributed important ideas, but each also revealed limitations that inform the design requirements for a more deployable framework.

Prior Approaches and Lessons Learned

OpenPGP and the Web of Trust OpenPGP introduced a decentralized model in which users generate their own key pairs and other users may certify bindings between identities and keys through a web of trust. Public keys can be uploaded to key servers for distribution. This model demonstrated the value of decentralized key generation and distribution, but it has seen limited deployment outside technically sophisticated communities. In particular, user-to-user certification does not scale well for the general Internet population, key servers do not by themselves establish verified bindings between an email address and a submitted key, and key discovery is not deterministic: a relying party may need to consult multiple servers, and the absence of a key at one location does not establish that no key exists. These observations suggest that a more deployable framework should provide built-in verification of the binding between an email address and its public key, should support deterministic lookup, and should not depend on user-to-user coordination for routine operation.

S/MIME and Certificate Authorities S/MIME addressed the verification problem by using Certificate Authorities (CAs) to certify bindings between identities and public keys. In enterprise and managed environments, this approach can provide a workable solution for encrypted and signed email. However, S/MIME deployment has generally depended on access to CA infrastructure and related operational arrangements, which has limited participation outside managed environments. This suggests that a broadly deployable framework should support participation by any email address, including addresses under domains that have not deployed specialized PKI infrastructure of their own.

DANE and DNS-Based Key Distribution DANE and OPENPGPKEY contributed an important architectural insight: the domain is a natural authority for information about addresses under its namespace, and DNS is a natural mechanism for designating that authority. However, storing per-user key material directly in DNS can create operational challenges at large scale. DNS is well suited to publishing domain-level and service-level information, but per-user key distribution may require storage, update, and retrieval mechanisms that scale more naturally through database-backed services and application-layer APIs. The lesson is that DNS is well suited for designating where authoritative key information can be obtained, while the key material itself may be better served through infrastructure that scales independently of DNS.

Web Key Directory Web Key Directory (WKD) partially addressed this issue by separating publication from DNS storage and delivering keys over HTTPS. This demonstrated the practical value of using existing web infrastructure to distribute per-address key material. However, WKD relies on domain-hosted publication without defining a broader framework for verified key registration and universal lookup coverage. Further, WKD is limited to a particular application context and does not define a general mechanism for distributing multiple keys for the same identifier for different uses.

Design Principles The preceding discussion motivates the following design principles for the DKA framework:

• Domain-designated authority. A domain designates, using DNS, an authoritative key service for identifiers under its namespace. Authority over key records for a given identifier derives from that domain's DNS designation.
• Scalable key distribution. Per-identifier key material is stored and served through infrastructure that scales independently of DNS.
• Verified binding. The framework provides mechanisms for verifying the association between an email-address identifier and its public key, and communicates which verification methods were performed so that relying applications can apply local trust policy.
• Deterministic lookup. Given an email-address identifier and a selector, a conforming client obtains a single definitive result by following a fixed lookup order: a matching key record, an indication that no record exists, or an error.
• Application agnosticism. The framework distributes keys without prescribing or constraining what applications do with them.
• Cryptographic agility. The framework does not prescribe a single key type or algorithm and supports future cryptographic schemes.
• Incremental deployment. The framework operates over existing DNS, email, and HTTPS infrastructure and does not require coordinated ecosystem-wide upgrades.
• Universal coverage. Via the Fallback DKA (fDKA), the framework provides immediate coverage for every email-address identifier regardless of whether that identifier's domain has deployed a DKA, addressing the bootstrapping problem that has limited adoption of comparable proposals.

Scope This document specifies the DKA framework: DNS-based designation of Domain Key Authorities, the key lookup protocol, the key registration mechanism, selector-scoped key management, and the Fallback DKA. The framework is application-agnostic. Applications that consume DKA-distributed keys (such as encrypted email, passwordless authentication, or cryptocurrency wallet addressing) are outside the scope of this document.

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.

Terminology

• Email-Address Identifier: An identifier having the syntactic form of an email address (local-part@domain), used as the name to which one or more public keys can be bound. The syntax of email-address identifiers follows .
• Domain Portion: The portion of an email-address identifier following the "@" character.
• Domain Key Authority (DKA): A network-accessible service designated by an Internet domain to collect, verify, store, and distribute public keys associated with email-address identifiers under that domain.
• Fallback DKA (fDKA): A DKA designated by a well-known domain that accepts key registrations from email-address identifiers belonging to any domain. The fDKA is operationally identical to a domain DKA except that it does not restrict registrations to a single domain.
• Designating Domain: An Internet domain that publishes a DKA Locator Record designating a DKA as authoritative for public keys associated with email-address identifiers under that domain.
• DKA Locator Record: A DNS TXT record at a well-known subdomain by which a designating domain designates its DKA.
• Selector: A string value that distinguishes one public key from another for the same email-address identifier, enabling different keys for different application contexts.
• Default Selector: The selector value "default", used when no selector is explicitly specified.
• Public Key Record: A data object maintained by a DKA that associates a public key with an email-address identifier and selector, together with verification metadata and optional application metadata.
• Verification Methods: Named methods performed by a DKA to verify the association between an email-address identifier and a submitted public key.
• Key Lookup Request: A request sent by a client to a DKA to obtain the Public Key Record associated with a specified email-address identifier and optional selector.
• Key Lookup Response: A response returned by a DKA containing the requested Public Key Record, an indication that no matching record exists, or an error.
• Requesting Client: A software component that performs DKA discovery and sends Key Lookup Requests.
• Registrant: An entity that submits a public key for association with an email-address identifier.

Architecture Overview The DKA framework is a distributed framework in which Internet domains designate Domain Key Authorities to act as key services for email-address identifiers under those domains. The framework separates four functions that have been conflated, underspecified, or application-bound in earlier approaches:

• Designation of authority. DNS provides the designation function at domain granularity, identifying which service is authoritative for key records under a given domain.
• Storage of key material. The DKA service stores per-identifier key records at identifier-level granularity using infrastructure that scales independently of DNS.
• Retrieval of key records. The DKA service is discovered by applications via DNS and accessed via HTTPS to retrieve structured key records with metadata.
• Identifier-to-key binding. The framework treats an email-address identifier as an Internet identifier to which one or more public keys may be bound, without limiting use of those keys to email transport. This separates the identifier's role as a routable email address from its broader role as a name for a person, agent, service, or account in applications that consume DKA-distributed keys.

This separation preserves domain-level authority while permitting key storage and lookup to be implemented using databases, caches, or other application-layer infrastructure.

DKA Framework Architecture

Lookup Priority The lookup protocol gives priority to the domain DKA for any (email-address identifier, selector) pair it holds. For a given pair, the client queries the domain DKA first. If the domain DKA returns a matching record, the lookup is complete and the fDKA is not queried. If the domain DKA does not hold a record for that pair, or if no domain DKA exists, the client queries the fDKA. The complete procedure is specified in .

Universal Coverage The Fallback DKA (fDKA), designated by a well-known domain under IANA governance, accepts registrations from any email-address identifier regardless of its domain. The fDKA addresses the bootstrapping problem: any email address can register a key with the fDKA and any application can query it, creating a usable key-distribution service from initial deployment without requiring per-domain adoption. As individual domains deploy their own DKAs, the lookup order () naturally gives priority to domain-designated services. The fDKA continues to serve (identifier, selector) pairs for which the domain DKA has no record, ensuring uninterrupted coverage during the transition.

Selector-Scoped Keys An email-address identifier may be associated with multiple public keys, each distinguished by a selector. Selectors allow different applications to use different keys without the DKA interpreting what the selectors mean or what applications consume them. For example, an identifier might have one key under selector "default" for general use, another under "auth" for authentication, and another under "signing" for digital signatures. The DKA stores and serves keys by identifier and selector without assigning semantic meaning to selector values. Applications define their own selector conventions independently.

Cryptographic Agility The DKA framework does not prescribe a key type or algorithm. Selector-scoped Public Key Records MAY maintain metadata associated with each public key to indicate its cryptographic properties. This cryptographic agnosticism enables the DKA framework to support future cryptographic schemes, including post-quantum schemes.

Deterministic Lookup For any given (email-address identifier, selector) pair, a conforming client follows a fixed lookup order. The client first queries the DKA designated by the identifier's domain. If that DKA returns a matching Public Key Record, that record is the lookup result and the client does not query the fDKA for the same pair. If the domain DKA returns no matching record, or if no domain DKA is designated, the client queries the fDKA, whose response becomes the final result. Because all conforming clients follow this same ordered procedure, they obtain the same result for the same (email-address identifier, selector) pair, assuming the underlying DKA state is unchanged.

Incremental Deployment The framework operates over existing DNS, email, and HTTPS infrastructure and is not dependent on universal adoption. Email-address identifiers under domains that have deployed a DKA use their respective DKAs for key distribution. Email-address identifiers under domains that have not deployed a DKA use the fDKA.

Discovery and Retrieval Flow A Requesting Client begins with an email-address identifier for which it seeks a public key. The flow proceeds as follows:

1. The client extracts the domain portion of the identifier.
2. The client queries DNS for a DKA Locator Record at _dka.<domain>.
3. If a DKA Locator Record is found, the client obtains the DKA hostname.
4. The client constructs the lookup URL and sends a Key Lookup Request to the DKA, specifying the email-address identifier and optionally a selector.
5. If the DKA returns a matching Public Key Record, the lookup is complete.
6. If no matching record is found at the domain DKA, or if no DKA Locator Record exists for the domain, the client sends a Key Lookup Request to the fDKA.

DNS Designation

DKA Locator Record A domain designates its DKA by publishing a TXT record at the DNS name formed by prepending "_dka." to the domain. The record format follows the tag-value syntax used by DMARC and DKIM : The record contains the following tags:

• v=DKA1 (REQUIRED): Version tag identifying this as a DKA designation record and indicating protocol version DKA1.
• dka= (REQUIRED): Hostname of the DKA service.

The record format is defined by the following ABNF :

ABNF for DKA Locator Record

The underscore-prefixed subdomain follows the conventions established in for DNS names used with underscore-scoped service designations. A domain MUST NOT publish more than one valid DKA Locator Record at the same _dka subdomain. If multiple TXT records exist at that name, a client MUST ignore records that do not contain a syntactically valid v=DKA1 tag. If more than one valid DKA Locator Record remains, the client MUST treat the condition as a configuration error. Clients MUST ignore unrecognized tags in the DKA Locator Record. This permits future versions to introduce additional tags without breaking existing clients.

DKA Service Endpoint The DKA service identified by the DKA Locator Record MUST expose its lookup interface at the well-known URI path /.well-known/dka/ as defined by . The DKA service MUST be served over HTTPS . Clients MUST NOT send Key Lookup Requests over unencrypted HTTP.

fDKA Designation The fDKA is designated by a well-known domain managed under IANA governance. The designation uses the same DKA Locator Record format as domain DKAs. The recommended designation is fdka.arpa. The corresponding DKA Locator Record would be: The fDKA is intended to operate as a shared community infrastructure service, analogous to other IANA-managed infrastructure zones such as those under the .arpa top-level domain (see RFC 3172). IANA will designate the domain, and the IETF community will determine the detailed operational arrangements including selection of operator(s), service expectations, abuse mitigation policies, and transparency requirements through the normal IETF process. The fDKA implements the same registration, verification, lookup, and response protocols as a domain DKA, with the sole difference that it does not enforce domain verification (). Operators of the fDKA zone MUST publish the DKA Locator Record with DNSSEC signing and are expected to follow established best practices for high-availability infrastructure services, including robust rate limiting, monitoring, and minimal logging of personal data.

Subdomain Scoping Each domain portion in an email-address identifier is treated as a distinct designating domain. A DKA Locator Record at _dka.example.com designates a DKA for email-address identifiers whose domain portion is example.com. It does not apply to sub.example.com or any other subdomain. A DKA Locator Record at _dka.sub.example.com would be required to designate a DKA for sub.example.com.

Client Discovery Given an email-address identifier user@example.com, a Requesting Client:

1. Extracts the domain portion: example.com.
2. Queries DNS for TXT records at _dka.example.com.
3. Parses the response for a record containing v=DKA1.
4. Extracts the DKA hostname from the dka= tag.
5. Constructs the DKA Service Endpoint as https://<dka-hostname>/.well-known/dka/.

Key Registration

Registration Protocol A registrant submits a public key to a DKA by email. The registration follows a two-step protocol. Step 1 -- Initiation.
The registrant sends an email from the email address to be associated with the key (the submission email address) to the DKA's designated mailbox. The email need not contain any specific content. Step 2 -- Token exchange and key submission.
The DKA responds to the submission email address with a verification email containing a unique, time-limited verification token and instructions for completing registration. The registrant replies with the verification token and a JSON payload containing the public key and optional registration parameters: ", "public_key": "", "selector": "", "metadata": {} } ]]> In version DKA1, the JSON payload MUST be included in the body of the reply email. The DKA MUST extract the JSON from the first MIME part with Content-Type: application/json, or, if no such part exists, from the first text/plain MIME part whose content parses as valid JSON. Future versions of this specification may define additional submission mechanisms. It is expected that key submission and verification workflow will be performed through the use of automated assistants. The reply email MUST originate from the same email address to which the verification token was sent. The DKA MUST verify that the sender address on the reply matches the address to which the token was delivered.

Domain Verification A domain-scoped DKA MUST verify that the domain portion of the submission email address matches the domain the DKA serves. If the domain portion does not match, the DKA MUST reject the submission. An fDKA does not perform this domain check and accepts public keys from any email address. This is the sole protocol-level difference between a domain DKA and the fDKA.

Email-Address Verification The registration protocol described above establishes the registrant's control of the submission email address through two mechanisms:

• Mailbox control.
  The verification token is delivered to the submission email address and must be returned by the registrant. Successful return of the token confirms that the registrant has access to the mailbox associated with the submission email address.
• DKIM validation.
  The DKA validates the DKIM signature on the registration reply and verifies that the domain in the From address is the same as the DKIM signing domain identified by the d= tag. If these checks succeed, the DKA records the verification method dkim-validation.

The DKA records which verification methods were successfully performed. These are reported in the verification_methods field of the Key Lookup Response. The framework is designed to accommodate additional verification methods in future specifications. The initial verification method identifiers are:

• mailbox-control: The registrant demonstrated control of the mailbox.
• dkim-validation: A DKA-defined verification outcome indicating that the registration reply passed DKIM signature validation and that the domain in the From address matched the DKIM signing domain. This identifier documents what checks were performed by the DKA; it does not by itself imply any broader security or policy meaning beyond those checks.

Token Expiration Verification tokens MUST have a finite expiration period. The DKA MUST communicate the expiration period to the registrant in the verification email. The DKA MUST reject registration replies containing expired tokens.

Key Storage Upon successful verification, the DKA stores the public key as a Public Key Record associated with the submission email address and selector. If a Public Key Record already exists for the same email-address identifier and selector, the new record replaces it, and the record's version number is incremented. The public_key field contains a base64-encoded value. The DKA MUST verify that the public_key field is syntactically valid base64 before storing the Public Key Record. The DKA stores and serves this value without interpreting its decoded contents. The framework does not prescribe the key type, algorithm, or format of the encoded key material. Interpretation of the decoded key material is the responsibility of the consuming application.

Registration Confirmation Upon successful registration, update, or deletion of a Public Key Record, the DKA SHOULD send a confirmation email to the submission email address indicating the outcome and the selector affected.

Key Deletion A registrant may request deletion of a Public Key Record by initiating the registration protocol and replying to the verification token with a JSON payload that identifies the selector to be deleted: ", "selector": "", "delete": true } ]]> A deletion payload MUST NOT contain a public_key field. If a payload contains both a public_key field and "delete": true, the DKA MUST reject the request. A registration payload containing a valid public_key field and no "delete": true is a create-or-replace operation for the Public Key Record associated with the submission email address and selector. The DKA performs the same verification as for registration before deleting the record identified by the submission email address and selector. If no selector field is present, the DKA deletes the Public Key Record associated with the default selector. If no matching Public Key Record exists, the DKA SHOULD treat the request as successfully completed.

Key Registration Flow | | | | Step 2: Verification token | |<--------------------------------------| | | | Step 3: Reply with token + | | public key (JSON) | |-------------------------------------->| | | | +------------------+ | | Verify: | | | - Mailbox ctrl | | | - DKIM valid | | | - Domain match | | | (domain DKA) | | +------------------+ | | | Step 4: Confirmation (SHOULD) | |<--------------------------------------| | [Key stored] ]]>

Key Lookup

Lookup Request A Requesting Client obtains a Public Key Record by sending an HTTPS GET request to the DKA's lookup endpoint: /.well-known/dka/lookup ?email_address=&selector= ]]> The email_address parameter is REQUIRED and specifies the email-address identifier. The value MUST be percent-encoded per ; in particular, the "@" character MUST be encoded as %40. The selector parameter is OPTIONAL. If omitted, the DKA returns the Public Key Record associated with the default selector.

Lookup Response The DKA MUST return all responses with Content-Type: application/json. A successful lookup returns a JSON object with the following fields: Field definitions:

• email_address (REQUIRED): The email-address identifier associated with the Public Key Record.
• selector (REQUIRED): The selector value.
• public_key (REQUIRED): The base64-encoded public key.
• verification_methods (REQUIRED): An array of verification method identifiers indicating which methods the DKA successfully performed when the key was registered. This field provides provenance information for the key-to-identifier binding. It does not assert a trust level; relying applications apply their own trust policies based on the reported methods.
• metadata (REQUIRED): A JSON object containing key-value pairs provided by the registrant during registration. MAY be an empty object. The DKA stores and returns metadata without interpreting its contents.
• version (REQUIRED): An integer incremented each time the Public Key Record for this email-address identifier and selector is updated. Clients MAY use the version to detect key changes.
• updated_at (REQUIRED): An ISO 8601 timestamp indicating when the Public Key Record was last modified.

If no Public Key Record exists for the specified email-address identifier and selector, the DKA MUST return an HTTP 404 response. The response MUST NOT distinguish between "no keys exist for this identifier" and "keys exist for this identifier but not under the specified selector."

Error Responses When a request cannot be fulfilled, the DKA MUST return an appropriate HTTP status code with a JSON body containing at minimum the following fields: ", "message": "" } ]]> The following error codes are defined:

• not_found: No matching Public Key Record exists (HTTP 404).
• invalid_request: The request is malformed or missing required parameters (HTTP 400).
• rate_limited: The client has exceeded the DKA's rate limit (HTTP 429).
• server_error: An internal error prevented the DKA from fulfilling the request (HTTP 500).

DKAs MAY define additional error codes. Clients MUST treat unrecognized error codes as equivalent to server_error.

Caching DKAs SHOULD include appropriate Cache-Control headers in lookup responses. The specific caching policy is an operational decision for each DKA.

Lookup Order A Requesting Client looking up a public key for a given (email-address identifier, selector) pair MUST proceed as follows:

1. The client queries DNS for a DKA Locator Record for the identifier's domain.
2. If a DKA Locator Record is found, the client sends a Key Lookup Request to the designated domain DKA.
3. If the domain DKA returns a matching Public Key Record, the lookup is complete. The client MUST NOT query the fDKA for the same (identifier, selector) pair.
4. If the domain DKA returns a 404 response for the requested (identifier, selector) pair, or if no DKA Locator Record exists for the domain, the client sends a Key Lookup Request to the fDKA.
5. The result from the fDKA (a matching record or 404) is the final result.

This order is deterministic: for any given (identifier, selector) pair, a conforming client always obtains the same result regardless of implementation. The domain DKA has priority; the fDKA serves as the fallback for (identifier, selector) pairs that the domain DKA does not hold. A user MAY register keys at both their domain DKA and the fDKA. For a given email-address identifier and selector, a conforming client first queries the domain DKA. If the domain DKA returns a key for that selector, that key is the lookup result. Otherwise, the client queries the fDKA, and a key returned by the fDKA becomes the lookup result.

Key Lookup Flow ? | | | |--------------->| | | | DKA hostname | | | |<---------------| | | | | | | GET /.well-known/dka/lookup | | |------------------------------------>| | | Public Key Record or 404 | | |<------------------------------------| | | | | [Only if domain DKA returned 404 or no DKA exists] | | GET /.well-known/dka/lookup | |---------------------------------------------------->| | Public Key Record or 404 | |<----------------------------------------------------| ]]>

Selectors

The Default Selector Every DKA MUST support a selector value of "default". A registration that does not specify a selector is stored under the default selector. A lookup that does not specify a selector returns the Public Key Record associated with the default selector. This ensures that the simplest interaction with the framework --- registering a key without specifying a selector, looking up a key without specifying a selector --- works without the registrant or requesting client being aware of the selector mechanism.

Selector Naming Selector values are case-insensitive ASCII strings consisting of letters, digits, and hyphens. Selector values MUST NOT begin or end with a hyphen. Selector values MUST NOT exceed 63 characters in length. The syntax of a selector value is defined by the following ABNF :

ABNF for Selector Values

The DKA framework defines one reserved selector value, "default", which every conforming DKA MUST support. Apart from "default", this specification does not define a registry of selector values or assign semantic meaning to selectors. Applications that consume DKA-distributed keys define their own selector conventions independently of this specification.

Multiple Keys An email-address identifier MAY be associated with any number of Public Key Records under different selectors at the same DKA. Each (email-address identifier, selector) pair identifies at most one Public Key Record. Registration, update, and deletion operations act on a single (identifier, selector) pair.

The Fallback DKA

Purpose The fDKA is necessary to bootstrap the DKA framework. Without the fDKA, the framework would provide service only for identifiers under domains that have already deployed a DKA, creating a deployment deadlock in which applications have limited incentive to implement the framework until enough domains participate, and domains have limited incentive to deploy until enough applications consume it. The fDKA breaks this deadlock by providing an immediately available location at which any email-address identifier can register a key and from which clients can retrieve keys using the same lookup model.

Designation The fDKA is designated by a well-known domain managed under IANA governance. The designation uses the same DKA Locator Record format as domain DKAs.

Operational Equivalence The fDKA implements the same registration protocol, verification methods, lookup protocol, and response format as a domain DKA. The sole operational difference is that the fDKA does not perform domain verification (): it accepts registrations from email-address identifiers belonging to any domain. A conforming fDKA implementation is identical to a conforming domain DKA implementation with the domain restriction removed.

Registration Independence The domain DKA and the fDKA are independent key stores. A user MAY register keys at both their domain DKA and the fDKA. The existence of a domain DKA does not prevent a user from registering at the fDKA, and a domain DKA does not suppress the fDKA. For a given (identifier, selector) pair, the domain DKA takes precedence in the lookup order (). As a result, the domain DKA has priority for selectors it serves, while the fDKA can serve selectors not present at the domain DKA. Future specifications may define mechanisms by which a user can express a policy regarding which of their registered keys should be preferred for a given purpose.

Security Considerations

Security Property The DKA framework provides a single security property: verified provenance of the key-to-identifier binding. After a successful lookup, a Requesting Client can determine that:

• The public key was submitted by a party who demonstrated control of the mailbox associated with the email-address identifier at the time of registration (if mailbox-control is reported).
• The submission satisfied the DKA-defined checks corresponding to dkim-validation (if dkim-validation is reported).

The framework does not provide end-to-end authentication of the registrant's identity, does not attest to the registrant's possession of the corresponding private key (see ), and does not by itself provide transparency or historical continuity of keys. Future specifications may define transparency logs or other mechanisms for tracking the public-key history of (email-address identifier, selector) pairs.

Transport Security DKA service endpoints MUST be served over HTTPS to protect the integrity of lookup responses and prevent substitution of key material by on-path attackers.

DNS Security The DKA framework relies on DNS for discovery of Domain Key Authorities and therefore inherits the known vulnerabilities of the DNS protocol, including cache poisoning, unauthorized zone modifications, and man-in-the-middle attacks on queries that are not protected by DNSSEC. Without DNSSEC validation, an attacker capable of poisoning the cache for a _dka.<domain> record could redirect clients to a malicious DKA service that supplies attacker-controlled public keys, thereby undermining the integrity of key-to-identifier bindings. Domains that publish DKA Locator Records SHOULD deploy DNSSEC to provide origin authentication and data integrity for these records. The DKA Locator Record designating the Fallback DKA (fDKA) MUST be signed with DNSSEC, as the fDKA might serve a large number of email address identifiers. Operators of the fDKA zone are expected to follow established DNSSEC operational practices, including regular key rollover and monitoring.

Verification Provides Provenance, Not Trust The verification_methods field in a Key Lookup Response reports what the DKA verified when the key was registered. It does not assert a trust level or recommend a level of reliance. A consuming application that accepts keys verified only by mailbox-control knows that someone with mailbox access registered the key, but has no domain-level endorsement of that binding. An application that additionally requires dkim-validation knows that the registration satisfied the DKA-defined checks associated with that verification method. Neither method verifies that the registrant possesses the corresponding private key. Applications SHOULD select verification requirements based on their threat model and the consequences of accepting a fraudulent key. The framework does not impose policy; it provides the provenance data from which applications can make informed decisions.

Mailbox Compromise The primary threat to the key-to-identifier binding is compromise of the registrant's email account, which would allow an attacker to register a fraudulent key. This risk is inherent to any system that uses email-based verification and is mitigated by strong email account security practices, including multi-factor authentication. The current registration protocol verifies that the registrant controls the mailbox associated with the email-address identifier but does not verify that the registrant possesses the private key corresponding to the submitted public key. A proof-of-possession mechanism, in which the registrant signs a challenge with the corresponding private key, would strengthen the key-to-identifier binding by ensuring that only a party holding the private key can register it. Such a mechanism is expected to be addressed in a future specification.

Non-Enumeration A DKA MUST NOT provide any interface that enumerates email-address identifiers for which Public Key Records exist. A DKA MUST NOT provide any interface that enumerates selector values associated with a given email-address identifier. Lookups are point queries only: given an email-address identifier and a selector, the DKA returns the matching record or indicates that no matching record exists. When no matching record exists, the DKA MUST NOT distinguish between "this identifier has no keys" and "this identifier has keys but not under the specified selector." Both cases produce the same response.

Rate Limiting DKAs SHOULD implement rate limiting on Key Lookup Requests to mitigate enumeration attempts through brute-force querying of identifier-selector combinations.

Metadata Authenticity The metadata field in a Public Key Record is self-asserted by the registrant and is not verified by the DKA. Consuming applications MUST NOT treat metadata values (such as algorithm identifiers or expiration dates) as authoritative without independent verification.

Key Lifecycle Key updates and deletions follow the same verification requirements as initial registration. Detailed key lifecycle management, including rotation policies, revocation mechanisms, and multi-device coordination, is expected to be addressed in future specifications. Key transparency logs, which would allow clients to detect unexpected key changes, are a potential future extension.

Privacy Considerations The DKA framework publishes public-key bindings for email-address identifiers. As with any public lookup mechanism, this creates privacy considerations related to the exposure of identifier participation, metadata, and lookup behavior. A successful lookup reveals that a given (email-address identifier, selector) pair has a registered Public Key Record at a particular DKA. This may disclose that the identifier participates in the framework and, in some cases, that the registrant uses multiple selectors for different application contexts. Although the DKA framework prohibits enumeration interfaces and recommends rate limiting, a determined attacker may still attempt to infer participation through repeated point queries. The framework mitigates some privacy risks by decentralizing storage and lookup. Public Key Records are not maintained in a single global repository. Domains MAY operate their own DKAs, thereby limiting centralized aggregation of identifier-to-key bindings. The fDKA provides universal coverage without requiring all domains to deploy their own DKAs, but it also concentrates lookup traffic for identifiers whose domains have not deployed a DKA. The DKA framework does not require submission, escrow, or storage of private keys. DKAs store only public-key material and associated metadata. Compromise of a DKA therefore does not, by itself, reveal private keys. The framework avoids dependence on a separate revocation authority. A registrant who controls the mailbox associated with an email-address identifier can replace or delete a Public Key Record using the same verification process as registration. This allows users to revoke or rotate keys without relying on an external certificate or revocation service. DKA and fDKA operators will generally be able to observe lookup requests and registration traffic, including queried identifiers, source addresses, and timing information. Operators SHOULD minimize retention of logs containing personal data, SHOULD protect such logs appropriately, and SHOULD publish clear retention policies where feasible. Applications using DKA-distributed keys should consider whether a lookup may itself disclose user intent. For example, querying for a recipient's key may reveal an intention to communicate securely with that recipient. The lookup selector may reveal the purpose or application context of such communication. Applications with stronger privacy requirements MAY use additional measures such as query minimization, proxying, or privacy-preserving access mechanisms. The framework supports self-service key recovery, provided the user retains control of the associated mailbox.

Manageability Considerations DKA operators are responsible for maintaining reliable, secure, and scalable key services. This section outlines operational considerations for deploying and managing DKAs and the fDKA.

Service Availability DKA services SHOULD be operated with high availability. Operators SHOULD deploy redundant infrastructure, load balancing, and monitoring to ensure consistent responsiveness to lookup and registration requests.

Logging and Monitoring Operators SHOULD implement logging sufficient to diagnose operational issues, detect abuse, and support security investigations. Logs SHOULD avoid storing unnecessary personal data and SHOULD be protected appropriately. Retention periods SHOULD be minimized.

Abuse Mitigation DKAs SHOULD implement rate limiting, anomaly detection, and other abuse controls to prevent enumeration attempts, denial-of-service attacks, and malicious registration behavior.

Key Storage Integrity Operators MUST ensure that stored Public Key Records are protected against unauthorized modification. Storage systems SHOULD support integrity verification, access control, and regular backups.

DNS Operations Domains publishing DKA Locator Records SHOULD maintain DNSSEC signing and monitoring. Operators SHOULD ensure timely updates to DKA hostnames and SHOULD avoid stale or conflicting records.

Operational Transparency Operators SHOULD publish documentation describing service behavior, retention policies, rate limits, and operational practices. For the fDKA, such transparency is especially important due to its role as a shared infrastructure service.

IANA Considerations

Well-Known URI Registration This document requests registration of the following well-known URI :

Field	Value
URI suffix	dka
Change controller	IETF
Specification document	This document
Status	permanent

fDKA Domain This document requests designation of a well-known domain for the Fallback DKA under IANA governance. The operational model for the fDKA is that of a community-operated infrastructure service: IANA designates the domain name, and the IETF community determines the operational arrangements through the normal IETF process, similar to other infrastructure services under the .arpa top-level domain. The recommended designation is fdka.arpa. The corresponding DKA Locator Record would be:

Verification Methods Registry This document requests establishment of an IANA registry for DKA verification method identifiers. The initial contents of the registry are:

Identifier	Description	Reference
mailbox-control	Registrant demonstrated control of the mailbox for the submission email address	This document
dkim-validation	DKA-defined verification outcome for a registration reply that passes DKIM validation and the additional domain-consistency checks defined by this specification	This document

New entries may be added through the Specification Required policy.

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. 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] Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] This document is a specification of the basic protocol for Internet electronic mail transport. It consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a "mail submission" protocol for "split-UA" (User Agent) mail reading systems and mobile environments. [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] 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. Formally, any DNS Resource Record (RR) may occur under any domain name. However, some services use an operational convention for defining specific interpretations of an RRset by locating the records in a DNS branch under the parent domain to which the RRset actually applies. The top of this subordinate branch is defined by a naming convention that uses a reserved node name, which begins with the underscore character (e.g., "_name"). The underscored naming construct defines a semantic scope for DNS record types that are associated with the parent domain above the underscored branch. This specification explores the nature of this DNS usage and defines the "Underscored and Globally Scoped DNS Node Names" registry with IANA. The purpose of this registry is to avoid collisions resulting from the use of the same underscored name for different services. This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. Informative References 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. This document clarifies and updates the DNS-Based Authentication of Named Entities (DANE) TLSA specification (RFC 6698), based on subsequent implementation experience. It also contains guidance for implementers, operators, and protocol developers who want to use DANE records. OpenPGP is a message format for email (and file) encryption that lacks a standardized lookup mechanism to securely obtain OpenPGP public keys. DNS-Based Authentication of Named Entities (DANE) is a method for publishing public keys in DNS. This document specifies a DANE method for publishing and locating OpenPGP public keys in DNS for a specific email address using a new OPENPGPKEY DNS resource record. Security is provided via Secure DNS, however the OPENPGPKEY record is not a replacement for verification of authenticity via the "web of trust" or manual verification. The OPENPGPKEY record can be used to encrypt an email that would otherwise have to be sent unencrypted. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 4.0. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 5751. This document specifies the message formats used in OpenPGP. OpenPGP provides encryption with public key or symmetric cryptographic algorithms, digital signatures, compression, and key management. This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws. This document obsoletes RFCs 4880 ("OpenPGP Message Format"), 5581 ("The Camellia Cipher in OpenPGP"), and 6637 ("Elliptic Curve Cryptography (ECC) in OpenPGP").

Complete Example This appendix illustrates the full DKA discovery, registration, and lookup flow using a working deployment.

DNS Discovery A Requesting Client seeks the public key for alice@example.com. It queries DNS: The client parses the record and determines that the DKA for example.com is located at dka.example.com.

Key Registration Alice registers a public key with her domain's DKA:

1. Alice sends an email from alice@example.com to dka@dka.example.com.
2. The DKA responds with a verification email: ", "public_key": "", "selector": "", "metadata": {}} ]]>
3. Alice replies from alice@example.com with:
4. The DKA verifies mailbox control and applies the checks associated with dkim-validation, then stores the key.

Key Lookup --- Domain DKA The Requesting Client sends a lookup request: The DKA returns: Because the domain DKA returned a matching record, a conforming client does not query the fDKA for (alice@example.com, "default").

Key Lookup --- Fallback DKA A Gmail user, bob21@gmail.com, has registered a key with the fDKA at dka.fdka.arpa. A Requesting Client seeking bob21@gmail.com's key:

1. Queries _dka.gmail.com --- no DKA Locator Record found.
2. Since no domain DKA exists, queries the fDKA:
3. The fDKA returns:

This example demonstrates the fDKA's role as a bootstrap mechanism: a Gmail user participates in the framework without any action by Google. If Google later deploys a DKA for gmail.com, the domain DKA would take priority for any (identifier, selector) pairs it serves, while the fDKA would continue to serve pairs not present at Google's DKA.

Reference Implementation An open-source reference implementation of the DKA framework is available. The implementation serves as both a domain DKA and an fDKA, with the operational difference controlled by a configuration parameter specifying whether the DKA restricts registrations to a specific domain or accepts registrations from any domain.

Working Demonstration A working demonstration of the DKA framework, illustrating key registration, key lookup, and fDKA behavior, is available at:

• https://keymail1.com/demo