rfc9558xml2.original.xml		rfc9558.xml
	<?xml version='1.0' encoding='utf-8'?>		<?xml version='1.0' encoding='UTF-8'?>
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
	<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF		<!DOCTYPE rfc [
	C.2119.xml">		<!ENTITY nbsp "&#160;">
	<!ENTITY RFC3110 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF		<!ENTITY zwsp "&#8203;">
	C.3110.xml">		<!ENTITY nbhy "&#8209;">
	<!ENTITY RFC4033 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF		<!ENTITY wj "&#8288;">
	C.4033.xml">
	<!ENTITY RFC4034 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.4034.xml">
	<!ENTITY RFC4035 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.4035.xml">
	<!ENTITY RFC4509 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.4509.xml">
	<!ENTITY RFC5208 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.5208.xml">
	<!ENTITY RFC5280 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.5280.xml">
	<!ENTITY RFC5933 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.5933.xml">
	<!ENTITY RFC6840 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.6840.xml">
	<!ENTITY RFC6986 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.6986.xml">
	<!ENTITY RFC7091 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.7091.xml">
	<!ENTITY RFC7836 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.7836.xml">
	<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.8174.xml">
	<!ENTITY RFC9215 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	C.9215.xml">
	]>		]>
	<rfc docName="draft-makarenko-gost2012-dnssec-05" category="info" ipr="trust2009
	02">		<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
	<?rfc strict="yes"?>		docName="draft-makarenko-gost2012-dnssec-05"
	<?rfc compact="yes"?>		number="9558"
	<?rfc subcompact="no"?>		category="info"
	<?rfc symrefs="yes"?>		ipr="trust200902"
	<?rfc sortrefs="no"?>		obsoletes=""
	<?rfc text-list-symbols="o*+-"?>		updates=""
	<?rfc toc="yes"?>		submissionType="independent"
			xml:lang="en"
			symRefs="true"
			sortRefs="false"
			tocInclude="true"
			version="3">
	<front>		<front>
	<title abbrev="Use of GOST 2012 Signatures in DNSSEC">		<title abbrev="Use of GOST 2012 Signatures in DNSSEC">
	Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource Records f or DNSSEC		Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource Records f or DNSSEC
	</title>		</title>
	<author fullname="Boris Makarenko" initials="B." surname="Makarenko">		<seriesInfo name="RFC" value="9558"/>
	<organization>The Technical center of Internet, LLC</organization>		<author fullname="Boris Makarenko" initials="B." surname="Makarenko">
			<organization>The Technical center of Internet, LLC</organization>
	<address>		<address>
	<postal>		<postal>
	<street>8 marta str., 1, bld 12</street>		<street>8 marta St., 1, Bldg. 12</street>
	<city>Moscow</city>		<city>Moscow</city>
	<code>127083</code>		<code>127083</code>
	<country>Russian Federation</country>		<country>Russian Federation</country>
	</postal>		</postal>
	<email>bmakarenko@tcinet.ru</email>		<email>bmakarenko@tcinet.ru</email>
	</address>		</address>
	</author>		</author>
	<author fullname="Vasily Dolmatov" initials="V." surname="Dolmatov" role="edit		<author fullname="Vasily Dolmatov" initials="V." surname="Dolmatov" role="ed
	or">		itor">
	<organization>JSC "NPK Kryptonite"</organization>		<organization>JSC "NPK Kryptonite"</organization>
	<address>		<address>
	<postal>		<postal>
	<street>Spartakovskaya sq., 14, bld 2, JSC "NPK Kryptonite"</street>		<street>Spartakovskaya Sq., 14, Bldg. 2</street>
	<city>Moscow</city>		<city>Moscow</city>
	<code>105082</code>		<code>105082</code>
	<country>Russian Federation</country>		<country>Russian Federation</country>
	</postal>		</postal>
	<email>vdolmatov@gmail.com</email>		<email>vdolmatov@gmail.com</email>
	</address>		</address>
	</author>		</author>
	<date month="January" year="2024" day="25"/>
	<abstract>		<date month="March" year="2024"/>
	<t>
			<!-- [rfced] Please insert any keywords (beyond those that appear in
			the title) for use on https://www.rfc-editor.org/search. -->
			<keyword>example</keyword>
			<abstract>
			<t>
	This document describes how to produce digital signatures and hash		This document describes how to produce digital signatures and hash
	functions using the GOST R 34.10-2012 and GOST R 34.11-2012 algorithms		functions using the GOST R 34.10-2012 and GOST R 34.11-2012 algorithms
	for DNSKEY, RRSIG, and DS resource records, for use in the Domain		for DNSKEY, RRSIG, and DS resource records, for use in the Domain
	Name System Security Extensions (DNSSEC).		Name System Security Extensions (DNSSEC).
	</t>		</t>
	</abstract>		</abstract>
	</front>		</front>
	<middle>		<middle>
	<section title="Introduction">		<section numbered="true" toc="default">
			<name>Introduction</name>
	<t>		<t>
	The Domain Name System (DNS) is the global hierarchically distributed		The Domain Name System (DNS) is the global, hierarchically distributed
	database for Internet Naming. The DNS has been extended to use		database for Internet Naming. The DNS has been extended to use
	cryptographic keys and digital signatures for the verification of the		cryptographic keys and digital signatures for the verification of the
	authenticity and integrity of its data. RFC 4033 <xref target="RFC4033"/		authenticity and integrity of its data. RFC 4033 <xref target="RFC4033"
	>, RFC 4034		format="default"/>, RFC 4034
	<xref target="RFC4034"/>, and RFC 4035 <xref target="RFC4035"/> describe		<xref target="RFC4034" format="default"/>, and RFC 4035 <xref target="RF
	these DNS Security		C4035" format="default"/> describe these DNS Security
	Extensions, called DNSSEC.		Extensions, called DNSSEC.
	</t>		</t>
	<t>		<t>
	RFC 4034 describes how to store DNSKEY and RRSIG resource records,		RFC 4034 describes how to store DNSKEY and RRSIG resource records
	and specifies a list of cryptographic algorithms to use. This		and specifies a list of cryptographic algorithms to use. This
	document extends that list with the signature and hash algorithms		document extends that list with the signature and hash algorithms
	GOST R 34.10-2012 (<xref target="RFC7091"/>) and GOST R 34.11-2012		GOST R 34.10-2012 (<xref target="RFC7091" format="default"/>) and GOST R
	(<xref target="RFC6986"/>), and specifies how to store DNSKEY data and		34.11-2012
			(<xref target="RFC6986" format="default"/>), and it specifies how to sto
			re DNSKEY data and
	how to produce RRSIG resource records with these algorithms.		how to produce RRSIG resource records with these algorithms.
	</t>		</t>
	<t>		<t>
	Algorithms GOsudarstvennyy STandart(GOST) R 34.10-2012 and GOST R 34.11- 2012 are Russian national standards.		GOST R 34.10-2012 and GOST R 34.11-2012 are Russian national standards.
	Their cryptographic properties haven't been independently verified.		Their cryptographic properties haven't been independently verified.
	</t>		</t>
	<t>		<t>
	Familiarity with DNSSEC and with GOST signature and hash algorithms		Familiarity with DNSSEC and with GOST signature and hash algorithms
	is assumed in this document.		is assumed in this document.
	</t>		</t>
	<section title="Terminology">		<t>
			Caution:
			</t>
			<t>
			This specification is not a standard and does not have IETF community con
			sensus. It makes use of a cryptographic algorithm that is a national standard f
			or Russia. Neither the IETF nor the IRTF has analyzed that algorithm for suitabi
			lity for any given application, and it may contain either intended or unintended
			weaknesses.
			</t>
			<section numbered="true" toc="default">
			<name>Terminology</name>
	<t>		<t>
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "S		The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
	HOULD", "SHOULD NOT",		"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
	"RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this docume		",
	nt are to be interpreted		"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
	as described in BCP 14 <xref target="RFC2119" /> <xref target="RFC8174		"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	" /> when, and only when,		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
	they appear in all capitals, as shown here.		be
			interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
			target="RFC8174"/> when, and only when, they appear in all capitals, as
			shown here.
	</t>		</t>
	</section>		</section>
	</section>		</section>
	<section title="DNSKEY Resource Records">		<section numbered="true" toc="default">
			<name>DNSKEY Resource Records</name>
	<t>		<t>
	The format of the DNSKEY RR can be found in RFC 4034 <xref target="RFC40 34"/>.		The format of the DNSKEY RR can be found in RFC 4034 <xref target="RFC40 34" format="default"/>.
	</t>		</t>
	<t>		<t>
	GOST R 34.10-2012 public keys are stored with the algorithm number TBA1.		GOST R 34.10-2012 public keys are stored with the algorithm number 23.
	</t>		</t>
	<t>		<t>
	According to RFC 7091 <xref target="RFC7091"/>, a GOST R 34.10-2012 publ		According to RFC 7091 <xref target="RFC7091" format="default"/>, a GOST
	ic key is a point on the		R 34.10-2012 public key is a point on the
	elliptic curve Q = (x,y). The wire representation of a public key MUST		elliptic curve Q = (x, y). The wire representation of a public key <bcp1
			4>MUST</bcp14>
	contain 64 octets, where the first 32 octets contain the little-endian		contain 64 octets, where the first 32 octets contain the little-endian
	representation of x and the second 32 octets contain the little-endian		representation of x and the second 32 octets contain the little-endian
	representation of y.		representation of y.
	</t>		</t>
	<t>		<t>
	As RFC 6986 and RFC 7091 allows 2 variants of length of the output hash and signature		As RFC 6986 and RFC 7091 allow two variants of the length of the output hash and the signature
	and many variants of parameters of the digital signature, for the purpos e of this		and many variants of parameters of the digital signature, for the purpos e of this
	document we use 256-bit variant of the digital signature algorithm, corr esponding		document we use the 256-bit variant of the digital signature algorithm, corresponding with the
	256-bit variant of the digest algorithm. We select the parameters for		256-bit variant of the digest algorithm. We select the parameters for
	the digital signature algorithm to be id-tc26-gost-3410-2012-256-paramSe tA		the digital signature algorithm to be id-tc26-gost-3410-2012-256-paramSe tA
	as specified in RFC 7836 <xref target="RFC7836"/>.		as specified in RFC 7836 <xref target="RFC7836" format="default"/>; this document refers to it as "parameter set A".
	</t>		</t>
	<section title="Using a Public Key with Existing Cryptographic Libraries">		<section numbered="true" toc="default">
			<name>Using a Public Key with Existing Cryptographic Libraries</name>
	<t>		<t>
	At the time of this writing, existing GOST-aware cryptographic		At the time of this writing, existing GOST-aware cryptographic
	libraries are capable of reading GOST R 34.10-2012 public keys via a g eneric X.509		libraries are capable of reading GOST R 34.10-2012 public keys via a g eneric X.509
	API if the key is encoded according to RFC 9215 <xref target="RFC9215" />, Section 4.		API if the key is encoded according to RFC 9215 <xref target="RFC9215" section="4" sectionFormat="comma" format="default"/>.
	</t>		</t>
	<t>		<t>
	To make this encoding from the wire format of a GOST R 34.10-2012 publ ic key with		To make this encoding from the wire format of a GOST R 34.10-2012 publ ic key with
	the parameters used in this document, prepend the 64 octets of key		the parameters used in this document, prepend the 64 octets of key
	data with the following 30-byte sequence:		data with the following 30-byte sequence:
	</t>		</t>
	<figure>		<artwork name="" type="" align="left" alt=""><![CDATA[
	<artwork>
	0x30 0x5c 0x30 0x17 0x06 0x08 0x2a 0x85		0x30 0x5c 0x30 0x17 0x06 0x08 0x2a 0x85
	0x03 0x07 0x01 0x01 0x01 0x01 0x30 0x0b		0x03 0x07 0x01 0x01 0x01 0x01 0x30 0x0b
	0x06 0x09 0x2a 0x85 0x03 0x07 0x01 0x02		0x06 0x09 0x2a 0x85 0x03 0x07 0x01 0x02
	0x01 0x01 0x01 0x03 0x41 0x00		0x01 0x01 0x01 0x03 0x41 0x00
	</artwork>		]]></artwork>
	</figure>
	<t>		<t>
	These bytes provide the following ASN.1 structure suitable for parsing by cryptographic toolkits:		These bytes provide the following ASN.1 structure suitable for parsing by cryptographic toolkits:
	</t>		</t>
	<figure>		<sourcecode type="asn.1"><![CDATA[
	<artwork>
	0 92: SEQUENCE {		0 92: SEQUENCE {
	2 23: SEQUENCE {		2 23: SEQUENCE {
	4 8: OBJECT IDENTIFIER '1 2 643 7 1 1 1 1'		4 8: OBJECT IDENTIFIER '1 2 643 7 1 1 1 1'
	14 11: SEQUENCE {		14 11: SEQUENCE {
	16 9: OBJECT IDENTIFIER '1 2 643 7 1 2 1 1 1'		16 9: OBJECT IDENTIFIER '1 2 643 7 1 2 1 1 1'
	: }		: }
	: }		: }
	27 65: BIT STRING		27 65: BIT STRING
	</artwork>		]]></sourcecode>
	</figure>
	<t>		<t>
	The OIDs in the structure above represent GOST R 34.10-2012 public key		The OIDs in the structure above represent a GOST R 34.10-2012 public k
	with 256 bits private key		ey with a 256-bit private key
	length algorithm and Parameter set A. The structure itself represents		length and parameter set A. The structure itself represents SubjectPub
	SubjectPublicKeyInfo field		licKeyInfo field
	of an X.509 certificate as defined in RFC 5280 <xref target="RFC5280"/		of an X.509 certificate as defined in RFC 5280 <xref target="RFC5280"
	>, Section 4.1.		section="4.1" sectionFormat="comma" format="default"/>
	</t>		</t>
	</section>		</section>
	<section title="GOST DNSKEY RR Example">		<section numbered="true" toc="default" anchor="gost_dnskey_rr_ex">
			<name>GOST DNSKEY RR Example</name>
	<t>		<t>
	Given a private key with the following value:		Given a private key with the following value:
	</t>		</t>
	<figure>		<artwork name="" type="" align="left" alt=""><![CDATA[
	<artwork>
	Private-key-format: v1.2		Private-key-format: v1.2
	Algorithm: TBA1 (ECC-GOST12)		Algorithm: 23 (ECC-GOST12)
	Gost12Asn1: MD4CAQAwFwYIKoUDBwEBAQEwCwYJKoUDBwECAQEBBCD/Mw9o6R5lQHJ13jz0		Gost12Asn1: MD4CAQAwFwYIKoUDBwEBAQEwCwYJKoUDBwECAQEBBCD/Mw9o6R5lQHJ13
	W+C1tdsS4W7RJn04rk9MGJq3Hg==		jz0W+C1tdsS4W7RJn04rk9MGJq3Hg==
	</artwork>		]]></artwork>
	</figure>
	<t>		<t>
	The following DNSKEY RR stores a DNS zone key for example:		The following DNSKEY RR stores a DNS zone key for example:
	</t>		</t>
	<figure>		<sourcecode type="dns-rr"><![CDATA[
	<artwork>		example. 600 IN DNSKEY 256 3 23 (
	example. 600 IN DNSKEY 256 3 TBA1 (
	XGiiHlKUJd5fSeAK5O3L4tUNCPxs4pGqum6wKbqjdkqu		XGiiHlKUJd5fSeAK5O3L4tUNCPxs4pGqum6wKbqjdkqu
	IQ8nOXrilXZ9HcY8b2AETkWrtWHfwvJD4twPPJFQSA==		IQ8nOXrilXZ9HcY8b2AETkWrtWHfwvJD4twPPJFQSA==
	) ;{id = 47355 (zsk), size = 512b}		) ;{id = 47355 (zsk), size = 512b}
	</artwork>		]]></sourcecode>
	</figure>
	<t>
	The private key here is presented in PrivateKeyInfo ASN.1 structure, a
	s described in RFC5208 <xref target="RFC5208"/>, Section 5.
	</t>
	<t>		<t>
	Public key can be calculated from the private key using algorithm desc ribed in RFC 7091 <xref target="RFC7091"/>.		The private key here is presented in PrivateKeyInfo ASN.1 structure, a s described in RFC 5958 <xref target="RFC5958" sectionFormat="comma" section="2" />.
	</t>		</t>
	<t>		<t>
	[RFC Editor note: Note: Algorithm numbers 23 and 5 are used as an exam ple in this document, as actual numbers have not yet been assigned. If the assig ned values will differ, the example keys and signatures will have to be recalcul ated before the official publication of the RFC.]		The public key can be calculated from the private key using algorithm described in RFC 7091 <xref target="RFC7091" format="default"/>.
	</t>		</t>
	</section>		</section>
	</section>		</section>
	<section title="RRSIG Resource Records">		<section numbered="true" toc="default">
			<name>RRSIG Resource Records</name>
	<t>		<t>
	The value of the signature field in the RRSIG RR follows RFC 7091		The value of the signature field in the RRSIG RR follows RFC 7091
	<xref target="RFC7091"/> and is calculated as follows. The values for th e RDATA		<xref target="RFC7091" format="default"/> and is calculated as follows. The values for the RDATA
	fields that precede the signature data are specified in RFC 4034		fields that precede the signature data are specified in RFC 4034
	<xref target="RFC4034"/>.		<xref target="RFC4034" format="default"/>.
	</t>		</t>
	<figure>		<artwork name="" type="" align="left" alt=""><![CDATA[
	<artwork>
	hash = GOSTR3411-2012(data)		hash = GOSTR3411-2012(data)
	</artwork>		]]></artwork>
	</figure>
	<t>		<t>
	where "data" is the wire format data of the resource record set that		where "data" is the wire format data of the resource record set that
	is signed, as specified in RFC 4034 <xref target="RFC4034"/>.		is signed, as specified in RFC 4034 <xref target="RFC4034" format="defau lt"/>.
	</t>		</t>
	<t>		<t>
	The signature is calculated from the hash according to the		The signature is calculated from the hash according to
	GOST R 34.10-2012 standard, and its wire format is compatible with		GOST R 34.10-2012, and its wire format is compatible with
	RFC 7091 <xref target="RFC7091"/>.		RFC 7091 <xref target="RFC7091" format="default"/>.
	</t>		</t>
	<section title="RRSIG RR Example">		<section numbered="true" toc="default">
			<name>RRSIG RR Example</name>
	<t>		<t>
	Consider a given RRset consisting of one MX RR to be signed with the		Consider a given RRset consisting of one MX RR to be signed with the
	private key described in Section 2.2 of this document:		private key described in <xref target="gost_dnskey_rr_ex"/> of this do cument:
	</t>		</t>
	<figure><artwork>		<sourcecode type="dns-rr"><![CDATA[
	example. 600 IN MX 10 mail.example.</artwork>		example. 600 IN MX 10 mail.example.]]></sourcecode>
	</figure>
	<t>		<t>
	Setting the inception date to 2022-10-06 12:32:30 UTC and the		Setting the inception date to 2022-10-06 12:32:30 UTC and the
	expiration date to 2022-11-03 12:32:30 UTC, the following signature		expiration date to 2022-11-03 12:32:30 UTC, the following signature
	RR will be valid:		RR will be valid:
	</t>		</t>
	<figure>		<sourcecode type="dns-rr"><![CDATA[
	<artwork>		example. 600 IN RRSIG MX 23 1 600 20221103123230 (
	example. 600 IN RRSIG MX TBA1 1 600 20221103123230 (
	20221006123230 47355 example.		20221006123230 47355 example.
	EuLO0Qpn6zT1pzj9T2H5AWjcgzfmjNiK/vj811bExa0V		EuLO0Qpn6zT1pzj9T2H5AWjcgzfmjNiK/vj811bExa0V
	HMOVD9ma8rpf0B+D+V4Q0CWu1Ayzu+H/SyndnOWGxw==		HMOVD9ma8rpf0B+D+V4Q0CWu1Ayzu+H/SyndnOWGxw==
	)		)
	</artwork>		]]></sourcecode>
	</figure>
	<t>		<t>
	The GOST R 34.10-2012 signature algorithm uses random (pseudorandom) i		The GOST R 34.10-2012 signature algorithm uses random (pseudorandom) i
	nteger k as described in Section 6.1		nteger k as described in
	of RFC 7091 <xref target="RFC7091"/>.		<xref target="RFC7091" section="6.1" sectionFormat="of" format="defaul
			t">RFC 7091</xref>.
	The following value for k was used to produce the signature example.</ t>		The following value for k was used to produce the signature example.</ t>
	<figure>		<artwork name="" type="" align="left" alt=""><![CDATA[
	<artwork>
	k = 8BBD0CE7CAF3FC1C2503DF30D13ED5DB75EEC44060FA22FB7E29628407C1E34		k = 8BBD0CE7CAF3FC1C2503DF30D13ED5DB75EEC44060FA22FB7E29628407C1E34
	</artwork>		]]></artwork>
	</figure>
	<t>		<t>
	This value for k MUST NOT be used when computing GOST R 34.10-2012 sig natures.		This value for k <bcp14>MUST NOT</bcp14> be used when computing GOST R 34.10-2012 signatures.
	It is provided only so the above signature example can be reproduced.		It is provided only so the above signature example can be reproduced.
	The actual signature value will differ between signature calculations.		The actual signature value will differ between signature calculations.
	</t>		</t>
	</section>		</section>
	</section>		</section>
	<section title="DS Resource Records">		<section numbered="true" toc="default">
			<name>DS Resource Records</name>
	<t>		<t>
	The GOST R 34.11-2012 digest algorithm is denoted in DS RRs by the		The GOST R 34.11-2012 digest algorithm is denoted in DS RRs by the
	digest type TBA2. The wire format of a digest value is compatible with		digest type 5. The wire format of a digest value is compatible with
	RFC 6986 <xref target="RFC6986"/>.		RFC 6986 <xref target="RFC6986" format="default"/>.
	</t>		</t>
	<section title="DS RR Example">		<section numbered="true" toc="default">
			<name>DS RR Example</name>
	<t>		<t>
	For Key Signing Key (KSK):		For Key Signing Key (KSK):
	</t>		</t>
	<figure>		<sourcecode type="dns-rr"><![CDATA[
	<artwork>		example. IN DNSKEY 257 3 23 (
	example. IN DNSKEY 257 3 TBA1 (
	p8Req8DLJOfPymO5vExuK4gCcihF5N1YL7veCJ47av+w		p8Req8DLJOfPymO5vExuK4gCcihF5N1YL7veCJ47av+w
	h/qs9yJpD064k02rYUHfWnr7IjvJlbn3Z0sTZe9GRQ==		h/qs9yJpD064k02rYUHfWnr7IjvJlbn3Z0sTZe9GRQ==
	) ;{id = 29468 (ksk), size = 512b}		) ;{id = 29468 (ksk), size = 512b}
	</artwork>		]]></sourcecode>
	</figure>
	<t>		<t>
	The DS RR will be:		The DS RR will be:
	</t>		</t>
	<figure>		<sourcecode type="dns-rr"><![CDATA[
	<artwork>		example. IN DS 29468 23 5 (
	example. IN DS 29468 TBA1 TBA2 (
	6033725b0ccfc05d1e9d844d49c6cf89		6033725b0ccfc05d1e9d844d49c6cf89
	0b13d5eac9439189947d5db6c8d1c1ec		0b13d5eac9439189947d5db6c8d1c1ec
	)		)
	</artwork>		]]></sourcecode>
	</figure>
	</section>		</section>
	</section>		</section>
	<section title="Operational Considerations">		<section numbered="true" toc="default">
	<section title="Key Sizes">		<name>Operational Considerations</name>
			<section numbered="true" toc="default">
			<name>Key Sizes</name>
	<t>		<t>
	The key size of GOST R 34.10-2012 public keys conforming to this speci fication MUST be 512 bits according to RFC 7091 <xref target="RFC7091"/>.		The key size of GOST R 34.10-2012 public keys conforming to this speci fication <bcp14>MUST</bcp14> be 512 bits according to RFC 7091 <xref target="RFC 7091" format="default"/>.
	</t>		</t>
	</section>		</section>
	<section title="Signature Sizes">		<section numbered="true" toc="default">
			<name>Signature Sizes</name>
	<t>		<t>
	The size of a GOST R 34.10-2012 signature conforming to this specifica tion MUST be 512 bits according to RFC 7091 <xref target="RFC7091"/>.		The size of a GOST R 34.10-2012 signature conforming to this specifica tion <bcp14>MUST</bcp14> be 512 bits according to RFC 7091 <xref target="RFC7091 " format="default"/>.
	</t>		</t>
	</section>		</section>
	<section title="Digest Sizes">		<section numbered="true" toc="default">
			<name>Digest Sizes</name>
	<t>		<t>
	The size of a GOST R 34.11-2012 digest conforming to this specificatio n MUST be 256 bits according to RFC 6986 <xref target="RFC6986"/>.		The size of a GOST R 34.11-2012 digest conforming to this specificatio n <bcp14>MUST</bcp14> be 256 bits according to RFC 6986 <xref target="RFC6986" f ormat="default"/>.
	</t>		</t>
	</section>		</section>
	</section>		</section>
	<section title="Implementation Considerations">		<section numbered="true" toc="default">
	<t>		<name>Implementation Considerations</name>
	The support of this cryptographic suite in DNSSEC-aware systems is OPTIO
	NAL. According to RFC6840 <xref target="RFC6840"/>, Section 5.2 systems that do
	not support these algorithms MUST ignore the RRSIG, DNSKEY and DS resource recor
	ds associated with the GOST R 34.10-2012 digital signature algorithm.
	</t>
	<t>		<t>
	[(To be removed in RFC). To check the correctness of the implementation, authors recommend using OpenSSL 1.1.1 or 3.0.x series, a fork of ldns available at https://github.com/beldmit/ldns/tree/gost2012, and a reference implementatio n of GOST crypto algorithms available at https://github.com/gost-engine/engine.]		The support of this cryptographic suite in DNSSEC-aware systems is <bcp1 4>OPTIONAL</bcp14>. According to RFC 6840 <xref target="RFC6840" section="5.2" s ectionFormat="comma" format="default"/>, systems that do not support these algor ithms <bcp14>MUST</bcp14> ignore the RRSIG, DNSKEY, and DS resource records asso ciated with the GOST R 34.10-2012 digital signature algorithm.
	</t>		</t>
	</section>		</section>
	<section title="IANA Considerations">		<section numbered="true" toc="default">
	<t>		<name>IANA Considerations</name>
	This document updates the IANA registry
	"DNS Security Algorithm Numbers".
	The following entries have been added to the registry:
	</t>
	<figure>
	<artwork>
	Zone Trans.
	Value Algorithm Mnemonic Signing Sec. References
	TBA1 GOST R 34.10-2012 ECC-GOST12 Y * RFC TBA
	</artwork>
	</figure>
	<t>		<t>
	This document updates the IANA registry "Digest Algorithms" in the		The following entry has been added to the IANA registry for
	"Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms" reg		"DNS Security Algorithm Numbers":
	sitry group
	by adding an entry for the GOST R 34.11-2012 algorithm:
	</t>		</t>
	<figure>		<table>
	<artwork>		<thead>
	Value Algorithm Status		<tr>
	TBA2 GOST R 34.11-2012 OPTIONAL		<th align="left">Number</th>
	</artwork>		<th align="left">Description</th>
	</figure>		<th align="left">Mnemonic</th>
			<th align="left">Zone Signing</th>
			<th align="left">Trans. Sec.</th>
			<th align="left">Reference</th>
			</tr>
			</thead>
			<tbody>
			<tr>
			<td align="left">23</td>
			<td align="left">GOST R 34.10-2012</td>
			<td align="left">ECC-GOST12</td>
			<td align="left">Y</td>
			<td align="left">*</td>
			<td align="left">RFC 9558</td>
			</tr>
			</tbody>
			</table>
	<t>		<t>
	[RFC editor note:		The following entry has been added to the IANA registry for "Digest Algo
	For the purpose of example computations, the following values were use		rithms" in the
	d:		"Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms" reg
	TBA1 = 23, TBA2 = 5. If the assigned values will differ, the example k		istry group:
	eys and signatures
	will have to be recalculated before the official publication of the RF
	C.]
	</t>		</t>
			<table>
			<thead>
			<tr>
			<th align="left">Value</th>
			<th align="left">Description</th>
			<th align="left">Status</th>
			<th align="left">Reference</th>
			</tr>
			</thead>
			<tbody>
			<tr>
			<td align="left">5</td>
			<td align="left">GOST R 34.11-2012</td>
			<td align="left">OPTIONAL</td>
			<td align="left">RFC 9558</td>
			</tr>
			</tbody>
			</table>
	</section>		</section>
	<section title="Security Considerations">		<section numbered="true" toc="default">
	<t>		<name>Security Considerations</name>
	It is recommended to use a dual KSK algorithm signed zone until GOST-awar
	e DNSSEC software become more widespread, unless GOST-only cryptography is requi
	red.
	Otherwise, GOST-signed zones may be considered unsigned by the DNSSEC sof
	tware currently in use.
	</t>
	<t>		<t>
	Currently, the cryptographic resistance of the GOST R 34.10-2012		It is recommended to use a dual KSK algorithm signed zone until
	digital signature algorithm is estimated as 2**128 operations of		GOST-aware DNSSEC software becomes more widespread, unless GOST-only
	multiple elliptic curve point computations on prime modulus of order 2**		cryptography is to be used. Otherwise, GOST-signed zones may be
	256.		considered unsigned by the DNSSEC software currently in use.
	</t>		</t>
	<t>		<t>
	Currently, the cryptographic collision resistance of the GOST R 34.11-20		Like all algorithms, it is possible that a signficant flaw could be
	12		discovered with GOST R 34.11-2012. In that case, deployments should
	hash algorithm is estimated as 2**128 operations of computations of a st		roll over to another algorithm. See RFC 7583 <xref target="RFC7583"/>
	ep		on the timing of such changes.
	hash function.
	</t>		</t>
	</section>		</section>
	<section title="Acknowledgments">		</middle>
			<back>
			<references>
			<name>References</name>
			<references>
			<name>Normative References</name>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
			119.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
			110.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
			033.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
			034.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
			035.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
			840.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
			986.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
			091.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
			583.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
			836.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
			174.xml"/>
			</references>
			<references>
			<name>Informative References</name>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
			509.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
			280.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
			933.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
			958.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
			215.xml"/>
			</references>
			</references>
			<section numbered="false" toc="default">
			<name>Acknowledgments</name>
	<t>		<t>
	This document is a minor extension to RFC 4034 <xref target="RFC4034"/>.		This document is a minor extension to RFC 4034 <xref target="RFC4034"
	Also, we		format="default"/>. Also, we tried to follow the documents RFC 3110
	tried to follow the documents RFC 3110 <xref target="RFC3110"/>, RFC 450		<xref target="RFC3110" format="default"/>, RFC 4509 <xref
	9 <xref target="RFC4509"/>,		target="RFC4509" format="default"/>, and RFC 5933 <xref
	and RFC 5933 <xref target="RFC5933"/> for consistency. The authors of an		target="RFC5933" format="default"/> for consistency. The authors of
	d		and contributors to these documents are gratefully acknowledged for
	contributors to these documents are gratefully acknowledged for their ha		their hard work.
	rd work.
	</t>		</t>
	<t>		<t>
	The following people provided additional feedback, text, and valuable		The following people provided additional feedback, text, and valuable
	assistance: Alexander Venedyukhin, Michael StJohns, Valery Smyslov, Tim		assistance: <contact fullname="Alexander Venedyukhin" />,
	Wicinski, Stephane Bortzmeyer.		<contact fullname="Michael StJohns" />, <contact
	</t>		fullname="Valery Smyslov" />, <contact fullname="Tim Wicinski" />, and <
			contact fullname="Stéphane Bortzmeyer" />. </t>
	</section>		</section>
	</middle>
	<back>
	<references title="Normative References">
	&RFC2119;
	&RFC3110;
	&RFC4033;
	&RFC4034;
	&RFC4035;
	&RFC6840;
	&RFC6986;
	&RFC7091;
	&RFC7836;
	&RFC8174;
	</references>
	<references title="Informative References">
	&RFC4509;
	&RFC5208;
	&RFC5280;
	&RFC5933;
	&RFC9215;
	</references>
	</back>		</back>
	</rfc>		</rfc>
End of changes. 84 change blocks.
	256 lines changed or deleted		286 lines changed or added
This html diff was produced by rfcdiff 1.48.