Skip to main content

Using Identity as Raw Public Key in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
draft-wang-tls-raw-public-key-with-ibc-03

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Haiguang Wang , Yanjiang Yang , Xin Kang
Last updated 2018-12-26
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-wang-tls-raw-public-key-with-ibc-03
Internet Engineering Task Force                             H. Wang, Ed.
Internet-Draft                                                   Y. Yang
Intended status: Standards Track                                 X. Kang
Expires: June 29, 2019                    Huawei International Pte. Ltd.
                                                       December 26, 2018

 Using Identity as Raw Public Key in Transport Layer Security (TLS) and
                Datagram Transport Layer Security (DTLS)
               draft-wang-tls-raw-public-key-with-ibc-03

Abstract

   This document specifies the use of identity as a raw public key in
   Transport Layer Security (TLS) and Datagram Transport Layer Security
   (DTLS).  The TLS protocol procedures are kept unchanged, but cipher
   suites are extended to support Identity-based signature (IBS).  The
   example OID tables in the [RFC 7250] are expanded with OIDs specific
   to IBS algorithms.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on June 29, 2019.

Copyright Notice

   Copyright (c) 2018 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.  Code Components extracted from this document must

Wang, et al.              Expires June 29, 2019                 [Page 1]
Internet-Draft           TLS-RAW-Public-Key-IBC            December 2018

   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Extension of RAW Public Key to IBC-based Public Key . . . . .   4
   4.  New Key Exchange Algorithms and Cipher Suites . . . . . . . .   5
   5.  TLS Client and Server Handshake Behavior  . . . . . . . . . .   6
   6.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .   9
     6.1.  TLS Client and Server Use IBS algorithm . . . . . . . . .   9
     6.2.  Combined Usage of Raw Public Keys and X.509 Certificates   10
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  12
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  12
     10.2.  Informative References . . . . . . . . . . . . . . . . .  13
   Appendix A.  Examples . . . . . . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   DISCLAIMER: This is a personal draft and has not yet seen significant
   security analysis.

   Traditionally, TLS client and server exchange public keys endorsed by
   PKIX [PKIX] certificates.  It is considered complicated and may cause
   security weaknesses with the use of PKIX certificates Defeating-SSL
   [Defeating-SSL].  To simplify certificates exchange, using RAW public
   key with TLS/DTLS has been spcified in [RFC 7250].  That is, instead
   of transmitting a full certificate or a certificate chain in the TLS
   messages, only public keys are exchanged between client and server.
   However, using RAW public key requires out-of-band mechanisms to bind
   the public key to the entity presenting the key.

   Recently, 3GPP has adopted the EAP authentication framework for 5G
   and EAP-TLS is considered as one of the candidate authentication
   methods for private networks, especially for networks with a large
   number of IoT devices.  For IoT networks, TLS/DTLS with RAW public
   key is particularly attractive, but binding identities with public
   keys might be challenging.  The cost to maintain a large table for
   identity and public key mapping at server side incurs additional
   maintenance cost.  e.g. devices have to pre-register to the server.

