Skip to main content

TLS Authentication using ITS certificate
draft-msahli-ise-ieee1609-06

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 8902.
Authors Mounira Msahli , Nancy Cam-Winget , William Whyte , Ahmed Serhrouchni , Houda Labiod
Last updated 2020-04-08
Replaces draft-msahli-ipwave-extension-ieee1609
RFC stream Independent Submission
Formats
IETF conflict review conflict-review-msahli-ise-ieee1609, conflict-review-msahli-ise-ieee1609, conflict-review-msahli-ise-ieee1609, conflict-review-msahli-ise-ieee1609, conflict-review-msahli-ise-ieee1609, conflict-review-msahli-ise-ieee1609, conflict-review-msahli-ise-ieee1609, conflict-review-msahli-ise-ieee1609
Stream ISE state In ISE Review
Consensus boilerplate Unknown
Document shepherd Eliot Lear
Shepherd write-up Show Last changed 2020-03-24
IESG IESG state Became RFC 8902 (Experimental)
Telechat date (None)
Responsible AD (None)
Send notices to Adrian Farrel <rfc-ise@rfc-editor.org>
IANA IANA review state Version Changed - Review Needed
IANA expert review state Expert Reviews OK
draft-msahli-ise-ieee1609-06
Network Working Group                                     M. Msahli, Ed.
Internet-Draft                                             Telecom Paris
Intended status: Experimental                         N. Cam-Winget, Ed.
Expires: October 10, 2020                                          Cisco
                                                           W. Whyte, Ed.
                                                                Qualcomm
                                                          A. Serhrouchni
                                                               H. Labiod
                                                           Telecom Paris
                                                           April 8, 2020

                TLS Authentication using ITS certificate
                      draft-msahli-ise-ieee1609-06

Abstract

   The IEEE and ETSI have specified a type of end-entity certificates.
   This document defines an experimental change to TLS to support IEEE/
   ETSI certificate types to authenticate TLS entities.

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 October 10, 2020.

Copyright Notice

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

Msahli, et al.          Expires October 10, 2020                [Page 1]
Internet-Draft   IEEE and ETSI Certificate Types for TLS      April 2020

   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
     1.1.  Experiment Overview . . . . . . . . . . . . . . . . . . .   4
   2.  Requirements Terminology  . . . . . . . . . . . . . . . . . .   4
   3.  Extension Overview  . . . . . . . . . . . . . . . . . . . . .   4
   4.  TLS Client and Server Handshake . . . . . . . . . . . . . . .   5
     4.1.  Client Hello  . . . . . . . . . . . . . . . . . . . . . .   7
     4.2.  Server Hello  . . . . . . . . . . . . . . . . . . . . . .   7
   5.  Certificate Verification  . . . . . . . . . . . . . . . . . .   8
   6.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .   9
     6.1.  TLS Server and TLS Client use the ITS Certificate . . . .   9
     6.2.  TLS Client uses the ITS certificate and TLS Server uses
           the X.509 certificate . . . . . . . . . . . . . . . . . .   9
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
     7.1.  Securely Obtaining Certificates from an Online Repository  10
     7.2.  Expiry of Certificates  . . . . . . . . . . . . . . . . .  10
     7.3.  Algorithms and Cryptographic Strength . . . . . . . . . .  11
     7.4.  Interpreting ITS Certificate Permissions  . . . . . . . .  11
     7.5.  Psid and Pdufunctionaltype in CertificateVerify . . . . .  11
   8.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  12
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  12
   11. Normative References  . . . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   The TLS protocol [RFC8446] allows the use of X.509 certificates and
   Raw Public Key to authenticate servers and clients.  This document
   describes an experimental extension following the procedures laid out
   by [RFC7250] to support use of the certificate format specified by
   the IEEE in [IEEE1609.2] and profiled by the European
   Telecommunications Standards Institute (ETSI) in [TS103097].  In this
   document, we call this certificates: ITS certificates.  These
   standards specify secure communications in vehicular environments.
   These certificates are referred to in this document as Intelligent
   Transportation Systems (ITS) Certificates.

   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 such as are found in Intelligent

