IETF Internet-Drafts & RFCs — Daily Digest

The AEGIS Authenticated Encryption Algorithms

Describes the AEGIS-128L, AEGIS-256, AEGIS-128X, and AEGIS-256X AES-based authenticated encryption with associated data (AEAD) algorithms, designed for high-performance applications. It also specifies their use as stream ciphers and as message authentication codes (MACs). The document is a product of the Crypto Forum Research Group (CFRG), providing a stable reference for the AEGIS family of high-speed AEAD constructions.

Advertising Unreachable Links in OSPF

OSPF Router LSAs use fixed-format encodings that always include advertised links in the default SPF computation, which is undesirable for non-default computations such as Flexible Algorithms (RFC 9350). Historically the LSLinkInfinity metric (0xffff) marked a link unreachable. This RFC defines MaxReachableLinkMetric (0xfffe) to provide backward-compatible reachability where specifications previously advertised MaxLinkMetric (0xffff). When all routers in an area support and advertise the capability via a Router Information LSA, links with LSLinkInfinity are treated as unreachable. It updates RFC 5443, RFC 6987, RFC 8379, and RFC 8770.

BIER (Bit Index Explicit Replication) is a multicast forwarding architecture that simplifies and optimizes multicast delivery. This draft specifies the mechanism and a basic BIER OAM packet format for performing failure detection and fault isolation directly on the BIER data plane, without any dependency on other layers such as IP. It provides a ping/trace-style capability tailored to the BIER forwarding plane.

Defines the pcapng file format used to record captured packets to a file. The format is extensible; Wireshark can currently read and write it, and libpcap can read some pcapng files. The document aims to standardize the on-disk representation widely used by packet-capture tooling, describing its block structure and extensibility so that interoperable implementations can produce and consume the format.

Specifies a method for two parties in a communication to exchange Evidence and Attestation Results using exported authenticators (RFC 9261). It introduces the cmw_attestation extension, allowing attestation credentials to be carried directly in the Certificate message during Exported Authenticator-based post-handshake authentication. The approach supports both the passport and background-check models of the RATS architecture while binding attestation to the underlying communication channel.

By its name, this appears to be revision 10 of a 'tttps' proposal under the informal 'helmprotocol' individual series; its official abstract could not be retrieved on this run (the ietf.org archive page returned 404), so this description is approximate and written from the document name. It probably concerns a transport/transfer protocol variant related to TLS/HTTPS-style secure transport. It will be grounded from the official Abstract on the next run.

By its name, this is an initial (-00) 'deepspace' proposal in the individual 'helmprotocol' series; its official abstract could not be retrieved on this run (404 on the ietf.org archive page), so this summary is approximate and derived from the name only. It likely relates to protocol operation over deep-space or high-latency/delay-tolerant links. No specific mechanisms, algorithms, or claims are asserted here; it will be grounded from the Abstract on the next run.

By its name, this is an initial (-00) 'confidence' proposal in the individual 'helmprotocol' series; the official abstract could not be retrieved on this run (404 on the ietf.org archive page), so this description is approximate and based on the document name alone. It probably addresses some notion of confidence or trust signalling within the helmprotocol framework. Details are deliberately not invented; it will be grounded from the Abstract on the next run.

Specifies the 'rttp' URI scheme. An rttp URI names a claim of intent directed at an identified subject; the subject's address is derived by computation from the URI authority, with no lookup service, registry, or name-resolution system consulted at resolution time. The draft states requirements a client MUST meet when handling such a URI, to avoid two failure modes short user-embeddable strings invite: treating the authority as a navigation target (open redirect), and using a registered protocol handler as a general-purpose launcher.

Extends the Lightweight Authenticated Key Exchange (LAKE) protocol — formerly EDHOC (RFC 9528) — into a post-quantum setting by defining new cipher suites using quantum-resistant algorithms such as ML-DSA for signatures and ML-KEM for key exchange. It also updates RFC 9528 by renaming the protocol from EDHOC to LAKE and adding columns to the Method Types and Cipher Suites registries indicating whether a method requires, and whether a cipher suite supports, Diffie-Hellman or Non-Interactive Key Exchange (NIKE) primitives.

Aimed at the early deployment phase of DomainKeys Identified Mail Signatures v2 (DKIM2). It defines extra debug information that implementations can surface to help testers during initial rollout. The document explicitly notes it is intended to assist testers and is unlikely to be published as a standard, marking it as a transitional deployment aid rather than a long-term specification.