Wang, et al.              Expires June 29, 2019                 [Page 2]
Internet-Draft           TLS-RAW-Public-Key-IBC            December 2018

   To simplify the binding between the public key and the entity
   presenting the public key, a better way could be using Identity-Based
   Cryptography(IBC), such as ECCSI public key specified in [RFC 6507],
   for authentication.  Different from X.509 certificates and raw public
   keys, a public key in IBC takes the form of the entity's identity.
   This eliminates the necessity of binding between a public key and the
   entity presenting the public key.

   The concept of IBC was first proposed by Adi Shamir in 1984.  As a
   special class of public key cryptography, IBC uses a user's identity
   as public key, avoiding the hassle of public key certification in
   public key cryptosystems.  IBC broadly includes IBE (Identity-based
   Encryption) and IBS (Identity-based Signature).  For an IBC system to
   work, there exists a trusted third party, PKG (private key generator)
   responsible for issuing private keys to the users.  In particular,
   the PKG has in possession a pair of Master Public Key and Master
   Secret Key; a private key is generated based on the user's identity
   by using the Master Secret key, while the Master Public key is used
   together with the user's identities for encryption (in case of IBE)
   and signature verification ( in case of IBS).

   A number of IBE and IBS algorithms have been standardized by
   different standardization bodies, such as IETF, IEEE, ISO/IEC, etc.
   For example, IETF has spcified several RFCs such as [RFC 5091], [RFC
   6507] and [RFC6508] for both IBE and IBS algorithms.  ISO/JTC and
   IEEE also have a few standards on IBC algorithms.

   RFC 7250 has specified the use of raw public key with TLS/DTLS
   handshake.  However, supporting of IBS algorithms has not been
   included therein.  Since IBS algorithms are efficient in public key
   transmission and also eliminate the binding between public keys and
   identities, in this document, an amendment to RFC 7250 is added for
   supporting IBS algorithms.

   IBS algorithm exempts client and server from public key certification
   and identity binding by checking an entity's signatures and its
   identity against the master public key of its PKG.  With an IBS
   algorithm, a PKG generates private keys for entities based on their
   identities.  Global parameters such as PKG's Master Public Key (MPK)
   need be provisioned to both client and server.  These parameters are
   not user specific, but PKG specific.

   For a client, PKG specific parameters can be provisioned at the time
   PKG provisions the private key to the client.  For the server, how to
   get the PKG specific parameters provisioned is out of the scope of
   this document, and it is deployment dependent.

Wang, et al.              Expires June 29, 2019                 [Page 3]
Internet-Draft           TLS-RAW-Public-Key-IBC            December 2018

   The document is organized as follows: Section 3 defines the data
   structure required when identity is used as raw public key, and a
   list of OIDs for IBS algorithms.  Section 4 defines the cipher suites
   required to support IBS algorithm over TLS/DTLS.  Section 5 explains
   how client and server authenticate each other when using identity as
   raw public key.  Section 6 gives examples for using identity as raw
   public key over TLS/DTLS handshake procedure.  Section 7 discusses
   the security considerations.

2.  Terms

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

3.  Extension of RAW Public Key to IBC-based Public Key

   To support the negotiation of using raw public between client and
   server, a new Certificate structure is defined in RFC 7250.  It is
   used by the client and server in the hello messages to indicate the
   types of certificates supported by each side.

   When RawPublicKey type is selected for authentication, a data
   structure, subjectPublicKeyInfo, is used to carry the raw public key
   and its cryptographic algorithm.  Within the subjectPublicKeyInfo
   structure, two fields, algorithm and subjectPublicKey, are defined.
   The algorithm is a data structure specifies the cryptographic
   algorithm used with raw public key, which is represented by an object
   Identifiers (OID); and the parameters field provides necessary
   parameters associated with the algorithm.  The subjectPublicKey field
   within the subjectPublicKeyInfo carry the raw public itself.

       subjectPublicKeyInfo  ::=  SEQUENCE  {
                algorithm                  AlgorithmIdentifier,
                subjectPublicKey           BIT STRING
           }

       AlgorithmIdentifier   ::=  SEQUENCE  {
            algorithm               OBJECT IDENTIFIER,
            parameters              ANY DEFINED BY algorithm OPTIONAL
           }

            Figure 1: SubjectECCSIPublicKeyInfo ASN.1 Structure

   When using an IBS algorithm, an identity is used as the raw public
   key, which can be converted to an OCTET string and put into the
   subjectPublicKey field.  The algorithm field in Algorithm Identifier
   structure is the object identifier of the IBS algorithm used.  Beside

