<?xml version='1.0' encoding='utf-8'?> encoding='UTF-8'?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"> nbsp    "&#160;">
  <!ENTITY RFC3110 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3110.xml"> zwsp   "&#8203;">
  <!ENTITY RFC4033 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4033.xml"> nbhy   "&#8209;">
  <!ENTITY RFC4034 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4034.xml">
<!ENTITY RFC4035 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4035.xml">
<!ENTITY RFC4509 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4509.xml">
<!ENTITY RFC5208 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5208.xml">
<!ENTITY RFC5280 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml">
<!ENTITY RFC5933 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5933.xml">
<!ENTITY RFC6840 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6840.xml">
<!ENTITY RFC6986 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6986.xml">
<!ENTITY RFC7091 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7091.xml">
<!ENTITY RFC7836 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7836.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC9215 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9215.xml"> wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
docName="draft-makarenko-gost2012-dnssec-05"
number="9558"
category="info" ipr="trust200902">
  <?rfc strict="yes"?>
  <?rfc compact="yes"?>
  <?rfc subcompact="no"?>
  <?rfc symrefs="yes"?>
  <?rfc sortrefs="no"?>
  <?rfc text-list-symbols="o*+-"?>
  <?rfc toc="yes"?>
ipr="trust200902"
obsoletes=""
updates=""
submissionType="independent"
xml:lang="en"
symRefs="true"
sortRefs="false"
tocInclude="true"
version="3">

  <front>
    <title abbrev="Use of GOST 2012 Signatures in DNSSEC">
    Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC
    </title>
    <seriesInfo name="RFC" value="9558"/>
    <author fullname="Boris Makarenko" initials="B." surname="Makarenko">
      <organization>The Technical center of Internet, LLC</organization>
      <address>
        <postal>
          <street>8 marta str., St., 1, bld Bldg. 12</street>
          <city>Moscow</city>
          <code>127083</code>
          <country>Russian Federation</country>
        </postal>
        <email>bmakarenko@tcinet.ru</email>
      </address>
    </author>
    <author fullname="Vasily Dolmatov" initials="V." surname="Dolmatov" role="editor">
      <organization>JSC "NPK Kryptonite"</organization>
      <address>
        <postal>
          <street>Spartakovskaya sq., Sq., 14, bld 2, JSC "NPK Kryptonite"</street> Bldg. 2</street>
          <city>Moscow</city>
          <code>105082</code>
          <country>Russian Federation</country>
        </postal>
        <email>vdolmatov@gmail.com</email>
      </address>
    </author>

    <date month="January" year="2024" day="25"/> month="March" year="2024"/>

