Diff: rfc9987.original.xml

	rfc9987.original.xml	rfc9987.xml

	<?xml version="1.0" encoding="utf-8"?>	<?xml version="1.0" encoding="UTF-8"?>
	<?xml-model href="rfc7991bis.rnc"?>
	<!-- <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> -->
	<!DOCTYPE rfc [	<!DOCTYPE rfc [
	<!ENTITY nbsp " ">	<!ENTITY nbsp " ">
	<!ENTITY zwsp "">	<!ENTITY zwsp "">
	<!ENTITY nbhy "‑">	<!ENTITY nbhy "‑">
	<!ENTITY wj "⁠">	<!ENTITY wj "⁠">
	]>	]>

	<rfc
	xmlns:xi="http://www.w3.org/2001/XInclude"	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
	category="std"	tf-sshm-ssh-agent-16" number="9987" ipr="trust200902" obsoletes="" updates="" c
	docName="draft-ietf-sshm-ssh-agent-16"	onsensus="true" submissionType="IETF" xml:lang="en" sortRefs="false" symRefs="tr
	ipr="trust200902"	ue" tocInclude="true" version="3">
	obsoletes=""
	updates=""
	consensus="true"
	submissionType="IETF"
	xml:lang="en"
	version="3">
	<!--
	* docName should be the name of your draft
	* category should be one of std, bcp, info, exp, historic
	* ipr should be one of trust200902, noModificationTrust200902, noDerivatives
	Trust200902, pre5378Trust200902
	* updates can be an RFC number as NNNN.
	* obsoletes can be an RFC number as NNNN

	<front>	<front>

	<title>SSH Agent Protocol</title>	<title abbrev="SSH Agent Protocol">Secure Shell (SSH) Agent Protocol</title>
	<seriesInfo name="Internet-Draft" value="draft-ietf-sshm-ssh-agent-16"/>
	<author fullname="Damien Miller" initials="D." surname="Miller">	<!-- [rfced] Please note that the title of the document has been
	<organization>OpenSSH</organization>	updated as follows:
	<address>
	<email>djm@openssh.com</email>	Abbreviations have been expanded per Section 3.6 of RFC 7322 ("RFC
	<uri>https://www.openssh.com/</uri>	Style Guide"). Please review.
	</address>
	</author>	Original:
	<date />	SSH Agent Protocol
	<area>General</area>
	<workgroup>Internet Engineering Task Force</workgroup>	Current:
	<keyword>ssh</keyword>	Secure Shell (SSH) Agent Protocol
	<keyword>agent</keyword>	-->
	<keyword>ssh-agent</keyword>
	<abstract>	<seriesInfo name="RFC" value="9987"/>
	<t>	<author fullname="Damien Miller" initials="D." surname="Miller">
		<organization>OpenSSH</organization>
		<address>
		<email>djm@openssh.com</email>
		<uri>https://www.openssh.com/</uri>
		</address>
		</author>
		<date month="May" year="2026"/>
		<area>SEC</area>
		<workgroup>sshm</workgroup>

		<keyword>ssh</keyword>
		<keyword>agent</keyword>
		<keyword>ssh-agent</keyword>

		<abstract>
		<t>
	This document specifies a key agent protocol for use in	This document specifies a key agent protocol for use in
	the Secure Shell (SSH) protocol.	the Secure Shell (SSH) protocol.
	</t>	</t>
	</abstract>	</abstract>

	<note removeInRFC="true">
	<t>
	In the IANA considerations section, please replace
	"thisRFC" with "RFC" and the assigned number, when known.
	</t>
	</note>
	</front>	</front>

	<middle>	<middle>
	<section><name>Introduction</name>	<section><name>Introduction</name>
	<t>	<t>
	Secure Shell (SSH)	Secure Shell (SSH)
	<xref target="RFC4251" />	<xref target="RFC4251" />
	is a protocol for secure remote connections	is a protocol for secure remote connections
	<xref target="RFC4253" />	<xref target="RFC4253" />
	and login	and login
	<xref target="RFC4254" />	<xref target="RFC4254" />
	over untrusted networks.	over untrusted networks.
	It supports multiple authentication mechanisms	It supports multiple authentication mechanisms

	<xref target="RFC4252" />,	<xref target="RFC4252" />
	including public key authentication. This document	including public key authentication. This document
	specifies the protocol for interacting with a key	specifies the protocol for interacting with a key
	management component, usually referred to as "an agent",	management component, usually referred to as "an agent",
	that holds private keys. SSH clients (and possibly	that holds private keys. SSH clients (and possibly
	SSH servers) can invoke the agent via this protocol	SSH servers) can invoke the agent via this protocol
	to perform operations using public and private keys	to perform operations using public and private keys
	held in the agent.	held in the agent.
	</t>	</t>
	<t>	<t>
	Holding keys in an agent offers usability and security	Holding keys in an agent offers usability and security
	advantages to loading and unwrapping them at each use, as	advantages to loading and unwrapping them at each use, as

	each key unwrapping may require entry of a pass-phrase.	each key unwrapping may require entry of a passphrase.
	Access to an agent may optionally be forwarded across an SSH connection,	Access to an agent may optionally be forwarded across an SSH connection,
	thereby allowing remote systems to use stored keys without directly	thereby allowing remote systems to use stored keys without directly
	exposing the key material to the remote system.	exposing the key material to the remote system.
	Finally, the agent may be implemented as a dedicated component that	Finally, the agent may be implemented as a dedicated component that
	presents a smaller attack surface than a key loaded into	presents a smaller attack surface than a key loaded into

	a full SSH server or client, and which may be subject to special	a full SSH server or client and that may be subject to special
	protection from the wider system.	protection from the wider system.
	</t>	</t>

	<section removeInRFC="true"><name>Background</name>
	<t>
	This agent protocol is already widely used and a de-facto
	standard, having been implemented by a number of popular
	SSH clients and servers for many years. The purpose of
	this document is to describe the protocol as it has been
	implemented.
	</t>
	</section>	</section>
	<section anchor="requirements"><name>Requirements Language</name>	<section anchor="requirements"><name>Requirements Language</name>

	<t>	<t>
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",	The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
	"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT	IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be	NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
	interpreted as described in BCP 14 <xref target="RFC2119"/>	RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	<xref target="RFC8174"/> when, and only when, they appear in	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
	all capitals, as shown here.	be interpreted as
	</t>	described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
		when, and only when, they appear in all capitals, as shown here.
		</t>

	</section>	</section>

	</section>

	<section><name>Protocol Overview</name>	<section><name>Protocol Overview</name>
	<t>	<t>

	The agent protocol is a packetised request-response protocol,	The agent protocol is a packetised request-response protocol that is
	solely driven by the client. It consists of a number of	solely driven by the client. It consists of a number of
	requests sent from a client to an agent and a set of reply	requests sent from a client to an agent and a set of reply
	messages that are sent in response. At no time does the agent	messages that are sent in response. At no time does the agent
	send messages except in response to a client request. Replies	send messages except in response to a client request. Replies
	are sent in order.	are sent in order.
	</t>	</t>
	<t>	<t>
	These requests include the ability to load keys into an agent,	These requests include the ability to load keys into an agent,

	remove some or all keys from an agent and to perform signature	remove some or all keys from an agent, and perform signature
	operations using previously-loaded keys.	operations using previously loaded keys.
	</t>	</t>
	<t>	<t>

	Agents MAY implement support for only a subset of available key type	Agents <bcp14>MAY</bcp14> implement support for only a subset of availabl
	and MAY additionally refuse some operations in particular contexts.	e key types
		and <bcp14>MAY</bcp14> additionally refuse some operations in particular
		contexts.
	For example, an agent may allow only clients local to itself to	For example, an agent may allow only clients local to itself to

	add keys, or may make particular subsets of keys available to a	add keys or may make particular subsets of keys available to a
	given client.	given client.

	For this reason, clients of the agent SHOULD be prepared to	For this reason, clients of the agent <bcp14>SHOULD</bcp14> be prepared t o
	fail gracefully if any operation is refused.	fail gracefully if any operation is refused.
	</t>	</t>

	<section removeInRFC="true"><name>Background</name>
	<t>
	Note that this protocol is separate to and incompatible with
	the one described in the similarly-named
	<xref target="draft-ietf-secsh-agent-02" /> which expired
	in 2004.
	</t>
	</section>	</section>

	<section><name>Terminology and units</name>	<section><name>Terminology and Units</name>
	<t>	<t>

	Henceforth in this document, "agent" will be used to refer to a	Henceforth, in this document, "agent" will be used to refer to a
	key management component that implements the responder side of	key management component that implements the responder side of
	this protocol. "Client" will refer to a tool that implements	this protocol. "Client" will refer to a tool that implements
	the requester side of the protocol to communicate with an agent.	the requester side of the protocol to communicate with an agent.
	If it is pertinent that the client in question is a	If it is pertinent that the client in question is a

	<xref target="RFC4251" /> Secure Shell client, then it will be	Secure Shell client as described in <xref target="RFC4251"/>, the n the client will be
	explicitly referred to as an "SSH client".	explicitly referred to as an "SSH client".
	Similarly, "SSH server" will be used to refer to Secure Shell	Similarly, "SSH server" will be used to refer to Secure Shell
	servers.	servers.
	</t>	</t>
	<t>	<t>
	All encoding data types ("byte", "uint32", "string", etc.) are	All encoding data types ("byte", "uint32", "string", etc.) are
	as specified in <xref target="RFC4251" section="5" />.	as specified in <xref target="RFC4251" section="5" />.
	Additionally, the type "byte[]" without a specified length	Additionally, the type "byte[]" without a specified length
	within the square brackets indicates an unadorned sequence of	within the square brackets indicates an unadorned sequence of
	zero or more bytes where the length is determined by context.	zero or more bytes where the length is determined by context.
	</t>	</t>
	<t>	<t>
	All length units are given in bytes unless otherwise specified.	All length units are given in bytes unless otherwise specified.
	</t>	</t>
	</section>	</section>

	</section>

	<section anchor="protomess"><name>Protocol Messages</name>	<section anchor="protomess"><name>Protocol Messages</name>
	<t>	<t>

	Messages consist of a length, type and contents.	Messages consist of a "length", "type", and "contents".
	</t>	</t>

	<sourcecode>	<sourcecode><![CDATA[
	uint32 length	uint32 length
	byte type	byte type

	byte[length - 1] contents	byte[length - 1] contents]]></sourcecode>
	</sourcecode>
	<t>	<t>
	In the sections below, the "length" field is omitted. For	In the sections below, the "length" field is omitted. For
	clarity, the symbolic names of the message types are shown;	clarity, the symbolic names of the message types are shown;

	their numeric values are listed in <xref target="messagenum"/>	their numeric values are listed in <xref target="messagenum"/>.
	below.
	</t>	</t>


	<section anchor="genericresp"><name>Generic agent responses</name>	<section anchor="genericresp"><name>Generic Agent Responses</name>
	<t>	<t>
	The following generic messages may be sent by the agent	The following generic messages may be sent by the agent

	in response to requests from the client. On success the	in response to requests from the client. On success, the
	agent MUST reply either with the single-byte response:	agent <bcp14>MUST</bcp14> reply either with the single-byte respo
		nse:
	</t>	</t>

	<sourcecode>	<sourcecode><![CDATA[
	byte SSH_AGENT_SUCCESS	byte SSH_AGENT_SUCCESS]]></sourcecode>
	</sourcecode>
	<t>	<t>

	or a request-specific success message that may contain	or with a request-specific success message that may contain
	additional fields.	additional fields.

	On failure, the agent MUST reply with the single-byte response:	On failure, the agent <bcp14>MUST</bcp14> reply with the single-b yte response:
	</t>	</t>

	<sourcecode>	<sourcecode><![CDATA[
	byte SSH_AGENT_FAILURE	byte SSH_AGENT_FAILURE]]></sourcecode>
	</sourcecode>
	<t>	<t>

	or a request-specific failure message that may contain	or with a request-specific failure message that may contain
	additional fields.	additional fields.

	SSH_AGENT_FAILURE messages MUST also be sent in reply to	SSH_AGENT_FAILURE messages <bcp14>MUST</bcp14> also be sent in re ply to
	requests with unknown or unsupported types.	requests with unknown or unsupported types.
	</t>	</t>
	</section>	</section>

	<section anchor="addkeys"><name>Adding keys to the agent</name>	<section anchor="addkeys"><name>Adding Keys to the Agent</name>
	<t>	<t>
	Keys may be added to the agent using the	Keys may be added to the agent using the
	SSH_AGENTC_ADD_IDENTITY or	SSH_AGENTC_ADD_IDENTITY or
	SSH_AGENTC_ADD_ID_CONSTRAINED messages.	SSH_AGENTC_ADD_ID_CONSTRAINED messages.
	The latter variant allows adding keys with	The latter variant allows adding keys with
	optional constraints on their usage.	optional constraints on their usage.
	</t>	</t>
	<t>	<t>
	The generic format for the	The generic format for the
	SSH_AGENTC_ADD_IDENTITY message is:	SSH_AGENTC_ADD_IDENTITY message is:
	</t>	</t>

	<sourcecode>	<sourcecode><![CDATA[
	byte SSH_AGENTC_ADD_IDENTITY	byte SSH_AGENTC_ADD_IDENTITY
	string key type	string key type
	byte[] key data	byte[] key data

	string comment	string comment]]></sourcecode>
	</sourcecode>
	<t>	<t>

	Here "key type" is the specified key type name, for example	Here "key type" is the specified key type name, for example,
	"ssh-rsa" for an RSA key as defined by	"ssh-rsa" for an RSA key as defined by
	<xref target="RFC4253" />.	<xref target="RFC4253" />.

	"key data" consists of the public and private components	The "key data" consists of the public and private components
	of the key and varies by key type, as specified in subsections	of the key and varies by key type, as specified in Sections
	<xref target="add-dsa" format="counter" /> through	<xref target="add-dsa" format="counter" /> through
	<xref target="add-rsa" format="counter" />	<xref target="add-rsa" format="counter" />
	for commonly used key types.	for commonly used key types.

	"comment" is	A "comment" is
	a human-readable key name or comment	a human-readable key name or comment
	as a UTF-8 string that may serve to identify the	as a UTF-8 string that may serve to identify the
	key in user-visible messages. This string may be of zero length.	key in user-visible messages. This string may be of zero length.
	</t>	</t>
	<t>	<t>

	The SSH_AGENTC_ADD_ID_CONSTRAINED message is similar,	The SSH_AGENTC_ADD_ID_CONSTRAINED message is similar
	but adds an extra field:	but adds an extra field:
	</t>	</t>

	<sourcecode>	<sourcecode><![CDATA[
	byte SSH_AGENTC_ADD_ID_CONSTRAINED	byte SSH_AGENTC_ADD_ID_CONSTRAINED
	string key type	string key type
	byte[] key data	byte[] key data
	string comment	string comment

	constraint[] constraints	constraint[] constraints]]></sourcecode>
	</sourcecode>
	<t>	<t>
	Constraints are used to place limits on the validity	Constraints are used to place limits on the validity
	or use of keys.	or use of keys.
	<xref target="constraints" /> details constraint types	<xref target="constraints" /> details constraint types

	and their format.	and their formats.
	Clients SHOULD prefer the SSH_AGENTC_ADD_IDENTITY message	Clients <bcp14>SHOULD</bcp14> prefer the SSH_AGENTC_ADD_IDENTITY
	over sending an SSH_AGENTC_ADD_ID_CONSTRAINED with an empty	message
	constraints field, though both are valid and equivalent.	over sending an SSH_AGENTC_ADD_ID_CONSTRAINED message with an emp
		ty
		"constraints" field, though both are valid and equivalent.
	</t>	</t>
	<t>	<t>

	An agent MUST reply with SSH_AGENT_SUCCESS	An agent <bcp14>MUST</bcp14> reply with SSH_AGENT_SUCCESS
	if the key was successfully loaded	if the key was successfully loaded

	as a result of one of these messages, or	as a result of one of these messages or
	SSH_AGENT_FAILURE otherwise.	SSH_AGENT_FAILURE otherwise.
	</t>	</t>
	<t>	<t>

	Adding a key that is already present in an agent SHOULD replace
		Adding a key that is already present in an agent <bcp14>SHOULD</b
		cp14> replace
	any constraints it was previously loaded with those (if any)	any constraints it was previously loaded with those (if any)

	present in the subsequent add request, as this ensures that	that are present in the subsequent add request, as this ensures t hat
	security-relevant constraints on a loaded key best match user	security-relevant constraints on a loaded key best match user

	expectations. Otherwise an agent MAY refuse to load a key that	expectations. Otherwise, an agent <bcp14>MAY</bcp14> refuse to lo ad a key that
	has already been loaded.	has already been loaded.
	</t>	</t>
	<t>	<t>

	An agent MAY support only a subset of the key types defined	An agent <bcp14>MAY</bcp14> support only a subset of the key type
	here and MAY support additional key types as described below.	s defined
		here and <bcp14>MAY</bcp14> support additional key types as descr
		ibed below.
	If an agent does not recognise the type name in a request to	If an agent does not recognise the type name in a request to

	add a key, then it MUST respond with an SSH_AGENT_FAILURE reply.	add a key, then it <bcp14>MUST</bcp14> respond with an SSH_AGENT_ FAILURE reply.
	</t>	</t>

	<section anchor="add-dsa"><name>DSA keys</name>	<section anchor="add-dsa"><name>DSA Keys</name>
	<t>	<t>

	DSA keys have key type "ssh-dss" and are	Digital Signature Algorithm (DSA) keys have key type "ssh -dss" and are
	defined in <xref target="RFC4253" />. They	defined in <xref target="RFC4253" />. They
	may be added to the agent using the following	may be added to the agent using the following
	message. The "constraints" field is only	message. The "constraints" field is only
	present for the SSH_AGENTC_ADD_ID_CONSTRAINED	present for the SSH_AGENTC_ADD_ID_CONSTRAINED
	message.	message.
	</t>	</t>

	<sourcecode>	<sourcecode><![CDATA[
	byte SSH_AGENTC_ADD_IDENTITY or	byte SSH_AGENTC_ADD_IDENTITY or
	SSH_AGENTC_ADD_ID_CONSTRAINED	SSH_AGENTC_ADD_ID_CONSTRAINED
	string "ssh-dss"	string "ssh-dss"
	mpint p	mpint p
	mpint q	mpint q
	mpint g	mpint g
	mpint y	mpint y
	mpint x	mpint x
	string comment	string comment

	constraint[] constraints	constraint[] constraints]]></sourcecode>
	</sourcecode>
	<t>	<t>

	The "p", "q", "g" values are the DSA domain	The "p", "q", and "g" values are the DSA domain
	parameters. "y" and "x" are the public and	parameters. The "y" and "x" values are the public and
	private keys respectively. These values are	private keys, respectively. These values are
	as defined by Section 4.1 of	as defined by Section 4.1 of
	<xref target="FIPS.186-4"/>.	<xref target="FIPS.186-4"/>.
	</t>	</t>
	</section>	</section>

	<section anchor="add-ecdsa"><name>ECDSA keys</name>	<section anchor="add-ecdsa"><name>ECDSA Keys</name>
	<t>	<t>

	ECDSA keys have key types starting with	Elliptic Curve Digital Signature Algorithm (ECDSA) keys h ave key types starting with
	"ecdsa-sha2-" and are defined in	"ecdsa-sha2-" and are defined in
	<xref target="RFC5656" />. They	<xref target="RFC5656" />. They
	may be added to the agent using the	may be added to the agent using the
	following message.	following message.
	The "constraints" field is only present for	The "constraints" field is only present for
	the SSH_AGENTC_ADD_ID_CONSTRAINED message.	the SSH_AGENTC_ADD_ID_CONSTRAINED message.
	</t>	</t>

	<sourcecode>	<sourcecode><![CDATA[
	byte SSH_AGENTC_ADD_IDENTITY or	byte SSH_AGENTC_ADD_IDENTITY or
	SSH_AGENTC_ADD_ID_CONSTRAINED	SSH_AGENTC_ADD_ID_CONSTRAINED
	string key type	string key type
	string ecdsa_curve_name	string ecdsa_curve_name
	string Q	string Q
	mpint d	mpint d
	string comment	string comment

	constraint[] constraints	constraint[] constraints]]></sourcecode>
	</sourcecode>
	<t>	<t>
	The values "Q" and "d" are the ECDSA public and	The values "Q" and "d" are the ECDSA public and
	private values respectively. Both are defined	private values respectively. Both are defined
	by Section 6.2 of <xref target="FIPS.186-5"/>.	by Section 6.2 of <xref target="FIPS.186-5"/>.
	</t>	</t>
	</section>	</section>

	<section anchor="add-eddsa"><name>EDDSA keys</name>	<section anchor="add-eddsa"><name>EdDSA Keys</name>
	<t>	<t>
	<xref target="RFC8709" /> defines Ed25519 and	<!--[rfced] Please review both how we added in an expansion for the
		abbreviation EdDSA and the possible citation add in the following
		text. Note also that we have updated one instance of "EDDSA" to
		"EdDSA". Please let us know any objections.

		Original:
		[RFC8709] defines Ed25519 and Ed448 with key type names "ssh-ed25519"
		and "ssh-ed448" respectively.

		Current:
		[RFC8709] defines Edwards-curve Digital Signature Algorithm (EdDSA)
		keys (see [RFC8032]) Ed25519 and Ed448 with key type names
		"ssh-ed25519" and "ssh-ed448", respectively.
		-->

		<xref target="RFC8709" /> defines Edwards-curve Digital S
		ignature Algorithm (EdDSA) keys (see <xref target="RFC8032"/>) Ed25519 and
	Ed448 with key type names "ssh-ed25519" and	Ed448 with key type names "ssh-ed25519" and

	"ssh-ed448" respectively.	"ssh-ed448", respectively.
	These may be added to the agent using the	These may be added to the agent using the
	following message. The "constraints"	following message. The "constraints"
	field is only present for	field is only present for
	the SSH_AGENTC_ADD_ID_CONSTRAINED message.	the SSH_AGENTC_ADD_ID_CONSTRAINED message.
	</t>	</t>

	<sourcecode>	<sourcecode><![CDATA[
	byte SSH_AGENTC_ADD_IDENTITY or	byte SSH_AGENTC_ADD_IDENTITY or
	SSH_AGENTC_ADD_ID_CONSTRAINED	SSH_AGENTC_ADD_ID_CONSTRAINED
	string "ssh-ed25519" or "ssh-ed448"	string "ssh-ed25519" or "ssh-ed448"
	string ENC(A)	string ENC(A)
	string k \|\| ENC(A)	string k \|\| ENC(A)
	string comment	string comment

	constraint[] constraints	constraint[] constraints]]></sourcecode>
	</sourcecode>
	<t>	<t>

	The first value is the EDDSA public key
		<!--[rfced] Do we need both "redundant" and "repetition" here?

		Original:
		...(this redundant repetition of the public key is to maintain
		compatibility with widely deployed implementations).

		Perhaps:
		...(this repetition of the public key is to maintain
		compatibility with widely deployed implementations).
		-->

		The first value is the EdDSA public key
	ENC(A).	ENC(A).
	The second value is a concatenation of	The second value is a concatenation of
	the private key k	the private key k
	and the public	and the public
	ENC(A) key (this redundant repetition of the public key	ENC(A) key (this redundant repetition of the public key
	is to maintain compatibility with widely deployed	is to maintain compatibility with widely deployed
	implementations).	implementations).
	The contents and interpretation of the	The contents and interpretation of the
	ENC(A) and k values are	ENC(A) and k values are
	defined by <xref target="RFC8032" section="3.2"/>.	defined by <xref target="RFC8032" section="3.2"/>.
	</t>	</t>
	</section>	</section>

	<section anchor="add-rsa"><name>RSA keys</name>	<section anchor="add-rsa"><name>RSA Keys</name>
	<t>	<t>
	RSA keys have key type "ssh-rsa" and are	RSA keys have key type "ssh-rsa" and are
	defined in <xref target="RFC4253" />. They	defined in <xref target="RFC4253" />. They
	may be added to the agent using the following	may be added to the agent using the following
	message. The "constraints" field is only	message. The "constraints" field is only
	present for the	present for the
	SSH_AGENTC_ADD_ID_CONSTRAINED message.	SSH_AGENTC_ADD_ID_CONSTRAINED message.
	</t>	</t>

	<sourcecode>	<sourcecode><![CDATA[
	byte SSH_AGENTC_ADD_IDENTITY or	byte SSH_AGENTC_ADD_IDENTITY or
	SSH_AGENTC_ADD_ID_CONSTRAINED	SSH_AGENTC_ADD_ID_CONSTRAINED
	string "ssh-rsa"	string "ssh-rsa"
	mpint n	mpint n
	mpint e	mpint e
	mpint d	mpint d
	mpint iqmp	mpint iqmp
	mpint p	mpint p
	mpint q	mpint q
	string comment	string comment

	constraint[] constraints	constraint[] constraints]]></sourcecode>
	</sourcecode>
	<t>	<t>
	"n" is the public composite modulus.	"n" is the public composite modulus.
	"e" is the public exponent.	"e" is the public exponent.
	"d" is the private exponent.	"d" is the private exponent.
	"p" and "q" are its constituent private	"p" and "q" are its constituent private
	prime factors.	prime factors.
	"iqmp" is the inverse of "q" modulo	"iqmp" is the inverse of "q" modulo

	"p". All these values except "iqmp"	"p". All of these values, except "iqmp"
	(which can be calculated from the others)	(which can be calculated from the others),
	are defined by Section 5.1 of	are defined by Section 5.1 of
	<xref target="FIPS.186-5" />.	<xref target="FIPS.186-5" />.
	</t>	</t>
	</section>	</section>

	<section anchor="add-other"><name>Other keys</name>	<section anchor="add-other"><name>Other Keys</name>
	<t>	<t>

	Agents and their clients MAY support additional key	Agents and their clients <bcp14>MAY</bcp14> support addit ional key
	types not documented here. Vendor-specific key types	types not documented here. Vendor-specific key types

	MUST use the domain-qualified naming convention	<bcp14>MUST</bcp14> use the domain-qualified naming conve ntion
	defined in <xref target="RFC4251" section="6" />	defined in <xref target="RFC4251" section="6" />

	until code-points are allocated by IANA	until codepoints are allocated by IANA
	<xref target="IANA-PUBKEYS" />.	<xref target="IANA-PUBKEYS" />.
	</t>	</t>
	</section>	</section>

	<section anchor="addtoken"><name>Adding keys from a token</name>	<section anchor="addtoken"><name>Adding Keys from a Token</name>
	<t>	<t>
	Keys hosted on smart-cards or other hardware	Keys hosted on smart-cards or other hardware
	tokens may be added using the	tokens may be added using the
	SSH_AGENTC_ADD_SMARTCARD_KEY and	SSH_AGENTC_ADD_SMARTCARD_KEY and
	SSH_AGENTC_ADD_SMARTCARD_KEY_CONSTRAINED	SSH_AGENTC_ADD_SMARTCARD_KEY_CONSTRAINED

	requests. Note that "constraints" field is only	requests. Note that the "constraints" field is only
	included for the	included for the
	SSH_AGENTC_ADD_SMARTCARD_KEY_CONSTRAINED	SSH_AGENTC_ADD_SMARTCARD_KEY_CONSTRAINED
	variant of this message.	variant of this message.
	</t>	</t>

	<sourcecode>	<sourcecode><![CDATA[
	byte SSH_AGENTC_ADD_SMARTCARD_KEY or	byte SSH_AGENTC_ADD_SMARTCARD_KEY or
	SSH_AGENTC_ADD_SMARTCARD_KEY_CONSTRAINED	SSH_AGENTC_ADD_SMARTCARD_KEY_CONSTRAINED
	string token id	string token id
	string PIN	string PIN

	constraint[] constraints	constraint[] constraints]]></sourcecode>
	</sourcecode>
	<t>	<t>
	Here "token id" is an opaque identifier for the	Here "token id" is an opaque identifier for the
	hardware token and "PIN" is an optional	hardware token and "PIN" is an optional
	password or PIN to unlock the key.	password or PIN to unlock the key.
	The interpretation of "token id" is not defined	The interpretation of "token id" is not defined

	by the protocol but is left solely up to	by the protocol: it is left solely up to
	the agent.	the agent.
	</t>	</t>
	<t>	<t>
	Typically, only the public components of	Typically, only the public components of
	any keys supported on a hardware token	any keys supported on a hardware token

	will be loaded into an agent so, strictly	will be loaded into an agent; thus, strictly
	speaking, this message really arranges	speaking, this message really arranges for
	future private key operations to be	future private key operations to be
	delegated to the hardware token in question.	delegated to the hardware token in question.
	</t>	</t>
	<t>	<t>

	An agent MUST reply with SSH_AGENT_SUCCESS	An agent <bcp14>MUST</bcp14> reply with SSH_AGENT_SUCCESS
	if one or more keys were successfully loaded	if one or more keys were successfully loaded

	as a result of one of these messages, or	as a result of one of these messages or with
	SSH_AGENT_FAILURE if no keys were found.	SSH_AGENT_FAILURE if no keys were found.

	The agent MUST also return SSH_AGENT_FAILURE	The agent <bcp14>MUST</bcp14> also return SSH_AGENT_FAILU RE
	if the "token id" was not recognised, if the request	if the "token id" was not recognised, if the request
	was against agent policy, or if	was against agent policy, or if
	the agent doesn't support token-hosted keys	the agent doesn't support token-hosted keys
	at all.	at all.
	</t>	</t>
	</section>	</section>

	<section title="Key Constraints" anchor="constraints">	<section anchor="constraints">
		<name>Key Constraints</name>
	<t>	<t>
	A number of constraints may be used in the	A number of constraints may be used in the
	constrained variants of the key add messages.	constrained variants of the key add messages.
	Each constraint is represented by a type byte	Each constraint is represented by a type byte
	followed by zero or more value bytes.	followed by zero or more value bytes.
	</t>	</t>
	<t>	<t>
	Zero or more constraints may be specified when	Zero or more constraints may be specified when
	adding a key with one of the *_CONSTRAINED	adding a key with one of the *_CONSTRAINED
	requests. Multiple constraints are appended	requests. Multiple constraints are appended
	consecutively to the end of the request:	consecutively to the end of the request:
	</t>	</t>

	<sourcecode>	<sourcecode><![CDATA[
	byte constraint1_type	byte constraint1_type
	byte[] constraint1_data	byte[] constraint1_data
	byte constraint2_type	byte constraint2_type
	byte[] constraint2_data	byte[] constraint2_data
	....	....
	byte constraintN_type	byte constraintN_type

	byte[] constraintN_data	byte[] constraintN_data]]></sourcecode>
	</sourcecode>
	<t>	<t>
	To fully parse a constraint, it is necessary to	To fully parse a constraint, it is necessary to

	know its structure beforehand and it is not	know its structure beforehand; it is not
	possible to safely recover when an unrecognised	possible to safely recover when an unrecognised
	constraint is encountered.	constraint is encountered.
	Given this, if an agent does not recognise or support a	Given this, if an agent does not recognise or support a

	requested constraint it MUST abort parsing, refuse the	requested constraint, it <bcp14>MUST</bcp14> abort parsin
	request and return an SSH_AGENT_FAILURE message to the	g, refuse the
		request, and return an SSH_AGENT_FAILURE message to the
	client.	client.
	</t>	</t>
	<t>	<t>

	The following constraints are defined.	The following subsections describe the constraints that h ave been defined.
	</t>	</t>

	<section><name>Key lifetime constraint</name>	<section><name>Key Lifetime Constraint</name>
	<t>	<t>
	This constraint requests that the	This constraint requests that the
	agent limit the key's lifetime by	agent limit the key's lifetime by
	deleting it after the specified	deleting it after the specified
	duration (in seconds) has elapsed	duration (in seconds) has elapsed
	from the time the key was added to	from the time the key was added to
	the agent.	the agent.
	</t>	</t>

	<sourcecode>	<sourcecode><![CDATA[
	byte SSH_AGENT_CONSTRAIN_LIFETIME	byte SSH_AGENT_CONSTRAIN_LIFETIME

	uint32 seconds	uint32 seconds]]></sourcecode>
	</sourcecode>
	</section>	</section>

	<section><name>Key confirmation constraint</name>	<section><name>Key Confirmation Constraint</name>
	<t>	<t>
	This constraint requests that the	This constraint requests that the
	agent require explicit user	agent require explicit user
	confirmation for each private key	confirmation for each private key
	operation using the key. For example,	operation using the key. For example,
	the agent could present a confirmation	the agent could present a confirmation
	dialog before completing a signature	dialog before completing a signature
	operation.	operation.
	</t>	</t>

	<sourcecode>	<sourcecode><![CDATA[
	byte SSH_AGENT_CONSTRAIN_CONFIRM	byte SSH_AGENT_CONSTRAIN_CONFIRM]]></sourcecode>
	</sourcecode>
	</section>	</section>

	<section anchor="contraintext"><name>Constraint extension s</name>	<section anchor="contraintext"><name>Constraint Extension s</name>
	<t>	<t>
	Agents may implement experimental	Agents may implement experimental
	or private-use constraints through	or private-use constraints through
	an extension constraint that supports	an extension constraint that supports
	named constraints.	named constraints.
	</t>	</t>

	<sourcecode>	<sourcecode><![CDATA[
	byte SSH_AGENT_CONSTRAIN_EXTENSION	byte SSH_AGENT_CONSTRAIN_EXTENSION
	string extension name	string extension name

	byte[] extension-specific details	byte[] extension-specific details]]></sourcecode>
	</sourcecode>
	<t>	<t>

	The extension name MUST consist of	The "extension name" <bcp14>MUST</bcp14> consist of
	a UTF-8 string.	a UTF-8 string.

	Vendor extensions MUST be suffixed by the	Vendor extensions <bcp14>MUST</bcp14> be suffixed by the
	implementation domain following	implementation domain following
	the naming scheme defined in	the naming scheme defined in
	<xref target="RFC4251" section="6" />,	<xref target="RFC4251" section="6" />,

	e.g. "foo@example.com".	e.g., "foo@example.com".
	</t>	</t>
	<t>	<t>
	Note, given the above requirement to reject	Note, given the above requirement to reject
	keys with unsupported constraints, a constraint	keys with unsupported constraints, a constraint

	extension is only usable when both client	extension is only usable when both the client
	and agent support it. Otherwise, the agent	and agent support it. Otherwise, the agent
	will be required to reject the key. This is	will be required to reject the key. This is
	desirable, as the constraint extension may	desirable, as the constraint extension may
	specify limits on the key that, if ignored,	specify limits on the key that, if ignored,
	may result in the key being available in	may result in the key being available in

	situations the user did not intend (i.e. the	situations the user did not intend (i.e., the
	agent will fail safely).	agent will fail safely).
	</t>	</t>
	</section>	</section>
	</section>	</section>
	</section>	</section>

	<section anchor="pubkeyblob"><name>Public key encoding</name>	<section anchor="pubkeyblob"><name>Public Key Encoding</name>
	<t>	<t>
	Keys previously loaded into an agent are referred to by their	Keys previously loaded into an agent are referred to by their
	public key blob, which is the standard SSH wire encoding for	public key blob, which is the standard SSH wire encoding for
	public keys. SSH protocol key encodings are defined in	public keys. SSH protocol key encodings are defined in
	<xref target="RFC4253" /> for "ssh-rsa" and "ssh-dss" keys,	<xref target="RFC4253" /> for "ssh-rsa" and "ssh-dss" keys,

	in <xref target="RFC5656" /> for "ecdsa-sha2-*" keys and in	in <xref target="RFC5656" /> for "ecdsa-sha2-*" keys, and in
	<xref target="RFC8709" /> for "ssh-ed25519" and "ssh-ed448"	<xref target="RFC8709" /> for "ssh-ed25519" and "ssh-ed448"
	keys.	keys.
	</t>	</t>
	</section>	</section>

	<section anchor="rmkeys"><name>Removing keys from the agent</name>	<section anchor="rmkeys"><name>Removing Keys from the Agent</name>
	<t>	<t>
	A client may request that an agent remove	A client may request that an agent remove
	all keys that it stores:	all keys that it stores:
	</t>	</t>

	<sourcecode>	<sourcecode><![CDATA[
	byte SSH_AGENTC_REMOVE_ALL_IDENTITIES	byte SSH_AGENTC_REMOVE_ALL_IDENTITIES]]></sourcecode>
	</sourcecode>
	<t>	<t>
	On receipt of such a message,	On receipt of such a message,

	an agent SHOULD delete all keys that it is holding	an agent <bcp14>SHOULD</bcp14> delete all keys that it is holding
	and reply with SSH_AGENT_SUCCESS, otherwise it MUST	and reply with SSH_AGENT_SUCCESS; otherwise, it <bcp14>MUST</bcp1
		4>
	reply with SSH_AGENT_FAILURE if the request was refused.	reply with SSH_AGENT_FAILURE if the request was refused.
	</t>	</t>
	<t>	<t>

	This request SHOULD be honoured regardless of	This request <bcp14>SHOULD</bcp14> be honoured regardless of
	any agent policy that limits actions that a given	any agent policy that limits actions that a given

	client may take, as otherwise a user would be unable to	client may take; otherwise, a user would be unable to
	quickly and completely remove their keys in an urgent situation.	quickly and completely remove their keys in an urgent situation.
	</t>	</t>
	<t>	<t>
	Specific keys may also be removed:	Specific keys may also be removed:
	</t>	</t>

	<sourcecode>	<sourcecode><![CDATA[
	byte SSH_AGENTC_REMOVE_IDENTITY	byte SSH_AGENTC_REMOVE_IDENTITY

	string key blob	string key blob]]></sourcecode>
	</sourcecode>
	<t>	<t>
	Where "key blob" is the standard public key encoding of the	Where "key blob" is the standard public key encoding of the
	key to be removed (<xref target="pubkeyblob" />).	key to be removed (<xref target="pubkeyblob" />).
	</t>	</t>
	<t>	<t>

	An agent MUST reply with SSH_AGENT_SUCCESS if the key was	An agent <bcp14>MUST</bcp14> reply with SSH_AGENT_SUCCESS if the key was
	deleted or SSH_AGENT_FAILURE if it was not found.	deleted or SSH_AGENT_FAILURE if it was not found.
	</t>	</t>
	<t>	<t>
	Token-hosted keys may be removed from an agent using:	Token-hosted keys may be removed from an agent using:
	</t>	</t>

	<sourcecode>	<sourcecode><![CDATA[
	byte SSH_AGENTC_REMOVE_SMARTCARD_KEY	byte SSH_AGENTC_REMOVE_SMARTCARD_KEY
	string token id	string token id

	string PIN	string PIN]]></sourcecode>
	</sourcecode>
	<t>	<t>
	Where "token id" is an opaque identifier for the hardware token	Where "token id" is an opaque identifier for the hardware token
	and "PIN" is an optional password or PIN (not typically	and "PIN" is an optional password or PIN (not typically
	used), both encoded using UTF-8.	used), both encoded using UTF-8.

	Requesting deletion of token-hosted keys SHOULD	Requesting deletion of token-hosted keys <bcp14>SHOULD</bcp14>
	cause the agent to remove all keys it loaded from the device	cause the agent to remove all keys it loaded from the device
	matching "token id".	matching "token id".

	Similarly to SSH_AGENTC_REMOVE_ALL_IDENTITIES, agents SHOULD	Similarly to SSH_AGENTC_REMOVE_ALL_IDENTITIES, agents <bcp14>SHOU LD</bcp14>
	honour this request regardless of local policy to allow	honour this request regardless of local policy to allow
	fast and complete removal of keys.	fast and complete removal of keys.

	Note: this operation affects the agent only, it SHOULD NOT
		<!--[rfced] Please review if any text marked "Note:" should be put in
		the <aside> element (defined as "a container for content that is
		semantically less important or tangential to the content that
		surrounds it" at
		https://authors.ietf.org/en/rfcxml-vocabulary#aside.

		Original:
		Note: this operation affects the agent only, it SHOULD NOT cause the
		keys be deleted from the token itself.

		-->

		<!--[rfced] Please confirm that the following update maintains your
		intended meaning:

		Original:
		An agent MUST reply with SSH_AGENT_SUCCESS keys were deleted or
		SSH_AGENT_FAILURE if none were found.

		Current:
		An agent MUST reply with SSH_AGENT_SUCCESS if the keys were deleted or
		SSH_AGENT_FAILURE if none were found.

		-->

		Note: this operation affects the agent only; it <bcp14>SHOULD NOT
		</bcp14>
	cause the keys be deleted from the token itself.	cause the keys be deleted from the token itself.
	</t>	</t>
	<t>	<t>

	An agent MUST reply with SSH_AGENT_SUCCESS keys were	An agent <bcp14>MUST</bcp14> reply with SSH_AGENT_SUCCESS if the keys were
	deleted or SSH_AGENT_FAILURE if none were found.	deleted or SSH_AGENT_FAILURE if none were found.
	</t>	</t>
	</section>	</section>

	<section anchor="listkeys"><name>Requesting a list of keys</name>	<section anchor="listkeys"><name>Requesting a List of Keys</name>
	<t>	<t>
	A client may request a list of keys from an agent using the	A client may request a list of keys from an agent using the
	following message:	following message:
	</t>	</t>

	<sourcecode>	<sourcecode><![CDATA[
	byte SSH_AGENTC_REQUEST_IDENTITIES	byte SSH_AGENTC_REQUEST_IDENTITIES]]></sourcecode>
	</sourcecode>
	<t>	<t>

	The agent MUST reply with a message with the following	The agent <bcp14>MUST</bcp14> reply with a message with the follo
	preamble.	wing
		preamble:
	</t>	</t>

	<sourcecode>	<sourcecode><![CDATA[
	byte SSH_AGENT_IDENTITIES_ANSWER	byte SSH_AGENT_IDENTITIES_ANSWER

	uint32 nkeys	uint32 nkeys]]></sourcecode>
	</sourcecode>
	<t>	<t>
	Where "nkeys" indicates the number of keys to follow.	Where "nkeys" indicates the number of keys to follow.
	Following the preamble are zero or more keys, representing the	Following the preamble are zero or more keys, representing the
	keys the agent makes available to the client with each	keys the agent makes available to the client with each
	encoded as:	encoded as:
	</t>	</t>

	<sourcecode>	<sourcecode><![CDATA[
	string key blob	string key blob

	string comment	string comment]]></sourcecode>
	</sourcecode>
	<t>	<t>
	Where "key blob" is the standard public key encoding of the	Where "key blob" is the standard public key encoding of the
	key (<xref target="pubkeyblob" />) and "comment" is a	key (<xref target="pubkeyblob" />) and "comment" is a
	human-readable comment encoded as a UTF-8 string.	human-readable comment encoded as a UTF-8 string.
	</t>	</t>
	</section>	</section>

	<section anchor="privkeyops"><name>Private key operations</name>	<section anchor="privkeyops"><name>Private Key Operations</name>
	<t>	<t>

	A client may request the agent perform a	A client may request that the agent perform a
	private key signature operation using the	private key signature operation using the
	following message:	following message:
	</t>	</t>

	<sourcecode>	<sourcecode><![CDATA[
	byte SSH_AGENTC_SIGN_REQUEST	byte SSH_AGENTC_SIGN_REQUEST
	string key blob	string key blob
	string data	string data

	uint32 flags	uint32 flags]]></sourcecode>
	</sourcecode>
	<t>	<t>
	Where "key blob" is the key requested to perform the	Where "key blob" is the key requested to perform the
	signature (encoded as per <xref target="pubkeyblob" />),	signature (encoded as per <xref target="pubkeyblob" />),

	"data" is the data to be signed and "flags" is a bitfield	"data" is the data to be signed, and "flags" is a bitfield
	containing the bitwise OR of zero or more signature flags	containing the bitwise OR of zero or more signature flags
	(see below).	(see below).
	</t>	</t>
	<t>	<t>
	If the agent does not support the requested flags, or is	If the agent does not support the requested flags, or is
	otherwise unable or unwilling to generate the signature	otherwise unable or unwilling to generate the signature

	(for example, because it doesn't have the specified key,	(for example, because it doesn't have the specified key
	or the user refused confirmation of a constrained key),	or the user refused confirmation of a constrained key),

	it MUST reply with an SSH_AGENT_FAILURE message.	it <bcp14>MUST</bcp14> reply with an SSH_AGENT_FAILURE message.
	</t>	</t>
	<t>	<t>

	On success, the agent MUST reply with:	On success, the agent <bcp14>MUST</bcp14> reply with:
	</t>	</t>

	<sourcecode>	<sourcecode><![CDATA[
	byte SSH_AGENT_SIGN_RESPONSE	byte SSH_AGENT_SIGN_RESPONSE

	string signature	string signature]]></sourcecode>
	</sourcecode>
	<t>	<t>
	The signature format is specific to the algorithm of the key	The signature format is specific to the algorithm of the key
	type in use. SSH protocol signature formats are defined in	type in use. SSH protocol signature formats are defined in
	<xref target="RFC4253" /> for "ssh-rsa" and "ssh-dss" keys,	<xref target="RFC4253" /> for "ssh-rsa" and "ssh-dss" keys,

	in <xref target="RFC5656" /> for "ecdsa-sha2-*" keys and in	in <xref target="RFC5656" /> for "ecdsa-sha2-*" keys, and in
	<xref target="RFC8709" /> for "ssh-ed25519" and "ssh-ed448"	<xref target="RFC8709" /> for "ssh-ed25519" and "ssh-ed448"
	keys.	keys.
	</t>	</t>

	<section><name>Signature flags</name>	<section><name>Signature Flags</name>
	<t>	<t>
	Two flags are currently defined for	Two flags are currently defined for
	signature request messages:	signature request messages:
	SSH_AGENT_RSA_SHA2_256 and SSH_AGENT_RSA_SHA2_512	SSH_AGENT_RSA_SHA2_256 and SSH_AGENT_RSA_SHA2_512
	(defined in <xref target="sigflagnum" />).	(defined in <xref target="sigflagnum" />).
	These two flags are only valid for	These two flags are only valid for
	"ssh-rsa" keys and request that the agent	"ssh-rsa" keys and request that the agent
	return a signature using	return a signature using
	the "rsa-sha2-256" or "rsa-sha2-512"	the "rsa-sha2-256" or "rsa-sha2-512"

	signature methods respectively. These	signature methods, respectively. These
	signature schemes are defined in	signature schemes are defined in
	<xref target="RFC8332" />.	<xref target="RFC8332" />.
	</t>	</t>
	</section>	</section>
	</section>	</section>

	<section anchor="lock"><name>Locking and unlocking an agent</name>	<section anchor="lock"><name>Locking and Unlocking an Agent</name>
	<t>	<t>
	The agent protocol supports instructing an agent to	The agent protocol supports instructing an agent to

	temporarily lock itself with a pass-phrase. When locked, an	temporarily lock itself with a passphrase. When locked, an
	agent MUST suspend processing of sensitive operations	agent <bcp14>MUST</bcp14> suspend processing of sensitive operati
		ons
	(private key signature operations at the very least) until it	(private key signature operations at the very least) until it

	has been unlocked with the same pass-phrase.	has been unlocked with the same passphrase.
	</t>	</t>
	<t>	<t>
	The following message instructs an agent to lock itself:	The following message instructs an agent to lock itself:
	</t>	</t>

	<sourcecode>	<sourcecode><![CDATA[
	byte SSH_AGENTC_LOCK	byte SSH_AGENTC_LOCK

	string passphrase	string passphrase]]></sourcecode>
	</sourcecode>
	<t>	<t>

	The agent MUST reply with SSH_AGENT_SUCCESS if locked	The agent <bcp14>MUST</bcp14> reply with SSH_AGENT_SUCCESS if loc
	successfully or SSH_AGENT_FAILURE otherwise (e.g. if the agent	ked
		successfully or SSH_AGENT_FAILURE otherwise (e.g., if the agent
	was already locked).	was already locked).
	</t>	</t>
	<t>	<t>
	The following message requests unlocking an agent:	The following message requests unlocking an agent:
	</t>	</t>

	<sourcecode>	<sourcecode><![CDATA[
	byte SSH_AGENTC_UNLOCK	byte SSH_AGENTC_UNLOCK

	string passphrase	string passphrase]]></sourcecode>
	</sourcecode>
	<t>	<t>

	If the agent is already locked and the pass-phrase matches the	If the agent is already locked and the passphrase matches the
	one used to lock it then it MUST unlock and reply with	one used to lock it, then it <bcp14>MUST</bcp14> unlock and reply
		with
	SSH_AGENT_SUCCESS. If the agent is already unlocked or if	SSH_AGENT_SUCCESS. If the agent is already unlocked or if

	the pass-phrase does not match it MUST reply with	the passphrase does not match, it <bcp14>MUST</bcp14> reply with
	SSH_AGENT_FAILURE.	SSH_AGENT_FAILURE.
	</t>	</t>
	</section>	</section>

	<section anchor="extreq"><name>Extension mechanism</name>	<section anchor="extreq"><name>Extension Mechanism</name>
	<t>	<t>
	The agent protocol includes an optional extension mechanism	The agent protocol includes an optional extension mechanism
	that allows vendor-specific and experimental messages to be	that allows vendor-specific and experimental messages to be
	sent via the agent protocol. Extension requests from the	sent via the agent protocol. Extension requests from the
	client consist of:	client consist of:
	</t>	</t>

	<sourcecode>	<sourcecode><![CDATA[
	byte SSH_AGENTC_EXTENSION	byte SSH_AGENTC_EXTENSION
	string extension type	string extension type

	byte[] extension request-specific contents	byte[] extension request-specific contents]]></sourcecode>
	</sourcecode>
	<t>	<t>

	The extension type indicates the type of the extension message	The "extension type" indicates the type of the extension message
	as a UTF-8 string. Implementation-specific extensions MUST	as a UTF-8 string. Implementation-specific extensions <bcp14>MUS
		T</bcp14>
	be suffixed by the implementation domain following the	be suffixed by the implementation domain following the
	extension naming scheme defined in	extension naming scheme defined in

	<xref target="RFC4251" section="6" />, e.g. "foo@example.com".	<xref target="RFC4251" section="6" />, e.g., "foo@example.com".
	</t>	</t>
	<t>	<t>
	An agent that does not support extensions of the supplied type	An agent that does not support extensions of the supplied type

	MUST reply with an empty SSH_AGENT_FAILURE message. This reply	<bcp14>MUST</bcp14> reply with an empty SSH_AGENT_FAILURE message . This reply
	is also sent by agents that do not support the extension	is also sent by agents that do not support the extension
	mechanism at all.	mechanism at all.
	</t>	</t>
	<t>	<t>
	The contents of successful extension reply messages are	The contents of successful extension reply messages are

	specific to the extension type.	specific to the "extension type".
	Successful extension requests MUST return	Successful extension requests <bcp14>MUST</bcp14> return
	either SSH_AGENT_SUCCESS on success or an extension-specific	either SSH_AGENT_SUCCESS on success or an extension-specific
	response message:	response message:
	</t>	</t>

	<sourcecode>	<sourcecode><![CDATA[
	byte SSH_AGENT_EXTENSION_RESPONSE	byte SSH_AGENT_EXTENSION_RESPONSE
	string extension type	string extension type

	byte[] extension response-specific contents	byte[] extension response-specific contents]]></sourcecode>
	</sourcecode>
	<t>	<t>

	Where the extension type is the same as that in the request.	Where the "extension type" is the same as that in the request.
	</t>	</t>
	<t>	<t>

	Extension failure SHOULD be signaled using an	Extension failure <bcp14>SHOULD</bcp14> be signaled using an
	SSH_AGENT_EXTENSION_FAILURE message:	SSH_AGENT_EXTENSION_FAILURE message:
	</t>	</t>

	<sourcecode>	<sourcecode><![CDATA[
	byte SSH_AGENT_EXTENSION_FAILURE	byte SSH_AGENT_EXTENSION_FAILURE]]></sourcecode>
	</sourcecode>
	<t>	<t>

	Extensions SHOULD NOT use	Extensions <bcp14>SHOULD NOT</bcp14> use
	the standard SSH_AGENT_FAILURE message. This allows failed	the standard SSH_AGENT_FAILURE message. This allows failed
	requests to be distinguished from the extension not being	requests to be distinguished from the extension not being
	supported.	supported.
	</t>	</t>

	<section anchor="queryext"><name>Query extension</name>	<section anchor="queryext"><name>Query Extension</name>
	<t>	<t>

	A single, optional extension request "query" is	A single optional extension request "query" is
	defined to allow a client to query which, if any,	defined to allow a client to query which, if any,
	extensions are supported by an agent.	extensions are supported by an agent.
	</t>	</t>

	<sourcecode>	<sourcecode><![CDATA[
	byte SSH_AGENTC_EXTENSION	byte SSH_AGENTC_EXTENSION

	string "query"	string "query"]]></sourcecode>
	</sourcecode>
	<t>	<t>

	If an agent supports the query extension it	If an agent supports the query extension, it
	SHOULD reply with a list of supported extension names.	<bcp14>SHOULD</bcp14> reply with a list of supported exte
		nsion names.
	</t>	</t>

	<sourcecode>	<sourcecode><![CDATA[
	byte SSH_AGENT_EXTENSION_RESPONSE	byte SSH_AGENT_EXTENSION_RESPONSE
	string "query"	string "query"

	string[] supported extension types	string[] supported extension types]]></sourcecode>
	</sourcecode>
	</section>	</section>
	</section>	</section>
	</section>	</section>


	<section anchor="connecting"><name>Connecting to an agent</name>	<section anchor="connecting"><name>Connecting to an Agent</name>
	<t>	<t>
	Agents are exposed to the local system using a connection-oriented	Agents are exposed to the local system using a connection-oriented
	endpoint. On Unix-like systems, it is typical to arrange for	endpoint. On Unix-like systems, it is typical to arrange for
	the agent to listen on a filesystem-based Unix domain socket.	the agent to listen on a filesystem-based Unix domain socket.
	On Microsoft Windows, it is usual to use a Windows Named Pipe.	On Microsoft Windows, it is usual to use a Windows Named Pipe.

	Access to these endpoints SHOULD be controlled as discussed in	Access to these endpoints <bcp14>SHOULD</bcp14> be controlled as discusse d in
	<xref target="Security" />. Multiple clients may access a single	<xref target="Security" />. Multiple clients may access a single
	agent by making connections to these sockets.	agent by making connections to these sockets.
	</t>	</t>
	<t>	<t>
	In both cases, it is common to expose the name or address of the	In both cases, it is common to expose the name or address of the
	listening endpoint via an environment variable named "SSH_AUTH_SOCK".	listening endpoint via an environment variable named "SSH_AUTH_SOCK".
	Clients of an agent will use this variable to locate and connect to	Clients of an agent will use this variable to locate and connect to

	the listening agent. Agents alternately MAY use an implicit mechanism	the listening agent. Alternatively, agents <bcp14>MAY</bcp14> use an imp licit mechanism
	for clients to locate their endpoint, such as a default per-user	for clients to locate their endpoint, such as a default per-user
	location.	location.
	</t>	</t>
	</section>	</section>


	<section anchor="fwd"><name>Forwarding access to an agent</name>	<section anchor="fwd"><name>Forwarding Access to an Agent</name>
	<t>	<t>

		<!--[rfced] Please clarify how these two "using" clauses relate to the
		sentence:

		Original:
		The agent protocol may be forwarded over an SSH connection, using the
		[RFC4254] connection protocol, allowing agent forwarding to be
		requested for any session channel, using a model that is similar to
		the connection protocol's support for X11 Forwarding (Section 6.3 of
		[RFC4254]).

		Perhaps:
		Using the connection protocol described in [RFC4254], the agent
		protocol may be forwarded over an SSH connection. This allows agent
		forwarding to be requested for any session channel using a model that
		is similar to the connection protocol's support for X11 Forwarding
		(Section 6.3 of [RFC4254]).

		-->
	The agent protocol may be forwarded over an SSH connection, using the	The agent protocol may be forwarded over an SSH connection, using the
	<xref target="RFC4254" /> connection protocol, allowing agent	<xref target="RFC4254" /> connection protocol, allowing agent
	forwarding to be requested for any session channel, using a model	forwarding to be requested for any session channel, using a model
	that is similar to the connection protocol's support for X11 Forwarding	that is similar to the connection protocol's support for X11 Forwarding
	(<xref target="RFC4254" section="6.3"/>).	(<xref target="RFC4254" section="6.3"/>).

	This feature is OPTIONAL for SSH protocol and agent implementations.	This feature is <bcp14>OPTIONAL</bcp14> for the SSH protocol and agent im plementations.
	</t>	</t>

	<section anchor="fwdext" title="Advertising agent forwarding support">	<section anchor="fwdext">
		<name>Advertising Agent Forwarding Support</name>
	<t>	<t>
	Support for agent forwarding may be advertised by an SSH	Support for agent forwarding may be advertised by an SSH

	server using the <xref target="RFC8308" /> extension	server using the extension mechanism described in <xref target="R
	mechanism using the name "agent-forward" in the	FC8308" /> using the name "agent-forward" in the
	SSH_MSG_EXT_INFO message.	SSH_MSG_EXT_INFO message.
	</t>	</t>

	<sourcecode>	<sourcecode><![CDATA[
	string "agent-forward"	string "agent-forward"

	string "0" (version)	string "0" (version)]]></sourcecode>
	</sourcecode>
	<t>	<t>
	Note that this protocol substantially predates the existence	Note that this protocol substantially predates the existence

	of the <xref target="RFC8308" /> extension mechanism and	of the extension mechanism described in <xref target="RFC8308" />
	several widely-deployed SSH implementations that support agent	. Further note that
	forwarding do not advertise their ability to do so. SSH Clients	several widely deployed SSH implementations that support agent
	MAY opportunistically attempt to request agent forwarding in	forwarding do not advertise their ability to do so. SSH clients
	the absence of an <xref target="RFC8308" /> advertisement	<bcp14>MAY</bcp14> opportunistically attempt to request agent for
		warding in
		the absence of an advertisement (see <xref target="RFC8308" />)
	using the vendor-specific names mentioned below.	using the vendor-specific names mentioned below.

	Likewise, SSH servers MAY implement the vendor-specific names in	Likewise, SSH servers <bcp14>MAY</bcp14> implement the vendor-spe cific names in
	addition to the one described here.	addition to the one described here.
	</t>	</t>
	</section>	</section>

	<section anchor="fwdreq"><name>Requesting agent forwarding</name>	<section anchor="fwdreq"><name>Requesting Agent Forwarding</name>
	<t>	<t>
	An SSH client may request agent forwarding for a	An SSH client may request agent forwarding for a

	previously-opened session	previously opened session
	(<xref target="RFC4254" section="6.1" />) using the	(see <xref target="RFC4254" section="6.1" />) using the
	following channel request. This request is sent after the	following channel request. This request is sent after the

	channel has been opened, but before a shell, command or	channel has been opened, but before a shell, command, or
	subsystem has been executed.	subsystem has been executed.
	</t>	</t>

	<sourcecode>	<sourcecode><![CDATA[
	byte SSH_MSG_CHANNEL_REQUEST	byte SSH_MSG_CHANNEL_REQUEST
	uint32 channel_id	uint32 channel_id
	string "agent-req" or "auth-agent-req@openssh.com"	string "agent-req" or "auth-agent-req@openssh.com"

	boolean want_reply	boolean want_reply]]></sourcecode>
	</sourcecode>
	<t>	<t>

	Where channel_id is the identifier for an established session	Where "channel_id" is the identifier for an established session
	channel (as returned from a previous SSH_MSG_CHANNEL_OPEN	channel (as returned from a previous SSH_MSG_CHANNEL_OPEN

	request, and the want_reply flag indicates whether the SSH	request) and the "want_reply" flag indicates whether the SSH
	server should respond with a confirmation of whether the request	server should respond with a confirmation of whether the request
	was successful (as specified in	was successful (as specified in

	<xref target="RFC4254" section="5.4"/>)	<xref target="RFC4254" section="5.4"/>).
	</t>	</t>
	<t>	<t>
	If an SSH server accepts this request, typically it will arrange	If an SSH server accepts this request, typically it will arrange

	to make an endpoint (e.g. a listening socket) available and	to make an endpoint (e.g., a listening socket) available and
	advertise this fact to the subordinate session. Most	advertise this fact to the subordinate session. Most
	implementations on Unix-like systems do this by providing a	implementations on Unix-like systems do this by providing a
	user-private listening Unix domain socket and recording its	user-private listening Unix domain socket and recording its

	location in an environment variable SSH_AUTH_SOCK.	location in an environment variable "SSH_AUTH_SOCK".
	</t>	</t>
	<t>	<t>
	As mentioned previously, many deployed implementations only	As mentioned previously, many deployed implementations only
	support the pre-standardisation	support the pre-standardisation
	"auth-agent-req@openssh.com" request name. The "agent-req" name	"auth-agent-req@openssh.com" request name. The "agent-req" name

	SHOULD only be used if support was explicitly advertised as	<bcp14>SHOULD</bcp14> only be used if support was explicitly adve rtised as
	per <xref target="fwdext" />.	per <xref target="fwdext" />.
	</t>	</t>
	</section>	</section>

	<section anchor="fwdtype"><name>Agent connection requests</name>	<section anchor="fwdtype"><name>Agent Connection Requests</name>
	<t>	<t>
	After an SSH client has requested that a session have agent	After an SSH client has requested that a session have agent

	forwarding enabled, the SSH server later may request a	forwarding enabled, the SSH server may request a
	connection to the forwarded agent. The SSH server does this by	connection to the forwarded agent. The SSH server does this by
	requesting a dedicated channel to communicate with the	requesting a dedicated channel to communicate with the
	SSH client's agent.	SSH client's agent.
	</t>	</t>

	<sourcecode>	<sourcecode><![CDATA[
	byte SSH_MSG_CHANNEL_OPEN	byte SSH_MSG_CHANNEL_OPEN
	string "agent-connect" or "auth-agent@openssh.com"	string "agent-connect" or "auth-agent@openssh.com"
	uint32 channel_id	uint32 channel_id
	uint32 local_window	uint32 local_window

	uint32 local_maxpacket	uint32 local_maxpacket]]></sourcecode>
	</sourcecode>
	<t>	<t>

	The channel_id, local_window and local_maxpacket fields	The "channel_id", "local_window", and "local_maxpacket" fields
	should be interpreted as specified by	should be interpreted as specified by
	<xref target="RFC4254" section="5.1"/>.	<xref target="RFC4254" section="5.1"/>.
	</t>	</t>
	<t>	<t>

	As above, the "agent-connect" open type name SHOULD only be	As above, the "agent-connect" open type name <bcp14>SHOULD</bcp14 > only be
	used if support was explicitly advertised as per	used if support was explicitly advertised as per
	<xref target="fwdext" />.	<xref target="fwdext" />.
	</t>	</t>
	<t>	<t>

	An SSH client SHOULD be prepared to handle multiple concurrent	An SSH client <bcp14>SHOULD</bcp14> be prepared to handle multipl
	forwarded connections to a client-side agent, otherwise requests	e concurrent
		forwarded connections to a client-side agent; otherwise, requests
	to access the agent from the remote side that happen to overlap	to access the agent from the remote side that happen to overlap
	prior requests may fail. Overlapping requests may occur because	prior requests may fail. Overlapping requests may occur because
	the SSH connection protocol <xref target="RFC4254" /> allows	the SSH connection protocol <xref target="RFC4254" /> allows

	multiple user sessions over a single <xref target="RFC4253" />	multiple user sessions over a single transport (see <xref target=
	transport, which may each request use of the agentcw	"RFC4253" />), which may each request use of the agentcw
	independently and potentially concurrently.	independently and potentially concurrently.
	</t>	</t>
	<t>	<t>

	An SSH client MAY accept agent connection requests (subject to	An SSH client <bcp14>MAY</bcp14> accept agent connection requests (subject to
	authorisation) without a prior agent forwarding request having	authorisation) without a prior agent forwarding request having
	been made to support the situation where agent forwarding	been made to support the situation where agent forwarding
	without opening a session is desired.	without opening a session is desired.

	Similarly, an SSH client MAY continue to accept agent connection	Similarly, an SSH client <bcp14>MAY</bcp14> continue to accept ag ent connection
	requests after the session for which agent forwarding was	requests after the session for which agent forwarding was
	requested has closed.	requested has closed.
	</t>	</t>
	<t>	<t>

	An SSH client MUST refuse unauthorised agent connection	An SSH client <bcp14>MUST</bcp14> refuse unauthorised agent conne ction
	requests, when agent forwarding is neither requested nor	requests, when agent forwarding is neither requested nor
	desired by the SSH client but an SSH server sends an agent	desired by the SSH client but an SSH server sends an agent
	connection request anyway.	connection request anyway.
	</t>	</t>
	<t>	<t>
	Because the "agent-connect" request contains no identifier to	Because the "agent-connect" request contains no identifier to
	distinguish which session channel originated the connection	distinguish which session channel originated the connection
	request, an SSH connection can effectively forward	request, an SSH connection can effectively forward
	access to only a single SSH client-side agent using	access to only a single SSH client-side agent using
	this protocol (although there may be multiple concurrent	this protocol (although there may be multiple concurrent
	connections to that single agent).	connections to that single agent).
	</t>	</t>
	</section>	</section>
	</section>	</section>


	<section><name>Protocol numbers</name>	<section><name>Protocol Numbers</name>
	<section anchor="messagenum" title="Message type numbers">	<section anchor="messagenum">
		<name>Message Type Numbers</name>
	<t>	<t>
	The following numbers are used as message types for requests	The following numbers are used as message types for requests
	from the client to the agent.	from the client to the agent.
	</t>	</t>

	<sourcecode>	<sourcecode><![CDATA[
	SSH_AGENTC_REQUEST_IDENTITIES 11	SSH_AGENTC_REQUEST_IDENTITIES 11
	SSH_AGENTC_SIGN_REQUEST 13	SSH_AGENTC_SIGN_REQUEST 13
	SSH_AGENTC_ADD_IDENTITY 17	SSH_AGENTC_ADD_IDENTITY 17
	SSH_AGENTC_REMOVE_IDENTITY 18	SSH_AGENTC_REMOVE_IDENTITY 18
	SSH_AGENTC_REMOVE_ALL_IDENTITIES 19	SSH_AGENTC_REMOVE_ALL_IDENTITIES 19
	SSH_AGENTC_ADD_SMARTCARD_KEY 20	SSH_AGENTC_ADD_SMARTCARD_KEY 20
	SSH_AGENTC_REMOVE_SMARTCARD_KEY 21	SSH_AGENTC_REMOVE_SMARTCARD_KEY 21
	SSH_AGENTC_LOCK 22	SSH_AGENTC_LOCK 22
	SSH_AGENTC_UNLOCK 23	SSH_AGENTC_UNLOCK 23
	SSH_AGENTC_ADD_ID_CONSTRAINED 25	SSH_AGENTC_ADD_ID_CONSTRAINED 25
	SSH_AGENTC_ADD_SMARTCARD_KEY_CONSTRAINED 26	SSH_AGENTC_ADD_SMARTCARD_KEY_CONSTRAINED 26

	SSH_AGENTC_EXTENSION 27	SSH_AGENTC_EXTENSION 27]]></sourcecode>
	</sourcecode>
	<t>	<t>
	The following numbers are used as message types for replies	The following numbers are used as message types for replies
	from the agent to the client.	from the agent to the client.
	</t>	</t>

	<sourcecode>	<sourcecode><![CDATA[
	SSH_AGENT_FAILURE 5	SSH_AGENT_FAILURE 5
	SSH_AGENT_SUCCESS 6	SSH_AGENT_SUCCESS 6
	SSH_AGENT_IDENTITIES_ANSWER 12	SSH_AGENT_IDENTITIES_ANSWER 12
	SSH_AGENT_SIGN_RESPONSE 14	SSH_AGENT_SIGN_RESPONSE 14
	SSH_AGENT_EXTENSION_FAILURE 28	SSH_AGENT_EXTENSION_FAILURE 28

	SSH_AGENT_EXTENSION_RESPONSE 29	SSH_AGENT_EXTENSION_RESPONSE 29]]></sourcecode>
	</sourcecode>	<section anchor="reservednum"><name>Reserved Message Type Numbers
	<section anchor="reservednum"><name>Reserved message type numbers	</name>
	</name>
	<t>	<t>
	The following message type numbers are reserved for	The following message type numbers are reserved for
	implementations that implement support for the legacy	implementations that implement support for the legacy

	SSH protocol version 1: 1-4, 7-10, 15-16 and	SSH protocol version 1: 1-4, 7-10, 15-16, and
	24 (inclusive).	24 (inclusive).

	These message numbers MAY be used by an	These message numbers <bcp14>MAY</bcp14> be used by an
	implementation supporting the legacy protocol but	implementation supporting the legacy protocol but

	MUST NOT be reused otherwise.	<bcp14>MUST NOT</bcp14> be reused otherwise.
	</t>	</t>
	<t>	<t>

	Message number 0 is also reserved and MUST NOT	Message number 0 is also reserved and <bcp14>MUST NOT</bc p14>
	be used.	be used.
	</t>	</t>
	<t>	<t>

	The range of message numbers 240-255 are reserved for	The range of message numbers 240-255 is reserved for
	Private Use extensions to the agent protocol and	Private Use extensions to the agent protocol and

	MUST NOT be used by generic implementations.	<bcp14>MUST NOT</bcp14> be used by generic implementation s (see <xref target="RFC8126"/> for more information on Private Use).
	</t>	</t>
	</section>	</section>
	</section>	</section>

	<section anchor="constraintid" title="Constraint identifiers">	<section anchor="constraintid">
		<name>Constraint Identifiers</name>
	<t>	<t>
	The following numbers are used to identify key constraints.	The following numbers are used to identify key constraints.
	These are only used in key constraints and are not sent as	These are only used in key constraints and are not sent as
	message numbers.	message numbers.
	</t>	</t>

	<sourcecode>	<sourcecode><![CDATA[
	SSH_AGENT_CONSTRAIN_LIFETIME 1	SSH_AGENT_CONSTRAIN_LIFETIME 1
	SSH_AGENT_CONSTRAIN_CONFIRM 2	SSH_AGENT_CONSTRAIN_CONFIRM 2

	SSH_AGENT_CONSTRAIN_EXTENSION 255	SSH_AGENT_CONSTRAIN_EXTENSION 255]]></sourcecode>
	</sourcecode>
	<t>	<t>
	The constraint identifier 0 is reserved.	The constraint identifier 0 is reserved.
	</t>	</t>
	</section>	</section>

	<section anchor="sigflagnum" title="Signature flags">	<section anchor="sigflagnum">
		<name>Signature Flags</name>
	<t>	<t>
	The following numbers may be present in signature request	The following numbers may be present in signature request
	(SSH_AGENTC_SIGN_REQUEST) messages. These flags form a bit	(SSH_AGENTC_SIGN_REQUEST) messages. These flags form a bit
	field by taking the logical OR of zero or more flags.	field by taking the logical OR of zero or more flags.
	</t>	</t>

	<sourcecode>	<sourcecode><![CDATA[
	SSH_AGENT_RSA_SHA2_256 0x00000002	SSH_AGENT_RSA_SHA2_256 0x00000002

	SSH_AGENT_RSA_SHA2_512 0x00000004	SSH_AGENT_RSA_SHA2_512 0x00000004]]></sourcecode>
	</sourcecode>
	<t>	<t>
	The flag value 1 is reserved for historical implementations.	The flag value 1 is reserved for historical implementations.
	</t>	</t>
	</section>	</section>
	</section>	</section>


		<!--[rfced] We had the following questions related to the IANA
		registries:

		a) We see no mention in the tables in this document of unassigned
		values as appears at the corresponding IANA registries.

		Please let us know if this document should be updated to match the
		registries in this regard.

		b) Please note that we have updated the column title in the Connection
		Protocol Channel Types section (Table 7) to read as "Channel Type"
		instead of "Request Type" to match the registry at
		https://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh-paramet
		ers-11.
		Please let us know any objections.

		-->

	<section anchor="IANA"><name>IANA Considerations</name>	<section anchor="IANA"><name>IANA Considerations</name>
	<t>	<t>

	This protocol requires five registries be established, one for	This protocol describes the establishment of five registries: one for
	message type numbers, one for constraint numbers,	message type numbers, one for constraint numbers,
	one for signature request	one for signature request

	flags, one for constraint extension names	flags, one for constraint extension names,
	and one for extension request names. Additionally,	and one for extension request names. Additionally,
	new codepoints are requested in three existing registries.	new codepoints are requested in three existing registries.
	</t>	</t>
	<section><name>Guidance for Designated Experts</name>	<section><name>Guidance for Designated Experts</name>
	<t>	<t>
	When a Designated Expert (DE) is asked to review additions to the	When a Designated Expert (DE) is asked to review additions to the

	new registries described above (<xref target="agentnum" />,	new registries described in this document (<xref target="agentnum" />,
	<xref target="constraintnum" />, <xref target="sigflag" /> and	<xref target="constraintnum" />, <xref target="sigflag" />, and
	<xref target="reqname" />), they are requested to verify that	<xref target="reqname" />), they are requested to verify that
	suitable documentation as described in <xref target="RFC8126" />	suitable documentation as described in <xref target="RFC8126" />
	exists and is permanently and publicly available.	exists and is permanently and publicly available.
	The DE is also requested to check the clarity of purpose and use of	The DE is also requested to check the clarity of purpose and use of

	the requested code points. The DE should also verify that specifications	the requested codepoints. The DE should also verify that specifications
	produced in the IETF that request code points in these registries have	produced in the IETF that request codepoints in these registries have
	been made available to the SSHM working group and the ssh@ietf.org	been made available to the SSHM Working Group and the ssh@ietf.org
	mailing list for review. Requests for code points made for	mailing list for review. Requests for codepoints made for
	specifications produced outside the IETF should not conflict with	specifications produced outside the IETF should not conflict with
	active IETF work or prior IETF specifications.	active IETF work or prior IETF specifications.
	</t>	</t>
	<t>	<t>

	The available number of code points in the SSH agent protocol	The available number of codepoints in the SSH agent protocol
	numbers (<xref target="agentnum" />), constraint numbers	numbers (<xref target="agentnum" />), constraint numbers

	(<xref target="constraintnum" />) and SSH agent signature	(<xref target="constraintnum" />), and SSH agent signature
	flags (<xref target="sigflag" />) registries are limited,	flags (<xref target="sigflag" />) registries are limited,

	so the DE is requested to ensure the use of code points is very well	so the DE is requested to ensure the use of codepoints is very well
	justified. For the SSH agent protocol message numbers, named extension	justified. For the SSH agent protocol message numbers, named extension
	requests (<xref target="reqname" />) provide an alternative for most	requests (<xref target="reqname" />) provide an alternative for most

	uses with no practical limitation on the number of available code	uses with no practical limitation on the number of available codepoints.
	points.
	For key constraint numbers, the constraint extension	For key constraint numbers, the constraint extension
	mechanism (<xref target="contraintext" />) provides a similar	mechanism (<xref target="contraintext" />) provides a similar

	alternative that is not limited by available code points.	alternative that is not limited by available codepoints.
	</t>	</t>
	</section>	</section>

	<section anchor="agentnum"><name>New registry: SSH agent protocol message type numbers</name>	<section anchor="agentnum"><name>"SSH Agent Protocol Message Type Numbers " Registry</name>
	<t>	<t>

	This registry, titled "SSH agent protocol message type numbers"	The "SSH Agent Protocol Message Type Numbers" registry
	records the message type numbers for client requests and	records the message type numbers for client requests and
	agent responses.	agent responses.

	It should be created in the Secure Shell (SSH) Protocol	It is located in the "Secure Shell (SSH) Protocol
	Parameters registry group <xref target="IANA-SSH" />.	Parameters" registry group <xref target="IANA-SSH" />.
	Its initial state should consist of the following	Its initial state consists of the following
	numbers and reservations.	numbers and reservations.
	Future message number allocations shall occur via	Future message number allocations shall occur via
	Expert Review as per <xref target="RFC8126" />.	Expert Review as per <xref target="RFC8126" />.
	</t>	</t>
	<table>	<table>
	<thead>	<thead>

	<tr><th>Number(s)</th><th>Identifier</th><th>Reference</th></tr>	<tr><th>Number</th><th>Identifier</th><th>Reference</th></tr>
	</thead>	</thead>
	<tbody>	<tbody>

	<tr><td>0</td><td>reserved</td><td>thisrfc, <xref target="reservednum" /></td></	<tr><td>0</td><td>Reserved</td><td>RFC 9987, <xref target="reservednum" /></td><
	tr>	/tr>
	<tr><td>1</td><td>reserved</td><td>thisrfc, <xref target="reservednum" /></td></	<tr><td>1</td><td>Reserved</td><td>RFC 9987, <xref target="reservednum" /></td><
	tr>	/tr>
	<tr><td>2</td><td>reserved</td><td>thisrfc, <xref target="reservednum" /></td></	<tr><td>2</td><td>Reserved</td><td>RFC 9987, <xref target="reservednum" /></td><
	tr>	/tr>
	<tr><td>3</td><td>reserved</td><td>thisrfc, <xref target="reservednum" /></td></	<tr><td>3</td><td>Reserved</td><td>RFC 9987, <xref target="reservednum" /></td><
	tr>	/tr>
	<tr><td>4</td><td>reserved</td><td>thisrfc, <xref target="reservednum" /></td></	<tr><td>4</td><td>Reserved</td><td>RFC 9987, <xref target="reservednum" /></td><
	tr>	/tr>
	<tr><td>5</td><td>SSH_AGENT_FAILURE</td><td>thisrfc, Sections <xref target="gene	<tr><td>5</td><td>SSH_AGENT_FAILURE</td><td>RFC 9987, Sections <xref target="gen
	ricresp" format="counter" /> and <xref target="messagenum" format="counter" /></	ericresp" format="counter" /> and <xref target="messagenum" format="counter" /><
	td></tr>	/td></tr>
	<tr><td>6</td><td>SSH_AGENT_SUCCESS</td><td>thisrfc, Sections <xref target="gene	<tr><td>6</td><td>SSH_AGENT_SUCCESS</td><td>RFC 9987, Sections <xref target="gen
	ricresp" format="counter" /> and <xref target="messagenum" format="counter" /></	ericresp" format="counter" /> and <xref target="messagenum" format="counter" /><
	td></tr>	/td></tr>
	<tr><td>7</td><td>reserved</td><td>thisrfc, <xref target="reservednum" /></td></	<tr><td>7</td><td>Reserved</td><td>RFC 9987, <xref target="reservednum" /></td><
	tr>	/tr>
	<tr><td>8</td><td>reserved</td><td>thisrfc, <xref target="reservednum" /></td></	<tr><td>8</td><td>Reserved</td><td>RFC 9987, <xref target="reservednum" /></td><
	tr>	/tr>
	<tr><td>9</td><td>reserved</td><td>thisrfc, <xref target="reservednum" /></td></	<tr><td>9</td><td>Reserved</td><td>RFC 9987, <xref target="reservednum" /></td><
	tr>	/tr>
	<tr><td>10</td><td>reserved</td><td>thisrfc, <xref target="reservednum" /></td><	<tr><td>10</td><td>Reserved</td><td>RFC 9987, <xref target="reservednum" /></td>
	/tr>	</tr>
	<tr><td>11</td><td>SSH_AGENTC_REQUEST_IDENTITIES</td><td>thisrfc, Sections <xref	<tr><td>11</td><td>SSH_AGENTC_REQUEST_IDENTITIES</td><td>RFC 9987, Sections <xre
	target="listkeys" format="counter" /> and <xref target="messagenum" format="cou	f target="listkeys" format="counter" /> and <xref target="messagenum" format="co
	nter" /></td></tr>	unter" /></td></tr>
	<tr><td>12</td><td>SSH_AGENT_IDENTITIES_ANSWER</td><td>thisrfc, Sections <xref t	<tr><td>12</td><td>SSH_AGENT_IDENTITIES_ANSWER</td><td>RFC 9987, Sections <xref
	arget="listkeys" format="counter" /> and <xref target="messagenum" format="count	target="listkeys" format="counter" /> and <xref target="messagenum" format="coun
	er" /></td></tr>	ter" /></td></tr>
	<tr><td>13</td><td>SSH_AGENTC_SIGN_REQUEST</td><td>thisrfc, Sections <xref targe	<tr><td>13</td><td>SSH_AGENTC_SIGN_REQUEST</td><td>RFC 9987, Sections <xref targ
	t="privkeyops" format="counter" /> and <xref target="messagenum" format="counter	et="privkeyops" format="counter" /> and <xref target="messagenum" format="counte
	" /></td></tr>	r" /></td></tr>
	<tr><td>14</td><td>SSH_AGENT_SIGN_RESPONSE</td><td>thisrfc, Sections <xref targe	<tr><td>14</td><td>SSH_AGENT_SIGN_RESPONSE</td><td>RFC 9987, Sections <xref targ
	t="privkeyops" format="counter" /> and <xref target="messagenum" format="counter	et="privkeyops" format="counter" /> and <xref target="messagenum" format="counte
	" /></td></tr>	r" /></td></tr>
	<tr><td>15</td><td>reserved</td><td>thisrfc, <xref target="reservednum" /></td><	<tr><td>15</td><td>Reserved</td><td>RFC 9987, <xref target="reservednum" /></td>
	/tr>	</tr>
	<tr><td>16</td><td>reserved</td><td>thisrfc, <xref target="reservednum" /></td><	<tr><td>16</td><td>Reserved</td><td>RFC 9987, <xref target="reservednum" /></td>
	/tr>	</tr>
	<tr><td>17</td><td>SSH_AGENTC_ADD_IDENTITY</td><td>thisrfc, Sections <xref targe	<tr><td>17</td><td>SSH_AGENTC_ADD_IDENTITY</td><td>RFC 9987, Sections <xref targ
	t="addkeys" format="counter" /> and <xref target="messagenum" format="counter" /	et="addkeys" format="counter" /> and <xref target="messagenum" format="counter"
	></td></tr>	/></td></tr>
	<tr><td>18</td><td>SSH_AGENTC_REMOVE_IDENTITY</td><td>thisrfc, Sections <xref ta	<tr><td>18</td><td>SSH_AGENTC_REMOVE_IDENTITY</td><td>RFC 9987, Sections <xref t
	rget="rmkeys" format="counter" /> and <xref target="messagenum" format="counter"	arget="rmkeys" format="counter" /> and <xref target="messagenum" format="counter
	/></td></tr>	" /></td></tr>
	<tr><td>19</td><td>SSH_AGENTC_REMOVE_ALL_IDENTITIES</td><td>thisrfc, Sections <x	<tr><td>19</td><td>SSH_AGENTC_REMOVE_ALL_IDENTITIES</td><td>RFC 9987, Sections <
	ref target="rmkeys" format="counter" /> and <xref target="messagenum" format="co	xref target="rmkeys" format="counter" /> and <xref target="messagenum" format="c
	unter" /></td></tr>	ounter" /></td></tr>
	<tr><td>20</td><td>SSH_AGENTC_ADD_SMARTCARD_KEY</td><td>thisrfc, Sections <xref	<tr><td>20</td><td>SSH_AGENTC_ADD_SMARTCARD_KEY</td><td>RFC 9987, Sections <xref
	target="addtoken" format="counter" /> and <xref target="messagenum" format="coun	target="addtoken" format="counter" /> and <xref target="messagenum" format="cou
	ter" /></td></tr>	nter" /></td></tr>
	<tr><td>21</td><td>SSH_AGENTC_REMOVE_SMARTCARD_KEY</td><td>thisrfc, Sections <xr	<tr><td>21</td><td>SSH_AGENTC_REMOVE_SMARTCARD_KEY</td><td>RFC 9987, Sections <x
	ef target="rmkeys" format="counter" /> and <xref target="messagenum" format="cou	ref target="rmkeys" format="counter" /> and <xref target="messagenum" format="co
	nter" /></td></tr>	unter" /></td></tr>
	<tr><td>22</td><td>SSH_AGENTC_LOCK</td><td>thisrfc, Sections <xref target="lock"	<tr><td>22</td><td>SSH_AGENTC_LOCK</td><td>RFC 9987, Sections <xref target="lock
	format="counter" /> and <xref target="messagenum" format="counter" /></td></tr>	" format="counter" /> and <xref target="messagenum" format="counter" /></td></tr
	<tr><td>23</td><td>SSH_AGENTC_UNLOCK</td><td>thisrfc, Sections <xref target="loc	>
	k" format="counter" /> and <xref target="messagenum" format="counter" /></td></t	<tr><td>23</td><td>SSH_AGENTC_UNLOCK</td><td>RFC 9987, Sections <xref target="lo
	r>	ck" format="counter" /> and <xref target="messagenum" format="counter" /></td></
	<tr><td>24</td><td>reserved</td><td>thisrfc, <xref target="reservednum" /></td><	tr>
	/tr>	<tr><td>24</td><td>Reserved</td><td>RFC 9987, <xref target="reservednum" /></td>
	<tr><td>25</td><td>SSH_AGENTC_ADD_ID_CONSTRAINED</td><td>thisrfc, Sections <xref	</tr>
	target="addkeys" format="counter" /> and <xref target="messagenum" format="coun	<tr><td>25</td><td>SSH_AGENTC_ADD_ID_CONSTRAINED</td><td>RFC 9987, Sections <xre
	ter" /></td></tr>	f target="addkeys" format="counter" /> and <xref target="messagenum" format="cou
	<tr><td>26</td><td>SSH_AGENTC_ADD_SMARTCARD_KEY_CONSTRAINED</td><td>thisrfc, Sec	nter" /></td></tr>
	tions <xref target="addtoken" format="counter" /> and <xref target="messagenum"	<tr><td>26</td><td>SSH_AGENTC_ADD_SMARTCARD_KEY_CONSTRAINED</td><td>RFC 9987, Se
	format="counter" /></td></tr>	ctions <xref target="addtoken" format="counter" /> and <xref target="messagenum"
	<tr><td>27</td><td>SSH_AGENTC_EXTENSION</td><td>thisrfc, Sections <xref target="	format="counter" /></td></tr>
	extreq" format="counter" /> and <xref target="messagenum" format="counter" /></t	<tr><td>27</td><td>SSH_AGENTC_EXTENSION</td><td>RFC 9987, Sections <xref target=
	d></tr>	"extreq" format="counter" /> and <xref target="messagenum" format="counter" /></
	<tr><td>28</td><td>SSH_AGENT_EXTENSION_FAILURE</td><td>thisrfc, Sections <xref t	td></tr>
	arget="extreq" format="counter" /> and <xref target="messagenum" format="counter	<tr><td>28</td><td>SSH_AGENT_EXTENSION_FAILURE</td><td>RFC 9987, Sections <xref
	" /></td></tr>	target="extreq" format="counter" /> and <xref target="messagenum" format="counte
	<tr><td>29</td><td>SSH_AGENT_EXTENSION_RESPONSE</td><td>thisrfc, Sections <xref	r" /></td></tr>
	target="extreq" format="counter" /> and <xref target="messagenum" format="counte	<tr><td>29</td><td>SSH_AGENT_EXTENSION_RESPONSE</td><td>RFC 9987, Sections <xref
	r" /></td></tr>	target="extreq" format="counter" /> and <xref target="messagenum" format="count
	<tr><td>240-255</td><td>Private Use</td><td>thisrfc, <xref target="messagenum" /	er" /></td></tr>
	></td></tr>	<tr><td>240-255</td><td>Private Use</td><td>RFC 9987, <xref target="messagenum"
		/></td></tr>
	</tbody>	</tbody>
	</table>	</table>
	</section>	</section>

	<section anchor="constraintnum"><name>New registry: SSH agent key constra int numbers</name>	<section anchor="constraintnum"><name>"SSH Agent Key Constraint Numbers" Registry</name>
	<t>	<t>

	This registry, titled "SSH agent key constraint numbers"	The "SSH Agent Key Constraint Numbers" registry
	records the message numbers for key use constraints.	records the message numbers for key use constraints.

	It should be created in the Secure Shell (SSH) Protocol	It is located in the "Secure Shell (SSH) Protocol
	Parameters registry group <xref target="IANA-SSH" />.	Parameters" registry group <xref target="IANA-SSH" />.
	Its initial state should consist of the	Its initial state is as follows.
	following numbers.
	Future key constraint number allocations shall occur via	Future key constraint number allocations shall occur via
	Expert Review as per <xref target="RFC8126" />.	Expert Review as per <xref target="RFC8126" />.
	</t>	</t>
	<table>	<table>
	<thead>	<thead>
	<tr><th>Number</th><th>Identifier</th><th>Reference</th></tr>	<tr><th>Number</th><th>Identifier</th><th>Reference</th></tr>
	</thead>	</thead>
	<tbody>	<tbody>

	<tr><td>0</td><td>reserved</td><td>thisrfc, <xref target="constraintid" /></td><	<tr><td>0</td><td>Reserved</td><td>RFC 9987, <xref target="constraintid" /></td>
	/tr>	</tr>
	<tr><td>1</td><td>SSH_AGENT_CONSTRAIN_LIFETIME</td><td>thisrfc, <xref target="co	<tr><td>1</td><td>SSH_AGENT_CONSTRAIN_LIFETIME</td><td>RFC 9987, <xref target="c
	nstraintid" /></td></tr>	onstraintid" /></td></tr>
	<tr><td>2</td><td>SSH_AGENT_CONSTRAIN_CONFIRM</td><td>thisrfc, <xref target="con	<tr><td>2</td><td>SSH_AGENT_CONSTRAIN_CONFIRM</td><td>RFC 9987, <xref target="co
	straintid" /></td></tr>	nstraintid" /></td></tr>
	<tr><td>255</td><td>SSH_AGENT_CONSTRAIN_EXTENSION</td><td>thisrfc, <xref target=	<tr><td>255</td><td>SSH_AGENT_CONSTRAIN_EXTENSION</td><td>RFC 9987, <xref target
	"constraintid" /></td></tr>	="constraintid" /></td></tr>
	</tbody>	</tbody>
	</table>	</table>
	</section>	</section>

	<section anchor="constraintexts"><name>New registry: SSH agent key constr aint extension names</name>	<section anchor="constraintexts"><name>"SSH Agent Key Constraint Extensio n Names" Registry</name>
	<t>	<t>

	This registry, titled "SSH agent key constraint extension names"	The "SSH Agent Key Constraint Extension Names" registry
	records the names used in the SSH_AGENT_CONSTRAIN_EXTENSION	records the names used in the SSH_AGENT_CONSTRAIN_EXTENSION
	constraint extension type (<xref target="contraintext" />).	constraint extension type (<xref target="contraintext" />).

	It should be created in the Secure Shell (SSH) Protocol	It is located in the "Secure Shell (SSH) Protocol
	Parameters registry group <xref target="IANA-SSH" />.	Parameters" registry group <xref target="IANA-SSH" />.
	Its initial state should be empty.	Its initial state is empty.
	Future key constraint extension name allocations shall occur via	Future key constraint extension name allocations shall occur via
	Expert Review as per <xref target="RFC8126" />.	Expert Review as per <xref target="RFC8126" />.
	</t>	</t>
	</section>	</section>

	<section anchor="sigflag"><name>New registry: SSH agent signature flags</ name>	<section anchor="sigflag"><name>"SSH Agent Signature Flags" Registry</nam e>
	<t>	<t>

	This registry, titled "SSH agent signature flags"	The "SSH Agent Signature Flags" registry
	records the values for signature request	records the values for signature request
	(SSH_AGENTC_SIGN_REQUEST) flag values.	(SSH_AGENTC_SIGN_REQUEST) flag values.

	It should be created in the Secure Shell (SSH) Protocol	It is located in the "Secure Shell (SSH) Protocol
	Parameters registry group <xref target="IANA-SSH" />.	Parameters" registry group <xref target="IANA-SSH" />.
	Its initial state should consist of the	Its initial state consists of the
	following numbers. Note that as the flags are	following numbers. Note that as the flags are
	combined by bitwise OR, all flag values must be	combined by bitwise OR, all flag values must be
	powers of two and the maximum available	powers of two and the maximum available
	flag value is 0x80000000.	flag value is 0x80000000.
	</t>	</t>
	<t>	<t>
	Future signature flag allocations shall occur via	Future signature flag allocations shall occur via
	Expert Review as per <xref target="RFC8126" />.	Expert Review as per <xref target="RFC8126" />.
	</t>	</t>
	<table>	<table>
	<thead>	<thead>
	<tr><th>Number</th><th>Identifier</th><th>Reference</th></tr>	<tr><th>Number</th><th>Identifier</th><th>Reference</th></tr>
	</thead>	</thead>
	<tbody>	<tbody>

	<tr><td>0x01</td><td>reserved</td><td>thisrfc, <xref target="sigflagnum" /></td>	<tr><td>0x01</td><td>Reserved</td><td>RFC 9987, <xref target="sigflagnum" /></td
	</tr>	></tr>
	<tr><td>0x02</td><td>SSH_AGENT_RSA_SHA2_256</td><td>thisrfc, <xref target="sigfl	<tr><td>0x02</td><td>SSH_AGENT_RSA_SHA2_256</td><td>RFC 9987, <xref target="sigf
	agnum" /></td></tr>	lagnum" /></td></tr>
	<tr><td>0x04</td><td>SSH_AGENT_RSA_SHA2_512</td><td>thisrfc, <xref target="sigfl	<tr><td>0x04</td><td>SSH_AGENT_RSA_SHA2_512</td><td>RFC 9987, <xref target="sigf
	agnum" /></td></tr>	lagnum" /></td></tr>
	</tbody>	</tbody>
	</table>	</table>
	</section>	</section>

	<section anchor="reqname"><name>New registry: SSH agent extension request names</name>	<section anchor="reqname"><name>"SSH Agent Extension Request Names" Regis try</name>
	<t>	<t>

	This registry, titled "SSH agent extension request names"	The "SSH Agent Extension Request Names" registry
	records the names used in the generic extension request	records the names used in the generic extension request
	message (SSH_AGENTC_EXTENSION).	message (SSH_AGENTC_EXTENSION).

	It should be created in the Secure Shell (SSH) Protocol	It is located in the "Secure Shell (SSH) Protocol
	Parameters registry group <xref target="IANA-SSH" />.	Parameters" registry group <xref target="IANA-SSH" />.
	Its initial state should consist of the	Its initial state consists of the
	following names.	following names.
	</t>	</t>
	<t>	<t>
	Future name allocations shall occur via	Future name allocations shall occur via
	Expert Review as per <xref target="RFC8126" />.	Expert Review as per <xref target="RFC8126" />.
	</t>	</t>
	<table>	<table>
	<thead>	<thead>
	<tr><th>Extension Name</th><th>Reference</th></tr>	<tr><th>Extension Name</th><th>Reference</th></tr>
	</thead>	</thead>
	<tbody>	<tbody>

	<tr><td>query</td><td>thisrfc, <xref target="queryext" /></td></tr>	<tr><td>query</td><td>RFC 9987, <xref target="queryext" /></td></tr>
	</tbody>	</tbody>
	</table>	</table>
	</section>	</section>

	<section title="Additions to SSH Extension Names">	<section>
		<name>Additions to the "Extension Names" Registry</name>
	<t>	<t>

	IANA is requested to insert the following entries into the	IANA has added the following entries to the
	table Extension Names <xref target="IANA-SSH-EXT" /> in	"Extension Names" registry <xref target="IANA-SSH-EXT" /> in
	the Secure Shell (SSH) Protocol Parameters registry group	the "Secure Shell (SSH) Protocol Parameters" registry group
	<xref target="IANA-SSH" />.	<xref target="IANA-SSH" />.
	</t>	</t>
	<table>	<table>
	<thead>	<thead>
	<tr><th>Extension Name</th><th>Reference</th></tr>	<tr><th>Extension Name</th><th>Reference</th></tr>
	</thead>	</thead>
	<tbody>	<tbody>

	<tr><td>agent-forward</td><td>thisrfc, <xref target="fwdext" /></td></tr>	<tr><td>agent-forward</td><td>RFC 9987, <xref target="fwdext" /></td></tr>
	</tbody>	</tbody>
	</table>	</table>
	</section>	</section>

	<section title="Additions to SSH Connection Protocol Channel Request Name	<section>
	s">	<name>Additions to the "Connection Protocol Channel Request Names" Regi
		stry</name>
	<t>	<t>

	IANA is requested to insert the following entries into the	IANA has added the following entries to the
	table Connection Protocol Channel Request Names	"Connection Protocol Channel Request Names" registry
	<xref target="IANA-SSH-CHANREQ" /> in the	<xref target="IANA-SSH-CHANREQ" /> in the

	Secure Shell (SSH) Protocol Parameters registry group	"Secure Shell (SSH) Protocol Parameters" registry group
	<xref target="IANA-SSH" />.	<xref target="IANA-SSH" />.
	</t>	</t>
	<table>	<table>
	<thead>	<thead>
	<tr><th>Request Type</th><th>Reference</th></tr>	<tr><th>Request Type</th><th>Reference</th></tr>
	</thead>	</thead>
	<tbody>	<tbody>

	<tr><td>agent-req</td><td>thisrfc, <xref target="fwdreq" /></td></tr>	<tr><td>agent-req</td><td>RFC 9987, <xref target="fwdreq" /></td></tr>
	</tbody>	</tbody>
	</table>	</table>
	</section>	</section>

	<section title="Additions to SSH Connection Protocol Channel Types">	<section>
		<name>Additions to the "Connection Protocol Channel Types" Registry</na
		me>
	<t>	<t>

	IANA is requested to insert the following entries into the	IANA has added the following entries to the
	table Connection Protocol Channel Types <xref target="IANA-SSH-CH	"Connection Protocol Channel Types" registry <xref target="IANA-S
	ANTYPE" /> under	SH-CHANTYPE" /> under the
	Secure Shell (SSH) Protocol Parameters	"Secure Shell (SSH) Protocol Parameters" registry group
	<xref target="IANA-SSH" />.	<xref target="IANA-SSH" />.
	</t>	</t>
	<table>	<table>
	<thead>	<thead>

	<tr><th>Request Type</th><th>Reference</th></tr>	<tr><th>Channel Type</th><th>Reference</th></tr>
	</thead>	</thead>
	<tbody>	<tbody>

	<tr><td>agent-connect</td><td>thisrfc, <xref target="fwdtype" /></td></tr>	<tr><td>agent-connect</td><td>RFC 9987, <xref target="fwdtype" /></td></tr>
	</tbody>	</tbody>
	</table>	</table>
	</section>	</section>
	</section>	</section>

	<section anchor="Security"><name>Security Considerations</name>	<section anchor="Security"><name>Security Considerations</name>
	<t>	<t>
	The agent is a service that is tasked with retaining and providing	The agent is a service that is tasked with retaining and providing
	controlled access to what are typically long-lived login	controlled access to what are typically long-lived login

	authentication credentials. It is by nature a sensitive and trusted	authentication credentials. It is, by nature, a sensitive and trusted
	software component. Moreover, the agent protocol itself does not	software component. Moreover, the agent protocol itself does not
	include any authentication or transport security; ability to	include any authentication or transport security; ability to
	communicate with an agent is usually sufficient to invoke it to	communicate with an agent is usually sufficient to invoke it to
	perform private key operations.	perform private key operations.
	</t>	</t>
	<t>	<t>
	Since being able to access an agent is usually sufficient to perform	Since being able to access an agent is usually sufficient to perform
	private key operations, it is critically important that the agent	private key operations, it is critically important that the agent
	only be exposed to its owner and their authorised delegates.	only be exposed to its owner and their authorised delegates.

	On Unix-like systems this may be achieved via filesystem permissions	On Unix-like systems, this may be achieved via filesystem permissions
	on the agent socket and/or identity checks on the client connected	on the agent socket and/or identity checks on the client connected

	to a socket (e.g. SO_PEERCRED on some Unix-like systems).	to a socket (e.g., SO_PEERCRED on some Unix-like systems).
	On Windows, access to a named pipe may be controlled by attaching a	On Windows, access to a named pipe may be controlled by attaching a
	security descriptor at the time of its creation.	security descriptor at the time of its creation.
	</t>	</t>
	<t>	<t>
	The primary design intention of an agent is that an attacker with	The primary design intention of an agent is that an attacker with
	unprivileged access to their victim's agent should be prevented from	unprivileged access to their victim's agent should be prevented from
	gaining a copy of any keys that have been loaded into it. This may	gaining a copy of any keys that have been loaded into it. This may

	not preclude the attacker from stealing use of those keys (e.g.	not preclude the attacker from stealing use of those keys (e.g.,
	if they have been loaded without a confirmation constraint).	if they have been loaded without a confirmation constraint).
	</t>	</t>
	<t>	<t>
	Given this, the agent should, as far as possible, prevent its	Given this, the agent should, as far as possible, prevent its

	memory being read by other processes to prevent theft of loaded keys.	memory from being read by other processes to prevent theft of loaded keys
	This typically includes disabling debugging interfaces and	.
		Typically, this includes disabling debugging interfaces and
	preventing process memory dumps on abnormal termination.	preventing process memory dumps on abnormal termination.
	</t>	</t>
	<t>	<t>

	Another, more subtle, means by which keys may be stolen are via	Another, more subtle, means by which keys may be stolen is via
	cryptographic side-channels. Private key operations may leak	cryptographic side-channels. Private key operations may leak
	information about the contents of keys via differences in timing,	information about the contents of keys via differences in timing,

	power use or by side effects in the memory subsystems (e.g. CPU	power use, or by side effects in the memory subsystems (e.g., CPU
	caches) of the host running the agent. For the case of a local	caches) of the host running the agent. For the case of a local
	attacker and an agent holding unconstrained keys, the only limit	attacker and an agent holding unconstrained keys, the only limit
	on the number of private key operations the attacker may be able	on the number of private key operations the attacker may be able
	to observe is the rate at which the CPU can perform signatures.	to observe is the rate at which the CPU can perform signatures.
	This grants the attacker an almost ideal oracle for side-channel	This grants the attacker an almost ideal oracle for side-channel
	attacks. While a full treatment of side-channel attacks is beyond	attacks. While a full treatment of side-channel attacks is beyond

	the scope of this specification, agents SHOULD use cryptographic	the scope of this specification, agents <bcp14>SHOULD</bcp14> use cryptog
	implementations that are resistant to side-channel attacks and MAY	raphic
		implementations that are resistant to side-channel attacks and <bcp14>MAY
		</bcp14>
	take additional measures to hide the actual time spent processing	take additional measures to hide the actual time spent processing
	private key operations. Failure to do so may expose keys to recovery	private key operations. Failure to do so may expose keys to recovery
	through these side-channels.	through these side-channels.
	</t>	</t>
	<t>	<t>
	Forwarding access to a local agent over an SSH connection	Forwarding access to a local agent over an SSH connection
	(<xref target="fwd" />) inherently creates a transitive trust	(<xref target="fwd" />) inherently creates a transitive trust

	relationship. SSH implementations SHOULD NOT forward use of an agent	relationship. SSH implementations <bcp14>SHOULD NOT</bcp14> forward use o
	by default and users SHOULD NOT forward use of an agent to hosts that	f an agent
		by default, and users <bcp14>SHOULD NOT</bcp14> forward use of an agent t
		o hosts that
	are not fully trusted, as doing so could expose access to the user's	are not fully trusted, as doing so could expose access to the user's

	keys to attackers on remote hosts. Agents SHOULD implement additional	keys to attackers on remote hosts. Agents <bcp14>SHOULD</bcp14> implement
	controls over key visibility and use for forwarded agent connections,	additional
	otherwise the user has only an all-or-nothing choice over whether to	controls over key visibility and use for forwarded agent connections;
		otherwise, the user has only an all-or-nothing choice about whether to
	forward an agent.	forward an agent.
	</t>	</t>


		<!--[rfced] How would we separate this slashed phrase?

		Original:
		Implementation of token/smartcard-hosted keys...

		Perhaps A:

		Implementation of keys hosted by a token or smartcard....

		Perhaps B:
		Implementation of token keys or smartcard-hosted keys...
		-->

	<t>	<t>

	Implementation of token/smartcard-hosted keys requires some care too.	Implementation of token/smartcard-hosted keys requires some care, too.
	On some systems, tokens may invoked by providing a path to shared	On some systems, tokens may be invoked by providing a path to a shared
	library that must be loaded to make use of keys hosted on the device	library that must be loaded to make use of keys hosted on the device
	(a path to a library for a particular PKCS#11 module, for example).	(a path to a library for a particular PKCS#11 module, for example).
	Loading a shared library on most platforms implies automatic	Loading a shared library on most platforms implies automatic
	execution of code in that library in the address space of	execution of code in that library in the address space of
	the process that loads it.	the process that loads it.

	To avoid loading of potentially-hostile code, agents that support	To avoid the loading of potentially hostile code, agents that support
	loading token-hosted keys via library path SHOULD ensure that only	loading token-hosted keys via a library path <bcp14>SHOULD</bcp14> ensur
		e that only
	trusted token provider libraries are loadable.	trusted token provider libraries are loadable.

	Additionally agents SHOULD ensure that loaded token library code	Additionally, agents <bcp14>SHOULD</bcp14> ensure that loaded token libra
	cannot gain access to other keys loaded in the agent and MAY disallow	ry code
		cannot gain access to other keys loaded in the agent and <bcp14>MAY</bcp1
		4> disallow
	remote clients from loading token keys entirely.	remote clients from loading token keys entirely.

	Protection for existing keys from tokey library code may be achieved	Protection for existing keys from a token library code may be achieved
	by loading the token library into a separate process to the agent	by loading the token library into a separate process to the agent
	and arranging for the agent to invoke token operations to this	and arranging for the agent to invoke token operations to this
	process via IPC.	process via IPC.
	</t>	</t>
	<t>	<t>
	Finally, with respect to the agent locking functionality in	Finally, with respect to the agent locking functionality in

	<xref target="lock" />, an agent SHOULD take countermeasures	<xref target="lock" />, an agent <bcp14>SHOULD</bcp14> take countermeasur
	against brute-force guessing attacks against the pass-phrase.	es
		against brute-force guessing attacks on the passphrase.
	This may take the form of enforced delays when an unlock attempt is	This may take the form of enforced delays when an unlock attempt is
	made with an incorrect password (potentially increasing for subsequent	made with an incorrect password (potentially increasing for subsequent
	failures), a lockout period where the agent refuses to accept further	failures), a lockout period where the agent refuses to accept further

	requests after some threshold of failed unlock attempts has been made	requests after some threshold of failed unlock attempts has been made,
	and/or deletion of all keys held by the agent after a threshold of	and/or deletion of all keys held by the agent after a threshold of
	failed unlock attempts.	failed unlock attempts.
	</t>	</t>
	</section>	</section>

	<section removeInRFC="true" anchor="implstatus"><name>Implementation Status</nam
	e>
	<t>
	Note to editor: please also remove the orphaned reference to RFC7942.
	</t>
	<t>
	This section records the status of known implementations of the
	protocol defined by this specification at the time of posting of
	this Internet-Draft, and is based on a proposal described in
	<xref target="RFC7942" />. The description of implementations in
	this section is intended to assist the IETF in its decision processes
	in progressing drafts to RFCs. Please note that the listing of any
	individual implementation here does not imply endorsement by the
	IETF. Furthermore, no effort has been spent to verify the
	information presented here that was supplied by IETF contributors.
	This is not intended as, and must not be construed to be, a
	catalog of available implementations or their features. Readers
	are advised to note that other implementations may exist.
	</t>
	<t>
	According to <xref target="RFC7942" />, "this will allow reviewers
	and working groups to assign due consideration to documents that
	have the benefit of running code, which may serve as evidence of
	valuable experimentation and feedback that have made the implemented
	protocols more mature. It is up to the individual working groups
	to use this information as they see fit".
	</t>
	<t>
	The following projects maintain an implementation of this
	protocol:
	</t>
	<dl>
	<dt>OpenSSH</dt>
	<dd>
	<t>
	OpenSSH is the originating implementation of this protocol and
	has supported it since 2000.
	</t>
	<t>
	Website: https://www.openssh.com/
	</t>
	</dd>


	<dt>PuTTY</dt>
	<dd>
	<t>
	PuTTY is a popular SSH client implementation for multiple
	platforms that has included a compatible agent client since
	2001.
	</t>
	<t>
	Website: https://www.chiark.greenend.org.uk/~sgtatham/putty/
	</t>
	</dd>

	<dt>Dropbear</dt>
	<dd>
	<t>
	Dropbear is an SSH client and server implementation for
	Unix-like systems. It has supported the agent protocol since
	2005.
	</t>
	<t>
	Website: https://matt.ucc.asn.au/dropbear/dropbear.html
	</t>
	</dd>

	<dt>Paramiko</dt>
	<dd>
	<t>
	Paramiko is an SSH client and server implementation in the
	Python programming language. It has supported an agent protocol
	implementation since 2005.
	</t>
	<t>
	Website: https://www.paramiko.org/
	</t>
	</dd>

	<dt>Golang x/crypto/ssh/agent</dt>
	<dd>
	<t>
	The Go programming language project has supported an
	implementation of this protocol in its external "x" repository
	since 2015.
	</t>
	<t>
	Website: https://pkg.go.dev/golang.org/x/crypto/ssh/agent
	</t>
	</dd>
	</dl>
	<t>
	This list is not exhaustive.
	</t>
	</section>
	</middle>	</middle>

	<back>	<back>
	<references>	<references>
	<name>References</name>	<name>References</name>
	<references><name>Normative References</name>	<references><name>Normative References</name>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referenc e.RFC.2119.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referenc e.RFC.2119.xml" />
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referenc e.RFC.4251.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referenc e.RFC.4251.xml" />
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referenc e.RFC.4253.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referenc e.RFC.4253.xml" />
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referenc e.RFC.4254.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referenc e.RFC.4254.xml" />
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referenc e.RFC.5656.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referenc e.RFC.5656.xml" />
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referenc e.RFC.8032.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referenc e.RFC.8032.xml" />
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referenc e.RFC.8174.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referenc e.RFC.8174.xml" />
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referenc e.RFC.8308.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referenc e.RFC.8308.xml" />
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referenc e.RFC.8332.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referenc e.RFC.8332.xml" />
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referenc e.RFC.8709.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referenc e.RFC.8709.xml" />

	<reference anchor="FIPS.186-4">
	<front>	<reference anchor="FIPS.186-4">
	<title>Digital Signature Standard (DSS)</title>	<front>
	<author>	<title>Digital Signature Standard (DSS)</title>
	<organization>	<author>
	National Institute of	<organization abbrev="NIST">National Institute of Standard
	Standards and Technology	s and Technology</organization>
	</organization>	</author>
	</author>	<date month="June" year="2013"/>
	<date month="July" year="2013" />	</front>
	</front>	<seriesInfo name="NIST FIPS" value="186-4"/>
	<refcontent>FIPS PUB 186-4</refcontent>	<seriesInfo name="DOI" value="10.6028/NIST.FIPS.186-4"/>
	<seriesInfo name="DOI" value="10.6028/NIST.FIPS.186-4"/>	</reference>
	</reference>
	<reference anchor="FIPS.186-5">	<reference anchor="FIPS.186-5">
	<front>	<front>
	<title>Digital Signature Standard (DSS)</title>	<title>Digital Signature Standard (DSS)</title>
	<author>	<author>
	<organization>	<organization abbrev="NIST">National Institute of Standard
	National Institute of	s and Technology</organization>
	Standards and Technology	</author>
	</organization>	<date month="February" year="2023"/>
	</author>	</front>
	<date month="February" year="2023" />	<seriesInfo name="NIST FIPS" value="186-5"/>
	</front>	<seriesInfo name="DOI" value="10.6028/NIST.FIPS.186-5"/>
	<refcontent>FIPS PUB 186-5</refcontent>	</reference>
	<seriesInfo name="DOI" value="10.6028/NIST.FIPS.186-5"/>
	</reference>
	</references>	</references>

	<references><name>Informative References</name>	<references><name>Informative References</name>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referenc e.RFC.4252.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referenc e.RFC.4252.xml" />

	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referenc e.RFC.7942.xml" />
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referenc e.RFC.8126.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referenc e.RFC.8126.xml" />
	<reference anchor="IANA-SSH-CHANREQ" target="https://www.iana.org /assignments/ssh-parameters/"><front>	<reference anchor="IANA-SSH-CHANREQ" target="https://www.iana.org /assignments/ssh-parameters/"><front>
	<title>Connection Protocol Channel Types</title>	<title>Connection Protocol Channel Types</title>
	<author>	<author>
	<organization>IANA</organization>	<organization>IANA</organization>
	</author>	</author>
	</front></reference>	</front></reference>

	<reference anchor="IANA-SSH" target="https://www.iana.org/assignm ents/ssh-parameters/ssh-parameters.xhtml"><front>	<reference anchor="IANA-SSH" target="https://www.iana.org/assignm ents/ssh-parameters/"><front>
	<title>Secure Shell (SSH) Protocol Parameters</title>	<title>Secure Shell (SSH) Protocol Parameters</title>
	<author>	<author>
	<organization>IANA</organization>	<organization>IANA</organization>
	</author>	</author>
	</front></reference>	</front></reference>
	<reference anchor="IANA-SSH-CHANTYPE" target="https://www.iana.or g/assignments/ssh-parameters/"><front>	<reference anchor="IANA-SSH-CHANTYPE" target="https://www.iana.or g/assignments/ssh-parameters/"><front>
	<title>Extension Names</title>	<title>Extension Names</title>
	<author>	<author>
	<organization>IANA</organization>	<organization>IANA</organization>
	</author>	</author>

	skipping to change at line 1560 ¶	skipping to change at line 1512 ¶
	<author>	<author>
	<organization>IANA</organization>	<organization>IANA</organization>
	</author>	</author>
	</front></reference>	</front></reference>
	<reference anchor="IANA-PUBKEYS" target="https://www.iana.org/ass ignments/ssh-parameters/"><front>	<reference anchor="IANA-PUBKEYS" target="https://www.iana.org/ass ignments/ssh-parameters/"><front>
	<title>Public Key Algorithm Names</title>	<title>Public Key Algorithm Names</title>
	<author>	<author>
	<organization>IANA</organization>	<organization>IANA</organization>
	</author>	</author>
	</front></reference>	</front></reference>

	<!-- XXX bibtex gives me xml2rfc errors -->
	<!-- <xi:include href="https://datatracker.ietf.org/doc/bibxml3/d	<!-- [rfced] Note that the reference [I-D.ietf-secsh-agent] has been
	raft-ietf-secsh-agent-02.xml" /> -->	removed as it had no corresponding citation in the document.
	<reference anchor="draft-ietf-secsh-agent-02" target="https://dat	Please let us know any objections.
	atracker.ietf.org/doc/html/draft-ietf-secsh-agent-02"><front>	-->
	<title>Secure Shell Authentication Agent Protocol</title>
	<author surname="Ylonen" fullname="Tatu Ylonen" />
	<author surname="Rinne" fullname="Timo J. Rinne" />
	<author surname="Lehtinen" fullname="Sami Lehtinen" />
	<date year="2004" month="January"/>
	<abstract>
	<t>
	This document describes the Secure Shell
	authentication agent protocol (i.e., the
	protocol used between a client requesting
	authentication and the authentication agent).
	This protocol usually runs in a
	machine-spe-cific local channel or over a
	forwarded authentication channel. It is
	assumed that the channel is trusted, so no
	protection for the communications channel
	is provided by this protocol.
	</t>
	</abstract>
	</front></reference>
	</references>	</references>
	</references>	</references>


	<!--
	<section><name>Appendix 1</name>
	<t>
	This becomes an Appendix
	</t>
	</section>

	<section anchor="Acknowledgments" numbered="false"><name>Acknowledgments</name>	<section anchor="Acknowledgments" numbered="false"><name>Acknowledgments</name>
	<t>	<t>
	This protocol was designed and first implemented by	This protocol was designed and first implemented by

	Markus Friedl, based on a similar protocol for an agent	<contact fullname="Markus Friedl"/>, based on a similar protocol for an a
	to support the legacy SSH version 1 by Tatu Ylonen.	gent
		to support the legacy SSH version 1 by <contact fullname="Tatu Ylonen"/>.
	</t>	</t>
	<t>	<t>

	Thanks to Simon Tatham, Niels Möller, James Spencer, Simon Josefsson,	Thanks to <contact fullname="Simon Tatham"/>, <contact fullname="Niels
	Matt Johnston, Jakub Jelen, Rich Salz, Caspar Schutijser,	Möller"/>, <contact fullname="James Spencer"/>, <contact
	Florian Obser, Martin Thomson, Deb Cooley and Tero Kivinen who reviewed	fullname="Simon Josefsson"/>, <contact fullname="Matt Johnston"/>,
	and helped improve this document.	<contact fullname="Jakub Jelen"/>, <contact fullname="Rich Salz"/>,
		<contact fullname="Caspar Schutijser"/>, <contact fullname="Florian
		Obser"/>, <contact fullname="Martin Thomson"/>, <contact fullname="Deb
		Cooley"/>, and <contact fullname="Tero Kivinen"/> who reviewed and
		helped improve this document.
	</t>	</t>
	</section>	</section>


	<!--	<!-- [rfced] Would you like the references to be alphabetized or left
	<section anchor="Contributors" numbered="false"><name>Contributors</name>	in their current order?
	<t>Thanks to all of the contributors.</t>	-->
	<contact fullname="Jane Doe" initials="J" surname="Doe">
	<organization>Acme</organization>	<!--[rfced] Please note that we have expanded abbreviations on first
	<address>	use. Please review these expansions for accuracy. -->
	<email>jdoe@example.com</email>
	</address>	<!-- [rfced] We had the following questions/comments regarding
	</contact>	responses from the document intake email:
	</section>
		a) Regarding <sourcecode>:

		"This document has none of the former, but plenty of the latter. The
		stuff in <sourcecode> blocks are message definitions. Did I use the
		wrong element type?"

		None of the <sourcecode> pieces have a type set. The only type with
		"message" in the name at the list (see below) is "http-message".

		Please let us know if you would like to set a <sourcecode> type for
		each instance of the sourcecode element. If the current list of
		preferred values for "type"
		(https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types)
		does not contain an applicable type, then feel free to let us know.

		Also, it is acceptable to leave the "type" attribute not set. Please
		let us know if that is your choice.

		b) Regarding using quotes for protocol message field names and literal
		strings:

		"Literal strings that appear in protocol messages should be in double
		quotes both in protocol message definitions and in descriptive text.

		Protocol message field names should be in double quotes when they
		appear in descriptive text, but not in the protocol message
		definition."

		It seemed the byte names (e.g., SSH_AGENTC_ADD_ID_CONSTRAINED) were
		never in quotes. We have left these as they were.

		Please review our updates and let us know if any further changes are
		necessary (as these same terms seem to be used in the general sense,
		this was not always clear to us).

		-->

		<!--[rfced] We had the following questions/comments related to
		terminology use throughout the document:

		a) Should the use of "type" and "key type" be made uniform here?

		type "ssh-dss" vs. key type "ssh-rsa"

		b) We see both "Windows Named Pipe" and "On Windows, access to a named
		pipe". Please review and let us know if updates should be made for
		uniformity.
		-->

		<!-- [rfced] Please review the "Inclusive Language" portion of the
		online Style Guide
		<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
		and let us know if any changes are needed. Updates of this
		nature typically result in more precise language, which is
		helpful for readers.

		Note that our script did not flag any words in particular, but this
		should still be reviewed as a best practice.

	-->	-->

	</back>	</back>
	</rfc>	</rfc>

End of changes. 283 change blocks.
	703 lines changed or deleted	736 lines changed or added
This html diff was produced by rfcdiff 1.48.