Wang, et al.              Expires June 29, 2019                 [Page 4]
Internet-Draft           TLS-RAW-Public-Key-IBC            December 2018

   that, it is necessary to tell the peer the set of global parameters
   used by the signer.  The information can be carried in the payload of
   the parameters field in AlgorithmIdentifier.  However, the global
   public parameters can be large.  Instead of carrying the full set of
   global public parameters of a PKG, an URI or IRI of a PKG is put in
   the parameter field.  The URI/IRI allows the peer know which set of
   public parameters shall be used to verify the signature.

   The structure to carry the PKGInfo is specified in Figure 2:

       opaque DistinguishedName<1..2^16-1>;
       struct {
          DistinguishedName pkg_addr<1..2^16-1>;
       } PKGInfo;

                    Figure 2: PKGInfo ANSI.1 Structure

   The pkg_addr field is a string of an URI or IRI of a PKG, indicating
   the PKG where public parameters of the IBC algorithm identified by
   the OBJECT IDENTIFIER are available.

   When using an IBS algorithm, an identity is used as raw public key,
   which can be converted to an OCTET string.  Therefore, the
   Certificate and subjectPublicKey structure can be reused without
   changes.

   To use a signature algorithm with TLS, OID for the signature need to
   be provided.  However, no OID for for the IBS algorithm specified in
   RFC 6507 has been given.  Thus, OID should be allocated to the ECCSI
   algorithm specified in [RFC 6507] before it can be used for TLS.  The
   following table shows the basic information needed for the ECCSI
   signature algorithm to be used for TLS.

   +-----------------------------------+--------------+----------------+
   |              Key Type             |   Document   |      OID       |
   +-----------------------------------+--------------+----------------+
   |        Elliptic Curve-Based       | Section 5.2  |  1.3.6.1.5.x   |
   | Signatureless For Identitiy-based | in RFC 6507  |    (need to    |
   |         Encryption (ECCSI)        |              |     apply)     |
   +-----------------------------------+--------------+----------------+

                   Table 1: Algorithm Object Identifiers

4.  New Key Exchange Algorithms and Cipher Suites

   To support using identity as raw public key, new key exchange
   algorithms corresponding to the IBS algorithms need to be defined.
   The existing key exchange algorithms making use of ephemeral DH are

Wang, et al.              Expires June 29, 2019                 [Page 5]
Internet-Draft           TLS-RAW-Public-Key-IBC            December 2018

   extended to support IBS algorithms.  Considering the performance and
   the compatibility with the use of ECDSA in TLS (see [RFC 4492]), this
   specification proposes to support the IBS algorithm, ECCSI, defined
   in [RFC 6507].  As a reult, the table below summarizes the new key
   exchange algorithm, which mimics DHE_DSS, ECDHE_ECDSA, respectively
   (see [RFC 5246] and [RFC 4492]).

    +-------------------------+---------------------------------------+
    |  Key Exchange Algorithm |              Description              |
    +-------------------------+---------------------------------------+
    |       ECDHE_ECCSI       |  Ephemeral ECDH with ECCSI signatures |
    +-------------------------+---------------------------------------+

                   Table 2: Algorithm Object Identifiers

   To include the new key exhange algorithm, the data structure
   KeyExchangeAlgorithm need to be expanded with a new value ecdhe_eccsi
   as follows:

       enum {
               ecdhe_eccsi
       } KeyExchangeAlgorithm;

           Figure 3: Include ecdhe_eccsi in KeyExchangeAlgorithm

   Note: The specification of ECDHE_ECCSI can follow ECHDE_ECDSA by
   substituting ECDSA with ECCSI[RFC6507].  The detailed specification
   will be provided in the future

   Note: Other key exchange algorithms with other IBS algorithms may be
   added in the future.

   Accordingly, below defines new cipher suites that use above new key
   exchange algorithms:

   CipherSuite TLS_ECDHE_ECCSI_WITH_AES_128_CBC_SHA256 = { TBD, TBD }

   CipherSuite TLS_ECDHE_ECCSI_WITH_AES_256_CBC_SHA256 = { TBD, TBD }

5.  TLS Client and Server Handshake Behavior

   When IBS is used as RAW public for TLS, signature and hash algorithms
   are negotiated during the handshake.

   The handshake between the TLS client and server follows the
   procedures defined in [RFC 7250], but with the support of the new key
   exchange algorithm and cipher suites specific to the IBS algorithms.
   The high-level message exchange in the following figure shows TLS

