DKIM2 lets an organization that owns a signing domain take responsibility for a message by attaching a digital signature tied to that domain. The domain publishes a public key in DNS and messages are signed with the matching private key; verifiers check the signature by querying the signer's domain for that key. This document defines the DKIM2 DNS record format and how to locate the record.
Defines eqr-core-1, a narrow, deterministic conformance profile for Evidence Qualification Receipts. It covers strict JSON structure, SHA-256 digest encoding, UTC timestamps, evidence-reference integrity, requirement-state derivation, and three-valued PASS/FAIL/INDETERMINATE results, all checked by a closed algorithm. Conformance does not show that evidence is true, that a proposition is scientifically valid, that an issuer is trustworthy, or that an action is authorized. The goal is interoperable verification of receipt semantics.
The Zero Trust Intelligence Protocol (ZTIP) is a transport-independent protocol for governed AI agent transactions. It defines five immutable JSON envelope types and a transaction lifecycle. Policy authorizes each agent-initiated action before it runs, a hash over a canonical form protects integrity, and an authority independent of the actor verifies that the work completed. An actor's claim of success counts only as attestation, which never alone satisfies a required check. This revision clarifies what integrity verification does not prove and sets fail-closed rules for verifying multiple envelopes together. It describes ZTIP v1.0-draft, with schemas and a reference runtime in the project repository.
Proposes a companion format that links two fixed software-artifact commitments to attribution and revisioned claims. It defines the exact bytes to be signed, separate checks for trust and freshness, and procedures for making and verifying claims, with limits on operational state. Intended for software-provenance maintainers, release operators, and independent reviewers, it reuses existing IETF canonicalization and signature standards rather than a new primitive. It separates evidence from application control systems from evidence that the companion itself was deployed, and states that a complete operational profile, independently authenticated trust/freshness evidence, and a verified field deployment are still needed before it is implementable.
Argues that a verifier result shows what a check returned, not whether the check could have returned anything else: a check comparing too few fields, or whose rejecting input never occurred, yields the same accepting result as a working check, and a conformance matrix cannot tell them apart. It sets out two obligations: a check should be shown to have been exercised into its rejecting outcome, and a result claiming completeness must name the set of records it treats as whole and not rely only on an interested party. It defines no wire format, token, harness, or registry, but requires records able to express certain facts, leaving encoding to profiles.
RFC 9721 ties IP and MAC mobility sequence numbers together, which causes excessive control-plane churn when one IP moves among several IPs bound to a single MAC. This draft proposes separate sequence-number spaces for MAC-IP routes and MAC-only routes, reducing BGP updates from O(N) to O(1) when one IP moves among N IPs on a MAC. It stays fully compatible with RFC 9721 implementations and describes an upgrade path for deployments moving from RFC 7432 to IP mobility under RFC 9721 or this draft.
Certification Authorities may require a Certificate Signing Request to include extra verifiable information confirming policy compliance, for example proof that a private key is protected by a hardware security module and cannot be exported. Generating, sending, and verifying that information is called remote attestation. While standardization is ongoing, proprietary mechanisms have been used for years. This document defines ASN.1 structures that carry attestation data in PKCS#10 and CRMF requests, supporting both standard and proprietary attestation formats.
By its name, this draft probably concerns the deployment of enterprise machine-type communications (MTC), apparently under an effort abbreviated PLANTS. The official Abstract page returned no document on this run, so this description is written from the name and is approximate; it will be grounded on the next run.
Specifies nine post-quantum key exchange algorithms for TLS 1.3 based on HQC-KEM, the code-based KEM NIST selected for the forthcoming FIPS 207: three standalone HQC-KEM variants, two hybrids pairing HQC-KEM with X25519 or X448, two pairing it with ML-KEM, and two combining it with ML-KEM plus X25519 or X448. Because HQC-KEM rests on different hardness assumptions than lattice-based ML-KEM, these provide algorithmic diversity hedging against future lattice cryptanalysis or implementation weaknesses. They target TLS 1.3, DTLS 1.3, and QUIC, and the hybrids follow the general hybrid key exchange construction for TLS 1.3.
Extends JMAP so clients and servers can attach metadata to objects of existing JMAP data types. Each supported type gets two new properties, metadata (shared) and privateMetadata (per-user), both keyed by a namespace identifier. A namespace is either an IANA-registered name or a vendor's domain name, letting vendors extend the schema without prior coordination. Because the metadata is a property of the related object, clients use the existing /get, /set, /changes, and /query methods to read, change, and synchronize it.
An individual submission at a high revision (-21), suggesting a long-maintained specification; its subject ("aer1") is not determinable from the name alone. The official Abstract page returned no document on this run, so no grounded description is available; it will be grounded on the next run.
Addresses attestation freshness in certificate requests. When an end entity includes attestation statements in a CSR, it often needs a nonce from a Relying Party or Verifier to prove the Evidence is current. This draft specifies how an end entity requests that nonce from an RA/CA through certificate lifecycle protocols, defining message formats and protocol bindings for CMP, EST, and CMC, including optional type-specific information needed to produce fresh Evidence.
Introduces RepSec, a post-breach data neutralisation protocol. It aims to reduce the value of stolen or unauthorised data copies by making data usable only when the execution environment passes attestation and integrity checks. It works independently of perimeter and access-control models, seeking to limit exploitation, resale value, and operational impact without disrupting legitimate use.
Defines a lab benchmarking method for whether an AI agent's memory subsystem notices when its stored memory has been changed at the storage layer (alteration, deletion, reordering, replay, forgery). The subsystem should refuse or flag altered memory before use. The method has nine storage-level edits, three verdict classes, a read-time vs audit-time distinction, three control cases, and a scoring rule, following the style of RFC 2544 and RFC 8239. This revision adds a ninth edit (rolling the store back to an older genuine copy) and reports 31 result rows for released subsystems, 18 claiming tamper evidence, with a machine-readable record for recomputation.
Part of the DIEM family of drafts on digital emblems (see the DIEM ADEM core and DNS drafts in this digest). By its name this -00 revision probably describes the overall DIEM architecture that ties the ADEM components together. The official Abstract page returned no abstract on this run, so this description is written from the name and related drafts and is approximate; it will be grounded on the next run.
The ADEM Core Specification defines the message format and authorization model for digital, distinctive emblems. This document specifies how such emblems can be used to mark domain names and how they can be conveyed over the DNS.
During armed conflict, IHL-recognized emblems such as the red cross, red crescent, and red crystal mark physical assets so that, for example, military forces can recognize which assets have IHL protections. This draft defines a message format and authorization model for a digital version of these emblems, signalling that network-connected services carry those protections.
Describes how to measure performance in SRv6 networks using the Simple Two-Way Active Measurement Protocol (STAMP), with the optional extensions in RFC 8972 and the SR-specific extensions in RFC 9503. The measurements cover individual links and SRv6 paths, including SRv6 Policy segment lists, IGP best paths, and Flexible Algorithm paths, as well as Layer-3 and Layer-2 services carried over those paths.
Describes HMTP, a way to submit and transfer email over HTTPS. It keeps SMTP's core ideas (message format, envelope/content separation, delivery status notifications) and adds security and features SMTP offers only through extensions or not at all. Transport encryption is required, each transfer request is signed for the sending domain using DKIM-published keys, request identifiers make retries safe, and errors are reported per recipient with SMTP status mappings. Messages travel unchanged inside a JSON wrapper, large content can be referenced by URL with hash integrity checks, and endpoints are discovered via DNS and a well-known URI. It can fall back to SMTP, allowing gradual adoption.
OAuth 2.0 governs access, token constraints, and token lifecycle but has no common way to tie an approved piece of work to the credentials issued for it, including that work's bounds and end. This gap matters most when an AI agent acts for a user: the agent's authority should come from approval of a bounded task, stay within what was approved, and end when the task finishes or approval is withdrawn. The draft describes a withdrawal use case and proposes a framework of three objects (a bounded work proposal, the governing authorization created on approval, and approval evidence). It specifies no wire formats and aims to agree on the problem and conceptual model.
Extends RFC 9340 with quantum-native architectural tenets for designing and evolving the Quantum Internet, presented as practical guidelines for using quantum entanglement rather than dogma and linked to the principle of constant change from RFC 1958. It proposes an entanglement-packet-switching model, defines quantum packets, and separates the Quantum Data Plane from the Quantum Control Plane. It also introduces Quantum Internet Addressing as a complementary abstraction for control and coordination, and Generalized Quantum Forwarding covering quantum-packet processing and manipulation of entanglement resources.
Describes a method for rating a website's agent-readiness, meaning how well it serves AI agents and generative-search crawlers that work without a human reviewing pages. The method relies entirely on published standards and groups observable server behavior into four pillars (agent discoverability, semantic entity grounding, content efficiency and ingestion, and transport), each mapped to specific IETF RFCs and W3C specifications, combining per-pillar results into one reproducible 0-100 score. The scoring formula and weights are a measurement convention, not a standard; the method is diagnostic only and changes no protocol. A running reference implementation exists.
Explains that an OAuth scope written as an HTTPS URL can be fetched to get a JSON description of what the scope is. That description is informational only and does not alter what the scope authorizes. Fetching follows the pattern and security rules from the OAuth Client ID Metadata Document.
Defines a deterministic function called MUSUBI settlement. It takes a contract signed by two parties, signed records of an agent's actions under that contract, and Bitcoin block header data, then checks whether the recorded actions stayed within the contract's grant. Anyone with the same inputs can recompute the result without trusting whoever produced it. The document specifies one part, settle core v0, in enough detail for a second implementation, and stresses that settlement is not runtime enforcement and not a judgement of liability.
DNSSEC validators rebuild the original owner name of a signed RRset from the RRSIG Labels field. If that rebuilt name falls outside the signing zone, a valid signature could be wrongly treated as authorizing wildcard data in another zone, and aggressive use of validated caches can spread the problem to other names. This draft updates RFC 4035 to require that the rebuilt owner stay within the signer's zone, and updates RFC 8198 so cached wildcard data keeps that authorization. It does not change wildcard matching, wildcard synthesis, or DNS message formats.
Covers AI agents that act for people or organizations and encounter credential offers or proof requests, such as a website asking for an attribute before continuing. Because agents can be steered by content they read, the draft holds they should not hold credentials or keys or decide what gets disclosed. It proposes the Agent-to-Wallet Protocol (A2WP), in which the agent forwards the request unaltered to a wallet; the wallet decides whether to proceed, asks the user for approval when needed, and completes issuance or presentation with the issuer or verifier. The agent gets back the outcome and any continuation, while credentials, presentations, and keys never leave the wallet.
The JMAP base protocol (RFC 8620) can upload and download arbitrary binary data, called blobs, which other JMAP extensions can use. This document adds a method that presents blobs as a filesystem, with the kinds of metadata that other remote filesystem protocols provide.
Related to the DAWN (Discovery of Agents With Names) effort. By its name this draft probably specifies infrastructure-assisted discovery of named agents. The official Abstract page was not reachable on this run, so this description is written from the name and is approximate; it will be grounded on the next run.
Defines a record format for AI agent authorization decisions and the effects that followed them. Each record is one in-toto predicate type signed inside a DSSE envelope, pairing the decision with the observed effect and a derived agreement value, noting whether the decision point could evaluate the request and how fresh each relied-upon input was. A canonicalization contract lets a party that trusts neither the agent nor its operator recompute the record's consistency from its bytes. It carries the seven minimum audit fields of the WIMSE AI Identity Management System framework, is meant as a data model for the proposed AUDIT working group, and defines no policy.
Describes methods that use ASPA (Autonomous System Provider Authorization) objects in the RPKI to check the BGP AS_PATH attribute of advertised routes. The verification strengthens routing security by detecting and mitigating route leaks and AS_PATH manipulations.
Automated agents increasingly act for companies, such as requesting quotes, booking appointments, and placing orders. Tools like Web Bot Auth can confirm a request came from a key holder but do not show which company is behind the agent or what it may do. This draft proposes a small credential file on a company's own domain, a DNS TXT record linking the file to that domain, and a registry that checks both and returns a signed answer. The credential is the company's own declaration of which agents act for it and their permitted and prohibited actions, making no claims about creditworthiness, trustworthiness, or quality.
Segment Routing steers packets through a network using source routing and applies to both MPLS (SR-MPLS) and IPv6 (SRv6) data planes. This document specifies procedures for performance measurement in SR-MPLS networks using STAMP (RFC 8762), with optional extensions from RFC 8972 and SR-specific extensions from RFC 9503. The procedures measure SR-MPLS paths, including SR Policy segment lists, IGP best paths, and Flex-Algo paths, as well as Layer-3 and Layer-2 services carried over those paths.
Defines metadata about a workload's identity, such as group membership, roles, and entitlements, for use in auditing, authorization, and accounting. The metadata can be delivered inside JWT-based Workload Identity Credentials or retrieved from an authenticated endpoint that serves workloads authenticated with JWT or X.509 credentials and limits what it reveals by the caller's authorization. An optional JWT claim or X.509 extension can point to the endpoint. The draft argues a workload's identifier should be kept separate from its metadata, distinguishing stable attributes and durable principal associations from per-request grants, and covers services, batch and CI jobs, serverless functions, and AI agents.
Defines a YANG data model for configuring and managing BGP. The model covers protocol, policy, and operational aspects such as the RIB, and is based on operational requirements from data center, carrier, and content provider networks.
Segment Routing over IPv6 (SRv6) applies Segment Routing to the IPv6 data plane, using IPv6 addresses as segment identifiers. This document covers the threats to SRv6 networks and how to mitigate them. It does not define any new security protocols or extensions.
Defines a protocol for proxying Ethernet frames over HTTP, analogous to HTTP IP proxying but operating at Layer 2. It lets an HTTP client open a tunnel through an HTTP server connected to a physical or virtual Ethernet segment, exchanging Layer 2 frames through it. The protocol does not guarantee in-order frame delivery.
Describes PQuAKE, a proposed mutual-authentication construction using an ephemeral KEM exchange, encapsulations to certified long-term KEM keys, transcript binding, and explicit key confirmation. It targets constrained links where avoiding online post-quantum handshake signatures could reduce communication or computation cost, and offers an optional pre-shared secret to protect encrypted credentials against active outsiders. It seeks CFRG review of its security and applicability, with a possible Informational RFC if review supports it, and notes it does not represent CFRG consensus or an IETF working group recommendation.
States that the AERO and OMNI Interface functional specifications are mature enough to advance toward RFC publication, and that this first amendment documents updates to the base specifications, with more amendments to follow if needed.
Defines the OBJECTID+ extension for IMAP, replacing RFC 8474. It bundles object identifiers into compound key-value responses and adds an ACCOUNTID for account-level context. It adds OBJECTID response codes for RENAME and lets clients select mailboxes by identifier through SELECT and EXAMINE. The extension activates implicitly when a client uses one of its features, so clients supporting only RFC 8474 keep working. It also updates RFC 9698: when JMAPACCESS is advertised alongside OBJECTID+, ACCOUNTID values must match JMAP accountIds.
The JMAP base protocol (RFC 8620) synchronizes current object state between clients and servers. This extension adds the ability to retrieve historical versions of objects, including objects that have been destroyed, by extending the standard Foo/get method.
Introduces Entity Profiles, a way to classify OAuth 2.0 clients and token subjects by their operational context. These profiles describe the client that starts an OAuth flow and the subject represented in a token. The draft defines new JWT claims and metadata for use in access tokens, ID tokens, JWT authorization grant assertions, and transaction tokens, and covers token introspection, dynamic client registration, and Authorization Server metadata. It also provides vocabulary for classifying acting entities in delegation chains.
This Best Current Practice document describes DNS Security Extensions (DNSSEC), specified in RFCs 4033, 4034, and 4035 along with several related RFCs. It gathers these RFCs in one place to help readers understand DNSSEC, without updating them, and states that DNSSEC is the best current practice for origin authentication of DNS data. It serves as a single reference for other documents that cite DNSSEC and obsoletes RFC 9364.
Defines a COSE header parameter that tells the receiver to use a hash of an authentication credential, instead of the credential itself, in protocol computations. It targets the Lightweight Authenticated Key Exchange (LAKE) protocol in RFC 9528. Because credentials no longer need to be sent, protocol messages get smaller, which helps performance on constrained networks.
By its name, this draft likely defines an attestation/trust-transfer protocol (ATTP) applied to industrial control systems. The official Abstract page was not reachable on this run, so this description is written from the name and is approximate; it will be grounded on the next run.
Updates the registration procedures for provisional URI schemes to address issues that did not exist when RFC 7595 was written.
Extends In Situ Operations, Administration, and Maintenance (IOAM) so that IOAM nodes can compute on-path delay samples, which underpin on-path delay statistics that can be exported using the IPFIX Information Elements in RFC 9951. It defines an On-Path Delay IOAM data field and extends the IOAM Direct Export (DEX) Option-Type with a timestamp reference inserted by the encapsulating node, letting transit and decapsulating nodes compute and locally aggregate on-path delay. Results can be exposed through mechanisms such as IPFIX export or the YANG on-path telemetry data model.
By its name, this draft is probably a YANG data model for a green (energy-efficient) network controller, aligned with the IETF GREEN effort on energy-efficient networking. The official Abstract page had no abstract on this run, so this description is written from the name and is approximate; it will be grounded on the next run.
Proposes a post-quantum cryptography strategy for DNSSEC using two algorithm types: conservatively designed algorithms that should rarely need replacing, which can run in a mode that reduces the impact of large signatures; and low-impact algorithms that slot in like today's signature schemes. Together they aim to keep everyday performance strong while providing a robust fallback. The document also covers recommended testing and deployment steps and the operational issues of adopting PQC for DNSSEC.
STAMP and its optional extensions support edge-to-edge active measurements, and IOAM data fields can record hop-by-hop and end-to-end operational and telemetry information. This document extends STAMP so that it reflects MPLS Network Action Sub-Stacks and Post-Stack MPLS Headers, letting active measurement packets gather that information, for example through IOAM data fields.
Describes a YANG data model for managing the lifecycle of network incidents. It standardizes how incidents are reported, diagnosed, and resolved, aiming to reduce troubleshooting tickets and support network service health and probable root cause analysis.
Human-cyber-physical systems combine people, computing and communication services, and networked physical processes, and their network data is heterogeneous and high-dimensional. An abnormal condition may show up in one entity's attributes, in an interaction between entities, or only when evidence from several domains is considered together. This draft presents an initial framework for anomaly detection in these environments, covering collecting observations, building entity and relation context, analyzing high-dimensional data, and reporting results, plus a small conceptual information model so each anomaly result keeps its observation scope, feature context, and score meaning.
HTTP's built-in CONNECT method has long supported TCP tunneling but has notable drawbacks because it provides no well-defined HTTP origin or path. This draft defines an alternative proxy configuration for TCP connections that, like CONNECT-UDP and CONNECT-IP, identifies the proxy service with a URI Template.
Updates RFC 9678 (EAP-AKA' FS) so that the Transient EAP Keys used to protect EAP packets gain forward secrecy. Reauthentication runs that follow one full authentication then cannot be linked to each other, improving end-user privacy. The update also applies to successors of RFC 9678 that use post-quantum or hybrid key encapsulation mechanisms.
Describes vaara.receipt/v1, a signed record that binds a decision about an autonomous action to the evidence the decision was based on, optionally with external timestamp anchors. Third parties can recompute its digests and, for public-key signatures, verify it without access to the issuer, because it uses the JSON Canonicalization Scheme. A decision and the execution receipt that answers it form a verifiable pair through a back link. Trust does not depend on a single root, so it can be verified with or without a hardware TEE and re-expressed as an IETF RATS Entity Attestation Result. Downstream specifications can add their own evidence schemas without redefining the envelope.
Defines a sustainability-data well-known URI that a web origin uses to publish a JSON declaration of energy use, carbon footprint, and related sustainability metrics for a target (the organization behind the origin, the origin itself, a part of it, or a service, device, or product) over different reporting periods. Each declaration links to its methodology and may include a signature, reference upstream providers' declarations, and link to third-party attestations. The metrics are the publisher's own claims, not verified facts. The document registers the URI and the media type application/sustainability-data+json.
Profiles draft-farley-acta-signed-receipts, a signed decision receipt format for machine-to-machine access control, for use as evidence in card-scheme payment disputes. It defines how a receipt is populated for disputes and adds four evidence layers bound to it: card-scheme dispute-evidence categories (Visa Compelling Evidence 3.0 and Mastercard First-Party Trust), agent-specific anchors with no scheme-defined field, a settlement anchor recording the money that actually moved, and an evidence-custody wrapper aligned with U.S. Federal Rules of Evidence 901 and 902. It describes itself as a vendor profile of one implementation, not a new protocol, claiming no IETF consensus.
IDR working group draft. By its name it likely defines BGP signaling of iFIT (in-situ Flow Information Telemetry) capabilities so routers can advertise and learn iFIT support. The official Abstract page was not reachable on this run, so this description is written from the name and is approximate; it will be grounded on the next run.
IDR working group draft. By its name it likely defines carrying iFIT (in-situ Flow Information Telemetry) information in BGP SR Policy. The official Abstract page was not reachable on this run, so this description is written from the name and is approximate; it will be grounded on the next run.
STAMP (RFC 8762) with the optional extensions in RFC 8972 can be used for active measurement. Bit errors, often caused by factors such as poor fiber quality, can slip past CRC and FEC checks and remain as residual bit errors. This document extends the RFC 8972 extensions so that the residual bit error rate can be measured within the Extra Padding TLV of STAMP test packets.
Describes using QUIC as a secure transport for NETCONF, the network configuration protocol. QUIC streams can avoid some TCP head-of-line blocking, and the security is comparable to NETCONF over TLS. The draft also defines a YANG module that extends the ietf-netconf-client and ietf-netconf-server modules.
Proposes an architecture for AI agents and autonomous systems that separates the ability to generate or request an action from the authority to make it take effect. A proposed operation stays non-effective until a protected enforcement component validates the required authority, purpose, destination, scope, runtime context, policy version, freshness, and revocation status; validation evidence is committed first, and a scoped, non-bearer capability is then released. A separate Finality Sink verifies that capability against the actual operation immediately before the consequential effect. It covers sandboxing, egress control, credential brokering, delegation, self-modification, hardware-assisted enforcement, and fail-closed behavior, as mechanisms for examination rather than a complete protocol.
Specifies a minimal JSON evidence-record profile for checking artifact digests while separating integrity verification from scientific assessment. It defines an interoperable record structure, a validation algorithm, and negative test cases, and does not claim that an integrity-checked scientific claim is true.
Once all of a dual-stack host's applications support IPv6, IPv4 is no longer needed. Withdrawing DHCPv4 addresses in that case can leave the host sending repeated, unanswered DHCPv4 requests, adding unnecessary broadcast traffic to the link. This draft proposes continuing to assign the host an IPv4 address through DHCPv4 while stopping it from using that address for any communication beyond the host itself, and describes a DHCPv4 method for doing so.
Agent auditing draws on evidence from users, agents, tools, services, and policy components across several administrative domains; the evidence needed depends on the question asked, and showing that evidence checks out does not show it is relevant or sufficient. This draft offers a representation-independent model for stating an audit task, listing alternative evidence requirements, describing what sources are expected to produce, and explaining the basis for a result. It distinguishes verifying evidence from evaluating the task, missing evidence from a recorded negative event, and the validity of individual records from their sufficiency across domains. It defines no record formats, verification mechanisms, authorization models, completeness controls, storage protocols, or policy.
Defines a profile for control commands that a software agent sends to operational-technology or industrial control systems. An enforcement point refuses such a command unless it carries a verifiable statement of which agent issued it, which human principal the agent acts for, whether that principal authorized this specific action on this specific asset, whether a named human signed off where the risk class requires it, and an append-only record for later attribution. It adds no new cryptography, combining existing primitives into a Command Authority Envelope. It fails closed on authority but never on safety and MUST NOT be placed in the trip path of a safety function, mapping to IEC 62443 and NERC CIP requirements.
Describes PRF (Prf is Reversed Frp), a lightweight TCP relay protocol using length-prefixed binary messages. It tunnels TCP connections between peers through a public middle relay, originally built so Minecraft multiplayer sessions could work behind NAT or firewalls. The protocol defines three roles (Server, Client, and Middle) and four message types for registering rooms, making connection requests, handing off workers, and parsing direct Minecraft client handshakes.
The BGP Monitoring Protocol (BMP) tracks BGP operational status, including peer session changes and route updates, so operators do not have to query devices manually. This draft extends the BMP Initiation Message so a monitoring station can learn which optional BGP capabilities a device supports, which ones are enabled, and what its default configuration parameters are.
DNSSEC validators rebuild the original owner name of a signed RRset from the RRSIG Labels field. If that rebuilt name falls outside the signing zone, a valid signature could be wrongly treated as authorizing wildcard data in another zone, and aggressive use of validated caches can spread the problem to other names. This draft updates RFC 4035 to require that the rebuilt owner stay within the signer's zone, and updates RFC 8198 so cached wildcard data keeps that authorization. It does not change wildcard matching, wildcard synthesis, or DNS message formats.