<?xml version='1.0' encoding='utf-8'?> encoding='UTF-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF"
submissionType="independent"
docName="draft-cuiling-dnsop-sm2-alg-15"
number="9563"
category="info"
ipr="trust200902"
obsoletes=""
updates=""
xml:lang="en"
tocInclude="true"
symRefs="true" sortRefs="false"
sortRefs="true"
version="3">
  <!-- xml2rfc v2v3 conversion 3.19.1 -->
  <!-- Generated by id2xml 1.5.2 on 2024-01-19T02:40:24Z -->

	<front>
    <title abbrev="SM2 Digital Signature Algorithm for DNSS">SM2 DNSSEC">SM2 Digital Signature Algorithm for DNSSEC</title>
    <seriesInfo name="Internet-Draft" value="draft-cuiling-dnsop-sm2-alg-15"/> name="RFC" value="9563"/>
    <author initials="C." surname="Zhang" fullname="Cuiling Zhang">
      <organization>CNNIC</organization>
      <address>
        <postal>
          <street>No.4 South 4th Street, Zhongguancun</street>
          <street>Beijing, 100190</street>
          <street>China</street>
          <city>Beijing</city><code>100190</code>
          <country>China</country>
        </postal>
        <email>zhangcuiling@cnnic.cn</email>
      </address>
    </author>
    <author initials="Y." surname="Liu" fullname="Yukun Liu">
      <organization>CNNIC</organization>
      <address>
        <postal>
          <street>No.4 South 4th Street, Zhongguancun</street>
          <street>Beijing, 100190</street>
          <street>China</street>
          <city>Beijing</city><code>100190</code>
          <country>China</country>
        </postal>
        <email>liuyukun@cnnic.cn</email>
      </address>
    </author>
    <author initials="F." surname="Leng" fullname="Feng Leng">
      <organization>CNNIC</organization>
      <address>
        <postal>
          <street>No.4 South 4th Street, Zhongguancun</street>
          <street>Beijing, 100190</street>
          <street>China</street>
          <city>Beijing</city><code>100190</code>
          <country>China</country>
        </postal>
        <email>lengfeng@cnnic.cn</email>
      </address>
    </author>
    <author initials="Q." surname="Zhao" fullname="Qi Zhao">
      <organization>CNNIC</organization>
      <address>
        <postal>
          <street>No.4 South 4th Street, Zhongguancun</street>
          <street>Beijing, 100190</street>
          <street>China</street>
          <city>Beijing</city><code>100190</code>
          <country>China</country>
        </postal>
        <email>zhaoqi@cnnic.cn</email>
      </address>
    </author>
    <author initials="Z." surname="He" fullname="Zheng He">
      <organization>CNNIC</organization>
      <address>
        <postal>
          <street>No.4 South 4th Street, Zhongguancun</street>
          <street>Beijing, 100190</street>
          <street>China</street>
          <city>Beijing</city><code>100190</code>
          <country>China</country>
        </postal>
        <email>hezh@cnnic.cn</email>
      </address>
    </author>

    <date year="2024" month="January" day="18"/> month="September"/>