Defines a new verifiable data structure type for COSE Receipts, specifically for ledgers based on post-order traversal binary Merkle trees. These trees — also called history trees, and more commonly known as Merkle Mountain Ranges — are designed for high throughput, ease of replication, and compatibility with commodity cloud storage. The profile enables transparency/receipt use cases over such append-only, replication-friendly log structures.

Defines the Agent-to-Wallet Protocol (A2WP), an interface through which a software agent requests digital credential operations from a wallet. A2WP supports credential acquisition, presentation, and optional queries for authorized credential metadata, while the wallet controls credential selection, disclosure, approval, and cryptographic execution. It defines an information model, observable operation behavior, and an HTTPS binding. Credential formats, agent identity schemes, delegation, policy languages, and wallet internals are out of scope, integrated instead via protocol mappings.

Presents technical detail on a set of CVEs, EUVDs, and GitHub Security Advisories that, the authors argue, show early attestation failing in practice even without physical access. It contends that because continuous attestation is generally required, early attestation adds unnecessary complexity. Results are backed by formal analysis in ProVerif with Apache-2.0 artifacts for reproducibility, and the authors report that remaining early-attestation implementations they examined remain vulnerable. It catalogs multiple high-CVSS advisories across the ecosystem.

Defines a threat model for autonomous high-consequence AI agents and identifies an 'effectuation-boundary gap': a request can be correctly authenticated, authorized, and attested yet still be unsafe to execute because parameters, policy state, prerequisites, delegation state, lineage, or the execution path changed after the earlier decision. It describes an execution-finality architecture in which a proposed act stays non-effective until a protected enforcement point verifies exact-act binding, freshness, current policy state, anti-replay state, provenance, and path completeness immediately before effectuation, consuming authority in coordination with the commit.

Argues that authenticating an AI assistant or granting it broad permission does not answer whether a specific pending operation, with exact parameters and current system state, is authorized to become externally effective. It composes existing mechanisms (OS permissions, OAuth, RAR, sender-constrained tokens, TEEs, attestation) into a sequence: keep the act non-effective, bind authority to the exact act and state, re-derive the pending consequence at a mandatory effectuation boundary (a 'Finality Sink'), consume freshness in a TOCTOU-resistant way, and deny alternate paths. It cites DMA/Siri interoperability as a motivating example and links runnable reference implementations.

Treats AI factories and AI-native infrastructure as heterogeneous control systems where CPUs, GPUs, NPUs, memory controllers, CXL/PCIe paths, DMA/RDMA engines, DPUs, SmartNICs, fabrics, chiplets, storage, and power/cooling controllers can all take part in one consequential operation. It argues existing mechanisms (attestation, confidential computing, IOMMU/SMMU isolation) are necessary but insufficient, and defines the missing rule: hold an operation pending, validate authority and state, bind a scoped non-bearer capability, and require the boundary (Finality Sink) controlling the consequence to verify the binding before commit. It provides 98 enforcement profiles.

Describes seventy-seven enforcement profiles for a common engineering pattern across networks, AI systems, cloud, vehicles, radios, accelerators, and control systems: keep a pending operation non-effective or inhibited until a mandatory enforcement point at the actual consequence boundary verifies that the exact live operation still matches current bounded authority. It introduces Capability-Validated Inbound Descriptors (CVID) and stresses functional equivalence across implementations, with coverage spanning domains from satellite networks to payment settlement.

Addresses enterprise AI systems connected to many organizational repositories, tools, and workflows, where an AI workload individually authorized to read multiple sources can reconstruct a sensitive relationship or future state that no single store contains. It separates not only protected data but the authority to create protected semantic relationships among that data, introducing 'Technical Non-Joinability' as a separately enforceable property. A bounded reconstruction authorization ties processing to workload, session, permitted fields/relationships, purpose, and output conditions. It presents 79 enforcement profiles applying the architecture to enterprise AI enforcement points.

Describes a protected execution-finality architecture that distinguishes successful computation from authority for external consequence. A proposed operation stays non-effective while a Protected Enforcement Domain validates authority predicates and state, committing validation evidence before authorizing a scoped capability bound to the act, evidence, state, freshness, scope, boundary, and Finality Sink. The sink performs machine-enforced capability checks before the operation crosses the finality boundary, failing closed on absent, expired, revoked, replayed, stale, or mismatched conditions. It provides 132 enforcement profiles across agentic AI, RAN/RF, IoT, PQC, and silicon boundaries.

