]> Huawei

niyuan1@huawei.com

Huawei

liuchunchi@huawei.com

next generation unicorn sparkling distributed ledger This document defines a new DNS resource record type, Agent Entity Discovery (AED), to publish agent-specific trust anchors or direct match constraints for verifying an agent's certificate or token. This enables the cross-domain users or agents to authenticate, and establish secure, end-to-end connections directly with a private-domain agent entity. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction AI agents are evolving from isolated, single-domain components into collaborative entities interacting across domain boundaries. This shift requires agent-specific credential associations, such as private-domain trust anchors, to be securely exchanged or published for cross-domain authentication. For instance, SPIFFE Federation allows disparate domains to securely exchange their trust bundles via the bundle endpoint, enabling agents to cryptographically verify other agents' credentials. However, such a federation relies on out-of-band pre-configuration between participating organizations, and is therefore not suitable for dynamic, internet-scale discovery and authentication. Conversely, existing internet-scale mechanisms such as DNSSEC and DANE only secure identities at the domain level. Consequently, a client cannot differentiate among multiple agents that are served from the same domain name, leading to risks of impersonation and lateral movement. To bridge this gap, this document introduces a mechanism that re-anchors trust at the agent entity level rather than at the domain name level. By extending DNS Resource Records (RRs) to publish agent-specific credential associations, a cross-domain client can retrieve these records during the discovery phase and establish an end-to-end connection directly to the target AI agent, rather than the domain name that hosts it. The credential association defined in this mechanism provides two functions, inheriting the definition of certificate associations of : it functions either as a credential trust anchor used to cryptographically verify the signature of an agent's presented credential (either via certification path validation or JWT signature verification), or as a credential constraint used to perform a direct match against the agent's credential.

Conventions and 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 when, and only when, they appear in all capitals, as shown here.

Workflow This section outlines the workflow for establishing a secure, end-to-end connection directly with a private-domain agent entity (see Figure 1). A private-domain administrator (e.g. a private-domain identity server) publishes agent-specific AED (Agent Entity Discovery) RRs to the DNS server. Then, a client can query and parse these records, and use the retrieved credential associations to verify the target agent during the connection. | | | | | | | | Answer AED | | | |<--------------| | | | | | | |3.TLS handshake| | | |<------------------------------> | | (Validate X.509/RPK/PSK etc.)| | | | | | |4.Application credential validation (Optional) | |<------------------------------- | | | | | | | | | ]]> Figure 1: Workflow of Agent Entity-Level Discovery and End-to-End Connection

1. Registration: The private-domain administrator constructs a dedicated QNAME (as defined in ) for the internal agent and publishes its AED RRs (as defined in ) to the DNS server.
2. Discovery: A client sends a DNS query for the agent's specific QNAME with the AED QTYPE, and extracts the agent's credential associations from the recevied AED RRs. The client also obtains the agent's network location (IP address and port) via A/AAAA or SRV RRs. Subsequent TLS handshake messages SHOULD be sent to this obtained address.
3. Connection: The client initiates a direct TLS connection to the agent. During the handshake, the client validates the credential presented by the agent against the credential associations.
4. Application credential validation (Optional): If additional application-layer authentication is required inside the secure tunnel, the agent presents an application-layer token, then the client utilizes the credential associations from the AED RR to verify the token signature.

Domain Names for AED RR The QNAME for an AED RR is constructed by prepending the agent identifier (agent_id) as the left-most label to the base domain name, as shown below: . ]]> Figure 2: Domain Names for AED For example, to request AED RRs for an AI agent identified as "agent-007" hosted at "www.example.com", the QNAME "agent-007.www.example.com" is used. To maintain flexibility, the internal structure and generation mechanism of the "agent_id" label are left open to deployment-specific choices or future specifications. However, any abstract identifier used MUST be mapped to a valid DNS label. Examples of such identifiers MAY include:

• a WIMSE workload identifier;
• a W3C DID;
• an encoded application-layer path component, etc.

The AED RR This section defines a new DNS RR type: AED, which is used to associate a set of trust anchors or credential constraints with a specific AI agent entity, thus enabling a client to authenticate that AI agent.

AED RDATA Wire Format The RDATA for an AED RR consists of a one-octet Usage field, a one-octet Selector field, a one-octet Matching Type field, and a variable-length Credential Association Data field. Figure 3: AED RDATA Wire Format

