<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="exp" docName="draft-msahli-ise-ieee1609-07" indexInclude="true" ipr="trust200902" number="8902" prepTime="2020-09-30T11:33:00" scripts="Common,Latin" sortRefs="true" submissionType="independent" symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en">
  <link href="https://datatracker.ietf.org/doc/draft-msahli-ise-ieee1609-07" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc8902" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="IEEE and ETSI Certificate Types for TLS">TLS Authentication Using Intelligent Transport System (ITS) Certificates</title>
    <seriesInfo name="RFC" value="8902" stream="independent"/>
    <author fullname="Mounira Msahli" initials="M" role="editor" surname="Msahli">
      <organization showOnFrontPage="true">Telecom Paris</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <code/>
          <country>France</country>
        </postal>
        <email>mounira.msahli@telecom-paris.fr</email>
      </address>
    </author>
    <author fullname="Nancy Cam-Winget" initials="N" role="editor" surname="Cam-Winget">
      <organization showOnFrontPage="true">Cisco</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <code/>
          <country>United States of America</country>
        </postal>
        <email>ncamwing@cisco.com</email>
      </address>
    </author>
    <author fullname="William Whyte" initials="W" role="editor" surname="Whyte">
      <organization showOnFrontPage="true">Qualcomm</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <code/>
          <country>United States of America</country>
        </postal>
        <email>wwhyte@qti.qualcomm.com</email>
      </address>
    </author>
    <author fullname="Ahmed Serhrouchni" initials="A" surname="Serhrouchni">
      <organization showOnFrontPage="true">Telecom Paris</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <code/>
          <country>France</country>
        </postal>
        <email>ahmed.serhrouchni@telecom-paris.fr</email>
      </address>
    </author>
    <author fullname="Houda Labiod" initials="H" surname="Labiod">
      <organization showOnFrontPage="true">Telecom Paris</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <code/>
          <country>France</country>
        </postal>
        <email>houda.labiod@telecom-paris.fr</email>
      </address>
    </author>
    <date month="09" year="2020"/>
    <workgroup/>
    <keyword>TLS</keyword>
    <keyword>Intelligent Transport System (ITS) Certificates</keyword>
    <keyword>IEEE</keyword>
    <keyword>ETSI</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">
  
  The IEEE and ETSI have specified a type of end-entity certificate. This document defines an experimental change to TLS to support IEEE/ETSI certificate types to authenticate TLS entities. </t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for examination, experimental implementation, and
            evaluation.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document defines an Experimental Protocol for the Internet
            community.  This is a contribution to the RFC Series,
            independently of any other RFC stream.  The RFC Editor has chosen to publish this
            document at its discretion and makes no statement about its value
            for implementation or deployment.  Documents approved for publication
            by the RFC Editor are not candidates for any level of Internet
            Standard; see Section 2 of RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc8902" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2020 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) 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.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2">
              <li pn="section-toc.1-1.1.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-experiment-overview">Experiment Overview</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-terminology">Requirements Terminology</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-extension-overview">Extension Overview</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-tls-client-and-server-hands">TLS Client and Server Handshake</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-client-hello">Client Hello</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-server-hello">Server Hello</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-certificate-verification">Certificate Verification</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-examples">Examples</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
              <li pn="section-toc.1-1.6.2.1">
                <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-tls-server-and-tls-client-u">TLS Server and TLS Client Use the ITS Certificate</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.2">
                <t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-tls-client-uses-the-its-cer">TLS Client Uses the ITS Certificate and TLS Server Uses the X.509 Certificate</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-securely-obtaining-certific">Securely Obtaining Certificates from an Online Repository</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.2">
                <t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-expiry-of-certificates">Expiry of Certificates</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.3">
                <t indent="0" pn="section-toc.1-1.7.2.3.1"><xref derivedContent="7.3" format="counter" sectionFormat="of" target="section-7.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-algorithms-and-cryptographi">Algorithms and Cryptographic Strength</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.4">
                <t indent="0" pn="section-toc.1-1.7.2.4.1"><xref derivedContent="7.4" format="counter" sectionFormat="of" target="section-7.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-interpreting-its-certificat">Interpreting ITS Certificate Permissions</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.5">
                <t indent="0" pn="section-toc.1-1.7.2.5.1"><xref derivedContent="7.5" format="counter" sectionFormat="of" target="section-7.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-psid-and-pdufunctionaltype-">Psid and Pdufunctionaltype in CertificateVerify</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-privacy-considerations">Privacy Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.12">
            <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">The TLS protocol <xref target="RFC8446" format="default" sectionFormat="of" derivedContent="RFC8446"/> allows the use of X.509
      certificates and raw public keys to authenticate servers and
      clients. This document describes an experimental extension following the
      procedures laid out by <xref target="RFC7250" format="default" sectionFormat="of" derivedContent="RFC7250"/> to support use of the certificate
      format specified by the IEEE in <xref target="IEEE1609.2" format="default" sectionFormat="of" derivedContent="IEEE1609.2"/> and profiled by the
      European Telecommunications Standards Institute (ETSI) in <xref target="TS103097" format="default" sectionFormat="of" derivedContent="TS103097"/>. These standards specify secure communications in
      vehicular environments. These certificates are referred to in this
      document as Intelligent Transport Systems (ITS) Certificates.</t>
      <t indent="0" pn="section-1-2">The certificate types are optimized for bandwidth and processing time
      to support delay-sensitive applications and also to provide both
      authentication and authorization information to enable fast access
      control decisions in ad hoc networks found in Intelligent
      Transport Systems (ITS). The standards specify different types of
      certificates to support a full Public Key Infrastructure (PKI)
      specification; the certificates to be used in this context are
      end-entity certificates, i.e., certificates that have the IEEE 1609.2
      appPermissions field present.</t>
      <t indent="0" pn="section-1-3">Use of ITS certificates is becoming widespread in the ITS
      setting. ITS communications, in practice, make heavy use of 10 MHz
      channels with a typical throughput of 6 Mbps. (The 802.11OCB modulation
      that gives this throughput is not the one that gives the highest
      throughput, but it provides for a robust signal over a range up to
      300-500 m, which is the "sweet spot" communications range for ITS
      operations like collision avoidance). The compact nature of ITS
      certificates as opposed to X.509 certificates makes them appropriate for
      this setting. </t>
      <t indent="0" pn="section-1-4">The ITS certificates are also suited to the machine-to-machine (M2M)
      ad hoc network setting because their direct encoding of permissions (see
      <xref target="ITS-permissions" format="default" sectionFormat="of" derivedContent="Section 7.4"/>) allows a receiver to make an immediate
      accept/deny decision about an incoming message without having to refer
      to a remote identity and access management server. The EU has committed
      to the use of ITS certificates in Cooperative Intelligent Transport
      Systems deployments. A multi-year project developed a certificate policy
      for the use of ITS certificates, including a specification of how
      different root certificates can be trusted across the system (hosted at
      &lt;<eref target="https://ec.europa.eu/transport/themes/its/c-its_en" brackets="none"/>&gt;,
      direct link at &lt;<eref target="https://ec.europa.eu/transport/sites/transport/files/c-its_certificate_policy_release_1.pdf" brackets="none"/>&gt;).</t>
      <t indent="0" pn="section-1-5"> The EU has committed funding for the first five years of operation
      of the top-level Trust List Manager entity, enabling organizations such
      as motor vehicle original equipment manufacturers (OEMs) and national
      road authorities to create root certificate authorities (CAs) and have
      them trusted. In the US, the US Department of Transportation (USDOT)
      published a proposed regulation, active as of late 2019 though not
      rapidly progressing, requiring all light vehicles in the US to implement
      vehicle-to-everything (V2X) communications, including the use of ITS
      certificates (available at &lt;<eref target="https://www.federalregister.gov/documents/2017/01/12/2016-31059/federal-motor-vehicle-safety-standards-v2v-communications" brackets="none"/>&gt;). As
      of 2019, ITS deployments across the US, Europe, and Australia were using
      ITS certificates. Volkswagen has committed to deploying V2X using ITS
      certificates. New York, Tampa, and Wyoming are deploying traffic
      management systems using ITS certificates. GM deployed V2X in the
      Cadillac CTS, using ITS certificates.</t>
      <t indent="0" pn="section-1-6"> ITS certificates are also used in a number of standards that build
      on top of the foundational IEEE and ETSI standards, particularly the
      Society of Automobile Engineers (SAE) J2945/x series of standards for
      applications and ISO 21177 <xref target="ISO21177" format="default" sectionFormat="of" derivedContent="ISO21177"/>, which builds a framework for exchanging
      multiple authentication tokens on top of the TLS variant specified in
      this document.

