IETF Internet-Drafts & RFCs — Daily Digest

Defines an enforcement boundary at which an operation produced by an AI system is checked against the effect it will actually cause, rather than the effect requested or approved upstream. The operation carries no external consequence until that verification succeeds. The mechanism is a safety interlock: it does not restrict what the system may compute, only whether a specific computed operation may take effect. It is complementary to alignment, sandboxing, monitoring and interpretability, addressing the separate question of what stops a produced operation from becoming effective. Core invariant: computation is not authority.

Specifies the Canonical Payload Binding (CPB) construction that systems anchoring records to a SCITT Transparency Service repeatedly need: a canonical form of structured content, a content-addressed identifier derived from it, binding to a SCITT Signed Statement and Receipt, and references citing external artifacts by digest. A payload profile declares its canonicalization algorithm and exclusion set to obtain a reproducible derived identifier. A CPB Signed Statement carries either complete content per RFC 9943 or a digest via the COSE Hash Envelope (RFC 9995). It also defines an abstract typed digest reference model and an optional 'cpb-refs' header, with an IANA registry for canonicalization algorithm identifiers.

Identifies observability gaps that keep network operators and security teams from determining the post-quantum cryptography (PQC) readiness of networked environments. PQC readiness requires knowing which cryptographic algorithms are in use, which are vulnerable to quantum attack, and which have been or are being migrated to NIST-approved PQC algorithms. The document argues that current network protocols and management frameworks do not provide enough visibility to answer those questions at scale, motivating new telemetry and inventory mechanisms.

Describes the Authorization Posture Mechanism (APM), by which an OAuth 2.0 authorization server (or a resource server acting on its behalf) re-evaluates the mutual consistency of three bound factors -- client certificate, access token and device posture -- on a per-request basis for privileged operations, rather than only at session establishment. When re-evaluated posture degrades relative to the posture under which the token was issued, APM defines deterministic, least-privilege Graduated Outcomes such as scope reduction and method restriction, instead of a binary allow/deny.

Defines an ACME profile extension letting servers and clients express per-account and per-order post-quantum cryptographic (PQC) posture. It introduces metadata objects and a server-side adequacy scoring mechanism that determines whether a given order meets an account's declared PQC readiness threshold. Discoverable capability metadata and per-order policy directives are added without modifying core ACME operations, and multi-tenant servers must implement tenant-isolation controls to prevent cross-account posture leakage. It operates at the policy layer above algorithm negotiation, covering posture scoring, adequacy thresholds, hybrid policy bits, rotation epoch anchoring and tenant isolation.

Defines the X.509 Post-Quantum Rotation Envelope extension, a CA-side commitment mechanism that lets an issuing CA publish, sign and bind to its certificates a machine-verifiable guarantee of PQ or PQ/T hybrid issuance continuity across the CA's own key-rotation boundaries. The extension carries a SHA-384 hash of a signed JSON manifest hosted at a stable /.well-known URI enumerating the algorithms the CA commits to keep issuing, successor-CA public-key hashes and the OCSP/CRL endpoints that stay authoritative. Relying parties can verify that the CA's published continuity posture matches what was bound at issuance, detecting silent degradation, unannounced CA replacement or rollback of PQ-capable commitments. It complements subject-side commitments such as I-D.reddy-lamps-x509-pq-commit.

Specifies requirements for post-quantum cryptography (PQC) certificate rotation in multi-tenant public key infrastructure (PKI) environments. It observes that multi-tenant PKI deployments face coordination challenges during PQC migration that single-tenant deployments do not, because they must issue and manage certificates across multiple distinct tenant organizations. The document frames the isolation, sequencing and posture requirements needed to rotate tenants to PQC algorithms without cross-tenant interference.