Wang, et al.              Expires June 29, 2019                 [Page 6]
Internet-Draft           TLS-RAW-Public-Key-IBC            December 2018

   handshake using raw public keys, where the client_certificate_type
   and server_certificate_type extensions added to the client and server
   hello messages (see Section 4 of [RFC 7250]).

       client_hello,
       client_certificate_type,
       server_certificate_type   ->

                                 <-  server_hello,
                                     client_certificate_type,
                                     server_certificate_type,
                                     certificate,
                                     server_key_exchange,
                                     certificate_request,
                                     server_hello_done
       certificate,
       client_key_exchange,
       certificate_verify,
       change_cipher_spec,
       finished                  ->

                                 <- change_cipher_spec,
                                    finished

      Application Data        <------->     Application Data

                Figure 4: Basic Raw Public Key TLS Exchange

   The client hello messages tells the server the types of certificate
   or raw public key supported by the client, and also the certificate
   types that client expects to receive from server.  When raw public
   with IBS algorithm from server is supported by the client, the client
   includes desired IBS cipher suites in the client hello message based
   on the order of client preference.

   After receiving the client hello message, server determines the
   client and server certificate types for handshakes.  When the
   selected certificate type is RAW public key and IBS is the chosen
   signature algorithm, server uses the SubjectPublicKeyInfo structure
   to carry the raw public key, OID for IBS algorithm and URI/IRI for
   global public parameters.  With these information, the client knows
   the signature algorithm and the public parameters that should be used
   to verify the signature.  The format of signature in the
   server_key_exhange message is defined in the corresponding
   specification.  For example, when ECCSI is used, the format of
   signature is defined in [RFC 6507].

Wang, et al.              Expires June 29, 2019                 [Page 7]
Internet-Draft           TLS-RAW-Public-Key-IBC            December 2018

   When sever specifies that RAW public key should be used by client to
   authenticate with server, the client_certificate_type in the server
   hello is set to RawPublicKey.  Besides that, the server also sends
   Certificate Request, indicating that client should use some specific
   signature and hash algorithms.  When IBS is chosen as raw public key
   signature algorithm, the server need to indicate the supporting of
   IBS signature algorithms in the CertificateRequest.

   The Certificate Request is a structure defined in TLS1.2 as follows :

     struct {
         ClientCertificateType certificate_types<1..2^8-1>;
         SignatureAndHashAlgorithm supported_signature_algorithms<2^16-1>;
         DistinguishedName certificate_authorities<0..2^16-1>;
      } CertificateRequest;

             Figure 5: ANSI.1 structure for CertificateRequest

   To support IBS algorithms, values of the ClientCertificateType and
   SignatureAlgorithm need to be amended.  To support ECCSI defined in
   IETF RFC 6507, eccsi_sign type is added to ClientCertificateType as
   follows:

        enum {
            eccsi_sign, (255)
         } ClientCertificateType;

             Figure 6: Value of ECCSI in ClientCertificateType

   eccsi_sign: the subsequent client certificate is a raw public key
   certificate containing an ECCSI public key.

   Moreover, an eccsi type needs to be added to the SignatureAlgorithm
   structure, which is in turn used in the SignatureAndHashAlgorithm
   structure:

        enum {
                eccsi, (255)
        } SignatureAlgorithm.

              Figure 7: Value of ECCSI for SignatureAlgorithm

   No new hash function type is required.  RFC 6507 does not specify any
   specific hash function to use for ECCSI.  As a result, SHA256
   suffices to instantiate ECCSI.

Wang, et al.              Expires June 29, 2019                 [Page 8]
Internet-Draft           TLS-RAW-Public-Key-IBC            December 2018

   To support more IBS signature algorithms, additional values can be
   added to the ClientCertificateType and SignatureAlgorithm in the
   future.

   If raw public key is selected by server for client authentication,
   the client checks the CertificateRequest received for signature
   algorithms.  If client wants to use an IBS algorithm for signature,
   then the signature algorithm it intended to use must be in the list
   of supported signature algorithms by the server.  Assume the IBS
   algorithm supported by the client is in the list, then the client
   specifies the IBS signature algorithm and PKG information with
   SubjectPublicKeyInfo structure in the certificate structure and
   provide signatures in the certificate verify message.  The format of
   signature in the certificate_verify message is defined in the
   corresponding specification.

   The server verifies the signature based on the algorithm and PKG
   parameters specified by the messages from client.

6.  Examples

   In the following, examples of handshake exchange using IBS algorithm
   under RawPublicKey are illustrated.