</t>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-1.1">
        <name slugifiedName="name-experiment-overview">Experiment Overview</name>
        <t indent="0" pn="section-1.1-1">This document describes an experimental extension to the TLS
        security model. It uses a form of certificate that has not previously
        been used in the Internet.  Systems using this Experimental approach
        are segregated from systems using standard TLS by the use of a new
        certificate type value, reserved through IANA (see <xref target="IANA" format="default" sectionFormat="of" derivedContent="Section 9"/>).  An implementation of TLS that is not involved in
        the Experiment will not recognize this new certificate type and will
        not participate in the experiment; TLS sessions will either negotiate
        the use of existing X.509 certificates or fail to be established. </t>
        <t indent="0" pn="section-1.1-2">This extension has been encouraged by stakeholders in the
        Cooperative ITS community in order to support ITS use-case
        deployment, and it is anticipated that its use will be widespread. </t>
      </section>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-requirements-terminology">Requirements Terminology</name>
      <t indent="0" pn="section-2-1">
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> 
    when, and only when, they appear in all capitals, as shown here.
      </t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-extension-overview">Extension Overview</name>
      <t indent="0" pn="section-3-1"> The TLS extensions "client_certificate_type" and
      "server_certificate_type" <xref target="RFC7250" format="default" sectionFormat="of" derivedContent="RFC7250"/> are used to negotiate
      the type of Certificate messages used in TLS to authenticate the server
      and, optionally, the client. Using separate extensions allows for mixed
      deployments where the client and server can use certificates of different types. It is expected that ITS
 deployments will see both peers using ITS certificates due to the homogeneity of the ecosystem, but there is no barrier at a technical level that prevents mixed certificate usage. This document defines a new certificate type, 1609Dot2, for usage with
