Internet DRAFT - draft-chen-sm2-sm3-algorithms
draft-chen-sm2-sm3-algorithms
Network Working Group Y. Chen
Internet Draft J. Wang
Intended status: Informational B. Zhang
Expires:April 30, 2023 Z. Fan
X. Ma
Z. Li
J. Xie
November 6, 2022
China Academy of Information and Communications Technology
Use of the SM2 and SM3 Algorithms in Handle System
draft-chen-sm2-sm3-algorithms-04
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This memo provides information for
the Internet community. It does not specify an Internet standard of
any kind. Distribution of this memo is unlimited.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on April 30, 2023.
Copyright Notice
Copyright (c) 2020 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
(https://trustee.ietf.org/license-info) 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.
Chen, et al. Expires May 6, 2023 [Page 1]
Internet-Draft SM2 and SM3 Algorithm in Handle System November, 2022
Abstract
The Handle System is a global name service that allows secured handle
resolution and administration over the public Internet according to
[1][5][3]. Handle System protocol [3] is designed to be transmitted
as a byte stream via a TCP connection. In this document, SM2 and SM3
algorithms [4][5]are introduced into the handle system to enhance the
security and compactivity. Trusted resolution and message credential
are extended to support SM2 and SM3 algorithms.
Table of Contents
1. Introduction...................................................2
2. SM2 and SM3 Algorithms Overview................................2
2.1. SM2 Algorithm.............................................3
2.2. SM3 Algorithm.............................................3
3. Trusted Resolution with SM2 and SM3 Algorithms.................3
3.1. HS_CERT Extension.........................................3
3.1.1. Header using SM2 and SM3.............................4
3.1.2. Payload using SM2 and SM3............................4
3.1.3. Signatrue of the Header and Payload..................5
3.2. HS_SIGNATRUE Extension....................................5
3.2.1. Header using SM2 and SM3.............................6
3.2.2. Payload using SM2 and SM3............................6
3.2.3. Signatrue of the Header and Payload..................8
4. Message Credential with SM2 and SM3 Algorithms.................8
4.1. Message Credential........................................8
4.2. Data Signing with SM2 Algorithm...........................8
4.3. SM3 Digest Algorithm in Message Credential................9
5. Security Considerations........................................9
6. IANA Considerations............................................9
7. References.....................................................9
7.1. Normative References......................................9
8. Acknowledgments...............................................10
1. Introduction
RFC 3650-RFC 3652[1],[5][3] provide an open protocol, a general-
purpose global name service, and a reference implementation of the
protocol. RSA and DSA algorithms are commonly used when generating
data signatures. With the development of cryptography and computer
technology, the currently commonly used 1024-bit RSA algorithm faces
security threats. In order to enhance data integrity protection based
on digital signature and message verification, SM2 and SM3 algorithms
are introduced to the Handle System.
2. SM2 and SM3 Algorithms Overview
Digital signature means that a signer generates a digital signature
on data, and verification are performed to verify the authenticity of
the signature. Each signer has a unique pair of public key and
private key, where the private key is used to generate the signature,
and the verifier uses the signer public key to verify the signature.
Chen, et al. Expires May 6, 2023 [Page 2]
Internet-Draft SM2 and SM3 Algorithm in Handle System November, 2022
Verification of signature can be performed to confirm that the sender
holds the corresponding private key through the public key and
signature information without revealing the sender's private key. The
signature can also bind the sender's identity and information to
prevent imitation.
Both SM2 and SM3 are encryption algorithms approved by the Chinese
National Cryptographic Bureau. The key length and the packet length
are both 128 bits.
2.1. SM2 Algorithm
SM2 is an asymmetric cryptographic algorithm published by the Chinese
State Cryptography Administration[4]. Its calculation speed and
secret key generation speed are faster than RSA since the it is based
on ECC. Currently, only SM3 can be used for data digest processing in
the SM2 digital signature algorithm.
2.2. SM3 Algorithm
SM3 is a cryptographic hash algorithm independently designed by
Chinese State Cryptography Administration[5]. The SM3 algorithm is
normally used in data digest with a higher level of security than the
MD5 algorithm and the SHA-1 algorithm.
3. Trusted Resolution with SM2 and SM3 Algorithms
Trusted resolution system is developed to achieve credibility and
verification through data signing and issuing certificates based on
the handle system proposed by [2]RFC3651.SM2 and SM3 algorithms could
be used to generate signature and data digest during trusted
resolution.
3.1. HS_CERT Extension
According to Handle System reference implementation, HS_CERT value is
a handle value with a data field that consists of a JWT (json web
token) structure[6] that are encoded with base64 respectively and
concatenated with period. <Data> field of HS_CERT consists of the
following entries:
<Header>
A JSON object with an "alg" member which suggests algorithms used in
the HS_CERT value.
<Payload>
<Payload> is a JSON object with member "perms" objects ,"publicKey"
objects, "iss" , "sub","exp","nbf" and "iat".
<Signature>
Chen, et al. Expires May 6, 2023 [Page 3]
Internet-Draft SM2 and SM3 Algorithm in Handle System November, 2022
The <Signature> entry refers to signature information of the <Header>
and <Payload> entries.
In this document, examples of HS_CERT data are illustrated
considering the situation where SM2 and SM3 algorithms are used.
3.1.1. Header using SM2 and SM3
Example of the JWT Header in HS_CERT:
{
"alg":"SM2SM3"
}
The Header declares that the algorithms used in the certificate are
SM2 and SM3 algorithms.
3.1.2. Payload using SM2 and SM3
The payload is where the valid information is stored. The payload is
made up of two types of data: predefined claims and data extended by
user according to the RFC7519[6]. After encrypted with base64,
payload is stored in claim sets of JWT.
The following is an example of JWT Claims Set in HS_CERT data:
{
"perms": [
{
"perm": "everything"
}
],
"publicKey": {
"kty": "SM2",
"x": "uwNiWxWtqh6TYfooxpxSpF3VEdOF0_NFrpMZu03nTVM",
"y": "ODb6JqNLB8suvZtmccCJaTv0EpVcLGOuqPxMAM8faUw"
},
"iss": "100:88",
Chen, et al. Expires May 6, 2023 [Page 4]
Internet-Draft SM2 and SM3 Algorithm in Handle System November, 2022
"sub": "100:88.2045",
"exp": 1632381987,
"nbf": 1569309387,
"iat": 1569309987
The "perms" (permission) claim indicates the user authority of the
certificate.
There are four authority types defined:
"everything" means that issuer of the certificate can issue
certificate to any handle in the system.
"thisHandle" means the issuer of the certificate can only issue
certificate to itself.
"derivedPrefixes" indicates that the issuer can only issue
certificates to its sub-naming authority.
"handlesUnderThisPrefix" means the issuer can only issue handle all
the handles under this prefix.
The "publicKey" (public key) claim specifies algorithm of the public
key, which is set to SM2 in this example.
3.1.3. Signatrue of the Header and Payload
The third part of <data> field in handle HS_CERT is a signature
information, in which SM2 private key of the issuer is used to sign
<Header> and <Payload>.
Generation of SM2 signature refers to the process of using the result
of SM3 digest and the signer's private key to obtain the signature
result.
3.2. HS_SIGNATRUE Extension
HS_SIGNATURE is a handle data structure where issuer signs the handle
values to ensure authenticity of the information. HS_SIGNATRUE
contains a data field that is a JWT (json web token) structure[6]
RFC7519.
<Data> field of HS_SIGNATURE consists of the following entries:
<Header>
A JSON object with an "alg" member which suggests algorithms used in
the HS_SIGNATURE value.
<Payload>
Chen, et al. Expires May 6, 2023 [Page 5]
Internet-Draft SM2 and SM3 Algorithm in Handle System November, 2022
<Payload> is a JSON object with member objects "digests","iss" ,
"sub","exp","nbf","iat".
<Signature>
The <Signature> entry refers to signature information of the <Header>
and <Payload> entries.
Examples of HS_SIGNATRUE data using SM2 and SM3 algorithms are
showing in following sections.
3.2.1. Header using SM2 and SM3
Example of the JWT Header in HS_SIGNATRUE:
{
"alg":"SM2SM3"
}
The Header declares that the algorithms used in the certificate
structure are SM2 and SM3 algorithms.
3.2.2. Payload using SM2 and SM3
The following is an example of JWT Claims Set in HS_SIGNATURE data:
{
"digests": {
"alg": "SM3",
"digests": [{
"index": 100,
"digest": "/7HpWmicaPFaMSePkbn+f/jcfAawEnieytM3qyJOha0="
},
{
"index": 1,
"digest": "300Bm9dCucz3vk+X71UWGuMe2FV62dEthRdb4iQvZzU="
},
{
Chen, et al. Expires May 6, 2023 [Page 6]
Internet-Draft SM2 and SM3 Algorithm in Handle System November, 2022
"index": 301,
"digest": "aaV/sW/Eau00jtcDUzG7vqKVAc4mENJ2oZ+U4virnig="
},
{
"index": 401,
"digest": "XevUCYQfS+pucLkJA+vhVpC1lN4OVQzQugwfthpiaHk="
}
]
},
"iss": "301:0.CR/20",
"sub": "301:0.NA/20",
"exp": 1640995200,
"nbf": 1459815236,
"iat": 1459815836
}
The "digests" claim contains digests of handle values where SM3
algorithm is used to generate the digests.
The "iss" (issuer) claim identifies the handle that issued the
JWT.
The "sub" (subject) claim identifies the handle that is the
subject of the certificate.
The "exp" (expiration time) claim identifies the expiration time on
or after which the JWT MUST NOT be accepted for processing.
The "nbf" (not before) claim identifies the time before which the JWT
MUST NOT be accepted for processing.
The "iat" (issued at) claim identifies the time at which the JWT was
issued.
Chen, et al. Expires May 6, 2023 [Page 7]
Internet-Draft SM2 and SM3 Algorithm in Handle System November, 2022
3.2.3. Signatrue of the Header and Payload
The third part of HS_SIGNATURE <data> field is a signature
information, in which SM2 private key of the issuer is used to sign <
Header> and <Payload> entries after base64 encoded and concatenated
with period.
4. Message Credential with SM2 and SM3 Algorithms
4.1. Message Credential
The Handle system protocol provides support for the security
protection of analytical data, including support for confidentiality
protection based on symmetric encryption mechanism, and data
integrity protection based on digital signature or message
verification.
The Handle system protocol stipulates that the Handle message is made
up of the following parts: message envelope, message header, message
body, and message credential.
The client can request the Handle server to digitally sign the
operation response message or generate a message authentication code
by setting the authentication bit (CT) in the operation flag field
(OpFlag) of the message header, and use the message credential field
for delivery.
The message credential includes the following fields, according to
RFC3652 [3]: Credential Length, Version, Reserved, Options, Signer,
Type, <SignedInfo>.
4.2. Data Signing with SM2 Algorithm
<Type field> in the message credential is used to specify the type of
algorithm used in the <SignedInfo> field, <SignedInfo> consists of
the following fields:
SignedInfo: <Length>: 4-byte unsigned integer
DigestAlgorithm: <UTF8-String>
SignedData: <Length, Signature>
The following table lists the key type, and corresponding algorithm:
Type Name Key Type Algorithm
--------- ------------ --------
HS_SIGNED DSA_PUB_KEY DSA
HS_SIGNED RSA_PUB_KEY RSA-PSS
Chen, et al. Expires May 6, 2023 [Page 8]
Internet-Draft SM2 and SM3 Algorithm in Handle System November, 2022
HS_SIGNED SM2_PUB_KEY SM2
4.3. SM3 Digest Algorithm in Message Credential
Where the <DigestAlgorithm> refers to the digest algorithm used to
generate the digital signature and the <SignedData> contains digital
signature over the Message Header and Message Body.
In this document, value of <DigestAlgorithm> could be set to "SM3"
which means that SM3 algorithm is used to generate the data digest.
The following table lists the < DigestAlgorithm >s that could be
supported:
Digest Algorithm Name Algorithm
--------------------- --------
SHA-1 SHA-1
SHA-256/SHA256 SHA-256
SM3 SM3
5. Security Considerations
Data integrity under the protocol is achieved via the server's
digital signature. Care must be taken to protect the server's private
key from any impersonation attack.
6. IANA Considerations
7. References
7.1. Normative References
[1] Sun, S. and L. Lannom, "Handle System Overview", RFC 3650
November 2003.
[2] Sun, S., Reilly, S. and L. Lannom, "Handle System Namespace
and Service Definition", RFC 3651, November 2003.
[3] Sun, S. and L. Lannom, "Handle System Overview", RFC 3652
November 2003.
[4] National Cryptography Administration, " Public Key
Cryptographic Algorithm SM2 Based on Elliptic Curves", December
2010.
[5] National Cryptography Administration, "SM3 Cryptographic
Hash Algorithm", December 2010.
Chen, et al. Expires May 6, 2023 [Page 9]
Internet-Draft SM2 and SM3 Algorithm in Handle System November, 2022
[6] Jones, et al., "JSON Web Token (JWT)", RFC 7519, May 2015.
8. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.The Trusted
Resolution System described in this document relies on works and
protocols put forward by RFC 3650, RFC 3651,and RFC 3652[1][5][3].
Author's Address
Yuying Chen
CAICT
No.52 Huayuan North Road, Haidian District
Beijing, Beijing, 100191
China
Phone: +86 188 1008 2358
Email: chenyuying@caict.ac.cn
Jiahui Wang
CAICT
No.52 Huayuan North Road, Haidian District
Beijing, Beijing, 100191
China
Phone: +86 186 0156 0021
Email: wangjiahui@caict.ac.cn
Bo Zhang
CAICT
No.52 Huayuan North Road, Haidian District
Beijing, Beijing, 100191
Chen, et al. Expires May 6, 2023 [Page 10]
Internet-Draft SM2 and SM3 Algorithm in Handle System November, 2022
China
Phone: +86 159 1112 3285
Email: zhangbo3@caict.ac.cn
Zhipeng Fan
CAICT
No.52 Huayuan North Road, Haidian District
Beijing, Beijing, 100191
China
Phone: +86 159 1112 3285
Email: fanzhipeng@caict.ac.cn
Xufeng Ma
CAICT
No.52 Huayuan North Road, Haidian District
Beijing, Beijing, 100191
China
Phone: +86 188 1143 3140
Email: maxufeng@caict.ac.cn
Zhiping Li
CAICT
No.52 Huayuan North Road, Haidian District
Chen, et al. Expires May 6, 2023 [Page 11]
Internet-Draft SM2 and SM3 Algorithm in Handle System November, 2022
Beijing, Beijing, 100191
China
Phone: +86 185 1107 1386
Email: lizhiping@caict.ac.cn
Jiagui Xie
CAICT
No.52 Huayuan North Road, Haidian District
Beijing, Beijing, 100191
China
Phone: +86 150 0138 5070
Email: xiejiagui@caict.ac.cn
Chen, et al. Expires May 6, 2023 [Page 12]