<!-- [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
      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
      Name System Security Extensions (DNSSEC).
      </t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>
        The Domain Name System (DNS) is the global global, hierarchically distributed
        database for Internet Naming. The DNS has been extended to use
        cryptographic keys and digital signatures for the verification of the
        authenticity and integrity of its data. RFC 4033 <xref target="RFC4033"/>, target="RFC4033" format="default"/>, RFC 4034
        <xref target="RFC4034"/>, target="RFC4034" format="default"/>, and RFC 4035 <xref target="RFC4035"/> target="RFC4035" format="default"/> describe these DNS Security
        Extensions, called DNSSEC.
      </t>
      <t>
        RFC 4034 describes how to store DNSKEY and RRSIG resource records, records
        and specifies a list of cryptographic algorithms to use. This
        document extends that list with the signature and hash algorithms
        GOST R 34.10-2012 (<xref target="RFC7091"/>) target="RFC7091" format="default"/>) and GOST R 34.11-2012
        (<xref target="RFC6986"/>), target="RFC6986" format="default"/>), and it specifies how to store DNSKEY data and
        how to produce RRSIG resource records with these algorithms.
      </t>
      <t>
        Algorithms GOsudarstvennyy STandart(GOST)
        GOST R 34.10-2012 and GOST R 34.11-2012 are Russian national standards.
        Their cryptographic properties haven't been independently verified.
      </t>
      <t>
        Familiarity with DNSSEC and with GOST signature and hash algorithms
        is assumed in this document.
      </t>
      <t>
	Caution:
      </t>
      <t>
	This specification is not a standard and does not have IETF community consensus.  It makes use of a cryptographic algorithm that is a national standard for Russia. Neither the IETF nor the IRTF has analyzed that algorithm for suitability for any given application, and it may contain either intended or unintended weaknesses.
      </t>
      <section title="Terminology"> numbered="true" toc="default">
        <name>Terminology</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
          "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
    "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP 14 BCP&nbsp;14 <xref target="RFC2119" /> target="RFC2119"/> <xref target="RFC8174" />
    target="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.
        </t>
      </section>
    </section>
    <section title="DNSKEY numbered="true" toc="default">
      <name>DNSKEY Resource Records"> Records</name>
      <t>
        The format of the DNSKEY RR can be found in RFC 4034 <xref target="RFC4034"/>. target="RFC4034" format="default"/>.
      </t>
      <t>
        GOST R 34.10-2012 public keys are stored with the algorithm number TBA1. 23.
      </t>
      <t>
        According to RFC 7091 <xref target="RFC7091"/>, target="RFC7091" format="default"/>, a GOST R 34.10-2012 public key is a point on the
        elliptic curve Q = (x,y). (x, y). The wire representation of a public key MUST <bcp14>MUST</bcp14>
        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 y.
      </t>
      <t>
        As RFC 6986 and RFC 7091 allows 2 allow two variants of the length of the output hash and the signature
        and many variants of parameters of the digital signature, for the purpose of this
        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
        the digital signature algorithm to be id-tc26-gost-3410-2012-256-paramSetA
        as specified in RFC 7836 <xref target="RFC7836"/>. target="RFC7836" format="default"/>; this document refers to it as "parameter set A".
      </t>
      <section title="Using numbered="true" toc="default">
        <name>Using a Public Key with Existing Cryptographic Libraries"> Libraries</name>
        <t>
          At the time of this writing, existing GOST-aware cryptographic
          libraries are capable of reading GOST R 34.10-2012 public keys via a generic X.509
          API if the key is encoded according to RFC 9215 <xref target="RFC9215"/>, Section 4. target="RFC9215" section="4" sectionFormat="comma" format="default"/>.
        </t>
        <t>
          To make this encoding from the wire format of a GOST R 34.10-2012 public key with
          the parameters used in this document, prepend the 64 octets of key
          data with the following 30-byte sequence:
        </t>
        <figure>
          <artwork>
        <artwork name="" type="" align="left" alt=""><![CDATA[
0x30 0x5c 0x30 0x17 0x06 0x08 0x2a 0x85
0x03 0x07 0x01 0x01 0x01 0x01 0x30 0x0b
0x06 0x09 0x2a 0x85 0x03 0x07 0x01 0x02
0x01 0x01 0x01 0x03 0x41 0x00
</artwork>
        </figure>
]]></artwork>
        <t>
          These bytes provide the following ASN.1 structure suitable for parsing by cryptographic toolkits:
        </t>
	    <figure>
          <artwork>
        <sourcecode type="asn.1"><![CDATA[
  0  92: SEQUENCE {
  2  23:   SEQUENCE {
  4   8:     OBJECT IDENTIFIER '1 2 643 7 1 1 1 1'
 14  11:     SEQUENCE {
 16   9:       OBJECT IDENTIFIER '1 2 643 7 1 2 1 1 1'
       :       }
       :     }
 27  65:   BIT STRING
</artwork>
        </figure>
]]></sourcecode>

        <t>
          The OIDs in the structure above represent a GOST R 34.10-2012 public key with 256 bits a 256-bit private key
          length algorithm and Parameter parameter set A. The structure itself represents SubjectPublicKeyInfo field
          of an X.509 certificate as defined in RFC 5280 <xref target="RFC5280"/>, Section 4.1. target="RFC5280" section="4.1" sectionFormat="comma" format="default"/>
        </t>
      </section>
      <section title="GOST numbered="true" toc="default" anchor="gost_dnskey_rr_ex">
        <name>GOST DNSKEY RR Example"> Example</name>
        <t>
          Given a private key with the following value:
        </t>
        <figure>
          <artwork>
        <artwork name="" type="" align="left" alt=""><![CDATA[
Private-key-format: v1.2
Algorithm: TBA1 23 (ECC-GOST12)
Gost12Asn1: MD4CAQAwFwYIKoUDBwEBAQEwCwYJKoUDBwECAQEBBCD/Mw9o6R5lQHJ13jz0
            W+C1tdsS4W7RJn04rk9MGJq3Hg==
</artwork>
        </figure> MD4CAQAwFwYIKoUDBwEBAQEwCwYJKoUDBwECAQEBBCD/Mw9o6R5lQHJ13
            jz0W+C1tdsS4W7RJn04rk9MGJq3Hg==
]]></artwork>
        <t>
          The following DNSKEY RR stores a DNS zone key for example:
        </t>
        <figure>
          <artwork>
        <sourcecode type="dns-rr"><![CDATA[
example.  600  IN  DNSKEY  256 3 TBA1 23 (
            XGiiHlKUJd5fSeAK5O3L4tUNCPxs4pGqum6wKbqjdkqu
            IQ8nOXrilXZ9HcY8b2AETkWrtWHfwvJD4twPPJFQSA==
    ) ;{id = 47355 (zsk), size = 512b}
</artwork>
        </figure>
        <t>
]]></sourcecode>

<!-- [rfced] RFC 5208 has been obsoleted by RFC 5958.  May we replace
the informative reference RFC 5208 with RFC 5958? If so, what section
number should be used?

Original:
   The private key here is presented in PrivateKeyInfo ASN.1 structure,
   as described in RFC5208 <xref target="RFC5208"/>, [RFC5208], Section 5.
-->

        <t>
          The private key here is presented in PrivateKeyInfo ASN.1 structure, as described in RFC 5958 <xref target="RFC5958"/>
        </t>
        <t>
          Public
          The public key can be calculated from the private key using algorithm described in RFC 7091 <xref target="RFC7091"/>.
        </t>
        <t>
          [RFC Editor note: Note: Algorithm numbers 23 and 5 are used as an example in this document, as actual numbers have not yet been assigned. If the assigned values will differ, the example keys and signatures will have to be recalculated before the official publication of the RFC.] target="RFC7091" format="default"/>.
        </t>

      </section>
    </section>
    <section title="RRSIG numbered="true" toc="default">
      <name>RRSIG Resource Records"> Records</name>
      <t>
       The value of the signature field in the RRSIG RR follows RFC 7091
       <xref target="RFC7091"/> 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
       <xref target="RFC4034"/>. target="RFC4034" format="default"/>.
      </t>
      <figure>
        <artwork>
      <artwork name="" type="" align="left" alt=""><![CDATA[
hash = GOSTR3411-2012(data)
</artwork>
      </figure>
]]></artwork>
      <t>
        where "data" is the wire format data of the resource record set that
        is signed, as specified in RFC 4034 <xref target="RFC4034"/>. target="RFC4034" format="default"/>.
      </t>
      <t>
        The signature is calculated from the hash according to the
        GOST R 34.10-2012 standard, 34.10-2012, and its wire format is compatible with
        RFC 7091 <xref target="RFC7091"/>. target="RFC7091" format="default"/>.
      </t>
      <section title="RRSIG numbered="true" toc="default">
        <name>RRSIG RR Example"> Example</name>
        <t>
          Consider a given RRset consisting of one MX RR to be signed with the
          private key described in Section 2.2 <xref target="gost_dnskey_rr_ex"/> of this document:
        </t>
          <figure><artwork>
        <sourcecode type="dns-rr"><![CDATA[
example.  600  IN  MX  10 mail.example.</artwork>
          </figure> mail.example.]]></sourcecode>
        <t>
          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
          RR will be valid:
        </t>
        <figure>
          <artwork>
        <sourcecode type="dns-rr"><![CDATA[
example.  600 IN  RRSIG MX TBA1 23 1 600 20221103123230 (
                       20221006123230 47355 example.
                       EuLO0Qpn6zT1pzj9T2H5AWjcgzfmjNiK/vj811bExa0V
                       HMOVD9ma8rpf0B+D+V4Q0CWu1Ayzu+H/SyndnOWGxw==
)
</artwork>
        </figure>
]]></sourcecode>
        <t>
          The GOST R 34.10-2012 signature algorithm uses random (pseudorandom) integer k as described in Section 6.1
          of RFC 7091
          <xref target="RFC7091"/>. target="RFC7091" section="6.1" sectionFormat="of" format="default">RFC 7091</xref>.
          The following value for k was used to produce the signature example.</t>
        <figure>
          <artwork>
        <artwork name="" type="" align="left" alt=""><![CDATA[
k = 8BBD0CE7CAF3FC1C2503DF30D13ED5DB75EEC44060FA22FB7E29628407C1E34
</artwork>
        </figure>
]]></artwork>
        <t>
          This value for k MUST NOT <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.
          The actual signature value will differ between signature calculations.
        </t>
      </section>
    </section>
    <section title="DS numbered="true" toc="default">
      <name>DS Resource Records"> Records</name>
      <t>
        The GOST R 34.11-2012 digest algorithm is denoted in DS RRs by the
        digest type TBA2. 5. The wire format of a digest value is compatible with
        RFC 6986 <xref target="RFC6986"/>. target="RFC6986" format="default"/>.
      </t>
      <section title="DS numbered="true" toc="default">
        <name>DS RR Example"> Example</name>
        <t>
          For Key Signing Key (KSK):
        </t>
        <figure>
          <artwork>
        <sourcecode type="dns-rr"><![CDATA[
example.  IN  DNSKEY  257 3 TBA1 23 (
                       p8Req8DLJOfPymO5vExuK4gCcihF5N1YL7veCJ47av+w
                       h/qs9yJpD064k02rYUHfWnr7IjvJlbn3Z0sTZe9GRQ==
                       ) ;{id = 29468 (ksk), size = 512b}
</artwork>
        </figure>
]]></sourcecode>
        <t>
          The DS RR will be:
        </t>
        <figure>
          <artwork>
        <sourcecode type="dns-rr"><![CDATA[
example.  IN  DS  29468 TBA1 TBA2 23 5 (
                      6033725b0ccfc05d1e9d844d49c6cf89
                      0b13d5eac9439189947d5db6c8d1c1ec
                      )
</artwork>
        </figure>
]]></sourcecode>
      </section>
    </section>
    <section title="Operational Considerations"> numbered="true" toc="default">
      <name>Operational Considerations</name>
      <section title="Key Sizes"> numbered="true" toc="default">
        <name>Key Sizes</name>
        <t>
          The key size of GOST R 34.10-2012 public keys conforming to this specification MUST <bcp14>MUST</bcp14> be 512 bits according to RFC 7091 <xref target="RFC7091"/>. target="RFC7091" format="default"/>.
        </t>
      </section>
      <section title="Signature Sizes"> numbered="true" toc="default">
        <name>Signature Sizes</name>
        <t>
          The size of a GOST R 34.10-2012 signature conforming to this specification MUST <bcp14>MUST</bcp14> be 512 bits according to RFC 7091 <xref target="RFC7091"/>. target="RFC7091" format="default"/>.
        </t>
      </section>
      <section title="Digest Sizes"> numbered="true" toc="default">
        <name>Digest Sizes</name>
        <t>
          The size of a GOST R 34.11-2012 digest conforming to this specification MUST <bcp14>MUST</bcp14> be 256 bits according to RFC 6986 <xref target="RFC6986"/>. target="RFC6986" format="default"/>.
        </t>
      </section>
    </section>
    <section title="Implementation Considerations"> numbered="true" toc="default">
      <name>Implementation Considerations</name>
      <t>
        The support of this cryptographic suite in DNSSEC-aware systems is OPTIONAL. <bcp14>OPTIONAL</bcp14>. According to RFC6840 RFC 6840 <xref target="RFC6840"/>, Section 5.2 target="RFC6840" section="5.2" sectionFormat="comma" format="default"/>, systems that do not support these algorithms MUST <bcp14>MUST</bcp14> ignore the RRSIG, DNSKEY DNSKEY, and DS resource records associated with the GOST R 34.10-2012 digital signature algorithm.
      </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 implementation of GOST crypto algorithms available at https://github.com/gost-engine/engine.]
      </t>
    </section>
    <section title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>
        This document updates
        The following entry has been added to the IANA registry for
        "DNS Security Algorithm Numbers". Numbers":
      </t>
      <table>
          <thead>
            <tr>
              <th align="left">Number</th>
              <th align="left">Description</th>
              <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>
        The following entries have entry has 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>
        This document updates the IANA registry for "Digest Algorithms" in the
        "Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms" regsitry group
        by adding an entry for the GOST R 34.11-2012 algorithm:
      </t>
      <figure>
        <artwork>
Value   Algorithm           Status
TBA2    GOST R 34.11-2012   OPTIONAL
</artwork>
      </figure>
      <t>
          [RFC editor note:
          For the purpose of example computations, the following values were used:
          TBA1 = 23, TBA2 = 5. If the assigned values will differ, the example keys and signatures
          will have to be recalculated before the official publication of the RFC.] registry group:
      </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 title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
       It is recommended to use a dual KSK algorithm signed zone until GOST-aware DNSSEC software become becomes more widespread, unless GOST-only cryptography is required.
       Otherwise, GOST-signed zones may be considered unsigned by the DNSSEC software currently in use.
      </t>
      <t>
        Currently, the cryptographic resistance of the GOST R 34.10-2012
        digital signature algorithm is estimated as 2**128 2<sup>128</sup> operations of
        multiple elliptic curve point computations on a prime modulus of order 2**256. 2<sup>256</sup>.
      </t>
      <t>
        Currently, the cryptographic collision resistance of the GOST R 34.11-2012
        hash algorithm is estimated as 2**128 2<sup>128</sup> operations of computations of a step
        hash function.
      </t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3110.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4033.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4034.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4035.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6840.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6986.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7091.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7836.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4509.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5933.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5958.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9215.xml"/>
      </references>
    </references>
    <section title="Acknowledgments"> numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>
        This document is a minor extension to RFC 4034 <xref target="RFC4034"/>. target="RFC4034"
        format="default"/>. Also, we tried to follow the documents RFC 3110
        <xref target="RFC3110"/>, target="RFC3110" format="default"/>, RFC 4509 <xref target="RFC4509"/>,
        target="RFC4509" format="default"/>, and RFC 5933 <xref target="RFC5933"/>
        target="RFC5933" format="default"/> for consistency. The authors of
        and contributors to these documents are gratefully acknowledged for
        their hard work.
      </t>
      <t>
        The following people provided additional feedback, text, and valuable
        assistance: Alexander Venedyukhin, Michael StJohns, Valery Smyslov, Tim Wicinski, Stephane Bortzmeyer. <contact fullname="Alexander Venedyukhin" />,
        <contact fullname="Michael StJohns" />, <contact
        fullname="Valery Smyslov" />, <contact fullname="Tim Wicinski" />, and <contact fullname="Stéphane Bortzmeyer" />.  </t>
    </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>

</rfc>