rfc9563.original		rfc9563.txt
	Network Working Group C. Zhang		Independent Submission C. Zhang
	Internet-Draft Y. Liu		Request for Comments: 9563 Y. Liu
	Intended status: Informational F. Leng		Category: Informational F. Leng
	Expires: 21 July 2024 Q. Zhao		ISSN: 2070-1721 Q. Zhao
	Z. He		Z. He
	CNNIC		CNNIC
	18 January 2024		April 2024
	SM2 Digital Signature Algorithm for DNSSEC		SM2 Digital Signature Algorithm for NSSEC
	draft-cuiling-dnsop-sm2-alg-15
	Abstract		Abstract
	This document specifies the use of the SM2 digital signature		This document specifies the use of the SM2 digital signature
	algorithm and SM3 hash algorithm for DNS Security (DNSSEC).		algorithm and SM3 hash algorithm for DNS Security (DNSSEC).
	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.		not have consensus of the IETF community.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This document is not an Internet Standards Track specification; it is
	provisions of BCP 78 and BCP 79.		published for informational purposes.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		This is a contribution to the RFC Series, independently of any other
	and may be updated, replaced, or obsoleted by other documents at any		RFC stream. The RFC Editor has chosen to publish this document at
	time. It is inappropriate to use Internet-Drafts as reference		its discretion and makes no statement about its value for
	material or to cite them other than as "work in progress."		implementation or deployment. Documents approved for publication by
			the RFC Editor are not candidates for any level of Internet Standard;
			see Section 2 of RFC 7841.
	This Internet-Draft will expire on 21 July 2024.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			https://www.rfc-editor.org/info/rfc9563.
	Copyright Notice		Copyright Notice
	Copyright (c) 2024 IETF Trust and the persons identified as the		Copyright (c) 2024 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents
	license-info) in effect on the date of publication of this document.		(https://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights		publication of this document. Please review these documents
	and restrictions with respect to this document. Code Components		carefully, as they describe your rights and restrictions with respect
	extracted from this document must include Revised BSD License text as		to this document.
	described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction
	2. SM3 DS Records . . . . . . . . . . . . . . . . . . . . . . . 3		2. SM3 DS Records
	3. SM2 Parameters . . . . . . . . . . . . . . . . . . . . . . . 3		3. SM2 Parameters
	4. DNSKEY and RRSIG Resource Records for SM2 . . . . . . . . . . 3		4. DNSKEY and RRSIG Resource Records for SM2
	4.1. DNSKEY Resource Records . . . . . . . . . . . . . . . . . 3		4.1. DNSKEY Resource Records
	4.2. RRSIG Resource Records . . . . . . . . . . . . . . . . . 3		4.2. RRSIG Resource Records
	5. Support for NSEC3 Denial of Existence . . . . . . . . . . . . 4		5. Support for NSEC3 Denial of Existence
	6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 4		6. Example
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5		7. IANA Considerations
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 6		8. Security Considerations
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6		9. References
	9.1. Normative References . . . . . . . . . . . . . . . . . . 6		9.1. Normative References
	9.2. Informative References . . . . . . . . . . . . . . . . . 8		9.2. Informative References
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8		Authors' Addresses
	1. Introduction		1. Introduction
	DNSSEC is broadly defined in [RFC4033], [RFC4034], and [RFC4035]. It		DNSSEC is broadly defined in [RFC4033], [RFC4034], and [RFC4035]. It
	uses cryptographic keys and digital signatures to provide		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 [IANA].		registered in the DNSSEC algorithm numbers registry [IANA].
	This document defines the DNSKEY and RRSIG resource records (RRs) of		This document defines the DNSKEY and RRSIG resource records (RRs) of
	new signing algorithms: SM2 uses elliptic curves over 256-bit prime		new signing algorithms: SM2 uses elliptic curves over 256-bit prime
	fields with SM3 hash algorithm. (A description of SM2 and SM3 can be		fields with SM3 hash algorithm. (A description of SM2 can be found
	found in GB/T 32918.2-2016 [GBT-32918.2-2016] or ISO/IEC14888-3:2018		in GB/T 32918.2-2016 [GBT-32918.2-2016] or ISO/IEC14888-3:2018
	[ISO-IEC14888-3_2018], and GB/T 32905-2016 [GBT-32905-2016] or ISO/		[ISO-IEC14888-3_2018], and a description of SM3 can be found in GB/T
	IEC10118-3:2018 [ISO-IEC10118-3_2018].) This document also defines		32905-2016 [GBT-32905-2016] or ISO/IEC10118-3:2018
	the DS RR for the SM3 one-way hash algorithm. In the signing		[ISO-IEC10118-3_2018].) This document also defines the DS RR for the
	algorithm defined in this document, the size of the key for the		SM3 one-way hash algorithm. In the signing algorithm defined in this
	elliptic curve is matched with the size of the output of the hash		document, the size of the key for the elliptic curve is matched with
	algorithm. Both are 256 bits.		the size of the output of the hash algorithm. Both are 256 bits.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	document are to be interpreted as described in [RFC2119].		"OPTIONAL" in this document are to be interpreted as described in
			BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
			capitals, as shown here.
	2. SM3 DS Records		2. SM3 DS Records
	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 [RFC4509] except that the underlying		SHA-256 as specified in [RFC4509] except that the underlying
	algorithm is SM3 with digest type code [TBD1, waiting for an IANA's		algorithm is SM3 with digest type code 6.
	code assignment].
	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
	[GBT-32905-2016] and generates 256-bit hash value.		[GBT-32905-2016] and generates a 256-bit hash value.
	3. SM2 Parameters		3. SM2 Parameters
	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
	has been added to ISO/IEC 14888-3:2018. And the parameters of the		algorithm has been added to [ISO-IEC14888-3_2018]. The parameters of
	curve used in this profile are as follows:		the curve used in this profile are as follows:
	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
	4. DNSKEY and RRSIG Resource Records for SM2		4. DNSKEY and RRSIG Resource Records for SM2
	4.1. DNSKEY Resource Records		4.1. DNSKEY Resource Records
	SM2 public keys consist of a single value, called "P". In DNSSEC		SM2 public keys consist of a single value, called "P". In DNSSEC
	keys, P is a string of 32 octets that represents the uncompressed		keys, 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		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		string is described in Section 4.2.8 of [GBT-32918.1-2016].)
	[GBT-32918.1-2016].)
	4.2. RRSIG Resource Records		4.2. RRSIG Resource Records
	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 [GBT-32918.1-2016].)		to bit strings is described in Section 4.2.1 of [GBT-32918.1-2016].)
	Each integer MUST be encoded as 32 octets.		Each integer MUST be encoded as 32 octets.
	Process details are described in Section 6 "Digital signature		Process details are described in Section 6 of [GBT-32918.2-2016].
	generation algorithm and its process" in [GBT-32918.2-2016].
	The algorithm number associated with the DNSKEY and RRSIG resource		The algorithm number associated with the DNSKEY and RRSIG resource
	records is [TBD2, waiting for an IANA’s code assignment], which is		records is 17, which is described in the IANA Considerations section.
	described in the IANA Considerations section.
	Conformant implementations that create records to be put into the DNS		Conformant implementations that create records to be put into the DNS
	MAY implement signing and verification for the above algorithm.		MAY implement signing and verification for the above algorithm.
	Conformant DNSSEC verifiers MAY implement verification for the above		Conformant DNSSEC verifiers MAY implement verification for the above
	algorithm.		algorithm.
	5. Support for NSEC3 Denial of Existence		5. Support for NSEC3 Denial of Existence
	This document does not define algorithm aliases mentioned in		This document does not define algorithm aliases mentioned in
	[RFC5155].		[RFC5155].
	skipping to change at page 4, line 33 ¶		skipping to change at line 159 ¶
	still serve zones that use the signing algorithms defined in this		still serve zones that use the signing algorithms defined in this
	document with NSEC denial of existence.		document with NSEC denial of existence.
	If using NSEC3, the iterations MUST be 0 and salt MUST be an empty		If using NSEC3, the iterations MUST be 0 and salt MUST be an empty
	string as recommended in Section 3.1 of [RFC9276].		string as recommended in Section 3.1 of [RFC9276].
	6. Example		6. Example
	The following is an example of SM2 keys and signatures in DNS zone		The following is an example of SM2 keys and signatures in DNS zone
	file format, including DNSKEY RR, NSEC3PARAM RR, NSEC3 RR with RRSIG		file format, including DNSKEY RR, NSEC3PARAM RR, NSEC3 RR with RRSIG
	RRs and DS RR.		RRs, and DS RR.
	Private-key-format: v1.3		Private-key-format: v1.3
	Algorithm: [TBD2] (SM2SM3)		Algorithm: 17 (SM2SM3)
	PrivateKey: V24tjJgXxp2ykscKRZdT+iuR5J1xRQN+FKoQACmo9fA=		PrivateKey: V24tjJgXxp2ykscKRZdT+iuR5J1xRQN+FKoQACmo9fA=
	example. 3600 IN DS 27215 TBD2 TBD1 (		example. 3600 IN DS 27215 17 6 (
	86671f82dd872e4ee73647a95dff7fd0af599ff8a43f fa26c9a2593091653c0e		86671f82dd872e4ee73647a95dff7fd0af599ff8a43f fa26c9a2593091653c0e
	)		)
	example. 3600 IN DNSKEY 256 3 TBD2 (		example. 3600 IN DNSKEY 256 3 17 (
	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		62KP1QB93KRGR6LM7SEVPJVNG90BLUE8.example. 3600 IN NSEC3 1 1 10
	AABBCCDD (		AABBCCDD (
	GTGVQIILTSSJ8FFO9J6DC8PRTFAEA8G2 NS SOA RRSIG DNSKEY NSEC3PARAM )		GTGVQIILTSSJ8FFO9J6DC8PRTFAEA8G2 NS SOA RRSIG DNSKEY NSEC3PARAM )
	62KP1QB93KRGR6LM7SEVPJVNG90BLUE8.example. 3600 IN RRSIG NSEC3 TBD2 2		62KP1QB93KRGR6LM7SEVPJVNG90BLUE8.example. 3600 IN RRSIG NSEC3 17 2
	3600 (		3600 (
	20230901000000 20220901000000 65042 example.		20230901000000 20220901000000 65042 example.
	FOWLegTgFkFY9vCOo4kHwjEvZ+IL1NMl4s9V		FOWLegTgFkFY9vCOo4kHwjEvZ+IL1NMl4s9V
	hVyPOwokd5uOLKeXTP19HIeEtW73WcJ9XNe/ ie/knp7Edo/hxw== )		hVyPOwokd5uOLKeXTP19HIeEtW73WcJ9XNe/ ie/knp7Edo/hxw== )
	Here is an example program [Example_Program] based on dnspython and		[Example_Program] is an example program based on dnspython and gmssl,
	gmssl, which supplies key generating, zone signing, zone validating		which supplies key generating, zone signing, zone validating, and DS
	and DS RR generating functions for convenience.		RR generating functions for convenience.
	7. IANA Considerations		7. IANA Considerations
	This document will update the IANA registry for digest types in DS		IANA has registered the following in the "Digest Algorithms" registry
	records, currently called "Digest Algorithms," in the "Delegation		within the "DNSSEC Delegation Signer (DS) Resource Record (RR) Type
	Signer (DS) Resource Record (RR) Type Digest Algorithms" registry		Digest Algorithms" registry group.
	group.
	Value TBD1		+=======+=============+==========+===============+
	Digest Type SM3		| Value | Digest Type | Status | Reference |
	Status OPTIONAL		+=======+=============+==========+===============+
	Reference This document		| 6 | SM3 | OPTIONAL | This document |
			+-------+-------------+----------+---------------+
	This document will update the IANA registry "Domain Name System		Table 1
	Security (DNSSEC) Algorithm Numbers".
	Number TBD2		IANA has registered the following in the "DNS Security Algorithm
	Description SM2 signing algorithm with SM3 hashing algorithm		Numbers" registry within the "Domain Name System Security (DNSSEC)
	Mnemonic SM2SM3		Algorithm Numbers" registry group.
	Zone Signing Y
	Trans. Sec. *		+========+================+==========+=========+========+===========+
	Reference This document		| Number | Description | Mnemonic | Zone | Trans. | Reference |
			| | | | Signing | Sec. | |
			+========+================+==========+=========+========+===========+
			| 17 | SM2 signing | SM2SM3 | Y | * | This |
			| | algorithm | | | | document |
			| | with SM3 | | | | |
			| | hashing | | | | |
			| | algorithm | | | | |
			+--------+----------------+----------+---------+--------+-----------+
			Table 2
	* There has been no determination of standardization of the use of		* There has been no determination of standardization of the use of
	this algorithm with Transaction Security.		this algorithm with Transaction Security.
	8. Security Considerations		8. Security Considerations
	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
	key provides stronger security strength. The security of ECC-based		longer key provides stronger security strength. The security of ECC-
	algorithms is influenced by the curve it uses, too.		based algorithms is influenced by the curve it uses, too.
	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 found in either SM2 or SM3. In this case, the proper remediation
	is crypto-agility. In the case of DNSSEC, the appropriate approach		is crypto-agility. In the case of DNSSEC, the appropriate approach
	would be to regenerate appropriate DS, DNSKEY, RRSIG, and NSEC3		would be to regenerate appropriate DS, DNSKEY, RRSIG, and NSEC3
	records. Care MUST be taken in this situation to permit appropriate		records. Care MUST be taken in this situation to permit appropriate
	rollovers, taking into account record caching. See [RFC7583] for		rollovers, taking into account record caching. See [RFC7583] for
	details. Choice of a suitable replacement algorithm should be one		details. A suitable replacement algorithm should be both widely
	that is both widely implemented and not known to have weaknesses.		implemented and not known to have weaknesses.
	The security considerations listed in [RFC4509] apply here as well.		The security considerations listed in [RFC4509] apply here as well.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
			[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
			2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
			May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.		[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	Rose, "DNS Security Introduction and Requirements",		Rose, "DNS Security Introduction and Requirements",
	RFC 4033, DOI 10.17487/RFC4033, March 2005,		RFC 4033, DOI 10.17487/RFC4033, March 2005,
	<https://www.rfc-editor.org/info/rfc4033>.		<https://www.rfc-editor.org/info/rfc4033>.
	[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.		[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	Rose, "Resource Records for the DNS Security Extensions",		Rose, "Resource Records for the DNS Security Extensions",
	RFC 4034, DOI 10.17487/RFC4034, March 2005,		RFC 4034, DOI 10.17487/RFC4034, March 2005,
	<https://www.rfc-editor.org/info/rfc4034>.		<https://www.rfc-editor.org/info/rfc4034>.
	[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.		[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	Rose, "Protocol Modifications for the DNS Security		Rose, "Protocol Modifications for the DNS Security
	Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,		Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
	<https://www.rfc-editor.org/info/rfc4035>.		<https://www.rfc-editor.org/info/rfc4035>.
	[IANA] IANA, "Domain Name System Security (DNSSEC) Algorithm		[IANA] IANA, "DNS Security Algorithm Numbers",
	Numbers", Registered DNSSEC Algorithm Numbers, April 2020,		<https://www.iana.org/assignments/dns-sec-alg-numbers>.
	<https://www.iana.org/assignments/dns-sec-alg-numbers/dns-
	sec-alg-numbers.xhtml>.
	[RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer		[RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
	(DS) Resource Records (RRs)", RFC 4509,		(DS) Resource Records (RRs)", RFC 4509,
	DOI 10.17487/RFC4509, May 2006,		DOI 10.17487/RFC4509, May 2006,
	<https://www.rfc-editor.org/info/rfc4509>.		<https://www.rfc-editor.org/info/rfc4509>.
	[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS		[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
	Security (DNSSEC) Hashed Authenticated Denial of		Security (DNSSEC) Hashed Authenticated Denial of
	Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,		Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
	<https://www.rfc-editor.org/info/rfc5155>.		<https://www.rfc-editor.org/info/rfc5155>.
	skipping to change at page 8, line 6 ¶		skipping to change at line 319 ¶
	[GBT-32918.2-2016]		[GBT-32918.2-2016]
	Standardization Administration of China, "Information		Standardization Administration of China, "Information
	security technology --- Public key cryptographic algorithm		security technology --- Public key cryptographic algorithm
	SM2 based on elliptic curves --- Part 2: Digital signature		SM2 based on elliptic curves --- Part 2: Digital signature
	algorithm", GB/T 32918.2-2016, March 2017,		algorithm", GB/T 32918.2-2016, March 2017,
	<http://www.gmbz.org.cn/		<http://www.gmbz.org.cn/
	upload/2018-07-24/1532401673138056311.pdf>.		upload/2018-07-24/1532401673138056311.pdf>.
	[ISO-IEC14888-3_2018]		[ISO-IEC14888-3_2018]
	International Organization for Standardization, "IT		ISO/IEC, "IT Security techniques -- Digital signatures
	Security techniques -- Digital signatures with appendix --		with appendix -- Part 3: Discrete logarithm based
	Part 3: Discrete logarithm based mechanisms", ISO/		mechanisms", ISO/IEC 14888-3:2018, November 2018.
	IEC 14888-3:2018, November 2018.
	[GBT-32905-2016]		[GBT-32905-2016]
	Standardization Administration of China, "Information		Standardization Administration of China, "Information
	security technology --- SM3 cryptographic hash algorithm",		security technology --- SM3 cryptographic hash algorithm",
	GB/T 32905-2016, March 2017, <http://www.gmbz.org.cn/		GB/T 32905-2016, March 2017, <http://www.gmbz.org.cn/
	upload/2018-07-24/1532401392982079739.pdf>.		upload/2018-07-24/1532401392982079739.pdf>.
	[ISO-IEC10118-3_2018]		[ISO-IEC10118-3_2018]
	International Organization for Standardization, "IT		ISO/IEC, "IT Security techniques -- Hash-functions -- Part
	Security techniques -- Hash-functions -- Part 3: Dedicated		3: Dedicated hash-functions", ISO/IEC 10118-3:2018,
	hash-functions", ISO/IEC 10118-3:2018, October 2018.		October 2018.
	9.2. Informative References		9.2. Informative References
	[Example_Program]		[Example_Program]
	Zhang, C., "Sign and Validate DNSSEC Signature with SM2SM3		"sign and validate dnssec signature with sm2sm3
	Algorithm", SM2SM3 DNSSEC Example Program, April 2023,		algorithm", commit 6f98c17, April 2023,
	<https://github.com/scooct/dnssec_sm2sm3>.		<https://github.com/scooct/dnssec_sm2sm3>.
	Authors' Addresses		Authors' Addresses
	Cuiling Zhang		Cuiling Zhang
	CNNIC		CNNIC
	No.4 South 4th Street, Zhongguancun		No.4 South 4th Street, Zhongguancun
	Beijing, 100190		Beijing
			100190
	China		China
	Email: zhangcuiling@cnnic.cn		Email: zhangcuiling@cnnic.cn
	Yukun Liu		Yukun Liu
	CNNIC		CNNIC
	No.4 South 4th Street, Zhongguancun		No.4 South 4th Street, Zhongguancun
	Beijing, 100190		Beijing
			100190
	China		China
	Email: liuyukun@cnnic.cn		Email: liuyukun@cnnic.cn
	Feng Leng		Feng Leng
	CNNIC		CNNIC
	No.4 South 4th Street, Zhongguancun		No.4 South 4th Street, Zhongguancun
	Beijing, 100190		Beijing
			100190
	China		China
	Email: lengfeng@cnnic.cn		Email: lengfeng@cnnic.cn
	Qi Zhao		Qi Zhao
	CNNIC		CNNIC
	No.4 South 4th Street, Zhongguancun		No.4 South 4th Street, Zhongguancun
	Beijing, 100190		Beijing
			100190
	China		China
	Email: zhaoqi@cnnic.cn		Email: zhaoqi@cnnic.cn
	Zheng He		Zheng He
	CNNIC		CNNIC
	No.4 South 4th Street, Zhongguancun		No.4 South 4th Street, Zhongguancun
	Beijing, 100190		Beijing
			100190
	China		China
	Email: hezh@cnnic.cn		Email: hezh@cnnic.cn
End of changes. 44 change blocks.
	120 lines changed or deleted		130 lines changed or added
This html diff was produced by rfcdiff 1.48.