IETF Internet-Drafts & RFCs — Daily Digest

Defines a unified, gateway-free solution for seamless Multicast VPN (MVPN) interoperability between EVPN and MVPN Provider Edges, building on RFC 6513 and RFC 6514. EVPN is now pervasive for Network Virtualization Overlay services across data centers, enterprise and service-provider networks. As operators move central offices toward SDN fabrics and NFV, they need to preserve existing MVPN service between legacy networks and new Service Provider Data Centers without gateway devices. The draft also shows how the same approach serves as a routed multicast solution in data centers containing only EVPN PEs, cutting cost and provisioning while keeping forwarding optimal.

States the problem, common terminology, security models and technical requirements for discovering, validating and establishing secure connections with local network devices. It examines why web PKI is hard to extend to offline or constrained environments. Requirements cover privacy-preserving device discovery, generating local trust anchors, and setting up mutually authenticated secure connections without relying on global certificate authorities or problematic Trust On First Use mechanisms.

Extends the existing per-organization limit on IETF Nominating Committee (nomcom) representation (RFC 8713, Section 4.17) so that not all voting members belong to the same gender. It guarantees up to three voting seats to volunteers who opt into a self-declared pool, and changes the random selection only in years when a plain random draw would seat fewer such volunteers.

The official abstract could not be retrieved on this run (the draft page returned 404), so this description is approximate. By its name it probably defines a typed evidence-record format, likely for structured attestation or audit evidence in a security context. No specific mechanisms are asserted here to avoid inventing content; it will be grounded from the official Abstract on the next run.

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

Defines Contextual IP Prefix Semantics (CIPS), a model distinguishing addresses, canonical prefixes, addresses with prefix context, and prefix selectors, and shows how these forms are qualified by operational context. It offers a taxonomy of operational contexts and a vocabulary for implementers, stressing that true canonical-prefix support means preserving the canonical prefix form as its own identity rather than merely accepting slash-qualified text. The aim is to help specification authors, API designers, tool developers and operators keep semantic distinctions when prefix-bearing values cross interchange boundaries.

The official abstract could not be retrieved on this run (the draft page returned 404), so this description is approximate. By its name this is an individual submission (identifier 'aer1'); its precise scope cannot be confirmed from the name alone. No specific mechanisms are asserted here; it will be grounded from the official Abstract on the next run.

The official abstract could not be retrieved on this run (the draft page returned 404), so this description is approximate. By its name this is probably a content profile tied to an 'eu2122' context. The exact subject cannot be confirmed from the name, so no mechanisms are asserted; it will be grounded from the official Abstract on the next run.

Presents technical evidence that 'early attestation' fails in practice, even without physical access, by analyzing a set of CVEs, EUVD entries and GitHub Security Advisories, including several high-severity issues (two CVEs at CVSS 9.1 and GHSAs rated from 6.3 up to 9.0-10.0). It argues that because continuous attestation is generally required anyway, early attestation only adds unnecessary complexity. Findings are backed by ProVerif formal-analysis artifacts under Apache-2.0. Most early-attestation implementations have been archived or withdrawn; the draft flags Edgeless Systems Contrast and Meta's AI as still vulnerable and urges users to evaluate their systems carefully.

Describes extensions to YANG notification subscriptions that let metrics be published directly from processors on line cards to target receivers, while the subscription itself is still maintained at the route processor. This supports distributed forwarding systems within a single network node.

Adds selective disclosure to JWT access tokens without changing the Authorization header format or how the token is validated. An RFC 9068 token is sent as today, but some claims become selectively disclosable per SD-JWT (RFC 9901); the Disclosures and an optional Key Binding JWT travel in two new HTTP fields. A recipient that does not implement the profile ignores those fields and treats the token as an ordinary JWT access token. The token itself carries no selectively disclosable value, and the holder chooses per request which values to reveal.

Defines the 'model_attestation' block of the Agent Action Capsule (AAC) profile, referenced by the base profile but never defined there, and within it a 'compute_attestation' container carrying runtime extensions: the model-serving runtime, the agent's execution environment (architectural pattern, orchestration framework, sandbox confinement, invoked tool version) and host hardware, plus model and weights claims. Every claim declares its source explicitly; a verifier grades claims by how they were observed and never infers a stronger grade than the evidence supports. Hardware or platform attestation is cited by content-addressed reference to a foreign attestation record and verified with that record's own verifier.

