SAIP: Signed Agent Identity Protocol
draft-jovancevic-saip-08
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Srecko Jovancevic | ||
| Last updated | 2026-04-21 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-jovancevic-saip-08
Network Working Group S. Jovancevic
Internet-Draft SKGO, IKT Support
Intended status: Standards Track 20 April 2026
Expires: 20 October 2026
SAIP: Signed Agent Identity Protocol
draft-jovancevic-saip-08
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="<ID>"; alg="<ALG>"; ts="<TS>"; nonce="<NONCE>";
[pk="<PK>"]; [tm="<TM>"]; sig="<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=<id>;ts=<ts>;nonce=<nonce>;method=<METHOD>;path=<path>
Where <METHOD> is uppercase and <path> 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=<id>;ts=<ts>;nonce=<nonce>;phase=EHLO;helo=<helo_name>
6.3. Other Protocols
id=<id>;ts=<ts>;nonce=<nonce>;phase=<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: <n+1>
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: <new>; fallback=<old>;
fallback-expires=<unix_timestamp>
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.<vendor-domain>.
Where <vendor-domain> 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.<domain>. IN TXT "v=saip1; [parameters]"
Defined parameters:
v=saip1 MUST be present. Version indicator.
pk=<key> Base64URL-encoded Ed25519 public key.
Used directly for signature verification.
re=<host> Preferred RE hostname for registry-based lookup.
MAY be used as fallback if pk= verification fails.
asn=<list> Comma-separated authorized ASNs for delegated
infrastructure per [VICDM] Section 6.1.
ip=<prefix> CIDR prefix of authorized delegated infrastructure.
Multiple ip= parameters are permitted.
exp=<ts> 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.<domain> 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="<base64url_rolling_pubkey>";
rcert="<base64_rolling_key_cert>";
sig="<base64_sig_by_rolling_privkey>"
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:
<instance-label>._saip.<vendor-domain>.
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.
10.5.6. MAC-Based Identity Binding (Optional Extension)
This section specifies the MAC identity binding extension defined
conceptually in [VICDM] Section 6.4.7. When implemented, it adds
a hardware identity layer to the DNS-Native trust model.
10.5.6.1. Additional Header Parameters
MAC binding introduces the following optional SAIP header
parameters:
+===========+==========+=========+==============================+
| Param | Type | Required| Description |
+===========+==========+=========+==============================+
| mac | String | MAY | MAC address in |
| | | | XX:XX:XX:XX:XX:XX format. |
| | | | Real or Virtual (V-MAC). |
| | | | MUST be signed via mac_proof.|
+-----------+----------+---------+------------------------------+
| mac_proof | Base64 | MUST if | MAC Attestation Proof. |
| | | mac= | Sign(MasterPrivateKey, |
| | | present | type||mac_bytes||ts||nonce). |
| | | | Proves MAC was attested by |
| | | | MasterKey holder. |
+-----------+----------+---------+------------------------------+
mac= and mac_proof= MUST always appear together. mac= without
mac_proof= MUST be rejected as an unverifiable identity claim
per [VICDM] Class 1.
10.5.6.2. Virtual MAC (V-MAC) Derivation
For agents without a meaningful physical MAC address, a V-MAC
MUST be derived from the MasterPublicKey as follows:
raw = SHA256(MasterPublicKey)[0:6]
v_mac = (raw[0] | 0x02) || raw[1:6]
The LAA bit (bit 1 of octet 0, value 0x02) distinguishes V-MAC
from globally assigned hardware MAC addresses per IEEE 802.
Servers MAY verify V-MAC derivation independently:
(SHA256(MasterPublicKey)[0] | 0x02) == mac[0]
AND SHA256(MasterPublicKey)[1:6] == mac[1:6]
This provides a secondary cryptographic binding between the
V-MAC and the MasterPublicKey without requiring the mac_proof.
10.5.6.3. MAC Attestation Proof Format
The mac_proof= value MUST be computed as:
For Real MAC:
mac_proof = Sign(MasterPrivateKey,
"real" ||
mac_bytes ||
ts ||
nonce)
For V-MAC:
mac_proof = Sign(MasterPrivateKey,
"virtual" ||
mac_bytes ||
ts ||
nonce)
Where:
o "real" and "virtual" are UTF-8 encoded type prefixes
o mac_bytes is the 6-byte MAC in big-endian, no separators
o ts and nonce are the same values as in the SAIP header
o || denotes byte-level concatenation
The inclusion of ts and nonce binds mac_proof to this specific
request, preventing mac_proof replay across different requests.
10.5.6.4. Complete DNS-Native MAC Header Example
; Real MAC (IoT device, TPM-bound key)
SAIP: id="manufacturer.washer.wm-bg-4471";
alg="ed25519";
ts="1744200000";
nonce="7f3k9p2m";
mac="B8:27:EB:4A:3C:11";
mac_proof="<Sign(MasterKey,'real'||mac||ts||nonce)>";
rpk="<RollingPubKey>";
rcert="<RollingKeyCert>";
sig="<RollingKeySig>"
; V-MAC (cloud crawler, software or HSM key)
SAIP: id="acme.crawler.nyc-042";
alg="ed25519";
ts="1744200000";
nonce="a1b2c3d4";
mac="AE:CE:7F:3A:B1:09";
mac_proof="<Sign(MasterKey,'virtual'||mac||ts||nonce)>";
rpk="<RollingPubKey>";
rcert="<RollingKeyCert>";
sig="<RollingKeySig>"
10.5.6.5. Server Verification with MAC Binding
When mac= and mac_proof= are present, servers MUST perform
the following additional verification steps after standard
SAIP verification (Section 9.2):
1. Check DNS record for mac= field:
Verify that the mac= value in the SAIP header matches
the mac= value in the agent's DNS TXT record.
Mismatch MUST result in rejection.
2. Verify mac_proof= using MasterPublicKey:
Reconstruct the signed payload:
type_prefix || mac_bytes || ts || nonce
Verify mac_proof signature with MasterPublicKey.
Failure MUST result in rejection.
3. For V-MAC: optionally verify derivation:
Check SHA256(MasterPublicKey)[0:6] against mac= value
(with LAA bit applied). Mismatch SHOULD be logged.
4. If ip= or asn= present in DNS record:
Compare against request source address.
Mismatch SHOULD trigger trust downgrade and logging
but MAY be accepted under deployment policy.
5. On full triplet verification success:
Classify as Class 3+ (Fully Verified with Hardware
Attestation) per [VICDM] Section 6.4.7.
10.5.6.6. Privacy Considerations for MAC Binding
Real MAC addresses reveal hardware manufacturer information
via the OUI (Organizationally Unique Identifier — first 3
octets). Implementations using Real MAC:
o MUST transmit SAIP headers over TLS [RFC8446] to prevent
MAC disclosure to network observers.
o SHOULD consider whether OUI disclosure is acceptable
under applicable privacy policy.
V-MAC reveals no hardware manufacturer information and is
RECOMMENDED for privacy-sensitive deployments.
MAC binding is OPTIONAL. Agents that do not include mac=
and mac_proof= operate in standard SAIP mode and are not
penalized for absence of MAC binding.
10.6. Agent Letter of Intent (ALOI)
This section implements the ALOI mechanism defined in [VICDM]
Section 6.5. ALOI enables agents to publish a cryptographically
bound behavioral declaration at registration time.
10.6.1. ALOI Header Parameter
When an agent operates under an ALOI declaration, it MUST
include the following parameter in every SAIP header:
+===========+==========+=========+==============================+
| Param | Type | Required| Description |
+===========+==========+=========+==============================+
| aloi-hash | Base64 | MUST if | SHA256 of the canonical ALOI |
| | | ALOI | string from the agent's DNS |
| | | declared| TXT record. Binds this |
| | | | request to the declared ALOI.|
+-----------+----------+---------+------------------------------+
The aloi-hash= MUST be included in the canonical string that
is signed by the Rolling Key:
id=<id>;ts=<ts>;nonce=<nonce>;method=<METHOD>;path=<path>;
aloi-hash=<aloi-hash>
This creates cryptographic proof that the agent is operating
under its declared ALOI for this specific request.
10.6.2. DNS Record Format
ALOI parameters are published in the agent's DNS TXT record
using the "aloi-" prefix. See [VICDM] Section 6.5.4 for
complete examples. A summary of defined parameters:
aloi= Primary intent: crawl, backup, monitor,
api, smtp, iot, sync
aloi-scope= Declared access scope (glob patterns)
aloi-rate= Self-imposed rate limit (e.g., 10/sec)
aloi-exclude= Paths the agent declares it will not access
aloi-ua= Declared User-Agent string
aloi-expires= ALOI expiry timestamp
10.6.3. Server Enforcement
Servers implementing ALOI enforcement MUST:
1. Verify aloi-hash= matches SHA256 of the DNS ALOI record.
Mismatch MUST be treated as a critical violation.
2. Verify request path matches aloi-scope=.
3. Verify request path does not match aloi-exclude=.
4. Verify request rate does not exceed aloi-rate=.
5. Verify User-Agent matches aloi-ua= (if declared).
On violation detection, servers MUST include in the response:
SAIP-Violation: <type>; declared=<val>; attempted=<val>;
penalty=<action>
Defined violation types per [VICDM] Section 6.5.6:
scope-exceeded, exclusion-breach, rate-exceeded,
ua-mismatch, aloi-expired, aloi-hash-mismatch.
10.6.4. Violation Scoring and Sanctions
Servers SHOULD apply progressive sanctions per the model
defined in [VICDM] Section 6.5.7:
1 violation: Warning only (SAIP-Violation header + log)
2-3: Throttle to minimal rate
4-5: Trust downgrade to Class 1
6-10: Block all requests
>10: Report to RE for InstanceID revocation
Violation scores SHOULD decay at -1 point per 24 hours of
fully compliant behavior, allowing agents to recover trust.
10.6.5. Good Faith Self-Reporting
Agents that detect they have unintentionally violated their
ALOI declaration MAY self-report before server detection,
using the Good Faith Mechanism defined in [VICDM] Section 6.5.8.
Self-reporting is performed by including in the next request:
SAIP-Self-Report: violation=<type>;
declared=<declared-value>;
attempted=<attempted-value>;
ts=<timestamp-of-violation>;
self-sig=<Sign(MasterPrivateKey,
type||declared||attempted||
ts||nonce)>
The self-sig= MUST be verifiable using the MasterPublicKey
retrieved from DNS. This proves the self-report is authentic.
Self-reported violations MUST receive reduced penalties per
[VICDM] Section 6.5.8. Agents that consistently self-report
SHOULD receive elevated trust scores, as self-reporting
demonstrates responsible vendor implementation.
This mechanism implements the voluntary disclosure principle:
proactive transparency is rewarded; concealment is penalized.
10.6.6. RE Violation Reporting
Servers MAY report violations to the RE for ecosystem-wide
awareness. The violation report MUST be signed by the server
to prevent fabrication:
POST <re-endpoint>/violation
{
"instance-id": "<agent-id>",
"violation": "<violation-type>",
"declared": "<declared-value>",
"attempted": "<attempted-value>",
"ts": <unix-timestamp>,
"server-sig": "<Sign(ServerKey, report-hash)>"
}
The RE MAY aggregate violation reports from multiple servers
to build a cross-ecosystem behavioral profile of agent instances,
enabling coordinated revocation when patterns of abuse emerge
across multiple independent servers.
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="<base64url_public_key>"; sig="<base64_sig>"
S: (validates signature, timestamp, nonce)
If invalid: 550 5.7.1 SAIP verification failed
If valid: (continue)
C: MAIL FROM:<sender@example.com>
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,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in
RFC 2119 Key Words", BCP 14, RFC 8174,
DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J.
Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106,
RFC 4086, DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.
[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,
<https://www.rfc-editor.org/info/rfc9334>.
[RFC5321] Klenke, J., "Simple Mail Transfer Protocol",
RFC 5321, DOI 10.17487/RFC5321, October 2008,
<https://www.rfc-editor.org/info/rfc5321>.
[RFC1034] Mockapetris, P., "Domain names - concepts and
facilities", STD 13, RFC 1034,
DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035,
DOI 10.17487/RFC1035, November 1987,
<https://www.rfc-editor.org/info/rfc1035>.
[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,
<https://www.rfc-editor.org/info/rfc4033>.
[VICDM] Jovančević, S., "Verifiable Identity Claims and
Delegation Model (VICDM)",
draft-jovancevic-vicdm-04, April 2026,
<https://datatracker.ietf.org/doc/
draft-jovancevic-vicdm/>.
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,
<https://www.rfc-editor.org/info/rfc9421>.
[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,
<https://www.rfc-editor.org/info/rfc6376>.
[RFC7208] Kitterman, S., "Sender Policy Framework (SPF)",
RFC 7208, DOI 10.17487/RFC7208, April 2014,
<https://www.rfc-editor.org/info/rfc7208>.
[RFC7489] Kucherawy, M., Ed., and E. Zwicky, Ed., "DMARC",
RFC 7489, DOI 10.17487/RFC7489, March 2015,
<https://www.rfc-editor.org/info/rfc7489>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS)
Protocol Version 1.3", RFC 8446,
DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization
Framework", RFC 6749, DOI 10.17487/RFC6749,
October 2012,
<https://www.rfc-editor.org/info/rfc6749>.
[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,
<https://www.rfc-editor.org/info/rfc5077>.
[TPM20] Trusted Computing Group, "TPM Library Specification,
Family 2.0", Trusted Computing Group, 2019,
<https://trustedcomputinggroup.org/>.
[SAIP-02] Jovančević, S., "SAIP: Signed Agent Identity
Protocol", draft-jovancevic-saip-04, April 2026,
<https://datatracker.ietf.org/doc/
draft-jovancevic-saip/>.
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=<VendorMasterPubKey>;
re=re1.saip-registry.example"
; Individual agent records (one per bot instance)
agent-nyc-042._saip.yourdomain.com. 300 IN TXT "v=saip1;
pk=<AgentMasterPubKey>"
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<base64url>..."
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="<RollingPubKey>";
rcert="<MasterSig_over_rpk_ts_nonce_method_path>";
sig="<RollingPrivKeySig_over_canonical>"
; 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=<VendorRootPubKey>;
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=<CrawlerPubKey1>"
crawler-us-west-02._saip.bigcorp.com. 300 IN TXT "v=saip1;
pk=<CrawlerPubKey2>"
crawler-eu-de-03._saip.bigcorp.com. 300 IN TXT "v=saip1;
pk=<CrawlerPubKey3>"
; 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=<TPM_Device_PubKey_1>"
wm-ns-1823._saip.manufacturer.com. 300 IN TXT "v=saip1;
pk=<TPM_Device_PubKey_2>"
wm-lj-0392._saip.manufacturer.com. 300 IN TXT "v=saip1;
pk=<TPM_Device_PubKey_3>"
; 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=<RelayPubKey1>;
asn=1234"
relay-de-02._saip.company.com. 300 IN TXT "v=saip1;
pk=<RelayPubKey2>;
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="<RollingPubKey>"; rcert="<cert>"; sig="<sig>"
; S: (verifies via DNS → relay-bg-01._saip.company.com)
; S: (if valid, continues; if invalid, 550 5.7.1)
; C: MAIL FROM:<sender@company.com>
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=<CrawlerMasterPubKey>"
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=<NEW_CrawlerMasterPubKey>"
; 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."
Srecko Jovancevic
SKGO, IKT Support
Makedonska 22
11000 Belgrade
Serbia
Email: srecko.jovancevic@skgo.org
Email: srecko.jovancevic@gmail.com
URI: https://github.com/sreckojovancevic