<!-- [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 specifies the use of the SM2 digital signature algorithm
   and SM3 hash algorithm for DNS Security (DNSSEC).</t>
      <t>
   This draft document is an independent submission Independent Submission to the RFC series, series and does
   not have consensus of the IETF community.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="sect-1" numbered="true" toc="default">
      <name>Introduction</name>
      <t>
   DNSSEC is broadly defined in <xref target="RFC4033" format="default"/>, <xref target="RFC4034" format="default"/>, and <xref target="RFC4035" format="default"/>.
   It uses cryptographic keys and digital signatures to provide
   authentication of DNS data. DNSSEC signature algorithms are
   registered in the DNSSEC algorithm IANA numbers registry <xref target="IANA" format="default"/>.</t>
      <t>
   This document defines the DNSKEY and RRSIG resource records (RRs)
   of new signing algorithms: SM2 uses elliptic curves over 256-bit
   prime fields with SM3 hash algorithm. (A description of SM2 and SM3 can be found in GB/T 32918.2-2016 GM/T 0003.2-2012 <xref target="GBT-32918.2-2016" target="GMT-0003.2" format="default"/> or ISO/IEC14888-3:2018
   <xref target="ISO-IEC14888-3_2018" format="default"/>, and GB/T 32905-2016 a description of SM3
   can be found in GM/T 0004-2012 <xref target="GBT-32905-2016" target="GMT-0004" format="default"/> or
   ISO/IEC10118-3:2018 <xref target="ISO-IEC10118-3_2018" format="default"/>.) This document also
   defines the DS RR for the SM3 one-way hash algorithm. In the signing
   algorithm defined in this document, the size of the key for the
   elliptic curve is matched with the size of the output of the hash
   algorithm. Both are 256 bits.</t>

<t>
Many implementations may not support SM2 signatures and SM3 digests.  <xref target="RFC6840" sectionFormat="of" section="5.2"/> specifies handling of answers in such cases.</t>

<t>
Caution: This specification is not a standard and does not have IETF community consensus. It makes use of cryptographic algorithms that are national standards for China, as well as ISO/IEC standards (ISO/IEC 14888:3-2018 <xref target="ISO-IEC14888-3_2018"/> and ISO/IEC 10118:3-2018 <xref target="ISO-IEC10118-3_2018" format="default"/>). 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>
      <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD 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&nbsp;14 <xref target="RFC2119" format="default"/>.</t> target="RFC2119"/> <xref
    target="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.</t>
    </section>
    <section anchor="sect-2" numbered="true" toc="default">
      <name>SM3 DS Records</name>
      <t>
   The implementation of SM3 in DNSSEC follows the implementation of
   SHA-256 as specified in <xref target="RFC4509" format="default"/> except that the underlying
   algorithm is SM3 with digest type code [TBD1, waiting for an IANA's code assignment].</t> 6.</t>
      <t>
   The generation of a an SM3 hash value is described in Section 5 of
   <xref target="GBT-32905-2016" target="GMT-0004" format="default"/> and generates a 256-bit hash value.</t>
    </section>
    <section anchor="sect-3" numbered="true" toc="default">
      <name>SM2 Parameters</name>
      <t>
   Verifying SM2 signatures requires agreement between the signer and
   the verifier of on the parameters used. The SM2 digital signature algorithm
   has been added to ISO/IEC 14888-3:2018. And the <xref target="ISO-IEC14888-3_2018"/>. The parameters of the
   curve used in this profile are as follows:</t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
p  = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF
     FFFFFFFF 00000000 FFFFFFFF FFFFFFFF
a  = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF
     FFFFFFFF 00000000 FFFFFFFF FFFFFFFC
b  = 28E9FA9E 9D9F5E34 4D5A9E4B CF6509A7
     F39789F5 15AB8F92 DDBCBD41 4D940E93
xG = 32C4AE2C 1F198119 5F990446 6A39C994
     8FE30BBF F2660BE1 715A4589 334C74C7
yG = BC3736A2 F4F6779C 59BDCEE3 6B692153
     D0A9877C C62A4740 02DF32E5 2139F0A0
n  = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF
     7203DF6B 21C6052B 53BBF409 39D54123
]]></artwork>
    </section>
    <section anchor="sect-4" numbered="true" toc="default">
      <name>DNSKEY and RRSIG Resource Records for SM2</name>
      <section anchor="sect-4.1" numbered="true" toc="default">
        <name>DNSKEY Resource Records</name>
        <t>
   SM2 public keys consist of a single value, called "P".  In DNSSEC
   keys, P is a string of 32 64 octets that represents the uncompressed
   form of a curve point, "x | y".  (Conversion of a point to an octet
   string is described in Section 4.2.8 of GB/T 32918.1-2016 <xref target="GBT-32918.1-2016" format="default"/>.)</t>
      </section>
      <section anchor="sect-4.2" numbered="true" toc="default">
        <name>RRSIG Resource Records</name>
        <t>
   The SM2 signature is the combination of two non-negative integers,
   called "r" and "s". The two integers, each of which is formatted as
   a simple octet string, are combined into a single longer octet string
   for DNSSEC as the concatenation "r | s". (Conversion of the integers
   to bit strings is described in Section 4.2.1 of <xref target="GBT-32918.1-2016" format="default"/>.)
   Each integer MUST <bcp14>MUST</bcp14> be encoded as 32 octets.</t>
        <t>
   Process details are described in Section 6 of <xref target="sect-6" format="default"/> "Digital signature generation algorithm and its process" in <xref target="GBT-32918.2-2016" target="GMT-0003.2" format="default"/>.</t>
        <t>
   The algorithm number associated with the DNSKEY and RRSIG resource records
   is [TBD2, waiting for an IANA’s code assignment], 17, which is described in
   the IANA Considerations section.</t>

        <t>
   Conformant implementations that create records to be put into the DNS MAY <bcp14>MAY</bcp14>
   implement signing and verification for the above SM2 digital signature algorithm. Conformant
   DNSSEC verifiers MAY <bcp14>MAY</bcp14> implement verification for the above algorithm.</t>
      </section>
    </section>
    <section anchor="sect-5" numbered="true" toc="default">
      <name>Support for NSEC3 Denial of Existence</name>
      <t>
   This document does not define algorithm aliases mentioned in <xref target="RFC5155" format="default"/>.</t>
      <t>
   A DNSSEC validator that implements the signing algorithms defined in this
   document MUST <bcp14>MUST</bcp14> be able to validate negative answers in the form of both NSEC
   and NSEC3 with hash algorithm SHA-1, as defined in <xref target="RFC5155" format="default"/>. An authoritative
   server that does not implement NSEC3 MAY <bcp14>MAY</bcp14> still serve zones that use the
   signing algorithms defined in this document with NSEC denial of existence.</t>
      <t>
   If using NSEC3, the iterations MUST <bcp14>MUST</bcp14> be 0 and salt MUST <bcp14>MUST</bcp14> be an empty string
   as recommended in Section 3.1 of <xref target="RFC9276" format="default"/>.</t> sectionFormat="of" section="3.1"/>.</t>
    </section>
    <section anchor="sect-6" numbered="true" toc="default">
      <name>Example</name>
      <t>
   The following is an example of SM2 keys and signatures in DNS zone file format,
   including DNSKEY RR, NSEC3PARAM RR, NSEC3 RR with RRSIG RRs RRs, and DS RR.</t>
      <artwork name="" type="" align="left" alt=""><![CDATA[

      <sourcecode type="dns-rr"><![CDATA[
Private-key-format: v1.3
Algorithm: [TBD2] 17 (SM2SM3)
PrivateKey: V24tjJgXxp2ykscKRZdT+iuR5J1xRQN+FKoQACmo9fA=
]]></artwork>
      <dl newline="true" spacing="normal" indent="3">
        <dt>example.

example. 3600 IN DS 27215 TBD2 TBD1 (</dt>
        <dd> 17 6 (
   86671f82dd872e4ee73647a95dff7fd0af599ff8a43f fa26c9a2593091653c0e
   )
	</dd>
      </dl>
      <artwork name="" type="" align="left" alt=""><![CDATA[

example. 3600  IN   DNSKEY  256 3 TBD2 17 (
    7EQ32PTAp+1ac6R9Ze2nfB8pPc2OJqkHSjug
    ALr4SuD9awuQxhfw7wMpiXv7JK4/VwwTrCxJ
    wu+qUuDsgoBK4w==
    ) ; ZSK; alg = SM2SM3 ; key id = 65042
example. 3600  IN   RRSIG   DNSKEY TBD2 17 1 3600 (
    20230901000000 20220901000000 65042 example.
    lF2eq49e62Nn4aT5x8ZI6PdRSTPHPDixZdyl
    lM6GWu4lkRWkpTgWLE4lQK/+qHdNS4DdTd36
    Jsuu0FSO5k48Qg== )

example. 0  IN   NSEC3PARAM 1 0 10 AABBCCDD
example. 0  IN   RRSIG    NSEC3PARAM TBD2 17 1 0 (
       20230901000000 20220901000000 65042 example.
       aqntwEYEJzkVb8SNuJLwdx7f+vivv5IUIeAj
]]></artwork>
      <dl newline="false" spacing="normal" indent="4">
        <dt>62KP1QB93KRGR6LM7SEVPJVNG90BLUE8.example. )

62KP1QB93KRGR6LM7SEVPJVNG90BLUE8.example. 3600 IN NSEC3</dt>
        <dd>
          <t> NSEC3  1 1 10
    AABBCCDD (
          </t>
          <t>
    GTGVQIILTSSJ8FFO9J6DC8PRTFAEA8G2 NS SOA RRSIG DNSKEY NSEC3PARAM )
          </t>
        </dd>
        <dt>62KP1QB93KRGR6LM7SEVPJVNG90BLUE8.example.

62KP1QB93KRGR6LM7SEVPJVNG90BLUE8.example. 3600 IN RRSIG</dt>
        <dd>
          <t> RRSIG  NSEC3 TBD2 17 2
    3600 (
          </t>
          <t>
    20230901000000 20220901000000 65042 example.
    FOWLegTgFkFY9vCOo4kHwjEvZ+IL1NMl4s9V
    hVyPOwokd5uOLKeXTP19HIeEtW73WcJ9XNe/ ie/knp7Edo/hxw== )
          </t>
        </dd>
      </dl>
]]></sourcecode>

      <t>
   Here
<xref target="Example_Program" format="default"/> is an example program <xref target="Example_Program" format="default"/> based on dnspython and gmssl,
   which supplies key generating, zone signing, zone validating validating, and DS RR
   generating functions for convenience.</t>
    </section>
    <section anchor="sect-7" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>
   This document will update the
IANA registry for digest types has registered the following in DS records,
   currently called the "Digest Algorithms," in Algorithms" registry within the "Delegation "DNSSEC Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms" registry group.</t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
       Value          TBD1
       Digest Type    SM3
       Status         OPTIONAL
       Reference      This document
]]></artwork> group. </t>
<table anchor="tab1">
  <thead>
    <tr>
      <th>Value</th>    <!-- <th>:  header -->
      <th>Digest Type</th>
      <th>Status</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>          <!-- The rows -->
    <tr>
      <td>6</td>
      <td>SM3</td>
      <td>OPTIONAL</td>
      <td>This document</td>
    </tr>
  </tbody>