Defines 'org.agentactioncapsule.otel', a namespaced payload extension for the Agent Action Capsule profile. It carries OpenTelemetry trace and span context alongside a sealed agent-action record, so the Capsule and the observability spans for the same action can be joined after the fact. It maps the OpenTelemetry Generative AI semantic conventions onto Capsule fields where a mapping is well defined, and states which OpenTelemetry values must not enter a Capsule at all. Capsule verification is unchanged: a verifier that does not implement the extension treats the block as informational.

Lists many of the considerations the DNS community must balance when choosing which post-quantum algorithms to standardize for DNSSEC. The author states explicitly that the draft is not meant to become an RFC; it is a discussion document intended to inform that decision rather than to define a mechanism.

RPC-with-TLS assumes DANE is available where deployed and recommends that an opportunistic-security client check for a TLSA record before an association, but never says how. This document supplies the missing details so a TLSA record can authenticate an RPC server with no certification-authority trust anchor provisioned on the client. It updates RFC 9289.

An applicability statement (per RFC 2026, Section 3.2) describing how to securely exchange structured business data over HTTP: XML, EDI formats (ANSI X12 and UN/EDIFACT) and other structured data packaged in standard MIME. Security uses Cryptographic Message Syntax with S/MIME body parts; authenticated acknowledgements use multipart/signed Message Disposition Notifications. Known as 'AS2', the second applicability statement after AS1 (RFC 3335). It obsoletes RFC 4130 and updates IANA registries originally established by RFC 3335 and RFC 4130.

RFC 4552 specifies using the IPsec Authentication Header (AH) and Encapsulating Security Payload (ESP) for authentication and confidentiality in OSPFv3. This document deprecates the use of AH for OSPFv3 and updates RFC 4552 accordingly. Operators are encouraged to use ESP with NULL encryption (per RFC 4552) or the OSPFv3 Authentication Trailer (RFC 7166) instead.

SRv6 is a traffic-engineering, encapsulation and steering mechanism that uses IPv6 addresses to identify segments in a predefined policy. This document discusses security considerations in SRv6 networks, covering potential threats and possible mitigation methods. It defines no new security protocols or extensions to existing protocols.

Authorization, delegation, execution and audit artifacts often identify an action using format-local content and digests that are not directly comparable across formats. This document defines the Canonical Action Identifier (CAID): a typed action object, a canonicalization and digest suite, a compact identifier string, and versioned action-type definitions with required material fields. It specifies a strict JSON input profile, a fixed ordered set of refusal reasons, and a digest identifying a type definition's validation semantics, and requests seven registries. An Action-Mapping Profile projects natively verified artifacts into a common type with closed results (EQUIVALENT_UNDER_PROFILE, NOT_EQUIVALENT, INDETERMINATE). It stresses that CAID carries no trust semantics: no identity, authority, authorization, execution, safety or legal reliance.

Addresses auditable payments for AI agents, building on HTTP 402, AP2 and credit-card systems. It defines a cryptographically secured payment-reconciliation protocol with four parts: a signed Trade Manifest (an offer created before payment), a Policy Decision Point applying default-deny authorization, a Spend Receipt issued as a COSE/CWT claim set after a gated payment, and rail-extract reconciliation against payment-system records. The protocol lets one verifiably answer whether spends aligned with policy, against which specific offers, and what deliverables were provided.

Adding new RRTYPEs to the DNS has historically required upgrading DNS servers and provisioning software to support each type in master files. This document defines a DNS extension language that lets most new RRTYPEs be supported simply by adding entries to configuration data read by the DNS software, with no software changes needed for each RRTYPE.

Describes PALA-1, version 1 of the Portable Append-only Log for Audit, a compact binary record format for tamper-evident audit trails from AI inference runtimes and robotic control systems. It targets modest hardware, no external witness, and separated verification and read permissions. Records form an append-only hash chain whose integrity check needs no key material, inspects no record bodies, and costs one hash per record rather than one signature. The format distinguishes internal consistency, completeness against external anchors, and existence proof via external witnesses; chain heads may optionally be published to transparency services such as SCITT. The wire format is frozen at version 1.0 and described as-is.

