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> <!-- [rfced] RFC 5208 has been obsoleted by RFC 5958. May we replace
The private key here is presented in PrivateKeyInfo ASN.1 structure, a the informative reference RFC 5208 with RFC 5958? If so, what section
s described in RFC5208 <xref target="RFC5208"/>, Section 5. number should be used?
</t>
Original:
The private key here is presented in PrivateKeyInfo ASN.1 structure,
as described in RFC5208 [RFC5208], Section 5.
-->
<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"/>
</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">
<name>Security Considerations</name>
<t> <t>
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. It is recommended to use a dual KSK algorithm signed zone until GOST-awar e DNSSEC software becomes more widespread, unless GOST-only cryptography is requ ired.
Otherwise, GOST-signed zones may be considered unsigned by the DNSSEC sof tware currently in use. Otherwise, GOST-signed zones may be considered unsigned by the DNSSEC sof tware currently in use.
</t> </t>
<t> <t>
Currently, the cryptographic resistance of the GOST R 34.10-2012 Currently, the cryptographic resistance of the GOST R 34.10-2012
digital signature algorithm is estimated as 2**128 operations of digital signature algorithm is estimated as 2<sup>128</sup> operations o
multiple elliptic curve point computations on prime modulus of order 2** f
256. multiple elliptic curve point computations on a prime modulus of order 2
<sup>256</sup>.
</t> </t>
<t> <t>
Currently, the cryptographic collision resistance of the GOST R 34.11-20 12 Currently, the cryptographic collision resistance of the GOST R 34.11-20 12
hash algorithm is estimated as 2**128 operations of computations of a st ep hash algorithm is estimated as 2<sup>128</sup> operations of computation s of a step
hash function. 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
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. 
245 lines changed or deleted 290 lines changed or added

This html diff was produced by rfcdiff 1.48.