idnits 2.17.1 draft-cuiling-dnsop-sm2-alg-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 281 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 22 instances of too long lines in the document, the longest one being 5 characters in excess of 72. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? -- The draft header indicates that this document updates RFC8624, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 102 has weird spacing: '... P is a sim...' -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Workgroup: Network Working Group C. Zhang 2 Internet-Draft: draft-cuiling-dnsop-sm2-alg-00 Y. Liu 3 Updates: 8624 (if approved) F. Leng 4 Published: 2022-04-07 Q. Zhao 5 Intended Status: Informational Z. He 6 Expires: 2022-10-07 CNNIC 8 SM2 Digital Signature Algorithm for DNSSEC 10 Abstract 12 This document describes how to specify SM2 Digital Signature 13 Algorithm keys and signatures in DNS Security (DNSSEC). It lists 14 the curve and uses SM3 as hash algorithm for signatures. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference material 29 or to cite them other than as "work in progress." 31 This Internet-Draft will expire on xx xxx 2022. 33 Copyright Notice 35 Copyright (c) 2022 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Revised BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Revised BSD License. 48 1. Introduction 50 DNSSEC is broadly defined in RFCs 4033, 4034, and 4035 ([RFC4033], 51 [RFC4034], and [RFC4035]). It uses cryptographic keys and digital 52 signatures to provide authentication of DNS data. Currently, there 53 are several signature algorithms, such as RSA with SHA-256,ECDSA 54 with curve P-256 and SHA-256, etc. 56 This document defines the DNSKEY and RRSIG resource records (RRs) 57 of a new signing algorithms: SM2 uses elliptic curves over 256-bit 58 prime fields with SM3 hash algorithm. (A description of SM2 and SM3 59 can be found in ISO/IEC 10118-3:2018 [ISO/IEC10118-3:2018] and 60 ISO/IEC 14888-3:2018 [ISO/IEC14888-3:2018].) This document also 61 defines the DS RR for the SM3 one-way hash algorithm. In the signing 62 algorithm defined in this document, the size of the key for the 63 elliptic curve is matched with the size of the output of the hash 64 algorithm. Both are 256 bits. 66 Like all ECC-based algorithms, signing with SM2 is significantly 67 faster than RSA based algorithms, while the validating is slower. 69 Due to the similarity between SM2 and ECDSA with curve P-256, some 70 of the material in this document is copied liberally from RFC 6605 71 [RFC6605]. 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in RFC 2119 [RFC2119]. 77 2. SM3 DS Records 79 SM3 is included in ISO/IEC 10118-3:2018 and is similar to SHA-256 80 in many ways. The implementation of SM3 in DNSSEC follows the 81 implementation of SHA-256 as specified in RFC 4509[RFC4509] except 82 that the underlying algorithm is SM3, the digest value is 32 bytes 83 long, and the digest type code is 17 [to be determined]. 85 3. SM2 Parameters 87 Verifying SM2 signatures requires agreement between the signer and 88 the verifier of the parameters used. SM2 digital signature algorithm 89 has been added to ISO/IEC 14888-3:2018. And the parameters of the 90 curve used in this document are as follows: 92 p = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 00000000 FFFFFFFF FFFFFFFF 93 a = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 00000000 FFFFFFFF FFFFFFFC 94 b = 28E9FA9E 9D9F5E34 4D5A9E4B CF6509A7 F39789F5 15AB8F92 DDBCBD41 4D940E93 95 xG = 32C4AE2C 1F198119 5F990446 6A39C994 8FE30BBF F2660BE1 715A4589 334C74C7 96 yG = BC3736A2 F4F6779C 59BDCEE3 6B692153 D0A9877C C62A4740 02DF32E5 2139F0A0 97 n = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF 7203DF6B 21C6052B 53BBF409 39D54123 99 4. DNSKEY and RRSIG Resource Records for SM2 101 SM2 public keys consist of a single value, called "P". In DNSSEC keys, 102 P is a simple bit string that represents the uncompressed form of a 103 curve point, "x | y". 105 The SM2 signature is the combination of two non-negative integers, 106 called "r" and "s". The two integers, each of which is formatted as 107 a simple octet string, are combined into a single longer octet string 108 for DNSSEC as the concatenation "r | s". (Conversion of the integers 109 to bit strings is the same as ECDSA signature.) Each integer MUST be 110 encoded as 32 octets. 112 Although SM2 uses elliptic curves, the process of digest and signature 113 generation is different from ECDSA. 115 The algorithm number associated with the DNSKEY and RRSIG resource records 116 is fully defined in the IANA Considerations section. It is: 118 DNSKEY and RRSIG RRs signifying SM2 with SM3 use the algorithm number 17 119 [to be determined]. 121 Conformant implementations that create records to be put into the DNS MAY 122 implement signing and verification for the above algorithm. Conformant 123 DNSSEC verifiers MAY implement verification for the above algorithm. 125 5. Support for NSEC3 Denial of Existence 127 This document does not define algorithm aliases mentioned in RFC 5155 128 [RFC5155]. 130 A DNSSEC validator that implements the signing algorithms defined in this 131 document MUST be able to validate negative answers in the form of both NSEC 132 and NSEC3 with hash algorithm 1, as defined in RFC 5155. An authoritative 133 server that does not implement NSEC3 MAY still serve zones that use the 134 signing algorithms defined in this document with NSEC denial of existence. 136 6. Example 138 The following is an example of SM2 keys and signatures in DNS format. 140 6.1. SM2 Example 142 Private-key-format: v1.3 143 Algorithm: 17[to be determined] (SM2SM3) 144 PrivateKey: V24tjJgXxp2ykscKRZdT+iuR5J1xRQN+FKoQACmo9fA= 146 example.net. 3600 IN DNSKEY 257 3 17 ( 147 jZbZMBImG9dtGWSVEwnv2l32OVKcX7MMJv+83/+A41ia 148 ZuO0ajXMcuyJbTr8Ud+kae6UlfqrnsG6tgADIPHxXA== ) 150 example.net. 3600 IN DS 27215 17 6 ( 151 86671f82dd872e4ee73647a95dff7fd0af599ff8a43f 152 fa26c9a2593091653c0e ) 154 www.example.net. 3600 IN A 192.0.2.1 155 www.example.net. 3600 IN RRSIG A 17 6 3600 ( 156 20220428075649 20220331075649 27215 example.net. 157 tz295lkfu2InRnLdLhKWDm354I6ZGSmYeOSDswKiQMU7 158 /Va0QrH7bD7ZnHB4wWsEjfy1XscwM4P86sVxkMJE7w== ) 160 7. IANA Considerations 162 This document updates the IANA registry for digest types in DS records, 163 currently called "Delegation Signer (DS) Resource Record (RR) Type Digest 164 Algorithms". The following entry has been added: 166 Value 6 [to be determined] 167 Digest Type SM3 168 Status OPTIONAL 170 This document updates the IANA registry "Domain Name System Security 171 (DNSSEC) Algorithm Numbers". The following two entries have been added 172 to the registry: 174 Number 17 175 Description SM2 signing algorithm with SM3 hashing algorithm 176 Mnemonic SM2SM3 177 Zone Signing Y 178 Trans. Sec. * 179 Reference This document 181 * There has been no determination of standardization of the use of this 182 algorithm with Transaction Security. 184 8. Security Considerations 186 The cryptographic work factor of SM2 is generally considered to be 187 equivalent to half the size of the key, which is 128 bits. Such an 188 assessment could, of course, change in the future if new attacks that 189 work better than the ones known today are found. 191 SM2 digital signature algorithm has come into use for less than a score 192 of years. So SM2SM3 algorithm is mainly used for research and experiment 193 purpose currently. 195 The security considerations listed in RFC 4509 apply here as well. 197 9. Normative References 199 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 200 Requirement Levels", BCP 14, RFC 2119, March 1997. 202 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 203 Rose, "DNS Security Introduction and Requirements", 204 RFC 4033, March 2005. 206 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 207 Rose, "Resource Records for the DNS Security 208 Extensions", RFC 4034, March 2005. 210 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 211 Rose, "Protocol Modifications for the DNS Security 212 Extensions", RFC 4035, March 2005. 214 [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation 215 Signer (DS) Resource Records (RRs)", RFC 4509, 216 May 2006. 218 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 219 Security (DNSSEC) Hashed Authenticated Denial of 220 Existence", RFC 5155, March 2008. 222 [RFC6605] Hoffman, P., and Wouter C.A. Wijngaards, "Elliptic Curve 223 Digital Signature Algorithm (DSA) for DNSSEC", RFC 6605, 224 April 2012. 226 [ISO/IEC14888-3:2018] International Organization for Standardization, 227 "IT Security techniques -- Digital signatures with appendix 228 -- Part 3: Discrete logarithm based mechanisms", ISO ISO/IEC 229 14888-3:2018, November 2018. 231 [ISO/IEC10118-3:2018] International Organization for Standardization, 232 "IT Security techniques -- Hash-functions -- Part 3: Dedicated 233 hash-functions", ISO ISO/IEC 10118-3:2018, October 2018. 235 Authors' Addresses 237 Cuiling Zhang 238 CNNIC 239 No.4 South 4th Street, Zhongguancun 240 Beijing, 100190 241 China 243 Email: zhangcuiling@cnnic.cn 245 Yukun Liu 246 CNNIC 247 No.4 South 4th Street, Zhongguancun 248 Beijing, 100190 249 China 251 Email: liuyukun@cnnic.cn 253 Feng Leng 254 CNNIC 255 No.4 South 4th Street, Zhongguancun 256 Beijing, 100190 257 China 259 Email: lengfeng@cnnic.cn 261 Qi Zhao 262 CNNIC 263 No.4 South 4th Street, Zhongguancun 264 Beijing, 100190 265 China 267 Email: zhaoqi@cnnic.cn 269 Zheng He 270 CNNIC 271 No.4 South 4th Street, Zhongguancun 272 Beijing, 100190 273 China 275 Email: hezh@cnnic.cn