Defines the use of Hybrid Public Key Encryption (HPKE) with CBOR Object Signing and Encryption (COSE). HPKE offers public-key encryption of arbitrary-sized plaintexts for a recipient public key, built from an asymmetric key encapsulation mechanism (KEM), a key derivation function (KDF) and an AEAD algorithm. This document specifies how HPKE is carried in COSE, with authentication provided by COSE-native security mechanisms or by the pre-shared-key authenticated variant of HPKE.

Updates DMARC (RFC 9989) for DKIM2. Because DKIM2 verification supports MTA relay forwarding with message modifications through multiple MTAs, this document updates DMARC to cover those scenarios. It generalizes and separates enforcement policy from constraint-validation policies, where DMARC otherwise ties an RFC5322 From alignment constraint to an enforcement policy on failure. It also provides a mechanism for MTAs to declare DKIM2 support through the DMARC DNS policy record, helping protect DKIM2 from downgrade attacks.

Specifies the PROBE network diagnostic tool. Like PING, PROBE queries the status of a probed interface, but it does not require bidirectional connectivity between the probing and probed interfaces; instead it needs bidirectional connectivity between the probing interface and a proxy interface. The proxy can be on the same node as the probed interface or on a directly connected node. This revision updates RFC 4884 and obsoletes RFC 8335.

Part of the Web4 series. Distinguishes claims, evidence, assessments, assertions, verification events, challenges, supersession, suspension, expiration, revocation and receipts, providing a common vocabulary and model for these lifecycle states -- without standardizing the private scoring internals that a verifier may use. The goal is interoperable handling of verification outcomes across federated systems.

Part of the Web4 series. Defines signed, bounded, time-limited and revocable authority mandates for agents and nodes, and links governed actions to their authority. The construct lets a principal delegate a scoped mandate that can be checked and revoked, binding each governed action back to the delegation that permitted it.

Part of the Web4 series. Defines durable, cryptographically verifiable receipts for assessment, authority, policy, claim and node-lifecycle events, without requiring publication of the protected evidence itself. The receipts provide tamper-evident proof that an event occurred while keeping sensitive underlying evidence confidential.

Part of the Web4 series. Defines machine-readable advertisements for federation policies, covering authority, versions, profiles, evidence formats, retention, challenges, appeals, revocation, disclosure, jurisdiction, proof and status. The advertisements let federated participants discover and align on each other's operating policies in a structured, verifiable way.

Starts from the assumption that an attacker already fully controls the AI workload -- its credentials, connectors, context window and output path -- and asks what is still denied at that moment. It specifies Execution-Consequence Decoupling enforced by three pillars: Decomposition of Authority (technical non-joinability across identity, content, relationship-mapping and cryptographic domains), mandatory mediation of every consequence-bearing candidate output, and technical non-completability so computation can finish without completing an external consequence. Reconstruction is governed by a non-bearer authorization object bound to attested execution context, and outputs are sealed, re-verified and committed to a validation receipt before a release capability is issued. It is the architecture-and-rationale companion to draft-das-enterprise-ai-output-finality.

Defines the EMILIA Protocol (EP) authorization receipt, an evidence artifact binding an enrolled approver key to one canonical action before execution. An approver-held key signs an Authorization Context containing the action hash, policy reference, shared authorization instance, per-signoff nonce, audience and validity window; a Trust Receipt carries the signed contexts, terminal consumption record and Merkle inclusion material for offline verification. The receipt is evidence, not authorization: offline verification does not establish revocation status, global non-replay, comprehension, legality, safety or execution. This revision defines the closed EP-AUTHORIZATION-BUNDLE-v1 pre-execution profile and its verification algorithm.

Addresses the presentation attack in human-authorization receipts: a receipt proves an enrolled key signed a digest committing to an exact action, but not that the signing surface displayed that action honestly. A benign summary shown over a different committed action yields laundered authority -- cryptographically valid, semantically false. The draft narrows the gap with two additive, offline-checkable pieces: a deterministic renderer (a pure function from the canonical action to a byte-identical human-readable rendering that a verifier re-derives) and a display attestation (a signed client claim binding what it showed to what it committed). Neither eliminates the attack, but together they make the residual risk explicit rather than hidden.