TLS 1.3. The updated CertificateType enumeration and corresponding addition to the CertificateEntry structure are shown below. CertificateType values are sent in the "server_certificate_type" and "client_certificate_type" extensions, and the CertificateEntry
 structures are included in the certificate chain sent in the Certificate message.
	 	 
	In the case of TLS 1.3, the "client_certificate_type" <bcp14>SHALL</bcp14> contain a list of supported certificate types proposed by the client as provided in the figure below:
	 


      </t>
      <sourcecode markers="false" pn="section-3-2">
  /* Managed by IANA */
   enum {
       X509(0),
       RawPublicKey(2),
       1609Dot2(3),
       (255)
   } CertificateType;

   struct {
       select (certificate_type) {

           /* certificate type defined in this document.*/
            case 1609Dot2:
            opaque cert_data&lt;1..2^24-1&gt;;

            /* RawPublicKey defined in RFC 7250*/
           case RawPublicKey:
           opaque ASN.1_subjectPublicKeyInfo&lt;1..2^24-1&gt;;

           /* X.509 certificate defined in RFC 8446*/
           case X.509:
           opaque cert_data&lt;1..2^24-1&gt;;

            };

          Extension extensions&lt;0..2^16-1&gt;;
      } CertificateEntry;
</sourcecode>
      <t indent="0" pn="section-3-3"> As per <xref target="RFC7250" format="default" sectionFormat="of" derivedContent="RFC7250"/>, the server processes the received
      [endpoint]_certificate_type extension(s) and selects one of the offered
      certificate types, returning the negotiated value in its
      EncryptedExtensions (TLS 1.3) message. Note that there is no requirement
      for the negotiated value to be the same in client_certificate_type and
      server_certificate_type extensions sent in the same message.</t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-tls-client-and-server-hands">TLS Client and Server Handshake</name>
      <t indent="0" pn="section-4-1"><xref target="msg_flow" format="default" sectionFormat="of" derivedContent="Figure 1"/> shows the handshake message flow for a full TLS 1.3 handshake negotiating both certificate types.
      </t>
      <figure anchor="msg_flow" align="left" suppress-title="false" pn="figure-1">
        <name slugifiedName="name-message-flow-with-certifica">Message Flow with Certificate Type Extension for Full TLS 1.3 Handshake</name>
        <artwork name="" type="" align="left" alt="" pn="section-4-2.1">
  Client                                           Server

Key  ^ ClientHello
Exch | + server_certificate_type*
     | + client_certificate_type*
     | + key_share*
     v + signature_algorithms*       --------&gt;
                                                ServerHello  ^ Key
                                               + key_share*  v Exch
                                      {EncryptedExtensions}  ^ Server
                                 {+ server_certificate_type*}| Params
                                 {+ client_certificate_type*}|
                                      {CertificateRequest*}  v
                                             {Certificate*}  ^
                                       {CertificateVerify*}  | Auth
                                                 {Finished}  v
                              &lt;-------  [Application Data*]
     ^ {Certificate*}
Auth | {CertificateVerify*}
     v {Finished}             --------&gt;
       [Application Data]     &lt;-------&gt;  [Application Data]		
              +  Indicates noteworthy extensions sent in the
                 previously noted message.

              *  Indicates optional or situation-dependent
                 messages/extensions that are not always sent.

              {} Indicates messages protected using keys
                 derived from a [sender]_handshake_traffic_secret.

              [] Indicates messages protected using keys
                 derived from [sender]_application_traffic_secret_N.		 
