Network Working Group S. Jovančević Internet-Draft SKGO, IKT Support Intended status: Standards Track 16 April 2026 Expires: 18 October 2026 SAIP: Signed Agent Identity Protocol draft-jovancevic-saip-06 Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 18 October 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Abstract The modern internet lacks a reliable mechanism for verifying the identity of automated software agents. Existing methods such as User-Agent strings and IP-based attribution are insufficient due to spoofing, shared infrastructure (NAT), and the rapid growth of automated agents including AI crawlers, IoT devices, and enterprise automation systems. This document specifies SAIP (Signed Agent Identity Protocol), a lightweight, opt-in mechanism for verifiable client identity at the application layer. SAIP implements the principles defined in the Verifiable Identity Claims and Delegation Model [VICDM] and enables servers to distinguish legitimate automated traffic from malicious actors through cryptographic identity at three levels of granularity: vendor, agent type, and individual instance. SAIP is protocol-agnostic and applicable to HTTP, SMTP, and other header-based protocols. It introduces DNS-based Attestation Discovery as a lightweight alternative to registry-based key lookup, making deployment accessible to organizations of any size. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . 6 4. Design Goals . . . . . . . . . . . . . . . . . . . . . . . 6 5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 7 5.1. Identification vs. Authorization . . . . . . . . . . . 7 5.2. Header Format . . . . . . . . . . . . . . . . . . . . . 7 5.3. Parameters . . . . . . . . . . . . . . . . . . . . . . 8 6. Canonicalization and Signature . . . . . . . . . . . . . . 9 6.1. HTTP Canonical String . . . . . . . . . . . . . . . . . 9 6.2. SMTP Canonical String . . . . . . . . . . . . . . . . . 10 6.3. Other Protocols . . . . . . . . . . . . . . . . . . . . 10 7. Rolling Key Derivation Function (RKDF) . . . . . . . . . . 10 7.1. Key Rotation Model . . . . . . . . . . . . . . . . . . 10 7.2. Sequence Window . . . . . . . . . . . . . . . . . . . . 11 7.3. Renegotiation and Recovery . . . . . . . . . . . . . . 11 7.4. Graceful Key Rotation . . . . . . . . . . . . . . . . . 13 7.5. Forward-Only Constraint . . . . . . . . . . . . . . . . 13 8. Opt-In Telemetry (tm= field) . . . . . . . . . . . . . . . 14 8.1. Commitment-Based Model . . . . . . . . . . . . . . . . 14 8.2. Audit-on-Demand . . . . . . . . . . . . . . . . . . . . 14 8.3. Telemetry Field Registry . . . . . . . . . . . . . . . 15 9. Processing Model . . . . . . . . . . . . . . . . . . . . . 15 9.1. Client Processing . . . . . . . . . . . . . . . . . . . 15 9.2. Server Processing . . . . . . . . . . . . . . . . . . . 16 10. Trust and Attestation Discovery . . . . . . . . . . . . . . . . . . 17 10.1. Stateless Mode (pk=) . . . . . . . . . . . . . . . . . 17 10.2. DNS-Based Attestation Discovery . . . . . . . . . . . . . . . . . . 17 10.3. Registry-Based Discovery . . . . . . . . . . . . . . . 19 10.4. Discovery Priority Order . . . . . . . . . . . . . . . 19 11. Registration Entity (RE) Requirements . . . . . . . . . . . 20 11.1. RE Eligibility . . . . . . . . . . . . . . . . . . . . 20 11.2. RE Governance . . . . . . . . . . . . . . . . . . . . . 21 11.3. Bootstrap and Evolution . . . . . . . . . . . . . . . . 21 12. Granular Policy Model . . . . . . . . . . . . . . . . . . . 22 13. SMTP Integration . . . . . . . . . . . . . . . . . . . . . 23 14. Security Considerations . . . . . . . . . . . . . . . . . . 24 15. Privacy Considerations . . . . . . . . . . . . . . . . . . 26 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . 26 17. References . . . . . . . . . . . . . . . . . . . . . . . . 27 17.1. Normative References . . . . . . . . . . . . . . . . . 27 17.2. Informative References . . . . . . . . . . . . . . . . 28 Appendix A. IoT Use Case . . . . . . . . . . . . . . . . . . . 29 Appendix B. Relationship to Existing Standards . . . . . . . . 30 Appendix C. VICDM Alignment . . . . . . . . . . . . . . . . . 31 Appendix D. DNS Record Examples . . . . . . . . . . . . . . . 32 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 33 1. Introduction The modern internet increasingly relies on automated software agents — AI crawlers, backup systems, IoT devices, monitoring agents, and enterprise integration services — to perform essential functions. However, these agents have no reliable, verifiable way to prove their identity to the servers they communicate with. Current approaches are fundamentally inadequate: o User-Agent strings are trivially spoofable text fields with no cryptographic binding. o IP-based filtering causes collateral damage on shared infrastructure and is ineffective against distributed agents. o Existing authentication frameworks (OAuth2, JWT, mTLS) operate at the session or user level, not the agent instance level. SAIP addresses this gap by introducing a cryptographic identity signal at the application layer — a single header that allows any server to verify the identity of the agent making a request at the level of the individual software instance, without disrupting existing protocol semantics. 1.1. Design Philosophy: The VICDM Principle SAIP is grounded in the Verifiable Identity Claims and Delegation Model [VICDM], which establishes the following core principle: Anonymous interaction is permitted. Identity assertion is permitted. False identity assertion is not. This principle has a critical implication for policy: An agent that asserts an identity it cannot prove is more dangerous than an agent that asserts no identity at all. The former actively corrupts trust signals; the latter is simply anonymous. Systems implementing SAIP SHOULD treat unverifiable identity claims with lower trust than genuine anonymous clients. SAIP is the protocol-layer implementation of this principle: it provides the cryptographic mechanism by which identity assertions become verifiable. 1.2. Relationship to Anonymous Authentication Anonymous bot authentication systems (such as Privacy Pass and related mechanisms under development in the IETF webbotauth working group) allow a bot to prove it is vouched for by a trusted attester without revealing its specific identity. SAIP and anonymous authentication are complementary: o Anonymous authentication addresses the privacy use case. o SAIP addresses the accountability use case. The web needs both. Sites that require per-instance revocation, audit trails, and fleet management need SAIP. Sites whose primary concern is privacy-preserving rate limiting may prefer anonymous attestation. Many deployments will benefit from both. 1.3. Changes from draft-jovancevic-saip-02 This document adds the following relative to -02: o Explicit alignment with [VICDM] principles (Section 1.1) o DNS-based Attestation Discovery (Section 10.2) as a lightweight alternative to RE registry lookup o DNS delegation record format (Section 10.2) o VICDM identity class mapping (Appendix C) o DNS record examples (Appendix D) o Clarified relationship to anonymous authentication (Section 1.2) 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Agent: A software process that makes automated requests on behalf of a vendor or operator. Examples include AI crawlers, backup agents, IoT devices, and monitoring systems. Vendor: The organization or developer responsible for an agent. Holds the Master Key and is registered with a Registration Entity or publishes keys via DNS. Instance: A specific, uniquely identified installation or deployment of an agent. Each instance has its own derived identity and Rolling Key state. Master Key: A long-term cryptographic key held by the vendor, used to derive per-instance Rolling Keys via RKDF. MUST be stored in hardware-backed secure storage where available. Rolling Key: A short-lived cryptographic key derived from the Master Key via RKDF, used to sign exactly one request. MUST be destroyed immediately after use. Registration An organization authorized to maintain and Entity (RE): distribute the public key registry for SAIP vendors. Operates analogously to a Certificate Authority in PKI systems. RKDF: Rolling Key Derivation Function. The mechanism by which Rolling Keys are derived sequentially from the Master Key and sequence state. Sequence: A monotonically increasing integer maintained by both client and server to track Rolling Key state. VICDM: Verifiable Identity Claims and Delegation Model. The conceptual framework [VICDM] that defines the principles this protocol implements. 3. Problem Statement Spoofability: User-Agent strings are trivial to manipulate. Any agent can claim any identity without cryptographic proof. IP Fatigue: IP-based filtering is unreliable for agents operating behind NAT, shared proxies, or cloud infrastructure. Automation Critical systems (backup agents, internal APIs, Friction: AI bots, IoT devices) are frequently blocked by generic security rules that cannot distinguish legitimate automation from malicious traffic. SMTP Trust Gap: Lack of granular client-level identity allows spam and abuse from compromised mail servers. Zero There is no existing mechanism to revoke access Accountability: for a specific software instance without affecting all other instances of the same vendor. False Identity: Under [VICDM], an agent asserting an identity it cannot prove is categorically more harmful than an anonymous agent. Current protocols provide no mechanism to distinguish or penalize false identity claims. 4. Design Goals Simplicity Minimal overhead, single-header implementation. (KISS): No changes to existing protocol semantics. Opt-In: No mandatory adoption. Compatible with legacy systems. Servers that do not implement SAIP MUST ignore the SAIP header without error. Backward SAIP MUST NOT alter the semantics of HTTP, Compatibility: SMTP, or any other protocol. Protocol- Applicable to HTTP, SMTP, and other header- Agnostic: based protocols. Granular Policy decisions MUST be applicable at vendor, Control: agent type, and instance level independently. Identification SAIP is strictly an identification protocol. Only: It MUST NOT be used as an authorization mechanism. Accessible DNS-based Attestation Discovery enables organizations Deployment: of any size to deploy SAIP without RE registration. 5. Protocol Overview 5.1. Identification vs. Authorization SAIP provides a verifiable cryptographic assertion of WHO an agent is. It does not determine what that agent is permitted to do. Authorization remains the exclusive responsibility of existing application-layer mechanisms such as OAuth 2.0 [RFC6749], JWT, or ACLs. Under [VICDM], SAIP clients with successful verification are Class 3 (Fully Verified). See Appendix C for the full mapping. 5.2. Header Format The SAIP header is structured as a semicolon-separated list of parameters transmitted as a standard HTTP header field [RFC9110]: SAIP: id=""; alg=""; ts=""; nonce=""; [pk=""]; [tm=""]; sig="" Each parameter MUST be encoded as a quoted string. The order of parameters is NOT significant for parsing. Parameter names are case-sensitive. 5.3. Parameters +=========+==========+==========+================================+ | Param | Type | Required | Description | +=========+==========+==========+================================+ | id | String | MUST | Agent instance identifier. | | | | | Allowed chars: a-z, 0-9, ., _, | | | | | -. Maximum 128 characters. | | | | | RECOMMENDED format: | | | | | vendor.type.instance | | | | | Where vendor component SHOULD | | | | | correspond to the domain used | | | | | in DNS-based Attestation Discovery. | +---------+----------+----------+--------------------------------+ | alg | String | MUST | Algorithm: "ed25519" or | | | | | "hmac-sha256". Implementations | | | | | MUST support "ed25519". | +---------+----------+----------+--------------------------------+ | ts | Integer | MUST | Unix timestamp at signing. | +---------+----------+----------+--------------------------------+ | nonce | String | MUST | Per-request unique value, | | | | | minimum 8 chars, cryptographic | | | | | randomness per [RFC4086]. | +---------+----------+----------+--------------------------------+ | sig | Base64 | MUST | Signature over canonical string| | | | | per Section 6. | +---------+----------+----------+--------------------------------+ | pk | Base64URL| MAY | Public key for stateless | | | | | verification. | +---------+----------+----------+--------------------------------+ | tm | Base64 | MAY | Opt-in telemetry commitment. | | | | | See Section 8. MUST NOT be | | | | | present unless explicitly | | | | | enabled by deployment policy. | +---------+----------+----------+--------------------------------+ Implementations MUST reject headers missing any MUST parameter. Implementations MUST silently ignore unknown parameters. 6. Canonicalization and Signature 6.1. HTTP Canonical String id=;ts=;nonce=;method=;path= Where is uppercase and includes the query string if present. Example: id=acme.crawler.nyc-042;ts=1744200000;nonce=f3k9p2m1; method=GET;path=/api/v1/data?format=json 6.2. SMTP Canonical String id=;ts=;nonce=;phase=EHLO;helo= 6.3. Other Protocols id=;ts=;nonce=;phase= The canonical string definition for each protocol binding MUST be documented by the implementing software or a future companion specification. 7. Rolling Key Derivation Function (RKDF) 7.1. Key Rotation Model SAIP uses per-request Rolling Key rotation. RollingKey_(n+1) = HMAC-SHA256(MasterKey, InstanceID || Seq_n) Where Seq_n is a big-endian unsigned 64-bit integer. The Rolling Key MUST be used to sign exactly one request and MUST be destroyed immediately after use. The MasterKey SHOULD be stored in hardware-backed secure storage (TPM 2.0, HSM, Apple Secure Enclave, Android StrongBox). 7.2. Sequence Window Servers MUST implement a configurable look-ahead sequence window: o Default window size SHOULD be 5. o Maximum window size MUST NOT exceed 10. o Received sequence numbers within the window cause the server to advance state and invalidate prior sequences. o Sequences outside the window MUST be rejected. Upon successful verification, servers SHOULD respond with: SAIP-Next-Seq: Clients MUST advance sequence state on receipt of this header. On missing response, clients MUST retry with the same Rolling Key. 7.3. Renegotiation and Recovery Full Renegotiation MAY be initiated when a client loses sequence state entirely. Full Renegotiation MUST be authorized exclusively by an RE. Endpoint servers MUST NOT authorize Full Renegotiation. The Full Renegotiation process: 1. Client sends a Renegotiation Request to RE containing: - InstanceID, reason code, timestamp, nonce - Signature using previous MasterKey (valid window: 24 hours from ts value) - Hardware Attestation evidence per [RFC9334] (RECOMMENDED) 2. RE MUST validate: - MasterKey signature valid and within validity window - InstanceID not revoked - Rate limit: maximum 3 renegotiation requests per InstanceID per 24-hour period - Hardware Attestation consistent with registered hardware (if provided) 3. On success, RE issues new RKDF seed and starting Sequence. Previous sequence range is permanently invalidated. 4. Vendor MUST be notified of all Full Renegotiation events. 7.4. Graceful Key Rotation Key transitions use the SAIP-Key-Version header: SAIP-Key-Version: ; fallback=; fallback-expires= o Servers with new key MUST accept new key version. o Servers without new key SHOULD accept fallback until expiry. o After fallback-expires, old key MUST be rejected. 7.5. Forward-Only Constraint Implementations MUST enforce: o Sequence numbers MUST NOT decrease. o Algorithm MUST NOT downgrade during renegotiation. o Full Renegotiation MUST be RE-authorized. o Violations MUST be rejected and logged. 8. Opt-In Telemetry (tm= field) 8.1. Commitment-Based Model The tm= field MUST NOT be transmitted without explicit opt-in. tm = HMAC-SHA256(RollingKey, Metadata_String) Where Metadata_String is a semicolon-separated key=value string. The tm= value is computed using the same RollingKey as sig=. Raw metadata MUST NOT appear in the header. Example: asn=1234;geo=RS;attest=trusted;fw=2.1.4 8.2. Audit-on-Demand Servers SHOULD store tm= in audit logs. During incident response: 1. Operator obtains raw Metadata_String from client or RE log. 2. Verifier recomputes HMAC-SHA256(RollingKey, Metadata_String). 3. Match confirms metadata authenticity. 8.3. Telemetry Field Registry RECOMMENDED standard fields (IANA registry requested): asn Autonomous System Number geo ISO 3166-1 alpha-2 country code attest Hardware attestation status fw Firmware or software version gps Physical coordinates (IoT) api_hash HMAC of associated API credential 9. Processing Model 9.1. Client Processing 1. Construct canonical string per Section 6. 2. Derive current Rolling Key via RKDF (Section 7.1). 3. Sign canonical string using Rolling Key and alg=. 4. If telemetry enabled, compute tm= per Section 8.1. 5. Construct and transmit SAIP header. 6. On receiving SAIP-Next-Seq response: advance Sequence state, destroy used Rolling Key immediately. 7. On missing response: retry with same Rolling Key and Sequence. 9.2. Server Processing 1. Parse SAIP header. Reject if any MUST parameter is absent. 2. Validate ts=. MUST reject if |server_time - ts| > 300 seconds. 3. Validate nonce. SHOULD track nonces within validity window for sensitive endpoints. 4. Obtain public key via discovery order (Section 10.4). 5. Reconstruct canonical string and verify signature using constant-time comparison. 6. On success, include SAIP-Next-Seq in response. 7. Apply policy per Section 12 based on verified identity. 8. If tm= present and audit mode active, store in audit log. 9. Classify client per [VICDM] identity classes: - Verified signature: Class 3 (Fully Verified) - DNS partial match only: Class 2 (Partially Verified) - No SAIP header: Class 0 (Anonymous) - Invalid/unverifiable: Class 1 (treat below Class 0) 10. Trust and Attestation Discovery 10.1. Stateless Mode (pk=) If pk= is present, the server MAY verify immediately without external lookup. Servers SHOULD verify pk= consistency with prior observations for the same id= to detect key substitution attacks. 10.2. DNS-Based Attestation Discovery DNS-based Attestation Discovery allows vendors to publish a verifiable attestation statement — including cryptographic key material, authorized infrastructure, and preferred Registration Entity — using existing DNS infrastructure, without requiring prior RE registration. This mechanism is inspired by the DNS-based key publication patterns established by DKIM [RFC6376] and SPF [RFC7208], and extends them to the agent identity layer. Servers perform a DNS TXT query at: _saip.. Where is derived from the vendor component of the id= parameter (the leftmost label before the first dot). Example: for id="acme.crawler.nyc-042", the server queries: _saip.acme. The DNS TXT record format follows [VICDM] Section 6.2: _saip.. IN TXT "v=saip1; [parameters]" Defined parameters: v=saip1 MUST be present. Version indicator. pk= Base64URL-encoded Ed25519 public key. Used directly for signature verification. re= Preferred RE hostname for registry-based lookup. MAY be used as fallback if pk= verification fails. asn= Comma-separated authorized ASNs for delegated infrastructure per [VICDM] Section 6.1. ip= CIDR prefix of authorized delegated infrastructure. Multiple ip= parameters are permitted. exp= Unix timestamp after which this record SHOULD be considered expired. Servers SHOULD NOT use expired records for verification. Example records: ; Simple public key publication _saip.acme.com. IN TXT "v=saip1; pk=MCowBQYDK2Vd..." ; With preferred RE _saip.acme.com. IN TXT "v=saip1; pk=MCowBQYDK2Vd...; re=re1.saip-registry.example" ; With delegated infrastructure authorization _saip.acme.com. IN TXT "v=saip1; pk=MCowBQYDK2Vd...; asn=13335,15169" DNS-based verification requirements: o Servers MUST validate DNSSEC signatures where available [RFC4033]. o Servers MUST NOT use DNS responses with TTL of 0 for key material. o Servers SHOULD cache DNS key material according to the record TTL. Default TTL SHOULD be 3600 seconds. o If the DNS record contains asn= or ip= parameters, the server SHOULD verify that the client's network source is within the authorized set before accepting the key. o If the DNS record has expired (exp= in the past), the server MUST NOT use the key material for verification and SHOULD treat the request as Class 1 (unverifiable claim) per [VICDM]. 10.3. Registry-Based Discovery The server uses the id= parameter to look up the public key from a distributed RE registry. Implementations MUST support caching of registry responses: minimum TTL 60 seconds, maximum TTL 3600 seconds. 10.4. Discovery Priority Order When multiple discovery methods are available, servers MUST apply them in the following priority order: 1. pk= parameter (stateless, highest priority) 2. DNS-based Attestation Discovery (_saip. TXT record) 3. RE registry lookup (using id=) Servers MAY skip lower-priority methods once a valid key is found. Servers MUST NOT accept a request if no valid key can be found through any available method. Servers MAY skip lower-priority methods once a valid key is found. Servers MUST NOT accept a request if no valid key can be found through any available method. 10.5. DNS-Native Mode with Rolling Key Certification The DNS-Native mode implements the alternative trust model defined in [VICDM] Section 6.4. It replaces the RE registry with the vendor's DNS zone as the identity trust anchor. The DNS-Join trust model rests on three principles: hardware secures the Master Key, DNS publishes it and acts as the trust circuit breaker, and Rolling Keys provide speed and network efficiency. 10.5.1. Additional Header Parameters DNS-Native mode introduces two additional SAIP header parameters: +=========+==========+==========+================================+ | Param | Type | Required | Description | +=========+==========+==========+================================+ | rpk | Base64URL| MUST | Rolling Public Key. A fresh | | | | (DNS- | ephemeral Ed25519 public key | | | | Native | generated per request. | | | | mode) | | +---------+----------+----------+--------------------------------+ | rcert | Base64 | MUST | Rolling Key Certificate. | | | | (DNS- | Signature by MasterPrivateKey | | | | Native | over rpk + instanceID + ts + | | | | mode) | nonce + method + path. | | | | | Binds rpk to exactly one | | | | | request. Non-replayable. | +---------+----------+----------+--------------------------------+ When operating in DNS-Native mode, the sig= parameter MUST be computed using the Rolling Private Key (corresponding to rpk=) rather than an RKDF-derived key. The pk= parameter MUST NOT be present simultaneously with rpk= and rcert=. 10.5.2. DNS-Native Header Example SAIP: id="acme.agent-nyc-042"; alg="ed25519"; ts="1744200000"; nonce="7f3k9p2m"; rpk=""; rcert=""; sig="" 10.5.3. Rolling Key Certificate Format The rcert= value MUST be computed as: rcert = Sign(MasterPrivateKey, rpk || instanceID || ts || nonce || method || path) Where || denotes byte-level concatenation and all string values are UTF-8 encoded. The inclusion of nonce, method, and path binds the rcert= to exactly one request, making replay attacks structurally impossible regardless of the rcert= validity period. 10.5.4. Server Processing for DNS-Native Mode When rpk= and rcert= are present, servers MUST: 1. Extract the vendor domain from the id= parameter (leftmost component before the first dot). 2. Perform DNS TXT lookup at: ._saip.. to retrieve the Master Public Key. Cache per DNS TTL. MUST validate DNSSEC where available [RFC4033]. 3. Verify rcert= using the retrieved Master Public Key. This confirms rpk= is authorized by the Master Key holder for this exact request. 4. Verify sig= using rpk=. This confirms the request was signed by the holder of the corresponding Rolling Private Key. 5. Both verifications MUST succeed. Either failure MUST result in request rejection and SHOULD be logged. 6. Servers MUST NOT cache Master Public Keys beyond the DNS TTL of the source record. 10.5.5. Security Considerations for DNS-Native Mode Replay Protection: rcert= is bound to nonce + ts + method + path. Each rcert= is valid for exactly one request. Replay is structurally impossible. Key Compromise: Compromise of a Rolling Private Key exposes exactly one request. The Master Private Key remains in hardware and is never transmitted. Revocation: Vendor deletes the agent's _saip DNS record. After TTL expiry (RECOMMENDED: 300 seconds), all servers reject the agent's rcert= values. DNS Security: Servers MUST use DNSSEC [RFC4033] where available. _saip record TTL SHOULD be 300 seconds to bound the revocation window. Comparison with TLS: This model provides stronger replay protection than TLS Session Tickets [RFC5077] because rcert= is bound per-request rather than per time-window, while retaining equivalent performance via DNS caching. 11.1. RE Eligibility An organization qualifies as a Registration Entity if it satisfies all of the following: Global Infrastructure: Operates internet-scale infrastructure with sufficient geographic distribution to serve RE queries globally. Operational Track Record: Demonstrated history of reliably operating critical internet infrastructure. Neutrality Commitment: Formal agreement not to discriminate against any vendor, agent type, or competing RE. Community Approval: Majority consensus approval from existing active REs via cryptographically signed statements. An RE MUST maintain query availability of no less than 99.9% on a rolling 30-day basis. An RE MUST propagate revocation events to all peer REs within 300 seconds of issuance. 11.2. RE Governance No single entity controls the set of Registration Entities. A new RE MAY be added when a strict majority of existing active REs approve via signed statements in the RE audit log. An RE MUST be removed if: o Availability requirement fails for more than 72 consecutive hours, OR o Neutrality commitment is violated (majority vote), OR o RE ceases operations voluntarily. All RE membership changes MUST be recorded in a publicly accessible, append-only, verifiable audit log. 11.3. Bootstrap and Evolution The initial RE set is defined in the SAIP RE Bootstrap Registry (IANA, Section 16). The bootstrap set SHOULD include: o Regional Internet Registries (RIPE NCC, ARIN, APNIC, LACNIC, AFRINIC) — non-profit, geographically distributed, operationally neutral by mandate. o Academic and neutral institutions (Internet Society, ICANN, established research universities) — independent, non- commercial representation. o Infrastructure operators meeting Section 11.1 criteria. No single commercial organization category SHALL hold a majority of bootstrap RE positions. Vendors register with any RE of their choice. Servers configure which REs they trust. DNS-based Attestation Discovery (Section 10.2) is available as a zero-registration alternative. 12. Granular Policy Model SAIP enables policy enforcement at three levels independently: Vendor Level: All agents and instances of a given vendor. Agent Type Level: All instances of a specific agent type from a given vendor. Instance Level: Exactly one agent instance (full id= value). Implementations MUST support instance-level revocation without affecting other instances of the same vendor or agent type. Policy actions include: o BLOCK: Reject all requests from the targeted entity. o THROTTLE: Apply rate limits to the targeted entity. o DEGRADE: Reduce trust classification. o ALLOW: Grant priority or elevated rate limits. VICDM identity class mapping (see Appendix C) SHOULD inform the base trust level before granular policy is applied. Informative traffic classification: +===================+==============+=========+==================+ | Agent Category | SAIP Status | Trust | Example Rate | +===================+==============+=========+==================+ | Internal Systems | Verified | High | Unrestricted | +-------------------+--------------+---------+------------------+ | Known Partners | Verified | Medium | 100 req/sec | +-------------------+--------------+---------+------------------+ | General Clients | Verified | Low | 10 req/sec | +-------------------+--------------+---------+------------------+ | Anonymous | None | Minimal | 1 req/sec | +-------------------+--------------+---------+------------------+ | False Claim | Unverifiable | Below | Reject or | | | | Minimal | 0.1 req/sec | +-------------------+--------------+---------+------------------+ 13. SMTP Integration SAIP MAY be applied as an agent identity layer in SMTP [RFC5321] without modifying the SMTP protocol. The sending server MAY transmit a SAIP header line immediately after the server's EHLO response and before MAIL FROM. The SMTP canonical string per Section 6.2 MUST be used. Example exchange: C: EHLO backup-agent.example.com S: 250-mail.example.com Hello backup-agent.example.com 250-SIZE 52428800 250-8BITMIME 250 STARTTLS C: SAIP: id="acme.mailer.relay-bg-01"; alg="ed25519"; ts="1744200000"; nonce="7f3k9p2m"; pk=""; sig="" S: (validates signature, timestamp, nonce) If invalid: 550 5.7.1 SAIP verification failed If valid: (continue) C: MAIL FROM: o Non-implementing receivers MUST treat SAIP line as unrecognized command and continue per [RFC5321]. o Implementing receivers MAY reject with 550 5.7.1 (permanent) or 421 4.7.1 (temporary) based on local policy. o A future SMTP extension advertising SAIP capability in EHLO is RECOMMENDED for strict environments. o SAIP-verified SMTP agents correspond to Class 3 per [VICDM]. Unverifiable SMTP identity claims correspond to Class 1 and SHOULD be treated with lower trust than anonymous senders. 14. Security Considerations 14.1. Timestamp Validation Servers MUST reject requests where |server_time - ts| > 300s. 14.2. Nonce Requirements Nonce MUST be generated via cryptographically secure RNG per [RFC4086]. Servers SHOULD track nonces within the validity window. 14.3. Constant-Time Verification All signature comparisons MUST use constant-time algorithms. 14.4. Key Storage Requirements Master Keys SHOULD be stored in hardware-backed storage: TPM 2.0, Apple Secure Enclave, Android StrongBox, or HSM. Rolling Keys MUST be derived on demand and destroyed after use. 14.5. Compromise Scope Limitation Per-request RKDF limits stolen key value to one in-flight request. Vendors MUST revoke affected InstanceIDs via RE. Revocation MUST propagate to all REs within 300 seconds. 14.6. Header Injection Prevention Restricting id= to a-z, 0-9, '.', '_', '-' prevents header injection and parsing ambiguities. 14.7. Downgrade Attack Prevention Per Section 7.5, renegotiation is strictly forward-only. 14.8. DNS Security DNS-based Attestation Discovery MUST validate DNSSEC [RFC4033] where available. Implementations MUST NOT rely on unauthenticated DNS responses for key material in high-security deployments. DNS cache poisoning could cause a server to accept a spoofed public key. DNSSEC validation and monitoring of unexpected key changes SHOULD be used to mitigate this risk. 14.9. False Identity Claims Under [VICDM], clients asserting identities they cannot verify (Class 1) SHOULD receive lower trust than anonymous clients (Class 0). Implementations SHOULD log Class 1 interactions for audit purposes. 14.10. Remote Attestation Implementations SHOULD provide Remote Attestation evidence per [RFC9334] during Full Renegotiation. Attestation status MAY be committed in tm= (Section 8.3). 15. Privacy Considerations The id= parameter discloses vendor and instance identity to servers and network observers. Connections carrying SAIP headers SHOULD use TLS [RFC8446] or equivalent transport encryption. DNS-based Attestation Discovery (Section 10.2) causes the server to make a DNS query for the vendor's domain, which may be observable. Implementations in sensitive deployments SHOULD use stateless mode (pk=) or RE-based discovery to avoid DNS-observable lookups. The tm= field MUST NOT be transmitted without explicit opt-in. SAIP does not provide anonymity. Agents requiring anonymity SHOULD use anonymous attestation mechanisms instead. 16. IANA Considerations This document requests IANA to register the following HTTP header fields in the "Permanent Message Header Field Names" registry [RFC9110]: SAIP (defined in Section 5.2) SAIP-Next-Seq (defined in Section 7.2) SAIP-Key-Version (defined in Section 7.4) This document requests IANA to create the following registries: SAIP RE Bootstrap Registry Registration policy: Expert Review Initial contents: To be determined through IETF consensus. SAIP Telemetry Field Names Registration policy: Specification Required Initial contents: asn, geo, attest, fw, gps, api_hash (Section 8.3) This document requests IANA to update the following registry created by [VICDM]: VICDM DNS Delegation Record Parameters Add parameter: re (defined in Section 10.2 of this document) 17. References 17.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, . [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, . [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, . [RFC5321] Klenke, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, . [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, . [VICDM] Jovančević, S., "Verifiable Identity Claims and Delegation Model (VICDM)", draft-jovancevic-vicdm-02, April 2026, . 17.2. Informative References [RFC9421] Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP Message Signatures", RFC 9421, DOI 10.17487/RFC9421, February 2024, . [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, DOI 10.17487/RFC6376, September 2011, . [RFC7208] Kitterman, S., "Sender Policy Framework (SPF)", RFC 7208, DOI 10.17487/RFC7208, April 2014, . [RFC7489] Kucherawy, M., Ed., and E. Zwicky, Ed., "DMARC", RFC 7489, DOI 10.17487/RFC7489, March 2015, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, DOI 10.17487/RFC5077, January 2008, . [TPM20] Trusted Computing Group, "TPM Library Specification, Family 2.0", Trusted Computing Group, 2019, . [SAIP-02] Jovančević, S., "SAIP: Signed Agent Identity Protocol", draft-jovancevic-saip-04, April 2026, . Appendix A. IoT Use Case (Informative) SAIP is particularly well-suited for IoT deployments: Vendor: Manufacturer (registered at RE or via DNS, holds Master Key) Agent Type: Product line (e.g., washing machines) Instance: Individual device (identity bound to on-device TPM) DNS-based Attestation Discovery simplifies IoT deployment significantly: the manufacturer publishes _saip.manufacturer.com TXT record once, and all devices are immediately verifiable by any server without RE registration. The manufacturer's cloud service verifies device identity cryptographically; compromised devices are revoked at the instance level without fleet disruption. Per [VICDM], verified IoT devices are Class 3. Counterfeit devices without TPM access fall to Class 1 and receive lower trust than anonymous devices — removing the incentive to impersonate legitimate products. Appendix B. Relationship to Existing Standards (Informative) B.1. RFC 9421 (HTTP Message Signatures) RFC 9421 signs message content (WHAT). SAIP signs agent identity (WHO). Complementary, not competing. B.2. DKIM (RFC 6376) DKIM signs email messages at domain level. SAIP signs agents at instance level. The DNS TXT record pattern in Section 10.2 is directly inspired by DKIM's use of DNS for key publication. B.3. SPF (RFC 7208) SPF authorizes IP addresses to send mail for a domain using DNS TXT records. SAIP's DNS asn= and ip= delegation parameters in Section 10.2 serve an analogous purpose for agent identity. B.4. RATS (RFC 9334) SAIP's hardware attestation requirements (Section 14.10) and the tm= attestation field (Section 8.3) are compatible with RATS attestation evidence formats. Appendix C. VICDM Alignment (Informative) This appendix maps SAIP verification outcomes to VICDM identity classes [VICDM]. +=========+========================+=========+==================+ | VICDM | SAIP Condition | Trust | Notes | | Class | | Level | | +=========+========================+=========+==================+ | Class 3 | Valid signature via | High | Full SAIP | | | pk=, DNS, or RE | | verification | +---------+------------------------+---------+------------------+ | Class 2 | DNS record exists but | Medium | Partial: domain | | | no valid signature | | identity only | +---------+------------------------+---------+------------------+ | Class 0 | No SAIP header present | Low | Anonymous; | | | | | apply default | | | | | policy | +---------+------------------------+---------+------------------+ | Class 1 | SAIP header present | Below | False claim; | | | but unverifiable or | Class 0 | log; apply lower | | | signature invalid | | trust than anon | +---------+------------------------+---------+------------------+ The Class 1 row is operationally significant: an agent that presents an invalid or unverifiable SAIP header MUST receive lower trust than one that presents no SAIP header at all. This removes the incentive to make false identity claims. Appendix D. DNS Record Examples (Informative) D.1. Minimal deployment (public key only) _saip.example.com. 3600 IN TXT "v=saip1; pk=MCowBQYDK2VdAyEA..." D.2. With preferred RE fallback _saip.example.com. 3600 IN TXT "v=saip1; pk=MCowBQYDK2VdAyEA...; re=re1.saip-registry.example" D.3. CDN delegation by ASN (no pk, RE-based) _saip.example.com. 3600 IN TXT "v=saip1; asn=13335,15169; re=re1.saip-registry.example" D.4. Full record with expiry _saip.example.com. 3600 IN TXT "v=saip1; pk=MCowBQYDK2VdAyEA...; re=re1.saip-registry.example; asn=13335; exp=1767225600" D.5. IoT manufacturer (devices have hardware-bound keys) _saip.gorenje.com. 3600 IN TXT "v=saip1; re=re1.saip-registry.example" In this case the pk= is not in DNS — each device instance has its own TPM-bound key registered directly at the RE under the vendor's registration. DNS provides the RE discovery pointer. In this case the pk= is not in DNS — each device instance has its own TPM-bound key registered directly at the RE under the vendor's registration. DNS provides the RE discovery pointer. Appendix E. Operational Guide — DNS-Join How-To (Informative) This appendix provides practical guidance for administrators deploying SAIP in DNS-Native mode. All examples are illustrative. Production deployments MUST follow the security requirements defined in Sections 10.5 and 14. E.1. Prerequisites Before deploying SAIP DNS-Native mode, the following are required: o Authoritative DNS control over your domain (ability to create TXT records and delegate subdomains). o A hardware security module or equivalent for Master Key generation and storage. See Section E.2 for options. o DNSSEC enabled on your zone (RECOMMENDED, see Section 14.8). o DNS TTL set to 300 seconds for all _saip records (RECOMMENDED to minimize revocation window, see Section 10.5.4). The non-negotiable security requirement across all deployment options is: The Master Private Key MUST NOT be exportable from the hardware module in which it was generated. Any hardware or software configuration that does not enforce this property MUST NOT be used in production deployments. E.2. Key Generation E.2.1. Software — Development and Testing Only WARNING: Software-generated keys are stored on disk and are exportable. This method MUST NOT be used in production. It is provided only for development and testing purposes. Using OpenSSL (all platforms): # Generate Ed25519 Master keypair openssl genpkey -algorithm ed25519 -out master.key # Extract public key openssl pkey -in master.key -pubout -out master.pub # Base64URL encode for DNS TXT record openssl pkey -in master.key -pubout -outform DER | \ tail -c 32 | base64 | tr '+/' '-_' | tr -d '=' The output of the last command is the pk= value for the DNS TXT record. E.2.2. Hardware-Backed — Production Recommended All production deployments SHOULD use hardware-backed key generation where the Master Private Key is generated inside the hardware module and marked non-exportable at creation time. PKCS#11 is the standard interface supported by most hardware modules and is compatible with OpenSSL via provider/engine: # Install OpenSSL PKCS#11 provider (Linux example) apt install libpkcs11-provider # or distro equivalent # Generate non-exportable Ed25519 key inside hardware module openssl genpkey \ -provider pkcs11 \ -algorithm ed25519 \ -pkeyopt "pkcs11-uri:pkcs11:token=SAIP-Master;object=saip-key" \ -pkeyopt "non-exportable:true" # Extract public key (private key never leaves hardware) openssl pkey \ -provider pkcs11 \ -in "pkcs11:token=SAIP-Master;object=saip-key" \ -pubout -out master.pub E.2.3. Linux — TPM 2.0 (tpm2-tools) TPM 2.0 is available on most modern Linux servers and embedded devices. The tpm2-tools suite provides direct TPM access: # Create primary key context in TPM tpm2_createprimary -C e -g sha256 -G ecc -c primary.ctx # Create non-exportable Ed25519-equivalent key under primary tpm2_create -C primary.ctx -G ecc256 -u saip.pub -r saip.priv \ --attributes "fixedtpm|fixedparent|sensitivedataorigin|\ userwithauth|sign|noda" # Load key into TPM tpm2_load -C primary.ctx -u saip.pub -r saip.priv -c saip.ctx # Extract public key in PEM format via tpm2-pkcs11 tpm2_ptool addkey --algorithm=ecc256 --label=saip-master openssl pkey -provider tpm2 -in "handle:saip-master" -pubout Note: The "--attributes fixedtpm|fixedparent" flags ensure the key is permanently bound to this TPM and cannot be exported. E.2.4. Windows — CNG and TPM Windows exposes TPM functionality through the Cryptography API: Next Generation (CNG). PowerShell example: # Generate non-exportable key in TPM via CNG $key = [System.Security.Cryptography.ECDsa]::Create( [System.Security.Cryptography.ECCurve]::NamedCurves.nistP256 ) # Store in TPM-backed key storage provider $cngParams = New-Object ` System.Security.Cryptography.CngKeyCreationParameters $cngParams.Provider = [System.Security.Cryptography.CngProvider]:: MicrosoftPlatformCryptographyProvider # TPM provider $cngParams.ExportPolicy = ` [System.Security.Cryptography.CngExportPolicies]::None # Non-exportable $cngKey = [System.Security.Cryptography.CngKey]::Create( [System.Security.Cryptography.CngAlgorithm]::ECDiffieHellmanP256, "saip-master-key", $cngParams ) The ExportPolicies::None flag enforces non-exportability at the CNG level, which is enforced by the TPM hardware. E.2.5. macOS and iOS — Secure Enclave Apple platforms expose the Secure Enclave via the Security framework. Example using the security command-line tool: # Generate non-exportable key in Secure Enclave security create-keypair \ -a ec \ -s 256 \ -k saip-master \ -T /usr/bin/security \ -x # non-extractable flag For programmatic access, use SecKeyCreateRandomKey with kSecAttrTokenIDSecureEnclave and kSecAttrIsPermanent set to true, and kSecAttrIsExtractable set to false. E.2.6. Embedded and RTOS Environments For IoT and embedded deployments (QNX, FreeRTOS, Zephyr, and similar): wolfTPM (C library, platform-agnostic): /* Generate non-exportable ECC key in TPM */ WOLFTPM2_KEY masterKey; wolfTPM2_GetKeyTemplate_ECC(&publicTemplate, &sensitiveTemplate, TPM_ECC_NIST_P256, TPM_ALG_ECDSA); /* Set fixedTPM and fixedParent to prevent export */ publicTemplate.objectAttributes |= TPMA_OBJECT_FIXEDTPM; publicTemplate.objectAttributes |= TPMA_OBJECT_FIXEDPARENT; wolfTPM2_CreateKey(&dev, &masterKey, &parent, &publicTemplate, &sensitiveTemplate); Mbed TLS + PSA Crypto API (ARM TrustZone): /* Generate key with no export permission */ psa_key_attributes_t attrs = PSA_KEY_ATTRIBUTES_INIT; psa_set_key_algorithm(&attrs, PSA_ALG_ECDSA(PSA_ALG_SHA_256)); psa_set_key_type(&attrs, PSA_KEY_TYPE_ECC_KEY_PAIR( PSA_ECC_FAMILY_SECP_R1)); psa_set_key_bits(&attrs, 256); psa_set_key_usage_flags(&attrs, PSA_KEY_USAGE_SIGN_HASH); /* PSA_KEY_USAGE_EXPORT intentionally omitted */ psa_generate_key(&attrs, &key_id); E.2.7. Cloud HSM Cloud HSM services expose the same PKCS#11 interface and are suitable for cloud-native agent deployments: AWS CloudHSM: Use cloudhsm_mgmt_util or PKCS#11 SDK. Set CKA_EXTRACTABLE=false at key creation. Compatible with OpenSSL via the CloudHSM PKCS#11 provider. Azure Dedicated HSM / Azure Key Vault Managed HSM: Use az keyvault key create --protection hsm Keys created with HSM protection are non-exportable by policy. Google Cloud HSM (via Cloud KMS): Use gcloud kms keys create --protection-level hsm Private key material never leaves Google HSM boundary. All cloud HSM providers enforce non-exportability at the hardware level. The PKCS#11 interface is consistent across providers, enabling portable SAIP agent implementations. E.3. DNS Record Publishing E.3.1. Zone Structure The recommended DNS zone structure for SAIP is: ; Delegate _saip subdomain to allow bot self-registration _saip.yourdomain.com. IN NS ns1.yourdomain.com. ; Vendor root attestation record _saip.yourdomain.com. 300 IN TXT "v=saip1; pk=; re=re1.saip-registry.example" ; Individual agent records (one per bot instance) agent-nyc-042._saip.yourdomain.com. 300 IN TXT "v=saip1; pk=" The 300-second TTL is RECOMMENDED for all _saip records to bound the revocation window to 5 minutes. E.3.2. Record Verification After publishing, verify with standard DNS tools: # Verify vendor root record dig TXT _saip.yourdomain.com +short # Verify individual agent record dig TXT agent-nyc-042._saip.yourdomain.com +short # Verify DNSSEC (recommended) dig TXT _saip.yourdomain.com +dnssec Expected output format: "v=saip1; pk=MCowBQYDK2VdAyEA..." E.4. Complete Deployment Examples E.4.1. Small Vendor — Stateless Deployment Suitable for: small teams, internal tools, development. No RE registration required. ; DNS records _saip.smallvendor.com. 300 IN TXT "v=saip1; pk=MCowBQYDK2VdAyEAx..." backup-agent-01._saip.smallvendor.com. 300 IN TXT "v=saip1; pk=MCowBQYDK2VdAyEAy..." ; SAIP header sent by backup-agent-01 SAIP: id="smallvendor.backup.agent-01"; alg="ed25519"; ts="1744200000"; nonce="a1b2c3d4e5f6g7h8"; rpk=""; rcert=""; sig="" ; Server verification steps: ; 1. DNS lookup: agent-01._saip.smallvendor.com → MasterPubKey ; 2. Verify rcert with MasterPubKey ✓ ; 3. Verify sig with rpk ✓ ; 4. Accept request as Class 3 (Fully Verified) per [VICDM] E.4.2. Enterprise Fleet — AI Crawler Suitable for: large-scale crawler fleets, CDN-delivered agents. ; Zone delegation for self-registration _saip.bigcorp.com. 300 IN NS ns1.bigcorp.com. ; Vendor root with RE pointer _saip.bigcorp.com. 300 IN TXT "v=saip1; pk=; re=re1.saip-registry.example; asn=64496" ; Crawler fleet (each bot registers its own record) crawler-us-east-01._saip.bigcorp.com. 300 IN TXT "v=saip1; pk=" crawler-us-west-02._saip.bigcorp.com. 300 IN TXT "v=saip1; pk=" crawler-eu-de-03._saip.bigcorp.com. 300 IN TXT "v=saip1; pk=" ; Revoke single misbehaving crawler: ; Delete crawler-us-east-01._saip.bigcorp.com TXT record ; After 300s TTL expiry → all servers reject its rcert values ; Other crawlers unaffected ← surgical precision E.4.3. IoT Fleet — Home Appliances Suitable for: device manufacturers, embedded systems, IoT. ; Manufacturer root — RE handles per-device registry _saip.manufacturer.com. 300 IN TXT "v=saip1; re=re1.saip-registry.example" ; Individual devices with TPM-bound keys ; (published by device during factory provisioning or first boot) wm-bg-4471._saip.manufacturer.com. 300 IN TXT "v=saip1; pk=" wm-ns-1823._saip.manufacturer.com. 300 IN TXT "v=saip1; pk=" wm-lj-0392._saip.manufacturer.com. 300 IN TXT "v=saip1; pk=" ; Firmware compromise scenario: ; Batch wm-bg-4471 through wm-bg-4999 affected ; Manufacturer deletes their DNS records ; After 300s → fleet protected, unaffected devices continue ; No service interruption for wm-ns-* or wm-lj-* devices E.4.4. SMTP Mail Relay Suitable for: mail infrastructure, anti-spam enforcement. ; Mail relay agent records relay-bg-01._saip.company.com. 300 IN TXT "v=saip1; pk=; asn=1234" relay-de-02._saip.company.com. 300 IN TXT "v=saip1; pk=; asn=5678" ; SMTP exchange (see Section 13 for full protocol detail) ; C: EHLO relay-bg-01.company.com ; S: 250-mail.recipient.com Hello ... ; C: SAIP: id="company.relay.relay-bg-01"; alg="ed25519"; ; ts="1744200000"; nonce="x9y8z7w6"; ; rpk=""; rcert=""; sig="" ; S: (verifies via DNS → relay-bg-01._saip.company.com) ; S: (if valid, continues; if invalid, 550 5.7.1) ; C: MAIL FROM: E.5. Revocation Procedures E.5.1. Single Agent Revocation To revoke one agent immediately: 1. Delete the agent's _saip DNS TXT record: ; Remove from zone file or DNS management API ; DELETE agent-nyc-042._saip.yourdomain.com TXT 2. Lower TTL to 0 or minimum supported value before deletion to accelerate propagation (if DNS provider supports it). 3. After TTL expiry (default 300s), all servers will return NXDOMAIN for this agent's DNS lookup. rcert= verification will fail as no Master Public Key can be retrieved. 4. Log the revocation event for audit purposes. E.5.2. Full Fleet Revocation To revoke all agents of a vendor immediately: 1. Rotate the vendor's Master Public Key at the zone apex: ; Update _saip.yourdomain.com TXT with new pk= ; Old pk= is immediately invalid for new rcert verification 2. Or remove the _saip subdomain delegation entirely. 3. All outstanding rcert= values signed by the old Master Private Key become unverifiable immediately upon DNS TTL expiry. E.5.3. Emergency Revocation For immediate revocation without waiting for DNS TTL: o Notify RE (if registered) to add InstanceID to revocation list. RE-aware servers will check revocation independently of DNS TTL. o Use Anycast DNS or DNS NOTIFY to accelerate propagation to authoritative servers. o For critical infrastructure: pre-negotiate with major RE operators to maintain an emergency revocation channel. E.6. Common Mistakes and How to Avoid Them MISTAKE 1: Exportable Master Key Wrong: openssl genpkey -algorithm ed25519 -out master.key (key stored on disk, exportable) Right: Use PKCS#11 provider with non-exportable flag, TPM with fixedTPM|fixedParent attributes, or equivalent hardware enforcement. Impact: Attacker with filesystem access can clone the entire agent identity permanently. MISTAKE 2: TTL too high Wrong: _saip.example.com. 86400 IN TXT "v=saip1; pk=..." (24 hour TTL) Right: _saip.example.com. 300 IN TXT "v=saip1; pk=..." (5 minute TTL) Impact: Revocation takes up to 24 hours to propagate. Compromised agent continues operating. MISTAKE 3: No DNSSEC Wrong: Publishing _saip records without DNSSEC enabled. Right: Enable DNSSEC on the zone and validate at server. Impact: DNS cache poisoning can substitute attacker's public key, allowing impersonation. MISTAKE 4: Reusing nonce in rcert Wrong: Using timestamp alone as nonce (ts= only). Right: Generate cryptographically random nonce per request per [RFC4086], minimum 8 bytes. Impact: rcert becomes replayable within the ts= window. MISTAKE 5: Caching Master Key beyond DNS TTL Wrong: Caching MasterPublicKey for 24 hours regardless of DNS record TTL. Right: Cache MUST expire at DNS record TTL. Servers MUST re-query DNS after TTL expiry. Impact: Revoked agents continue to be accepted by servers that cache beyond TTL. E.7. Attack Scenario: The Great Impersonation Kill-Switch This scenario demonstrates Dynamic Delegation — the core operational advantage of DNS-Native SAIP over static certificate models. It illustrates what happens when an agent identity is compromised, and how the DNS trust anchor enables surgical, near-instant response. E.7.1. Background: Static vs. Dynamic Delegation Traditional PKI uses static delegation: Vendor → CA issues cert → cert valid for 1 year Attacker compromises key → attacker has 1 year of validity Revocation (CRL/OCSP) → complex, slow, often ignored SAIP DNS-Native uses dynamic delegation: Vendor → DNS publishes MasterPublicKey → TTL: 300 seconds Attacker compromises key → attacker has at most 300 seconds Revocation → delete DNS record → done The DNS record is not a static artifact. It is a live trust anchor that the vendor controls in real time. This is Dynamic Delegation in its purest form. E.7.2. Scenario Setup Consider the following deployment: Vendor: BigCorp, running an AI crawler fleet Agent: crawler-us-east-01._saip.bigcorp.com Key type: SOFTWARE-based Master Key (not TPM-backed) ← This is the vulnerability. See E.7.5. The agent's DNS record: crawler-us-east-01._saip.bigcorp.com. 300 IN TXT "v=saip1; pk=" The attacker gains read access to the agent's filesystem and extracts the Master Private Key. Because the key was stored in software (not hardware), it is exportable. With the Master Private Key, the attacker can: o Generate valid rcert= values for any request o Sign requests that appear to originate from the legitimate crawler-us-east-01 instance o Bypass rate limits and access controls granted to this agent E.7.3. Attack Timeline T+0:00 Attacker extracts MasterPrivateKey from filesystem. Begins generating valid SAIP headers impersonating crawler-us-east-01. T+0:00 Attacker's requests are accepted by all servers. Each rcert= is valid — signed by the real Master Key. No cryptographic alarm exists yet. T+5:00 BigCorp monitoring detects anomaly: crawler-us-east-01 appears to be making requests simultaneously from two geographically distant ASNs. Volumetric spike detected from unexpected IP ranges. T+5:30 Security team confirms: agent identity is compromised. Decision: activate Kill-Switch. T+6:00 Admin executes DNS rotation — one operation: ; Option A: Rotate to new Master Key crawler-us-east-01._saip.bigcorp.com. 300 IN TXT "v=saip1; pk=" ; Option B: Delete record entirely (full revocation) ; DELETE crawler-us-east-01._saip.bigcorp.com TXT T+6:00 DNS propagation begins. Authoritative servers immediately serve the updated/deleted record. T+11:00 DNS TTL expires on all caching resolvers (300s). Every server that queries DNS now receives either: - The new MasterPublicKey (Option A), or - NXDOMAIN (Option B). T+11:00 Attacker's rcert= values, signed by the old MasterPrivateKey, fail verification everywhere. The stolen key is cryptographically worthless. Chain of Trust is severed. T+11:00 If Option A: the legitimate crawler-us-east-01 (re-keyed with new Master Key) resumes normal operation immediately. Other crawlers in the fleet: unaffected throughout. T+11:00 KILL-SWITCH COMPLETE. Total response time: ~11 minutes from detection to full ecosystem protection. E.7.4. Why This Works — Dynamic Delegation The Kill-Switch works because of three properties acting together: Property 1 — DNS as Live Trust Anchor: The MasterPublicKey in DNS is not a static artifact. It is a live signal that every verifying server re-checks on every TTL expiry. The moment the signal changes, the entire ecosystem adapts — automatically, without coordination, without notifying individual servers. Property 2 — Short TTL as Security Parameter: The 300-second TTL is not a performance tuning parameter. It is a security parameter that bounds the maximum window during which a compromised key remains valid after revocation. Administrators SHOULD treat TTL as a security control and set it accordingly. Property 3 — Per-Request rcert Binding: Even before the DNS TTL expires, the attacker faces a structural limitation: each rcert= is bound to one specific nonce + ts + method + path combination and cannot be reused. The attacker must continuously generate new rcert= values — which requires the MasterPrivateKey — which they have. But after DNS rotation, those new rcert= values reference a MasterPublicKey that no longer exists in DNS. The Chain of Trust is broken at the root. The combination of these three properties creates a revocation mechanism that is: o Faster than CRL or OCSP in practice o Simpler to operate (one DNS record change) o Globally consistent (DNS propagation is the distribution mechanism — no separate revocation infrastructure needed) o Surgical (only the compromised instance is affected) E.7.5. Lessons Learned — The Role of Hardware This scenario began with one mistake: the Master Private Key was stored in software, making it exportable. Had the key been generated in a hardware module (TPM, HSM, Secure Enclave), the scenario would not have occurred: Attacker gains filesystem access: Software key → EXPORTED. Attack proceeds. TPM-bound key → NOT EXPORTABLE. Attack fails at step 1. The DNS Kill-Switch is a powerful recovery mechanism. But hardware-bound keys are the prevention mechanism that makes the Kill-Switch rarely necessary. The two-layer defense: Layer 1 (Prevention): Hardware-bound MasterPrivateKey. Attacker cannot export the key even with full filesystem access. Layer 2 (Recovery): DNS Dynamic Delegation Kill-Switch. If Layer 1 fails (physical access, supply chain compromise, insider threat), Layer 2 contains the damage in 300s. This is defense in depth applied to agent identity: "Hardware makes the Kill-Switch unnecessary. DNS makes the Kill-Switch sufficient." Srećko Jovančević SKGO, IKT Support Makedonska 22 11000 Belgrade Serbia Email: srecko.jovancevic@skgo.org Email: srecko.jovancevic@gmail.com URI: https://github.com/sreckojovancevic