SM2 Digital Signature Algorithm for DNSSEC CNNIC
No.4 South 4th Street, Zhongguancun Beijing 100190 China zhangcuiling@cnnic.cn
CNNIC
No.4 South 4th Street, Zhongguancun Beijing 100190 China liuyukun@cnnic.cn
CNNIC
No.4 South 4th Street, Zhongguancun Beijing 100190 China lengfeng@cnnic.cn
CNNIC
No.4 South 4th Street, Zhongguancun Beijing 100190 China zhaoqi@cnnic.cn
CNNIC
No.4 South 4th Street, Zhongguancun Beijing 100190 China hezh@cnnic.cn
This document specifies the use of the SM2 digital signature algorithm and SM3 hash algorithm for DNS Security (DNSSEC). This document is an Independent Submission to the RFC series and does not have consensus of the IETF community.
Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for 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. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .
Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents () in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
Table of Contents
  • .  Introduction
  • .  SM3 DS Records
  • .  SM2 Parameters
  • .  DNSKEY and RRSIG Resource Records for SM2
    • .  DNSKEY Resource Records
    • .  RRSIG Resource Records
  • .  Support for NSEC3 Denial of Existence
  • .  Example
  • .  IANA Considerations
  • .  Security Considerations
  • .  References
    • .  Normative References
    • .  Informative References
  • Authors' Addresses
