idnits 2.17.1 draft-wang-tls-raw-public-key-with-ibc-01.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 2 instances of too long lines in the document, the longest one being 32 characters in excess of 72. ** The abstract seems to contain references ([RFC7250]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 27, 2018) is 2124 days in the past. Is this intentional? 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 6507' is mentioned on line 244, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'PKIX' ** 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 Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 2 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: December 29, 2018 Huawei Technology Pte. Ltd. 6 June 27, 2018 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-01 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 cipher 17 suites are extended to support Identity-based signature (IBS). The 18 example OID tables in the RFC 7250 [RFC7250] are expanded with OIDs 19 specific to IBS algorithms. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on December 29, 2018. 38 Copyright Notice 40 Copyright (c) 2018 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 respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Extension of RAW Public Key to IBC-based Identity . . . . . . 4 58 4. New Key Exchange Algorithms and Cipher Suites . . . . . . . . 6 59 5. TLS Client and Server Handshake Behavior . . . . . . . . . . 7 60 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10 61 6.1. TLS Client and Server Use IBS algorithm . . . . . . . . . 10 62 6.2. Combined Usage of Raw Public Keys and X.509 Certificates 11 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 64 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 65 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 66 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 67 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 68 10.2. Informative References . . . . . . . . . . . . . . . . . 13 69 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 14 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 72 1. Introduction 74 DISCLAIMER: This is a personal draft and has not yet seen significant 75 security analysis. 77 Traditionally, TLS client and server exchange public keys endorsed by 78 PKIX [PKIX] certificates. It is considered complicated and may cause 79 security weaknesses with the use of PKIX certificates Defeating-SSL 80 [Defeating-SSL]. To simplify certificates exchange, using RAW public 81 key with TLS/DTLS has been spcified in RFC 7250. That is, instead of 82 transmitting a full certificate or a certificate chain in the TLS 83 messages, only public keys are exchanged between client and server. 84 However, using RAW public key requires out-of-band mechanisms to bind 85 the public key to the entity presenting the key. 87 Recently, 3GPP has adopted the EAP authentication framework for 5G 88 and EAP-TLS is considered as one of the candidate authentication 89 methods for private networks, especially for networks with a large 90 number of IOT devices. For IOT networks, TLS/DTLS with RAW public 91 key is particularly attractive, but binding identities with public 92 keys might be challenging. The cost to maintain a large table for 93 identity and public key mapping at server side incurs additional 94 maintenance cost. e.g. devices have to pre-register to the server. 96 To simplify the binding between the public key and the entity 97 presenting the public key, a better way could be using Identity-Based 98 Cryptography(IBC), such as ECCSI public key specified in RFC 6507, 99 for authentication. Different from X.509 certificates and raw public 100 keys, a public key in IBC takes the form of the entity's identity. 101 This eliminates the necessity of binding between a public key and the 102 entity presenting the public key. 104 The concept of IBC was first proposed by Adi Shamir in 1984. As a 105 special class of public key cryptography, IBC uses a user's identity 106 as public key, avoiding the hassle of public key certification in 107 public key cryptosystems. IBC broadly includes IBE (Identity-based 108 Encryption) and IBS (Identity-based Signature). For an IBC system to 109 work, there exists a trusted third party, PKG (private key generator) 110 responsible for issuing private keys to the users. In particular, 111 the PKG has in possession a pair of Master Public Key and Master 112 Secret Key; a private key is generated based on the user's identity 113 by using the Master Secret key, while the Master Public key is used 114 together with the user's identities for encryption (in case of IBE) 115 and signature verification ( in case of IBS). 117 A number of IBE and IBS algorithms have been standardized by 118 different standardization bodies, such as IETF, IEEE, ISO/IEC, etc. 119 For example, IETF has spcified several RFCs such as RFC 5091 120 [RFC5091], RFC 6507 [RFC6507] and RFC6508 [RFC6508] for both IBE and 121 IBS algorithms. ISO/JTC and IEEE also have a few standards on IBC 122 algorithms. 124 RFC 7250 has specified the use of raw public key with TLS/DTLS 125 handshake. However, supporting of IBS algorithms has not been 126 included therein. Since IBS algorithms are efficient in public key 127 transmission and also eliminate the binding between public keys and 128 identities, in this document, an amendment to RFC 7250 is added for 129 supporting IBS algorithms. 131 IBS algorithm exempts client and server from public key certification 132 and identity binding by checking an entity's signatures and its 133 identity against the master public key of its PKG. With an IBS 134 algorithm, a PKG generates private keys for entities based on their 135 identities. Global parameters such as PKG's Master Public Key (MPK) 136 need be provisioned to both client and server. These parameters are 137 not user specific, but PKG specific. 139 For a client, PKG specific parameters can be provisioned at the time 140 PKG provisions the private key to the client. For the server, how to 141 get the PKG specific parameters provisioned is out of the scope of 142 this document, and it is deployment dependent. 144 The document is organized as follows: Section 3 defines the data 145 structure required when identity is used as raw public key, and a 146 list of OIDs for IBS algorithms. Section 4 defines the cipher suites 147 required to support IBS algorithm over TLS/DTLS. Section 5 explains 148 how client and server authenticate each other when using identity as 149 raw public key. Section 6 gives examples for using identity as raw 150 public key over TLS/DTLS handshake procedure. Section 7 discusses 151 the security considerations. 153 2. Terms 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in RFC 2119 [RFC2119]. 159 3. Extension of RAW Public Key to IBC-based Identity 161 To support the negotiation of using raw public between client and 162 server, a new Certificate structure is defined in RFC 7250. It is 163 used by the client and server in the hello messages to indicate the 164 types of certificates supported by each side. 166 When RawPublicKey type is selected for authentication, a data 167 structure, subjectPublicKeyInfo, is used to carry the raw public key 168 and its cryptographic algorithm. Within the subjectPublicKeyInfo 169 structure, two fields, algorithm and subjectPublicKey, are defined. 170 The algorithm is a data structure specifies the cryptographic 171 algorithm used with raw public key, which is represented by an object 172 Identifiers (OID); and the parameters field provides necessary 173 parameters associated with the algorithm. The subjectPublicKey field 174 within the subjectPublicKeyInfo carry the raw public itself. 176 subjectPublicKeyInfo ::= SEQUENCE { 177 algorithm AlgorithmIdentifier, 178 subjectPublicKey BIT STRING 179 } 181 AlgorithmIdentifier ::= SEQUENCE { 182 algorithm OBJECT IDENTIFIER, 183 parameters ANY DEFINED BY algorithm OPTIONAL 184 } 186 Figure 1: SubjectECCSIPublicKeyInfo ASN.1 Structure 188 When using an IBS algorithm, an identity is used as raw public key, 189 which can be converted to an OCTET string and put into the 190 subjectPublicKey field. The algorithm field in AlgorithmIdentifier 191 structure is the object identifier of the IBS algorithm used. Beside 192 that, it is necessary to tell the peer the set of global parameters 193 used by signer. The information can be carried in the payload of the 194 parameters field in AlgorithmIdentifier. However, the global public 195 parameters can be heavy. Instead of carrying the full set of global 196 public parameters of a PKG, an URI or IRI of a PKG is put in the 197 parameter field. The URI/IRI allows the peer know which set of 198 public parameters shall be used to verify the signature. 200 The structure to carry the PKGInfo is specified in Figure 2: 202 opaque DistinguishedName<1..2^16-1>; 203 struct { 204 DistinguishedName pkg_addr<1..2^16-1>; 205 } PKGInfo; 207 Figure 2: PKGInfo ANSI.1 Structure 209 The pkg_addr field is a string of an URI or IRI of a PKG, indicating 210 the PKG where public parameters of the IBC algorithm identified by 211 the OBJECT IDENTIFIER are available. 213 In RFC 7250, OIDs for IBS algorithms are not included. In this 214 document, a list of OIDs for IBS algorithms are given in the 215 following table. 217 +----------------------+--------------------+-----------------------+ 218 | Key Type | Document | OID | 219 +----------------------+--------------------+-----------------------+ 220 | ISO/IEC 14888-3 | ISO/IEC 14888-3: | 1.0.14888.3.0.7 | 221 | ibs-1 | IBS-1 mechansim | | 222 | | (Identity-Based | | 223 | | Signature) | | 224 +----------------------+--------------------+-----------------------+ 225 | ISO/IEC 14888-3 | ISO/IEC 14888-3: | 1.0.14888.3.0.8 | 226 | ibs-2 | IBS-2 mechansim | | 227 | | (Identity-Based | | 228 | | Signature) | | 229 +----------------------+--------------------+-----------------------+ 230 | SM9-1 Digital | SM9-1 Digital | 1.2.156.10197.1.302.1 | 231 | Signature Algorithm | Signature | | 232 | | Algorithm | | 233 +----------------------+--------------------+-----------------------+ 234 | Elliptic Curve-Based | Section 5.2 in RFC | 1.3.6.1.5.x (need to | 235 | Signatureless For | 6507 | apply) | 236 | Identitiy-based | | | 237 | Encryption (ECCSI) | | | 238 +----------------------+--------------------+-----------------------+ 240 Table 1: Algorithm Object Identifiers 242 In particular, ISO/IEC 14888-3 specifies two IBS algorithms, IBS-1 243 and IBS-2. The ECCSI is an IBS algorithm that is specified in IETF 244 [RFC 6507]. SM9-1 is a Chinese standard for an IBS algorithm. 246 4. New Key Exchange Algorithms and Cipher Suites 248 To support identity as raw public key, new key exchange algorithms 249 corresponding to the IBS algorithms need to be defined. The existing 250 key exchange algorithms making use of ephemeral DH are extended to 251 support of the IBS algorithms. Considering the performance and the 252 compatibility with the use of ECDSA in TLS (see RFC 4492), this 253 specification proposes to support the IBS algorithm, ECCSI, defined 254 in RFC 6507 [RFC6507]. As a reult, the table below summarizes the 255 new key exchange algorithms, which mimic DHE_DSS, ECDHE_ECDSA, 256 respectively (see RFC 5246 and RFC 4492). 258 +-------------------------+---------------------------------------+ 259 | Key Exchange Algorithm | Description | 260 +-------------------------+---------------------------------------+ 261 | ECDHE_ECCSI | Ephemeral ECDH with ECCSI signatures | 262 +-------------------------+---------------------------------------+ 264 Table 2: Algorithm Object Identifiers 266 To include new key exhange algorithm, the data structure 267 KeyExchangeAlgorithm need to be expanded with a new value ecdhe_eccsi 268 as follows: 270 enum { 271 ecdhe_eccsi 272 } KeyExchangeAlgorithm; 274 Figure 3: Include ecdhe_eccsi in KeyExchangeAlgorithm 276 Note: The specification of ECDHE_ECCSI can follow ECHDE_ECDSA by 277 substituting ECDSA with ECCSI. The detailed specification will be 278 provided in the future 280 Note: Other key exchange algorithm with other IBS algorithm may be 281 added in the future. 283 Accordingly, below defines the new cipher suites that use the above 284 new key exchange algorithms: 286 CipherSuite TLS_ECDHE_ECCSI_WITH_AES_128_CBC_SHA256 = { 0xC0, 0x80 } 288 CipherSuite TLS_ECDHE_ECCSI_WITH_AES_256_CBC_SHA256 = { 0xC0, 0x8A } 290 5. TLS Client and Server Handshake Behavior 292 When IBS is used as RAW public for TLS, signature and hash algorithms 293 are negotiated during the handshake. 295 The handshake between the TLS client and server follows the 296 procedures defined in RFC 7250 [RFC7250], but with the support of the 297 new key exchange algorithm and cipher suites specific to the IBS 298 algorithms. The high-level message exchange in the below figure 299 shows TLS handshake using raw public keys, where the 300 client_certificate_type and server_certificate_type extensions added 301 to the client and server hello messages (see Section 4 of RFC 7250). 303 client_hello, 304 client_certificate_type, 305 server_certificate_type -> 307 <- server_hello, 308 client_certificate_type, 309 server_certificate_type, 310 certificate, 311 server_key_exchange, 312 certificate_request, 313 server_hello_done 314 certificate, 315 client_key_exchange, 316 certificate_verify, 317 change_cipher_spec, 318 finished -> 320 <- change_cipher_spec, 321 finished 323 Application Data <-------> Application Data 325 Figure 4: Basic Raw Public Key TLS Exchange 327 The client hello messages tells the server the types of certificate 328 or raw public key supported by the client, and also the certificate 329 types that client expects to receive from server. When raw public 330 with IBS algorithm from server is supported by the client, the client 331 includes desired IBS cipher suites in the client hello message based 332 on the order of client preference. 334 After receiving the client hello message, server determines the 335 client and server certificate types for handshakes. When the 336 selected certificate type is RAW public key and IBS is the chosen 337 signature algorithm, server uses the SubjectPublicKeyInfo structure 338 to carry the raw public key, OID for IBS algorithm and URI/IRI for 339 global public parameters. With these information, the client knows 340 the signature algorithm and the public parameters that should be used 341 to verify the signature. The format of signature in the 342 server_key_exhange message is defined in the corresponding 343 specification. For example, when ECCSI is used, the format of 344 signature is defined in RFC 6507. 346 When sever specifies that RAW public key should be used by client to 347 authenticate with server, the client_certificate_type in the server 348 hello is set to RawPublicKey. Besides that, the server also sends 349 Certificate Request, indicating that client should use some specific 350 signature and hash algorithms. When IBS is chosen as raw public key 351 signature algorithm, the server need to indicate the supporting of 352 IBS signature algorithms in the CertificateRequest. 354 The Certificate Request is a structure defined in TLS1.2 as follows : 356 struct { 357 ClientCertificateType certificate_types<1..2^8-1>; 358 SignatureAndHashAlgorithm supported_signature_algorithms<2^16-1>; 359 DistinguishedName certificate_authorities<0..2^16-1>; 360 } CertificateRequest; 362 Figure 5: ANSI.1 structure for CertificateRequest 364 To support IBS algorithms, values of the ClientCertificateType and 365 SignatureAlgorithm need to be amended. To support ECCSI defined in 366 IETF RFC 6507, eccsi_sign (TBD) type is added to 367 ClientCertificateType as follows: 369 enum { 370 eccsi_sign(TBD), (255) 371 } ClientCertificateType; 373 Figure 6: Value of ECCSI in ClientCertificateType 375 eccsi_sign: the subsequent client certificate is a raw public key 376 certificate containing an ECCSI public key. 378 Moreover, an eccsi(TBD) type needs to be added to the 379 SignatureAlgorithm structure, which is in turn used in the 380 SignatureAndHashAlgorithm structure: 382 enum { 383 eccsi(TBD), (255) 384 } SignatureAlgorithm. 386 Figure 7: Value of ECCSI for SignatureAlgorithm 388 No new hash function type is required. RFC 6507 does not specify any 389 specific hash function to use for ECCSI. As a result, SHA256 390 suffices to instantiate ECCSI. 392 To support more IBS signature algorithms, additional values can be 393 added to the ClientCertificateType and SignatureAlgorithm in the 394 future. 396 If raw public key is selected by server for client authentication, 397 the client checks the CertificateRequest received for signature 398 algorithms. If client wants to use an IBS algorithm for signature, 399 then the signature algorithm it intended to use must be in the list 400 of supported signature algorithms by the server. Assume the IBS 401 algorithm supported by the client is in the list, then the client 402 specifies the IBS signature algorithm and PKG information with 403 SubjectPublicKeyInfo structure in the certificate structure and 404 provide signatures in the certificate verify message. The format of 405 signature in the certificate_verify message is defined in the 406 corresponding specification. 408 The server verifies the signature based on the algorithm and PKG 409 parameters specified by the messages from client. 411 6. Examples 413 In the following, examples of handshake exchange using IBS algorithm 414 under RawPublicKey are illustrated. 416 6.1. TLS Client and Server Use IBS algorithm 418 In this example, both the TLS client and server use ECCSI for 419 authentication, and they are restricted in that they can only process 420 ECCSI keys. As a result, the TLS client sets both the 421 server_certificate_type extension and the client_certificate_type 422 extension to be raw public key; in addition, the client sets the 423 ciphersuites in the client hello message to be 424 TLS_ECDHE_ECCSI_WITH_AES_256_CBC_SHA256. 426 When the TLS server receives the client hello, it processes the 427 message. Since it has an ECCSI raw public key from the PKG, it 428 indicates in (2) that it agrees to use ECCSI and provided an ECCSI 429 key by placing the SubjectPublicKeyInfo structure into the 430 Certificate payload back to the client (3), including the OID and 431 URI/IRI of global public key parameters. The client_certificate_type 432 in (4) indicates that the TLS server accepts raw public key. The TLS 433 server demands client authentication, and therefore includes a 434 certificate_request (5) for ECCSI raw public. The client, which has 435 an ECCSI key, returns its ECCSI certificate in the Certificate 436 payload to the server (6). 438 client_hello, 439 cipher_suites=(TLS_ECDHE_ECCSI_WITH_AES_256_CBC_SHA256) // (1) 440 client_certificate_type=(RawPublicKey) // (1) 441 server_certificate_type=(RawPublicKey) // (1) 442 -> 443 <- server_hello, 444 server_certificate_type= RawPublicKey // (2) 445 certificate=((1.3.6.1.5.x, 446 pkgx.org/1.html), KEY) // (3) 447 client_certificate_type=RawPublicKey // (4) 448 certificate_request= (eccsi_sign, (eccsi, 449 SHA256)), // (5) 450 server_key_exchange, 451 server_hello_done 453 certificate=( 454 (1.3.6.1.5.x, 455 pkgx.org/1.html), 456 KEY), // (6) 457 client_key_exchange, 458 change_cipher_spec, 459 finished -> 461 <- change_cipher_spec, 462 finished 464 Application Data <-------> Application Data 466 Figure 8: Basic Raw Public Key TLS Exchange 468 6.2. Combined Usage of Raw Public Keys and X.509 Certificates 470 This example combines the uses of an ECCSI key and an X.509 471 certificate. The TLS client uses an ECCSI key for client 472 authentication, and the TLS server provides an X.509 certificate for 473 server authentication. 475 The exchange starts with the client indicating its ability to process 476 a raw public key, or an X.509 certificate, if provided by the server. 477 It prefers a raw public key, since 478 TLS_ECDHE_ECSSI_WITH_AES_256_CBC_SHA256 proceeds 479 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA256 in the cipher_suites payload, 480 and the RawPublicKey value precedes the other value in the 481 server_certificate_type payload. Furthermore, the client indicates 482 that it has a raw public key for client-side authentication. 484 The server chooses to provide its X.509 certificate in (3) and 485 indicates that choice in (2). For client authentication, the server 486 indicates in (4) that it has selected the raw public key format and 487 requests an ECCSI certificate from the client in (4) and (5). The 488 TLS client provides an ECSSI certificate in (6) after receiving and 489 processing the TLS server hello message. 491 client_hello, 492 cipher_suites=(TLS_ECDHE_ECSSI_WITH_AES_256_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA256), // (1) 493 client_certificate_type=(RawPublicKey), // (1) 494 server_certificate_type=(RawPublicKey, X.509) // (1) 495 -> 496 <- server_hello, 497 server_certificate_type=X.509, // (2) 498 certificate, // (3) 499 client_certificate_type=RawPublicKey // (4) 500 certificate_request= (eccsi_sign, (eccsi, 501 SHA256)), // (5) 502 server_key_exchange, 503 server_hello_done 504 certificate=(KEY, 505 (1.3.6.1.5.x, 506 pkgx.org/1.html)), // (6) 507 client_key_exchange, 508 change_cipher_spec, 509 finished -> 511 <- change_cipher_spec, 512 finished 514 Application Data <-------> Application Data 516 Figure 9: Basic Raw Public Key TLS Exchange 518 7. Security Considerations 520 Using IBS-enabled raw public key in TLS/DTLS will not change the 521 information flows of TLS, so the security of the resulting protocol 522 rests on the security of the used IBS algorithms. The example IBS 523 algorithms mentioned above are all standardized and open, and thus 524 the security of these algorithms is supposed to have gone through 525 wide scrutinization. 527 8. IANA Considerations 529 9. Acknowledgements 530 10. References 532 10.1. Normative References 534 [PKIX] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 535 Housley, R., and W. Polk, "Internet X.509 Public Key 536 Infrastructure Certificate and Certificate Revocation 537 List(CRL) Profile", June 2008. 539 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 540 Requirement Levels", BCP 14, RFC 2119, 541 DOI 10.17487/RFC2119, March 1997, 542 . 544 [RFC5091] Boyen, X. and L. Martin, "Identity-Based Cryptography 545 Standard (IBCS) #1: Supersingular Curve Implementations of 546 the BF and BB1 Cryptosystems", RFC 5091, 547 DOI 10.17487/RFC5091, December 2007, 548 . 550 [RFC6507] Groves, M., "Elliptic Curve-Based Certificateless 551 Signatures for Identity-Based Encryption (ECCSI)", 552 RFC 6507, DOI 10.17487/RFC6507, February 2012, 553 . 555 [RFC6508] Groves, M., "Sakai-Kasahara Key Encryption (SAKKE)", 556 RFC 6508, DOI 10.17487/RFC6508, February 2012, 557 . 559 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 560 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 561 Transport Layer Security (TLS) and Datagram Transport 562 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 563 June 2014, . 565 10.2. Informative References 567 [Defeating-SSL] 568 Marlinspike, M.,, "New Tricks for Defeating SSL in 569 Practice", Feb 2009, 570 . 574 Appendix A. Examples 576 Authors' Addresses 578 Haiguang Wang (editor) 579 Huawei Technology Pte. Ltd. 580 20 Secience Park Road, #3-30/31 581 Singapore 117687 582 SG 584 Phone: +65 6825 4200 585 Email: wang.haiguang1@huawei.com 587 Yanjiang Yang 588 Huawei Technology Pte. Ltd. 589 20 Secience Park Road, #3-30/31 590 Singapore 117687 591 SG 593 Phone: +65 6825 4200 594 Email: yang.yanjiang@huawei.com 596 Xin Kang 597 Huawei Technology Pte. Ltd. 598 20 Secience Park Road, #3-30/31 599 Singapore 117687 600 SG 602 Phone: +65 6825 4200 603 Email: xin.kang@huawei.com