Defines the OpenA2A Agent Authorization Protocol (AAP), providing agent identity assertion, scoped capability grants, cross-agent delegation, behavioral attestation, cross-organizational federation and revocation propagation, as the authorization complement to agent communication protocols such as A2A and the Model Context Protocol, much as OAuth 2.0 complements HTTP. AAP has two layers; this document defines the token model (what credentials contain, how they are signed and verified), while a companion broker/resolution layer keeps credential values out of the agent's reasoning context. This revision adds a mandatory-to-understand 'authorization_details' claim with a typed registry and per-type attenuation, an 'aap_crit' claim, a 'cnf' key-binding claim, a session label, and a local grant revocation list.

Defines a benchmarking method measuring whether an AI agent's memory subsystem detects that its persisted memory has been altered, removed, reordered, replayed or forged at the storage layer, and whether it refuses to serve or reports that memory. The method specifies eight storage-level edits, three verdict classes, a read-time versus audit-time detection distinction, three control cases and a scoring rule, in the spirit of RFC 2544 and RFC 8239, and is intended as a test method for the 'Protection of Memory Data Integrity' metric under discussion in the Benchmarking Methodology WG. This revision adds a control proving each edit landed as intended, reports results on thirteen memory subsystems (six claiming tamper evidence), and records the first vendor fix made in response to a measurement.

Hardware components underpin all computation, yet existing attestation largely relies on manufacturer endorsements that give little visibility into runtime behavior. This document extends the Remote ATtestation procedureS (RATS) architecture with a data model and guidelines for including measurements of hardware components in attestation Evidence, whether physical properties, self-test results or behavioral observations. It considers a threat model spanning adversarial actions and physical phenomena such as environmental variation and aging, and proposes abstract interfaces for collecting measurements plus a security model for their use in appraisal, while remaining agnostic to implementation mechanisms.

The official abstract could not be retrieved on this run (the draft page returned 404), so this description is approximate. By its name it appears to define an X.509 certificate profile for AI-agent identity. The exact fields and semantics cannot be confirmed from the name alone, so none are asserted here; it will be grounded from the official Abstract on the next run.

Defines the concept of Service & Infrastructure Maps (SIMAP) and identifies a set of requirements and use cases. Previously known as the 'Digital Map', SIMAP makes the ties between service and infrastructure layers explicit, clarifies expected outcomes for operations and automation, and removes ambiguity around the term 'digital'. The document is meant as a reference for assessing various topology modules against SIMAP requirements.

Integrated Sensing and Communications (ISAC) jointly designs sensing and communication over shared spectral and hardware resources. Distributed sensing tasks fuse raw or pre-processed data from multiple heterogeneous sensors at a processing/computing function, imposing time-synchronization and possibly AI/ML constraints. The joint selection of sensing entities, processing locations and network configuration under time-varying conditions yields a large, coupled, non-stationary decision space, which motivates agentic AI for closed-loop configuration. The document presents initial considerations and candidate solution directions for an architecture enabling agentic AI for sensing as an exemplary network-optimization use case.

BGP exchanges routing information between Autonomous Systems and, given its importance, needs basic security properties for BGP and BGP-speaking routers. This document serves as a repository of contemporary approaches for safeguarding BGP operations. It deliberately avoids judging technique effectiveness or mandating implementations, advising operators to assess whether methods suit their use cases and noting that the available options evolve over time and should not be treated as permanent best practice.

Operating the global routing ecosystem involves many interacting components, and operational terminology has emerged, disappeared and shifted meaning over time. To help operators and implementers read contemporary drafts, this document provides an overview of terms and abbreviations used in the global routing operations community. It explicitly does not act as an authoritative source of correct terminology, but strives to give an overview of practice.

Defines the OpenA2A Agent Identity Protocol (AIP), an open standard for creating, managing and verifying cryptographic identities for AI agents. It centers on five elements: a multi-factor behavioral trust mechanism computed from independently verifiable signals; a portable signed credential with hybrid Ed25519 and ML-DSA-65 signatures for quantum readiness; an append-only Merkle transparency log for identity events; W3C Decentralized Identifiers using did:web at the provider layer and did:opena2a at the ecosystem layer; and a structured capability vocabulary with reserved namespaces. It also covers challenge-response verification, behavioral governance, key rotation and revocation, and audit logging, complementing A2A, MCP, OpenID Connect, WebAuthn and W3C Verifiable Credentials.