Msahli, et al.          Expires October 10, 2020                [Page 2]
Internet-Draft   IEEE and ETSI Certificate Types for TLS      April 2020

   Transportation Systems (ITS).  The standards specify different types
   of certificate 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.

   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.

   The ITS certificates are also suited to the M2M ad hoc network
   setting, because their direct encoding of permissions (see Security
   Considerations, 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
   Transportation 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
   https://ec.europa.eu/transport/themes/its/c-its_en, direct link at
   https://ec.europa.eu/transport/sites/transport/files/
   c-its_certificate_policy_release_1.pdf).

   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 OEMs and national road authorities to create root
   CAs and have them trusted.  In the US, the US Department of
   Transportation (USDOT) published a proposed regulation, which as of
   late 2019, is active though not rapidly progressing, which would
   require all light vehicles in the US to implement V2X communications
   including the use of ITS certificates (available from
   https://www.federalregister.gov/documents/2017/01/12/2016-31059/
   federal-motor-vehicle-safety-standards-v2v-communications).  As of
   2019, ITS deployments across the US, Europe and Australia were using
   ITS certificates.  Volkswagen have committed to deploying V2X using
   ITS certificates.  New York, Tampa and Wyoming are deploying traffic
   management systems using ITS certificates.  GM deployed V2X in their
   Cadillac CTSes using ITS certificates.

   ITS certificates are also used in a number of standards that build on
   top of the foundational IEEE and ETSI standards, particularly the SAE

Msahli, et al.          Expires October 10, 2020                [Page 3]
Internet-Draft   IEEE and ETSI Certificate Types for TLS      April 2020

   J2945/x series of standards for applications and ISO 21177, which
   builds a framework for exchanging multiple authentication tokens on
   top of the TLS variant specified in this document.

1.1.  Experiment Overview

   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 system using standard TLS by the use of a new
   Certificate Type value, reserved through IANA (see Section 9).  An
   implementation of TLS that is not involved in the Experiment will not
   recognise 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.

   This extension has been encouraged by stakeholders in the Cooperative
   ITS community in order to support the ITS use cases deployment and it
   is anticipated that its use will be widespread.

2.  Requirements Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Extension Overview

   The TLS extension "client_certificate_type" and
   "server_certificate_type" [RFC7250] are used to negotiate the type of
   Certificate messages used in TLS to authenticate the server and,
   optionally, the client.  Using separate extension allows for mixed
   deployments where 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" extension,
   and the CertificateEntry structures are included in the certificate
   chain sent in the Certificate message.  In case of TLS 1.3, the
   "client_certificate_type " SHALL contain a list of supported
   certificate types proposed by the client as provided in the figure
   below:

Msahli, et al.          Expires October 10, 2020                [Page 4]
Internet-Draft   IEEE and ETSI Certificate Types for TLS      April 2020

     /* 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<1..2^24-1>;

               /* RawPublicKey defined in RFC 7250*/
              case RawPublicKey:
              opaque ASN.1_subjectPublicKeyInfo<1..2^24-1>;

              /* X.509 certificate defined in RFC 5246*/
              case X.509:
              opaque cert_data<1..2^24-1>;

               };

             Extension extensions<0..2^16-1>;
         } CertificateEntry;

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

4.  TLS Client and Server Handshake

   Figure 1 shows the handshake message flow for a full TLS 1.3
   handshake negotiating both certificate types.