</table>

      <t>
   This document will update the
IANA has registered the following in the "DNS Security Algorithm Numbers" registry within the "Domain Name System Security (DNSSEC) Algorithm Numbers".</t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
       Number         TBD2
       Description    SM2 Numbers" registry group.    </t>

<table anchor="tab2">
  <thead>
    <tr>
      <th>Number</th>    <!-- <th>:  header -->
      <th>Description</th>
      <th>Mnemonic</th>
      <th>Zone Signing</th>
      <th>Trans. Sec.</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>          <!-- The rows -->
    <tr>
      <td>17</td>
      <td>SM2 signing algorithm with SM3 hashing algorithm
       Mnemonic       SM2SM3
       Zone Signing   Y
       Trans. Sec.    *
       Reference      This document
]]></artwork> algorithm</td>
      <td>SM2SM3</td>
      <td>Y</td>
      <td>*</td>
      <td>This document</td>
    </tr>
  </tbody>
</table>
      <t>
   * There has been no determination of standardization of the use of this
   algorithm with Transaction Security.</t>
    </section>
    <section anchor="sect-8" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
   The security strength of SM2 depends on the size of the key. Longer A longer
   key provides stronger security strength. The security of ECC-based
   algorithms is influenced by the curve it uses, too.</t>
      <t>
   Like any cryptographic algorithm, it may come to pass that a weakness
   is found in either SM2 or SM3. In this case, the proper remediation is
   crypto-agility. In the case of DNSSEC, the appropriate approach would
   be to regenerate appropriate DS, DNSKEY, RRSIG, and NSEC3 records.
   Care MUST <bcp14>MUST</bcp14> be taken in this situation to permit appropriate rollovers,
   taking into account record caching. See <xref target="RFC7583" format="default"/> for details. Choice
   of a A suitable replacement algorithm should be one that is both widely
   implemented and not known to have weaknesses.</t>
      <t>
   The security considerations listed in <xref target="RFC4509" format="default"/> apply here as well.</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.8174.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"/>

        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC4033" target="https://www.rfc-editor.org/info/rfc4033" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4033.xml"> anchor="IANA" target="https://www.iana.org/assignments/dns-sec-alg-numbers">
          <front>
            <title>DNS Security Introduction and Requirements</title>
            <author fullname="R. Arends" initials="R." surname="Arends"/>
            <author fullname="R. Austein" initials="R." surname="Austein"/>
            <author fullname="M. Larson" initials="M." surname="Larson"/>
            <author fullname="D. Massey" initials="D." surname="Massey"/>
            <author fullname="S. Rose" initials="S." surname="Rose"/>
            <date month="March" year="2005"/>
            <abstract>
              <t>The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS-TRACK]</t>
            </abstract> Algorithm Numbers</title>
            <author>
              <organization>IANA</organization>
            </author>
            <date/>
          </front>
          <seriesInfo name="RFC" value="4033"/>
          <seriesInfo name="DOI" value="10.17487/RFC4033"/>
        </reference>
        <reference anchor="RFC4034" target="https://www.rfc-editor.org/info/rfc4034" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4034.xml">
          <front>
            <title>Resource Records

	<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.5155.xml"/>