Introduction DNSSEC is broadly defined in , , and . It uses cryptographic keys and digital signatures to provide authentication of DNS data. DNSSEC signature algorithms are registered in the DNSSEC algorithm numbers registry . 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 can be found in GM/T 0003.2-2012 or ISO/IEC14888-3:2018 , and a description of SM3 can be found in GM/T 0004-2012 or ISO/IEC10118-3:2018 .) 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. Many implementations may not support SM2 signatures and SM3 digests. specifies handling of answers in such cases. 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 and ISO/IEC 10118:3-2018 ). 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. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.
SM3 DS Records The implementation of SM3 in DNSSEC follows the implementation of SHA-256 as specified in except that the underlying algorithm is SM3 with digest type code 6. The generation of an SM3 hash value is described in Section 5 of and generates a 256-bit hash value.
SM2 Parameters Verifying SM2 signatures requires agreement between the signer and the verifier on the parameters used. The SM2 digital signature algorithm has been added to . The parameters of the curve used in this profile are as follows: 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
DNSKEY and RRSIG Resource Records for SM2
DNSKEY Resource Records SM2 public keys consist of a single value, called "P". In DNSSEC keys, P is a string of 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 .)
RRSIG Resource Records 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 .) Each integer MUST be encoded as 32 octets. Process details are described in Section 6 of . The algorithm number associated with the DNSKEY and RRSIG resource records is 17, which is described in the IANA Considerations section. Conformant implementations that create records to be put into the DNS MAY implement signing and verification for the SM2 digital signature algorithm. Conformant DNSSEC verifiers MAY implement verification for the above algorithm.
Support for NSEC3 Denial of Existence This document does not define algorithm aliases mentioned in . 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 and NSEC3 with hash algorithm SHA-1, as defined in . An authoritative server that does not implement NSEC3 MAY still serve zones that use the signing algorithms defined in this document with NSEC denial of existence. If using NSEC3, the iterations MUST be 0 and salt MUST be an empty string as recommended in .
Example 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, and DS RR. Private-key-format: v1.3 Algorithm: 17 (SM2SM3) PrivateKey: V24tjJgXxp2ykscKRZdT+iuR5J1xRQN+FKoQACmo9fA= example. 3600 IN DS 27215 17 6 ( 86671f82dd872e4ee73647a95dff7fd0af599ff8a43f fa26c9a2593091653c0e ) example. 3600 IN DNSKEY 256 3 17 ( 7EQ32PTAp+1ac6R9Ze2nfB8pPc2OJqkHSjug ALr4SuD9awuQxhfw7wMpiXv7JK4/VwwTrCxJ wu+qUuDsgoBK4w== ) ; ZSK; alg = SM2SM3 ; key id = 65042 example. 3600 IN RRSIG DNSKEY 17 1 3600 ( 20230901000000 20220901000000 65042 example. lF2eq49e62Nn4aT5x8ZI6PdRSTPHPDixZdyl lM6GWu4lkRWkpTgWLE4lQK/+qHdNS4DdTd36 Jsuu0FSO5k48Qg== ) example. 0 IN NSEC3PARAM 1 0 10 AABBCCDD example. 0 IN RRSIG NSEC3PARAM 17 1 0 ( 20230901000000 20220901000000 65042 example. 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== ) is an example program based on dnspython and gmssl, which supplies key generating, zone signing, zone validating, and DS RR generating functions for convenience.
IANA Considerations IANA has registered the following in the "Digest Algorithms" registry within the "DNSSEC Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms" registry group.
Value Digest Type Status Reference
6 SM3 OPTIONAL This document
IANA has registered the following in the "DNS Security Algorithm Numbers" registry within the "Domain Name System Security (DNSSEC) Algorithm Numbers" registry group.
Number Description Mnemonic Zone Signing Trans. Sec. Reference
17 SM2 signing algorithm with SM3 hashing algorithm SM2SM3 Y * This document
* There has been no determination of standardization of the use of this algorithm with Transaction Security.
Security Considerations The security strength of SM2 depends on the size of the key. A longer key provides stronger security strength. The security of ECC-based algorithms is influenced by the curve it uses, too. 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 be taken in this situation to permit appropriate rollovers, taking into account record caching. See for details. A suitable replacement algorithm should be both widely implemented and not known to have weaknesses. The security considerations listed in apply here as well.
References Normative References SM2 Public Key Cryptographic Algorithms Based on Elliptic Curves Part 1: General Cryptography Standardization Technical Committee of China [In Chinese] English translation available at: SM2 Public Key Cryptographic Algorithms Based on Elliptic Curves Part 2: Digital Signature Algorithm Cryptography Standardization Technical Committee of China [In Chinese] English translation available at: SM3 Cryptographic Hash Algorithm Cryptography Standardization Technical Committee of China [In Chinese] English translation available at: . DNS Security Algorithm Numbers IANA IT Security techniques -- Hash-functions -- Part 3: Dedicated hash-functions ISO/IEC IT Security techniques -- Digital signatures with appendix -- Part 3: Discrete logarithm based mechanisms ISO/IEC Key words for use in RFCs to Indicate Requirement Levels 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. DNS Security Introduction and Requirements 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] Resource Records for the DNS Security Extensions This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines 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 is given. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK] Protocol Modifications for the DNS Security Extensions This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications that add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with 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. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK] Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs) This document specifies how to use 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] DNS Security (DNSSEC) Hashed Authenticated Denial of Existence The Domain Name System Security (DNSSEC) Extensions introduced the NSEC resource record (RR) for authenticated denial of existence. This document introduces an 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] Clarifications and Implementation Notes for DNS Security (DNSSEC) This document is a collection of technical clarifications to the DNS Security (DNSSEC) document set. It is meant to serve as a resource to implementors as well as a collection of DNSSEC errata that existed at the time of writing. This document updates the core DNSSEC documents (RFC 4033, RFC 4034, and RFC 4035) as well as the NSEC3 specification (RFC 5155). It also defines NSEC3 and SHA-2 (RFC 4509 and RFC 5702) as core parts of the DNSSEC specification. DNSSEC Key Rollover Timing Considerations This document describes the issues surrounding the timing of events 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 various parameters affecting the process. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Guidance for NSEC3 Parameter Settings NSEC3 is a DNSSEC mechanism providing proof of nonexistence by asserting that 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 about selecting NSEC3 iteration and salt parameters. Informative References sign and validate dnssec signature with sm2sm3 algorithm commit 6f98c17
Authors' Addresses CNNIC
No.4 South 4th Street, Zhongguancun Beijing 100190 China zhangcuiling@cnnic.cn
CNNIC
No.4 South 4th Street, Zhongguancun Beijing 100190 China liuyukun@cnnic.cn
CNNIC
No.4 South 4th Street, Zhongguancun Beijing 100190 China lengfeng@cnnic.cn
CNNIC
No.4 South 4th Street, Zhongguancun Beijing 100190 China zhaoqi@cnnic.cn
CNNIC
No.4 South 4th Street, Zhongguancun Beijing 100190 China hezh@cnnic.cn