</artwork>
      </figure>
      <t indent="0" pn="section-4-3"> In the case of TLS 1.3, in order to negotiate the support of ITS
      certificate-based authentication, clients and servers include the
      extension of type "client_certificate_type" and
      "server_certificate_type" in the extended Client Hello and
      "EncryptedExtensions".</t>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-4.1">
        <name slugifiedName="name-client-hello">Client Hello</name>
        <t indent="0" pn="section-4.1-1">In order to indicate the support of ITS certificates, a client
        <bcp14>MUST</bcp14> include an extension of type
        "client_certificate_type" or "server_certificate_type" in the extended
        Client Hello message as described in <xref target="RFC8446" sectionFormat="of" section="4.1.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8446#section-4.1.2" derivedContent="RFC8446"/> (TLS 1.3).</t>
        <t indent="0" pn="section-4.1-2">For TLS 1.3, the rules for when the Client Certificate and
        CertificateVerify messages appear are as follows:
  
        </t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.1-3">
          <li pn="section-4.1-3.1">The client's Certificate message is present if and only if
          the server sent a CertificateRequest message.</li>
          <li pn="section-4.1-3.2">The client's CertificateVerify message is present if and only if the client's Certificate message is present and contains a non-empty certificate_list.</li>
        </ul>
        <t indent="0" pn="section-4.1-4"> For maximum compatibility, all implementations
        <bcp14>SHOULD</bcp14> be prepared to handle "potentially" extraneous
        certificates and arbitrary orderings from any TLS version, with the
        exception of the end-entity certificate, which <bcp14>MUST</bcp14> be
        first. </t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-4.2">
        <name slugifiedName="name-server-hello">Server Hello</name>
        <t indent="0" pn="section-4.2-1"> When the server receives the Client Hello containing the client_certificate_type extension and/or the server_certificate_type extension, the following scenarios are possible:
	
        </t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.2-2">
          <li pn="section-4.2-2.1">If both the client and server indicate support for the ITS
          certificate type, the server <bcp14>MAY</bcp14> select the first
          (most preferred) certificate type from the client's list that is
          supported by both peers.</li>
          <li pn="section-4.2-2.2">The server does not support any of the proposed certificate
          types and terminates the session with a fatal alert of type
          "unsupported_certificate".</li>
          <li pn="section-4.2-2.3">The server supports the certificate types specified in this
          document. In this case, it <bcp14>MAY</bcp14> respond with a
          certificate of this type. It <bcp14>MAY</bcp14> also include the
          client_certificate_type extension in Encrypted Extension.  Then, the
          server requests a certificate from the client (via the
          CertificateRequest message).</li>
        </ul>
        <t indent="0" pn="section-4.2-3">The certificates in the TLS client or server certificate chain
        <bcp14>MAY</bcp14> be sent as part of the handshake,
        <bcp14>MAY</bcp14> be obtained from an online repository, or
        might already be known to and cached at the endpoint.  If the
        handshake does not contain all the certificates in the chain, and the
        endpoint cannot access the repository and does not already know the
        certificates from the chain, then it <bcp14>SHALL</bcp14> reject the
        other endpoint's certificate and close the connection. Protocols to
        support retrieving certificates from a repository are specified in
        ETSI <xref target="TS102941" format="default" sectionFormat="of" derivedContent="TS102941"/>.</t>
      </section>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-certificate-verification">Certificate Verification</name>
      <t indent="0" pn="section-5-1">Verification of an ITS certificate or certificate chain is described in
  section 5.1 of <xref target="IEEE1609.2" format="default" sectionFormat="of" derivedContent="IEEE1609.2"/>. In the case of
  TLS 1.3, and when the certificate_type is 1609.2, the CertificateVerify
  contents and processing are different than for the CertificateVerify message
  specified for other values of certificate_type in <xref target="RFC8446" format="default" sectionFormat="of" derivedContent="RFC8446"/>. In this case, the CertificateVerify message contains an
  Ieee1609Dot2Data encoded with Canonical Octet Encoding Rules (OER)
  <xref target="ITU-TX.696" format="default" sectionFormat="of" derivedContent="ITU-TX.696"/>
  of type signed as specified in <xref target="IEEE1609.2" format="default" sectionFormat="of" derivedContent="IEEE1609.2"/> and <xref target="IEEE1609.2b" format="default" sectionFormat="of" derivedContent="IEEE1609.2b"/>, where:

