SM2 Digital Signature Algorithm for DNSSEC

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:

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. 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.