Presents technical detail on CVE-2026-33697, EUVD-2026-16488 and several GitHub Security Advisories to demonstrate how intra-handshake (early) attestation fails in practice, even without physical access. Because continuous attestation is generally required anyway, the work concludes that intra-handshake attestation adds unnecessary complexity. Results are backed by formal analysis using ProVerif; fourteen CVEs and GHSAs are cited with CVSS scores from 6.3 to 10.0 against implementations including Edgeless Systems Contrast and Meta's AI, with artifacts to be shared for reproducibility.

Registers additional syntax definitions for use in the Lightweight Directory Access Protocol (LDAP) and the X.500 directory services series. The registrations cover widely used datatypes and syntaxes, filling gaps so that these values can be represented and interoperated consistently across LDAP and X.500 directories.

Describes performance-measurement procedures for SRv6 networks using the Simple Two-Way Active Measurement Protocol (STAMP, RFC 8762) with its optional extensions (RFC 8972, RFC 9503). Segment Routing steers packets by source routing over both MPLS and IPv6 data planes; this document targets the SRv6 data plane. The procedures apply to links and SRv6 paths -- including segment lists of SRv6 Policies, SRv6 IGP best paths and Flex-Algo paths -- as well as Layer-3 and Layer-2 services carried over those paths.

Specifies an architectural framework for high-risk, multi-system enterprise and public-sector AI deployments, addressing the gap where traditional access controls cannot prevent unauthorized joining of separately accessible information into strategic intelligence, nor prevent release of reconstructed meaning. Key mechanisms are technical non-joinability (identity, content and relationship-mapping held in independently controlled vaults, so access to data is not authority to form every relationship) and technical non-completability (computation is not authority to release, requiring session-bound reconstruction authorization objects and output release boundaries). It enables incremental deployment through protected gateways without replacing existing databases, models or applications.

Describes performance-measurement procedures for SR-MPLS networks using STAMP (RFC 8762) with its optional extensions (RFC 8972, RFC 9503). Segment Routing steers packets by source routing over both MPLS and IPv6 data planes; this document targets the SR-MPLS data plane. The procedures apply to SR-MPLS paths -- including segment lists of SR-MPLS Policies, SR-MPLS IGP best paths and Flex-Algo paths -- as well as Layer-3 and Layer-2 services carried over those paths.

Part of the Web4 series. Defines an implementation-neutral envelope for externally presented assessment results, including subject, issuer, policy, result, validity, evidence commitments, proof and current status, while the protected assessment methods remain confidential. The envelope lets an assessor publish a verifiable outcome that others can consume without exposing how the assessment was computed.

Addresses a governance gap where systems grant data access for one stated purpose but routinely permit consumption for a different purpose, because nothing in the protocol can refuse unauthorized reuse or record actual authorizations. Current controls rely on self-asserted purpose strings that express intent rather than proof of authority, and fail when requesters misrepresent their use. The proposed architecture makes undeclared or purpose-switched use technically detectable and refusable at point-of-use, producing verifiable evidence of authorized actions for liability determinations, at the cost of bounded evaluation latency. A runnable reference implementation accompanies the document.

A test document submitted only to exercise the asynchronous submission API endpoint. It carries no protocol content; its abstract states plainly that it exists to test the async API submission path.

The Virtualized Conversations (vCon) format provides a structured way to store recordings of conversations -- phone calls, email threads, multi-party chats -- along with metadata such as transcripts and mid-call events. Its structure suits two-party and basic multiparty phone calls, but there is a need for vCon to also record AI agent conversations, which are just another conversation type. This document proposes changes to the vCon object model to make it a better fit for AI agent conversations and more complex conferencing use cases.

