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-03 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. 11. Registration Entity (RE) Requirements 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-01, 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, . [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-02, 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. Author's Address 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