Msahli, et al.          Expires October 10, 2020                [Page 5]
Internet-Draft   IEEE and ETSI Certificate Types for TLS      April 2020

   Client                                           Server

 Key  ^ ClientHello
 Exch | + server_certificate_type*
      | + client_certificate_type*
      | + key_share*
      v + signature_algorithms*       -------->
                                                   ServerHello  ^ Key
                                                  + key_share*  v Exch
                                         {EncryptedExtensions}  ^ Server
                                    {+ server_certificate_type*}| Params
                                    {+ client_certificate_type*}|
                                         {CertificateRequest*}  v
                                                {Certificate*}  ^
                                          {CertificateVerify*}  | Auth
                                                    {Finished}  v
                                <-------   [Application Data*]
      ^ {Certificate*}
 Auth | {CertificateVerify*}
      v {Finished}              -------->
        [Application Data]      <------->   [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.

    Figure 1: Message Flow with certificate type extension for Full TLS
                               1.3 Handshake

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

Msahli, et al.          Expires October 10, 2020                [Page 6]
Internet-Draft   IEEE and ETSI Certificate Types for TLS      April 2020

4.1.  Client Hello

   In order to indicate the support of ITS certificates, a client MUST
   include an extension of type "client_certificate_type" or
   "server_certificate_type" in the extended Client Hello message as
   described in Section 4.1.2 of TLS 1.3 [RFC8446].

   For both TLS 1.3, the rules for when the Client Certificate and
   CertificateVerify messages appear are as follows:

      - The client's Certificate message is present if and only if the
      server sent a CertificateRequest message.

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

   For maximum compatibility, all implementations SHOULD be prepared to
   handle "potentially" extraneous certificates and arbitrary orderings
   from any TLS version, with the exception of the end-entity
   certificate which MUST be first.

4.2.  Server Hello

   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:

      - If both client and server indicate support for the ITS
      certificate type, the server MAY select the first (most preferred)
      certificate type from the client's list that is supported by both
      peers

      - The server does not support any of the proposed certificate
      types and terminates the session with a fatal alert of type
      "unsupported_certificate".

      - The server supports the certificate types specified in this
      document.  In this case, it MAY respond with a certificate of this
      type.  It MAY also include the client_certificate_type extension
      in Encrypted Extension.  Then, the server requests a certificate
      from the client ( via the CertificateRequest message )

   The certificates in the TLS client or server certificate chain MAY be
   sent as part of the handshake, or MAY be sent 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 the endpoint does

Msahli, et al.          Expires October 10, 2020                [Page 7]
Internet-Draft   IEEE and ETSI Certificate Types for TLS      April 2020

   not already know the certificates from the chain, then it SHALL
   reject the other endpoint's certificate and close the connection.
   Protocols to support retrieving certificates from a repository are
   specified in ETSI[ETSI102941].

5.  Certificate Verification

   Verification of an ITS certificates or certificate chain is described
   in section 5.1 of [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 [RFC8446].  In this
   case, the CertificateVerify message contains a Canonical Octet
   Encoding Rules [ITU-TX.696] -encoded IEEE1609Dot2Data of type signed
   as specified in [IEEE1609.2], [IEEE1609.2b], where:

      Payload contains an extDataHash containing the SHA-256 hash of the
      data the signature is calculated over.  This is identical to the
      data that the signature is calculated over it in standard TLS,
      which is reproduced below for clarity.

      Provider Service Identifier (Psid) indicates the application
      activity that the certificate is authorizing.

      generationTime is the time at which the data structure was
      generated.

      PduFunctionalType (as specified in [IEEE1609.2b]) is present and
      is set equal to tlsHandshake (1).

   All other fields in the headerInfo are omitted.  The certificate
   appPermissions field SHALL be present and SHALL permit (as defined in
   [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 SHALL also be present.
   For more details on the use of PSID and SSP, see [IEEE1609.2] clauses
   5.1.1 and 5.2.3.3.3.  All other fields in the headerInfo are omitted.

   The certificate appPermissions field SHALL be present and SHALL
   permit (as defined in IEEE 1609.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 SHALL
   also be present.

   The signature and verification are carried out as specified in
   [IEEE1609.2].

Msahli, et al.          Expires October 10, 2020                [Page 8]
Internet-Draft   IEEE and ETSI Certificate Types for TLS      April 2020

   The input to the hash process is identical to the message input for
   TLS 1.3, as specified in [RFC8446] section 4.4.3, consisting of pad,
   context string, separator and content, where content is Transcript-
   Hash(Handshake Context, Certificate).

6.  Examples

   Some of message-exchange examples are illustrated in Figures 2 and 3.

6.1.  TLS Server and TLS Client use the ITS Certificate

   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 figure 2.

      Client                                           Server

   ClientHello,
   client_certificate_type=1609Dot2,
   server_certificate_type=1609Dot2,   -------->     ServerHello,
                                            {EncryptedExtensions}
                               {client_certificate_type=1609Dot2}
                               {server_certificate_type=1609Dot2}
                                             {CertificateRequest}
                                                    {Certificate}
                                              {CertificateVerify}
                                                       {Finished}
     {Certificate}           <-------          [Application Data]
     {CertificateVerify}
     {Finished}              -------->
     [Application Data]      <------->         [Application Data]

        Figure 2: TLS Client and TLS Server use the ITS certificate

6.2.  TLS Client uses the ITS certificate and TLS Server uses the X.509
      certificate

   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 figure 3.  The
   client indicates its ability to receive and to 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 case of Raw Public Key supported by the server.

Msahli, et al.          Expires October 10, 2020                [Page 9]
Internet-Draft   IEEE and ETSI Certificate Types for TLS      April 2020

   Client                                           Server
   ClientHello,
   client_certificate_type=(1609Dot2),
   server_certificate_type=(1609Dot2,
   X509,RawPublicKey),         ----------->         ServerHello,
                                           {EncryptedExtensions}
                              {client_certificate_type=1609Dot2}
                                  {server_certificate_type=X509}
                                            {CertificateRequest}
                                                   {Certificate}
                                             {CertificateVerify}
                                                      {Finished}
                               <---------     [Application Data]
   {Finished}                  --------->
   [Application Data]          <-------->     [Application Data]

   Figure 3: TLS Client uses the ITS certificate and TLS Server uses the
                             X.509 certificate

7.  Security Considerations

   This section provides an overview of the basic security
   considerations which need to be taken into account before
   implementing the necessary security mechanisms.  The security
   considerations described throughout [RFC8446] apply here as well.

7.1.  Securely Obtaining Certificates from an Online Repository

   In particular, the certificates used to establish a secure connection
   MAY 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 [ETSI102941]
   provides a mechanism that can be used to securely obtain ITS
   certificates.

7.2.  Expiry of Certificates

   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 MUST check the expiry time in the received ITS
   certificate and SHOULD terminate a session when the certificate
   received in the handshake expires.

Msahli, et al.          Expires October 10, 2020               [Page 10]
Internet-Draft   IEEE and ETSI Certificate Types for TLS      April 2020

7.3.  Algorithms and Cryptographic Strength

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

7.4.  Interpreting ITS Certificate Permissions

   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
   which 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 [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 [IEEE16092] and for more information about the
   development of SSPs, see [SAEJ29455]

7.5.  Psid and Pdufunctionaltype in CertificateVerify

   The CertificateVerify message for TLS 1.3 is an Ieee1609Dot2Data of
   type signed, signed using an ITS certificate.  This certificate may
   include multiple PSIDs.  When a CertificateVerify message of this
   form is used, the HeaderInfo within the Ieee1609Dot2Data MUST have
   the pduFunctionalType field present and set to tlsHandshake.  The
   background to this requirement is as follows.  A 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 MUST NOT
   be interpreted as a CertificateVerify.

Msahli, et al.          Expires October 10, 2020               [Page 11]
Internet-Draft   IEEE and ETSI Certificate Types for TLS      April 2020

   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.

8.  Privacy Considerations

   For privacy considerations in a vehicular environment the ITS
   certificate is used for many reasons:

      In order to address the risk of a personal data leakage, messages
      exchanged for V2V communications are signed using ITS pseudonym
      certificates

      The purpose of these certificates is to provide privacy and
      minimize the exchange of private data

9.  IANA Considerations

   IANA maintains the "Transport Layer Security (TLS) Extensions"
   registry with a subregistry called "TLS Certificate Types".

   IANA has previously assigned an entry (value 3) for "1609Dot2" with
   reference set to draft-tls-certieee1609.  IANA is requested to update
   that entry to reference the RFC number of this document when it is
   published.

10.  Acknowledgements

   The authors wish to thank Adrian Farrel , Eric Rescola , Russ
   Housley, Ilari Liusvaara and Benjamin Kaduk for their feedback and
   suggestions on improving this document.  Thanks are due to Sean
   Turner for his valuable and detailed comments.  Special thanks to
   Panos Kampanakis, Jasja Tijink and Bill Lattin for their guidance and
   support of the draft.

11.  Normative References

   [ETSI102941]
              "ETSI TS 102 941 : Intelligent Transport Systems (ITS);
              Security; Trust and Privacy Management", 2018.

Msahli, et al.          Expires October 10, 2020               [Page 12]
Internet-Draft   IEEE and ETSI Certificate Types for TLS      April 2020

   [IEEE1609.2]
              "IEEE Standard for Wireless Access in Vehicular
              Environments - Security Services for Applications and
              Management Messages", 2016.

   [IEEE1609.2b]
              "IEEE Standard for Wireless Access in Vehicular
              Environments--Security Services for Applications and
              Management Messages - Amendment 2--PDU Functional Types
              and Encryption Key Management", 2019.

   [IEEE16092]
              "IEEE Standard for Wireless Access in Vehicular
              Environments Identifier Allocations", December 2016.

   [ISO21177]
              "Intelligent transport systems -- ITS station security
              services for secure session establishment and
              authentication between trusted devices".

   [ITU-TX.696]
              "Procedures for the operation of object identifier
              registration authorities: General procedures and top arcs
              of the international object identifier tree", July 2011.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", March 1997.

   [RFC7250]  Wouters, P., Tschofenig, H., Weiler, S., and T.  Kivinen,
              "Using Raw Public Keys in Transport Layer Security (TLS)
              and Datagram Transport Layer Security (DTLS)", June 2014.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", May 2017.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", August 2018.

   [SAEJ29453]
              "Requirements for V2I Weather Applications".

   [SAEJ29455]
              "Service Specific Permissions and Security Guidelines for
              Connected Vehicle Applications".

   [TS103097]
              "ETSI TS 103 097 : Intelligent Transport Systems (ITS);
              Security; Security header and certificate formats".

Msahli, et al.          Expires October 10, 2020               [Page 13]
Internet-Draft   IEEE and ETSI Certificate Types for TLS      April 2020

Authors' Addresses

   Mounira Msahli (editor)
   Telecom Paris
   France

   EMail: mounira.msahli@telecom-paris.fr

   Nancy Cam-Winget (editor)
   Cisco
   USA

   EMail: ncamwing@cisco.com

   William Whyte (editor)
   Qualcomm
   USA

   EMail: wwhyte@qti.qualcomm.com

   Ahmed Serhrouchni
   Telecom Paris
   France

   EMail: ahmed.serhrouchni@telecom-paris.fr

   Houda Labiod
   Telecom Paris
   France

   EMail: houda.labiod@telecom-paris.fr

Msahli, et al.          Expires October 10, 2020               [Page 14]