Defines a data structure that can be appended to selected ICMP messages to gain visibility into environmental information on the Internet, providing per-hop (per network node) power metrics and other present or future environmental metrics. This supports an objective from the IAB E-Impact workshop report. The techniques are useful both transactionally (a user-issued traceroute or ping) and in scheduled automated settings, where they can run periodically in a mesh across an administrative domain to map environmental information.

Describes an architecture using Remote Attestation to provide Attesters with identity documents (keys or credentials) to authenticate to a large class of RATS-Unaware Relying Parties (RUPs) -- deployed services that predate remote attestation and are hard to change. It is intended to work with common credential-acquisition protocols such as EST, SPIFFE/SPIRE and ACMEv2. A separate goal is to encapsulate the Attester-side complexity of attestation and credential acquisition (like Envoy does), abstracting away which protocols and mechanisms are used and whether the RATS Passport or Background Check model applies.

Specifies Virtual eXtensible Local Area Network (VXLAN), an overlay for virtualized data centers accommodating multiple tenants, usable in cloud-provider and enterprise data-center networks. This document obsoletes RFC 7348 -- which documented the deployed VXLAN protocol -- and moves the specification to the IETF document stream, allowing extensions that add to the VXLAN header and register them with IANA. The format and processing described remain fully compatible with RFC 7348.

A product of the Crypto Forum Research Group (CFRG) that lists additions to RFC 8017 to increase the security of RSA implementations. It provides guidance for implementers on protecting against side-channel attacks, recommends against the RSAES-PKCS1-v1_5 encryption scheme, and offers an alternative depadding algorithm that protects against side-channel attacks arising from users of vulnerable APIs.

Specifies how the post-quantum signature scheme ML-DSA (FIPS 204) is used for authentication in TLS 1.3. It is a concise profile defining the code points and usage needed to authenticate TLS 1.3 handshakes with ML-DSA signatures.

Network platforms use telemetry such as YANG-Push to continuously stream counters and state; this document describes the metadata that ensures collected data can be interpreted correctly. It specifies the Data Manifest, composed of two YANG modules (the normative Platform Manifest and the non-normative Data Collection Manifest), specified at the network level (e.g. controllers) to span several platforms. The manifest must be streamed and stored alongside the data so it stays fully exploitable by data scientists and tools. It also augments the YANG-Push model to include the actual collection period when it differs from the configured one.

The Robots Exclusion Protocol lets origins ask automated clients to avoid certain paths but cannot express who is asking, purposes, terms or pricing, and lacks server-side enforcement. This document defines terms.txt, a well-known file stating per-path and per-purpose access policies (allowed, charged or denied) with use levels, pricing and delegation requirements. It also specifies the HTTP exchange that enforces these terms: requests signed with Web Bot Auth carrying signed intent declarations, delegation tokens and payment vouchers bound to authenticated identifiers; payment negotiation via Problem Details; and origin-signed receipts. It delineates which properties are enforced pre-delivery, which are audit-only, and which remain contractual.

Specifies the Mercurius Window System (MWS), a zero-trust, network-native window system for contemporary desktops that combines persistent, detachable graphical sessions with network transparency and works on a workstation without network connectivity. The session model lets users start or resume a detached session at the workstation itself or from another device across the network. MWS complements local display systems such as Wayland: applications and their state stay on the workstation while a Portal provides display and input. The document specifies the session, window and communication behaviour needed for independent implementations to interoperate.

Establishes requirements for retrospective verification of agent actions after interactions conclude, noting that evidence an agent was authorized to act does not establish that the authorization was enforced, that the action executed, or that the intended effect occurred -- these are distinct transitions. It addresses binding material actions and governing conditions at decision time, identifying the specific policy revisions in force, preventing later substitution, and preserving enough information for independent evaluation when original participants, sessions, credentials or keys are unavailable. It specifies no evidence format, token system, delegation protocol, audit framework, registry or transparency service.

