IETF Internet-Drafts & RFCs — Daily Digest

Protocol-Specific Profiles for JSContact

This RFC defines the 'JSContact Profiles' registry, an IANA registry for named subsets of JSContact elements. Its purpose is to make JSContact easier to use in contact-data exchange protocols, and in other use cases where supporting the full set of JSContact semantics might be inappropriate. By registering well-defined profiles, implementers can agree on a bounded subset of elements suited to a particular protocol or application.

The AEGIS Authenticated Encryption Algorithms

This RFC describes four AES-based authenticated encryption with associated data (AEAD) algorithms: AEGIS-128L, AEGIS-256, AEGIS-128X, and AEGIS-256X, designed for high-performance applications. It also specifies their use as stream ciphers and as message authentication codes. The document is a product of the Crypto Forum Research Group (CFRG) of the IRTF and represents that group's consensus on the AEGIS family.

Advertising Unreachable Links in OSPF

This RFC specifies how OSPF advertises unreachable links. OSPF Router LSAs use fixed-format encodings that always include advertised links in the default SPF computation; for non-default computations such as Flexible Algorithms (RFC 9350) this may be unintended. The metric LSLinkInfinity (0xffff) marks a link as unreachable, and if all routers in an area support the feature and advertise the capability via an area-scoped Router Information LSA, such links are treated as unreachable. MaxReachableLinkMetric (0xfffe) provides backward-compatible reachability, updating RFC 5443, RFC 6987, RFC 8379, and RFC 8770 to advertise 0xfffe rather than MaxLinkMetric (0xffff).

Bit Index Explicit Replication (BIER) is a multicast forwarding architecture that simplifies and optimizes multicast delivery. This document specifies OAM mechanisms and packet formats for BIER ping and trace, enabling failure detection and fault isolation directly on the BIER data plane. The procedures work without depending on other network layers such as IP, so operators can probe and troubleshoot BIER forwarding on its own terms.

This document specifies the pcapng (PCAP Next Generation) capture file format for recording captured network packets to disk. The format is designed to be extensible, so new block and option types can be added over time. It is already widely supported: Wireshark can read and write pcapng, and libpcap can read some pcapng files, giving it broad compatibility with existing packet-analysis tooling.

This specification defines a method for two parties in a communication to exchange Evidence and Attestation Results using exported authenticators, as defined in RFC 9261. It introduces a 'cmw_attestation' extension that lets attestation credentials be embedded directly in Certificate messages during post-handshake authentication. The design supports both the passport and background-check models of the RATS architecture, and keeps the attestation cryptographically bound to the underlying communication channel.

By its name, this individual draft concerns the 'HELM' protocol and a 'tttps' scheme or transport variant. The document page could not be opened on the fast source during this run (HTTP 404), so no official Abstract was retrieved. This is revision -10, indicating a mature, actively maintained individual submission. The description here is approximate and will be grounded from the official Abstract on the next run once the page is reachable.

By its name, this new -00 individual draft appears to relate to the 'HELM' protocol applied to a 'deep space' or delay/disruption-tolerant networking context. The document page could not be opened on the fast source during this run (HTTP 404), so no official Abstract was retrieved. As a first (-00) version it likely sets out initial goals and scope. This summary is approximate and will be grounded from the Abstract on the next run.

By its name, this new -00 individual draft appears to concern a 'confidence' mechanism within the 'HELM' protocol family. The document page could not be opened on the fast source during this run (HTTP 404), so no official Abstract was retrieved. As a -00 submission it probably introduces the concept and its intended use. This description is approximate and will be grounded from the official Abstract on a subsequent run.

This document 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. It also states requirements a client MUST satisfy when handling such a URI, to avoid two failure modes that 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.

The Lightweight Authenticated Key Exchange (LAKE) protocol, formerly EDHOC (RFC 9528), relies on elliptic-curve cryptography for key exchange and authentication. This document specifies how LAKE operates in a post-quantum setting by defining new cipher suites built on 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 extending the Method Types and Cipher Suites registries with columns indicating, respectively, whether a method requires and whether a suite supports Diffie-Hellman or Non-Interactive Key Exchange (NIKE) primitives.

This short individual draft defines a diagnostic header field for implementations of DomainKeys Identified Mail Signatures v2 (DKIM2). During early deployment, implementers and testers benefit from extra debug information about how DKIM2 processing proceeded. The document is explicitly aimed at helping testers and states that it is unlikely to be published as an RFC, positioning it as an interim aid for the DKIM2 rollout phase.

This document defines a new verifiable data structure type for COSE Receipts, specifically for ledgers based on post-order traversal binary Merkle trees. Such trees, also called history trees, are more commonly known as Merkle Mountain Ranges (MMRs). The profile targets ledgers designed for high throughput, easy replication, and compatibility with commodity cloud storage, so that receipts can attest to entries in MMR-based logs interoperably.

