rfc9563.original.xml   rfc9563.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" docName="d
raft-cuiling-dnsop-sm2-alg-15" category="info" ipr="trust200902" obsoletes="" up <rfc xmlns:xi="http://www.w3.org/2001/XInclude"
dates="" xml:lang="en" symRefs="true" sortRefs="false" version="3"> submissionType="independent"
<!-- xml2rfc v2v3 conversion 3.19.1 --> docName="draft-cuiling-dnsop-sm2-alg-15"
<!-- Generated by id2xml 1.5.2 on 2024-01-19T02:40:24Z --> number="9563"
category="info"
ipr="trust200902"
obsoletes=""
updates=""
xml:lang="en"
tocInclude="true"
symRefs="true"
sortRefs="false"
version="3">
<!-- [rfced] May we set sortRefs to true so the references will appear in alphan
umeric order? -->
<!-- [rfced] The abbreviated title includes "DNSS". Please confirm this is corr
ect, as we do not find instances of "DNSS" in the RFC Series.
<title abbrev="SM2 Digital Signature Algorithm for DNSS">
-->
<front> <front>
<title abbrev="SM2 Digital Signature Algorithm for DNSS">SM2 Digital Signatu <title abbrev="SM2 Digital Signature Algorithm for DNSS">SM2 Digital Signatu
re Algorithm for DNSSEC</title> re Algorithm for NSSEC</title>
<seriesInfo name="Internet-Draft" value="draft-cuiling-dnsop-sm2-alg-15"/> <seriesInfo name="RFC" value="9563"/>
<author initials="C." surname="Zhang" fullname="Cuiling Zhang"> <author initials="C." surname="Zhang" fullname="Cuiling Zhang">
<organization>CNNIC</organization> <organization>CNNIC</organization>
<address> <address>
<postal> <postal>
<street>No.4 South 4th Street, Zhongguancun</street> <street>No.4 South 4th Street, Zhongguancun</street>
<street>Beijing, 100190</street> <city>Beijing</city><code>100190</code>
<street>China</street> <country>China</country>
</postal> </postal>
<email>zhangcuiling@cnnic.cn</email> <email>zhangcuiling@cnnic.cn</email>
</address> </address>
</author> </author>
<author initials="Y." surname="Liu" fullname="Yukun Liu"> <author initials="Y." surname="Liu" fullname="Yukun Liu">
<organization>CNNIC</organization> <organization>CNNIC</organization>
<address> <address>
<postal> <postal>
<street>No.4 South 4th Street, Zhongguancun</street> <street>No.4 South 4th Street, Zhongguancun</street>
<street>Beijing, 100190</street> <city>Beijing</city><code>100190</code>
<street>China</street> <country>China</country>
</postal> </postal>
<email>liuyukun@cnnic.cn</email> <email>liuyukun@cnnic.cn</email>
</address> </address>
</author> </author>
<author initials="F." surname="Leng" fullname="Feng Leng"> <author initials="F." surname="Leng" fullname="Feng Leng">
<organization>CNNIC</organization> <organization>CNNIC</organization>
<address> <address>
<postal> <postal>
<street>No.4 South 4th Street, Zhongguancun</street> <street>No.4 South 4th Street, Zhongguancun</street>
<street>Beijing, 100190</street> <city>Beijing</city><code>100190</code>
<street>China</street> <country>China</country>
</postal> </postal>
<email>lengfeng@cnnic.cn</email> <email>lengfeng@cnnic.cn</email>
</address> </address>
</author> </author>
<author initials="Q." surname="Zhao" fullname="Qi Zhao"> <author initials="Q." surname="Zhao" fullname="Qi Zhao">
<organization>CNNIC</organization> <organization>CNNIC</organization>
<address> <address>
<postal> <postal>
<street>No.4 South 4th Street, Zhongguancun</street> <street>No.4 South 4th Street, Zhongguancun</street>
<street>Beijing, 100190</street> <city>Beijing</city><code>100190</code>
<street>China</street> <country>China</country>
</postal> </postal>
<email>zhaoqi@cnnic.cn</email> <email>zhaoqi@cnnic.cn</email>
</address> </address>
</author> </author>
<author initials="Z." surname="He" fullname="Zheng He"> <author initials="Z." surname="He" fullname="Zheng He">
<organization>CNNIC</organization> <organization>CNNIC</organization>
<address> <address>
<postal> <postal>
<street>No.4 South 4th Street, Zhongguancun</street> <street>No.4 South 4th Street, Zhongguancun</street>
<street>Beijing, 100190</street> <city>Beijing</city><code>100190</code>
<street>China</street> <country>China</country>
</postal> </postal>
<email>hezh@cnnic.cn</email> <email>hezh@cnnic.cn</email>
</address> </address>
</author> </author>
<date year="2024" month="January" day="18"/>
<date year="2024" month="April"/>
<!-- [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> <abstract>
<t> <t>
This document specifies the use of the SM2 digital signature algorithm This document specifies the use of the SM2 digital signature algorithm
and SM3 hash algorithm for DNS Security (DNSSEC).</t> and SM3 hash algorithm for DNS Security (DNSSEC).</t>
<t> <t>
This draft is an independent submission to the RFC series, and does This document is an Independent Submission to the RFC series and does
not have consensus of the IETF community.</t> not have consensus of the IETF community.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="sect-1" numbered="true" toc="default"> <section anchor="sect-1" numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<t> <t>
DNSSEC is broadly defined in <xref target="RFC4033" format="default"/>, <xref target="RFC4034" format="default"/>, and <xref target="RFC4035" format="default "/>. 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 It uses cryptographic keys and digital signatures to provide
authentication of DNS data. DNSSEC signature algorithms are authentication of DNS data. DNSSEC signature algorithms are
registered in the DNSSEC algorithm IANA registry <xref target="IANA" format=" default"/>.</t> registered in the DNSSEC algorithm numbers registry <xref target="IANA" forma t="default"/>.</t>
<t> <t>
This document defines the DNSKEY and RRSIG resource records (RRs) This document defines the DNSKEY and RRSIG resource records (RRs)
of new signing algorithms: SM2 uses elliptic curves over 256-bit of new signing algorithms: SM2 uses elliptic curves over 256-bit
prime fields with SM3 hash algorithm. (A description of SM2 and SM3 prime fields with SM3 hash algorithm. (A description of SM2 can be found in G
can be found in GB/T 32918.2-2016 <xref target="GBT-32918.2-2016" format="def B/T 32918.2-2016 <xref target="GBT-32918.2-2016" format="default"/> or ISO/IEC14
ault"/> or ISO/IEC14888-3:2018 888-3:2018
<xref target="ISO-IEC14888-3_2018" format="default"/>, and GB/T 32905-2016 <x <xref target="ISO-IEC14888-3_2018" format="default"/>, and a description of S
ref target="GBT-32905-2016" format="default"/> or M3
can be found in GB/T 32905-2016 <xref target="GBT-32905-2016" format="default
"/> or
ISO/IEC10118-3:2018 <xref target="ISO-IEC10118-3_2018" format="default"/>.) T his document also ISO/IEC10118-3:2018 <xref target="ISO-IEC10118-3_2018" format="default"/>.) T his document also
defines the DS RR for the SM3 one-way hash algorithm. In the signing 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 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 elliptic curve is matched with the size of the output of the hash
algorithm. Both are 256 bits.</t> algorithm. Both are 256 bits.</t>
<t> <t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
document are to be interpreted as described in <xref target="RFC2119" format= ",
"default"/>.</t> "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
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>
</section> </section>
<section anchor="sect-2" numbered="true" toc="default"> <section anchor="sect-2" numbered="true" toc="default">
<name>SM3 DS Records</name> <name>SM3 DS Records</name>
<t> <t>
The implementation of SM3 in DNSSEC follows the implementation of The implementation of SM3 in DNSSEC follows the implementation of
SHA-256 as specified in <xref target="RFC4509" format="default"/> except that the underlying 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 assi gnment].</t> algorithm is SM3 with digest type code 6.</t>
<t> <t>
The generation of a SM3 hash value is described in Section 5 of The generation of an SM3 hash value is described in Section 5 of
<xref target="GBT-32905-2016" format="default"/> and generates 256-bit hash v <xref target="GBT-32905-2016" format="default"/> and generates a 256-bit hash
alue.</t> value.</t>
</section> </section>
<section anchor="sect-3" numbered="true" toc="default"> <section anchor="sect-3" numbered="true" toc="default">
<name>SM2 Parameters</name> <name>SM2 Parameters</name>
<t> <t>
Verifying SM2 signatures requires agreement between the signer and Verifying SM2 signatures requires agreement between the signer and
the verifier of the parameters used. SM2 digital signature algorithm the verifier on the parameters used. The SM2 digital signature algorithm
has been added to ISO/IEC 14888-3:2018. And the parameters of the has been added to <xref target="ISO-IEC14888-3_2018"/>. The parameters of the
curve used in this profile are as follows:</t> curve used in this profile are as follows:</t>
<!-- [rfced] The following artwork extends beyond the 72 character margin by 4 c
haracters. Please review and let us know how the lines may be broken.
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 name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
p = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 00000000 FFFFFFFF FFFFFFFF p = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 00000000 FFFFFFFF FFFFFFFF
a = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 00000000 FFFFFFFF FFFFFFFC a = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 00000000 FFFFFFFF FFFFFFFC
b = 28E9FA9E 9D9F5E34 4D5A9E4B CF6509A7 F39789F5 15AB8F92 DDBCBD41 4D940E93 b = 28E9FA9E 9D9F5E34 4D5A9E4B CF6509A7 F39789F5 15AB8F92 DDBCBD41 4D940E93
xG = 32C4AE2C 1F198119 5F990446 6A39C994 8FE30BBF F2660BE1 715A4589 334C74C7 xG = 32C4AE2C 1F198119 5F990446 6A39C994 8FE30BBF F2660BE1 715A4589 334C74C7
yG = BC3736A2 F4F6779C 59BDCEE3 6B692153 D0A9877C C62A4740 02DF32E5 2139F0A0 yG = BC3736A2 F4F6779C 59BDCEE3 6B692153 D0A9877C C62A4740 02DF32E5 2139F0A0
n = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF 7203DF6B 21C6052B 53BBF409 39D54123 n = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF 7203DF6B 21C6052B 53BBF409 39D54123
]]></artwork> ]]></artwork>
</section> </section>
<section anchor="sect-4" numbered="true" toc="default"> <section anchor="sect-4" numbered="true" toc="default">
<name>DNSKEY and RRSIG Resource Records for SM2</name> <name>DNSKEY and RRSIG Resource Records for SM2</name>
<section anchor="sect-4.1" numbered="true" toc="default"> <section anchor="sect-4.1" numbered="true" toc="default">
<name>DNSKEY Resource Records</name> <name>DNSKEY Resource Records</name>
<t> <t>
SM2 public keys consist of a single value, called "P". In DNSSEC keys, SM2 public keys consist of a single value, called "P". In DNSSEC keys,
P is a string of 32 octets that represents the uncompressed form of a P is a string of 32 octets that represents the uncompressed form of a
curve point, "x | y". (Conversion of a point to an octet string is 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-201 6" format="default"/>.)</t> described in Section 4.2.8 of <xref target="GBT-32918.1-2016" format="default "/>.)</t>
</section> </section>
<section anchor="sect-4.2" numbered="true" toc="default"> <section anchor="sect-4.2" numbered="true" toc="default">
<name>RRSIG Resource Records</name> <name>RRSIG Resource Records</name>
<t> <t>
The SM2 signature is the combination of two non-negative integers, The SM2 signature is the combination of two non-negative integers,
called "r" and "s". The two integers, each of which is formatted as 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 a simple octet string, are combined into a single longer octet string
for DNSSEC as the concatenation "r | s". (Conversion of the integers 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-201 6" format="default"/>.) to bit strings is described in Section 4.2.1 of <xref target="GBT-32918.1-201 6" format="default"/>.)
Each integer MUST be encoded as 32 octets.</t> Each integer <bcp14>MUST</bcp14> be encoded as 32 octets.</t>
<t> <t>
Process details are described in <xref target="sect-6" format="default"/> "Di gital signature generation algorithm and its process" in <xref target="GBT-32918 .2-2016" format="default"/>.</t> Process details are described in Section 6 of <xref target="GBT-32918.2-2016" format="default"/>.</t>
<t> <t>
The algorithm number associated with the DNSKEY and RRSIG resource records The algorithm number associated with the DNSKEY and RRSIG resource records
is [TBD2, waiting for an IANA’s code assignment], which is described in is 17, which is described in
the IANA Considerations section.</t> the IANA Considerations section.</t>
<!-- [rfced] Does the "above algorithm" refer to the digital signature algorithm
, and is this different from the digital signature generation algorithm?
Original:
Conformant implementations that create records to be put into the DNS
MAY implement signing and verification for the above algorithm.
Conformant DNSSEC verifiers MAY implement verification for the above
algorithm.
-->
<t> <t>
Conformant implementations that create records to be put into the DNS MAY Conformant implementations that create records to be put into the DNS <bcp14> MAY</bcp14>
implement signing and verification for the above algorithm. Conformant implement signing and verification for the above algorithm. Conformant
DNSSEC verifiers MAY implement verification for the above algorithm.</t> DNSSEC verifiers <bcp14>MAY</bcp14> implement verification for the above algo rithm.</t>
</section> </section>
</section> </section>
<section anchor="sect-5" numbered="true" toc="default"> <section anchor="sect-5" numbered="true" toc="default">
<name>Support for NSEC3 Denial of Existence</name> <name>Support for NSEC3 Denial of Existence</name>
<t> <t>
This document does not define algorithm aliases mentioned in <xref target="RF C5155" format="default"/>.</t> This document does not define algorithm aliases mentioned in <xref target="RF C5155" format="default"/>.</t>
<t> <t>
A DNSSEC validator that implements the signing algorithms defined in this A DNSSEC validator that implements the signing algorithms defined in this
document MUST be able to validate negative answers in the form of both NSEC document <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" for mat="default"/>. An authoritative and NSEC3 with hash algorithm SHA-1, as defined in <xref target="RFC5155" for mat="default"/>. An authoritative
server that does not implement NSEC3 MAY still serve zones that use the server that does not implement NSEC3 <bcp14>MAY</bcp14> still serve zones tha t use the
signing algorithms defined in this document with NSEC denial of existence.</t > signing algorithms defined in this document with NSEC denial of existence.</t >
<t> <t>
If using NSEC3, the iterations MUST be 0 and salt MUST be an empty string If using NSEC3, the iterations <bcp14>MUST</bcp14> be 0 and salt <bcp14>MUST<
as recommended in Section 3.1 of <xref target="RFC9276" format="default"/>.</ /bcp14> be an empty string
t> as recommended in <xref target="RFC9276" sectionFormat="of" section="3.1"/>.<
/t>
</section> </section>
<section anchor="sect-6" numbered="true" toc="default"> <section anchor="sect-6" numbered="true" toc="default">
<name>Example</name> <name>Example</name>
<t> <t>
The following is an example of SM2 keys and signatures in DNS zone file forma t, The following is an example of SM2 keys and signatures in DNS zone file forma t,
including DNSKEY RR, NSEC3PARAM RR, NSEC3 RR with RRSIG RRs and DS RR.</t> including DNSKEY RR, NSEC3PARAM RR, NSEC3 RR with RRSIG RRs, and DS RR.</t>
<!-- [rfced] It's unclear why some of the example text in Section 6 was formatte
d as a definition list <dl> and some as <artwork>. We have combined the text in
to one <artwork> block. However, we wonder whether this should be <sourcecode>,
perhaps with type="dns-rr".
The current list of preferred <sourcecode> values for "type" is available at
https://www.rfc-editor.org/materials/sourcecode-types.txt. If the current
list does not contain an applicable type, feel free to suggest additions
for consideration. Note that it is also acceptable to leave the "type"
attribute not set.
Please review the output carefully and pay particular attention to line breaks a
nd wrapping.
-->
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
Private-key-format: v1.3 Private-key-format: v1.3
Algorithm: [TBD2] (SM2SM3) Algorithm: 17 (SM2SM3)
PrivateKey: V24tjJgXxp2ykscKRZdT+iuR5J1xRQN+FKoQACmo9fA= PrivateKey: V24tjJgXxp2ykscKRZdT+iuR5J1xRQN+FKoQACmo9fA=
]]></artwork>
<dl newline="true" spacing="normal" indent="3"> example. 3600 IN DS 27215 17 6 (
<dt>example. 3600 IN DS 27215 TBD2 TBD1 (</dt> 86671f82dd872e4ee73647a95dff7fd0af599ff8a43f fa26c9a2593091653c0e
<dd> )
86671f82dd872e4ee73647a95dff7fd0af599ff8a43f
fa26c9a2593091653c0e ) example. 3600 IN DNSKEY 256 3 17 (
</dd>
</dl>
<artwork name="" type="" align="left" alt=""><![CDATA[
example. 3600 IN DNSKEY 256 3 TBD2 (
7EQ32PTAp+1ac6R9Ze2nfB8pPc2OJqkHSjug 7EQ32PTAp+1ac6R9Ze2nfB8pPc2OJqkHSjug
ALr4SuD9awuQxhfw7wMpiXv7JK4/VwwTrCxJ ALr4SuD9awuQxhfw7wMpiXv7JK4/VwwTrCxJ
wu+qUuDsgoBK4w== wu+qUuDsgoBK4w==
) ; ZSK; alg = SM2SM3 ; key id = 65042 ) ; ZSK; alg = SM2SM3 ; key id = 65042
example. 3600 IN RRSIG DNSKEY TBD2 1 3600 ( example. 3600 IN RRSIG DNSKEY 17 1 3600 (
20230901000000 20220901000000 65042 example. 20230901000000 20220901000000 65042 example.
lF2eq49e62Nn4aT5x8ZI6PdRSTPHPDixZdyl lF2eq49e62Nn4aT5x8ZI6PdRSTPHPDixZdyl
lM6GWu4lkRWkpTgWLE4lQK/+qHdNS4DdTd36 lM6GWu4lkRWkpTgWLE4lQK/+qHdNS4DdTd36
Jsuu0FSO5k48Qg== ) Jsuu0FSO5k48Qg== )
example. 0 IN NSEC3PARAM 1 0 10 AABBCCDD example. 0 IN NSEC3PARAM 1 0 10 AABBCCDD
example. 0 IN RRSIG NSEC3PARAM TBD2 1 0 ( example. 0 IN RRSIG NSEC3PARAM 17 1 0 (
20230901000000 20220901000000 65042 example. 20230901000000 20220901000000 65042 example.
aqntwEYEJzkVb8SNuJLwdx7f+vivv5IUIeAj aqntwEYEJzkVb8SNuJLwdx7f+vivv5IUIeAj
62KP1QB93KRGR6LM7SEVPJVNG90BLUE8.example. 3600 IN NSEC3 1 1 10
AABBCCDD (
GTGVQIILTSSJ8FFO9J6DC8PRTFAEA8G2 NS SOA RRSIG DNSKEY NSEC3PARAM )
62KP1QB93KRGR6LM7SEVPJVNG90BLUE8.example. 3600 IN RRSIG NSEC3 17 2
3600 (
20230901000000 20220901000000 65042 example.
FOWLegTgFkFY9vCOo4kHwjEvZ+IL1NMl4s9V
hVyPOwokd5uOLKeXTP19HIeEtW73WcJ9XNe/ ie/knp7Edo/hxw== )
]]></artwork> ]]></artwork>
<dl newline="false" spacing="normal" indent="4">
<dt>62KP1QB93KRGR6LM7SEVPJVNG90BLUE8.example. 3600 IN NSEC3</dt>
<dd>
<t>
1 1 10 AABBCCDD (
</t>
<t>
GTGVQIILTSSJ8FFO9J6DC8PRTFAEA8G2
NS SOA RRSIG DNSKEY NSEC3PARAM )
</t>
</dd>
<dt>62KP1QB93KRGR6LM7SEVPJVNG90BLUE8.example. 3600 IN RRSIG</dt>
<dd>
<t>
NSEC3 TBD2 2 3600 (
</t>
<t>
20230901000000 20220901000000 65042 example.
FOWLegTgFkFY9vCOo4kHwjEvZ+IL1NMl4s9V
hVyPOwokd5uOLKeXTP19HIeEtW73WcJ9XNe/
ie/knp7Edo/hxw== )
</t>
</dd>
</dl>
<t> <t>
Here is an example program <xref target="Example_Program" format="default"/> <xref target="Example_Program" format="default"/> is an example program based on
based on dnspython and gmssl, dnspython and gmssl,
which supplies key generating, zone signing, zone validating and DS RR which supplies key generating, zone signing, zone validating, and DS RR
generating functions for convenience.</t> generating functions for convenience.</t>
</section> </section>
<section anchor="sect-7" numbered="true" toc="default"> <section anchor="sect-7" numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t> <t>
This document will update the IANA registry for digest types in DS records, IANA has registered the following in the "Digest Algorithms" registry within the
currently called "Digest Algorithms," in the "Delegation Signer (DS) Resource "DNSSEC Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms" reg
Record (RR) Type Digest Algorithms" registry group.</t> istry group. </t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <table anchor="tab1">
Value TBD1 <thead>
Digest Type SM3 <tr>
Status OPTIONAL <th>Value</th> <!-- <th>: header -->
Reference This document <th>Digest Type</th>
]]></artwork> <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> <t>
This document will update the IANA registry "Domain Name System Security (DNS IANA has registered the following in the "DNS Security Algorithm Numbers" regist
SEC) Algorithm Numbers".</t> ry within the "Domain Name System Security (DNSSEC) Algorithm Numbers" registry
<artwork name="" type="" align="left" alt=""><![CDATA[ group. </t>
Number TBD2
Description SM2 signing algorithm with SM3 hashing algorithm <table anchor="tab2">
Mnemonic SM2SM3 <thead>
Zone Signing Y <tr>
Trans. Sec. * <th>Number</th> <!-- <th>: header -->
Reference This document <th>Description</th>
]]></artwork> <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</td>
<td>SM2SM3</td>
<td>Y</td>
<td>*</td>
<td>This document</td>
</tr>
</tbody>
</table>
<t> <t>
* There has been no determination of standardization of the use of this * There has been no determination of standardization of the use of this
algorithm with Transaction Security.</t> algorithm with Transaction Security.</t>
</section> </section>
<section anchor="sect-8" numbered="true" toc="default"> <section anchor="sect-8" numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<t> <t>
The security strength of SM2 depends on the size of the key. Longer The security strength of SM2 depends on the size of the key. A longer
key provides stronger security strength. The security of ECC-based key provides stronger security strength. The security of ECC-based
algorithms is influenced by the curve it uses, too.</t> algorithms is influenced by the curve it uses, too.</t>
<t> <t>
Like any cryptographic algorithm, it may come to pass that a weakness 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 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 crypto-agility. In the case of DNSSEC, the appropriate approach would
be to regenerate appropriate DS, DNSKEY, RRSIG, and NSEC3 records. be to regenerate appropriate DS, DNSKEY, RRSIG, and NSEC3 records.
Care MUST be taken in this situation to permit appropriate rollovers, Care <bcp14>MUST</bcp14> be taken in this situation to permit appropriate rol
taking into account record caching. See <xref target="RFC7583" format="defaul lovers,
t"/> for details. Choice taking into account record caching. See <xref target="RFC7583" format="defaul
of a suitable replacement algorithm should be one that is both widely t"/> for details. A suitable replacement algorithm should be both widely
implemented and not known to have weaknesses.</t> implemented and not known to have weaknesses.</t>
<t> <t>
The security considerations listed in <xref target="RFC4509" format="default" /> apply here as well.</t> The security considerations listed in <xref target="RFC4509" format="default" /> apply here as well.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
119" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21
<front> 19.xml"/>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
le> 74.xml"/>
<author fullname="S. Bradner" initials="S." surname="Bradner"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.40
<date month="March" year="1997"/> 33.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.40
<t>In many standards track documents several words are used to sig 34.xml"/>
nify the requirements in the specification. These words are often capitalized. T <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.40
his document defines these words as they should be interpreted in IETF documents 35.xml"/>
. This document specifies an Internet Best Current Practices for the Internet Co
mmunity, and requests discussion and suggestions for improvements.</t> <reference anchor="IANA" target="https://www.iana.org/assignments/dns-se
</abstract> c-alg-numbers">
</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/rfc4
033" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4033.xml">
<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 or
igin authentication and data integrity to the Domain Name System. This document
introduces these extensions and describes their capabilities and limitations. Th
is 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>
</front>
<seriesInfo name="RFC" value="4033"/>
<seriesInfo name="DOI" value="10.17487/RFC4033"/>
</reference>
<reference anchor="RFC4034" target="https://www.rfc-editor.org/info/rfc4
034" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4034.xml">
<front>
<title>Resource Records 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 is part of a family of documents that describe th
e DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection
of resource records and protocol modifications that provide source authenticati
on for the DNS. This document defines the public key (DNSKEY), delegation signer
(DS), resource record digital signature (RRSIG), and authenticated denial of ex
istence (NSEC) resource records. The purpose and format of each resource record
is described in detail, and an example of each resource record is given.</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="4034"/>
<seriesInfo name="DOI" value="10.17487/RFC4034"/>
</reference>
<reference anchor="RFC4035" target="https://www.rfc-editor.org/info/rfc4
035" 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 is part of a family of documents that describe th
e DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection
of new resource records and protocol modifications that add data origin authent
ication and data integrity to the DNS. This document describes the DNSSEC protoc
ol modifications. This document defines the concept of a signed zone, along with
the requirements for serving and resolving by using DNSSEC. These techniques al
low a security-aware resolver to authenticate both DNS resource records and auth
oritative 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-se
c-alg-numbers/dns-sec-alg-numbers.xhtml">
<front> <front>
<title>Domain Name System Security (DNSSEC) Algorithm Numbers</title > <title>DNS Security Algorithm Numbers</title>
<author> <author>
<organization>IANA</organization> <organization>IANA</organization>
</author> </author>
<date month="April" year="2020"/> <date/>
</front>
<seriesInfo name="Registered" value="DNSSEC Algorithm Numbers"/>
</reference>
<reference anchor="RFC4509" target="https://www.rfc-editor.org/info/rfc4
509" 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 Reco
rds (RRs)</title>
<author fullname="W. Hardaker" initials="W." surname="Hardaker"/>
<date month="May" year="2006"/>
<abstract>
<t>This document specifies how to use the SHA-256 digest type in D
NS Delegation Signer (DS) Resource Records (RRs). DS records, when stored in a p
arent 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/rfc5
155" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5155.xml">
<front>
<title>DNS Security (DNSSEC) Hashed Authenticated Denial of Existenc
e</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 docume
nt introduces an alternative resource record, NSEC3, which similarly provides au
thenticated denial of existence. However, it also provides measures against zone
enumeration and permits gradual expansion of delegation-centric zones. [STANDAR
DS-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/rfc9
276" 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 there are no names that exist between two domain names within a z
one. Unlike its counterpart NSEC, NSEC3 avoids directly disclosing the bounding
domain name pairs. This document provides guidance on setting NSEC3 parameters b
ased on recent operational deployment experience. This document updates RFC 5155
with guidance 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/rfc7
583" 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 of ev
ents in the rolling of a key in a DNSSEC-secured zone. It presents timelines for
the key rollover and explicitly identifies the relationships between the variou
s parameters affecting the process.</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="7583"/>
<seriesInfo name="DOI" value="10.17487/RFC7583"/>
</reference> </reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.45
09.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.51
55.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.92
76.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.75
83.xml"/>
<!-- [rfced] We were unable to verify the reference information at these locatio
ns, as the sites were timing out. We will try again later. Please let us know
if there are other URLs that should be used.
[GBT-32905-2016] http://www.gmbz.org.cn/upload/2018-07-24/1532401392982079739.pd
f
[GBT-32918.1-2016] http://www.gmbz.org.cn/upload/2018-07-24/1532401673134070738.
pdf
[GBT-32918.2-2016] http://www.gmbz.org.cn/upload/2018-07-24/1532401673138056311.
pdf
-->
<reference anchor="GBT-32918.1-2016" target="http://www.gmbz.org.cn/uplo ad/2018-07-24/1532401673134070738.pdf"> <reference anchor="GBT-32918.1-2016" target="http://www.gmbz.org.cn/uplo ad/2018-07-24/1532401673134070738.pdf">
<front> <front>
<title>Information security technology --- Public key cryptographic algorithm SM2 based on elliptic curves --- Part 1: General</title> <title>Information security technology --- Public key cryptographic algorithm SM2 based on elliptic curves --- Part 1: General</title>
<author> <author>
<organization>Standardization Administration of China</organizatio n> <organization>Standardization Administration of China</organizatio n>
</author> </author>
<date month="March" year="2017"/> <date month="March" year="2017"/>
</front> </front>
<seriesInfo name="GB/T" value="32918.2-2016"/> <seriesInfo name="GB/T" value="32918.2-2016"/>
</reference> </reference>
skipping to change at line 435 skipping to change at line 405
<reference anchor="GBT-32918.2-2016" target="http://www.gmbz.org.cn/uplo ad/2018-07-24/1532401673138056311.pdf"> <reference anchor="GBT-32918.2-2016" target="http://www.gmbz.org.cn/uplo ad/2018-07-24/1532401673138056311.pdf">
<front> <front>
<title>Information security technology --- Public key cryptographic algorithm SM2 based on elliptic curves --- Part 2: Digital signature algorithm</ title> <title>Information security technology --- Public key cryptographic algorithm SM2 based on elliptic curves --- Part 2: Digital signature algorithm</ title>
<author> <author>
<organization>Standardization Administration of China</organizatio n> <organization>Standardization Administration of China</organizatio n>
</author> </author>
<date month="March" year="2017"/> <date month="March" year="2017"/>
</front> </front>
<seriesInfo name="GB/T" value="32918.2-2016"/> <seriesInfo name="GB/T" value="32918.2-2016"/>
</reference> </reference>
<reference anchor="ISO-IEC14888-3_2018"> <reference anchor="ISO-IEC14888-3_2018">
<front> <front>
<title>IT Security techniques -- Digital signatures with appendix -- Part 3: Discrete logarithm based mechanisms</title> <title>IT Security techniques -- Digital signatures with appendix -- Part 3: Discrete logarithm based mechanisms</title>
<author> <author>
<organization>International Organization for Standardization</orga nization> <organization>ISO/IEC</organization>
</author> </author>
<date month="November" year="2018"/> <date month="November" year="2018"/>
</front> </front>
<seriesInfo name="ISO/IEC" value="14888-3:2018"/> <seriesInfo name="ISO/IEC" value="14888-3:2018"/>
</reference> </reference>
<reference anchor="GBT-32905-2016" target="http://www.gmbz.org.cn/upload /2018-07-24/1532401392982079739.pdf"> <reference anchor="GBT-32905-2016" target="http://www.gmbz.org.cn/upload /2018-07-24/1532401392982079739.pdf">
<front> <front>
<title>Information security technology --- SM3 cryptographic hash al gorithm</title> <title>Information security technology --- SM3 cryptographic hash al gorithm</title>
<author> <author>
<organization>Standardization Administration of China</organizatio n> <organization>Standardization Administration of China</organizatio n>
</author> </author>
<date month="March" year="2017"/> <date month="March" year="2017"/>
</front> </front>
<seriesInfo name="GB/T" value="32905-2016"/> <seriesInfo name="GB/T" value="32905-2016"/>
</reference> </reference>
skipping to change at line 455 skipping to change at line 427
<reference anchor="GBT-32905-2016" target="http://www.gmbz.org.cn/upload /2018-07-24/1532401392982079739.pdf"> <reference anchor="GBT-32905-2016" target="http://www.gmbz.org.cn/upload /2018-07-24/1532401392982079739.pdf">
<front> <front>
<title>Information security technology --- SM3 cryptographic hash al gorithm</title> <title>Information security technology --- SM3 cryptographic hash al gorithm</title>
<author> <author>
<organization>Standardization Administration of China</organizatio n> <organization>Standardization Administration of China</organizatio n>
</author> </author>
<date month="March" year="2017"/> <date month="March" year="2017"/>
</front> </front>
<seriesInfo name="GB/T" value="32905-2016"/> <seriesInfo name="GB/T" value="32905-2016"/>
</reference> </reference>
<reference anchor="ISO-IEC10118-3_2018"> <reference anchor="ISO-IEC10118-3_2018">
<front> <front>
<title>IT Security techniques -- Hash-functions -- Part 3: Dedicated hash-functions</title> <title>IT Security techniques -- Hash-functions -- Part 3: Dedicated hash-functions</title>
<author> <author>
<organization>International Organization for Standardization</orga nization> <organization>ISO/IEC</organization>
</author> </author>
<date month="October" year="2018"/> <date month="October" year="2018"/>
</front> </front>
<seriesInfo name="ISO/IEC" value="10118-3:2018"/> <seriesInfo name="ISO/IEC" value="10118-3:2018"/>
</reference> </reference>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="Example_Program" target="https://github.com/scooct/dn ssec_sm2sm3"> <reference anchor="Example_Program" target="https://github.com/scooct/dn ssec_sm2sm3">
<front> <front>
<title>Sign and Validate DNSSEC Signature with SM2SM3 Algorithm</tit <title>sign and validate dnssec signature with sm2sm3 algorithm</tit
le> le>
<author initials="C." surname="Zhang" fullname="C. Zhang"> <author/>
</author>
<date month="April" year="2023"/> <date month="April" year="2023"/>
</front> </front>
<seriesInfo name="SM2SM3" value="DNSSEC Example Program"/> <refcontent>commit 6f98c17 </refcontent>
</reference> </reference>
</references> </references>
</references> </references>
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->
</back> </back>
</rfc> </rfc>
 End of changes. 58 change blocks. 
301 lines changed or deleted 259 lines changed or added

This html diff was produced by rfcdiff 1.48.