The DANE TLSA protocol describes how to publish TLS server certificates or public keys in the DNS. This document updates RFC 6698 and RFC 7671 to describe how to use the TLSA record to publish client certificates or public keys, along with the rules and considerations for using them with TLS. It also defines a new TLS extension, DANE Client Identity, to convey the client's domain-name identity to the server.

AI agents consume IETF specifications to generate and operate implementations. This document defines an 'Agent Considerations' subsection within the Operations and Management Considerations section described in RFC 5706 and its revision. It provides guidance on schemas, examples, capability descriptions and verification, with cross-references to agent-specific security and privacy analysis, so that specifications are more readily and reliably implemented by AI agents.

Defines terminology for expressions such as 'IPv6-Only' and 'IPv6-Mostly' to avoid confusion when they are used in IETF and other documents. The goal is that a reference to 'IPv6-Only' describes the actual functionality being used in a given scope, rather than the installed protocol support, giving authors and operators consistent, unambiguous language.

Defines an authority token profile for validating the JWTClaimConstraints and EnhancedJWTClaimConstraints certificate extensions within the ACME protocol. Based on the Authority Token framework, it establishes the specific ACME identifier type, challenge mechanism and token format needed to authorize a client to request a certificate containing these constraints.

The BGP Monitoring Protocol (BMP) provides periodic statistics snapshots, but snapshot values may hide variations that occurred between reporting intervals. This document defines a Statistics Information TLV that conveys additional information about BMP gauge-type statistics during the reporting period -- reporting minimum and maximum values observed (with timestamps) plus measures such as average, percentiles or snapshot values. This lets BMP collectors understand the dynamics of monitored statistics even when the reported snapshot values appear constant.

Defines IGP capability advertisements for measurement-group membership for active measurement protocols such as TWAMP and STAMP. An IS-IS capability sub-TLV and an OSPF Router Information LSA TLV (for OSPFv2 and OSPFv3) let IGP routers discover others participating in different measurement groups, enabling automatic discovery of measurement endpoints across the routing domain. A Group ID identifies membership, and the same interface address may serve multiple groups. A BGP-LS node attribute distributes measurement-group membership beyond a single IGP domain.

Publishers increasingly serve a curated plain-text summary of an origin for consumption by large language models and their crawlers, most visibly as 'llms.txt', but the practice has no specification, media type or discovery mechanism. This document specifies discovery and retrieval for publisher-curated context files: the well-known URI 'llm-context', a matching link relation, and a robots-exclusion extension record, so a publisher can advertise a context file by three independent paths and a consumer can find it without guessing. It defines a two-tier index/detail arrangement with conditional-request and size requirements, and reports an operational deployment where twenty crawlers issued 44,005 requests over fifteen days without once retrieving the served context file.

Describes JOSE and COSE serializations for PQ/T hybrid composite signatures. The composite algorithms combine ML-DSA as the post-quantum component with either ECDSA or EdDSA as the traditional component, so a single signature provides both classical and post-quantum assurance within JSON and CBOR object-signing formats.

In-situ OAM (IOAM, RFC 9197) collects operational and telemetry information in the packet as it traverses a path, and IOAM Direct Export (IOAM-DEX, RFC 9326) triggers direct export or local aggregation without inserting data into active packets. MPLS Network Action (MNA) mechanisms indicate actions to perform on label-switched paths, MPLS packets and the node itself, and transport the data those actions need. This document specifies how MNA collects and transports operational state and telemetry using both IOAM-Data-Fields and IOAM-DEX.

Defines a profile for carrying pre-run evaluation criteria as a SCITT Signed Statement payload using the architecture of RFC 9943. It specifies the payload media type, the selection of the Issuer and Subject CWT claims, the encoding of hash-only statements for criteria that must remain confidential, a sequencing requirement that makes amendment order verifiable, and the semantics of amendment itself. It defines no new transparency architecture; it describes how an existing artefact type is carried by the one RFC 9943 already defines.