Argues that identity, authorization, attestation, and signed-statement protocols lack interoperable objects at the effectuation boundary, since a token, capability, SVID, OAuth grant, attestation result, or signed mandate can stay cryptographically valid while presented for a different tool call, substituted beneficiary, second sink, replayed payment, migrated region, or alternate admin path. It specifies a Candidate Act Descriptor, a scoped non-bearer Execution Handle bound to the exact act and Finality Sink, verification that reconstructs the pending effect, atomic anti-replay consumption, and a Finality Receipt. Encoding profiles are given for JSON and COSE/CWT.

Specifies an experimental binding of a signed containment instruction and a 'Presidential Capability Advertisement' to a GIF89a image, so an operator can deliver one object for inspection, capability-claim presentation, and machine enforcement. It defines container, signature, anti-replay, delivery, enforcement-receipt, and recovery requirements, and deliberately establishes no image-carried release mechanism: the protection boundary sits at the managed resource interface rather than at recipient compliance. The experiment concerns authenticated artifact delivery and observable containment.

Segment Routing (SR) steers packets via source routing over both MPLS (SR-MPLS) and IPv6 (SRv6) data planes. This document describes performance-measurement procedures for SR-MPLS networks using the Simple Two-Way Active Measurement Protocol (STAMP, RFC 8762) with its optional extensions (RFC 8972, RFC 9503). The procedures apply to SR-MPLS paths — including segment lists of SR-MPLS Policies, IGP best paths, and IGP Flexible Algorithm paths — and to Layer-3 and Layer-2 services carried over them.

Companion to the SR-MPLS performance-measurement work, this document describes performance-measurement procedures for SRv6 networks using STAMP (RFC 8762) with its optional extensions (RFC 8972, RFC 9503). Segment Routing steers packets through source routing over the SRv6 data plane, and the procedures cover links and SRv6 paths — including segment lists of SRv6 Policies, IGP best paths, and IGP Flexible Algorithm paths — as well as Layer-3 and Layer-2 services carried over those SRv6 paths.

STAMP and its optional extensions can perform edge-to-edge active measurements, and IOAM data fields can record hop-by-hop and end-to-end telemetry. This draft extends STAMP to reflect IP headers as well as IPv6 extension headers for hop-by-hop and end-to-end active measurements, for example using IOAM data fields. It also specifies requirements for IPv6 STAMP in unauthenticated mode using a UDP zero-checksum, which deviates from the integrity requirement of RFC 6936.

Also building on STAMP and IOAM, this document extends STAMP to reflect MPLS Network Action Sub-Stacks and Post-Stack MPLS Headers for hop-by-hop and end-to-end active measurements — for example, by using IOAM data fields. It targets performance measurement in MPLS networks where these header constructs are present, complementing the STAMP IP/IPv6 extension-header reflection work.

Describes IP addressing with references (IPREF), a method for end-to-end communication across different address spaces not normally reachable natively. IPREF uses references to addresses rather than real addresses, allowing hosts to reach across NAT/NAT6 and across IPv4/IPv6 as a pure Layer-3 addressing feature that works with existing protocols. IPREF addresses (context addresses plus references) are publishable in DNS, so services behind NAT or on a different protocol become reachable from any address space when both ends support IPREF, providing IPv4/IPv6 compatibility for the mixed-protocol Internet.

Notes that RPKI provides cryptographic route-origin authorization but its hierarchical model gives no way for a superior authority to permanently divest control of a delegated resource. This draft explores a protected delegation boundary beyond which superior authorities can no longer reclaim a resource, suppress the holder's origin authorizations, or create competing authority. It specifies a hierarchical IPv4/IPv6 resource registry enforcing this property at the state-transition boundary and deriving Validated ROA Payloads for conventional ROV, with conflict/precedence rules so protected resources coexist with RPKI. It is intended for experimental deployment alongside RPKI.

Extends the Zero Trust Fabric Layer (ZTFL), which verified a single agent's single request, to handle delegation across multiple agents in multi-agent orchestration. Using an international-travel metaphor, an immutable Passport establishes identity for the whole journey; a Ticket issued once at task initiation binds every hop to one authorized chain; a per-hop Boarding Pass derived from the Ticket authorizes each leg; and a narrowly scoped Visa is required only when a hop crosses a tenant boundary. The model is formalized as a boundary-conditional evaluation function and validated against the Cedar policy language.

