idnits 2.17.1 draft-chen-sm2-sm3-algorithms-03.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 5 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 357: '...er which the JWT MUST NOT be accepted ...' RFC 2119 keyword, line 360: '... 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 -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '2' is defined on line 456, 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:October 15,2022 Z. Fan 5 X. Ma 6 Z. Li 7 J. Xie 9 May 9,2022 10 China Academy of Information and Communications Technology 12 Use of the SM2 and SM3 Algorithms in Handle System 13 draft-chen-sm2-sm3-algorithms-03 15 Status of this Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. This memo provides information for 19 the Internet community. It does not specify an Internet standard of 20 any kind. Distribution of this memo is unlimited. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet-Drafts. 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 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 This Internet-Draft will expire on October 15,2022. 39 Copyright Notice 41 Copyright (c) 2020 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with 49 respect to this document. 51 Abstract 53 The Handle System is a global name service that allows secured handle 54 resolution and administration over the public Internet according to 55 [1][5][3]. Handle System protocol [3] is designed to be transmitted 56 as a byte stream via a TCP connection. In this document, SM2 and SM3 57 algorithms [4][5]are introduced into the handle system to enhance the 58 security and compactivity. Trusted resolution and message credential 59 are extended to support SM2 and SM3 algorithms. 61 Table of Contents 63 1. Introduction...................................................2 64 2. SM2 and SM3 Algorithms Overview................................2 65 2.1. SM2 Algorithm.............................................3 66 2.2. SM3 Algorithm.............................................3 67 3. Trusted Resolution with SM2 and SM3 Algorithms.................3 68 3.1. HS_CERT Extension.........................................3 69 3.1.1. Header using SM2 and SM3.............................4 70 3.1.2. Payload using SM2 and SM3............................4 71 3.1.3. Signatrue of the Header and Payload..................5 72 3.2. HS_SIGNATRUE Extension....................................5 73 3.2.1. Header using SM2 and SM3.............................6 74 3.2.2. Payload using SM2 and SM3............................6 75 3.2.3. Signatrue of the Header and Payload..................8 76 4. Message Credential with SM2 and SM3 Algorithms.................8 77 4.1. Message Credential........................................8 78 4.2. Data Signing with SM2 Algorithm...........................8 79 4.3. SM3 Digest Algorithm in Message Credential................9 80 5. Security Considerations........................................9 81 6. IANA Considerations............................................9 82 7. References.....................................................9 83 7.1. Normative References......................................9 84 8. Acknowledgments...............................................10 86 1. Introduction 88 RFC 3650-RFC 3652[1],[5][3] provide an open protocol, a general- 89 purpose global name service, and a reference implementation of the 90 protocol. RSA and DSA algorithms are commonly used when generating 91 data signatures. With the development of cryptography and computer 92 technology, the currently commonly used 1024-bit RSA algorithm faces 93 security threats. In order to enhance data integrity protection based 94 on digital signature and message verification, SM2 and SM3 algorithms 95 are introduced to the Handle System. 97 2. SM2 and SM3 Algorithms Overview 99 Digital signature means that a signer generates a digital signature 100 on data, and verification are performed to verify the authenticity of 101 the signature. Each signer has a unique pair of public key and 102 private key, where the private key is used to generate the signature, 103 and the verifier uses the signer public key to verify the signature. 105 Verification of signature can be performed to confirm that the sender 106 holds the corresponding private key through the public key and 107 signature information without revealing the sender's private key. The 108 signature can also bind the sender's identity and information to 109 prevent imitation. 111 Both SM2 and SM3 are encryption algorithms approved by the Chinese 112 National Cryptographic Bureau. The key length and the packet length 113 are both 128 bits. 115 2.1. SM2 Algorithm 117 SM2 is an asymmetric cryptographic algorithm published by the Chinese 118 State Cryptography Administration[4]. Its calculation speed and 119 secret key generation speed are faster than RSA since the it is based 120 on ECC. Currently, only SM3 can be used for data digest processing in 121 the SM2 digital signature algorithm. 123 2.2. SM3 Algorithm 125 SM3 is a cryptographic hash algorithm independently designed by 126 Chinese State Cryptography Administration[5]. The SM3 algorithm is 127 normally used in data digest with a higher level of security than the 128 MD5 algorithm and the SHA-1 algorithm. 130 3. Trusted Resolution with SM2 and SM3 Algorithms 132 Trusted resolution system is developed to achieve credibility and 133 verification through data signing and issuing certificates based on 134 the handle system proposed by [2]RFC3651.SM2 and SM3 algorithms could 135 be used to generate signature and data digest during trusted 136 resolution. 138 3.1. HS_CERT Extension 140 According to Handle System reference implementation, HS_CERT value is 141 a handle value with a data field that consists of a JWT (json web 142 token) structure[6] that are encoded with base64 respectively and 143 concatenated with period. field of HS_CERT consists of the 144 following entries: 146
148 A JSON object with an "alg" member which suggests algorithms used in 149 the HS_CERT value. 151 153 is a JSON object with member "perms" objects ,"publicKey" 154 objects, "iss" , "sub","exp","nbf" and "iat". 156 157 The entry refers to signature information of the
159 and entries. 161 In this document, examples of HS_CERT data are illustrated 162 considering the situation where SM2 and SM3 algorithms are used. 164 3.1.1. Header using SM2 and SM3 166 Example of the JWT Header in HS_CERT: 168 { 170 "alg":"SM2SM3" 172 } 174 The Header declares that the algorithms used in the certificate are 175 SM2 and SM3 algorithms. 177 3.1.2. Payload using SM2 and SM3 179 The payload is where the valid information is stored. The payload is 180 made up of two types of data: predefined claims and data extended by 181 user according to the RFC7519[6]. After encrypted with base64, 182 payload is stored in claim sets of JWT. 184 The following is an example of JWT Claims Set in HS_CERT data: 186 { 188 "perms": [ 190 { 192 "perm": "everything" 194 } 196 ], 198 "publicKey": { 200 "kty": "SM2", 202 "x": "uwNiWxWtqh6TYfooxpxSpF3VEdOF0_NFrpMZu03nTVM", 204 "y": "ODb6JqNLB8suvZtmccCJaTv0EpVcLGOuqPxMAM8faUw" 206 }, 208 "iss": "100:88", 209 "sub": "100:88.2045", 211 "exp": 1632381987, 213 "nbf": 1569309387, 215 "iat": 1569309987 217 The "perms" (permission) claim indicates the user authority of the 218 certificate. 220 There are four authority types defined: 222 "everything" means that issuer of the certificate can issue 223 certificate to any handle in the system. 225 "thisHandle" means the issuer of the certificate can only issue 226 certificate to itself. 228 "derivedPrefixes" indicates that the issuer can only issue 229 certificates to its sub-naming authority. 231 "handlesUnderThisPrefix" means the issuer can only issue handle all 232 the handles under this prefix. 234 The "publicKey" (public key) claim specifies algorithm of the public 235 key, which is set to SM2 in this example. 237 3.1.3. Signatrue of the Header and Payload 239 The third part of field in handle HS_CERT is a signature 240 information, in which SM2 private key of the issuer is used to sign 241
and . 243 Generation of SM2 signature refers to the process of using the result 244 of SM3 digest and the signer's private key to obtain the signature 245 result. 247 3.2. HS_SIGNATRUE Extension 249 HS_SIGNATURE is a handle data structure where issuer signs the handle 250 values to ensure authenticity of the information. HS_SIGNATRUE 251 contains a data field that is a JWT (json web token) structure[6] 252 RFC7519. 254 field of HS_SIGNATURE consists of the following entries: 256
258 A JSON object with an "alg" member which suggests algorithms used in 259 the HS_SIGNATURE value. 261 262 is a JSON object with member objects "digests","iss" , 263 "sub","exp","nbf","iat". 265 267 The entry refers to signature information of the
269 and entries. 271 Examples of HS_SIGNATRUE data using SM2 and SM3 algorithms are 272 showing in following sections. 274 3.2.1. Header using SM2 and SM3 276 Example of the JWT Header in HS_SIGNATRUE: 278 { 280 "alg":"SM2SM3" 282 } 284 The Header declares that the algorithms used in the certificate 285 structure are SM2 and SM3 algorithms. 287 3.2.2. Payload using SM2 and SM3 289 The following is an example of JWT Claims Set in HS_SIGNATURE data: 291 { 293 "digests": { 295 "alg": "SM3", 297 "digests": [{ 299 "index": 100, 301 "digest": "/7HpWmicaPFaMSePkbn+f/jcfAawEnieytM3qyJOha0=" 303 }, 305 { 307 "index": 1, 309 "digest": "300Bm9dCucz3vk+X71UWGuMe2FV62dEthRdb4iQvZzU=" 311 }, 313 { 314 "index": 301, 316 "digest": "aaV/sW/Eau00jtcDUzG7vqKVAc4mENJ2oZ+U4virnig=" 318 }, 320 { 322 "index": 401, 324 "digest": "XevUCYQfS+pucLkJA+vhVpC1lN4OVQzQugwfthpiaHk=" 326 } 328 ] 330 }, 332 "iss": "301:0.CR/20", 334 "sub": "301:0.NA/20", 336 "exp": 1640995200, 338 "nbf": 1459815236, 340 "iat": 1459815836 342 } 344 The "digests" claim contains digests of handle values where SM3 345 algorithm is used to generate the digests. 347 The "iss" (issuer) claim identifies the handle that issued the 349 JWT. 351 The "sub" (subject) claim identifies the handle that is the 353 subject of the certificate. 355 The "exp" (expiration time) claim identifies the expiration time on 357 or after which the JWT MUST NOT be accepted for processing. 359 The "nbf" (not before) claim identifies the time before which the JWT 360 MUST NOT be accepted for processing. 362 The "iat" (issued at) claim identifies the time at which the JWT was 363 issued. 365 3.2.3. Signatrue of the Header and Payload 367 The third part of HS_SIGNATURE field is a signature 368 information, in which SM2 private key of the issuer is used to sign < 369 Header> and entries after base64 encoded and concatenated 370 with period. 372 4. Message Credential with SM2 and SM3 Algorithms 374 4.1. Message Credential 376 The Handle system protocol provides support for the security 377 protection of analytical data, including support for confidentiality 378 protection based on symmetric encryption mechanism, and data 379 integrity protection based on digital signature or message 380 verification. 382 The Handle system protocol stipulates that the Handle message is made 383 up of the following parts: message envelope, message header, message 384 body, and message credential. 386 The client can request the Handle server to digitally sign the 387 operation response message or generate a message authentication code 388 by setting the authentication bit (CT) in the operation flag field 389 (OpFlag) of the message header, and use the message credential field 390 for delivery. 392 The message credential includes the following fields, according to 393 RFC3652 [3]: Credential Length, Version, Reserved, Options, Signer, 394 Type, . 396 4.2. Data Signing with SM2 Algorithm 398 in the message credential is used to specify the type of 399 algorithm used in the field, consists of 400 the following fields: 402 SignedInfo: : 4-byte unsigned integer 404 DigestAlgorithm: 406 SignedData: 408 The following table lists the key type, and corresponding algorithm: 410 Type Name Key Type Algorithm 412 --------- ------------ -------- 414 HS_SIGNED DSA_PUB_KEY DSA 416 HS_SIGNED RSA_PUB_KEY RSA-PSS 417 HS_SIGNED SM2_PUB_KEY SM2 419 4.3. SM3 Digest Algorithm in Message Credential 421 Where the refers to the digest algorithm used to 422 generate the digital signature and the contains digital 423 signature over the Message Header and Message Body. 425 In this document, value of could be set to "SM3" 426 which means that SM3 algorithm is used to generate the data digest. 428 The following table lists the < DigestAlgorithm >s that could be 429 supported: 431 Digest Algorithm Name Algorithm 433 --------------------- -------- 435 SHA-1 SHA-1 437 SHA-256/SHA256 SHA-256 439 SM3 SM3 441 5. Security Considerations 443 Data integrity under the protocol is achieved via the server's 444 digital signature. Care must be taken to protect the server's private 445 key from any impersonation attack. 447 6. IANA Considerations 449 7. References 451 7.1. Normative References 453 [1] Sun, S. and L. Lannom, "Handle System Overview", RFC 3650 454 November 2003. 456 [2] Sun, S., Reilly, S. and L. Lannom, "Handle System Namespace 457 and Service Definition", RFC 3651, November 2003. 459 [3] Sun, S. and L. Lannom, "Handle System Overview", RFC 3652 460 November 2003. 462 [4] National Cryptography Administration, " Public Key 463 Cryptographic Algorithm SM2 Based on Elliptic Curves", December 464 2010. 466 [5] National Cryptography Administration, "SM3 Cryptographic 467 Hash Algorithm", December 2010. 469 [6] Jones, et al., "JSON Web Token (JWT)", RFC 7519, May 2015. 471 8. Acknowledgments 473 This document was prepared using 2-Word-v2.0.template.dot.The Trusted 474 Resolution System described in this document relies on works and 475 protocols put forward by RFC 3650, RFC 3651,and RFC 3652[1][5][3]. 477 Author's Address 479 Yuying Chen 480 CAICT 481 No.52 Huayuan North Road, Haidian District 482 Beijing, Beijing, 100191 483 China 485 Phone: +86 188 1008 2358 486 Email: chenyuying@caict.ac.cn 488 Jiahui Wang 489 CAICT 490 No.52 Huayuan North Road, Haidian District 491 Beijing, Beijing, 100191 492 China 494 Phone: +86 186 0156 0021 495 Email: wangjiahui@caict.ac.cn 497 Bo Zhang 498 CAICT 499 No.52 Huayuan North Road, Haidian District 500 Beijing, Beijing, 100191 501 China 503 Phone: +86 159 1112 3285 504 Email: zhangbo3@caict.ac.cn 506 Zhipeng Fan 507 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