idnits 2.17.1 draft-msahli-ise-ieee1609-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 22, 2019) is 1645 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'SAEJ29453' is defined on line 617, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Duplicate reference: RFC2119, mentioned in 'RFC8174', was also mentioned in 'RFC2119'. Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Msahli, Ed. 3 Internet-Draft Telecom Paris 4 Intended status: Experimental N. Cam-Winget, Ed. 5 Expires: April 24, 2020 Cisco 6 A. Serhrouchni, Ed. 7 H. Labiod , Ed. 8 Telecom Paris 9 W. Whyte, Ed. 10 Qualcomm 11 October 22, 2019 13 TLS Authentication using IEEE 1609.2 certificate 14 draft-msahli-ise-ieee1609-02 16 Abstract 18 This document specifies the use of the IEEE/ETSI certificate type to 19 authenticate TLS entities. The goal is to enable the use of end- 20 entity certificate specified by the IEEE and the European 21 Telecommunications Standards Institute (ETSI). This specification 22 defines an experimental change of TLS to support IEEE/ETSI 23 certificate type. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 24, 2020. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Experiment Overview . . . . . . . . . . . . . . . . . . . 4 61 2. Requirements Terminology . . . . . . . . . . . . . . . . . . 4 62 3. Extension Overview . . . . . . . . . . . . . . . . . . . . . 4 63 4. TLS Client and Server Handshake . . . . . . . . . . . . . . . 5 64 4.1. Client Hello . . . . . . . . . . . . . . . . . . . . . . 7 65 4.2. Server Hello . . . . . . . . . . . . . . . . . . . . . . 7 66 5. Certificate Verification . . . . . . . . . . . . . . . . . . 8 67 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 6.1. TLS Server and TLS Client use the 1609Dot2 Certificate . 9 69 6.2. TLS Client uses the IEEE 1609.2 certificate and TLS 70 Server uses the X.509 certificate . . . . . . . . . . . . 10 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 72 7.1. Securely obtaining certificates from an online repository 11 73 7.2. Expiry of certificates . . . . . . . . . . . . . . . . . 11 74 7.3. Algorithms and cryptographic strength . . . . . . . . . . 11 75 7.4. Interpreting C-ITS certificate permissions . . . . . . . 11 76 7.5. PSID and pduFunctionalType in CertificateVerify . . . . . 12 77 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13 78 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 79 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 80 11. Normative References . . . . . . . . . . . . . . . . . . . . 13 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 83 1. Introduction 85 The TLS protocol [RFC8446] [RFC5246] uses X.509 certificates and Raw 86 Public Key in order to authenticate servers and clients. This 87 document describes an experimental extension following the [RFC7250] 88 to support use of the certificate format specified by the IEEE in 89 [IEEE1609.2] and profiled by the European Telecommunications 90 Standards Institute (ETSI) in [TS103097]. These standards specify 91 secure communications in vehicular environments. These certificates 92 are referred to in this document as Cooperative Intelligent 93 Transportation Systems (C-ITS) Certificates. The certificate types 94 are optimized for bandwidth and processing time to support delay- 95 sensitive applications, and also to provide both authentication and 96 authorization information to enable fast access control decisions in 97 ad hoc networks such as are found in Intelligent Transportation 98 Systems (ITS). The standards specify different types of certificate 99 to support a full Public Key Infrastructure (PKI) specification; the 100 certificates to be used in this context are end-entity certificates, 101 i.e. certificates that have the IEEE 1609.2 appPermissions field 102 present. Use of C-ITS certificates is becoming widespread in the 103 C-ITS setting. ITS communications in practice make heavy use of 10 104 MHz channels with a typical throughput of 6 Mbps. (The 802.11OCB 105 modulation that gives this throughput is not the one that gives the 106 highest throughput, but it provides for a robust signal over a range 107 up to 300-500 m, which is the "sweet spot" for communications range 108 for ITS operations like collision avoidance). The C-ITS certificates 109 are also suited to the M2M ad hoc network setting, because their 110 direct encoding of permissions (see Security Considerations, section 111 7.6) allows a receiver to make an immediate accept/deny decision 112 about an incoming message without having to refer to a remote 113 identity and access management server. The EU has committed to the 114 use of C-ITS certificates in Cooperative Intelligent Transportation 115 Systems deployments. A multi-year project developed a certificate 116 policy for the use of C-ITS certificates, including a specification 117 of how different root certificates can be trusted across the system 118 (hosted at https://ec.europa.eu/transport/themes/its/c-its_en, direct 119 link at https://ec.europa.eu/transport/sites/transport/files/ 120 c-its_certificate_policy_release_1.pdf). The EU has committed 121 funding for the first five years of operation of the top-level Trust 122 List Manager entity, enabling organizations such as motor vehicle 123 OEMs and national road authorities to create root CAs and have them 124 trusted. In the US, the US Department of Transportation (USDOT) 125 published a proposed regulation, which at the time of writing is 126 active though not rapidly progressing, which would have required all 127 light vehicles in the US to implement V2X communications including 128 the use of C-ITS certificates (available from 129 https://www.federalregister.gov/documents/2017/01/12/2016-31059/ 130 federal-motor-vehicle-safety-standards-v2v-communications). As of 131 2019, ITS deployments across the US, Europe and Australia were using 132 C-ITS certificates. Volkswagen have committed to deploying V2X next 133 year using C-ITS certificates. New York, Tampa and Wyoming are 134 deploying traffic management systems using C-ITS certificates. GM 135 deployed V2X in their Cadillac CTSes using C-ITS certificates. C-ITS 136 certificates are also used in a number of standards that build on top 137 of the foundational IEEE and ETSI standards, particularly the SAE 138 J2945/x series of standards for applications and ISO 21177, which 139 builds a framework for exchanging multiple authentication tokens on 140 top of the TLS variant specified in this document. 142 1.1. Experiment Overview 144 This document describes an experimental extension of TLS security 145 model. We are using a form of certificate that has not traditionally 146 been used in the Internet. Systems using this Experimental approach 147 are segregated from system using standard TLS by the use of a new 148 Certificate Type value, reserved through IANA. The implementation of 149 TLS is not involved in the Experiment and it will not be able to 150 interact with an Experimental implementation. This extension has 151 been encouraged by stakeholders in the Cooperative ITS community in 152 order to support the C-ITS use cases deployment and it is anticipated 153 that its use will be widespread. 155 2. Requirements Terminology 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 159 "OPTIONAL" in this document are to be interpreted as described in BCP 160 14 [RFC2119] [RFC8174]when, and only when, they appear in all 161 capitals, as shown here. 163 3. Extension Overview 165 For TLS 1.2[RFC5246], the "extension_data" field SHALL follow the 166 [RFC7250]. In case of TLS 1.3, the "extension_data" field SHALL 167 contain a list of supported certificate types proposed by the client 168 as provided in the figure below: 170 /* Managed by IANA */ 171 enum { 172 X509(0), 173 RawPublicKey(2), 174 1609Dot2(3), 175 (255) 176 } CertificateType; 178 struct { 179 select (certificate_type) { 181 /* certificate type defined in this document.*/ 182 case 1609Dot2: 183 opaque cert_data<1..2^24-1>; 185 /* RawPublicKey defined in RFC 7250*/ 186 case RawPublicKey: 187 opaque ASN.1_subjectPublicKeyInfo<1..2^24-1>; 189 /* X.509 certificate defined in RFC 5246*/ 190 case X.509: 191 opaque cert_data<1..2^24-1>; 193 }; 195 Extension extensions<0..2^16-1>; 196 } CertificateEntry; 198 In case where the TLS server accepts the described extension, it 199 selects one of the certificate types. Note that a server MAY 200 authenticate the client using other authentication methods. 202 4. TLS Client and Server Handshake 204 The "client_certificate_type" and "server_certificate_type" 205 extensions MUST be sent in handshake phase as illustrated in figure 1 206 below. 208 Client Server 210 Key ^ ClientHello 211 Exch | + server_certificate_type* 212 | + client_certificate_type* 213 | + key_share* 214 v + signature_algorithms* --------> 215 ServerHello ^ Key 216 + key_share* v Exch 217 {EncryptedExtensions} ^ Server 218 {+ server_certificate_type*}| Params 219 {+ client_certificate_type*}| 220 {CertificateRequest*} v 221 {Certificate*} ^ 222 {CertificateVerify*} | Auth 223 {Finished} v 224 <------- [Application Data*] 225 ^ {Certificate*} 226 Auth | {CertificateVerify*} 227 v {Finished} --------> 228 [Application Data] <-------> [Application Data] 230 + Indicates noteworthy extensions sent in the 231 previously noted message. 233 * Indicates optional or situation-dependent 234 messages/extensions that are not always sent. 236 {} Indicates messages protected using keys 237 derived from a [sender]_handshake_traffic_secret. 239 [] Indicates messages protected using keys 240 derived from [sender]_application_traffic_secret_N. 242 Figure 1: Message Flow with certificate type extension for Full TLS 243 1.3 Handshake 245 In case of TLS 1.3 and in order to negotiate the support of IEEE 246 1609.2 or ETSI TS 103097 certificate-based authentication, the 247 clients and the servers MAY include the extension of type 248 "client_certificate_type" and "server_certificate_type" in the 249 extended Client Hello and "EncryptedExtensions". In case of TLS 1.2, 250 used extensions are in Client Hello and Server Hello. 252 4.1. Client Hello 254 In order to indicate the support of IEEE 1609.2 or ETSI TS 103097 255 certificates, client MUST include an extension of type 256 "client_certificate_type" or "server_certificate_type" in the 257 extended Client Hello message as described in Section 4.1.2 of TLS 258 1.3 [RFC8446]. 260 The extension 'client_certificate_type' sent in the Client Hello MAY 261 carry a list of supported certificate types, sorted by client 262 preference. It is a list in the case where the client supports 263 multiple certificate types. 265 In both TLS 1.2 and 1.3, the rules if client Certificate and 266 CertificateVerify messages appear is as follows: 268 - Client Certificate message is present if and only if server sent 269 a CertificateRequest message. 271 - Client CertificateVerify message is present if and only if the 272 Client Certificate message is present and contains non-empty 273 certificate list. 275 All implementations SHOULD be prepared to handle extraneous 276 certificates and arbitrary orderings from any TLS version, with the 277 exception of the end-entity certificate which MUST be first. 279 4.2. Server Hello 281 When the server receives the Client Hello containing the 282 client_certificate_type extension and/or the server_certificate_type 283 extension, the following options are possible: 285 - The server supports the extension described in this document. 286 It selects a certificate type from the client_certificate_type 287 field in the extended Client Hello and SHALL take into account the 288 client authentication list priority. 290 - The server does not support any of the proposed certificate type 291 and terminates the session with a fatal alert of type 292 "unsupported_certificate". 294 - The server does not support the extension defined in this 295 document. In this case, the server returns the Server Hello 296 without the extensions defined in this document. 298 - The server supports the extension defined in this document, but 299 it does not have any certificate type in common with the client. 301 Then, the server terminates the session with a fatal alert of type 302 "unsupported_certificate". 304 - The server supports the extensions defined in this document and 305 has at least one certificate type in common with the client. In 306 this case, the server MAY include the client_certificate_type 307 extension in the Server Hello for TLS 1.2 or in Encrypted 308 Extension for TLS 1.3. Then, the server requests a certificate 309 from the client (via the certificate_request message) 311 The TLS client or server public keys can be obtained from an online 312 repository. In fact, the repository is used to retrive the 313 certificate chain. All PKI requests and responses are indicated in 314 ETSI[ETSI102941]. 316 5. Certificate Verification 318 Verification of an IEEE 1609.2/ ETSI TS 103097 certificates or 319 certificate chain is described in section 5.1 of [IEEE1609.2]. In 320 the case of TLS 1.3 and when the certificate_type is 1609Dot2, the 321 CertificateVerify contents and processing are different than for the 322 CertificateVerify message specified for other values of 323 certificate_type in [RFC8446]. In this case, the CertificateVerify 324 message contains a Canonical Octet Encoding Rules [ITU-TX.696] 325 -encoded IEEE1609Dot2Data of type signed as specified in 326 [IEEE1609.2], [IEEE1609.2b], where: 328 Payload contains an extDataHash containing the SHA-256 hash of the 329 data and the signature is calculated over. This is identical to 330 the data, the signature is calculated over in standard TLS, which 331 is reproduced below for clarity. 333 Psid indicates the application activity that the certificate is 334 authorizing. 336 generationTime is the time at which the data structure was 337 generated. 339 PduFunctionalType (as specified in [IEEE1609.2b]) is present and 340 is set equal to tlsHandshake (1). 342 All other fields in the headerInfo are omitted. The certificate 343 appPermissions field shall be present and shall permit (as defined in 344 IEEE1609.2) signing of PDUs with the PSID indicated in the HeaderInfo 345 of the SignedData. If the application specification for that PSID 346 requires Service Specific Permissions (SSP) for signing a 347 pduFunctionalType of tlsHandshake, this SSP shall also be present. 349 For more details on the use of PSID and SSP, see [IEEE1609.2] clauses 350 5.1.1 and 5.2.3.3.3. All other fields in the headerInfo are omitted. 352 The certificate appPermissions field shall be present and shall 353 permit (as defined in IEEE 1609.2) signing of PDUs with the PSID 354 indicated in the HeaderInfo of the SignedData. If the application 355 specification for that PSID requires Service Specific Permissions 356 (SSP) for signing a pduFunctionalType of tlsHandshake, this SSP shall 357 also be present. 359 The message input to the signature calculation is the usual message 360 input for TLS 1.3, as specified in [RFC8446] section 4.4.3, 361 consisting of pad, context string, separator and content, where 362 content is Transcript- Hash(Handshake Context, Certificate). 364 The signature and verification are carried out as specified in 365 [IEEE1609.2]. 367 The message input to the signature calculation is the usual message 368 input for TLS 1.3, as specified in [RFC8446] section 4.4.3, 369 consisting of pad, context string, separator and content, where 370 content is Transcript- Hash(Handshake Context, Certificate). 372 The signature and verification are carried out as specified in 373 [IEEE1609.2]. 375 6. Examples 377 Some of exchanged messages examples are illustrated in Figures 2 and 378 3. 380 6.1. TLS Server and TLS Client use the 1609Dot2 Certificate 382 This section shows an example where the TLS client as well as the TLS 383 server use the IEEE 1609.2 certificate. In consequence, both the 384 server and the client populate the client_certificate_type and 385 server_certificate_type with extension IEEE 1609.2 certificates as 386 mentioned in figure 2. 388 Client Server 390 ClientHello, 391 client_certificate_type=1609Dot2, 392 server_certificate_type=1609Dot2, --------> ServerHello, 393 {EncryptedExtensions} 394 {client_certificate_type=1609Dot2} 395 {server_certificate_type=1609Dot2} 396 {CertificateRequest} 397 {Certificate} 398 {CertificateVerify} 399 {Finished} 400 {Certificate} <------- [Application Data] 401 {CertificateVerify} 402 {Finished} --------> 403 [Application Data] <-------> [Application Data] 405 Figure 2: TLS Client and TLS Server use the IEEE 1609.2 certificate 407 6.2. TLS Client uses the IEEE 1609.2 certificate and TLS Server uses 408 the X.509 certificate 410 This example shows the TLS authentication, where the TLS Client 411 populates the server_certificate_type extension with the X.509 412 certificate and Raw Public Key type as presented in figure 3. the 413 client indicates its ability to receive and to validate an X.509 414 certificate from the server. The server chooses the X.509 415 certificate to make its authentication with the Client. 417 Client Server 418 ClientHello, 419 client_certificate_type=(1609Dot2), 420 server_certificate_type=(1609Dot2, 421 X509,RawPublicKey), -----------> ServerHello, 422 {EncryptedExtensions} 423 {client_certificate_type=1609Dot2} 424 {server_certificate_type=X509} 425 {Certificate} 426 {CertificateVerify} 427 {Finished} 428 <--------- [Application Data] 429 {Finished} ---------> 430 [Application Data] <--------> [Application Data] 432 Figure 3: TLS Client uses the IEEE 1609.2 certificate and TLS Server 433 uses the X.509 certificate 435 7. Security Considerations 437 This section provides an overview of the basic security 438 considerations which need to be taken into account before 439 implementing the necessary security mechanisms. The security 440 considerations described throughout [RFC8446] regarding the supported 441 groups and signature algorithms apply here as well. 443 7.1. Securely obtaining certificates from an online repository 445 The certificates used to establish a secure connection may be 446 obtained from an online repository in particular, an online 447 repository may be used to obtain the CA certificates in the chain of 448 either participant in the secure session. ETSI TS 102 449 941[ETSI102941] provides a mechanism that can be used to securely 450 obtain C-ITS certificates. 452 7.2. Expiry of certificates 454 Conventions around certificate lifetime differ between C-ITS 455 certificates and X.509 certificates, and in particular C-ITS 456 certificates may be relatively short-lived compared with typical 457 X.509 certificates. A party to a TLS session that accepts C-ITS 458 certificates MUST check the expiry time in the received C-ITS 459 certificate and SHOULD terminate a session when the certificate 460 received in the handshake expires. We can consider the TLS 461 renegotiation as specified in [RFC8446] and [RFC5246], but an 462 implementation of proposed extension could favor terminating the 463 session on expiry of the the certificate. 465 7.3. Algorithms and cryptographic strength 467 All C-ITS certificates use public-key cryptographic algorithms with 468 an estimated strength of at least 128 bits specifically, Elliptic 469 Curve Cryptography (ECC) based on curves with keys of length 256 bits 470 or longer. An implementation of the techniques specified in this 471 document SHOULD require that if X.509 certificates are used by one of 472 the parties to the session, those certificates are associated with 473 cryptographic algorithms with (pre-quantum-computer) strength of at 474 least 128 bits. 476 7.4. Interpreting C-ITS certificate permissions 478 C-ITS certificates in TLS express the certificate holders permissions 479 using two fields: a Provider Service Identifier (PSID), also known as 480 an ITS Application Identifier (ITS-AID), which identifies a broad set 481 of application activities which provide a context for the certificate 482 holders permissions, and a Service Specific Permissions (SSP) field 483 associated with the PSID, which identifies which specific application 484 activities the certificate holder is entitled to carry out within the 485 broad set of activities identified by that PSID. For example, SAE 486 [SAEJ29453]uses PSID 0204099 to indicate activities around reporting 487 weather and managing weather response activities, and an SSP that 488 states whether the certificate holder is a Weather Data Management 489 System (WDMS, i.e. a central road manager), an ordinary vehicle, or a 490 vehicle belonging to a managed road maintenance fleet. For more 491 information about PSIDs, see [IEEE160912] and for more information 492 about the development of SSPs, see [SAEJ29455] 494 The assumption in this document is that a party that accepts C-ITS 495 certificates will do it in the context of an access control policy 496 that states what PSIDs and SSPs are to be accepted in the handshake, 497 and what activities are permitted within the session based on the 498 PSIDs and SSPs presented in the handshake. [ISO21177] provides a 499 generalization of this where additional certificates may be presented 500 within the context of a TLS session to provide a more complete 501 picture of the permissions of the counterparty within the session, 502 allowing that counterparty to demonstrate its entitlement to a 503 broader range of permissions than those indicated within the single 504 certificate presented within the handshake. An implementation that 505 accepts C-ITS certificates MUST do so in the context of an access 506 policy of this type. 508 7.5. PSID and pduFunctionalType in CertificateVerify 510 The CertificateVerify message for TLS 1.3 is an Ieee1609Dot2Data of 511 type signed, signed using a C-ITS certificate. This certificate may 512 include multiple PSIDs. When a CertificateVerify message of this 513 form is used, the HeaderInfo within the Ieee1609Dot2Data MUST have 514 the pduFunctionalType field present and set to tlsHandshake. The 515 background to this requirement is as follows. A C-ITS certificate 516 may (depending on the definition of the application associated with 517 its PSID(s)) be used to directly sign messages, or to sign TLS 518 CertificateVerify messages, or both. To prevent the possibility that 519 a signature generated in one context could be replayed in a different 520 context i.e., that a message signature could be replayed as a 521 CertificateVerify, or vice versa the pduFunctionalType field provides 522 a statement of intent by the signer as to the intended use of the 523 signed message. If the pduFunctionalType field is absent, the 524 message is a directly signed message for the application and MUST NOT 525 be interpreted as a CertificateVerify. If the pduFunctionalType 526 field is present and set equal to tlsHandshake, the message is a 527 CertificateVerify and MUST NOT be interpreted as a directly signed 528 message for the application. 530 Note that each PSID is owned by an owning organization that has sole 531 rights to define activities associated with that PSID. If an 532 application specifier wishes to expand activities associated with an 533 existing PSID (for example, to include activities over a secure 534 session such as specified in this document), that application 535 specifier must negotiate with the PSID owner to have that 536 functionality added to the official specification of activities 537 associated with that PSID. For new application activities, PSIDs can 538 be requested via IEEE or via ISO TC 204. In particular, note that 539 there is currently no PSID associated to the extension, although such 540 a PSID could be reserved in future if it were found to be useful. 542 8. Privacy Considerations 544 For privacy considerations in a vehicular environment the use of IEEE 545 1609.2/ETSI TS 103097 certificate is recommended for many reasons: 547 In order to address the risk of a personal data leakage, messages 548 exchanged for V2V communications are signed using IEEE 1609.2/ETSI 549 TS 103097 pseudonym certificates 551 The purpose of these certificates is to provide privacy relying on 552 geographical and/or temporal validity criteria, and minimizing the 553 exchange of private data 555 9. IANA Considerations 557 IANA is requested to change the reference for the "1609Dot2" entry 558 when RFC Editor notifies us that they've assigned an RFC number: 559 https://www.iana.org/assignments/tls-extensiontype-values/tls- 560 extensiontype-values.xhtml . 562 10. Acknowledgements 564 The authors wish to thank Eric Rescola , Russ Housley and Ilari 565 Liusvaara for their feedback and suggestions on improving this 566 document. Thanks are due to Sean Turner for his valuable and 567 detailed comments. Special thanks to Panos Kampanakis, Jasja Tijink 568 and Bill Lattin for their guidance and support of the draft. 570 11. Normative References 572 [ETSI102941] 573 "ETSI TS 102 941 : Intelligent Transport Systems (ITS); 574 Security; Trust and Privacy Management", 2018. 576 [IEEE1609.2] 577 "IEEE Standard for Wireless Access in Vehicular 578 Environments - Security Services for Applications and 579 Management Messages", 2016. 581 [IEEE1609.2b] 582 "IEEE Standard for Wireless Access in Vehicular 583 Environments--Security Services for Applications and 584 Management Messages - Amendment 2--PDU Functional Types 585 and Encryption Key Management", 2019. 587 [IEEE160912] 588 "IEEE Standard for Wireless Access in Vehicular 589 Environments Identifier Allocations", December 2016. 591 [ISO21177] 592 "Intelligent transport systems -- ITS station security 593 services for secure session establishment and 594 authentication between trusted devices". 596 [ITU-TX.696] 597 "Procedures for the operation of object identifier 598 registration authorities: General procedures and top arcs 599 of the international object identifier tree", July 2011. 601 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 602 Requirement Levels", March 1997. 604 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 605 (TLS) Protocol Version 1.2", August 2008. 607 [RFC7250] Wouters, P., Tschofenig, H., Weiler, S., and T. Kivinen, 608 "Using Raw Public Keys in Transport Layer Security (TLS) 609 and Datagram Transport Layer Security (DTLS)", June 2014. 611 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 612 2119 Key Words", May 2017. 614 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 615 Version 1.3", August 2018. 617 [SAEJ29453] 618 "Requirements for V2I Weather Applications". 620 [SAEJ29455] 621 "Service Specific Permissions and Security Guidelines for 622 Connected Vehicle Applications". 624 [TS103097] 625 "ETSI TS 103 097 : Intelligent Transport Systems (ITS); 626 Security; Security header and certificate formats". 628 Authors' Addresses 630 Mounira Msahli (editor) 631 Telecom Paris 632 France 634 EMail: mounira.msahli@telecom-paris.fr 636 Nancy Cam-Winget (editor) 637 Cisco 638 USA 640 EMail: ncamwing@cisco.com 642 Ahmed Serhrouchni (editor) 643 Telecom Paris 644 France 646 EMail: ahmed.serhrouchni@telecom-paris.fr 648 Houda Labiod (editor) 649 Telecom Paris 650 France 652 EMail: houda.labiod@telecom-paris.fr 654 William Whyte (editor) 655 Qualcomm 656 USA 658 EMail: wwhyte@qti.qualcomm.com