This document defines the Agent-to-Wallet Protocol (A2WP), an interface through which a software Agent requests digital-credential operations from a Wallet. It facilitates credential acquisition and presentation while the Wallet retains authority over credential selection, approvals, and cryptographic operations. A2WP defines an information model, observable operation behaviour, and an HTTPS binding. It deliberately excludes credential formats, Agent identity, delegation strategies, policy languages, and internal Wallet architecture, integrating external credential protocols through dedicated mappings to stay flexible while preserving interoperability.

This draft addresses early attestation, arguing it is 'considered harmful' and can fail in practice even without physical access; because continuous attestation is generally required, early attestation adds unnecessary complexity. It documents numerous published vulnerabilities (multiple CVEs and GHSAs, several at CVSS 9.1 and above) affecting early attestation implementations across ecosystem layers, and notes that some remaining implementations stay vulnerable to relay attacks. Findings are backed by formal analysis (ProVerif) with artifacts shared under Apache-2.0 for reproducibility. This is revision -35.

This document defines a threat model for autonomous high-consequence AI agents that are delegated authority to invoke APIs, move money, modify enterprise state, run infrastructure, or trigger physical actions. It 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 an act stays non-effective until a protected enforcement point verifies exact-act binding, freshness, current policy, anti-replay state, provenance, and path completeness right before effectuation.

This draft presents an execution-finality architecture aimed at secure, privacy-preserving AI interoperability, framed against Article 6(7) of the EU Digital Markets Act. As AI assistants interoperate with OS functions, apps, cloud, payments, files, and devices, authenticating an assistant or granting broad permission does not answer whether this exact pending operation, with these parameters and current state, may become externally effective. It introduces a Candidate Act held in a Non-Effective State, a Protected Execution Domain, and a mandatory Finality Sink that independently reconstructs the operation just before the consequence, defending against prompt injection, replay, token theft, parameter substitution, and stale authorization. It stresses it does not itself determine legal compliance.

This draft applies execution-finality enforcement to AI-factory silicon and accelerated infrastructure: GPUs, chiplets, memory fabrics, DPUs, RDMA, CXL, and photonic boundaries. It argues that authentication and access control are necessary but insufficient to decide whether a specific pending operation is still authorized at the instant it becomes effective. Consequential operations are held in a Non-Effective State while a Protected Enforcement Domain evaluates authority and binds a narrowly scoped, non-bearer permit to the exact parameters and Finality Sink. It catalogues 98 enforcement profiles across GPU, silicon, chiplet, and memory-fabric boundaries, summarised as: computation may produce a proposed act, but computation alone is not authority for consequence.

This individual submission catalogues seventy-seven enforcement profiles for a common pattern: keep a pending operation non-effective until a mandatory enforcement point at the real consequence boundary verifies that the exact live operation still matches current bounded authority. It introduces the Capability-Validated Inbound Descriptor (CVID) as one representation of that authority, binding to effect-determining parameters, sink, generation/policy state, freshness, and bounded-use state. Profiles span inbound communications, AI-native RAN and packet core, distributed inference, NTN, CBDC settlement, RDMA/DMA and accelerator paths, eSIM/roaming, and more, and deliberately separate authority to consume resources, to compute, and to cause an external effect.

This draft addresses 'technical non-joinability' for enterprise AI systems connected to many organizational repositories, apps, tools, and memory systems (e.g. ChatGPT Work, Claude, Gemini Enterprise, Copilot, Amazon Q, Agentforce, ServiceNow AI Agents). The core risk is that an AI workload individually authorized for many sources can combine them to reveal a sensitive relationship or future state no single repository contains. The mechanism separates not only protected data but the authority to create protected semantic relationships among it, keeping identity, content, relationship mapping, reconstruction-enablement, and authorization state under independent domains, and binding a reconstruction authorization to the actual workload, context, fields, relationships, purpose, and output conditions.

This draft defines execution finality at external-effect boundaries with enforcement profiles for 6G, AI-native RAN, RF, ISAC, accelerated compute, devices, and autonomous systems. Its central invariant: successful computation, authentication, attestation, access authorization, credential possession, or execution inside a trusted environment does not by itself establish authority for the resulting operation to become externally effective. It defines a Candidate Act, a Protected Enforcement Domain, Protected Validation Evidence, a scoped non-bearer capability, and a Finality Sink at the consequence boundary, and provides 132 enforcement profiles across agentic AI, radio access, sensing, content delivery, cyber-physical control, and hardware egress.

Titled 'Possession Is Not Authority,' this draft specifies five wire objects for finality enforcement: a canonical Candidate Act Descriptor, a scoped non-bearer Execution Handle bound to that act and a designated sink, a verify operation that reconstructs the pending effect, an atomic consume that prevents replay, and a Finality Receipt recording what was permitted. It observes that tokens, capabilities, cookies, SPIFFE SVIDs, WIMSE credentials, OAuth grants, attestation results, or signed mandates can stay valid while being presented for a different call, beneficiary, sink, replayed payment, migrated region, or alternate path. It defines JSON and COSE/CWT encoding profiles and claims prevention only when exact-act binding, sink binding, currentness, reuse policy, path coverage, and verify-to-commit serialization are load-bearing.