</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5-2">
        <li pn="section-5-2.1">payload contains an extDataHash containing the SHA-256 hash of
        the data that the signature is calculated over. This is identical to the
        data that the signature is calculated over in standard TLS, which
        is reproduced below for clarity.</li>
        <li pn="section-5-2.2">headerInfo.psid indicates the application
        activity that the certificate is authorizing.</li>
        <li pn="section-5-2.3">headerInfo.generationTime is the time at which the data structure was generated.</li>
        <li pn="section-5-2.4">headerInfo.pduFunctionalType (as specified in <xref target="IEEE1609.2b" format="default" sectionFormat="of" derivedContent="IEEE1609.2b"/>)
        is present and is set equal to tlsHandshake (1).</li>
      </ul>
      <t indent="0" pn="section-5-3">

   All other fields in the headerInfo are omitted. The certificate
   appPermissions field <bcp14>SHALL</bcp14> be present and
   <bcp14>SHALL</bcp14> permit (as defined in <xref target="IEEE1609.2" format="default" sectionFormat="of" derivedContent="IEEE1609.2"/>)
   signing of PDUs with the PSID indicated in the HeaderInfo of the
   SignedData. If the application specification for that PSID requires Service
   Specific Permissions (SSP) for signing a pduFunctionalType of tlsHandshake,
   this SSP <bcp14>SHALL</bcp14> also be present. For more details on the use
   of PSID and SSP, see <xref target="IEEE1609.2" format="default" sectionFormat="of" derivedContent="IEEE1609.2"/>, clauses 5.1.1 and
   5.2.3.3.3. All other fields in the headerInfo are omitted.</t>
      <t indent="0" pn="section-5-4">The certificate appPermissions field <bcp14>SHALL</bcp14> be present and <bcp14>SHALL</bcp14>
      permit (as defined in <xref target="IEEE1609.2" format="default" sectionFormat="of" derivedContent="IEEE1609.2"/>) signing of PDUs with the PSID
      indicated in the HeaderInfo of the SignedData. If the application
      specification for that PSID requires Service Specific Permissions (SSP)
      for signing a pduFunctionalType of tlsHandshake, this SSP <bcp14>SHALL</bcp14> also be
      present.</t>
      <t indent="0" pn="section-5-5">The signature and verification are carried out as specified in <xref target="IEEE1609.2" format="default" sectionFormat="of" derivedContent="IEEE1609.2"/>.</t>
      <t indent="0" pn="section-5-6"> The input to the hash process is identical to the message input for
      TLS 1.3, as specified in <xref target="RFC8446" sectionFormat="of" section="4.4.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8446#section-4.4.3" derivedContent="RFC8446"/>, consisting of pad, context string, separator, and
      content, where content is Transcript-Hash(Handshake Context,
      Certificate).</t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-examples">Examples</name>
      <t indent="0" pn="section-6-1">Some of the message-exchange examples are illustrated in Figures       
      <xref target="msg_fltw" format="counter" sectionFormat="of" derivedContent="2"/> and <xref target="msg_fluw" format="counter" sectionFormat="of" derivedContent="3"/>.</t>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-6.1">
        <name slugifiedName="name-tls-server-and-tls-client-u">TLS Server and TLS Client Use the ITS Certificate</name>
        <t indent="0" pn="section-6.1-1">This section shows an example where the TLS client as well as the TLS server use ITS certificates. In consequence, both the 
server and the client populate the client_certificate_type and
server_certificate_type extension with the IEEE 1609 Dot 2 type as mentioned
in <xref target="msg_fltw" format="default" sectionFormat="of" derivedContent="Figure 2"/>.
        </t>
        <figure anchor="msg_fltw" align="left" suppress-title="false" pn="figure-2">
          <name slugifiedName="name-tls-client-and-tls-server-u">TLS Client and TLS Server Use the ITS Certificate</name>
          <artwork name="" type="" align="left" alt="" pn="section-6.1-2.1">		
   Client                                           Server

ClientHello,
client_certificate_type=1609Dot2,
server_certificate_type=1609Dot2,  --------&gt;    ServerHello,
                                       {EncryptedExtensions}
                          {client_certificate_type=1609Dot2}
                          {server_certificate_type=1609Dot2}
                                        {CertificateRequest}
                                               {Certificate}
                                         {CertificateVerify}
                                                  {Finished}
  {Certificate}          &lt;-------         [Application Data]
  {CertificateVerify}
  {Finished}             --------&gt;
  [Application Data]     &lt;-------&gt;        [Application Data]		
</artwork>
        </figure>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-6.2">
        <name slugifiedName="name-tls-client-uses-the-its-cer">TLS Client Uses the ITS Certificate and TLS Server Uses the X.509 Certificate</name>
        <t indent="0" pn="section-6.2-1"> This example shows the TLS authentication, where the TLS client
        populates the server_certificate_type extension with the X.509
        certificate and raw public key type as presented in <xref target="msg_fluw" format="default" sectionFormat="of" derivedContent="Figure 3"/>. The client indicates its ability to receive and
        validate an X.509 certificate from the server. The server chooses the
        X.509 certificate to make its authentication with the client. This is
        applicable in the case of a raw public key supported by the server.
   	
        </t>
        <figure anchor="msg_fluw" align="left" suppress-title="false" pn="figure-3">
          <name slugifiedName="name-tls-client-uses-the-its-cert">TLS Client Uses the ITS Certificate and TLS Server Uses the X.509 Certificate</name>
          <artwork name="" type="" align="left" alt="" pn="section-6.2-2.1">
Client                                           Server
ClientHello,
client_certificate_type=(1609Dot2),
server_certificate_type=(1609Dot2,
X509,RawPublicKey),         -----------&gt;         ServerHello,
                                        {EncryptedExtensions}  
                           {client_certificate_type=1609Dot2}
                               {server_certificate_type=X509}
                                         {CertificateRequest}
                                                {Certificate}  
                                          {CertificateVerify} 
                                                   {Finished}  
                            &lt;---------     [Application Data]
{Finished}                  ---------&gt;
[Application Data]          &lt;--------&gt;     [Application Data]		
</artwork>
        </figure>
      </section>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-7-1">This section provides an overview of the basic security
      considerations that need to be taken into account before implementing
      the necessary security mechanisms. The security considerations described
      throughout <xref target="RFC8446" format="default" sectionFormat="of" derivedContent="RFC8446"/> apply here as
      well.</t>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-7.1">
        <name slugifiedName="name-securely-obtaining-certific">Securely Obtaining Certificates from an Online Repository</name>
        <t indent="0" pn="section-7.1-1">In particular, the certificates used to establish a secure connection <bcp14>MAY</bcp14> be obtained from an online repository. An online repository may be used to obtain the CA certificates in the chain of either participant in the secure session.