Specifies a YANG data model that extends the network topology model (RFC 8345) to map network topologies with inventories. It introduces the 'inventory-topology' network type and augmentations for physical entity mappings and capabilities, which any overlay network topology can use for service-provisioning validation, network maintenance and capacity planning. The model links topological elements to the underlying physical inventory.

Specifies the Human Delegation Provenance Protocol (HDP) v0.1, a lightweight token-based protocol that captures, structures, signs and verifies human delegation context in agentic AI systems. An HDP token binds a human authorization event to a session and records each agent's delegation action as a signed hop in an append-only chain, so any participant can verify the full provenance record offline using only the issuer's Ed25519 public key and the current session identifier -- no registry lookup, network call or third-party trust anchor. HDP is not an authorization protocol: a token confers no authority; it is a tamper-evident record of who authorized a task and what each agent declared it did, complementing capability formats such as UCAN and ZCAP-LD.

The SCITT architecture lets distinct Issuers agree on a common CWT Subject claim (sub). This document specifies a profile for independently deriving that claim from shared, application-defined Subject semantics without a shared assigning authority. An application maps its Subject description to a structured Value; the profile defines the derivation domain, deterministic binding encoding, SHA-256 construction, text syntax and candidate-to-claim comparison, with optional JSON and CBOR codecs to exchange admitted Values. SCITT provides the signed binding and transparency evidence while the construction derives sub from the complete mapped Value.

Specifies the design for inter-domain multicast overlays using the Locator/ID Separation Protocol (LISP) architecture and protocols, including how LISP multicast overlays operate over both multicast and unicast underlays. A signal-based approach using PIM programs LISP encapsulators with a replication list in a locator-set, where the replication list can mix multicast and unicast locators. When approved, this document obsoletes RFC 6831.

Defines the Open Cloud Mesh Integration Protocol (OCM-IP), which specifies how an OCM Server integrates supporting servers -- SSH/SFTP servers, web application platforms or stand-alone WebDAV servers -- to perform protocol-specific work on its behalf. It lets an OCM Server offload protocol-specific interactions and implement OCM as a lightweight server handling only discovery, share creation, token issuance and signing. It defines three integration modes -- provisioned (push over a signed back channel), self-contained (share info embedded in the signed access token) and introspected (credentials validated via a token introspection endpoint) -- while remaining invisible to the Receiving Server.

Extends the Open Cloud Mesh (OCM) protocol to enable federated groups as share recipients, using the Messaging Layer Security (MLS, RFC 9420) protocol for group administration and key distribution. MLS manages establishment and rotation of shared group keys across federated members while preserving group state, delivering both federated group membership and a standardized approach to cryptographically secure key distribution. This permits optional encryption and decryption of resources shared with federated groups, with MLS acting as a group-management vehicle offering discretionary encryption.

Under the base BGP specification, a speaker receiving an UPDATE with a malformed attribute must reset the session; RFC 7606 revised error handling for many attributes using 'treat-as-withdraw' and 'attribute discard' to reduce resets and improve stability. In practice, BGP session oscillations still occur due to malformed updates, unrecognized attribute fields or routing rules from a particular AFI/SAFI that affect forwarding of BGP messages. This document introduces additional approaches to further enhance the stability of BGP sessions.

IANA maintains several registries created for IPv4. As the IPv4 core specification is no longer being extended, and as some registries lack a defined IANA registration procedure, these registries need updating either to indicate a registration procedure or to reflect current practice that defining such extensions is not recommended. The document tidies the status and procedures of these legacy registries.

Introduces new IP Flow Information Export (IPFIX) Information Elements to identify a set of QUIC-related information contained in the QUIC Header, QUIC Frame and Stream for traffic being forwarded. The new Information Elements let flow exporters and collectors record and reason about QUIC-specific attributes of observed traffic.