<!-- [rfced] verify that an informational ref for 6840 is correct -->
	<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.9276.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7583.xml"/>

<!-- [rfced] We have updated the DNS Security Extensions</title>
            <author fullname="R. Arends" initials="R." surname="Arends"/>
            <author fullname="R. Austein" initials="R." surname="Austein"/>
            <author fullname="M. Larson" initials="M." surname="Larson"/>
            <author fullname="D. Massey" initials="D." surname="Massey"/>
            <author fullname="S. Rose" initials="S." surname="Rose"/>
            <date month="March" year="2005"/>
            <abstract>
              <t>This document references.  However, it is part of a family of documents that describe not clear to us whether the DNS Security Extensions (DNSSEC). The DNS Security Extensions
versions available on GMBZ are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines same as the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record published versions.  For example, the following is given.</t>
              <t>This document obsoletes RFC 2535 and incorporates changes from all updates related to RFC 2535. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4034"/>
          <seriesInfo name="DOI" value="10.17487/RFC4034"/>
        </reference>
        <reference anchor="RFC4035" target="https://www.rfc-editor.org/info/rfc4035" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4035.xml">
          <front>
            <title>Protocol Modifications for the DNS Security Extensions</title>
            <author fullname="R. Arends" initials="R." surname="Arends"/>
            <author fullname="R. Austein" initials="R." surname="Austein"/>
            <author fullname="M. Larson" initials="M." surname="Larson"/>
            <author fullname="D. Massey" initials="D." surname="Massey"/>
            <author fullname="S. Rose" initials="S." surname="Rose"/>
            <date month="March" year="2005"/>
            <abstract>
              <t>This document [GMT-32905-2016].