ETSI TS 102 941 <xref target="TS102941" format="default" sectionFormat="of" derivedContent="TS102941"/> provides a mechanism that can be used to securely obtain ITS certificates.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-7.2">
        <name slugifiedName="name-expiry-of-certificates">Expiry of Certificates</name>
        <t indent="0" pn="section-7.2-1">Conventions around certificate lifetime differ between ITS
        certificates and X.509 certificates, and in particular, ITS
        certificates may be relatively short lived compared with typical X.509
        certificates. A party to a TLS session that accepts ITS certificates
        <bcp14>MUST</bcp14> check the expiry time in the received ITS
        certificate and <bcp14>SHOULD</bcp14> terminate a session when the
        certificate received in the handshake expires. </t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-7.3">
        <name slugifiedName="name-algorithms-and-cryptographi">Algorithms and Cryptographic Strength</name>
        <t indent="0" pn="section-7.3-1"> All ITS certificates use public-key cryptographic algorithms with
        an estimated strength on the order of 128 bits or more, specifically,
        Elliptic Curve Cryptography (ECC) based on curves with keys of length
        256 bits or longer. An implementation of the techniques specified in
        this document <bcp14>SHOULD</bcp14> require that if X.509 certificates
        are used by one of the parties to the session, those certificates are
        associated with cryptographic algorithms with (pre-quantum-computer)
        strength of at least 128 bits.</t>
      </section>
      <section anchor="ITS-permissions" numbered="true" toc="include" removeInRFC="false" pn="section-7.4">
        <name slugifiedName="name-interpreting-its-certificat">Interpreting ITS Certificate Permissions</name>
        <t indent="0" pn="section-7.4-1"> ITS certificates in TLS express the certificate holders
        permissions using two fields: a PSID, also known as an ITS Application
        Identifier (ITS-AID), which identifies a broad set of application
        activities that provide a context for the certificate holder's
        permissions, and a Service Specific Permissions (SSP) field associated
        with that PSID, which identifies which specific application activities
        the certificate holder is entitled to carry out within the broad set
        of activities identified by that PSID.  For example, SAE <xref target="SAEJ29453" format="default" sectionFormat="of" derivedContent="SAEJ29453"/> uses PSID 0204099 to indicate
        activities around reporting weather and managing weather response
        activities, and an SSP that states whether the certificate holder is a
        Weather Data Management System (WDMS, i.e., a central road manager),
        an ordinary vehicle, or a vehicle belonging to a managed road
        maintenance fleet. For more information about PSIDs, see <xref target="IEEE1609.12" format="default" sectionFormat="of" derivedContent="IEEE1609.12"/>, and for more information about
        the development of SSPs, see <xref target="SAEJ29455" format="default" sectionFormat="of" derivedContent="SAEJ29455"/>.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-7.5">
        <name slugifiedName="name-psid-and-pdufunctionaltype-">Psid and Pdufunctionaltype in CertificateVerify</name>
        <t indent="0" pn="section-7.5-1"> The CertificateVerify message for TLS 1.3 is an Ieee1609Dot2Data
        of type signed, where the signature contained in this Ieee1609Dot2Data
	was generated using an ITS certificate. This certificate may
        include multiple PSIDs. When a CertificateVerify message of this form
        is used, the HeaderInfo within the Ieee1609Dot2Data
        <bcp14>MUST</bcp14> have the pduFunctionalType field present and set
        to tlsHandshake. The background to this requirement is as follows: an
        ITS certificate may (depending on the definition of the application
        associated with its PSID(s)) be used to directly sign messages or to
        sign TLS CertificateVerify messages, or both. To prevent the
        possibility that a signature generated in one context could be
        replayed in a different context, i.e., that a message signature could
        be replayed as a CertificateVerify, or vice versa, the
        pduFunctionalType field provides a statement of intent by the signer
        as to the intended use of the signed message. If the pduFunctionalType
        field is absent, the message is a directly signed message for the
        application and <bcp14>MUST NOT</bcp14> be interpreted as a
        CertificateVerify.</t>
        <t indent="0" pn="section-7.5-2"> Note that each PSID is owned by an owning organization that has
        sole rights to define activities associated with that PSID. If an
        application specifier wishes to expand activities associated with an
        existing PSID (for example, to include activities over a secure
        session such as specified in this document), that application
        specifier must negotiate with the PSID owner to have that
        functionality added to the official specification of activities
        associated with that PSID.</t>
      </section>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-8">
      <name slugifiedName="name-privacy-considerations">Privacy Considerations</name>
      <t indent="0" pn="section-8-1">For privacy considerations in a vehicular environment, the ITS
      certificate is used for many reasons:
      </t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-8-2">
        <li pn="section-8-2.1">In order to address the risk of a personal data leakage, messages
        exchanged for vehicle-to-vehicle (V2V) communications are signed using ITS pseudonym
        certificates.</li>
        <li pn="section-8-2.2">The purpose of these certificates is to provide privacy and
        minimize the exchange of private data.</li>
      </ul>
    </section>
    <section anchor="IANA" numbered="true" toc="include" removeInRFC="false" pn="section-9">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-9-1">IANA maintains the "Transport Layer Security (TLS) Extensions"
      registry with a subregistry called "TLS Certificate Types".</t>
      <t indent="0" pn="section-9-2">Value 3 was previously assigned for "1609Dot2" and included a 
  reference to draft-tls-certieee1609.  IANA has updated this
  entry to reference this RFC.</t>
    </section>
  </middle>
  <back>
    <references pn="section-10">
      <name slugifiedName="name-normative-references">Normative References</name>
      <reference anchor="IEEE1609.12" quoteTitle="true" derivedAnchor="IEEE1609.12">
        <front>
          <title>IEEE Standard for Wireless Access in Vehicular Environments (WAVE) - Identifier Allocations</title>
          <author>
            <organization showOnFrontPage="true">IEEE</organization>
          </author>
          <date month="December" year="2016"/>
        </front>
        <refcontent>IEEE 1609.12-2016</refcontent>
      </reference>
      <reference anchor="IEEE1609.2" quoteTitle="true" target="https://doi.org/10.1109/IEEESTD.2016.7426684" derivedAnchor="IEEE1609.2">
        <front>
          <title>IEEE Standard for Wireless Access in Vehicular Environments -- Security Services for Applications and Management Messages</title>
          <author>
            <organization showOnFrontPage="true">IEEE</organization>
          </author>
          <date month="March" year="2016"/>
        </front>
        <seriesInfo name="DOI" value="10.1109/IEEESTD.2016.7426684"/>
        <refcontent>IEEE Standard 1609.2-2016</refcontent>
      </reference>
      <reference anchor="IEEE1609.2b" quoteTitle="true" derivedAnchor="IEEE1609.2b">
        <front>
          <title>IEEE Standard for Wireless Access in Vehicular Environments--Security Services for Applications and Management Messages - Amendment 2--PDU Functional Types and Encryption Key Management</title>
          <author>
            <organization showOnFrontPage="true">IEEE</organization>
          </author>
          <date month="June" year="2019"/>
        </front>
        <refcontent>IEEE 1609.2b-2019</refcontent>
      </reference>
      <reference anchor="ISO21177" quoteTitle="true" derivedAnchor="ISO21177">
        <front>
          <title>Intelligent transport systems - ITS station security services for secure session establishment and authentication between trusted devices</title>
          <author>
            <organization showOnFrontPage="true">ISO</organization>
          </author>
          <date month="08" year="2019"/>
        </front>
        <refcontent>ISO/TS 21177:2019</refcontent>
      </reference>
      <reference anchor="ITU-TX.696" quoteTitle="true" derivedAnchor="ITU-TX.696">
        <front>
          <title>Information technology - ASN.1 encoding rules: Specification of Octet Encoding Rules (OER)</title>
          <author>
            <organization showOnFrontPage="true">ITU-T</organization>
          </author>
          <date month="August" year="2015"/>
        </front>
        <refcontent>Recommendation ITU-T X.696</refcontent>
      </reference>
      <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
        <front>
          <title>Key words for use in RFCs to Indicate Requirement Levels</title>
          <author initials="S." surname="Bradner" fullname="S. Bradner">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="1997" month="March"/>
          <abstract>
            <t indent="0">In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
          </abstract>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="2119"/>
        <seriesInfo name="DOI" value="10.17487/RFC2119"/>
      </reference>
      <reference anchor="RFC7250" target="https://www.rfc-editor.org/info/rfc7250" quoteTitle="true" derivedAnchor="RFC7250">
        <front>
          <title>Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)</title>
          <author initials="P." surname="Wouters" fullname="P. Wouters" role="editor">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="H." surname="Tschofenig" fullname="H. Tschofenig" role="editor">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="J." surname="Gilmore" fullname="J. Gilmore">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="S." surname="Weiler" fullname="S. Weiler">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="T." surname="Kivinen" fullname="T. Kivinen">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2014" month="June"/>
          <abstract>
            <t indent="0">This document specifies a new certificate type and two TLS extensions for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS).  The new certificate type allows raw public keys to be used for authentication.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="7250"/>
        <seriesInfo name="DOI" value="10.17487/RFC7250"/>
      </reference>
      <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
        <front>
          <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
          <author initials="B." surname="Leiba" fullname="B. Leiba">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2017" month="May"/>
          <abstract>
            <t indent="0">RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t>
          </abstract>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="8174"/>
        <seriesInfo name="DOI" value="10.17487/RFC8174"/>
      </reference>
      <reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8446" quoteTitle="true" derivedAnchor="RFC8446">
        <front>
          <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
          <author initials="E." surname="Rescorla" fullname="E. Rescorla">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2018" month="August"/>
          <abstract>
            <t indent="0">This document specifies version 1.3 of the Transport Layer Security (TLS) protocol.  TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
            <t indent="0">This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961.  This document also specifies new requirements for TLS 1.2 implementations.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8446"/>
        <seriesInfo name="DOI" value="10.17487/RFC8446"/>
      </reference>
      <reference anchor="SAEJ29453" quoteTitle="true" derivedAnchor="SAEJ29453">
        <front>
          <title>Requirements for V2I Weather Applications</title>
          <author>
            <organization showOnFrontPage="true">SAE</organization>
          </author>
          <date month="06" year="2017"/>
        </front>
        <refcontent>J2945/3</refcontent>
      </reference>
      <reference anchor="SAEJ29455" quoteTitle="true" derivedAnchor="SAEJ29455">
        <front>
          <title>Service Specific Permissions and Security Guidelines for Connected Vehicle Applications</title>
          <author>
            <organization showOnFrontPage="true">SAE</organization>
          </author>
          <date month="02" year="2020"/>
        </front>
        <refcontent>J2945/5_202002</refcontent>
      </reference>
      <reference anchor="TS102941" quoteTitle="true" derivedAnchor="TS102941">
        <front>
          <title>Intelligent Transport Systems (ITS); Security; Trust and Privacy Management</title>
          <author>
            <organization showOnFrontPage="true">ETSI</organization>
          </author>
          <date year="2018"/>
        </front>
        <refcontent>ETSI TS 102 941</refcontent>
      </reference>
      <reference anchor="TS103097" quoteTitle="true" derivedAnchor="TS103097">
        <front>
          <title>Intelligent Transport Systems (ITS); Security; Security header and certificate formats</title>
          <author>
            <organization showOnFrontPage="true">ETSI</organization>
          </author>
          <date>2017</date>
        </front>
        <refcontent>ETSI TS 103 097</refcontent>
      </reference>
    </references>
    <section anchor="ack" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.a-1">The authors wish to thank <contact fullname="Adrian Farrel"/>,
      <contact fullname="Eric Rescola"/>, <contact fullname="Russ Housley"/>,
      <contact fullname="Ilari Liusvaara"/>, and <contact fullname="Benjamin       Kaduk"/> for their feedback and suggestions on improving this document.
      Thanks are due to <contact fullname="Sean Turner"/> for his valuable and detailed
      comments. Special thanks to <contact fullname="Panos Kampanakis"/>,
      <contact fullname="Jasja Tijink"/>, and <contact fullname="Bill       Lattin"/> for their guidance and support of the document.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author fullname="Mounira Msahli" initials="M" role="editor" surname="Msahli">
        <organization showOnFrontPage="true">Telecom Paris</organization>
        <address>
          <postal>
            <street/>
            <city/>
            <code/>
            <country>France</country>
          </postal>
          <email>mounira.msahli@telecom-paris.fr</email>
        </address>
      </author>
      <author fullname="Nancy Cam-Winget" initials="N" role="editor" surname="Cam-Winget">
        <organization showOnFrontPage="true">Cisco</organization>
        <address>
          <postal>
            <street/>
            <city/>
            <code/>
            <country>United States of America</country>
          </postal>
          <email>ncamwing@cisco.com</email>
        </address>
      </author>
      <author fullname="William Whyte" initials="W" role="editor" surname="Whyte">
        <organization showOnFrontPage="true">Qualcomm</organization>
        <address>
          <postal>
            <street/>
            <city/>
            <code/>
            <country>United States of America</country>
          </postal>
          <email>wwhyte@qti.qualcomm.com</email>
        </address>
      </author>
      <author fullname="Ahmed Serhrouchni" initials="A" surname="Serhrouchni">
        <organization showOnFrontPage="true">Telecom Paris</organization>
        <address>
          <postal>
            <street/>
            <city/>
            <code/>
            <country>France</country>
          </postal>
          <email>ahmed.serhrouchni@telecom-paris.fr</email>
        </address>
      </author>
      <author fullname="Houda Labiod" initials="H" surname="Labiod">
        <organization showOnFrontPage="true">Telecom Paris</organization>
        <address>
          <postal>
            <street/>
            <city/>
            <code/>
            <country>France</country>
          </postal>
          <email>houda.labiod@telecom-paris.fr</email>
        </address>
      </author>
    </section>
  </back>
</rfc>