6.1.  TLS Client and Server Use IBS algorithm

   In this example, both the TLS client and server use ECCSI for
   authentication, and they are restricted in that they can only process
   ECCSI keys.  As a result, the TLS client sets both the
   server_certificate_type extension and the client_certificate_type
   extension to be raw public key; in addition, the client sets the
   ciphersuites in the client hello message to be
   TLS_ECDHE_ECCSI_WITH_AES_256_CBC_SHA256.

   When the TLS server receives the client hello, it processes the
   message.  Since it has an ECCSI raw public key from the PKG, it
   indicates in (2) that it agrees to use ECCSI and provided an ECCSI
   key by placing the SubjectPublicKeyInfo structure into the
   Certificate payload back to the client (3), including the OID and
   URI/IRI of global public key parameters.  The client_certificate_type
   in (4) indicates that the TLS server accepts raw public key.  The TLS
   server demands client authentication, and therefore includes a
   certificate_request (5) for ECCSI raw public.  The client, which has
   an ECCSI key, returns its ECCSI certificate in the Certificate
   payload to the server (6).

Wang, et al.              Expires June 29, 2019                 [Page 9]
Internet-Draft           TLS-RAW-Public-Key-IBC            December 2018

client_hello,
cipher_suites=(TLS_ECDHE_ECCSI_WITH_AES_256_CBC_SHA256) // (1)
client_certificate_type=(RawPublicKey) // (1)
server_certificate_type=(RawPublicKey) // (1)
                         ->
                         <- server_hello,
                            server_certificate_type= RawPublicKey // (2)
                            certificate=((1.3.6.1.5.x,
                                         pkgx.org/1.html), KEY) // (3)
                            client_certificate_type=RawPublicKey // (4)
                            certificate_request= (eccsi_sign, (eccsi,
                                            SHA256)), // (5)
                             server_key_exchange,
                             server_hello_done

certificate=(
   (1.3.6.1.5.x,
   pkgx.org/1.html),
   KEY), // (6)
client_key_exchange,
change_cipher_spec,
finished                  ->

                         <- change_cipher_spec,
                            finished

Application Data        <------->     Application Data

                Figure 8: Basic Raw Public Key TLS Exchange

6.2.  Combined Usage of Raw Public Keys and X.509 Certificates

   This example combines the uses of an ECCSI key and an X.509
   certificate.  The TLS client uses an ECCSI key for client
   authentication, and the TLS server provides an X.509 certificate for
   server authentication.

   The exchange starts with the client indicating its ability to process
   a raw public key, or an X.509 certificate, if provided by the server.
   It prefers a raw public key, since
   TLS_ECDHE_ECSSI_WITH_AES_256_CBC_SHA256 proceeds
   TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA256 in the cipher_suites payload,
   and the RawPublicKey value precedes the other value in the
   server_certificate_type payload.  Furthermore, the client indicates
   that it has a raw public key for client-side authentication.

   The server chooses to provide its X.509 certificate in (3) and
   indicates that choice in (2).  For client authentication, the server

Wang, et al.              Expires June 29, 2019                [Page 10]
Internet-Draft           TLS-RAW-Public-Key-IBC            December 2018

   indicates in (4) that it has selected the raw public key format and
   requests an ECCSI certificate from the client in (4) and (5).  The
   TLS client provides an ECSSI certificate in (6) after receiving and
   processing the TLS server hello message.

 client_hello,
 cipher_suites=(
 TLS_ECDHE_ECSSI_WITH_AES_256_CBC_SHA256,
 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA256), // (1)
 client_certificate_type=(RawPublicKey), // (1)
 server_certificate_type=
                    (RawPublicKey, X.509) // (1)
                       ->
                       <-  server_hello,
                           server_certificate_type=X.509, // (2)
                           certificate, // (3)
                           client_certificate_type = RawPublicKey // (4)
                           certificate_request= (eccsi_sign, (eccsi,
                                                        SHA256)), // (5)
                              server_key_exchange,
                              server_hello_done
 certificate=(KEY,
    (1.3.6.1.5.x,
    pkgx.org/1.html)), // (6)
 client_key_exchange,
 change_cipher_spec,
 finished                  ->

                           <- change_cipher_spec,
                              finished

 Application Data        <------->     Application Data

                Figure 9: Basic Raw Public Key TLS Exchange

7.  Security Considerations

   Using IBS-enabled raw public key in TLS/DTLS will not change the
   information flows of TLS, so the security of the resulting protocol
   rests on the security of the used IBS algorithms.  The example IBS
   algorithms mentioned above are all standardized and open, and thus
   the security of these algorithms is supposed to have gone through
   wide scrutinization.