- On http://www.gmbz.org.cn/upload/2018-07-24/1532401392982079739.pdf
Section 3 is part of missing a family of documents that describe definition for "n".

- On https://www.chinesestandard.net/PDF.aspx/GMT32905-2016 (Preview the DNS Security Extensions (DNSSEC). The DNS Security Extensions are PDF)
Section 3 includes a collection of new resource records and protocol modifications definition for "n".

Note that add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines there are other differences in the concept of a signed zone, along with definitions as well.

Are the requirements for serving and resolving by using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications.</t>
              <t>This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4035"/>
          <seriesInfo name="DOI" value="10.17487/RFC4035"/>
        </reference>
        <reference anchor="IANA" target="https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml">
          <front>
            <title>Domain Name System Security (DNSSEC) Algorithm Numbers</title>
            <author>
              <organization>IANA</organization>
            </author>
            <date month="April" year="2020"/>
          </front>
          <seriesInfo name="Registered" value="DNSSEC Algorithm Numbers"/>
        </reference>
        <reference anchor="RFC4509" target="https://www.rfc-editor.org/info/rfc4509" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4509.xml">
          <front>
            <title>Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)</title>
            <author fullname="W. Hardaker" initials="W." surname="Hardaker"/>
            <date month="May" year="2006"/>
            <abstract>
              <t>This document specifies how to use versions on the SHA-256 digest type in DNS Delegation Signer (DS) Resource Records (RRs). DS records, when stored in a parent zone, point to DNSKEYs in a child zone. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4509"/>
          <seriesInfo name="DOI" value="10.17487/RFC4509"/>
        </reference>
        <reference anchor="RFC5155" target="https://www.rfc-editor.org/info/rfc5155" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5155.xml">
          <front>
            <title>DNS Security (DNSSEC) Hashed Authenticated Denial GMBZ site drafts of Existence</title>
            <author fullname="B. Laurie" initials="B." surname="Laurie"/>
            <author fullname="G. Sisson" initials="G." surname="Sisson"/>
            <author fullname="R. Arends" initials="R." surname="Arends"/>
            <author fullname="D. Blacka" initials="D." surname="Blacka"/>
            <date month="March" year="2008"/>
            <abstract>
              <t>The Domain Name System Security (DNSSEC) Extensions introduced the NSEC resource record (RR) for authenticated denial of existence. This document introduces an standards or perhaps alternative resource record, NSEC3, which similarly provides authenticated denial of existence. However, it also provides measures against zone enumeration and permits gradual expansion of delegation-centric zones. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5155"/>
          <seriesInfo name="DOI" value="10.17487/RFC5155"/>
        </reference>
        <reference anchor="RFC9276" target="https://www.rfc-editor.org/info/rfc9276" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9276.xml">
          <front>
            <title>Guidance for NSEC3 Parameter Settings</title>
            <author fullname="W. Hardaker" initials="W." surname="Hardaker"/>
            <author fullname="V. Dukhovni" initials="V." surname="Dukhovni"/>
            <date month="August" year="2022"/>
            <abstract>
              <t>NSEC3 is a DNSSEC mechanism providing proof of nonexistence by asserting that
