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-04

The information below is for an old version of the document
Document Type Active Internet-Draft (individual)
Last updated 2019-01-16 (latest revision 2018-12-26)
Stream (None)
Intended RFC status (None)
Formats pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Internet Engineering Task Force                             H. Wang, Ed.
Internet-Draft                                                   Y. Yang
Intended status: Standards Track                                 X. Kang
Expires: July 20, 2019                    Huawei International Pte. Ltd.
                                                        January 16, 2019

 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-04

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
   signature algorithms are extended to support Identity-based signature
   (IBS).  A typical Identity-based signature algorithm, the ECCSI
   signature algorithm defined in RFC 6507, is supported in the current
   version.

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 July 20, 2019.

Copyright Notice

   Copyright (c) 2019 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

Wang, et al.              Expires July 20, 2019                 [Page 1]
Internet-Draft           TLS-RAW-Public-Key-IBC             January 2019

   to this document.  Code Components extracted from this document must
   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 Signature Algorithms for IBS  . . . . . . . . . . . . . .   6
   5.  TLS Client and Server Handshake Behavior  . . . . . . . . . .   6
   6.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
     6.1.  TLS Client and Server Use IBS algorithm . . . . . . . . .   8
     6.2.  Combined Usage of Raw Public Keys and X.509 Certificates   10
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   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] and has been
   included in the TLS 1.3[RFC 8446].  With RAW public key, 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 July 20, 2019                 [Page 2]
Internet-Draft           TLS-RAW-Public-Key-IBC             January 2019

   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 July 20, 2019                 [Page 3]
Internet-Draft           TLS-RAW-Public-Key-IBC             January 2019

   The document is organized as follows: Section 3 defines the data
   structure required when identity is used as raw public key.
   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 BIT string and put into the
   subjectPublicKey field.  The algorithm field in Algorithm Identifier
   structure is the object identifier of the IBS algorithm used.  Beside
   that, it is necessary to tell the peer the set of global parameters

Wang, et al.              Expires July 20, 2019                 [Page 4]
Internet-Draft           TLS-RAW-Public-Key-IBC             January 2019

   used by the signer.  The information can be carried in the payload of
   the parameters field in AlgorithmIdentifier.  In the following, a
   data structure for carrying ECCSI-based parameters are defined.  For
   other IBS algorithm, It can be defined in the future.

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

       ECCSIPublicParameters ::= SEQUENCE {
                     version  INTEGER { v2(2) },
                     curve  OBJECT IDENTIFIER,
                     hashfcn OBJECT IDENTIFIER,
                     pointP  POINT,
                     pointPpub POINT
       }

                    Figure 2: PKGInfo ANSI.1 Structure

   pointP shall be G in RFC 6507 and pointPpub shall be KPAK in RFC
   6507.  The POINT structure specifies a point on an elleptic curve.
   The POINT strcture is defined as follows:

       POINT ::= SEQUENCE {
           x INTEGER,
           y INTEGER
       }

                         Figure 3: POINT Structure

   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 support IBS algorithm over TLS protocol, a data structure for
   signature value need to be defined.  A data structure for ECCSI is
   defined as follows(based RFC 6507):

       ECCSI-Sig-Value ::= SEQUENCE {
           r INTEGER,
           s INTEGER,
           PVT OCTET STRING
       }

                 Figure 4: ECCSI Signature Value Structure

   where PVT (as defined in RFC 6507) is encoded as 0x04 || x-coordinate
   of [v]G || y-coordinate of [v]G.

Wang, et al.              Expires July 20, 2019                 [Page 5]
Internet-Draft           TLS-RAW-Public-Key-IBC             January 2019

   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 Signature Algorithms for IBS

   To support using identity as raw public key, new signature algorithms
   corresponding to the IBS need to be defined.  With TLS 1.3, the value
   for signature algorithm is defined in the SignatureScheme.  This
   document proposes to support the IBS algorithm, ECCSI, defined in
   [RFC 6507].  As a reult, the SignatureScheme data structure is
   amended by add in the support for ECCSI algorithm.

       enum {
               ...

           /* IBS ECCSI signature algorithm */
               eccsi_sha256 (TBD),

           /* Reserved Code Points */
           private_use (0xFE00..0xFFFF),
           (0xFFFF)
       } SignatureScheme;

           Figure 5: Include ecdhe_eccsi in KeyExchangeAlgorithm

   Note: The signature algorithm of eccsi_sha256 is defined in RFC6507.

   Note: Other IBS signature algorithms can be added in the future.

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.

Wang, et al.              Expires July 20, 2019                 [Page 6]
Internet-Draft           TLS-RAW-Public-Key-IBC             January 2019

   The handshake between the TLS client and server follows the
   procedures defined in [RFC 8446], but with the support of the new
   signature algorithms specific to the IBS algorithms.  The high-level
   message exchange in the following figure shows TLS 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,
           + key_share
           + signature_algorithms
       client_certificate_type,
       server_certificate_type   ->

                                 <-  server_hello,
                                     + key_share
                                     {EncryptyedExtensions}
                                     {client_certificate_type}
                                     {server_certificate_type}
                                     {Certificate}
                                     {CertificateVerify}
                                     {CertificateRequest}
                                     {Finished}
                                     [Applicaiton Data]
       {Certificate}
       {CertificateVerify}
       {Finished}          -------->
       [Application Data}  <-------> [Application Data]

                Figure 6: 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
   ECCSIPublicParameters 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
   signature value is in the CertificateVerify message and the format of
   signature value should be specified by each IBS algorithm.  In this