Presents a security- and privacy-preserving execution-finality architecture for third-party AI interoperability under the EU Digital Markets Act (DMA). It separates an AI-generated request from the authority to make that request externally effective: a requested operation stays in a Non-Effective State until protected infrastructure validates requester, resource, destination, user authorization/intent, purpose, scope, freshness, revocation state and runtime conditions. After validation it creates narrowly scoped, non-bearer execution authority bound to the specific Candidate Act, re-verified at a Finality Sink before the operation becomes effective. It addresses prompt injection, confused-deputy behaviour, replay, token theft, destination substitution, scope escalation, stale authorization and alternate-path bypass, enabling open participation with bounded, verifiable authority.

Derived-identifier constructions that combine local material with identifiers from other systems need a defined comparison domain. This document defines a structured value model for such constructions and their profiles: a Value contains exact context octets, exact content octets and a finite set of scoped opaque identifiers, with structural admission and equivalence independent of serialization and equality spanning context, content and complete identifier-set membership. It gives source mappings and profiles common obligations for fixed inputs, imported comparison adaptation and preservation of participation distinctions, while defining no global semantic namespace, wire format, cryptographic construction or trust mechanism.

Defines a 'Signed SAVNET-Peering Information' (SiSPI) object, a Cryptographic Message Syntax (CMS) protected content type included in the Resource Public Key Infrastructure (RPKI). A SiSPI object is a digitally signed object carrying an attestation for a single Autonomous System participating in inter-domain SAVNET. A valid SiSPI object confirms that the holder of the listed AS number has published an attestation of its participation in inter-domain SAVNET and its willingness to establish SAVNET peering relationships.

Remote attestation can establish that a CPU, confidential VM, GPU, AI accelerator, DPU or SmartNIC runs expected firmware and software in an expected configuration, but an acceptable Attestation Result describes the execution environment, not the operations it later emits -- it stays the same whether outputs arise from expected logic, prompt injection or model error. As agentic AI workloads move onto confidential accelerators and emit high-consequence operations (financial transfers, cloud-control mutations, database deletions, external API calls), platform trustworthiness alone cannot decide whether a concrete operation is authorized to take effect. The draft bridges platform appraisal with consequence-bearing authorization using an Execution-Finality Validator that issues act-bound, single-use Execution Handles verified at non-bypassable boundaries, requiring no silicon or firmware changes, with a working reference implementation.

The messages of the Internet Key Exchange version 2 (IKEv2) protocol are made up of payloads, each currently limited to 64KB by a 2-byte length field. While usually sufficient, several payloads may need to be larger -- particularly with post-quantum key exchange. This document updates RFC 7296 by defining an extension that allows larger payloads.

A number of extensions proposed in the TLS working group carry no information except a 1-bit indication that a certain optional feature is supported, yet each such extension takes 4 octets. This document defines a flags extension that can provide such indications at an average marginal cost of about 1 bit each, reducing overhead when many boolean capability signals are present.

VRRP Version 3 (RFC 9568) assumes multicast operation on a shared LAN, but some deployments need the VRRP first-hop redundancy function while being unable to use multicast delivery for advertisements. This document updates RFC 9568 by defining an optional configured unicast mode in which advertisements are sent to configured peer addresses rather than the VRRP multicast group. The VRRP packet format, state machine, protocol number, virtual IP semantics and virtual router MAC behaviour remain unchanged.

Authorization artifacts provide signed evidence of permissions and receipts record when authorization was exercised, but neither indicates where the authorization can be contested, which procedure applies, whether a filing changes execution state, or who selected the contestation forum. This document defines a transport-independent Contestability Binding for authorized agent actions that commits an authorization to a versioned Contestation Parameters Object identifying the forum, submission mechanism, standing policy, procedure, time bounds, declared effect policy and selection evidence. It makes bound contestation parameters identifiable, verifiable and resistant to post-action substitution, without determining standing, proving forum independence or resolving disputes.