Defines AIC-JWT, a JWT-based application-layer representation of the AI Agent Identity Certificate (AIC) data model, which binds an agent's cryptographic identity to a responsible principal with a capability container, delegation mode, authorization constraints and principal-signed delegation evidence. Because many HTTP, web and OAuth 2.0 deployments cannot present X.509 certificates at the transport layer, AIC-JWT carries the same model over JWT (RFC 7519) and JWS (RFC 7515) as a companion, not a replacement. The outer token is issuer-signed and carries the principal-signed DA JWT in a top-level 'da' claim, preserving AIC's two-layer signature model. Normative content is limited to the X.509-to-JWT mapping, DA representation and key-binding, validation rules, and a thin OAuth 2.0 consumption profile.

Defines the AI Agent Identity Certificate (AIC) extension for X.509 v3 certificates, binding an AI agent's cryptographic identity to a natural person (principal) and providing cryptographic evidence to support attribution of AI-autonomous actions to that principal. It separates cryptographic delegation from authorization semantics, carrying agent identity fields, a principal identifier, capability declarations, authorization-boundary constraints and delegation-authorization evidence with replay protection; a companion PrincipalAuthorization extension anchors principal-side grants and delegation policies. The document specifies the ASN.1 module, OID registration, field semantics, delegation model and extensibility framework, with security considerations for regulated enterprise deployment.

Defines version 2.0 of JSCalendar, a data model and JSON representation of calendar data for storage and exchange in a calendaring and scheduling environment. It obsoletes RFC 8984 (version 1.0), aiming to improve interoperability with existing iCalendar-based systems and aligning its definitions with JSContact, including IANA registry policy, validation requirements and versioning scheme.

A payment between two agents is observed by both the payer's and the payee's systems, yet existing protocols typically record only one party's observation and little about what was delivered. This document defines two-party settlement records carried as Agent Action Capsules, in which payer and payee each seal, under their own key, only what their own system observed. A settlement comprises up to four interlinked leg records referencing each other by digest and joined via typed payment identifiers; settlement state emerges from which legs are present and whether they align, rather than being asserted by any leg. Monetary values use integer-plus-scale rather than floating point, and a registry maps payment reference types to Lightning, x402, AP2 and ISO 20022, aligning states with ISO 20022 status codes.

Defines the KYAPay Token, a JWT carrying verified identity ('Know Your Agent', KYA) and payment (PAY) information for requests made by software agents on behalf of human principals. It explains how security intermediaries, such as bot managers, fraud detection, account-takeover protection and identity platforms, can use the token to confirm that an identified human authorized a particular automated request, shifting the question from 'is this human?' to 'did a verified human authorize this agent?'. It covers token transmission over HTTP, validation (including combination with request signing), and uses in access control, routing, fraud analysis and step-up authentication, while deliberately not prescribing how tokens are created.

Defines a token format for agent identity and payment tokens in JSON Web Token (JWT) format, so that authorization servers and resource servers from different vendors can consume identity and payment tokens in an interoperable manner.

Financial regulations require Anti-Money Laundering (AML) and Countering the Financing of Terrorism (CFT) methods in many jurisdictions worldwide. This specification defines a claim and values for declaring which AML/CFT methods were employed.

Knowing how a person's identity was verified can be important when making trust decisions. This specification defines a claim and values for declaring how the person's identity was verified.

The JWT 'amr' (Authentication Methods References) claim conveys the authentication methods used in an authentication. This specification defines additional Authentication Method Reference values beyond those already registered, to represent further authentication methods in use today.

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

Presents technical evidence that 'early attestation' fails in practice, even without physical access, by analyzing a set of CVEs, EUVD entries and GitHub Security Advisories, including several high-severity issues (two CVEs at CVSS 9.1 and GHSAs rated from 6.3 up to 9.0-10.0). It argues that because continuous attestation is generally required anyway, early attestation only adds unnecessary complexity. Findings are backed by ProVerif formal-analysis artifacts under Apache-2.0. Most early-attestation implementations have been archived or withdrawn; the draft flags Edgeless Systems Contrast and Meta's AI as still vulnerable and urges users to evaluate their systems carefully.