idnits 2.17.1 draft-wang-tls-raw-public-key-with-ibc-08.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 4 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 5, 2019) is 1879 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 7250' is mentioned on line 311, but not defined == Missing Reference: 'RFC 8446' is mentioned on line 306, but not defined == Missing Reference: 'RFC 6507' is mentioned on line 100, but not defined == Missing Reference: 'RFC 5091' is mentioned on line 123, but not defined == Unused Reference: 'RFC2434' is defined on line 558, but no explicit reference was found in the text == Unused Reference: 'RFC5091' is defined on line 561, but no explicit reference was found in the text == Unused Reference: 'RFC7250' is defined on line 576, but no explicit reference was found in the text == Unused Reference: 'RFC8216' is defined on line 586, but no explicit reference was found in the text == Unused Reference: 'RFC8446' is defined on line 590, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'PKIX' ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Downref: Normative reference to an Informational RFC: RFC 5091 ** Downref: Normative reference to an Informational RFC: RFC 6507 ** Downref: Normative reference to an Informational RFC: RFC 6508 ** Downref: Normative reference to an Informational RFC: RFC 8216 Summary: 6 errors (**), 0 flaws (~~), 11 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force H. Wang, Ed. 3 Internet-Draft Y. Yang 4 Intended status: Standards Track X. Kang 5 Expires: September 6, 2019 Huawei International Pte. Ltd. 6 March 5, 2019 8 Using Identity as Raw Public Key in Transport Layer Security (TLS) and 9 Datagram Transport Layer Security (DTLS) 10 draft-wang-tls-raw-public-key-with-ibc-08 12 Abstract 14 This document specifies the use of identity as a raw public key in 15 Transport Layer Security (TLS) and Datagram Transport Layer Security 16 (DTLS). The TLS protocol procedures are kept unchanged, but 17 signature algorithms are extended to support Identity-based signature 18 (IBS). A typical Identity-based signature algorithm, the ECCSI 19 signature algorithm defined in RFC 6507, is supported in the current 20 version. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 6, 2019. 39 Copyright Notice 41 Copyright (c) 2019 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 respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Extension of RAW Public Key to IBC-based Public Key . . . . . 4 59 4. New Signature Algorithms for IBS . . . . . . . . . . . . . . 6 60 5. TLS Client and Server Handshake Behavior . . . . . . . . . . 7 61 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 6.1. TLS Client and Server Use IBS algorithm . . . . . . . . . 9 63 6.2. Combined Usage of Raw Public Keys and X.509 Certificates 10 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 66 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 67 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 69 10.2. Informative References . . . . . . . . . . . . . . . . . 13 70 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 14 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 73 1. Introduction 75 DISCLAIMER: This is a personal draft and a limited security analysis 76 is provided. 78 Traditionally, TLS client and server exchange public keys endorsed by 79 PKIX [PKIX] certificates. It is considered complicated and may cause 80 security weaknesses with the use of PKIX certificates Defeating-SSL 81 [Defeating-SSL]. To simplify certificates exchange, using RAW public 82 key with TLS/DTLS has been spcified in [RFC 7250] and has been 83 included in the TLS 1.3[RFC 8446]. With RAW public key, instead of 84 transmitting a full certificate or a certificate chain in the TLS 85 messages, only public keys are exchanged between client and server. 86 However, using RAW public key requires out-of-band mechanisms to bind 87 the public key to the entity presenting the key. 89 Recently, 3GPP has adopted the EAP authentication framework for 5G 90 and EAP-TLS is considered as one of the candidate authentication 91 methods for private networks, especially for networks with a large 92 number of IoT devices. For IoT networks, TLS/DTLS with RAW public 93 key is particularly attractive, but binding identities with public 94 keys might be challenging. The cost to maintain a large table for 95 identity and public key mapping at server side incurs additional 96 maintenance cost. e.g. devices have to pre-register to the server. 98 To simplify the binding between the public key and the entity 99 presenting the public key, a better way could be using Identity-Based 100 Cryptography(IBC), such as ECCSI public key specified in [RFC 6507], 101 for authentication. Different from X.509 certificates and raw public 102 keys, a public key in IBC takes the form of the entity's identity. 103 This eliminates the necessity of binding between a public key and the 104 entity presenting the public key. 106 The concept of IBC was first proposed by Adi Shamir in 1984. As a 107 special class of public key cryptography, IBC uses a user's identity 108 as public key, avoiding the hassle of public key certification in 109 public key cryptosystems. IBC broadly includes IBE (Identity-based 110 Encryption) and IBS (Identity-based Signature). For an IBC system to 111 work, there exists a trusted third party, PKG (private key generator) 112 responsible for issuing private keys to the users. In particular, 113 the PKG has in possession a pair of Master Public Key and Master 114 Secret Key; a private key is generated based on the user's identity 115 by using the Master Secret key, while the Master Public key is used 116 together with the user's identities for encryption (in case of IBE) 117 and signature verification ( in case of IBS). Another name of PKG is 118 Key Management System (KMS), which is also used in some IBC system. 119 In this document, the terms of PKG and KMS are interchangable. 121 A number of IBE and IBS algorithms have been standardized by 122 different standardization bodies, such as IETF, IEEE, ISO/IEC, etc. 123 For example, IETF has spcified several RFCs such as [RFC 5091], [RFC 124 6507] and [RFC6508] for both IBE and IBS algorithms. ISO/JTC and 125 IEEE also have a few standards on IBC algorithms. 127 RFC 7250 has specified the use of raw public key with TLS/DTLS 128 handshake. However, supporting of IBS algorithms has not been 129 included therein. Since IBS algorithms are efficient in public key 130 transmission and also eliminate the binding between public keys and 131 identities, in this document, an amendment is added for supporting 132 IBS algorithms as raw public key. 134 IBS algorithm exempts client and server from public key certification 135 and identity binding by checking an entity's signatures and its 136 identity against the master public key of its PKG. With an IBS 137 algorithm, a PKG generates private keys for entities based on their 138 identities. Global parameters such as PKG's Master Public Key (MPK) 139 need be provisioned to both client and server. These parameters are 140 not user specific, but PKG specific. 142 For a client, PKG specific parameters can be provisioned at the time 143 PKG provisions the private key to the client. For the server, how to 144 get the PKG specific parameters provisioned is out of the scope of 145 this document, and it is deployment dependent. 147 The document is organized as follows: Section 3 defines the data 148 structure required when identity is used as raw public key. 149 Section 4 defines the cipher suites required to support IBS algorithm 150 over TLS/DTLS. Section 5 explains how client and server authenticate 151 each other when using identity as raw public key. Section 6 gives 152 examples for using identity as raw public key over TLS/DTLS handshake 153 procedure. Section 7 discusses the security considerations. 155 2. Terms 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 159 "OPTIONAL" in this document are to be interpreted as described in BCP 160 14 [RFC2119] [RFC8174] when, and only when, they appear in all 161 capitals. 163 3. Extension of RAW Public Key to IBC-based Public Key 165 To support the negotiation of using raw public between client and 166 server, a new Certificate structure is defined in RFC 7250. It is 167 used by the client and server in the hello messages to indicate the 168 types of certificates supported by each side. 170 When RawPublicKey type is selected for authentication, a data 171 structure, subjectPublicKeyInfo, is used to carry the raw public key 172 and its cryptographic algorithm. Within the subjectPublicKeyInfo 173 structure, two fields, algorithm and subjectPublicKey, are defined. 174 The algorithm is a data structure specifies the cryptographic 175 algorithm used with raw public key, which is represented by an object 176 Identifiers (OID); and the parameters field provides necessary 177 parameters associated with the algorithm. The subjectPublicKey field 178 within the subjectPublicKeyInfo carry the raw public itself. 180 subjectPublicKeyInfo ::= SEQUENCE { 181 algorithm AlgorithmIdentifier, 182 subjectPublicKey BIT STRING 183 } 185 AlgorithmIdentifier ::= SEQUENCE { 186 algorithm OBJECT IDENTIFIER, 187 parameters ANY DEFINED BY algorithm OPTIONAL 188 } 190 Figure 1: SubjectPublicKeyInfo ASN.1 Structure 192 With IBS algorithm, an identity is used as the raw public key, which 193 can be converted to an BIT string and put into the subjectPublicKey 194 field. The algorithm field in AlgorithmIdentifier structure is the 195 object identifier of the IBS algorithm used. Specifically, for the 196 ECCSI signature algorithm supported in this draft, the OBJECT 197 IDENTIFIER is described with following data structure: 199 sa-eccsiWithSHA256 SIGNATURE-ALGORITHM ::= { 200 IDENTIFIER id-alg-eccsi-with-sha256 201 VALUE ECCSI-Sig-Value PARAMS TYPE NULL ARE absent 202 HASHES { mda-sha256 } 203 SMIME-CAPS { IDENTIFIED BY id-alg-eccsi-with-sha256 } 204 } 206 Figure 2: ECCSI Signature Algorithm ANSI.1 Structure 208 Note, in a real implementation, only OID part will be transmitted 209 over the TLS negotiation protoocols. 211 Beside OID, it is necessary to tell the peer the set of global 212 parameters used by the signer. The information can be carried in the 213 payload of the parameters field in AlgorithmIdentifier. In the 214 following, a data structure for carrying ECCSI-based parameters are 215 defined. For other IBS algorithm, it can be defined in the future. 216 If client and server are sure that each of them knows the global 217 parameters, this data structure can be omitted from transmission. 219 The structure to carry the ECCSI-based global parameters is specified 220 in followng Figure : 222 ECCSIPublicParameters ::= SEQUENCE { 223 version INTEGER { v2(2) }, 224 curve OBJECT IDENTIFIER, 225 hashfcn OBJECT IDENTIFIER, 226 pointP POINT, 227 pointPpub POINT 228 } 230 Figure 3: ECCSI Global Parameters ANSI.1 Structure 232 With above data structure, pointP shall be G in RFC 6507 and 233 pointPpub shall be KPAK in RFC 6507. The POINT structure specifies a 234 point on an elleptic curve and is defined as follows: 236 POINT ::= SEQUENCE { 237 x INTEGER, 238 y INTEGER 239 } 241 Figure 4: POINT Structure ANSI.1 Structure 243 To support IBS algorithm over TLS protocol, a data structure for 244 signature value need to be defined. A data structure for ECCSI is 245 defined as follows(based RFC 6507): 247 ECCSI-Sig-Value ::= SEQUENCE { 248 r INTEGER, 249 s INTEGER, 250 PVT OCTET STRING 251 } 253 Figure 5: ECCSI Signature Value ANSI.1 Structure 255 where PVT (as defined in RFC 6507) is encoded as 0x04 || x-coordinate 256 of [v]G || y-coordinate of [v]G. 258 To use a signature algorithm with TLS, OID for the signature 259 algorithm need be provided. For ECCSI algorithm, an OID has been 260 assigned by IANA recently. The following table shows the basic 261 information needed for the ECCSI signature algorithm to be used for 262 TLS. 264 +------------------------------+---------------+--------------------+ 265 | Key Type | Document | OID | 266 +------------------------------+---------------+--------------------+ 267 | Elliptic Curve-Based | Section 5.2 | 1.3.6.1.5.5.7.6.29 | 268 | Signatureless For Identitiy- | in RFC 6507 | | 269 | based Encryption (ECCSI) | | | 270 +------------------------------+---------------+--------------------+ 272 Table 1: Algorithm Object Identifiers 274 4. New Signature Algorithms for IBS 276 To using identity as raw public key, new signature algorithms 277 corresponding to the IBS need to be defined. With TLS 1.3, the value 278 for signature algorithm is defined in the SignatureScheme. This 279 document specifies how to support ECCSI algorithm. As a reult, the 280 SignatureScheme data structure has to be amended by including the 281 ECCSI algorithm. 283 enum { 284 ... 286 /* IBS ECCSI signature algorithm */ 287 eccsi_sha256 (TBD), 289 /* Reserved Code Points */ 290 private_use (0xFE00..0xFFFF), 291 (0xFFFF) 292 } SignatureScheme; 294 Figure 6: Include ecdhe_eccsi in KeyExchangeAlgorithm 296 Note: The signature algorithm of eccsi_sha256 is defined in RFC6507. 298 Note: Other IBS signature algorithms can be added in the future. 300 5. TLS Client and Server Handshake Behavior 302 When IBS is used as RAW public for TLS, signature and hash algorithms 303 are negotiated during the handshake. 305 The handshake between the TLS client and server follows the 306 procedures defined in [RFC 8446], but with the support of the new 307 signature algorithms specific to the IBS algorithms. The high-level 308 message exchange in the following figure shows TLS handshake using 309 raw public keys, where the client_certificate_type and 310 server_certificate_type extensions added to the client and server 311 hello messages (see Section 4 of [RFC 7250]). 313 client_hello, 314 +key_share 315 +signature_algorithms 316 client_certificate_type, 317 server_certificate_type -> 319 <- server_hello, 320 + key_share 321 {EncryptyedExtensions} 322 {client_certificate_type} 323 {server_certificate_type} 324 {Certificate} 325 {CertificateVerify} 326 {CertificateRequest} 327 {Finished} 328 [Applicaiton Data] 329 {Certificate} 330 {CertificateVerify} 331 {Finished} --------> 332 [Application Data} <-------> [Application Data] 334 Figure 7: Basic Raw Public Key TLS Exchange 336 The client hello messages tells the server the types of certificate 337 or raw public key supported by the client, and also the certificate 338 types that client expects to receive from server. When raw public 339 with IBS algorithm from server is supported by the client, the client 340 includes desired IBS signature algorithm in the client hello message 341 based on the order of client preference. 343 After receiving the client hello message, server determines the 344 client and server certificate types for handshakes. When the 345 selected certificate type is RAW public key and IBS is the chosen 346 signature algorithm, server uses the SubjectPublicKeyInfo structure 347 to carry the raw public key, OID for IBS algorithm. If ECCSI is 348 selected, the ECCSIPublicParameters can be used to carry global 349 public parameters. With these information, the client knows the 350 signature algorithm and the public parameters that should be used to 351 verify the signature. The signature value is in the 352 CertificateVerify message and the format of signature value should be 353 specified by each IBS algorithm. In this document, an ECCSI-Sig- 354 Value data strcuture for ECCSI signature algorithm is defined based 355 on the specification of RFC 6507 357 When sever specifies that RAW public key should be used by client to 358 authenticate with server, the client_certificate_type in the server 359 hello is set to RawPublicKey. Besides that, the server also sends 360 Certificate Request, indicating that client should use some specific 361 signature and hash algorithms. When IBS is chosen as signature 362 algorithm, the server need to indicate the required IBS signature 363 algorithms in the signature_algorithm extension within the 364 CertificateRequest. 366 After receiving the server hello, the client checks the 367 CertificateRequest for signature algorithms. If client wants to use 368 an IBS algorithm for signature, then the signature algorithm it 369 intended to use must be in the list of supported signature algorithms 370 specified by the server. Assume the IBS algorithm supported by the 371 client is in the list, then the client response with the IBS 372 signature algorithm and PKG information with SubjectPublicKeyInfo 373 structure in the certificate structure and provide signatures in the 374 certificate verify message. The format of signature in the 375 CertificateVerify message should be sepcified by each individual 376 signature algorithm. If ECCSI is chosen, an ECCSI-Sig-Value data 377 strcuture is used to carry the signature. 379 The server verifies the signature based on the algorithm and PKG 380 parameters specified by the messages from client. 382 6. Examples 384 In the following, examples of handshake exchange using IBS algorithm 385 under RawPublicKey are illustrated. 387 6.1. TLS Client and Server Use IBS algorithm 389 In this example, both the TLS client and server use ECCSI for 390 authentication, and they are restricted in that they can only process 391 ECCSI signature algorithm. As a result, the TLS client sets both the 392 server_certificate_type and the client_certificate_type extensions to 393 be raw public key; in addition, the client sets the signature 394 algorithm in the client hello message to be eccsi_sha256. 396 When the TLS server receives the client hello, it processes the 397 message. Since it has an ECCSI raw public key from the PKG, it 398 indicates in (2) that it agrees to use ECCSI and provided an ECCSI 399 key by placing the SubjectPublicKeyInfo structure into the 400 Certificate payload back to the client (3), including the OID, the 401 identity of server, ServerID, which is the public key of server also, 402 and PKG public parameters (ECCSIPublicParameters). The 403 client_certificate_type in (4) indicates that the TLS server accepts 404 raw public key. The TLS server demands client authentication, and 405 therefore includes a certificate_request(5), which requires the 406 client to use eccsi_sha256 for signature. A signature value based on 407 the eccsi_sha256 algorithm is carried in the CertificateVerify (6). 408 The client, which has an ECCSI key, returns its ECCSI public key in 409 the Certificate payload to the server (7), which includes an OID for 410 the ECCSI signature algorithm, the PKGInfo for KMS parameters, and 411 identity of client, ClientID, which is the public key of client also. 412 The client also includes a signature value, ECCSI-Sig-Value, in the 413 CertificateVerify (8) message. 415 When client/server receive PKG public parameters from peer, it should 416 decide whether these parameters are acceptable or not. An exmaple 417 way to make decision is that a whitelist of acceptable PKG public 418 parameters are stored locally at client/server. They can simply make 419 a decision based on the white list stored locally. 421 client_hello, 422 +key_share // (1) 423 signature_algorithm = (eccsi_sha256) // (1) 424 client_certificate_type=(RawPublicKey) // (1) 425 server_certificate_type=(RawPublicKey) // (1) 426 -> 427 <- server_hello, 428 + key_share 429 { server_certificate_type = RawPublicKey} // (2) 430 {certificate=((1.3.6.1.5.5.7.6.29, 431 ECCSIPublicParameters), serverID)} //(3) 432 {client_certificate_type = RawPublicKey // (4) 433 {certificate_request = (eccsi_sha256)} //(5) 434 {CertificateVerify = {ECCSI-Sig-Value} // (6) 435 {Finishaed} 437 {Certificate=( 438 (1.3.6.1.5.5.7.6.29, 439 ECCSIPublicParameters), 440 ClientID)} // (7) 441 {CertificatVerify = (ECCSI-Sig-Value)} //(8) 442 {Finished } 443 [Applicateion Data] ----> 444 [Application Data] <---> [Application Data] 446 Figure 8: Basic Raw Public Key TLS Exchange 448 6.2. Combined Usage of Raw Public Keys and X.509 Certificates 450 This example combines the uses of an ECCSI key and an X.509 451 certificate. The TLS client uses an ECCSI key for client 452 authentication, and the TLS server provides an X.509 certificate for 453 server authentication. 455 The exchange starts with the client indicating its ability to process 456 a raw public key, or an X.509 certificate, if provided by the server. 458 It prefers a raw public key, since eccsi_sha256 proceeds 459 ecdsa_secp256r1_sha256 in the signature_algorithm payload, and the 460 RawPublicKey value precedes the other value in the 461 server_certificate_type payload. Furthermore, the client indicates 462 that it has a ECCSI-based raw public key for client-side 463 authentication. Client also indicate it supports server using either 464 ECCSI or ecdsa for the certificate signature. This further indicates 465 that server can also use ecdsa_secp256r1_sha256 to sign the message. 467 With the received client_hello, the server chooses to provide its 468 X.509 certificate in (3) and indicates that choice in (2). For 469 client authentication, the server indicates in (4) that it has 470 selected the raw public key format and requests an ECCSI certificate 471 from the client in (4) and (5). The TLS client provides an ECSSI 472 certificate in (6) and signature value after receiving and processing 473 the TLS server hello message. 475 client_hello, 476 +key_share 477 signature_algorithms =(eccsi_sha256) // (1) 478 signature_algorithms_cert =(eccsi_sha256, 479 ecdsa_secp256r1_sha256) // (1) 480 {client_certificate_type= 481 (RawPublicKey)} // (1) 482 {server_certificate_type= 483 (RawPublicKey, X.509) // (1) 484 -> 485 <- server_hello, 486 +key_share 487 {server_certificate_type=X.509} // (2) 488 {Certificate = (x.509 certificate)} // (3) 489 {client_certificate_type = (RawPublicKey)} // (4) 490 {CertificateRequest} = (eccsi_sha256)} // (5) 491 {CertificateVerify} 492 {Finished} 493 certificate=( 494 (1.3.6.1.5.5.7.6.29, 495 ECCSIPublicParameters), 496 ClientID), // (6) 497 {CertificatVerify = 498 (ECCSI-Sig-Value)} //(7) 499 { Finished } 500 [Applicateion Data] ----> 501 [Application Data] <---> [Application Data] 503 Figure 9: Basic Raw Public Key TLS Exchange 505 7. Security Considerations 507 Using ECCSI-based raw public key in TLS/DTLS does not change the 508 message flows of TLS, hence, for the most part, the security 509 considerations involved in using the Transport Layer Security 510 protocol with raw public key also apply here. The additional 511 security of the resulting protocol rests on the security of the used 512 ECCSI algorithms. 514 ECCSI signature algorithm has been standardized for ten years and has 515 been adopted in real application. However, we would like to point 516 out the difference between ECCSI and existing raw public key: the 517 private key of ECCSI used for signature generation is generated by 518 the Key Management System (KMS), while the private key for the 519 existing raw public key is generated locally. Therefore, ECCSI 520 mechanism may face a security risk of private key disclosure due to 521 improper management of KMS system. The user of ECCSI shall be aware 522 the above risk and a stronger key management system shall be adopted 523 by KMS system when using ECCSI. 525 8. IANA Considerations 527 Existing IANA references have not been updated yet to point to this 528 document. 530 IANA is asked to assign an OID for ECCSI signature algorithm 531 specified in the [RFC6507], which is used by this document. The 532 required OID should be assigned under the registry of SMI Security 533 for PKIX Algorithms (1.3.6.1.5.5.7.6) with following name: 535 - id-alg-eccsi-with-sha256. 537 - an OID has been assigned by IANA to ECCSI as 1.3.6.1.5.5.7.6.29. 539 The following TLS registries shall be updated also: 541 - Signature Scheme Registry: signature algorithm for ECCSI, 542 eccsi_with_sha256, are required to be reserved. 544 9. Acknowledgements 546 10. References 548 10.1. Normative References 550 [PKIX] "Internet X.509 Public Key Infrastructure Certificate and 551 Certificate Revocation List(CRL) Profile", June 2008. 553 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 554 Requirement Levels", BCP 14, RFC 2119, 555 DOI 10.17487/RFC2119, March 1997, 556 . 558 [RFC2434] "Guidelines for Writing an IANA Consideration Section in 559 RFCs", October 1998. 561 [RFC5091] Boyen, X. and L. Martin, "Identity-Based Cryptography 562 Standard (IBCS) #1: Supersingular Curve Implementations of 563 the BF and BB1 Cryptosystems", RFC 5091, 564 DOI 10.17487/RFC5091, December 2007, 565 . 567 [RFC6507] Groves, M., "Elliptic Curve-Based Certificateless 568 Signatures for Identity-Based Encryption (ECCSI)", 569 RFC 6507, DOI 10.17487/RFC6507, February 2012, 570 . 572 [RFC6508] Groves, M., "Sakai-Kasahara Key Encryption (SAKKE)", 573 RFC 6508, DOI 10.17487/RFC6508, February 2012, 574 . 576 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 577 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 578 Transport Layer Security (TLS) and Datagram Transport 579 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 580 June 2014, . 582 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 583 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 584 May 2017, . 586 [RFC8216] Pantos, R., Ed. and W. May, "HTTP Live Streaming", 587 RFC 8216, DOI 10.17487/RFC8216, August 2017, 588 . 590 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 591 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 592 . 594 10.2. Informative References 596 [Defeating-SSL] 597 "New Tricks for Defeating SSL in Practice", Feb 2009, 598 . 602 Appendix A. Examples 604 Authors' Addresses 606 Haiguang Wang (editor) 607 Huawei International Pte. Ltd. 608 11 North Buona Vista Dr, #17-08 609 Singapore 138589 610 SG 612 Phone: +65 6825 4200 613 Email: wang.haiguang1@huawei.com 615 Yanjiang Yang 616 Huawei International Pte. Ltd. 617 11 North Buona Vista Dr, #17-08 618 Singapore 138589 619 SG 621 Phone: +65 6825 4200 622 Email: yang.yanjiang@huawei.com 624 Xin Kang 625 Huawei International Pte. Ltd. 626 11 North Buona Vista Dr, #17-08 627 Singapore 138589 628 SG 630 Phone: +65 6825 4200 631 Email: xin.kang@huawei.com