translations?  Are there are no names that exist between two domain names within a zone. Unlike its counterpart NSEC, NSEC3 avoids directly disclosing the bounding domain name pairs. This document provides guidance on setting NSEC3 parameters based on recent operational deployment experience. This document updates RFC 5155 with guidance any concerns about selecting NSEC3 iteration and salt parameters.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="236"/>
          <seriesInfo name="RFC" value="9276"/>
          <seriesInfo name="DOI" value="10.17487/RFC9276"/>
        </reference>
        <reference anchor="RFC7583" target="https://www.rfc-editor.org/info/rfc7583" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7583.xml">
          <front>
            <title>DNSSEC Key Rollover Timing Considerations</title>
            <author fullname="S. Morris" initials="S." surname="Morris"/>
            <author fullname="J. Ihren" initials="J." surname="Ihren"/>
            <author fullname="J. Dickinson" initials="J." surname="Dickinson"/>
            <author fullname="W. Mekking" initials="W." surname="Mekking"/>
            <date month="October" year="2015"/>
            <abstract>
              <t>This document describes the issues surrounding the timing these differences?

Are there perhaps freely available versions of events in the rolling English translations with some kind of a key in a DNSSEC-secured zone. It presents timelines for the key rollover and explicitly identifies the relationships between the various parameters affecting front matter similar to the process.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7583"/>
          <seriesInfo name="DOI" value="10.17487/RFC7583"/>
        </reference>
        <reference anchor="GBT-32918.1-2016" target="http://www.gmbz.org.cn/upload/2018-07-24/1532401673134070738.pdf">
          <front>
            <title>Information security technology --- Public key cryptographic algorithm SM2 based on elliptic curves --- Part 1: General</title>
            <author>
              <organization>Standardization Administration of China</organization>
            </author>
            <date month="March" year="2017"/>
          </front>
          <seriesInfo name="GB/T" value="32918.2-2016"/>
        </reference> Chinese versions (for example, are there versions that include information identifying it as GB/T standards)?
