rfc9367.original.xml		rfc9367.xml
	<?xml version='1.0' encoding='utf-8'?>		<?xml version="1.0" encoding="UTF-8"?>
			<!-- draft submitted in xml v3 -->
	<!DOCTYPE rfc [		<!DOCTYPE rfc [
	<!ENTITY nbsp "&#160;">		<!ENTITY nbsp "&#160;">
	<!ENTITY zwsp "&#8203;">		<!ENTITY zwsp "&#8203;">
	<!ENTITY nbhy "&#8209;">		<!ENTITY nbhy "&#8209;">
	<!ENTITY wj "&#8288;">		<!ENTITY wj "&#8288;">
	]>		]>
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-smyshlyaev-tls13		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-smyshlyaev-tls13-
	-gost-suites-08" ipr="trust200902" obsoletes="" updates="" submissionType="IETF		gost-suites-08" number="9367" submissionType="independent" category="info" ipr="
	" category="info"		trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth="4
	xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" vers		" symRefs="true" sortRefs="true" version="3">
	ion="3">
	<front>		<front>
	<title abbrev="GOST Cipher Suites for TLS 1.3">		<title abbrev="GOST Cipher Suites for TLS 1.3">
	GOST Cipher Suites for Transport Layer Security (TLS) Protocol Versi on 1.3		GOST Cipher Suites for Transport Layer Security (TLS) Protocol Versi on&nbsp;1.3
	</title>		</title>
	<seriesInfo name="Internet-Draft" value="draft-smyshlyaev-tls13-gost-suites-		<seriesInfo name="RFC" value="9367"/>
	08"/>
	<author fullname="Stanislav Smyshlyaev" initials="S.V." role="editor" surnam		<author fullname="Stanislav Smyshlyaev" initials="S." role="editor" surname=
	e="Smyshlyaev">		"Smyshlyaev">
	<organization>CryptoPro</organization>		<organization>CryptoPro</organization>
	<address>		<address>
	<postal>		<postal>
	<street>18, Suschevsky val </street>		<street>18, Suschevsky val</street>
	<city>Moscow</city>		<city>Moscow</city>
	<code>127018</code>		<code>127018</code>
	<country>Russian Federation</country>		<country>Russian Federation</country>
	</postal>		</postal>
	<phone>+7 (495) 995-48-20</phone>		<phone>+7 (495) 995-48-20</phone>
	<email>svs@cryptopro.ru</email>		<email>svs@cryptopro.ru</email>
	</address>		</address>
	</author>		</author>
	<author fullname="Evgeny Alekseev" initials="E.K." surname="Alekseev">		<author fullname="Evgeny Alekseev" initials="E." surname="Alekseev">
	<organization>CryptoPro</organization>		<organization>CryptoPro</organization>
	<address>		<address>
	<postal>		<postal>
	<street>18, Suschevsky val </street>		<street>18, Suschevsky val</street>
	<city>Moscow</city>		<city>Moscow</city>
	<code>127018</code>		<code>127018</code>
	<country>Russian Federation</country>		<country>Russian Federation</country>
	</postal>		</postal>
	<email>alekseev@cryptopro.ru</email>		<email>alekseev@cryptopro.ru</email>
	</address>		</address>
	</author>		</author>
	<author fullname="Ekaterina Griboedova" initials="E.S." surname="Griboedova" >		<author fullname="Ekaterina Griboedova" initials="E." surname="Griboedova">
	<organization>CryptoPro</organization>		<organization>CryptoPro</organization>
	<address>		<address>
	<postal>		<postal>
	<street>18, Suschevsky val </street>		<street>18, Suschevsky val</street>
	<city>Moscow</city>		<city>Moscow</city>
	<code>127018</code>		<code>127018</code>
	<country>Russian Federation</country>		<country>Russian Federation</country>
	</postal>		</postal>
	<email>griboedova.e.s@gmail.com</email>		<email>griboedovaekaterina@gmail.com</email>
	</address>		</address>
	</author>		</author>
	<author fullname="Alexandra Babueva" initials="A.A." surname="Babueva">		<author fullname="Alexandra Babueva" initials="A." surname="Babueva">
	<organization>CryptoPro</organization>		<organization>CryptoPro</organization>
	<address>		<address>
	<postal>		<postal>
	<street>18, Suschevsky val </street>		<street>18, Suschevsky val</street>
	<city>Moscow</city>		<city>Moscow</city>
	<code>127018</code>		<code>127018</code>
	<country>Russian Federation</country>		<country>Russian Federation</country>
	</postal>		</postal>
	<email>babueva@cryptopro.ru</email>		<email>babueva@cryptopro.ru</email>
	</address>		</address>
	</author>		</author>
	<author fullname="Lidiia Nikiforova" initials="L.O." surname="Nikiforova">		<author fullname="Lidiia Nikiforova" initials="L." surname="Nikiforova">
	<organization>CryptoPro</organization>		<organization>CryptoPro</organization>
	<address>		<address>
	<postal>		<postal>
	<street>18, Suschevsky val </street>		<street>18, Suschevsky val</street>
	<city>Moscow</city>		<city>Moscow</city>
	<code>127018</code>		<code>127018</code>
	<country>Russian Federation</country>		<country>Russian Federation</country>
	</postal>		</postal>
	<email>nikiforova@cryptopro.ru</email>		<email>nikiforova@cryptopro.ru</email>
	</address>		</address>
	</author>		</author>
	<date year="2022"/>		<date year="2023" month="February" />
	<!--если не указываем число и месяц, они подставляются автоматически-->
	<area>General</area>		<keyword>GOST</keyword>
	<!--как в rfc7748-->		<keyword>cipher suite</keyword>
	<workgroup>Network Working Group</workgroup>		<keyword>TLS 1.3</keyword>
	<keyword>GOST, cipher suite, TLS 1.3, signature scheme</keyword>		<keyword>signature scheme</keyword>
	<abstract>		<abstract>
	<t>		<t>
	The purpose of this document is to make the Russian cryptographi		The purpose of this document is to make the Russian
	c standards		cryptographic standards available to the Internet community
	available to the Internet community for their implementation in		for their implementation in the Transport Layer Security (TLS)
	the Transport Layer Security (TLS)
	Protocol Version 1.3.		Protocol Version 1.3.
	</t>		</t>
	<t>		<t>
	This document defines the cipher suites, signature schemes, and		This document defines the cipher suites, signature schemes,
	key		and key exchange mechanisms for using Russian cryptographic
	exchange mechanisms for using Russian cryptographic standards, c		standards, called GOST algorithms, with TLS Version 1.3. Additi
	alled		onally, this document
	GOST algorithms, with Transport Layer Security (TLS) Version 1.3		specifies a profile of TLS 1.3 with GOST algorithms to
	.		facilitate interoperable implementations. The IETF has not
	Additionally, this document specifies a profile of TLS 1.3 with		endorsed the cipher suites, signature schemes, or key
	GOST		exchange mechanisms described in this document.
	algorithms to facilitate interoperable implementations. The IETF
	has not endorsed the cipher suites,
	signature schemes, key exchange mechanism described in this docu
	ment.
	</t>		</t>
	</abstract>		</abstract>
	</front>		</front>
	<middle>		<middle>
	<section anchor="Introduction" numbered="true" toc="default">		<section anchor="Introduction" numbered="true" toc="default">
	<name>Introduction</name>		<name>Introduction</name>
	<t>		<t>
	This document defines four new cipher suites (the TLS13_GOST cip		This document defines four new cipher suites (the TLS13_GOST
	her suites) and seven new signature schemes (the TLS13_GOST signature schemes)		cipher suites) and seven new signature schemes (the TLS13_GOST
	for the Transport Layer Security (TLS) Protocol Version 1.3, tha		signature schemes) for the Transport Layer Security (TLS)
	t are based on Russian cryptographic standards		Protocol Version 1.3 that are based on Russian cryptographic
	GOST R 34.12-2015 <xref target="RFC7801" format="default"/>, GO		standards GOST R 34.12-2015 <xref target="RFC7801"
	ST R 34.11-2012 <xref target="RFC6986" format="default"/> and GOST R 34.10-2012		format="default"/>, GOST R 34.11-2012 <xref target="RFC6986"
	<xref target="RFC7091" format="default"/>.		format="default"/>, and GOST R 34.10-2012 <xref
			target="RFC7091" format="default"/>.
	</t>		</t>
	<t>		<t>
	The TLS13_GOST cipher suites (see <xref target="CipherSuites" fo rmat="default"/>) have the following values:		The TLS13_GOST cipher suites (see <xref target="CipherSuites" fo rmat="default"/>) have the following values:
	</t>		</t>
	<ul empty="true" spacing="normal">		<ul spacing="normal" empty="true">
	<li>		<li>TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L = {0xC1, 0x03}</li>
	TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L = {0xC1, 0x03}		<li>TLS_GOSTR341112_256_WITH_MAGMA_MGM_L = {0xC1, 0x04}</li> <li>TLS_GOST
	;		R341112_256_WITH_KUZNYECHIK_MGM_S = {0xC1, 0x05}</li>
	TLS_GOSTR341112_256_WITH_MAGMA_MGM_L = {0xC1, 0x04};		<li>TLS_GOSTR341112_256_WITH_MAGMA_MGM_S = {0xC1, 0x06}
	TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S = {0xC1, 0x05}
	;
	TLS_GOSTR341112_256_WITH_MAGMA_MGM_S = {0xC1, 0x06}.
	</li>		</li>
	</ul>		</ul>
	<t>		<t>
	Each TLS13_GOST cipher suite specifies a pair (record protection		Each TLS13_GOST cipher suite specifies a pair (record
	algorithm, hash algorithm) such that:		protection algorithm, hash algorithm) such that:
	</t>		</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>
	The record protection algorithm is the AEAD algorithm (s		The record protection algorithm is the Authenticated Enc
	ee <xref target="AEAD" format="default"/>) based on the GOST R 34.12-2015 block		ryption with Associated Data (AEAD) algorithm
	cipher		(see <xref target="AEAD" format="default"/>) based on
	<xref target="RFC7801" format="default"/> in the Multili		the GOST R 34.12-2015 block cipher <xref
	near Galois Mode (MGM) <xref target="RFC9058" format="default"/> and the externa		target="RFC7801" format="default"/> in the Multilinear
	l re-keying approach		Galois Mode (MGM) <xref target="RFC9058"
	(see <xref target="RFC8645" format="default"/>) intended		format="default"/> and the external re-keying approach
	for increasing the lifetime of symmetric keys used to protect records.		(see <xref target="RFC8645" format="default"/>)
			intended for increasing the lifetime of symmetric keys
			used to protect records.
	</li>		</li>
	<li>		<li>
	The hash algorithm is the GOST R 34.11-2012 algorithm <x ref target="RFC6986" format="default"/>.		The hash algorithm is the GOST R 34.11-2012 algorithm <x ref target="RFC6986" format="default"/>.
	</li>		</li>
	</ul>		</ul>
	<t>		<t>
	Note: The TLS13_GOST cipher suites are divided into two types (d		Note: The TLS13_GOST cipher suites are divided into two types: t
	epending on the key lifetime limitations, see <xref target="TLSTREE" format="def		he "_S" (strong) cipher suites and the
	ault"/> and		"_L" (light) cipher suites (depending on the key lifetime
	<xref target="SNMAX" format="default"/>): the "_S" (strong) ciph		limitations, see Sections <xref target="TLSTREE"
	er suites and the "_L" (light) cipher suites.		format="counter"/> and
			<xref target="SNMAX" format="counter"/>).
	</t>		</t>
	<t>		<t>
	The TLS13_GOST signature schemes have the following values:		The TLS13_GOST signature schemes have the following values:
	</t>		</t>
	<ul empty="true" spacing="normal">		<ul empty="true" spacing="normal">
	<li>		<li>
	gostr34102012_256a = 0x0709;		gostr34102012_256a = 0x0709
	</li>		</li>
	<li>		<li>
	gostr34102012_256b = 0x070A;		gostr34102012_256b = 0x070A
	</li>		</li>
	<li>		<li>
	gostr34102012_256c = 0x070B;		gostr34102012_256c = 0x070B
	</li>		</li>
	<li>		<li>
	gostr34102012_256d = 0x070C;		gostr34102012_256d = 0x070C
	</li>		</li>
	<li>		<li>
	gostr34102012_512a = 0x070D;		gostr34102012_512a = 0x070D
	</li>		</li>
	<li>		<li>
	gostr34102012_512b = 0x070E;		gostr34102012_512b = 0x070E
	</li>		</li>
	<li>		<li>
	gostr34102012_512c = 0x070F.		gostr34102012_512c = 0x070F
	</li>		</li>
	</ul>		</ul>
	<t>		<t>
	Each TLS13_GOST signature scheme specifies a pair (signature alg orithm, elliptic curve) such that:		Each TLS13_GOST signature scheme specifies a pair (signature alg orithm, elliptic curve) such that:
	</t>		</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>
	The signature algorithm is the GOST R 34.10-2012 algorit hm <xref target="RFC7091" format="default"/>.		The signature algorithm is the GOST R 34.10-2012 algorit hm <xref target="RFC7091" format="default"/>.
	</li>		</li>
	<li>		<li>
	The elliptic curve is one of the curves defined in <xref target="EllipticCurve" format="default"/>.		The elliptic curve is one of the curves defined in <xref target="EllipticCurve" format="default"/>.
	</li>		</li>
	</ul>		</ul>
	<t>		<t>
	Also, this document specifies the key exchange mechanism with GO ST algorithms for TLS 1.3 protocol (see <xref target="KE" format="default"/>).		This document also specifies the key exchange mechanism with GOS T algorithms for the TLS 1.3 protocol (see <xref target="KE" format="default"/>) .
	</t>		</t>
	<t>		<t>
	Additionally, this document specifies a TLS13_GOST profile of th e TLS 1.3 protocol with GOST algorithms so that implementers can produce interop erable implementations.		Additionally, this document specifies a TLS13_GOST profile of th e TLS 1.3 protocol with GOST algorithms so that implementers can produce interop erable implementations.
	It uses TLS13_GOST cipher suites, TLS13_GOST signature schemes, key exchange mechanism that defined in this document.		It uses TLS13_GOST cipher suites, TLS13_GOST signature schemes, and key exchange mechanisms that are defined in this document.
	</t>		</t>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>Conventions Used in This Document</name>		<name>Conventions Used in This Document</name>
	<t>		<t>
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NO		The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
	T", "SHOULD", "SHOULD NOT",		IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	"RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this		NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
	document are to be interpreted		RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	as described in BCP 14 <xref target="RFC2119" format="default"/>		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
	<xref target="RFC8174" format="default"/> when, and only when,		be interpreted as
	they appear in all capitals, as shown here.		described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
	</t>		when, and only when, they appear in all capitals, as shown here.
			</t>
	</section>		</section>
	<section anchor="Definition" numbered="true" toc="default">		<section anchor="Definition" numbered="true" toc="default">
	<name>Basic Terms and Definitions</name>		<name>Basic Terms and Definitions</name>
	<t>		<t>
	This document follows the terminology from <xref target="I-D.ietf-tls- rfc8446bis" format="default"/> for "main secret".		This document follows the terminology from <xref target="I-D.ietf-tls- rfc8446bis" format="default"/> for "main secret".
	</t>		</t>
	<t>		<t>
	This document uses the following terms and definitions for the sets and operations		This document uses the following terms and definitions for the sets and operations
	on the elements of these sets:		on the elements of these sets:
	</t>		</t>
	<dl newline="false" spacing="normal" indent="16">		<dl newline="false" spacing="normal" indent="16">
	<dt>B_t</dt>		<dt>B_t</dt>
	<dd>		<dd>
	the set of byte strings of length t, t &gt;= 0, for t =		The set of byte strings of length t, t &gt;= 0; for t
	0 the		= 0, the B_t set consists of a single empty string of
	B_t set consists of a single empty string of zero length		zero length. If A is an element in B_t, then A =
	.		(a_1, a_2, ... , a_t), where a_1, a_2, ... , a_t are
	If A is an element in B_t, then A = (a_1, a_2,		in {0, ... , 255}.
	... , a_t), where a_1, a_2, ... , a_t are in {0, ... , 2
	55};
	</dd>		</dd>
	<dt>B*</dt>		<dt>B*</dt>
	<dd>		<dd>
	the set of all byte strings of a finite length		The set of all byte strings of a finite length
	(hereinafter referred to as strings), including the empt		(hereinafter referred to as strings) including the
	y		empty string.
	string;
	</dd>		</dd>
	<dt>A[i..j]</dt>		<dt>A[i..j]</dt>
	<dd>		<dd>
	the string A[i..j] = (a_i, a_{i+1}, ... , a_j) in B_{j-i +1}, where A = (a_1, a_2, ... , a_t) in B_t and 1&lt;=i&lt;=j&lt;=t;		The string A[i..j] = (a_i, a_{i+1}, ... , a_j) in B_{j-i +1}, where A = (a_1, a_2, ... , a_t) in B_t and 1&lt;=i&lt;=j&lt;=t.
	</dd>		</dd>
	<dt>A[i]</dt>		<dt>A[i]</dt>
	<dd>		<dd>
	the integer a_i in {0, ... , 255}, where A = (a_1, a_2, ... , a_t) in B_t and 1&lt;=i&lt;=t;		The integer a_i in {0, ... , 255}, where A = (a_1, a_2, ... , a_t) in B_t and 1&lt;=i&lt;=t.
	</dd>		</dd>
	<dt>|A|</dt>		<dt>|A|</dt>
	<dd>		<dd>
	the length of the byte string A in bytes;		The length of the byte string A in bytes.
	</dd>		</dd>
	<dt>A | C</dt>		<dt>A | C</dt>
	<dd>		<dd>
	the concatenation of strings A and C both belonging to B		The concatenation of strings A and C both belonging to
	*, i.e.,		B*; i.e., a string in B_{|A|+|C|}, where the left
	a string in B_{|A|+|C|}, where the left substring in		substring in B_|A| is equal to A and the right
	B_|A| is equal to A, and the right substring in B_|C| is		substring in B_|C| is equal to C.
	equal to C;
	</dd>		</dd>
	<dt>i &amp; j</dt>		<dt>i &amp; j</dt>
	<dd>		<dd>
	bitwise AND of integers i and j;		Bitwise AND of integers i and j.
	</dd>		</dd>
	<dt>STR_t</dt>		<dt>STR_t</dt>
	<dd>		<dd>
	the transformation that maps an integer i = 256<sup>t-1< /sup> * i_1 + ... + 256 * i_{t-1} + i_t		The transformation that maps an integer i = 256<sup>t-1< /sup> * i_1 + ... + 256 * i_{t-1} + i_t
	into the byte string STR_t(i) = (i_1, ... , i_t) in B_t		into the byte string STR_t(i) = (i_1, ... , i_t) in B_t
	(the interpretation of the integer as a byte string in b ig-endian format);		(the interpretation of the integer as a byte string in b ig-endian format).
	</dd>		</dd>
	<dt>str_t</dt>		<dt>str_t</dt>
	<dd>		<dd>
	the transformation that maps an integer i = 256<sup>t-1< /sup> * i_t + ... + 256 * i_2 + i_1		The transformation that maps an integer i = 256<sup>t-1< /sup> * i_t + ... + 256 * i_2 + i_1
	into the byte string str_t(i) = (i_1, ... , i_t) in B_t		into the byte string str_t(i) = (i_1, ... , i_t) in B_t
	(the interpretation of the integer as a byte string in l ittle-endian format);		(the interpretation of the integer as a byte string in l ittle-endian format).
	</dd>		</dd>
	<dt>k</dt>		<dt>k</dt>
	<dd>		<dd>
	the length of the block cipher key in bytes;		The length of the block cipher key in bytes.
	</dd>		</dd>
	<dt>n</dt>		<dt>n</dt>
	<dd>		<dd>
	the length of the block cipher block in bytes;		The length of the block cipher block in bytes.
	</dd>		</dd>
	<dt>IVlen</dt>		<dt>IVlen</dt>
	<dd>		<dd>
	the length of the initialization vector in bytes;		The length of the initialization vector in bytes.
	</dd>		</dd>
	<dt>S</dt>		<dt>S</dt>
	<dd>		<dd>
	the length of the authentication tag in bytes;		The length of the authentication tag in bytes.
	</dd>		</dd>
	<dt>E_i</dt>		<dt>E_i</dt>
	<dd>		<dd>
	the elliptic curve indicated by the client in "supported _groups" extension;		The elliptic curve indicated by the client in "supported _groups" extension.
	</dd>		</dd>
	<dt>O_i</dt>		<dt>O_i</dt>
	<dd>		<dd>
	the zero point of the elliptic curve E_i;		The zero point of the elliptic curve E_i.
	</dd>		</dd>
	<dt>m_i</dt>		<dt>m_i</dt>
	<dd>		<dd>
	the order of group of points belonging to the elliptic cur ve E_i;		The order of the group of points belonging to the elliptic curve E_i.
	</dd>		</dd>
	<dt>q_i</dt>		<dt>q_i</dt>
	<dd>		<dd>
	the order of the cyclic subgroup of the group of points be longing to the elliptic curve E_i;		The order of the cyclic subgroup of the group of points be longing to the elliptic curve E_i.
	</dd>		</dd>
	<dt>h_i</dt>		<dt>h_i</dt>
	<dd>		<dd>
	the cofactor of the cyclic subgroup which is equal to m_i / q_i;		The cofactor of the cyclic subgroup that is equal to m_i / q_i.
	</dd>		</dd>
	<dt>Q_sign</dt>		<dt>Q_sign</dt>
	<dd>		<dd>
	the public key stored in endpoint's certificate;		The public key stored in the endpoint's certificate.
	</dd>		</dd>
	<dt>d_sign</dt>		<dt>d_sign</dt>
	<dd>		<dd>
	the private key that corresponds to the Q_sign key;		The private key that corresponds to the Q_sign key.
	</dd>		</dd>
	<dt>P_i</dt>		<dt>P_i</dt>
	<dd>		<dd>
	the point of the elliptic curve E_i of the order q_i;		The point of the elliptic curve E_i of the order q_i.
	</dd>		</dd>
	<dt>(d_C^i, Q_C^i)</dt>		<dt>(d_C^i, Q_C^i)</dt>
	<dd>		<dd>
	the client's ephemeral key pair which consists of the priv ate key and the public key corresponding to the elliptic curve E_i;		The client's ephemeral key pair that consists of the priva te key and the public key corresponding to the elliptic curve E_i.
	</dd>		</dd>
	<dt>(d_S^i, Q_S^i)</dt>		<dt>(d_S^i, Q_S^i)</dt>
	<dd>		<dd>
	the server's ephemeral key pair which consists of the priv ate key and the public key corresponding to the elliptic curve E_i.		The server's ephemeral key pair that consists of the priva te key and the public key corresponding to the elliptic curve E_i.
	</dd>		</dd>
	</dl>		</dl>
	</section>		</section>
	<section anchor="CipherSuites" numbered="true" toc="default">		<section anchor="CipherSuites" numbered="true" toc="default">
	<name>Cipher Suite Definition</name>		<name>Cipher Suite Definition</name>
	<t>		<t>
	This section defines the following four TLS13_GOST cipher suites :		This section defines the following four TLS13_GOST cipher suites :
	</t>		</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<ul spacing="normal">
			<li>CipherSuite TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L = {0xC1, 0x03};</li>
	CipherSuite TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L = {0xC1, 0x03};		<li>CipherSuite TLS_GOSTR341112_256_WITH_MAGMA_MGM_L = {0xC1, 0x04};</li>
	CipherSuite TLS_GOSTR341112_256_WITH_MAGMA_MGM_L = {0xC1, 0x04};		<li>CipherSuite TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S = {0xC1, 0x05};</li>
	CipherSuite TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S = {0xC1, 0x05};		<li>CipherSuite TLS_GOSTR341112_256_WITH_MAGMA_MGM_S = {0xC1, 0x06}.</li>
	CipherSuite TLS_GOSTR341112_256_WITH_MAGMA_MGM_S = {0xC1, 0x06};		</ul>
			<t>
	]]></artwork>		Each cipher suite specifies a pair consisting of a record protection algorithm (
	<t>		see <xref target="RecordProtection" format="default"/>) and a hash algorithm (<x
	Each cipher suite specifies a pair of a record protection algori		ref target="HASH" format="default"/>).
	thm (see <xref target="RecordProtection" format="default"/>) and a hash algorith
	m (<xref target="HASH" format="default"/>).
	</t>		</t>
	<section anchor="RecordProtection" numbered="true" toc="default">		<section anchor="RecordProtection" numbered="true" toc="default">
	<name>Record Protection Algorithm</name>		<name>Record Protection Algorithm</name>
	<t>		<t>
	In accordance with Section 5.2 of <xref target="RFC8446" for		In accordance with <xref target="RFC8446" section="5.2" sect
	mat="default"/>, the record protection algorithm translates a TLSPlaintext struc		ionFormat="of"/>, the record protection algorithm translates a TLSPlaintext stru
	ture into a TLSCiphertext structure.		cture into a TLSCiphertext structure.
	If the TLS13_GOST cipher suite is negotiated, the encrypted_		If the TLS13_GOST cipher suite is negotiated, the encrypted_
	record field of the TLSCiphertext structure MUST be set to the AEADEncrypted val		record field of the TLSCiphertext structure <bcp14>MUST</bcp14> be set to the AE
	ue computed as follows:		ADEncrypted value computed as follows:
			</t>
			<t indent="3"> AEADEncrypted =
			AEAD-Encrypt(sender_record_write_key, nonce,
			additional_data, plaintext),
	</t>		</t>
	<ul empty="true" spacing="normal">
	<li>
	AEADEncrypted = AEAD-Encrypt(sender_record_write_key
	, nonce, additional_data, plaintext),
	</li>
	</ul>
	<t>		<t>
	where		where
	</t>		</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>
	the AEAD-Encrypt function is defined in <xref target ="AEAD" format="default"/>;		the AEAD-Encrypt function is defined in <xref target ="AEAD" format="default"/>;
	</li>		</li>
	<li>		<li>
	<t>		<t>
	the sender_record_write_key is a key derived from se nder_write_key (see Section 7.3 of <xref target="RFC8446" format="default"/>) us ing		the sender_record_write_key is a key derived from se nder_write_key (see <xref target="RFC8446" section="7.3" sectionFormat="of"/>) u sing
	the TLSTREE function defined in <xref target="TLSTRE E" format="default"/> and sequence number seqnum as follows:		the TLSTREE function defined in <xref target="TLSTRE E" format="default"/> and sequence number seqnum as follows:
	</t>		</t>
	<ul empty="true" spacing="normal">		<ul empty="true" spacing="normal">
	<li>		<li>
	sender_record_write_key = TLSTREE(sender_wri te_key, seqnum);		sender_record_write_key = TLSTREE(sender_wri te_key, seqnum);
	</li>		</li>
	</ul>		</ul>
	</li>		</li>
	<li>		<li>
	the nonce is a value derived from sequence number se		the nonce is a value derived from sequence number se
	qnum and sender_write_iv (see Section 7.3		qnum and sender_write_iv (see
	of <xref target="RFC8446" format="default"/>) in acc		<xref target="RFC8446" section="7.3" sectionFormat=
	ordance with Section 5.3 of <xref target="RFC8446" format="default"/>;		"of"/>) in accordance with <xref target="RFC8446" section="5.3" sectionFormat="o
			f"/>;
	</li>		</li>
	<li>		<li>
	the additional_data value is a record header that is generated in accordance with Section 5.2 of <xref target="RFC8446" format="defa ult"/>;		the additional_data value is a record header that is generated in accordance with <xref target="RFC8446" section="5.2" sectionFormat ="of"/>;
	</li>		</li>
	<li>		<li>
	the plaintext value is the TLSInnerPlaintext structu re encoded in accordance with Section 5.2 of <xref target="RFC8446" format="defa ult"/>.		the plaintext value is the TLSInnerPlaintext structu re encoded in accordance with <xref target="RFC8446" section="5.2" sectionFormat ="of"/>.
	</li>		</li>
	</ul>		</ul>
	<t>		<t>
	Note1: The AEAD-Encrypt function is exactly the same as the AEAD-Encrypt function defined in <xref target="RFC8446" format="default"/>, such that the key		Note 1: The AEAD-Encrypt function is exactly the same as the AEAD-Encrypt function defined in <xref target="RFC8446" format="default"/>, suc h that the key
	(the first argument) is calculated from sender_write_key and sequence number seqnum for each message separately to support the external		(the first argument) is calculated from sender_write_key and sequence number seqnum for each message separately to support the external
	re-keying approach according to <xref target="RFC8645" forma t="default"/>.		re-keying approach according to <xref target="RFC8645" forma t="default"/>.
	</t>		</t>
	<t>		<t>
	Note2: Sequence number is a value in the range 0-SNMAX, wher		Note 2: Sequence number is a value in the range 0-SNMAX,
	e the SNMAX value is defined in <xref target="SNMAX" format="default"/>.		where the SNMAX value is defined in <xref target="SNMAX"
	The SNMAX parameter is specified by a particular TLS13_GOST		format="default"/>. The SNMAX parameter is specified by a
	cipher suite to limit an amount of data that can be encrypted under		particular TLS13_GOST cipher suite to limit an amount of
	the same traffic key material (sender_write_key, sender_writ		data that can be encrypted under the same traffic key
	e_iv).		material (sender_write_key, sender_write_iv).
	</t>
	<t>
	The record deprotection algorithm reverses the process of th
	e record protection. In order to decrypt and verify a protected record with sequ
	ence number
	seqnum the algorithm takes as an input: sender_record_write_
	key, which is derived from sender_write_key, nonce, additional_data and the AEAD
	Encrypted value.
	The algorithm outputs the res value which is either plaintex
	t or an error indicating that the decryption failed.
	If a TLS13_GOST cipher suite is negotiated, the res value MU
	ST be computed as follows:
	</t>		</t>
	<ul empty="true" spacing="normal">
	<li>
	res = AEAD-Decrypt(sender_record_write_key, nonce, a
	dditional_data, AEADEncrypted),
	</li>
	</ul>
	<t>		<t>
	where the AEAD-Decrypt function is defined in <xref target="		The record deprotection algorithm reverses the process of th
	AEAD" format="default"/>.		e record protection.
			In order to decrypt and verify a protected record with seque
			nce
			number seqnum, the algorithm takes sender_record_write_key a
			s an input, which
			is derived from sender_write_key, nonce, additional_data, an
			d the AEADEncrypted
			value.
			The algorithm outputs the res value that is either plaintext
			or an error indicating that the decryption failed.
			If a TLS13_GOST cipher suite is negotiated, the res value <b
			cp14>MUST</bcp14> be computed as follows:
	</t>		</t>
			<t indent="3">
			res = AEAD-Decrypt(sender_record_write_key, nonce, additio
			nal_data, AEADEncrypted),</t>
			<t> where the AEAD-Decrypt function is as defined in <xref ta
			rget="AEAD" format="default"/>.
			</t>
	<t>		<t>
	Note: The AEAD-Decrypt function is exactly the same as the A EAD-Decrypt function defined in <xref target="RFC8446" format="default"/>, such that the key		Note: The AEAD-Decrypt function is exactly the same as the A EAD-Decrypt function defined in <xref target="RFC8446" format="default"/>, such that the key
	(the first argument) is calculated from sender_write_key and sequence number seqnum for each message separately to support the external		(the first argument) is calculated from sender_write_key and sequence number seqnum for each message separately to support the external
	re-keying approach according to <xref target="RFC8645" forma t="default"/>.		re-keying approach according to <xref target="RFC8645" forma t="default"/>.
	</t>		</t>
	<section anchor="AEAD" numbered="true" toc="default">		<section anchor="AEAD" numbered="true" toc="default">
	<name>AEAD Algorithm</name>		<name>AEAD Algorithm</name>
	<t>		<t>
	The AEAD-Encrypt and AEAD-Decrypt functions are defined as follows.		The AEAD-Encrypt and AEAD-Decrypt functions are defined as follows:
	</t>		</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[
			<sourcecode type="pseudocode"><![CDATA[
	+-------------------------------------------------------------------+		+-------------------------------------------------------------------+
	| AEAD-Encrypt(K, nonce, A, P) |		| AEAD-Encrypt(K, nonce, A, P) |
	|-------------------------------------------------------------------|		|-------------------------------------------------------------------|
	| Input: |		| Input: |
	| - encryption key K in B_k, |		| - encryption key K in B_k, |
	| - unique vector nonce in B_IVlen, |		| - unique vector nonce in B_IVlen, |
	| - additional authenticated data A in B_r, r >= 0, |		| - additional authenticated data A in B_r, r >= 0, |
	| - plaintext P in B_t, t >= 0. |		| - plaintext P in B_t, t >= 0. |
	| Output: |		| Output: |
	| - ciphertext C in B_{|P|}, |		| - ciphertext C in B_{|P|}, |
	skipping to change at line 430 ¶		skipping to change at line 454 ¶
	| - additional authenticated data A in B_r, r >= 0, |		| - additional authenticated data A in B_r, r >= 0, |
	| - ciphertext C in B_t, t >= 0, |		| - ciphertext C in B_t, t >= 0, |
	| - authentication tag T in B_S. |		| - authentication tag T in B_S. |
	| Output: |		| Output: |
	| - plaintext P in B_{|C|} or FAIL. |		| - plaintext P in B_{|C|} or FAIL. |
	|-------------------------------------------------------------------|		|-------------------------------------------------------------------|
	| 1. MGMnonce = STR_1(nonce[1] & 0x7f) | nonce[2..IVlen]; |		| 1. MGMnonce = STR_1(nonce[1] & 0x7f) | nonce[2..IVlen]; |
	| 2. res' = MGM-Decrypt(K, MGMnonce, A, C, T); |		| 2. res' = MGM-Decrypt(K, MGMnonce, A, C, T); |
	| 3. IF res' = FAIL then return FAIL; |		| 3. IF res' = FAIL then return FAIL; |
	| 4. IF res' = (A, P) then return P. |		| 4. IF res' = (A, P) then return P. |
	+-------------------------------------------------------------------+		+-------------------------------------------------------------------+]]></source
			code>
	]]></artwork>
	<t>		<t>
	where		where
	</t>		</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>
	the MGM-Encrypt and MGM-Decrypt functions are de		the MGM-Encrypt and MGM-Decrypt functions are
	fined in <xref target="RFC9058" format="default"/>. The length of authentication		defined in <xref target="RFC9058"
	tag T is equal to n bytes (S = n).		format="default"/>;</li> <li>the length of
	The length of the nonce parameter is equal to n		authentication tag T is equal to n bytes (S =
	bytes (IVlen = n).		n);</li> <li>the length of the nonce parameter
			is equal to n bytes (IVlen = n).
	</li>		</li>
	</ul>		</ul>
	<t>		<t>
	Cipher suites TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L and TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S MUST use Kuznyechik <xref target=" RFC7801" format="default"/>		Cipher suites TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L and TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S <bcp14>MUST</bcp14> use Kuznyechik <xref target="RFC7801" format="default"/>
	as a base block cipher for the AEAD algorithm. The block length n is 16 bytes (n = 16) and the key length k is 32 bytes (k = 32).		as a base block cipher for the AEAD algorithm. The block length n is 16 bytes (n = 16) and the key length k is 32 bytes (k = 32).
	</t>		</t>
	<t>		<t>
	Cipher suites TLS_GOSTR341112_256_WITH_MAGMA_MGM_L and T LS_GOSTR341112_256_WITH_MAGMA_MGM_S MUST use Magma <xref target="RFC8891" format ="default"/>		Cipher suites TLS_GOSTR341112_256_WITH_MAGMA_MGM_L and T LS_GOSTR341112_256_WITH_MAGMA_MGM_S <bcp14>MUST</bcp14> use Magma <xref target=" RFC8891" format="default"/>
	as a base block cipher for the AEAD algorithm. The block length n is 8 bytes (n = 8) and the key length k is 32 bytes (k = 32).		as a base block cipher for the AEAD algorithm. The block length n is 8 bytes (n = 8) and the key length k is 32 bytes (k = 32).
	</t>		</t>
	</section>		</section>
	<section anchor="TLSTREE" numbered="true" toc="default">		<section anchor="TLSTREE" numbered="true" toc="default">
	<name>TLSTREE</name>		<name>TLSTREE</name>
	<t>		<t>
	The TLS13_GOST cipher suites use the TLSTREE function to support the external re-keying approach (see <xref target="RFC8645" format="def ault"/>). The TLSTREE function is defined as follows:		The TLS13_GOST cipher suites use the TLSTREE function to support the external re-keying approach (see <xref target="RFC8645" format="def ault"/>). The TLSTREE function is defined as follows:
	</t>		</t><t indent="3">TLSTREE(K_root, i) = KDF_3(KDF_2(KDF_1(K_root, STR_8
	<ul empty="true" spacing="normal">		(i &amp; C_1)), STR_8(i &amp; C_2)), STR_8(i &amp; C_3)),
	<li>		</t>
	TLSTREE(K_root, i) = KDF_3(KDF_2(KDF_1(K_root, S
	TR_8(i &amp; C_1)), STR_8(i &amp; C_2)), STR_8(i &amp; C_3)),
	</li>
	</ul>
	<t>		<t>
	where		where
	</t>		</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>
	K_root in B_32;		K_root in B_32;
	</li>		</li>
	<li>		<li>
	i in {0, 1, ... , 2^64 - 1};		i in {0, 1, ... , 2^64 - 1};
	</li>		</li>
	<li>		<li>
	<t>		<t>
	KDF_j(K, D), j = 1, 2, 3, is the key derivation function defined as follows: </t>		KDF_j(K, D), j = 1, 2, 3, is the key derivation function defined as follows: </t>
			<ul spacing="normal">
			<li>
			KDF_1(K, D) = KDF_GOSTR3411_2012_256(K, "level1"
			, D),</li>
			<li>
			KDF_2(K, D) = KDF_GOSTR3411_2012_256(K, "level2"
			, D),</li>
			<li>
			KDF_3(K, D) = KDF_GOSTR3411_2012_256(K, "level3"
			, D),</li></ul>
	<t>		<t>
	KDF_1(K, D) = KDF_GOSTR3411_2012_256(K, "level1"		where the KDF_GOSTR3411_2012_256 function is def
	, D),</t>		ined in <xref target="RFC7836" format="default"/>, K in B_32, D in B_8;
	<t>
	KDF_2(K, D) = KDF_GOSTR3411_2012_256(K, "level2"
	, D),</t>
	<t>
	KDF_3(K, D) = KDF_GOSTR3411_2012_256(K, "level3"
	, D),</t>
	<t>
	where the KDF_GOSTR3411_2012_256 function is def
	ined in <xref target="RFC7836" format="default"/>, K in B_32, D in B_8.
	</t>
	</li>
	<li>
	C_1, C_2, C_3 are the constants defined by each
	cipher suite as follows:
	</li>
	</ul>
	<artwork name="" type="" align="left" alt=""><![CDATA[
	+------------------------------------------+----------------------+		</t></li>
	| CipherSuites | C_1, C_2, C_3 |
	+------------------------------------------+----------------------+
	|TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L |C_1=0xf800000000000000|
	| |C_2=0xfffffff000000000|
	| |C_3=0xffffffffffffe000|
	+------------------------------------------+----------------------+
	|TLS_GOSTR341112_256_WITH_MAGMA_MGM_L |C_1=0xffe0000000000000|
	| |C_2=0xffffffffc0000000|
	| |C_3=0xffffffffffffff80|
	+------------------------------------------+----------------------+
	|TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S |C_1=0xffffffffe0000000|
	| |C_2=0xffffffffffff0000|
	| |C_3=0xfffffffffffffff8|
	+------------------------------------------+----------------------+
	|TLS_GOSTR341112_256_WITH_MAGMA_MGM_S |C_1=0xfffffffffc000000|
	| |C_2=0xffffffffffffe000|
	| |C_3=0xffffffffffffffff|
	+------------------------------------------+----------------------+
	Table 1
	]]></artwork>		<li><t>
			C_1, C_2, C_3 are the constants defined by each
			cipher suite as follows:
			</t></li>
			</ul>
			<table>
			<thead>
			<tr>
			<th>CipherSuites</th>
			<th>C_1, C_2, C_3</th>
			</tr>
			</thead>
			<tbody>
			<tr>
			<td>TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L</td>
			<td><t>C_1=0xf800000000000000</t>
			<t>C_2=0xfffffff000000000</t>
			<t>C_3=0xffffffffffffe000</t></td>
			</tr>
			<tr>
			<td>TLS_GOSTR341112_256_WITH_MAGMA_MGM_L</td>
			<td><t>C_1=0xffe0000000000000</t>
			<t>C_2=0xffffffffc0000000</t>
			<t>C_3=0xffffffffffffff80</t></td>
			</tr>
			<tr>
			<td>TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S</td>
			<td><t>C_1=0xffffffffe0000000</t>
			<t>C_2=0xffffffffffff0000</t>
			<t>C_3=0xfffffffffffffff8</t></td>
			</tr>
			<tr>
			<td>TLS_GOSTR341112_256_WITH_MAGMA_MGM_S</td>
			<td><t>C_1=0xfffffffffc000000</t>
			<t>C_2=0xffffffffffffe000</t>
			<t>C_3=0xffffffffffffffff</t></td>
			</tr>
			</tbody>
			</table>
	</section>		</section>
	<section anchor="SNMAX" numbered="true" toc="default">		<section anchor="SNMAX" numbered="true" toc="default">
	<name>SNMAX parameter</name>		<name>SNMAX Parameter</name>
	<t>		<t>
	The SNMAX parameter is the maximum number of records enc rypted under the same traffic key material (sender_write_key and sender_write_iv )		The SNMAX parameter is the maximum number of records enc rypted under the same traffic key material (sender_write_key and sender_write_iv )
	and is defined by each cipher suite as follows:		and is defined by each cipher suite as follows:
	</t>		</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<table>
			<thead>
	+------------------------------------------+--------------------+		<tr>
	| CipherSuites | SNMAX |
	+------------------------------------------+--------------------+
	|TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L | SNMAX = 2^64 - 1 |
	+------------------------------------------+--------------------+
	|TLS_GOSTR341112_256_WITH_MAGMA_MGM_L | SNMAX = 2^64 - 1 |
	+------------------------------------------+--------------------+
	|TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S | SNMAX = 2^42 - 1 |
	+------------------------------------------+--------------------+
	|TLS_GOSTR341112_256_WITH_MAGMA_MGM_S | SNMAX = 2^39 - 1 |
	+------------------------------------------+--------------------+
	Table 2
	]]></artwork>		<th>CipherSuites</th>
			<th>SNMAX</th>
			</tr>
			</thead>
			<tbody>
			<tr>
			<td>TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L</td>
			<td>SNMAX = 2^64 - 1</td>
			</tr>
			<tr>
			<td>TLS_GOSTR341112_256_WITH_MAGMA_MGM_L</td>
			<td>SNMAX = 2^64 - 1</td>
			</tr>
			<tr>
			<td>TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S</td>
			<td>SNMAX = 2^42 - 1</td>
			</tr>
			<tr>
			<td>TLS_GOSTR341112_256_WITH_MAGMA_MGM_S</td>
			<td>SNMAX = 2^39 - 1</td>
			</tr>
			</tbody>
			</table>
	</section>		</section>
	</section>		</section>
	<section anchor="HASH" numbered="true" toc="default">		<section anchor="HASH" numbered="true" toc="default">
	<name>Hash Algorithm</name>		<name>Hash Algorithm</name>
	<t>		<t>
	The Hash algorithm is used for the key derivation process (s		The Hash algorithm is used for the key derivation process (s
	ee Section 7.1 of <xref target="RFC8446" format="default"/>),		ee <xref target="RFC8446" section="7.1" sectionFormat="of"/>),
	Finished message calculation (see Section 4.4.4 of <xref tar		Finished message calculation (see <xref target="RFC8446" sec
	get="RFC8446" format="default"/>), Transcript-Hash function computation		tion="4.4.4" sectionFormat="of"/>), Transcript-Hash function computation
	(see Section 4.4.1 of <xref target="RFC8446" format="default		(see <xref target="RFC8446" section="4.4.1" sectionFormat="o
	"/>), PSK binder value calculation (see Section 4.2.11.2 of <xref target="RFC844		f"/>), Pre-Shared Key (PSK) binder value calculation (see <xref target="RFC8446"
	6" format="default"/>),		section="4.2.11.2" sectionFormat="of"/>),
	external re-keying approach (see <xref target="TLSTREE" form		external re-keying approach (see <xref target="TLSTREE" form
	at="default"/>) and other purposes.		at="default"/>), and other purposes.
	</t>		</t>
	<t>		<t>
	If a TLS13_GOST cipher suite is negotiated, the Hash algorit		If a TLS13_GOST cipher suite is negotiated, the Hash algorit
	hm MUST be the GOST R 34.11-2012		hm <bcp14>MUST</bcp14> be the GOST R 34.11-2012
	hash algorithm <xref target="RFC6986" format="default"/> wit		hash algorithm <xref target="RFC6986" format="default"/> wit
	h 32-byte (256-bit) hash value.		h a 32-byte (256-bit) hash value.
	</t>		</t>
	</section>		</section>
	</section>		</section>
	<section anchor="SSD" numbered="true" toc="default">		<section anchor="SSD" numbered="true" toc="default">
	<name>Signature Scheme Definition</name>		<name>Signature Scheme Definition</name>
	<t>		<t>
	This section defines the following seven TLS13_GOST signature sc hemes:		This section defines the following seven TLS13_GOST signature sc hemes:
	</t>		</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<sourcecode name="" type=""><![CDATA[
	enum {		enum {
	gostr34102012_256a(0x0709),		gostr34102012_256a(0x0709),
	gostr34102012_256b(0x070A),		gostr34102012_256b(0x070A),
	gostr34102012_256c(0x070B),		gostr34102012_256c(0x070B),
	gostr34102012_256d(0x070C),		gostr34102012_256d(0x070C),
	gostr34102012_512a(0x070D),		gostr34102012_512a(0x070D),
	gostr34102012_512b(0x070E),		gostr34102012_512b(0x070E),
	gostr34102012_512c(0x070F)		gostr34102012_512c(0x070F)
	} SignatureScheme;		} SignatureScheme;]]></sourcecode>
	]]></artwork>
	<t>		<t>
	One of the TLS13_GOST signature schemes listed above SHOULD be u sed with the TLS13_GOST profile.		One of the TLS13_GOST signature schemes listed above <bcp14>SHOU LD</bcp14> be used with the TLS13_GOST profile.
	</t>		</t>
	<t>		<t>
	Each signature scheme specifies a pair of the signature algorith
	m (see <xref target="SignatureAlgorithm" format="default"/>) and the elliptic cu		Each signature scheme specifies a pair consisting of the signature algorit
	rve (see <xref target="EllipticCurve" format="default"/>).		hm (see <xref
	The procedure to calculate the signature value using TLS13_GOST		target="SignatureAlgorithm" format="default"/>) and the elliptic curve
	signature schemes is defined in <xref target="SIGN" format="default"/>.		(see <xref target="EllipticCurve" format="default"/>). The procedure to
			calculate the signature value using TLS13_GOST signature schemes is
			defined in <xref target="SIGN" format="default"/>.
	</t>		</t>
	<section anchor="SignatureAlgorithm" numbered="true" toc="default">		<section anchor="SignatureAlgorithm" numbered="true" toc="default">
	<name>Signature Algorithm</name>		<name>Signature Algorithm</name>
	<t>		<t>
	Signature algorithms corresponding to the TLS13_GOST signatu re schemes are defined as follows:		Signature algorithms corresponding to the TLS13_GOST signatu re schemes are defined as follows:
	</t>		</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[
	+------------------+--------------------------------------+--------+		<table>
	| SignatureScheme | Signature Algorithm | Refe- |		<thead>
	| Value | | rences |		<tr>
	+------------------+--------------------------------------+--------+		<th>SignatureScheme Value</th>
	|gostr34102012_256a|GOST R 34.10-2012 , 32-byte key length|RFC 7091|		<th>Signature Algorithm</th>
	+------------------+--------------------------------------+--------+		<th>References</th>
	|gostr34102012_256b|GOST R 34.10-2012 , 32-byte key length|RFC 7091|		</tr>
	+------------------+--------------------------------------+--------+		</thead>
	|gostr34102012_256c|GOST R 34.10-2012 , 32-byte key length|RFC 7091|		<tbody>
	+------------------+--------------------------------------+--------+		<tr>
	|gostr34102012_256d|GOST R 34.10-2012 , 32-byte key length|RFC 7091|		<td>gostr34102012_256a</td>
	+------------------+--------------------------------------+--------+		<td>GOST R 34.10-2012, 32-byte key length</td>
	|gostr34102012_512a|GOST R 34.10-2012 , 64-byte key length|RFC 7091|		<td>RFC 7091</td>
	+------------------+--------------------------------------+--------+		</tr><tr>
	|gostr34102012_512b|GOST R 34.10-2012 , 64-byte key length|RFC 7091|		<td>gostr34102012_256b</td>
	+------------------+--------------------------------------+--------+		<td>GOST R 34.10-2012, 32-byte key length</td>
	|gostr34102012_512c|GOST R 34.10-2012 , 64-byte key length|RFC 7091|		<td>RFC 7091</td></tr><tr>
	+------------------+--------------------------------------+--------+		<td>gostr34102012_256c</td>
	Table 3		<td>GOST R 34.10-2012, 32-byte key length</td>
			<td>RFC 7091</td></tr><tr>
	]]></artwork>		<td>gostr34102012_256d</td>
			<td>GOST R 34.10-2012, 32-byte key length</td>
			<td>RFC 7091</td></tr><tr>
			<td>gostr34102012_512a</td>
			<td>GOST R 34.10-2012, 64-byte key length</td>
			<td>RFC 7091</td></tr><tr>
			<td>gostr34102012_512b</td>
			<td>GOST R 34.10-2012, 64-byte key length</td>
			<td>RFC 7091</td></tr><tr>
			<td>gostr34102012_512c</td>
			<td>GOST R 34.10-2012, 64-byte key length</td>
			<td>RFC 7091</td></tr>
			</tbody>
			</table>
	</section>		</section>
	<section anchor="EllipticCurve" numbered="true" toc="default">		<section anchor="EllipticCurve" numbered="true" toc="default">
	<name>Elliptic Curve</name>		<name>Elliptic Curve</name>
	<t>		<t>
	Elliptic curves corresponding to the TLS13_GOST signature sc hemes are defined as follows:		Elliptic curves corresponding to the TLS13_GOST signature sc hemes are defined as follows:
	</t>		</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<table>
			<thead>
			<tr>
	+------------------+--------------------------------------+--------+		<th>SignatureScheme Value</th>
	| SignatureScheme | Curve Identifier Value | Refe- |		<th>Curve Identifier Value</th>
	| Value | | rences |		<th>References</th>
	+------------------+--------------------------------------+--------+		</tr>
	|gostr34102012_256a| id-tc26-gost-3410-2012-256-paramSetA |RFC 7836|		</thead>
	+------------------+--------------------------------------+--------+		<tbody>
	|gostr34102012_256b|id-GostR3410-2001-CryptoPro-A-ParamSet|RFC 4357|		<tr>
	+------------------+--------------------------------------+--------+		<td>gostr34102012_256a</td>
	|gostr34102012_256c|id-GostR3410-2001-CryptoPro-B-ParamSet|RFC 4357|		<td>id-tc26-gost-3410-2012-256-paramSetA</td>
	+------------------+--------------------------------------+--------+		<td>RFC 7836</td>
	|gostr34102012_256d|id-GostR3410-2001-CryptoPro-C-ParamSet|RFC 4357|		</tr><tr>
	+------------------+--------------------------------------+--------+
	|gostr34102012_512a| id-tc26-gost-3410-12-512-paramSetA |RFC 7836|
	+------------------+--------------------------------------+--------+
	|gostr34102012_512b| id-tc26-gost-3410-12-512-paramSetB |RFC 7836|
	+------------------+--------------------------------------+--------+
	|gostr34102012_512c| id-tc26-gost-3410-2012-512-paramSetC |RFC 7836|
	+------------------+--------------------------------------+--------+
	Table 4
	]]></artwork>		<td>gostr34102012_256b</td>
			<td>id-GostR3410-2001-CryptoPro-A-ParamSet</td>
			<td>RFC 4357</td>
			</tr><tr>
			<td>gostr34102012_256c</td>
			<td>id-GostR3410-2001-CryptoPro-B-ParamSet</td>
			<td>RFC 4357</td>
			</tr><tr>
			<td>gostr34102012_256d</td>
			<td>id-GostR3410-2001-CryptoPro-C-ParamSet</td>
			<td>RFC 4357</td>
			</tr><tr>
			<td>gostr34102012_512a</td>
			<td>id-tc26-gost-3410-12-512-paramSetA</td>
			<td>RFC 7836</td>
			</tr><tr>
			<td>gostr34102012_512b</td>
			<td>id-tc26-gost-3410-12-512-paramSetB</td>
			<td>RFC 7836</td>
			</tr><tr>
			<td>gostr34102012_512c</td>
			<td>id-tc26-gost-3410-2012-512-paramSetC</td>
			<td>RFC 7836</td>
			</tr>
			</tbody>
			</table>
	</section>		</section>
	<section anchor="SIGN" numbered="true" toc="default">		<section anchor="SIGN" numbered="true" toc="default">
	<name>SIGN function</name>		<name>SIGN Function</name>
	<t>		<t>
	If the TLS13_GOST signature scheme is used, the signature va lue in the CertificateVerify message (see <xref target="CV" format="default"/>)		If the TLS13_GOST signature scheme is used, the signature va lue in the CertificateVerify message (see <xref target="CV" format="default"/>)
	MUST be calculated using the SIGN function defined as follow s:		<bcp14>MUST</bcp14> be calculated using the SIGN function de fined as follows:
	</t>		</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<sourcecode type="pseudocode"><![CDATA[
	+-----------------------------------------------------+		+-----------------------------------------------------+
	| SIGN(d_sign, M) |		| SIGN(d_sign, M) |
	|-----------------------------------------------------|		|-----------------------------------------------------|
	| Input: |		| Input: |
	| - the sign key d_sign: 0 < d_sign < q; |		| - the sign key d_sign: 0 < d_sign < q; |
	| - the byte string M in B*. |		| - the byte string M in B*. |
	| Output: |		| Output: |
	| - signature value sgn in B_{2*l}. |		| - signature value sgn in B_{2*l}. |
	|-----------------------------------------------------|		|-----------------------------------------------------|
	| 1. (r, s) = SIGNGOST(d_sign, M) |		| 1. (r, s) = SIGNGOST(d_sign, M) |
	| 2. Return str_l(r) | str_l(s). |		| 2. Return str_l(r) | str_l(s). |
	|-----------------------------------------------------+		|-----------------------------------------------------+]]></sourcecode>
	]]></artwork>
	<t>		<t>
	where		where
	</t>		</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>
	q is the subgroup order of group of points of the el liptic curve;		q is the subgroup order of the group of points of th e elliptic curve;
	</li>		</li>
	<li>		<li>
	<t>		<t>
	l is defined as follows:		l is defined as follows:
	</t>		</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>
	l = 32 for the gostr34102012_256a, gostr3410 2012_256b, gostr34102012_256c		l = 32 for the gostr34102012_256a, gostr3410 2012_256b, gostr34102012_256c,
	and gostr34102012_256d signature schemes;		and gostr34102012_256d signature schemes;
	</li>		</li>
	<li>		<li>
	l = 64 for the gostr34102012_512a, gostr3410 2012_512b and gostr34102012_512c		l = 64 for the gostr34102012_512a, gostr3410 2012_512b, and gostr34102012_512c
	signature schemes;		signature schemes;
	</li>		</li>
	</ul>		</ul>
	</li>		</li>
	<li>		<li>
	SIGNGOST is an algorithm which takes a private key d		SIGNGOST is an algorithm that takes a private key d_
	_sign and a message M as an input and returns a pair of integers (r, s)		sign and a message M as an input and returns a pair of integers (r, s)
	calculated during signature generation process in ac		that is calculated during the signature generation p
	cordance with the GOST R 34.10-2012 signature algorithm		rocess in accordance with the GOST R 34.10-2012 signature algorithm
	(see Section 6.1 of <xref target="RFC7091" format="d		(see <xref target="RFC7091" section="6.1" sectionFor
	efault"/>).		mat="of"/>).
	</li>		</li>
	</ul>		</ul>
	<t>		<t>
	Note: The signature value sgn is the concatenation of two st rings that are byte representations of r and s values in the little-endian forma t.		Note: The signature value sgn is the concatenation of two st rings that are byte representations of r and s values in the little-endian forma t.
	</t>		</t>
	</section>		</section>
	</section>		</section>
	<section anchor="KEA" numbered="true" toc="default">		<section anchor="KEA" numbered="true" toc="default">
	<name>Key Exchange and Authentication</name>		<name>Key Exchange and Authentication</name>
	<t>		<t>
	Key exchange and authentication process in case of using the TLS		The key exchange and authentication process for using the
	13_GOST profile is defined in		TLS13_GOST profile is defined in Sections <xref target="KE"
	<xref target="KE" format="default"/>, <xref target="Auth" format		format="counter"/>, <xref target="Auth" format="counter"/>, and
	="default"/> and <xref target="HandshakeMessages" format="default"/>.		<xref target="HandshakeMessages" format="counter"/>.
	</t>		</t>
	<section anchor="KE" numbered="true" toc="default">		<section anchor="KE" numbered="true" toc="default">
	<name>Key Exchange</name>		<name>Key Exchange</name>
	<t>		<t>
	TLS13_GOST profile supports three basic key exchange modes w hich are defined in <xref target="RFC8446" format="default"/>: ECDHE, PSK-only a nd PSK with ECDHE.		The TLS13_GOST profile supports three basic key exchange mod es that are defined in <xref target="RFC8446" format="default"/>: Ephemeral Elli ptic Curve Diffie-Hellman (ECDHE), PSK-only, and PSK with ECDHE.
	</t>		</t>
	<t>		<t>
	Note: In accordance with <xref target="RFC8446" format="defa		Note: In accordance with <xref target="RFC8446" format="defa
	ult"/> TLS 1.3 also supports key exchange modes based on Diffie-Hellman protocol		ult"/>, TLS 1.3 also supports key exchange modes based on the Diffie-Hellman pro
	over finite fields. However, TLS13_GOST profile MUST use mod		tocol
	es based on Diffie-Hellman protocol over elliptic curves.		over finite fields. However, the TLS13_GOST profile <bcp14>M
			UST</bcp14> use modes based on the Diffie-Hellman protocol over elliptic curves.
	</t>		</t>
	<t>		<t>
	In accordance with <xref target="RFC8446" format="default"/> PSKs can be divided into two types:		In accordance with <xref target="RFC8446" format="default"/> , PSKs can be divided into two types:
	</t>		</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>
	internal PSKs which can be established during the pr evious connection;		internal PSKs that can be established during the pre vious connection;
	</li>		</li>
	<li>		<li>
	external PSKs which can be established out of band.		external PSKs that can be established out of band.
	</li>		</li>
	</ul>		</ul>
	<t>		<t>
	If the TLS13_GOST profile is used, PSK-only key exchange mod		If the TLS13_GOST profile is used, PSK-only key exchange mod
	e SHOULD be established via the internal PSKs, and external PSKs		e <bcp14>SHOULD</bcp14> be established via the internal PSKs, and external PSKs
	SHOULD be used only in PSK with ECDHE mode (see more in <xre		<bcp14>SHOULD</bcp14> be used only in PSK with ECDHE mode (s
	f target="Security" format="default"/>).		ee more in <xref target="Security" format="default"/>).
	</t>		</t>
	<t>		<t>
	If the TLS13_GOST profile is used and ECDHE or PSK with ECDH E key exchange mode is used, the ECDHE shared secret SHOULD be calculated		If the TLS13_GOST profile is used and ECDHE or PSK with ECDH E key exchange mode is used, the ECDHE shared secret <bcp14>SHOULD</bcp14> be ca lculated
	in accordance with <xref target="ECDHE" format="default"/> o n the basis of one of the elliptic curves defined in <xref target="SGR" format=" default"/>.		in accordance with <xref target="ECDHE" format="default"/> o n the basis of one of the elliptic curves defined in <xref target="SGR" format=" default"/>.
	</t>		</t>
	<section anchor="ECDHE" numbered="true" toc="default">		<section anchor="ECDHE" numbered="true" toc="default">
	<name>ECDHE Shared Secret Calculation</name>		<name>ECDHE Shared Secret Calculation</name>
	<t>		<t>
	If the TLS13_GOST profile is used, ECDHE shared secr		If the TLS13_GOST profile is used, the ECDHE shared
	et SHOULD be calculated in accordance with <xref target="ClientECDHECalc" format		secret <bcp14>SHOULD</bcp14> be calculated in accordance with Sections <xref tar
	="default"/>		get="ClientECDHECalc" format="counter"/>
	and <xref target="ServerECDHECalc" format="default"/		and <xref target="ServerECDHECalc" format="counter"/
	>. The public ephemeral keys used to obtain ECDHE shared secret SHOULD be repres		>. The public ephemeral keys used to obtain the ECDHE shared secret <bcp14>SHOUL
	ented in the format		D</bcp14> be represented in the format
	described in <xref target="EphKeyRepr" format="defau lt"/>.		described in <xref target="EphKeyRepr" format="defau lt"/>.
	</t>		</t>
	<section anchor="ClientECDHECalc" numbered="true" toc="default">		<section anchor="ClientECDHECalc" numbered="true" toc="default">
	<name>ECDHE Shared Secret Calculation on Client Side</name>		<name>ECDHE Shared Secret Calculation on the Client Side</name>
	<t>
	The client calculates ECDHE shared secret in accorda
	nce with the following steps:
	</t>
	<t>
	1. Chooses from all supported curves E_1, ..., E_R t
	he set of curves E_{i_1}, ..., E_{i_r}, 1 &lt;= i_1 &lt;= i_r &lt;= R, where
	</t>
	<ul spacing="normal">
	<li>
	r &gt;= 1 in case of the first ClientHello m
	essage;
	</li>
	<li>
	r = 1 in case of responding to the HelloRetr
	yRequest message, E_{i_1} corresponds to the curve
	indicated in the "key_share" extension in th
	e HelloRetryRequest message.
	</li>
	</ul>
	<t>
	2. Generates ephemeral key pairs (d_C^{i_1}, Q_C^{i_
	1}), ..., (d_C^{i_r}, Q_C^{i_r}) corresponding to
	the curves E_{i_1}, ..., E_{i_r}, where for each i i
	n {i_1, ..., i_r}:
	</t>
	<ul spacing="normal">
	<li>
	d_C^i is chosen from {1, ..., q_i - 1} at ra
	ndom;
	</li>
	<li>
	Q_C^i = d_C^i * P_i.
	</li>
	</ul>
	<t>
	3. Sends the ClientHello message specified in accord
	ance with Section 4.1.2 of <xref target="RFC8446" format="default"/>
	and <xref target="HelloMessages" format="default"/>,
	which contains:
	</t>
	<ul spacing="normal">
	<li>
	"key_share" extension with public ephemeral
	keys Q_C^{i_1}, ..., Q_C^{i_r} built in accordance with
	Section 4.2.8 of <xref target="RFC8446" form
	at="default"/>;
	</li>
	<li>
	"supported_groups" extension with supported
	curves E_1, ..., E_R built in accordance with
	Section 4.2.7 of <xref target="RFC8446" form
	at="default"/>.
	</li>
	</ul>
	<t>
	Note: The client MAY send an empty "key_share" exten
	sion in the first ClientHello message to request a group
	selection from the server in the HelloRetryRequest m
	essage and to generate an ephemeral key for the selected group only.
	The ECDHE shared secret may be calculated without se
	nding HelloRetryRequest message, if the "key_share" extension in the first
	ClientHello message contains the value corresponding
	to the curve that is selected by the server.
	</t>
	<t>
	4. If the HelloRetryRequest message is received, the
	client MUST return to step 1 and choose correct parameters in accordance
	with Section 4.1.2 of <xref target="RFC8446" format=
	"default"/>.
	If the ServerHello message is received, the client p
	roceeds to the next step. In other cases, the client MUST terminate the
	connection with the "unexpected_message" alert.
	</t>
	<t>
	5. Extracts curve E_res and ephemeral key Q_S^res, r
	es in {1, ..., R}, from the ServerHello message and checks whether
	Q_S^res belongs to E_res. If this check fails, the c
	lient MUST terminate the connection with "handshake_failure" alert.
	</t>
	<t>
	6. Generates Q^ECDHE:
	</t>
	<ul empty="true" spacing="normal">
	<li>
	Q^ECDHE = (X^ECDHE, Y^ECDHE) = (h_res * d_C^
	res) * Q_S^res.
	</li>
	</ul>
	<t>
	7. The client MUST check whether the calculated shar
	ed secret Q^ECDHE is not equal to the zero point O_res. If this check fails,
	the client MUST terminate the connection with "hands
	hake_failure" alert.
	</t>
	<t>
	8. The ECDHE shared secret is the byte representatio
	n of the coordinate X^ECDHE of the point Q^ECDHE in the little-endian format:
	</t>
	<ul empty="true" spacing="normal">
	<li>
	ECDHE = str_{coordinate_length}(X^ECDHE),
	</li>
	</ul>
	<t>		<t>
	where the coordinate_length value is defined by the particular elliptic curve (see <xref target="SGR" format="default"/>).		The client calculates the ECDHE shared secret in acc ordance with the following steps:
	</t>		</t>
	</section>
			<ol type="Step %d.">
			<li anchor="step1"><t>The client chooses from all supported curves E_1, ..., E
			_R
			the set of curves E_{i_1}, ..., E_{i_r}, 1 &lt;=
			i_1 &lt;= i_r &lt;= R, where
			</t>
			<ul>
			<li>r >= 1 in the case of the first ClientHello message;</li>
			<li>r = 1 in the case of responding to the HelloRetryRequest message; E_{i_
			1} corresponds to the curve indicated in the "key_share" extension in the HelloR
			etryRequest message.</li>
			</ul>
			</li>
			<li><t>The client generates ephemeral key pairs (d_C^{i_1}, Q_C^{i_1}), ..., (
			d_C^{i_r}, Q_C^{i_r}) corresponding to the curves E_{i_1}, ..., E_{i_r}, where f
			or each i in {i_1, ..., i_r}:</t>
			<ul>
			<li> d_C^i is chosen from {1, ..., q_i - 1} at random;</li>
			<li>Q_C^i = d_C^i * P_i.</li>
			</ul>
			</li>
			<li><t>The client sends the ClientHello message specified in accordance with <xr
			ef
			target="RFC8446" section="4.1.2" sectionFormat="of"/> and <xref
			target="HelloMessages" format="default"/> that contains:</t>
			<ul>
			<li>"key_share" extension with public ephemeral keys Q_C^{i_1}, ...,
			Q_C^{i_r} built in accordance with <xref target="RFC8446" section="4.2.8"
			sectionFormat="of"/>;</li>
			<li>"supported_groups" extension with supported curves E_1, ..., E_R built
			in accordance with <xref target="RFC8446" section="4.2.7"
			sectionFormat="of"/>.</li></ul>
			<t indent="3">Note: The client <bcp14>MAY</bcp14> send an empty "key_share" ex
			tension
			in the first ClientHello message to request a group selection from the
			server in the HelloRetryRequest message and to generate an ephemeral key for
			the selected group only. The ECDHE shared secret may be calculated without
			sending HelloRetryRequest message if the "key_share" extension in the first
			ClientHello message contains the value corresponding to the curve that is
			selected by the server.</t>
			</li>
			<li><t>If the HelloRetryRequest message is received, the client
			<bcp14>MUST</bcp14> return to <xref target="step1" format="none">Step 1</xref> a
			nd choose correct parameters in
			accordance with <xref target="RFC8446" section="4.1.2" sectionFormat="of"/>.
			If the ServerHello message is received, the client proceeds to the next
			step. In other cases, the client <bcp14>MUST</bcp14> terminate the connection
			with the "unexpected_message" alert.</t></li>
			<li><t>The client extracts curve E_res and ephemeral key Q_S^res, res in {1, ...
			,
			R}, from the ServerHello message and checks whether Q_S^res belongs to
			E_res. If this check fails, the client <bcp14>MUST</bcp14> terminate
			the connection with "handshake_failure" alert.</t></li>
			<li><t>The client generates Q^ECDHE:</t>
			<ul empty="true"><li>Q^ECDHE = (X^ECDHE, Y^ECDHE) = (h_res * d_C^res) * Q_S^res.
			</li>
			</ul></li>
			<li><t>The client <bcp14>MUST</bcp14> check whether the calculated shared
			secret Q^ECDHE is not equal to the zero point O_res. If this check fails, the
			client <bcp14>MUST</bcp14> terminate the connection with "handshake_failure"
			alert.</t></li>
			<li><t>The ECDHE shared secret is the byte representation of the coordinate X^EC
			DHE of the point Q^ECDHE in the little-endian format:</t>
			<t indent="3">
			ECDHE = str_{coordinate_length}(X^ECDHE),</t><t> where the coordinate_length val
			ue is defined by the particular elliptic curve (see <xref target="SGR" format="d
			efault"/>).</t>
			</li></ol> </section>
	<section anchor="ServerECDHECalc" numbered="true" toc="default">		<section anchor="ServerECDHECalc" numbered="true" toc="default">
	<name>ECDHE Shared Secret Calculation on Server Side</name>		<name>ECDHE Shared Secret Calculation on Server Side</name>
	<t>		<t>
	Upon receiving the ClientHello message, the server c		Upon receiving the ClientHello message, the server
	alculates ECDHE shared secret in accordance with the following steps:		calculates the ECDHE shared secret in accordance wit
	</t>		h
	<t>		the following steps:
	1. Chooses the curve E_res, res in {1, ..., R}, from
	the list of the curves E_1, ..., E_R indicated in the "supported_groups"
	extension in the ClientHello message and the corresp
	onding public ephemeral key Q_C^res from the list Q_C^{i_1}, ..., Q_C^{i_r},
	1 &lt;= i_1 &lt;= i_r &lt;= R, indicated in the "key
	_share" extension. If the corresponding public ephemeral key is not found
	(res in {1, ..., R}\{i_1, ..., i_r}), the server MUS
	T send the HelloRetryRequest message with the "key_share" extension indicating t
	he selected
	elliptic curve E_res and wait for the new ClientHell
	o message.
	</t>
	<t>
	2. Checks whether Q_C^res belongs to E_res. If this
	check fails, the server MUST terminate the connection with "handshake_failure" a
	lert.
	</t>
	<t>
	3. Generates ephemeral key pair (d_S^res, Q_S^res) c
	orresponding to E_res:
	</t>
	<ul spacing="normal">
	<li>
	d_S^res is chosen from {1, ..., q_res - 1} a
	t random;
	</li>
	<li>
	Q_S^res = d_S^res * P_res.
	</li>
	</ul>
	<t>
	4. Sends the ServerHello message generated in accord
	ance with Section 4.1.3 of <xref target="RFC8446" format="default"/>
	and <xref target="HelloMessages" format="default"/>
	with the "key_share" extension which contains public ephemeral key
	Q_S^res corresponding to E_res.
	</t>
	<t>
	5. Generates Q^ECDHE:
	</t>
	<ul empty="true" spacing="normal">
	<li>
	Q^ECDHE = (X^ECDHE, Y^ECDHE) = (h_res * d_S^
	res) * Q_C^res.
	</li>
	</ul>
	<t>
	6. The server MUST check whether the calculated shar
	ed secret Q^ECDHE is not equal to the zero point O_res. If this check fails, the
	server MUST
	abort the handshake with "handshake_failure" alert.
	</t>
	<t>
	7. The ECDHE shared secret is the byte representatio
	n of the coordinate X^ECDHE of the point Q^ECDHE in the little-endian format:
	</t>		</t>
	<ul empty="true" spacing="normal">		<ol type="Step %d.">
	<li>		<li><t>The server chooses the curve E_res, res in {1, ..., R}, from the list of
	ECDHE = str_{coordinate_length}(X^ECDHE),		the
	</li>		curves E_1, ..., E_R indicated in the "supported_groups" extension in the
			ClientHello message and the corresponding public ephemeral key Q_C^res from
			the list Q_C^{i_1}, ..., Q_C^{i_r}, 1 &lt;= i_1 &lt;= i_r &lt;= R, indicated
			in the "key_share" extension. If the corresponding public ephemeral key is not
			found (res in {1, ..., R}\{i_1, ..., i_r}), the server <bcp14>MUST</bcp14>
			send the HelloRetryRequest message with the "key_share" extension indicating
			the selected elliptic curve E_res and wait for the new ClientHello message.
			</t></li>
			<li><t>The server checks whether Q_C^res belongs to E_res. If this check fails,
			the server <bcp14>MUST</bcp14> terminate the connection with "handshake_failure"
			alert.</t></li>
			<li><t>The server generates ephemeral key pair (d_S^res, Q_S^res) corresponding
			to E_res:</t>
			<ul>
			<li>d_S^res is chosen from {1, ..., q_res - 1} at random;</li>
			<li>Q_S^res = d_S^res * P_res.</li>
	</ul>		</ul>
	<t>		</li>
	where the coordinate_length value is defined by the		<li><t>The server sends the ServerHello message generated in accordance with <xr
	particular elliptic curve (see <xref target="SGR" format="default"/>).		ef
	</t>		target="RFC8446" section="4.1.3" sectionFormat="of"/> and <xref
			target="HelloMessages" format="default"/> with the "key_share" extension that
			contains public ephemeral key Q_S^res corresponding to E_res.</t></li>
			<li><t>The server generates Q^ECDHE:</t>
			<t indent="3">Q^ECDHE = (X^ECDHE, Y^ECDHE) = (h_res * d_S^res) * Q_C^res.</t>
			</li>
			<li><t>The server <bcp14>MUST</bcp14> check whether the calculated shared
			secret Q^ECDHE is not equal to the zero point O_res. If this check fails, the
			server <bcp14>MUST</bcp14> abort the handshake with "handshake_failure" alert.</
			t></li>
			<li><t>The ECDHE shared secret is the byte representation of the coordinate
			X^ECDHE of the point Q^ECDHE in the little-endian format:</t>
			<t indent="3">ECDHE = str_{coordinate_length}(X^ECDHE),</t><t> where the coordin
			ate_length value is defined by the particular elliptic curve (see <xref target="
			SGR"
			format="default"/>).</t>
			</li>
			</ol>
	</section>		</section>
	<section anchor="EphKeyRepr" numbered="true" toc="default">		<section anchor="EphKeyRepr" numbered="true" toc="default">
	<name>Public ephemeral key representation</name>		<name>Public Ephemeral Key Representation</name>
	<t>		<t>
	This section defines the representation format of th e public ephemeral keys generated during the ECDHE shared secret calculation		This section defines the representation format of th e public ephemeral keys generated during the ECDHE shared secret calculation
	(see <xref target="ClientECDHECalc" format="default" /> and <xref target="ServerECDHECalc" format="default"/>).		(see Sections <xref target="ClientECDHECalc" format= "counter"/> and <xref target="ServerECDHECalc" format="counter"/>).
	</t>		</t>
	<t>		<t>
	If the TLS13_GOST profile is used and ECDHE or PSK w ith ECDHE key exchange mode is used, the public ephemeral key Q		If the TLS13_GOST profile is used and ECDHE or PSK w ith ECDHE key exchange mode is used, the public ephemeral key Q
	indicated in the KeyShareEntry.key_exchange field MU ST contain the data defined by the following structure:		indicated in the KeyShareEntry.key_exchange field <b cp14>MUST</bcp14> contain the data defined by the following structure:
	</t>		</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<sourcecode name="" type=""><![CDATA[
	struct {		struct {
	opaque X[coordinate_length];		opaque X[coordinate_length];
	opaque Y[coordinate_length];		opaque Y[coordinate_length];
	} PlainPointRepresentation;		} PlainPointRepresentation;]]></sourcecode>
	]]></artwork>
	<t>		<t>
	where X and Y, respectively, contain the byte repres entations of x and y values of the point Q (Q = (x, y)) in the little-endian for mat		where X and Y, respectively, contain the byte repres entations of x and y values of the point Q (Q = (x, y)) in the little-endian for mat
	and are specified as follows:		and are specified as follows:
	</t>		</t>
	<ul empty="true" spacing="normal">		<ul empty="false" spacing="normal">
	<li>		<li>
	X = str_{coordinate_length}(x);		X = str_{coordinate_length}(x);
	</li>		</li>
	<li>		<li>
	Y = str_{coordinate_length}(y).		Y = str_{coordinate_length}(y).
	</li>		</li>
	</ul>		</ul>
	<t>		<t>
	The coordinate_length value is defined by the partic ular elliptic curve (see <xref target="SGR" format="default"/>).		The coordinate_length value is defined by the partic ular elliptic curve (see <xref target="SGR" format="default"/>).
	</t>		</t>
	</section>		</section>
	</section>		</section>
	<section anchor="SGR" numbered="true" toc="default">		<section anchor="SGR" numbered="true" toc="default">
	<name>Values for the TLS Supported Groups Registry</name>		<name>Values for the TLS Supported Groups Registry</name>
	<t>		<t>
	The "supported_groups" extension is used to indicate the set of the elliptic curves supported by an endpoint and is defined		The "supported_groups" extension is used to indicate the set of the elliptic curves supported by an endpoint and is defined
	in Section 4.2.7 <xref target="RFC8446" format="default" />. This extension is always contained in the ClientHello message and optionally		in <xref target="RFC8446" section="4.2.7" sectionFormat= "of"/>. This extension is always contained in the ClientHello message and option ally
	in the EncryptedExtensions message.		in the EncryptedExtensions message.
	</t>		</t>
	<t>		<t>
	This section defines the following seven elliptic curves :		This section defines the following seven elliptic curves :
	</t>		</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<sourcecode name="" type=""><![CDATA[
	enum {		enum {
	GC256A(0x22), GC256B(0x23), GC256C(0x24), GC256D(0x25),		GC256A(0x22), GC256B(0x23), GC256C(0x24), GC256D(0x25),
	GC512A(0x26), GC512B(0x27), GC512C(0x28)		GC512A(0x26), GC512B(0x27), GC512C(0x28)
	} NamedGroup;		} NamedGroup;]]></sourcecode>
	]]></artwork>
	<t>		<t>
	If the TLS13_GOST profile is used and ECDHE or PSK with ECDHE key exchange mode is used, one of the elliptic curves listed above SHOULD be used.		If the TLS13_GOST profile is used and ECDHE or PSK with ECDHE key exchange mode is used, one of the elliptic curves listed above <bcp14> SHOULD</bcp14> be used.
	</t>		</t>
	<t>		<t>
	Each curve corresponds to the particular identifier and specifies the value of coordinate_length parameter (see "cl" column) as follows:		Each curve corresponds to the particular identifier and specifies the value of coordinate_length parameter (see "cl" column) as follows:
	</t>		</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<table anchor="table5">
			<thead>
			<tr>
			<th>Description</th>
			<th>Curve Identifier Value</th>
			<th>cl</th>
			<th>Reference</th>
			</tr>
			</thead>
			<tbody>
			<tr>
	+-----------+--------------------------------------+----+---------+		<td>GC256A</td><td> id-tc26-gost-3410-2012-256-paramSetA </td><td> 32 </td><td>R
	|Description| Curve Identifier Value | cl |Reference|		FC 7836</td></tr><tr>
	+-----------+--------------------------------------+----+---------+
	| GC256A | id-tc26-gost-3410-2012-256-paramSetA | 32 | RFC 7836|
	+-----------+--------------------------------------+----+---------+
	| GC256B |id-GostR3410-2001-CryptoPro-A-ParamSet| 32 | RFC 4357|
	+-----------+--------------------------------------+----+---------+
	| GC256C |id-GostR3410-2001-CryptoPro-B-ParamSet| 32 | RFC 4357|
	+-----------+--------------------------------------+----+---------+
	| GC256D |id-GostR3410-2001-CryptoPro-C-ParamSet| 32 | RFC 4357|
	+-----------+--------------------------------------+----+---------+
	| GC512A | id-tc26-gost-3410-12-512-paramSetA | 64 | RFC 7836|
	+-----------+--------------------------------------+----+---------+
	| GC512B | id-tc26-gost-3410-12-512-paramSetB | 64 | RFC 7836|
	+-----------+--------------------------------------+----+---------+
	| GC512C | id-tc26-gost-3410-2012-512-paramSetC | 64 | RFC 7836|
	+-----------+--------------------------------------+----+---------+
	Table 5
	]]></artwork>		<td>GC256B</td>
			<td>id-GostR3410-2001-CryptoPro-A-ParamSet</td>
			<td>32</td>
			<td>RFC 4357</td>
			</tr><tr>
			<td>GC256C</td>
			<td>id-GostR3410-2001-CryptoPro-B-ParamSet</td>
			<td>32</td>
			<td>RFC 4357</td>
			</tr><tr>
			<td>GC256D</td>
			<td>id-GostR3410-2001-CryptoPro-C-ParamSet</td>
			<td>32</td>
			<td>RFC 4357</td>
			</tr><tr>
			<td>GC512A</td>
			<td>id-tc26-gost-3410-12-512-paramSetA</td>
			<td>64</td>
			<td>RFC 7836</td>
			</tr><tr>
			<td>GC512B</td>
			<td>id-tc26-gost-3410-12-512-paramSetB</td>
			<td>64</td>
			<td>RFC 7836</td>
			</tr><tr>
			<td>GC512C</td>
			<td>id-tc26-gost-3410-2012-512-paramSetC</td>
			<td>64</td>
			<td>RFC 7836</td>
			</tr>
			</tbody>
			</table>
	<t>		<t>
	Note: The identifier values and the corresponding ellipt ic curves are the same as in <xref target="RFC9189" format="default"/>.		Note: The identifier values and the corresponding ellipt ic curves are the same as in <xref target="RFC9189" format="default"/>.
	</t>		</t>
	</section>		</section>
	</section>		</section>
	<section anchor="Auth" numbered="true" toc="default">		<section anchor="Auth" numbered="true" toc="default">
	<name>Authentication</name>		<name>Authentication</name>
	<t>		<t>
	In accordance with <xref target="RFC8446" format="default"/> , authentication can be performed via a signature with a certificate or via a sy mmetric pre-shared key (PSK).		In accordance with <xref target="RFC8446" format="default"/> , authentication can be performed via a signature with a certificate or via a sy mmetric PSK.
	The server side is always authenticated; the client side is optionally authenticated.		The server side is always authenticated; the client side is optionally authenticated.
	</t>		</t>
	<t>		<t>
	PSK-based authentication is performed as a side effect of ke		PSK-based authentication is performed as a side effect of ke
	y exchange. If the TLS13_GOST profile is used, external PSKs SHOULD be combined		y exchange. If the TLS13_GOST profile is used, external PSKs <bcp14>SHOULD</bcp1
	only with the mutual authentication (see more in <xref targe		4> be combined
	t="Security" format="default"/>).		only with mutual authentication (see <xref target="Security"
			format="default"/>).
	</t>		</t>
	<t>		<t>
	Certificate-based authentication is performed via Authentica tion messages and optional CertificateRequest message (sent if client authentica tion is required).		Certificate-based authentication is performed via Authentica tion messages and an optional CertificateRequest message (sent if client authent ication is required).
	If the TLS13_GOST profile is used, the signature schemes use d for certificate-based authentication are defined in <xref target="SSD" format= "default"/>		If the TLS13_GOST profile is used, the signature schemes use d for certificate-based authentication are defined in <xref target="SSD" format= "default"/>
	and Authentication messages are specified in <xref target="C ert" format="default"/> and <xref target="CV" format="default"/>. The Certificat eRequest message is specified in <xref target="CR" format="default"/>.		and Authentication messages are specified in Sections <xref target="Cert" format="counter"/> and <xref target="CV" format="counter"/>. The C ertificateRequest message is specified in <xref target="CR" format="default"/>.
	</t>		</t>
	</section>		</section>
	<section anchor="HandshakeMessages" numbered="true" toc="default">		<section anchor="HandshakeMessages" numbered="true" toc="default">
	<name>Handshake Messages</name>		<name>Handshake Messages</name>
	<t>		<t>
	The TLS13_GOST profile specifies the ClientHello, ServerHell o, CertificateRequest, Certificate		The TLS13_GOST profile specifies the ClientHello, ServerHell o, CertificateRequest, Certificate
	and CertificateVerify handshake messages that are described in further detail below.		and CertificateVerify handshake messages that are described in further detail below.
	</t>		</t>
	<section anchor="HelloMessages" numbered="true" toc="default">		<section anchor="HelloMessages" numbered="true" toc="default">
	<name>Hello Messages</name>		<name>Hello Messages</name>
	<t>		<t>
	The ClientHello message is sent when the client first co nnects to the server or responds		The ClientHello message is sent when the client first co nnects to the server or responds
	to the HelloRetryRequest message and is specified in acc ordance with Section 4.1.2 of <xref target="RFC8446" format="default"/>.		to the HelloRetryRequest message and is specified in acc ordance with <xref target="RFC8446" section="4.1.2" sectionFormat="of"/>.
	</t>		</t>
	<t>		<t>
	If the TLS13_GOST profile is used, the ClientHello messa ge MUST meet the following requirements.		If the TLS13_GOST profile is used, the ClientHello messa ge <bcp14>MUST</bcp14> meet the following requirements:
	</t>		</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>
	The ClientHello.cipher_suites field MUST contain the values defined in <xref target="CipherSuites" format="default"/>.		The ClientHello.cipher_suites field <bcp14>MUST< /bcp14> contain the values defined in <xref target="CipherSuites" format="defaul t"/>.
	</li>		</li>
	<li>		<li>
	If server authentication via a certificate is re		If server authentication via a certificate is
	quired, the extension_data field		required, the extension_data field of the
	of the "signature_algorithms" extension MUST con		"signature_algorithms" extension
	tain the values defined in <xref target="SSD" format="default"/>,		<bcp14>MUST</bcp14> contain the values defined
	which correspond to the GOST R 34.10-2012 signat		in <xref target="SSD" format="default"/> that co
	ure algorithm.		rrespond to the GOST R 34.10-2012
			signature algorithm.
	</li>		</li>
	<li>		<li>
	If server authentication via a certificate is re quired and the client uses optional		If server authentication via a certificate is re quired and the client uses optional
	"signature_algorithms_cert" extension, the exten		"signature_algorithms_cert" extension, the exten
	sion_data field of this extension SHOULD contain the		sion_data field of this extension <bcp14>SHOULD</bcp14> contain the
	values defined in <xref target="SSD" format="def		values defined in <xref target="SSD" format="def
	ault"/>, which correspond to the GOST R 34.10-2012 signature algorithm.		ault"/> that correspond to the GOST R 34.10-2012 signature algorithm.
	</li>		</li>
	<li>		<li>
	If the client wants to establish a TLS 1.3 conne		If the client wants to establish a TLS 1.3 conne
	ction using ECDHE shared secret, the extension_data field		ction using the ECDHE shared secret, the extension_data field
	of the "supported_groups" extension MUST contain		of the "supported_groups" extension <bcp14>MUST<
	the elliptic curve identifiers defined		/bcp14> contain the elliptic curve identifiers defined
	in <xref target="SGR" format="default"/>.		in <xref target="SGR" format="default"/>.
	</li>		</li>
	</ul>		</ul>
	<t>		<t>
	The ServerHello message is sent by the server in respons e to the ClientHello message to negotiate		The ServerHello message is sent by the server in respons e to the ClientHello message to negotiate
	an acceptable set of handshake parameters based on the C lientHello message and is specified in accordance		an acceptable set of handshake parameters based on the C lientHello message and is specified in accordance
	with Section 4.1.3 of <xref target="RFC8446" format="def ault"/>.		with <xref target="RFC8446" section="4.1.3" sectionForma t="of"/>.
	</t>		</t>
	<t>		<t>
	If the TLS13_GOST profile is used, the ServerHello messa		If the TLS13_GOST profile is used, the ServerHello messa
	ge MUST meet the following requirements.		ge <bcp14>MUST</bcp14> meet the following requirements: </t>
	</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>
	The ServerHello.cipher_suite field MUST contain one of the values defined		The ServerHello.cipher_suite field <bcp14>MUST</ bcp14> contain one of the values defined
	in <xref target="CipherSuites" format="default"/ >.		in <xref target="CipherSuites" format="default"/ >.
	</li>		</li>
	<li>		<li>
	<t>		<t>
	If the server decides to establish a TLS 1.3 con		If the server decides to establish a TLS 1.3 con
	nection using ECDHE shared secret,		nection using the ECDHE shared secret,
	the extension_data field of the "key_share" exte		the extension_data field of the "key_share" exte
	nsion MUST contain the elliptic curve		nsion <bcp14>MUST</bcp14> contain the elliptic curve
	identifier and the public ephemeral key that sat		identifier and the public ephemeral key that sat
	isfy the following conditions.		isfy the following conditions:
	</t>		</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>
	The elliptic curve identifier correspond s to the value that was indicated in the		The elliptic curve identifier correspond s to the value that was indicated in the
	"supported_groups" and the "key_share" e xtensions in the ClientHello message.		"supported_groups" and the "key_share" e xtensions in the ClientHello message.
	</li>		</li>
	<li>		<li>
	The elliptic curve identifier is one of the values defined in <xref target="SGR" format="default"/>.		The elliptic curve identifier is one of the values defined in <xref target="SGR" format="default"/>.
	</li>		</li>
	<li>		<li>
	skipping to change at line 1044 ¶		skipping to change at line 1116 ¶
	KeyShareEntry.group identifier.		KeyShareEntry.group identifier.
	</li>		</li>
	</ul>		</ul>
	</li>		</li>
	</ul>		</ul>
	</section>		</section>
	<section anchor="CR" numbered="true" toc="default">		<section anchor="CR" numbered="true" toc="default">
	<name>CertificateRequest</name>		<name>CertificateRequest</name>
	<t>		<t>
	This message is sent when the server requests client aut hentication via a certificate and is specified in		This message is sent when the server requests client aut hentication via a certificate and is specified in
	accordance with Section 4.3.2 of <xref target="RFC8446" format="default"/>.		accordance with <xref target="RFC8446" section="4.3.2" s ectionFormat="of"/>.
	</t>		</t>
	<t>		<t>
	If the TLS13_GOST profile is used, the CertificateReques		If the TLS13_GOST profile is used, the CertificateReques
	t message MUST meet the following		t message <bcp14>MUST</bcp14> meet the following
	requirements.		requirements:
	</t>		</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>
	The extension_data field of the "signature_algor ithms" extension MUST contain only the values		The extension_data field of the "signature_algor ithms" extension <bcp14>MUST</bcp14> contain only the values
	defined in <xref target="SSD" format="default"/> .		defined in <xref target="SSD" format="default"/> .
	</li>		</li>
	<li>		<li>
	If the server uses optional "signature_algorithm s_cert" extension, the extension_data field		If the server uses optional "signature_algorithm s_cert" extension, the extension_data field
	of this extension SHOULD contain only the values defined in <xref target="SSD" format="default"/>.		of this extension <bcp14>SHOULD</bcp14> contain only the values defined in <xref target="SSD" format="default"/>.
	</li>		</li>
	</ul>		</ul>
	</section>		</section>
	<section anchor="Cert" numbered="true" toc="default">		<section anchor="Cert" numbered="true" toc="default">
	<name>Certificate</name>		<name>Certificate</name>
	<t>		<t>
	This message is sent to convey the endpoint's certificat e chain to the peer and is specified in		This message is sent to convey the endpoint's certificat e chain to the peer and is specified in
	accordance with Section 4.4.2 of <xref target="RFC8446" format="default"/>.		accordance with <xref target="RFC8446" section="4.4.2" s ectionFormat="of"/>.
	</t>		</t>
	<t>		<t>
	If the TLS13_GOST profile is used, the Certificate messa ge MUST meet the following requirements.		If the TLS13_GOST profile is used, the Certificate messa ge <bcp14>MUST</bcp14> meet the following requirements.
	</t>		</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>
	Each endpoint's certificate provided to the peer		Each endpoint's certificate provided to the peer <bcp14>MUST</bcp14> be signed u
	MUST be signed using the algorithm		sing the algorithm
	which corresponds to a signature scheme indicate		that corresponds to a signature scheme indicated
	d by the peer in its "signature_algoritms_cert"		by the peer in its "signature_algorithms_cert"
	extension, if present (or in the "signature_algo rithms" extension, otherwise).		extension, if present (or in the "signature_algo rithms" extension, otherwise).
	</li>		</li>
	<li>		<li>
	The signature algorithm used for signing certifi cates SHOULD correspond to one of the		The signature algorithm used for signing certifi cates <bcp14>SHOULD</bcp14> correspond to one of the
	signature schemes defined in <xref target="SSD" format="default"/>.		signature schemes defined in <xref target="SSD" format="default"/>.
	</li>		</li>
	</ul>		</ul>
	<!--<t>
	Note: A certificate containing a key for one signature a
	lgorithm MAY be signed using
	a different signature algorithm, but all the signature a
	lgoritms used by an endpoint to create
	certificate chain MUST correspond to the signature schem
	es indicated by the peer in its
	"signature_algoritms_cert" extension, if present (or "si
	gnature_algorithms" extension, otherwise).
	</t>
	<t>
	Note: If the server cannot produce a certificate chain t
	hat is signed only via the indicated supported algorithms
	(for example, if all of the server certificates in the c
	hain are signed with the old signature algorithms
	such as GOST R 34.10-94which don't have the values to be
	indicated by the client in its "signature_algorithms_cert"
	extension), then it SHOULD continue the handshake by sen
	ding the client a certificate chain of its choice that may
	include algorithms that are not known to be supported by
	the client. Client MUST abort the handshake with a
	"bad_certificate" alert if the server Certificate messag
	e contains at least one certificate signed with an
	unsupported signature algorithm.
	</t>-->
	</section>		</section>
	<section anchor="CV" numbered="true" toc="default">		<section anchor="CV" numbered="true" toc="default">
	<name>CertificateVerify</name>		<name>CertificateVerify</name>
	<t>		<t>
	This message is sent to provide explicit proof that the endpoint has the private key		This message is sent to provide explicit proof that the endpoint has the private key
	corresponding to the public key indicated in its certifi cate and is specified in accordance		corresponding to the public key indicated in its certifi cate and is specified in accordance
	with Section 4.4.3 of <xref target="RFC8446" format="def ault"/>.		with <xref target="RFC8446" section="4.4.3" sectionForma t="of"/>.
	</t>		</t>
	<t>		<t>
	If the TLS13_GOST profile is used, the CertificateVerify		If the TLS13_GOST profile is used, the
	message MUST meet the following requirements.		CertificateVerify message <bcp14>MUST</bcp14> meet the
	</t>		following requirements: </t> <ul spacing="normal">
	<ul spacing="normal">		<li><t> The CertificateVerify.algorithm field
	<li>		<bcp14>MUST</bcp14> contain the signature scheme
	The CertificateVerify.algorithm field MUST conta		identifier that corresponds to the value indicated in
	in the signature scheme identifier which		the peer's "signature_algorithms" extension and is one
	corresponds to the value indicated in the peer's		of the values defined in <xref target="SSD"
	"signature_algorithms" extension and		format="default"/>. </t></li>
	which is one of the values defined in <xref targ
	et="SSD" format="default"/>.
	</li>
	<li>		<li>
	<t>		<t>
	The CertificateVerify.signature field contains t		The CertificateVerify.signature field contains
	he sgn value, which is computed as follows:		the sgn value that is computed as follows:
	</t>		</t>
	<ul empty="true" spacing="normal">		<t indent="3">sgn = SIGN(d_sign, M),
	<li>		</t>
	sgn = SIGN(d_sign, M),
	</li>
	</ul>
	<t>		<t>
	where		where
	</t>		</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>
	the SIGN function is defined in <xref ta rget="SIGN" format="default"/>,		the SIGN function is defined in <xref ta rget="SIGN" format="default"/>;
	</li>		</li>
	<li>		<li>
	d_sign is the sender's long-term private key that corresponds to		d_sign is the sender's long-term private key that corresponds to
	the sender's long-term public key Q_sign from the sender's certificate,		the sender's long-term public key Q_sign from the sender's certificate;
	</li>		</li>
	<li>		<li>
	the message M is defined in accordance w ith Section 4.4.3 of <xref target="RFC8446" format="default"/>.		the message M is defined in accordance w ith <xref target="RFC8446" sectionFormat="of" section="4.4.3"/>.
	</li>		</li>
	</ul>		</ul>
	</li>		</li>
	</ul>		</ul>
	</section>		</section>
	</section>		</section>
	</section>		</section>
	<section anchor="IANACON" numbered="true" toc="default">		<section anchor="IANACON" numbered="true" toc="default">
	<name>IANA Considerations</name>		<name>IANA Considerations</name>
	<t>		<t>
	IANA has added the following values to		IANA has added the following values to the "TLS Cipher Suites"
	the "TLS Cipher Suites" registry:		registry with a reference to this RFC:
	</t>		</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[
	+----------+-----------------------------+-------+-------------+-----------+		<table>
	| Value | Description |DTLS-OK| Recommended | Reference |		<thead>
	+----------+-----------------------------+-------+-------------+-----------+		<tr>
	|0xC1, 0x03| TLS_GOSTR341112_256_ | N | N | this RFC |		<th>Value</th>
	| | _WITH_KUZNYECHIK_MGM_L | | | |		<th>Description</th>
	+----------+-----------------------------+-------+-------------+-----------+		<th>DTLS-OK</th>
	|0xC1, 0x04| TLS_GOSTR341112_256_ | N | N | this RFC |		<th>Recommended</th>
	| | _WITH_MAGMA_MGM_L | | | |		</tr>
	+----------+-----------------------------+-------+-------------+-----------+		</thead>
	|0xC1, 0x05| TLS_GOSTR341112_256_ | N | N | this RFC |		<tbody>
	| | _WITH_KUZNYECHIK_MGM_S | | | |		<tr>
	+----------+-----------------------------+-------+-------------+-----------+		<td>0xC1, 0x03</td>
	|0xC1, 0x06| TLS_GOSTR341112_256_ | N | N | this RFC |		<td>TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L</td>
	| | _WITH_MAGMA_MGM_S | | | |		<td>N</td>
	+----------+-----------------------------+-------+-------------+-----------+		<td>N</td>
	Table 6		</tr>
			<tr>
	]]></artwork>		<td>0xC1, 0x04</td>
			<td>TLS_GOSTR341112_256_WITH_MAGMA_MGM_L</td>
			<td>N</td>
			<td>N</td>
			</tr>
			<tr>
			<td>0xC1, 0x05</td>
			<td>TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S</td>
			<td>N</td>
			<td>N</td>
			</tr>
			<tr>
			<td>0xC1, 0x06</td>
			<td>TLS_GOSTR341112_256_WITH_MAGMA_MGM_S</td>
			<td>N</td>
			<td>N</td>
			</tr>
			</tbody>
			</table>
	<t>		<t>
	IANA has added the following values to		IANA has added the following values to the "TLS SignatureScheme"
	the "TLS SignatureScheme" registry:		registry with a reference to this RFC:
	</t>		</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<table>
			<thead>
			<tr>
			<th>Value</th>
			<th>Description</th>
			<th>Recommended</th>
			</tr>
			</thead>
			<tbody>
			<tr>
			<td>0x0709</td>
			<td>gostr34102012_256a</td>
			<td>N</td>
			</tr><tr>
			<td>0x070A</td>
			<td>gostr34102012_256b</td>
			<td>N</td>
			</tr><tr>
	+-----------+----------------------+---------------+----------+		<td>0x070B</td>
	| Value | Description | Recommended | Reference|		<td>gostr34102012_256c</td>
	+-----------+----------------------+---------------+----------+		<td>N</td>
	| 0x0709 | gostr34102012_256a | N | this RFC |		</tr><tr>
	+-----------+----------------------+---------------+----------+
	| 0x070A | gostr34102012_256b | N | this RFC |		<td>0x070C</td>
	+-----------+----------------------+---------------+----------+		<td>gostr34102012_256d</td>
	| 0x070B | gostr34102012_256c | N | this RFC |		<td>N</td>
	+-----------+----------------------+---------------+----------+		</tr><tr>
	| 0x070C | gostr34102012_256d | N | this RFC |
	+-----------+----------------------+---------------+----------+		<td>0x070D</td>
	| 0x070D | gostr34102012_512a | N | this RFC |		<td>gostr34102012_512a</td>
	+-----------+----------------------+---------------+----------+		<td>N</td>
	| 0x070E | gostr34102012_512b | N | this RFC |		</tr><tr>
	+-----------+----------------------+---------------+----------+
	| 0x070F | gostr34102012_512c | N | this RFC |		<td>0x070E</td>
	+-----------+----------------------+---------------+----------+		<td>gostr34102012_512b</td>
	Table 7		<td>N</td>
			</tr><tr>
			<td>0x070F</td>
			<td>gostr34102012_512c</td>
			<td>N</td>
			</tr>
			</tbody>
			</table>
	]]></artwork>
	</section>		</section>
	<section anchor="Historical" numbered="true" toc="default">		<section anchor="Historical" numbered="true" toc="default">
	<name>Historical considerations</name>		<name>Historical Considerations</name>
	<t>		<t>
	Due to historical reasons in addition to the curve identifier va		In addition to the curve identifier values listed in <xref targe
	lues listed in Table 5		t="table5"/>,
	there exist some additional identifier values that correspond to		there are some additional identifier values that correspond to t
	the signature schemes as follows.		he signature schemes for historical reasons.
			They are as follows:
	</t>		</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<table>
			<thead>
	+--------------------+-------------------------------------------+		<tr>
	| Description | Curve Identifier Value |		<th>Description</th>
	+--------------------+-------------------------------------------+		<th>Curve Identifier Value</th>
	| gostr34102012_256b | id-GostR3410-2001-CryptoPro-XchA-ParamSet |		</tr>
	| | id-tc26-gost-3410-2012-256-paramSetB |		</thead>
	+--------------------+-------------------------------------------+		<tbody>
	| gostr34102012_256c | id-tc26-gost-3410-2012-256-paramSetC |		<tr>
	+--------------------+-------------------------------------------+		<td>gostr34102012_256b</td>
	| gostr34102012_256d | id-GostR3410-2001-CryptoPro-XchB-ParamSet |		<td>id-GostR3410-2001-CryptoPro-XchA-ParamSet,
	| | id-tc26-gost-3410-2012-256-paramSetD |		id-tc26-gost-3410-2012-256-paramSetB</td>
	+--------------------+-------------------------------------------+		</tr>
	Table 8		<tr>
			<td>gostr34102012_256c</td>
	]]></artwork>		<td>id-tc26-gost-3410-2012-256-paramSetC</td>
			</tr>
			<tr>
			<td>gostr34102012_256d</td>
			<td>id-GostR3410-2001-CryptoPro-XchB-ParamSet,
			id-tc26-gost-3410-2012-256-paramSetD</td>
			</tr>
			</tbody>
			</table>
	<t>		<t>
	Client should be prepared to handle any of them correctly if cor responding signature scheme is included in the "signature_algorithms"		The client should be prepared to handle any of them correctly if the corresponding signature scheme is included in the "signature_algorithms"
	or "signature_algorithms_cert" extensions.		or "signature_algorithms_cert" extensions.
	</t>		</t>
	</section>		</section>
	<section anchor="Security" numbered="true" toc="default">		<section anchor="Security" numbered="true" toc="default">
	<name>Security Considerations</name>		<name>Security Considerations</name>
	<t>		<t>
	In order to create an efficient and side-channel resistant imp		In order to create an efficient and side-channel resistant imp
	lementation, while using the TLSTREE algorithm the functions		lementation while using the TLSTREE algorithm, the functions
	KDF_j, j = 1, 2, 3, SHOULD be called only when necessary (when		KDF_j, j = 1, 2, 3, <bcp14>SHOULD</bcp14> be called only when
	the record sequence number seqnum reaches such a value that		necessary (when the record sequence number seqnum reaches such a value that
	seqnum &amp; C_j != (seqnum - 1) &amp; C_j). Otherwise the pre		seqnum &amp; C_j != (seqnum - 1) &amp; C_j). Otherwise, the pr
	vious value should be used.		evious value should be used.
	</t>		</t>
	</section>		</section>
	</middle>		</middle>
	<back>		<back>
			<displayreference target="I-D.ietf-tls-rfc8446bis" to="RFC8446BIS"/>
	<references>		<references>
	<name>References</name>		<name>References</name>
	<references>		<references>
	<name>Normative References</name>		<name>Normative References</name>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.2119.xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.2119.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.7801.xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.7801.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.6986.xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.6986.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.7091.xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.7091.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.7836.xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.7836.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8174.xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8174.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8446.xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8446.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8645.xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8645.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8891.xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8891.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.9058.xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.9058.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.9189.xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.9189.xml"/>
	</references>		</references>
	<references>		<references>
	<name>Informative References</name>		<name>Informative References</name>
			<!-- [I-D.ietf-tls-rfc8446bis] IESG state I-D Exists -->
	<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D .ietf-tls-rfc8446bis.xml"/>		<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D .ietf-tls-rfc8446bis.xml"/>
	</references>		</references>
	</references>		</references>
	<section anchor="Appendix" numbered="true" toc="default">		<section anchor="Appendix" numbered="true" toc="default">
	<name>Test Examples</name>		<name>Test Examples</name>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>Example 1</name>		<name>Example 1</name>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>Test case</name>
	<t>		<name>Test Case</name>
	Test examples are given for the following order of usi
	ng the TLS13_GOST profile.
	</t>
	<t>
	1. Full TLS Handshake is used.
	</t>
	<t>
	2. ECDHE key exchange mode is used.
	The elliptic curve GC512C is used for ECDHE shared sec
	ret calculation.
	</t>
	<t>
	3. The server side only authentication is used.
	The signature scheme gost34102012_256b is used.
	</t>
	<t>
	4. TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S cipher su
	ite is negotiated.
	</t>
	<t>
	5. Application Data is sent by the server prior to rec
	eiving the Finished message from the client.
	</t>
	<t>
	6. NewSessionTicket is sent after establishing a secur
	e connection.
	</t>
	<t>
	7. Nine Application Data records are sent during the o
	peration of the Record protocol.
	The sequence numbers are selected to demonstrate th
	e operation of the TLSTREE function.
	</t>
	<t>		<t>
	8. Alert protocol is used for closure of the connectio n.		Test examples are given for the following instance of th e TLS13_GOST profile:
	</t>		</t>
			<ol><li>Full TLS Handshake is used.
			</li>
			<li>ECDHE key exchange mode is used. The elliptic curve GC512C
			is used for ECDHE shared secret calculation.
			</li>
			<li>Authentication is only used on the server side. The signature
			scheme gost34102012_256b is used.
			</li>
			<li>TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S cipher suite is
			negotiated.
			</li>
			<li>Application Data is sent by the server prior to receiving the
			Finished message from the client.
			</li>
			<li> NewSessionTicket is sent after establishing a secure connecti
			on.
			</li>
			<li>Nine Application Data records are sent during the operation
			of the Record protocol. The sequence numbers are selected to
			demonstrate the operation of the TLSTREE function.
			</li>
			<li>Alert protocol is used for closure of the connection.
			</li></ol>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>Test examples</name>		<name>Test Examples</name>
	<artwork name="" type="" align="left" alt=""><![CDATA[
			<sourcecode name="" type=""><![CDATA[
	---------------------------Client---------------------------		---------------------------Client---------------------------
	ClientHello message:		ClientHello message:
	msg_type: 01		msg_type: 01
	length: 0000DE		length: 0000DE
	body:		body:
	legacy_version: 0303		legacy_version: 0303
	random: 03030303030303030303030303030303		random: 03030303030303030303030303030303
	03030303030303030303030303030303		03030303030303030303030303030303
	legasy_session_id:		legacy_session_id:
	length: 00		length: 00
	vector: --		vector: --
	cipher_suites:		cipher_suites:
	length: 0002		length: 0002
	vector:		vector:
	CipherSuite: C105		CipherSuite: C105
	compression_methods:		compression_methods:
	length: 01		length: 01
	vector:		vector:
	CompressionMethod: 00		CompressionMethod: 00
	skipping to change at line 1452 ¶		skipping to change at line 1562 ¶
	---------------------------Server---------------------------		---------------------------Server---------------------------
	ServerHello message:		ServerHello message:
	msg_type: 02		msg_type: 02
	length: 0000B6		length: 0000B6
	body:		body:
	legacy_version: 0303		legacy_version: 0303
	random: 83838383838383838383838383838383		random: 83838383838383838383838383838383
	83838383838383838383838383838383		83838383838383838383838383838383
	legasy_session_id:		legacy_session_id:
	length: 00		length: 00
	vector: --		vector: --
	cipher_suite:		cipher_suite:
	CipherSuite: C105		CipherSuite: C105
	compression_method:		compression_method:
	CompressionMethod: 00		CompressionMethod: 00
	extensions:		extensions:
	length: 008E		length: 008E
	vector:		vector:
	Extension: /* supported_versions */		Extension: /* supported_versions */
	skipping to change at line 2913 ¶		skipping to change at line 3023 ¶
	Record layer message:		Record layer message:
	type: 17		type: 17
	legacy_record_version: 0303		legacy_record_version: 0303
	length: 0013		length: 0013
	encrypted_record: CB19F306C3641754BE4FC95390DF06F9		encrypted_record: CB19F306C3641754BE4FC95390DF06F9
	CD44AA		CD44AA
	TLSCiphertext:		TLSCiphertext:
	00000: 17 03 03 00 13 CB 19 F3 06 C3 64 17 54 BE 4F C9		00000: 17 03 03 00 13 CB 19 F3 06 C3 64 17 54 BE 4F C9
	00010: 53 90 DF 06 F9 CD 44 AA		00010: 53 90 DF 06 F9 CD 44 AA]]></sourcecode>
	]]></artwork>
	</section>		</section>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>Example 2</name>		<name>Example 2</name>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>Test case</name>		<name>Test Case</name>
	<t>
	Test examples are given for the following order of usi
	ng the TLS13_GOST profile.
	</t>
	<t>
	1. Full TLS Handshake is used.
	</t>
	<t>
	2. PSK with ECDHE key exchange mode is used.
	The elliptic curve GC256B is used for ECDHE shared sec
	ret calculation.
	</t>
	<t>
	3. The server and client sides authentication is used.
	The external PSK is used for the mutual authentication
	.
	</t>
	<t>
	4. TLS_GOSTR341112_256_WITH_MAGMA_MGM_L cipher suite i
	s negotiated.
	</t>
	<t>
	5. Four Application Data records are sent during the o
	peration of the Record protocol.
	The sequence numbers are selected to demonstrate th
	e operation of the TLSTREE function.
	</t>
	<t>		<t>
	6. Alert protocol is used for closure of the connectio n.		Test examples are given for the following instance of the TLS13_GOST profile:
	</t>		</t>
			<ol><li>Full TLS Handshake is used.
			</li>
			<li>PSK with ECDHE key exchange mode is used. The elliptic
			curve GC256B is used for ECDHE shared secret calculation.
			</li>
			<li>Authentication is used on the server and client sides. The
			external PSK is used for the mutual authentication.
			</li>
			<li>TLS_GOSTR341112_256_WITH_MAGMA_MGM_L cipher suite is negotiate
			d.
			</li>
			<li>Four Application Data records are sent during the operation
			of the Record protocol. The sequence numbers are selected to
			demonstrate the operation of the TLSTREE function.
			</li>
			<li>Alert protocol is used for closure of the connection.
			</li></ol>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>Test examples</name>		<name>Test Examples</name>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<sourcecode name="" type=""><![CDATA[
	ePSK:		ePSK:
	00000: 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80		00000: 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
	00000: 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80		00000: 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
	---------------------------Client---------------------------		---------------------------Client---------------------------
	ClientHello1 message:		ClientHello1 message:
	msg_type: 01		msg_type: 01
	length: 00007B		length: 00007B
	body:		body:
	legacy_version: 0303		legacy_version: 0303
	random: 01010101010101010101010101010101		random: 01010101010101010101010101010101
	01010101010101010101010101010101		01010101010101010101010101010101
	legasy_session_id:		legacy_session_id:
	length: 00		length: 00
	vector: --		vector: --
	cipher_suites:		cipher_suites:
	length: 0002		length: 0002
	vector:		vector:
	CipherSuite: C104		CipherSuite: C104
	compression_methods:		compression_methods:
	length: 01		length: 01
	vector:		vector:
	CompressionMethod: 00		CompressionMethod: 00
	skipping to change at line 3110 ¶		skipping to change at line 3212 ¶
	---------------------------Server---------------------------		---------------------------Server---------------------------
	HelloRetryRequest message:		HelloRetryRequest message:
	msg_type: 02		msg_type: 02
	length: 000034		length: 000034
	body:		body:
	legacy_version: 0303		legacy_version: 0303
	random: CF21AD74E59A6111BE1D8C021E65B891		random: CF21AD74E59A6111BE1D8C021E65B891
	C2A211167ABB8C5E079E09E2C8A8339C		C2A211167ABB8C5E079E09E2C8A8339C
	legasy_session_id:		legacy_session_id:
	length: 00		length: 00
	vector: --		vector: --
	cipher_suite:		cipher_suite:
	CipherSuite: C104		CipherSuite: C104
	compression_method:		compression_method:
	CompressionMethod: 00		CompressionMethod: 00
	extensions:		extensions:
	length: 000C		length: 000C
	vector:		vector:
	Extension: /* supported_versions */		Extension: /* supported_versions */
	skipping to change at line 3161 ¶		skipping to change at line 3263 ¶
	---------------------------Client---------------------------		---------------------------Client---------------------------
	ClientHello2 message:		ClientHello2 message:
	msg_type: 01		msg_type: 01
	length: 0000BF		length: 0000BF
	body:		body:
	legacy_version: 0303		legacy_version: 0303
	random: 01010101010101010101010101010101		random: 01010101010101010101010101010101
	01010101010101010101010101010101		01010101010101010101010101010101
	legasy_session_id:		legacy_session_id:
	length: 00		length: 00
	vector: --		vector: --
	cipher_suites:		cipher_suites:
	length: 0002		length: 0002
	vector:		vector:
	CipherSuite: C104		CipherSuite: C104
	compression_methods:		compression_methods:
	length: 01		length: 01
	vector:		vector:
	CompressionMethod: 00		CompressionMethod: 00
	skipping to change at line 3324 ¶		skipping to change at line 3426 ¶
	---------------------------Server---------------------------		---------------------------Server---------------------------
	ServerHello message:		ServerHello message:
	msg_type: 02		msg_type: 02
	length: 00007C		length: 00007C
	body:		body:
	legacy_version: 0303		legacy_version: 0303
	random: 82828282828282828282828282828282		random: 82828282828282828282828282828282
	82828282828282828282828282828282		82828282828282828282828282828282
	legasy_session_id:		legacy_session_id:
	length: 00		length: 00
	vector: --		vector: --
	cipher_suite:		cipher_suite:
	CipherSuite: C104		CipherSuite: C104
	compression_method:		compression_method:
	CompressionMethod: 00		CompressionMethod: 00
	extensions:		extensions:
	length: 0054		length: 0054
	vector:		vector:
	Extension: /* supported_versions */		Extension: /* supported_versions */
	skipping to change at line 4085 ¶		skipping to change at line 4187 ¶
	TLSInnerPlaintext:		TLSInnerPlaintext:
	00000: 01 00 15		00000: 01 00 15
	Record layer message:		Record layer message:
	type: 17		type: 17
	legacy_record_version: 0303		legacy_record_version: 0303
	length: 000B		length: 000B
	encrypted_record: 464AEEAD391D97987169F3		encrypted_record: 464AEEAD391D97987169F3
	TLSCiphertext:		TLSCiphertext:
	00000: 17 03 03 00 0B 46 4A EE AD 39 1D 97 98 71 69 F3		00000: 17 03 03 00 0B 46 4A EE AD 39 1D 97 98 71 69 F3]]></sourcecode>
	]]></artwork>
	</section>		</section>
	</section>		</section>
	</section>		</section>
	<section anchor="contributors" numbered="true" toc="default">		<section anchor="contributors" numbered="false" toc="default">
	<name>Contributors</name>		<name>Contributors</name>
	<ul spacing="normal">		<contact fullname="Lilia Akhmetzyanova">
	<li>		<organization>CryptoPro</organization>
	<t>		<address>
	Lilia Akhmetzyanova </t>		<postal>
	<t>		</postal>
	CryptoPro </t>		<email>lah@cryptopro.ru</email>
	<t>		</address>
	lah@cryptopro.ru		</contact>
	</t>		<contact fullname="Alexandr Sokolov">
	</li>		<organization>CryptoPro</organization>
	<li>		<address>
	<t>		<postal>
	Alexandr Sokolov </t>		</postal>
	<t>		<email>sokolov@cryptopro.ru</email>
	CryptoPro </t>		</address>
	<t>		</contact>
	sokolov@cryptopro.ru		<contact fullname="Vasily Nikolaev">
	</t>		<organization>CryptoPro</organization>
	</li>		<address>
	<li>		<postal>
	<t>		</postal>
	Vasily Nikolaev </t>		<email>nikolaev@cryptopro.ru</email>
	<t>		</address>
	CryptoPro </t>		</contact>
	<t>
	nikolaev@cryptopro.ru
	</t>
	</li>
	</ul>
	</section>		</section>
	</back>		</back>
	</rfc>		</rfc>
End of changes. 202 change blocks.
	861 lines changed or deleted		878 lines changed or added
This html diff was produced by rfcdiff 1.48.