Wang, et al.              Expires June 29, 2019                [Page 11]
Internet-Draft           TLS-RAW-Public-Key-IBC            December 2018

8.  IANA Considerations

   Existing IANA references have not been updated yet to point to this
   document.

   With TLS protocol, an OID is required to identify the signature
   algorithm used by client or server.  For example, the RSA signature
   algorithm used in the TLS is identified by 1.2.840.113549.1.1 (Page 5
   of RFC 7250).  However, the ECCSI signature algorithm specified in
   the RFC 6507 and used in this document has not been assigned an OID
   yet.  Therefore, an OID should be assigned to the ECCSI signature
   algorithm.

   The following TLS registries shall be updated also:

   - TLS Cipher Suite Registry: Future values with the first byte in the
   range 0-191 (decimal) inclusive are assigned via Standards Action
   [RFC2434].  Values with the first byte in the range 192-254 (decimal)
   are assigned via Specification Required [RFC2434].  Values with the
   first byte 255 (decimal) are reserved for Private Use [RFC2434].

   - TLS KeyExchangeAlgorithm Registry: Future values are allocated via
   Standards Action [RFC2434]

   - TLS ClientCertificateType Registry: Future values are allocated via
   Standards Action [RFC2434]

   - TLS SignatureAlgorithm Registry: Future values are allocated via
   Standards Action [RFC2434]

9.  Acknowledgements

10.  References

10.1.  Normative References

   [PKIX]     Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation
              List(CRL) Profile", June 2008.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC2434]  Narten, D., Alvestrand, H., "Guidelines for Writing an
              IANA Consideration Section in RFCs", October 1998.

Wang, et al.              Expires June 29, 2019                [Page 12]
Internet-Draft           TLS-RAW-Public-Key-IBC            December 2018

   [RFC5091]  Boyen, X. and L. Martin, "Identity-Based Cryptography
              Standard (IBCS) #1: Supersingular Curve Implementations of
              the BF and BB1 Cryptosystems", RFC 5091,
              DOI 10.17487/RFC5091, December 2007,
              <https://www.rfc-editor.org/info/rfc5091>.

   [RFC6507]  Groves, M., "Elliptic Curve-Based Certificateless
              Signatures for Identity-Based Encryption (ECCSI)",
              RFC 6507, DOI 10.17487/RFC6507, February 2012,
              <https://www.rfc-editor.org/info/rfc6507>.

   [RFC6508]  Groves, M., "Sakai-Kasahara Key Encryption (SAKKE)",
              RFC 6508, DOI 10.17487/RFC6508, February 2012,
              <https://www.rfc-editor.org/info/rfc6508>.

   [RFC7250]  Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
              Weiler, S., and T. Kivinen, "Using Raw Public Keys in
              Transport Layer Security (TLS) and Datagram Transport
              Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
              June 2014, <https://www.rfc-editor.org/info/rfc7250>.

10.2.  Informative References

   [Defeating-SSL]
              Marlinspike, M.,, "New Tricks for Defeating SSL in
              Practice", Feb 2009,
              <http://www.blackhat.com/presentations/bh-dc-
              09/Marlinspike/
              BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf>.

Appendix A.  Examples

Authors' Addresses

   Haiguang Wang (editor)
   Huawei International Pte. Ltd.
   11 North Buona Vista Dr, #17-08
   Singapore  138589
   SG

   Phone: +65 6825 4200
   Email: wang.haiguang1@huawei.com

Wang, et al.              Expires June 29, 2019                [Page 13]
Internet-Draft           TLS-RAW-Public-Key-IBC            December 2018

   Yanjiang Yang
   Huawei International Pte. Ltd.
   11 North Buona Vista Dr, #17-08
   Singapore  138589
   SG

   Phone: +65 6825 4200
   Email: yang.yanjiang@huawei.com

   Xin Kang
   Huawei International Pte. Ltd.
   11 North Buona Vista Dr, #17-08
   Singapore  138589
   SG

   Phone: +65 6825 4200
   Email: xin.kang@huawei.com

Wang, et al.              Expires June 29, 2019                [Page 14]