Wang, et al.              Expires July 20, 2019                 [Page 7]
Internet-Draft           TLS-RAW-Public-Key-IBC             January 2019

   document, an ECCSI-Sig-Value data strcuture for ECCSI signature
   algorithm is defined based on the specification of RFC 6507

   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 signature
   algorithm, the server need to indicate the required IBS signature
   algorithms in the signature_algorithm extension within the
   CertificateRequest.

   To support more IBS signature algorithms, additional values can be
   added to the SignatureAlgorithm data structure 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 CertificateVerify message should be sepcified by
   each individual signature algorithm.  In this document, an ECCSI-Sig-
   Value data strcuture for ECCSI signature algorithm is defined based
   on the specification of RFC 6507.

   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
   signature algorithm in the client hello message to be eccsi_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

Wang, et al.              Expires July 20, 2019                 [Page 8]
Internet-Draft           TLS-RAW-Public-Key-IBC             January 2019

   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, the
   identity of server, ServerID, which is the public key of server also,
   and PKG public parameters (ECCSIPublicParameters).  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), which requires the
   client to use eccsi_sha256 for signature.  A signature value based on
   the eccsi_sha256 algorithm is carried in the CertificateVerify (6).
   The ECCSI-Sig-Value is defined in this document according to the
   specification in the RFC 6507.  The client, which has an ECCSI key,
   returns its ECCSI certificate in the Certificate payload to the
   server (7), which includes an OID for the ECCSI signature algorithm,
   the PKGInfo for KMS parameters, and identity of client, ClientID,
   which is the public key of client also.  The client also includes a
   signature value, ECCSI-Sig-Value, in the CertificateVerify (8)
   message, .

   When client/server receive PKG public parameters from peer, it should
   decide whether these parameters are acceptable or not.  An exmaple
   way to make decision is that a whitelist of acceptable PKG public
   parameters are stored locally at client/server.  They can simply make
   a decision based on the white list stored locally.

Wang, et al.              Expires July 20, 2019                 [Page 9]
Internet-Draft           TLS-RAW-Public-Key-IBC             January 2019

client_hello,
+ key_share // (1)
signature_algorithm = (eccsi_sha256)   // (1)
client_certificate_type=(RawPublicKey) // (1)
server_certificate_type=(RawPublicKey) // (1)
                         ->
                         <- server_hello,
                            + key_share
                            { server_certificate_type = RawPublicKey} // (2)
                            {certificate=((1.3.6.1.5.x,
                             ECCSIPublicParameters), serverID)} //(3)
                            {client_certificate_type = RawPublicKey // (4)
                            {certificate_request = (eccsi_sha256)} //(5)
                            {CertificateVerify = {ECCSI-Sig-Value} // (6)
                            {Finishaed}

{Certificate=(
 (1.3.6.1.5.x,
  ECCSIPublicParameters),
  ClientID)} // (7)
{CertificatVerify = (ECCSI-Sig-Value)} //(8)
{Finished }
[Applicateion Data] ---->
[Application Data]  <--->   [Application Data]

                Figure 7: 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 eccsi_sha256 proceeds
   ecdsa_secp256r1_sha256 in the signature_algorithm 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
   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) and signature value
   after receiving and processing the TLS server hello message.

Wang, et al.              Expires July 20, 2019                [Page 10]
Internet-Draft           TLS-RAW-Public-Key-IBC             January 2019

client_hello,
+ key_share
  signature_algorithms =(eccsi_sha256,
   ecdsa_sepc256r1_sha256)}   // (1)
  {client_certificate_type=
  (RawPublicKey)}             // (1)
  {server_certificate_type=
  (RawPublicKey, X.509)       // (1)
                      ->
                      <-  server_hello,
                          +key_share
                          {server_certificate_type=X.509} // (2)
                          {Certificate = (x.509 certificate)} // (3)
                          {client_certificate_type = (RawPublicKey)} // (4)
                          {CertificateRequest} = (eccsi_sha256)} // (5)
                          {CertificateVerify}
                          {Finished}
certificate=(
(1.3.6.1.5.x,
 ECCSIPublicParameters),
 ClientID), // (6)
{CertificatVerify =
  (ECCSI-Sig-Value)} //(8)
{ Finished }
[Applicateion Data] ---->
[Application Data]  <---> [Application Data]

                Figure 8: 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.

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

Wang, et al.              Expires July 20, 2019                [Page 11]
Internet-Draft           TLS-RAW-Public-Key-IBC             January 2019

   yet.  Therefore, an OID should be assigned to the ECCSI signature
   algorithm.

   The following TLS registries shall be updated also:

   - Signature Scheme Registry: signature algorithm for ECCSI are
   required to be addded.  Future values are allocated via Standards
   Action [RFC8216]

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.

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

Wang, et al.              Expires July 20, 2019                [Page 12]
Internet-Draft           TLS-RAW-Public-Key-IBC             January 2019

   [RFC8216]  Pantos, R., Ed. and W. May, "HTTP Live Streaming",
              RFC 8216, DOI 10.17487/RFC8216, August 2017,
              <https://www.rfc-editor.org/info/rfc8216>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

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

   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

Wang, et al.              Expires July 20, 2019                [Page 13]
Internet-Draft           TLS-RAW-Public-Key-IBC             January 2019

   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 July 20, 2019                [Page 14]