The Usage Field A one-octet value, called "usage", specifies how the association data is to be used for agent authentication. The usages defined in this document are: 0 -- Certificate Trust Anchor: Usage 0 is used to specify a certificate or public key that MUST serve as a domain-specific trust anchor for TLS certification path validation of the presented agent certificate during the TLS handshake. 1 -- JWT Trust Anchor: Usage 1 is used to specify a JSON Web Key (JWK) that MUST serve as a domain-specific trust anchor to verify the signature of an application-layer JSON Web Token (JWT) presented by the agent inside the tunnel. 2 -- Certificate Constraint: Usage 2 is used to specify a certificate or the public key that MUST directly match the certificate presented by the agent during the TLS handshake. 3 -- JWT Constraint: Usage 3 is used to specify a JWT that MUST directly match the JWT presented by the agent inside the tunnel. 4 -- RPK Constraint: Usage 4 is used to specify a raw public key (RPK) that MUST directly match the RPK presented by the agent during a TLS handshake and be used to verify the agent's possession of the private key via the CertificateVerify signature. 5 -- PSK Constraint: Usage 5 is used to specify a pre-shared key (PSK) identity. The PSK MUST be pre-established out-of-band and stored securely by both the client and the agent so that the client can use the PSK identity to select the correct key during a TLS-PSK handshake . The record MUST contain only the identity string, never the secret key material.

The Selector Field A one-octet value, called "selector", specifies which part of the trust anchor or credential is contained in the credential association data. The selectors defined in this document are: 0 -- Full credential: The full binary or textual structure of the credential or trust anchor.

• For X.509 certificates (usages 0 and 2): The DER-encoded binary structure of the full X.509 Certificate .
• For JWT trust anchors (usage 1): The UTF-8 encoded JSON string of the JWK .
• For JWT constraints (usage 3): The ASCII string representing the full JWT compact serialization .
• For PSK constraints (usage 5): The opaque string representing the PSK identity .

1 -- SubjectPublicKeyInfo: DER-encoded binary structure of the public key.

• For X.509 certificates (usages 0 and 2): The SubjectPublicKeyInfo field within the certificate, encoded in DER binary format .
• For RPK constraints (usage 4): The DER-encoded RPK structure .

The Matching Type Field A one-octet value, called "matching type", specifies how the credential association is presented and matched. The types defined in this document are the same as Section 2.1.3 of : 0 -- Exact match on selected content. 1 -- SHA-256 hash of selected content. 2 -- SHA-512 hash of selected content. The following constraints apply to this document: For JWT Trust Anchors (Usage 1): Matching type 1 or 2 is NOT RECOMMENDED unless the companion application protocol explicitly guarantees that the plain-text JWK is delivered alongside the token. Without the plain-text JWK, the client cannot obtain the public key material needed to verify the JWT signature. For PSK Constraints (Usage 5): The matching type MUST be set to 0. The client requires the raw, unhashed PSK identity to construct the TLS ClientHello message.

The Credential Association Data Field This variable-length field contains the credential association data to be matched, constructed according to the preceding fields:

• The Usage field exemplifies the use of the credential association data.
• The Selector field determines whether the credential association data contains the full structure or the SubjectPublicKeyInfo of the credential.
• The Matching Type field determines the data's representation: the raw data, or its cryptographic hash.

Security Considerations

DNSSEC Dependency All AED RRs MUST be authenticated via DNSSEC . Clients MUST reject AED RRs that do not have a valid DNSSEC validation chain.

IANA Considerations This document has no IANA actions.

Normative References Encrypted communication on the Internet often uses Transport Layer Security (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain's TLS servers. This requires matching improvements in TLS client software, but no change in TLS server software. [STANDARDS-TRACK] In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This RFC is the revised basic definition of The Domain Name System. It obsoletes RFC-882. This memo describes the domain style names and their used for host address look up and electronic mail forwarding. It discusses the clients and servers in the domain name system and the protocol used between them. This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication. The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS-TRACK] This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] This document specifies a new certificate type and two TLS extensions for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). The new certificate type allows raw public keys to be used for authentication. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification. JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. This document specifies three sets of new ciphersuites for the Transport Layer Security (TLS) protocol to support authentication based on pre-shared keys (PSKs). These pre-shared keys are symmetric keys, shared in advance among the communicating parties. The first set of ciphersuites uses only symmetric key operations for authentication. The second set uses a Diffie-Hellman exchange authenticated with a pre-shared key, and the third set combines public key authentication of the server with pre-shared key authentication of the client. [STANDARDS-TRACK]

Acknowledgments TODO acknowledge.