Defines vaara.receipt/v1, a signed and independently recomputable record that binds a decision about an autonomous action to the evidence it was made on, and optionally to one or more external timestamp anchors. It uses the JSON Canonicalization Scheme so third parties can recompute digests and verify signatures without issuer access, and pairs a decision with its execution receipt via an envelope back link. The trust model is root-agnostic — verifiable with or without hardware TEEs and re-expressible as an IETF RATS Entity Attestation Result — with a minimal profile serving as the format's floor.

Observes that UAS trust infrastructure answers 'who is this aircraft?' (Remote ID, strengthened by DRIP) and 'may this flight take place here and now?' (UTM/U-space/geo-awareness), but not whether a specific act — arming motors, crossing into a newly restricted volume, releasing a payload, activating a camera, emitting on a band, or joining a coordinated manoeuvre — may become effective at this actuator, at this instant, under current airspace and revocation state. It contributes Compact Broadcast Act Evidence and execution-finality embodiments for detect-and-avoid, emergency scenes, and control handover, complementing rather than replacing existing systems.

Defines a digital credential format using JSON Web Proofs (JWP) as the container and Blind BBS Signatures as the signature scheme, combined with a modular framework for attaching zero-knowledge sub-proofs. It lets holders selectively reveal attributes while proving predicates such as range or equality over concealed values, and supports binding credentials to holder-controlled device keys with possession verified at each presentation without exposing the public key or signature. Core serialization follows the SD-JWT VC data model; specific sub-proof and device-binding constructions are deferred to future specifications.

An applicability statement (RFC 2026 Section 3.2) describing how to securely exchange structured business data over HTTP — XML, EDI in ANSI X12 or UN/EDIFACT, or other structured formats — packaged using standard MIME structures. Authentication and confidentiality use Cryptographic Message Syntax with S/MIME security body parts, and authenticated acknowledgements use multipart/signed Message Disposition Notification responses. Known informally as 'AS2', it obsoletes RFC 4130, stands on its own without AS1 or SMTP except for IANA updates, and updates registries originally created by RFC 3335 and RFC 4130.

Proposes new cipher suites based on the AEGIS family of authenticated encryption with associated data (AEAD) algorithms. The suites integrate AEGIS into TLS 1.3, DTLS 1.3, and QUIC, extending these transport security protocols with AEGIS-based AEAD options aimed at high-performance encryption.

Specifies AIN-WRP, a protocol-independent mechanism for authoritative resolution of persistent digital agent identities and verification of relationship-specific state before an agent begins a protected interaction with another agent or service. An Agent Identity Number (AIN) is a stable lookup anchor, and the protocol resolves identity, lifecycle, operator/authority, endpoint, mandate, restriction, provenance, and cryptographic verification from competent sources. It separates persistent identity from credentials, proof of control, delegated authority, eligibility, policy, and execution, producing a Pre-Interaction Trust State conveyed as a signed, time-limited State Proof to a gateway.

Automatic Dependent Surveillance–Broadcast (ADS-B) is widely deployed but lacks security and privacy. This draft introduces the IETF TESLA protocol together with X.509 certificates from ICAO member states to verify all ADS-B messaging. It uses the 8PSK phase-overlay scheme from the ADS-B MOPS to carry three times more information with negligible impact on channel usage. Benefits include message authentication, a possible flight-authorization scheme to verify an aircraft is cleared for a specific flight, and a privacy-preserving method assigning random identifiers while enabling blind authentication.

Composite ML-KEM defines combinations of the Module-Lattice-based Key Encapsulation Mechanism (ML-KEM) with RSA-OAEP, ECDH, X25519, and X448. This document specifies the conventions for using Composite ML-KEM algorithms with the Cryptographic Message Syntax (CMS) via the KEMRecipientInfo structure defined in RFC 9629 ('Using Key Encapsulation Mechanism (KEM) Algorithms in the CMS'). It supports hybrid post-quantum key establishment in CMS-protected messages.

Defines the OTP-Token email header field, used to deliver One-Time Passcodes (OTP) in a machine-readable, origin-bound manner alongside the human-readable message that carries the code today. Recipient Message User Agents (rMUAs) can collaborate with other entities in the ecosystem to help deliver these codes to the context that wishes to verify their successful delivery, improving automated, secure handling of OTP emails.