idnits 2.17.1 draft-wang-tls-raw-public-key-with-ibc-02.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 3 instances of too long lines in the document, the longest one being 15 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 (October 12, 2018) is 2017 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 7250' is mentioned on line 300, but not defined == Missing Reference: 'RFC 6507' is mentioned on line 343, but not defined == Missing Reference: 'RFC 5091' is mentioned on line 119, but not defined == Missing Reference: 'RFC 4492' is mentioned on line 255, but not defined ** Obsolete undefined reference: RFC 4492 (Obsoleted by RFC 8422) == Missing Reference: 'RFC 5246' is mentioned on line 255, but not defined ** Obsolete undefined reference: RFC 5246 (Obsoleted by RFC 8446) == Unused Reference: 'RFC5091' is defined on line 548, but no explicit reference was found in the text == Unused Reference: 'RFC7250' is defined on line 563, but no explicit reference was found in the text -- 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: 7 errors (**), 0 flaws (~~), 8 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: April 15, 2019 Huawei Technology Pte. Ltd. 6 October 12, 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-02 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] are expanded with OIDs specific 19 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 April 15, 2019. 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 . . . . . . . . . . . . . . . . . . . . . 13 65 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 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 82 of 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], [RFC 120 6507] and [RFC6508] for both IBE and IBS algorithms. ISO/JTC and 121 IEEE also have a few standards on IBC algorithms. 123 RFC 7250 has specified the use of raw public key with TLS/DTLS 124 handshake. However, supporting of IBS algorithms has not been 125 included therein. Since IBS algorithms are efficient in public key 126 transmission and also eliminate the binding between public keys and 127 identities, in this document, an amendment to RFC 7250 is added for 128 supporting IBS algorithms. 130 IBS algorithm exempts client and server from public key certification 131 and identity binding by checking an entity's signatures and its 132 identity against the master public key of its PKG. With an IBS 133 algorithm, a PKG generates private keys for entities based on their 134 identities. Global parameters such as PKG's Master Public Key (MPK) 135 need be provisioned to both client and server. These parameters are 136 not user specific, but PKG specific. 138 For a client, PKG specific parameters can be provisioned at the time 139 PKG provisions the private key to the client. For the server, how to 140 get the PKG specific parameters provisioned is out of the scope of 141 this document, and it is deployment dependent. 143 The document is organized as follows: Section 3 defines the data 144 structure required when identity is used as raw public key, and a 145 list of OIDs for IBS algorithms. Section 4 defines the cipher suites 146 required to support IBS algorithm over TLS/DTLS. Section 5 explains 147 how client and server authenticate each other when using identity as 148 raw public key. Section 6 gives examples for using identity as raw 149 public key over TLS/DTLS handshake procedure. Section 7 discusses 150 the security considerations. 152 2. Terms 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in RFC 2119 [RFC2119]. 158 3. Extension of RAW Public Key to IBC-based Identity 160 To support the negotiation of using raw public between client and 161 server, a new Certificate structure is defined in RFC 7250. It is 162 used by the client and server in the hello messages to indicate the 163 types of certificates supported by each side. 165 When RawPublicKey type is selected for authentication, a data 166 structure, subjectPublicKeyInfo, is used to carry the raw public key 167 and its cryptographic algorithm. Within the subjectPublicKeyInfo 168 structure, two fields, algorithm and subjectPublicKey, are defined. 169 The algorithm is a data structure specifies the cryptographic 170 algorithm used with raw public key, which is represented by an object 171 Identifiers (OID); and the parameters field provides necessary 172 parameters associated with the algorithm. The subjectPublicKey field 173 within the subjectPublicKeyInfo carry the raw public itself. 175 subjectPublicKeyInfo ::= SEQUENCE { 176 algorithm AlgorithmIdentifier, 177 subjectPublicKey BIT STRING 178 } 180 AlgorithmIdentifier ::= SEQUENCE { 181 algorithm OBJECT IDENTIFIER, 182 parameters ANY DEFINED BY algorithm OPTIONAL 183 } 185 Figure 1: SubjectECCSIPublicKeyInfo ASN.1 Structure 187 When using an IBS algorithm, an identity is used as the raw public 188 key, which can be converted to an OCTET string and put into the 189 subjectPublicKey field. The algorithm field in AlgorithmIdentifier 190 structure is the object identifier of the IBS algorithm used. Beside 191 that, it is necessary to tell the peer the set of global parameters 192 used by the signer. The information can be carried in the payload of 193 the parameters field in AlgorithmIdentifier. However, the global 194 public parameters can be large. Instead of carrying the full set of 195 global public parameters of a PKG, an URI or IRI of a PKG is put in 196 the parameter field. The URI/IRI allows the peer know which set of 197 public parameters shall be used to verify the signature. 199 The structure to carry the PKGInfo is specified in Figure 2: 201 opaque DistinguishedName<1..2^16-1>; 202 struct { 203 DistinguishedName pkg_addr<1..2^16-1>; 204 } PKGInfo; 206 Figure 2: PKGInfo ANSI.1 Structure 208 The pkg_addr field is a string of an URI or IRI of a PKG, indicating 209 the PKG where public parameters of the IBC algorithm identified by 210 the OBJECT IDENTIFIER are available. 212 In [RFC 7250], OIDs for IBS algorithms are not included. In this 213 document, a list of OIDs for IBS algorithms is given in the following 214 table. 216 +----------------------+--------------------+-----------------------+ 217 | Key Type | Document | OID | 218 +----------------------+--------------------+-----------------------+ 219 | ISO/IEC 14888-3 | ISO/IEC 14888-3: | 1.0.14888.3.0.7 | 220 | ibs-1 | IBS-1 mechansim | | 221 | | (Identity-Based | | 222 | | Signature) | | 223 +----------------------+--------------------+-----------------------+ 224 | ISO/IEC 14888-3 | ISO/IEC 14888-3: | 1.0.14888.3.0.8 | 225 | ibs-2 | IBS-2 mechansim | | 226 | | (Identity-Based | | 227 | | Signature) | | 228 +----------------------+--------------------+-----------------------+ 229 | SM9-1 Digital | SM9-1 Digital | 1.2.156.10197.1.302.1 | 230 | Signature Algorithm | Signature | | 231 | | Algorithm | | 232 +----------------------+--------------------+-----------------------+ 233 | Elliptic Curve-Based | Section 5.2 in RFC | 1.3.6.1.5.x (need to | 234 | Signatureless For | 6507 | apply) | 235 | Identitiy-based | | | 236 | Encryption (ECCSI) | | | 237 +----------------------+--------------------+-----------------------+ 239 Table 1: Algorithm Object Identifiers 241 In particular, ISO/IEC 14888-3 specifies two IBS algorithms, IBS-1 242 and IBS-2. The ECCSI is an IBS algorithm that is specified in IETF 243 [RFC 6507]. SM9-1 is a Chinese standard for an IBS algorithm. 245 4. New Key Exchange Algorithms and Cipher Suites 247 To support using identity as raw public key, new key exchange 248 algorithms corresponding to the IBS algorithms need to be defined. 249 The existing key exchange algorithms making use of ephemeral DH are 250 extended to support IBS algorithms. Considering the performance and 251 the compatibility with the use of ECDSA in TLS (see [RFC 4492]), this 252 specification proposes to support the IBS algorithm, ECCSI, defined 253 in [RFC 6507]. As a reult, the table below summarizes the new key 254 exchange algorithm, which mimics DHE_DSS, ECDHE_ECDSA, respectively 255 (see [RFC 5246] and [RFC 4492]). 257 +-------------------------+---------------------------------------+ 258 | Key Exchange Algorithm | Description | 259 +-------------------------+---------------------------------------+ 260 | ECDHE_ECCSI | Ephemeral ECDH with ECCSI signatures | 261 +-------------------------+---------------------------------------+ 263 Table 2: Algorithm Object Identifiers 265 To include the new key exhange algorithm, the data structure 266 KeyExchangeAlgorithm need to be expanded with a new value ecdhe_eccsi 267 as follows: 269 enum { 270 ecdhe_eccsi 271 } KeyExchangeAlgorithm; 273 Figure 3: Include ecdhe_eccsi in KeyExchangeAlgorithm 275 Note: The specification of ECDHE_ECCSI can follow ECHDE_ECDSA by 276 substituting ECDSA with ECCSI[RFC6507]. The detailed specification 277 will be provided in the future 279 Note: Other key exchange algorithms with other IBS algorithms may be 280 added in the future. 282 Accordingly, below defines new cipher suites that use above new key 283 exchange algorithms: 285 CipherSuite TLS_ECDHE_ECCSI_WITH_AES_128_CBC_SHA256 = { 0xC0, 0x80 } 287 CipherSuite TLS_ECDHE_ECCSI_WITH_AES_256_CBC_SHA256 = { 0xC0, 0x8A } 289 5. TLS Client and Server Handshake Behavior 291 When IBS is used as RAW public for TLS, signature and hash algorithms 292 are negotiated during the handshake. 294 The handshake between the TLS client and server follows the 295 procedures defined in [RFC 7250], but with the support of the new key 296 exchange algorithm and cipher suites specific to the IBS algorithms. 297 The high-level message exchange in the following figure shows TLS 298 handshake using raw public keys, where the client_certificate_type 299 and server_certificate_type extensions added to the client and server 300 hello messages (see Section 4 of [RFC 7250]). 302 client_hello, 303 client_certificate_type, 304 server_certificate_type -> 306 <- server_hello, 307 client_certificate_type, 308 server_certificate_type, 309 certificate, 310 server_key_exchange, 311 certificate_request, 312 server_hello_done 313 certificate, 314 client_key_exchange, 315 certificate_verify, 316 change_cipher_spec, 317 finished -> 319 <- change_cipher_spec, 320 finished 322 Application Data <-------> Application Data 324 Figure 4: Basic Raw Public Key TLS Exchange 326 The client hello messages tells the server the types of certificate 327 or raw public key supported by the client, and also the certificate 328 types that client expects to receive from server. When raw public 329 with IBS algorithm from server is supported by the client, the client 330 includes desired IBS cipher suites in the client hello message based 331 on the order of client preference. 333 After receiving the client hello message, server determines the 334 client and server certificate types for handshakes. When the 335 selected certificate type is RAW public key and IBS is the chosen 336 signature algorithm, server uses the SubjectPublicKeyInfo structure 337 to carry the raw public key, OID for IBS algorithm and URI/IRI for 338 global public parameters. With these information, the client knows 339 the signature algorithm and the public parameters that should be used 340 to verify the signature. The format of signature in the 341 server_key_exhange message is defined in the corresponding 342 specification. For example, when ECCSI is used, the format of 343 signature is defined in [RFC 6507]. 345 When sever specifies that RAW public key should be used by client to 346 authenticate with server, the client_certificate_type in the server 347 hello is set to RawPublicKey. Besides that, the server also sends 348 Certificate Request, indicating that client should use some specific 349 signature and hash algorithms. When IBS is chosen as raw public key 350 signature algorithm, the server need to indicate the supporting of 351 IBS signature algorithms in the CertificateRequest. 353 The Certificate Request is a structure defined in TLS1.2 as follows : 355 struct { 356 ClientCertificateType certificate_types<1..2^8-1>; 357 SignatureAndHashAlgorithm supported_signature_algorithms<2^16-1>; 358 DistinguishedName certificate_authorities<0..2^16-1>; 359 } CertificateRequest; 361 Figure 5: ANSI.1 structure for CertificateRequest 363 To support IBS algorithms, values of the ClientCertificateType and 364 SignatureAlgorithm need to be amended. To support ECCSI defined in 365 IETF RFC 6507, eccsi_sign (TBD) type is added to 366 ClientCertificateType as follows: 368 enum { 369 eccsi_sign(TBD), (255) 370 } ClientCertificateType; 372 Figure 6: Value of ECCSI in ClientCertificateType 374 eccsi_sign: the subsequent client certificate is a raw public key 375 certificate containing an ECCSI public key. 377 Moreover, an eccsi(TBD) type needs to be added to the 378 SignatureAlgorithm structure, which is in turn used in the 379 SignatureAndHashAlgorithm structure: 381 enum { 382 eccsi(TBD), (255) 383 } SignatureAlgorithm. 385 Figure 7: Value of ECCSI for SignatureAlgorithm 387 No new hash function type is required. RFC 6507 does not specify any 388 specific hash function to use for ECCSI. As a result, SHA256 389 suffices to instantiate ECCSI. 391 To support more IBS signature algorithms, additional values can be 392 added to the ClientCertificateType and SignatureAlgorithm in the 393 future. 395 If raw public key is selected by server for client authentication, 396 the client checks the CertificateRequest received for signature 397 algorithms. If client wants to use an IBS algorithm for signature, 398 then the signature algorithm it intended to use must be in the list 399 of supported signature algorithms by the server. Assume the IBS 400 algorithm supported by the client is in the list, then the client 401 specifies the IBS signature algorithm and PKG information with 402 SubjectPublicKeyInfo structure in the certificate structure and 403 provide signatures in the certificate verify message. The format of 404 signature in the certificate_verify message is defined in the 405 corresponding specification. 407 The server verifies the signature based on the algorithm and PKG 408 parameters specified by the messages from client. 410 6. Examples 412 In the following, examples of handshake exchange using IBS algorithm 413 under RawPublicKey are illustrated. 415 6.1. TLS Client and Server Use IBS algorithm 417 In this example, both the TLS client and server use ECCSI for 418 authentication, and they are restricted in that they can only process 419 ECCSI keys. As a result, the TLS client sets both the 420 server_certificate_type extension and the client_certificate_type 421 extension to be raw public key; in addition, the client sets the 422 ciphersuites in the client hello message to be 423 TLS_ECDHE_ECCSI_WITH_AES_256_CBC_SHA256. 425 When the TLS server receives the client hello, it processes the 426 message. Since it has an ECCSI raw public key from the PKG, it 427 indicates in (2) that it agrees to use ECCSI and provided an ECCSI 428 key by placing the SubjectPublicKeyInfo structure into the 429 Certificate payload back to the client (3), including the OID and 430 URI/IRI of global public key parameters. The client_certificate_type 431 in (4) indicates that the TLS server accepts raw public key. The TLS 432 server demands client authentication, and therefore includes a 433 certificate_request (5) for ECCSI raw public. The client, which has 434 an ECCSI key, returns its ECCSI certificate in the Certificate 435 payload to the server (6). 437 client_hello, 438 cipher_suites=(TLS_ECDHE_ECCSI_WITH_AES_256_CBC_SHA256) // (1) 439 client_certificate_type=(RawPublicKey) // (1) 440 server_certificate_type=(RawPublicKey) // (1) 441 -> 442 <- server_hello, 443 server_certificate_type= RawPublicKey // (2) 444 certificate=((1.3.6.1.5.x, 445 pkgx.org/1.html), KEY) // (3) 446 client_certificate_type=RawPublicKey // (4) 447 certificate_request= (eccsi_sign, (eccsi, 448 SHA256)), // (5) 449 server_key_exchange, 450 server_hello_done 452 certificate=( 453 (1.3.6.1.5.x, 454 pkgx.org/1.html), 455 KEY), // (6) 456 client_key_exchange, 457 change_cipher_spec, 458 finished -> 460 <- change_cipher_spec, 461 finished 463 Application Data <-------> Application Data 465 Figure 8: Basic Raw Public Key TLS Exchange 467 6.2. Combined Usage of Raw Public Keys and X.509 Certificates 469 This example combines the uses of an ECCSI key and an X.509 470 certificate. The TLS client uses an ECCSI key for client 471 authentication, and the TLS server provides an X.509 certificate for 472 server authentication. 474 The exchange starts with the client indicating its ability to process 475 a raw public key, or an X.509 certificate, if provided by the server. 476 It prefers a raw public key, since 477 TLS_ECDHE_ECSSI_WITH_AES_256_CBC_SHA256 proceeds 478 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA256 in the cipher_suites payload, 479 and the RawPublicKey value precedes the other value in the 480 server_certificate_type payload. Furthermore, the client indicates 481 that it has a raw public key for client-side authentication. 483 The server chooses to provide its X.509 certificate in (3) and 484 indicates that choice in (2). For client authentication, the server 485 indicates in (4) that it has selected the raw public key format and 486 requests an ECCSI certificate from the client in (4) and (5). The 487 TLS client provides an ECSSI certificate in (6) after receiving and 488 processing the TLS server hello message. 490 client_hello, 491 cipher_suites=( 492 TLS_ECDHE_ECSSI_WITH_AES_256_CBC_SHA256, 493 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA256), // (1) 494 client_certificate_type=(RawPublicKey), // (1) 495 server_certificate_type= 496 (RawPublicKey, X.509) // (1) 497 -> 498 <- server_hello, 499 server_certificate_type=X.509, // (2) 500 certificate, // (3) 501 client_certificate_type = 502 RawPublicKey // (4) 503 certificate_request= (eccsi_sign, 504 (eccsi, SHA256)), // (5) 505 server_key_exchange, 506 server_hello_done 507 certificate=(KEY, 508 (1.3.6.1.5.x, 509 pkgx.org/1.html)), // (6) 510 client_key_exchange, 511 change_cipher_spec, 512 finished -> 514 <- change_cipher_spec, 515 finished 517 Application Data <-------> Application Data 519 Figure 9: Basic Raw Public Key TLS Exchange 521 7. Security Considerations 523 Using IBS-enabled raw public key in TLS/DTLS will not change the 524 information flows of TLS, so the security of the resulting protocol 525 rests on the security of the used IBS algorithms. The example IBS 526 algorithms mentioned above are all standardized and open, and thus 527 the security of these algorithms is supposed to have gone through 528 wide scrutinization. 530 8. IANA Considerations 532 9. Acknowledgements 534 10. References 536 10.1. Normative References 538 [PKIX] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 539 Housley, R., and W. Polk, "Internet X.509 Public Key 540 Infrastructure Certificate and Certificate Revocation 541 List(CRL) Profile", June 2008. 543 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 544 Requirement Levels", BCP 14, RFC 2119, 545 DOI 10.17487/RFC2119, March 1997, 546 . 548 [RFC5091] Boyen, X. and L. Martin, "Identity-Based Cryptography 549 Standard (IBCS) #1: Supersingular Curve Implementations of 550 the BF and BB1 Cryptosystems", RFC 5091, 551 DOI 10.17487/RFC5091, December 2007, 552 . 554 [RFC6507] Groves, M., "Elliptic Curve-Based Certificateless 555 Signatures for Identity-Based Encryption (ECCSI)", 556 RFC 6507, DOI 10.17487/RFC6507, February 2012, 557 . 559 [RFC6508] Groves, M., "Sakai-Kasahara Key Encryption (SAKKE)", 560 RFC 6508, DOI 10.17487/RFC6508, February 2012, 561 . 563 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 564 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 565 Transport Layer Security (TLS) and Datagram Transport 566 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 567 June 2014, . 569 10.2. Informative References 571 [Defeating-SSL] 572 Marlinspike, M.,, "New Tricks for Defeating SSL in 573 Practice", Feb 2009, 574 . 578 Appendix A. Examples 580 Authors' Addresses 582 Haiguang Wang (editor) 583 Huawei Technology Pte. Ltd. 584 20 Secience Park Road, #3-30/31 585 Singapore 117687 586 SG 588 Phone: +65 6825 4200 589 Email: wang.haiguang1@huawei.com 591 Yanjiang Yang 592 Huawei Technology Pte. Ltd. 593 20 Secience Park Road, #3-30/31 594 Singapore 117687 595 SG 597 Phone: +65 6825 4200 598 Email: yang.yanjiang@huawei.com 600 Xin Kang 601 Huawei Technology Pte. Ltd. 602 20 Secience Park Road, #3-30/31 603 Singapore 117687 604 SG 606 Phone: +65 6825 4200 607 Email: xin.kang@huawei.com