-->

        <reference anchor="GBT-32918.2-2016" target="http://www.gmbz.org.cn/upload/2018-07-24/1532401673138056311.pdf"> anchor="GMT-0003.2">
          <front>
            <title>Information security technology --- Public
            <title>SM2 public key cryptographic algorithm SM2 based on elliptic curves --- -- Part 2: Digital signature algorithm</title>
            <author>
              <organization>Standardization Administration
              <organization>Cryptography Standardization Technical Committee of China</organization>
            </author>
            <date month="March" year="2017"/> year="2012"/>
          </front>
          <seriesInfo name="GB/T" value="32918.2-2016"/> name="GM/T" value="0003.2-2012"/>
<refcontent>[In Chinese]</refcontent>
<annotation> English translation available at: <eref target="TBD">TBD</eref></annotation>
        </reference>

        <reference anchor="ISO-IEC14888-3_2018">
          <front>
            <title>IT Security techniques -- Digital signatures with appendix -- Part 3: Discrete logarithm based mechanisms</title>
            <author>
              <organization>International Organization for Standardization</organization>
              <organization>ISO/IEC</organization>
            </author>
            <date month="November" year="2018"/>
          </front>
          <seriesInfo name="ISO/IEC" value="14888-3:2018"/>
        </reference>

        <reference anchor="GBT-32905-2016" target="http://www.gmbz.org.cn/upload/2018-07-24/1532401392982079739.pdf"> anchor="GMT-0004">
          <front>
            <title>SM3 Cryptographic Hash Algorithm</title>
            <author>
              <organization>Cryptography Standardization Technical Committee of China</organization>
            </author>
            <date month="March" year="2012"/>
          </front>
          <seriesInfo name="GM/T" value="0004-2012"/>
<refcontent>[In Chinese]</refcontent>
<annotation>English translation available at: <eref target="TBD">TBD</eref>. </annotation>
        </reference>

        <reference anchor="GBT-32918.1-2016">
          <front>
            <title>Information security technology--Public key cryptographic algorithm SM2 based on elliptic curves--Part 1: General</title>
            <author>
              <organization>Standardization Administration of China</organization>
            </author>
            <date month="March" year="2017"/>
          </front>
          <seriesInfo name="GB/T" value="32918.1-2016"/>
<refcontent>[In Chinese]</refcontent>
	<annotation>English translation available at: <eref target="http://www.gmbz.org.cn/upload/2018-07-24/1532401673134070738.pdf">http://www.gmbz.org.cn/upload/2018-07-24/1532401673134070738.pdf</eref></annotation>
        </reference>

<!--
<reference anchor="GBT-32918.1-2016"
target="http://www.gmbz.org.cn/upload/2018-07-24/1532401673134070738.pdf">
          <front>
            <title>Information security technology --- - SM3 cryptographic hash algorithm</title> Cryptographic Hash Algorithm</title>
            <author>
              <organization>Standardization Administration of China</organization>
            </author>
            <date month="March" year="2017"/>
          </front>
          <seriesInfo name="GB/T" value="32905-2016"/>
        </reference>
-->
        <reference anchor="ISO-IEC10118-3_2018">
          <front>
            <title>IT Security techniques -- Hash-functions -- Part 3: Dedicated hash-functions</title>
            <author>
              <organization>International Organization for Standardization</organization>
              <organization>ISO/IEC</organization>
            </author>
            <date month="October" year="2018"/>
          </front>
          <seriesInfo name="ISO/IEC" value="10118-3:2018"/>
        </reference>

      </references>

      <references>
        <name>Informative References</name>

        <reference anchor="Example_Program" target="https://github.com/scooct/dnssec_sm2sm3">
          <front>
            <title>Sign
            <title>sign and Validate DNSSEC Signature validate dnssec signature with SM2SM3 Algorithm</title>
            <author initials="C." surname="Zhang" fullname="C. Zhang">
	</author> sm2sm3 algorithm</title>
            <author/>
            <date month="April" year="2023"/>
          </front>
          <seriesInfo name="SM2SM3" value="DNSSEC Example Program"/>
<refcontent>commit 6f98c17 </refcontent>
        </reference>

      </references>
    </references>

  </back>
</rfc>