idnits 2.17.1 draft-chen-sm2-sm3-algorithms-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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([3], [4], [5], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 356: '...er which the JWT MUST NOT be accepted ...' RFC 2119 keyword, line 359: '... MUST NOT be accepted for processing...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 30, 2020) is 1243 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '2' is defined on line 455, but no explicit reference was found in the text Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Y. Chen 2 Internet Draft J. Wang 3 Intended status: Informational B. Zhang 4 Expires: May 2021 Z. Fan 5 X. Ma 6 Z. Li 7 J. Xie 8 November 30, 2020 9 China Academy of Information and Communications Technology 11 Use of the SM2 and SM3 Algorithms in Handle System 12 draft-chen-sm2-sm3-algorithms-00 14 Status of this Memo 16 This Internet-Draft is submitted in full conformance with the 17 provisions of BCP 78 and BCP 79. This memo provides information for 18 the Internet community. It does not specify an Internet standard of 19 any kind. Distribution of this memo is unlimited. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 This Internet-Draft will expire on May 30, 2021. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with 48 respect to this document. 50 Abstract 52 The Handle System is a global name service that allows secured handle 53 resolution and administration over the public Internet according to 54 [1][5][3]. Handle System protocol [3] is designed to be transmitted 55 as a byte stream via a TCP connection. In this document, SM2 and SM3 56 algorithms [4][5]are introduced into the handle system to enhance the 57 security and compactivity. Trusted resolution and message credential 58 are extended to support SM2 and SM3 algorithms. 60 Table of Contents 62 1. Introduction...................................................2 63 2. SM2 and SM3 Algorithms Overview................................2 64 2.1. SM2 Algorithm.............................................3 65 2.2. SM3 Algorithm.............................................3 66 3. Trusted Resolution with SM2 and SM3 Algorithms.................3 67 3.1. HS_CERT Extension.........................................3 68 3.1.1. Header using SM2 and SM3.............................4 69 3.1.2. Payload using SM2 and SM3............................4 70 3.1.3. Signatrue of the Header and Payload..................5 71 3.2. HS_SIGNATRUE Extension....................................5 72 3.2.1. Header using SM2 and SM3.............................6 73 3.2.2. Payload using SM2 and SM3............................6 74 3.2.3. Signatrue of the Header and Payload..................8 75 4. Message Credential with SM2 and SM3 Algorithms.................8 76 4.1. Message Credential........................................8 77 4.2. Data Signing with SM2 Algorithm...........................8 78 4.3. SM3 Digest Algorithm in Message Credential................9 79 5. Security Considerations........................................9 80 6. IANA Considerations............................................9 81 7. References.....................................................9 82 7.1. Normative References......................................9 83 8. Acknowledgments...............................................10 85 1. Introduction 87 RFC 3650-RFC 3652[1],[5][3] provide an open protocol, a general- 88 purpose global name service, and a reference implementation of the 89 protocol. RSA and DSA algorithms are commonly used when generating 90 data signatures. With the development of cryptography and computer 91 technology, the currently commonly used 1024-bit RSA algorithm faces 92 security threats. In order to enhance data integrity protection based 93 on digital signature and message verification, SM2 and SM3 algorithms 94 are introduced to the Handle System. 96 2. SM2 and SM3 Algorithms Overview 98 Digital signature means that a signer generates a digital signature 99 on data, and verification are performed to verify the authenticity of 100 the signature. Each signer has a unique pair of public key and 101 private key, where the private key is used to generate the signature, 102 and the verifier uses the signer's public key to verify the signature. 104 Verification of signature can be performed to confirm that the sender 105 holds the corresponding private key through the public key and 106 signature information without revealing the sender's private key. The 107 signature can also bind the sender's identity and information to 108 prevent imitation. 110 Both SM2 and SM3 are encryption algorithms approved by the Chinese 111 National Cryptographic Bureau. The key length and the packet length 112 are both 128 bits. 114 2.1. SM2 Algorithm 116 SM2 is an asymmetric cryptographic algorithm published by the Chinese 117 State Cryptography Administration[4]. Its calculation speed and 118 secret key generation speed are faster than RSA since the it is based 119 on ECC. Currently, only SM3 can be used for data digest processing in 120 the SM2 digital signature algorithm. 122 2.2. SM3 Algorithm 124 SM3 is a cryptographic hash algorithm independently designed by 125 Chinese State Cryptography Administration[5]. The SM3 algorithm is 126 normally used in data digest with a higher level of security than the 127 MD5 algorithm and the SHA-1 algorithm. 129 3. Trusted Resolution with SM2 and SM3 Algorithms 131 Trusted resolution system is developed to achieve credibility and 132 verification through data signing and issuing certificates based on 133 the handle system proposed by [2]RFC3651.SM2 and SM3 algorithms could 134 be used to generate signature and data digest during trusted 135 resolution. 137 3.1. HS_CERT Extension 139 According to Handle System reference implementation, HS_CERT value is 140 a handle value with a data field that consists of a JWT (json web 141 token) structure[6] that are encoded with base64 respectively and 142 concatenated with period. field of HS_CERT consists of the 143 following entries: 145
147 A JSON object with an "alg" member which suggests algorithms used in 148 the HS_CERT value. 150 152 is a JSON object with member "perms" objects ,"publicKey" 153 objects, "iss" , "sub","exp","nbf" and "iat". 155 156 The entry refers to signature information of the
158 and entries. 160 In this document, examples of HS_CERT data are illustrated 161 considering the situation where SM2 and SM3 algorithms are used. 163 3.1.1. Header using SM2 and SM3 165 Example of the JWT Header in HS_CERT: 167 { 169 "alg":"SM2SM3" 171 } 173 The Header declares that the algorithms used in the certificate are 174 SM2 and SM3 algorithms. 176 3.1.2. Payload using SM2 and SM3 178 The payload is where the valid information is stored. The payload is 179 made up of two types of data: predefined claims and data extended by 180 user according to the RFC7519[6]. After encrypted with base64, 181 payload is stored in claim sets of JWT. 183 The following is an example of JWT Claims Set in HS_CERT data: 185 { 187 "perms": [ 189 { 191 "perm": "everything" 193 } 195 ], 197 "publicKey": { 199 "kty": "SM2", 201 "x": "uwNiWxWtqh6TYfooxpxSpF3VEdOF0_NFrpMZu03nTVM", 203 "y": "ODb6JqNLB8suvZtmccCJaTv0EpVcLGOuqPxMAM8faUw" 205 }, 207 "iss": "100:88", 208 "sub": "100:88.2045", 210 "exp": 1632381987, 212 "nbf": 1569309387, 214 "iat": 1569309987 216 The "perms" (permission) claim indicates the user authority of the 217 certificate. 219 There are four authority types defined: 221 "everything" means that issuer of the certificate can issue 222 certificate to any handle in the system. 224 "thisHandle" means the issuer of the certificate can only issue 225 certificate to itself. 227 "derivedPrefixes" indicates that the issuer can only issue 228 certificates to its sub-naming authority. 230 "handlesUnderThisPrefix" means the issuer can only issue handle all 231 the handles under this prefix. 233 The "publicKey" (public key) claim specifies algorithm of the public 234 key, which is set to SM2 in this example. 236 3.1.3. Signatrue of the Header and Payload 238 The third part of field in handle HS_CERT is a signature 239 information, in which SM2 private key of the issuer is used to sign 240
and . 242 Generation of SM2 signature refers to the process of using the result 243 of SM3 digest and the signer's private key to obtain the signature 244 result. 246 3.2. HS_SIGNATRUE Extension 248 HS_SIGNATURE is a handle data structure where issuer signs the handle 249 values to ensure authenticity of the information. HS_SIGNATRUE 250 contains a data field that is a JWT (json web token) structure[6] 251 RFC7519. 253 field of HS_SIGNATURE consists of the following entries: 255
257 A JSON object with an "alg" member which suggests algorithms used in 258 the HS_SIGNATURE value. 260 261 is a JSON object with member objects "digests","iss" , 262 "sub","exp","nbf","iat". 264 266 The entry refers to signature information of the
268 and entries. 270 Examples of HS_SIGNATRUE data using SM2 and SM3 algorithms are 271 showing in following sections. 273 3.2.1. Header using SM2 and SM3 275 Example of the JWT Header in HS_SIGNATRUE: 277 { 279 "alg":"SM2SM3" 281 } 283 The Header declares that the algorithms used in the certificate 284 structure are SM2 and SM3 algorithms. 286 3.2.2. Payload using SM2 and SM3 288 The following is an example of JWT Claims Set in HS_SIGNATURE data: 290 { 292 "digests": { 294 "alg": "SM3", 296 "digests": [{ 298 "index": 100, 300 "digest": "/7HpWmicaPFaMSePkbn+f/jcfAawEnieytM3qyJOha0=" 302 }, 304 { 306 "index": 1, 308 "digest": "300Bm9dCucz3vk+X71UWGuMe2FV62dEthRdb4iQvZzU=" 310 }, 312 { 313 "index": 301, 315 "digest": "aaV/sW/Eau00jtcDUzG7vqKVAc4mENJ2oZ+U4virnig=" 317 }, 319 { 321 "index": 401, 323 "digest": "XevUCYQfS+pucLkJA+vhVpC1lN4OVQzQugwfthpiaHk=" 325 } 327 ] 329 }, 331 "iss": "301:0.CR/20", 333 "sub": "301:0.NA/20", 335 "exp": 1640995200, 337 "nbf": 1459815236, 339 "iat": 1459815836 341 } 343 The "digests" claim contains digests of handle values where SM3 344 algorithm is used to generate the digests. 346 The "iss" (issuer) claim identifies the handle that issued the 348 JWT. 350 The "sub" (subject) claim identifies the handle that is the 352 subject of the certificate. 354 The "exp" (expiration time) claim identifies the expiration time on 356 or after which the JWT MUST NOT be accepted for processing. 358 The "nbf" (not before) claim identifies the time before which the JWT 359 MUST NOT be accepted for processing. 361 The "iat" (issued at) claim identifies the time at which the JWT was 362 issued. 364 3.2.3. Signatrue of the Header and Payload 366 The third part of HS_SIGNATURE field is a signature 367 information, in which SM2 private key of the issuer is used to sign < 368 Header> and entries after base64 encoded and concatenated 369 with period. 371 4. Message Credential with SM2 and SM3 Algorithms 373 4.1. Message Credential 375 The Handle system protocol provides support for the security 376 protection of analytical data, including support for confidentiality 377 protection based on symmetric encryption mechanism, and data 378 integrity protection based on digital signature or message 379 verification. 381 The Handle system protocol stipulates that the Handle message is made 382 up of the following parts: message envelope, message header, message 383 body, and message credential. 385 The client can request the Handle server to digitally sign the 386 operation response message or generate a message authentication code 387 by setting the authentication bit (CT) in the operation flag field 388 (OpFlag) of the message header, and use the message credential field 389 for delivery. 391 The message credential includes the following fields, according to 392 RFC3652 [3]: Credential Length, Version, Reserved, Options, Signer, 393 Type, . 395 4.2. Data Signing with SM2 Algorithm 397 in the message credential is used to specify the type of 398 algorithm used in the field, consists of 399 the following fields: 401 SignedInfo: : 4-byte unsigned integer 403 DigestAlgorithm: 405 SignedData: 407 The following table lists the key type, and corresponding algorithm: 409 Type Name Key Type Algorithm 411 --------- ------------ -------- 413 HS_SIGNED DSA_PUB_KEY DSA 415 HS_SIGNED RSA_PUB_KEY RSA-PSS 416 HS_SIGNED SM2_PUB_KEY SM2 418 4.3. SM3 Digest Algorithm in Message Credential 420 Where the refers to the digest algorithm used to 421 generate the digital signature and the contains digital 422 signature over the Message Header and Message Body. 424 In this document, value of could be set to "SM3" 425 which means that SM3 algorithm is used to generate the data digest. 427 The following table lists the < DigestAlgorithm >s that could be 428 supported: 430 Digest Algorithm Name Algorithm 432 --------------------- -------- 434 SHA-1 SHA-1 436 SHA-256/SHA256 SHA-256 438 SM3 SM3 440 5. Security Considerations 442 Data integrity under the protocol is achieved via the server's 443 digital signature. Care must be taken to protect the server's private 444 key from any impersonation attack. 446 6. IANA Considerations 448 7. References 450 7.1. Normative References 452 [1] Sun, S. and L. Lannom, "Handle System Overview", RFC 3650 453 November 2003. 455 [2] Sun, S., Reilly, S. and L. Lannom, "Handle System Namespace 456 and Service Definition", RFC 3651, November 2003. 458 [3] Sun, S. and L. Lannom, "Handle System Overview", RFC 3652 459 November 2003. 461 [4] National Cryptography Administration, " Public Key 462 Cryptographic Algorithm SM2 Based on Elliptic Curves", December 463 2010. 465 [5] National Cryptography Administration, "SM3 Cryptographic 466 Hash Algorithm", December 2010. 468 [6] Jones, et al., "JSON Web Token (JWT)", RFC 7519, May 2015. 470 8. Acknowledgments 472 This document was prepared using 2-Word-v2.0.template.dot.The Trusted 473 Resolution System described in this document relies on works and 474 protocols put forward by RFC 3650, RFC 3651,and RFC 3652[1][5][3]. 476 Author's Address 478 Yuying Chen 479 CAICT 480 No.52 Huayuan North Road, Haidian District 481 Beijing, Beijing, 100191 482 China 484 Phone: +86 188 1008 2358 485 Email: chenyuying@caict.ac.cn 487 Jiahui Wang 488 CAICT 489 No.52 Huayuan North Road, Haidian District 490 Beijing, Beijing, 100191 491 China 493 Phone: +86 186 0156 0021 494 Email: wangjiahui@caict.ac.cn 496 Bo Zhang 497 CAICT 498 No.52 Huayuan North Road, Haidian District 499 Beijing, Beijing, 100191 500 China 502 Phone: +86 159 1112 3285 503 Email: zhangbo3@caict.ac.cn 505 Zhipeng Fan 506 CAICT 508 No.52 Huayuan North Road, Haidian District 509 Beijing, Beijing, 100191 510 China 512 Phone: +86 159 1112 3285 513 Email: fanzhipeng@caict.ac.cn 515 Xufeng Ma 516 CAICT 517 No.52 Huayuan North Road, Haidian District 518 Beijing, Beijing, 100191 519 China 521 Phone: +86 188 1143 3140 522 Email: maxufeng@caict.ac.cn 524 Zhiping Li 525 CAICT 526 No.52 Huayuan North Road, Haidian District 527 Beijing, Beijing, 100191 528 China 530 Phone: +86 185 1107 1386 531 Email: lizhiping@caict.ac.cn 533 Jiagui Xie 534 CAICT 535 No.52 Huayuan North Road, Haidian District 536 Beijing, Beijing, 100191 537 China 539 Phone: +86 150 0138 5070 540 Email: xiejiagui@caict.ac.cn