rfc8902xml2.original.xml   rfc8902.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='UTF-8'?>
<!-- this is version 5 of this xml2rfc template -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.2119.xml">
<!ENTITY rfc2223 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.2223.xml">
<!ENTITY rfc2578 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.2578.xml">
<!ENTITY rfc2579 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.2579.xml">
<!ENTITY rfc2580 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.2580.xml">
<!ENTITY rfc2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.2629.xml">
<!ENTITY rfc3410 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.3410.xml">
<!ENTITY rfc4181 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4181.xml">
]>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<!--<rfc category="std" docName="draft-v2-tls-cert-ETSI-IEEE.txt" ipr="trust2009
02">-->
<!--<rfc category="info" docName="draft-v2-tls-cert-ETSI-IEEE.txt" ipr="trust200
902">-->
<rfc category="exp" docName="draft-msahli-ise-ieee1609-07" ipr="trust200902">
<front>
<!--<title abbrev="IEEE and IETF Certificate Types for TLS">Transport Lay
er Security (TLS) Authentication using ETSI TS 103 097 and IEEE 1609.2 certifica
tes</title>-->
<title abbrev="IEEE and ETSI Certificate Types for TLS"> TLS Authenticati
on using ITS certificate</title>
<author fullname="Mounira Msahli" initials="M.M" role="editor" surname="
Msahli">
<organization> 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.C" role="editor" surname=
"Cam-Winget">
<organization> Cisco</organization>
<address>
<postal>
<street/>
<city/>
<code/>
<country> USA </country>
</postal>
<email>ncamwing@cisco.com</email>
</address>
</author>
<author fullname="William Whyte" initials="W.W" role="editor" surname="Wh
yte">
<organization> Qualcomm</organization>
<address>
<postal>
<street/>
<city/>
<code/>
<country> USA </country>
</postal>
<email>wwhyte@qti.qualcomm.com</email>
</address>
</author>
<author fullname="Ahmed Serhrouchni " initials="A.S" surname="Serhrouchni">
<organization>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.L" surname="Labiod">
<organization>Telecom Paris </organization>
<address>
<postal>
<street/>
<city/>
<code/>
<country> France </country>
</postal>
<email>houda.labiod@telecom-paris.fr</email>
</address>
</author>
<date/>
<workgroup/>
<abstract>
<t>
The IEEE and ETSI have specified a type of end-entity certificates. This docum
ent defines an experimental change to TLS to support IEEE/ETSI certificate types
to authenticate TLS entities. </t>
</abstract>
</front> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<middle> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" number="8902" category="exp"
docName="draft-msahli-ise-ieee1609-07" ipr="trust200902"
obsoletes="" updates="" submissionType="independent" xml:lang="en"
tocInclude="true" symRefs="true" sortRefs="true" version="3" >
<section title="Introduction"> <front>
<t>The TLS protocol [RFC8446] allows the use of X.509 certificates and Raw Pub <title abbrev="IEEE and ETSI Certificate Types for TLS"> TLS Authentication
lic Key to authenticate servers and clients. This document describes an experime Using Intelligent Transport System (ITS) Certificates</title>
ntal extension following the procedures laid out by [RFC7250] to support use of <seriesInfo name="RFC" value="8902"/>
the certificate format specified by the IEEE in [IEEE1609.2] and profiled by <author fullname="Mounira Msahli" initials="M" role="editor" surname="Msahli
the European Telecommunications Standards Institute (ETSI) in [TS103097]. These ">
standards specify secure communications in vehicular environments. These certifi <organization> Telecom Paris</organization>
cates are referred to in this document as Intelligent Transportation Systems (IT <address>
S) Certificates.</t> <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> 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> 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>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>Telecom Paris </organization>
<address>
<postal>
<street/>
<city/>
<code/>
<country>France </country>
</postal>
<email>houda.labiod@telecom-paris.fr</email>
</address>
</author>
<date month="September" year="2020"/>
<workgroup/>
<t>The certificate types are optimized for bandwidth and processing time to s <keyword>TLS</keyword>
upport delay-sensitive applications, and also to provide both authentication and <keyword>Intelligent Transport System (ITS) Certificates</keyword>
authorization information to enable fast access control decisions <keyword>IEEE</keyword>
in ad hoc networks such as are found in Intelligent Transportation Systems (I <keyword>ETSI</keyword>
TS). The standards specify different types of certificate to support a full Publ
ic Key Infrastructure (PKI)
specification; the certificates to be used in this context are end-entity cert
ificates, i.e. certificates that have the IEEE 1609.2 appPermissions field prese
nt.</t>
<t> Use of ITS certificates is becoming widespread in the ITS setting. ITS comm <abstract>
unications in practice make heavy use of 10 MHz channels with a typical throughp <t>
ut of 6 Mbps. (The 802.11OCB modulation that gives
this throughput is not the one that gives the highest throughput, but it prov
ides 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>The ITS certificates are also suited to the M2M ad hoc network setting, becau The IEEE and ETSI have specified a type of end-entity certificate. This docume
se their direct encoding of permissions (see Security Considerations, section 7. nt defines an experimental change to TLS to support IEEE/ETSI certificate types
4) allows a receiver to make an immediate accept/deny decision about an incoming to authenticate TLS entities. </t>
message </abstract>
without having to refer to a remote identity and access management server. The E </front>
U has committed to the use of ITS certificates in Cooperative Intelligent Transp <middle>
ortation Systems deployments. A multi-year project developed a certificate polic <section numbered="true" toc="default">
y for the use <name>Introduction</name>
of ITS certificates, including a specification of how different root certificate <t>The TLS protocol <xref target="RFC8446"/> allows the use of X.509
s can be trusted across the system (hosted at https://ec.europa.eu/transport/the certificates and raw public keys to authenticate servers and
mes/its/c-its_en, direct link at https://ec.europa.eu/transport/sites/transport/ clients. This document describes an experimental extension following the
files/c-its_certificate_policy_release_1.pdf).</t> procedures laid out by <xref target="RFC7250"/> to support use of the cert
ificate
format specified by the IEEE in <xref target="IEEE1609.2"/> and profiled b
y the
European Telecommunications Standards Institute (ETSI) in <xref
target="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>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> The EU has committed funding for the first five years of operation of the to <t>Use of ITS certificates is becoming widespread in the ITS
p-level Trust List Manager entity, enabling organizations such as motor vehicle setting. ITS communications, in practice, make heavy use of 10 MHz
OEMs and national road authorities to create root CAs and have them trusted. In channels with a typical throughput of 6 Mbps. (The 802.11OCB modulation
the US, the US Department of Transportation (USDOT) published a proposed regulat that gives this throughput is not the one that gives the highest
ion, which as of late 2019, is active though not rapidly progressing, which woul throughput, but it provides for a robust signal over a range up to
d require all light vehicles in the US to implement V2X communications including 300-500 m, which is the "sweet spot" communications range for ITS
the use of ITS certificates (available from https://www.federalregister.gov/doc operations like collision avoidance). The compact nature of ITS
uments/2017/01/12/2016-31059/federal-motor-vehicle-safety-standards-v2v-communic certificates as opposed to X.509 certificates makes them appropriate for
ations). As of 2019, ITS deployments across the US, Europe and this setting. </t>
Australia were using ITS certificates. Volkswagen have committed to deploying V2 <t>The ITS certificates are also suited to the machine-to-machine (M2M)
X using ITS certificates. New York, Tampa and Wyoming are deploying traffic mana ad hoc network setting because their direct encoding of permissions (see
gement systems using ITS certificates. GM deployed V2X in their Cadillac CTSes u <xref target="ITS-permissions"/>) allows a receiver to make an immediate
sing ITS certificates.</t> 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"/>&gt;,
direct link at &lt;<eref
target="https://ec.europa.eu/transport/sites/transport/files/c-its_certifi
cate_policy_release_1.pdf"/>&gt;).</t>
<t> ITS certificates are also used in a number of standards that build on top of <t> The EU has committed funding for the first five years of operation
the foundational IEEE and ETSI standards, particularly the SAE J2945/x series o of the top-level Trust List Manager entity, enabling organizations such
f standards for applications and ISO 21177, which builds a framework for exchang as motor vehicle original equipment manufacturers (OEMs) and national
ing multiple authentication tokens on top of the TLS variant specified in this d road authorities to create root certificate authorities (CAs) and have
ocument. 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/fe
deral-motor-vehicle-safety-standards-v2v-communications"/>&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> 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"/>, which builds a frame
work for exchanging
multiple authentication tokens on top of the TLS variant specified in
this document.
</t> </t>
<section numbered="true" toc="default">
<name>Experiment Overview</name>
<section title="Experiment Overview"> <t>This document describes an experimental extension to the TLS
security model. It uses a form of certificate that has not previously
<t>This document describes an experimental extension to the TLS security model. been used in the Internet. Systems using this Experimental approach
It uses a form of certificate that has not previously been used in the Internet are segregated from systems using standard TLS by the use of a new
. Systems using this Experimental approach are segregated from system using sta certificate type value, reserved through IANA (see <xref
ndard TLS by the use of a new target="IANA"/>). An implementation of TLS that is not involved in
Certificate Type value, reserved through IANA (see Section 9). An implementa the Experiment will not recognize this new certificate type and will
tion of TLS that is not involved in the Experiment will not recognise this new C not participate in the experiment; TLS sessions will either negotiate
ertificate Type and will not participate in the experiment: TLS sessions will ei the use of existing X.509 certificates or fail to be established. </t>
ther negotiate <t>This extension has been encouraged by stakeholders in the
the use of existing X.509 certificates or fail to be established. </t> Cooperative ITS community in order to support ITS use-case
deployment, and it is anticipated that its use will be widespread. </t>
<t>This extension has been encouraged by stakeholders in the Cooperative ITS c </section>
ommunity in order to support the ITS use cases deployment and it is anticipated
that its use will be widespread. </t>
</section>
</section>
<section title="Requirements Terminology"> </section>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL <section numbered="true" toc="default">
NOT", <name>Requirements Terminology</name>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",
and "OPTIONAL" in this document
are to be interpreted as described in BCP 14 [RFC2119] <xref targ
et="RFC8174"/> when, and only when, they appear in all
capitals, as shown here. </t>
</section>
<section title="Extension Overview"> <t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</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&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
<t> The TLS extension "client_certificate_type" and "server_certificate_ </section>
type" [RFC7250] are used to negotiate the type of Certificate messages used in T <section numbered="true" toc="default">
LS to authenticate the server and, optionally, the client. Using separate extens <name>Extension Overview</name>
ion allows for mixed deployments where client and server can use certificates of <t> The TLS extensions "client_certificate_type" and
different types. It is expected that ITS "server_certificate_type" <xref target="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 o f the ecosystem, but there is no barrier at a technical level that prevents mixe d certificate usage. This document defines a new certificate type, 1609Dot2, for usage with deployments will see both peers using ITS certificates due to the homogeneity o f the ecosystem, but there is no barrier at a technical level that prevents mixe d certificate usage. This document defines a new certificate type, 1609Dot2, for usage with
TLS 1.3. The updated CertificateType enumeration and corresponding addition to t he CertificateEntry structure are shown below. CertificateType values are sent i n the "server_certificate_type" and "client_certificate_type" extension, and the CertificateEntry TLS 1.3. The updated CertificateType enumeration and corresponding addition to t he CertificateEntry structure are shown below. CertificateType values are sent i n the "server_certificate_type" and "client_certificate_type" extensions, and th e CertificateEntry
structures are included in the certificate chain sent in the Certificate messag e. structures are included in the certificate chain sent in the Certificate messag e.
In case of TLS 1.3, the "client_certificate_type " SHALL contain a list o In the case of TLS 1.3, the "client_certificate_type" <bcp14>SHALL</bcp14
f supported certificate types proposed by the client as provided in the figure b > contain a list of supported certificate types proposed by the client as provid
elow: ed in the figure below:
<figure>
<artwork>
</t>
<sourcecode>
/* Managed by IANA */ /* Managed by IANA */
enum { enum {
X509(0), X509(0),
RawPublicKey(2), RawPublicKey(2),
1609Dot2(3), 1609Dot2(3),
(255) (255)
} CertificateType; } CertificateType;
struct { struct {
select (certificate_type) { select (certificate_type) {
/* certificate type defined in this document.*/ /* certificate type defined in this document.*/
case 1609Dot2: case 1609Dot2:
opaque cert_data&lt;1..2^24-1&gt;; opaque cert_data&lt;1..2^24-1>;
/* RawPublicKey defined in RFC 7250*/ /* RawPublicKey defined in RFC 7250*/
case RawPublicKey: case RawPublicKey:
opaque ASN.1_subjectPublicKeyInfo&lt;1..2^24-1&gt;; opaque ASN.1_subjectPublicKeyInfo&lt;1..2^24-1>;
/* X.509 certificate defined in RFC 5246*/ /* X.509 certificate defined in RFC 8446*/
case X.509: case X.509:
opaque cert_data&lt;1..2^24-1&gt;; opaque cert_data&lt;1..2^24-1>;
}; };
Extension extensions&lt;0..2^16-1&gt;; Extension extensions&lt;0..2^16-1>;
} CertificateEntry; } CertificateEntry;
</artwork> </sourcecode>
</figure></t>
<t> As per [RFC7250], the server processes the received [endpoint]_certificate_
type extension(s) and selects one of the offered certificate types, returning th
e 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_c
ertificate_type and server_certificate_type extensions sent in the same message.
</t>
</section>
<section title="TLS Client and Server Handshake">
<t> Figure 1 shows the handshake message flow for a full TLS 1.3 handshak
e negotiating both certificate types.
<figure anchor="msg_flow" title="Message Flow with certificate ty
pe extension for Full TLS 1.3 Handshake">
<artwork>
<t> As per <xref target="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="default">
<name>TLS Client and Server Handshake</name>
<t><xref target="msg_flow"/> shows the handshake message flow for a full T
LS 1.3 handshake negotiating both certificate types.
</t>
<figure anchor="msg_flow">
<name>Message Flow with Certificate Type Extension for Full TLS 1.3 Hand
shake</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
Client Server Client Server
Key ^ ClientHello Key ^ ClientHello
Exch | + server_certificate_type* Exch | + server_certificate_type*
| + client_certificate_type* | + client_certificate_type*
| + key_share* | + key_share*
v + signature_algorithms* --------&gt; v + signature_algorithms* -------->
ServerHello ^ Key ServerHello ^ Key
+ key_share* v Exch + key_share* v Exch
{EncryptedExtensions} ^ Server {EncryptedExtensions} ^ Server
{+ server_certificate_type*}| Params {+ server_certificate_type*}| Params
{+ client_certificate_type*}| {+ client_certificate_type*}|
{CertificateRequest*} v {CertificateRequest*} v
{Certificate*} ^ {Certificate*} ^
{CertificateVerify*} | Auth {CertificateVerify*} | Auth
{Finished} v {Finished} v
&lt;------- [Application Data*] <------- [Application Data*]
^ {Certificate*} ^ {Certificate*}
Auth | {CertificateVerify*} Auth | {CertificateVerify*}
v {Finished} --------&gt; v {Finished} -------->
[Application Data] &lt;-------&gt; [Application Data] [Application Data] <-------> [Application Data]
+ Indicates noteworthy extensions sent in the + Indicates noteworthy extensions sent in the
previously noted message. previously noted message.
* Indicates optional or situation-dependent * Indicates optional or situation-dependent
messages/extensions that are not always sent. messages/extensions that are not always sent.
{} Indicates messages protected using keys {} Indicates messages protected using keys
derived from a [sender]_handshake_traffic_secret. derived from a [sender]_handshake_traffic_secret.
[] Indicates messages protected using keys [] Indicates messages protected using keys
derived from [sender]_application_traffic_secret_N. derived from [sender]_application_traffic_secret_N.
]]></artwork>
</figure>
<t> 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="default">
<name>Client Hello</name>
<t>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"/> (TLS 1.3).</t>
</artwork> <t>For TLS 1.3, the rules for when the Client Certificate and
</figure></t> CertificateVerify messages appear are as follows:
<t> In the case of TLS 1.3, in order to negotiate the support of ITS certific
ate-based authentication, clients and servers include the extension of type "cli
ent_certificate_type"
and "server_certificate_type" in the extended Client Hello and "EncryptedExte
nsions".</t>
<section title="Client Hello">
<t>In order to indicate the support of ITS certificates,
a client MUST include an extension of type "client_certif
icate_type" or "server_certificate_type" in the extended
Client Hello message as described in
Section 4.1.2 of TLS 1.3 <xref target="RFC8446"/>.</t>
<t>For both TLS 1.3, the rules for when the Client Certificate and CertificateV
erify messages appear are as follows:
<list style="symbolSSi">
<t> - The client's Certificate message is present if and only if the
server sent a CertificateRequest message.</t>
<t> - The client's CertificateVerify message is present if and only i
f the client's Certificate message is present and contains a non-empty certifica
te_list.</t>
</list>
</t>
<t> For maximum compatibility, all implementations SHOULD be prepared to handle
"potentially" extraneous certificates and arbitrary orderings from any TLS versi
on, with the exception of the end-entity certificate which MUST be first. </t>
</section>
<section title="Server Hello">
<t> When the server receives the Client Hello containing the client_certificate
_type extension and/or the server_certificate_type extension, the following scen
arios are possible:
<list style="symbolSSi">
<t> - If both client and server indicate support for the ITS certific
ate type, the server MAY select the first (most preferred) certificate type from
the client's list that is supported by both peers </t>
<t> - The server does not support any of the proposed certificate typ
es and terminates the session with a fatal alert of type "unsupported_certificat
e".</t>
<t> - The server supports the certificate types specified in this document. I
n 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 CertificateR
equest message ) </t>
</list>
</t>
<t>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 mi
ght already be known to and cached at the endpoint.
If the handshake does not contain all the certificates in the chain, and the end
point cannot access the repository, and the endpoint does not already know the c
ertificates from the chain, then it SHALL reject the
other endpoint&#8217;s certificate and close the connection. Protocols to suppor
t retrieving certificates from a repository are specified in ETSI<xref target="E
TSI102941"/>.</t>
</section>
</section>
<section title="Certificate Verification">
<!--<t>#Are there trust anchors, pre-loaded lists, standard verification
policies, TOFU approaches, or other regimes for validating these
certificates? "best practices" for certificate validation: pki memo,
scoopf (Lamia :P), PRESERVE... #</t>-->
<t>Verification of an ITS certificates or certificate chain is described in se
ction 5.1 of <xref target=" IEEE1609.2"/>. In the case of TLS 1.3 and when the c
ertificate_type is 1609.2, the
CertificateVerify contents and processing are different than for the Certific
ateVerify message specified for other values of certificate_type in [RFC8446]. I
n this case, the CertificateVerify message contains a Canonical Octet Encoding R
ules <xref target="ITU-TX.696"/>
-encoded IEEE1609Dot2Data of type signed as specified in [IEEE1609.2], [IEEE1
609.2b], where:
<list style="symbolSSi">
<t> Payload contains an extDataHash containing the SHA-256 hash of the data th
e 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.</
t>
<t> Provider Service Identifier (Psid) indicates the application activity th
at the certificate is authorizing.</t>
<t> generationTime is the time at which the data structure was generated.</t>
<t>PduFunctionalType (as specified in [IEEE1609.2b]) is present and is set equ
al to tlsHandshake (1).</t>
</list>
All other fields in the headerInfo are omitted. The certificate appPermission
s 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 s
igning 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.</
t>
<t>The certificate appPermissions field SHALL be present and SHALL permit (a
s defined in IEEE 1609.2) signing of PDUs with the PSID indicated
in the HeaderInfo of the SignedData. If the application specification for tha
t PSID requires Service Specific Permissions (SSP) for signing a pduFunctionalTy
pe of tlsHandshake, this SSP SHALL also be present.</t>
<t>The signature and verification are carried out as specified in [IEEE1609.2]
.</t>
<t> The input to the hash process is identical to the message input for TLS 1 </t>
.3, as specified in [RFC8446] section 4.4.3, consisting of pad, context string, <ul spacing="normal">
separator and content, where content is Transcript-Hash(Handshake Context, Certi <li>The client's Certificate message is present if and only if
ficate). </t> the server sent a CertificateRequest message.</li>
<li>The client's CertificateVerify message is present if and only if t
he client's Certificate message is present and contains a non-empty certificate_
list.</li>
</ul>
<t> 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="default">
<name>Server Hello</name>
<t> When the server receives the Client Hello containing the client_cert
ificate_type extension and/or the server_certificate_type extension, the followi
ng scenarios are possible:
</section> </t>
<ul spacing="normal">
<li>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>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>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>
<section title="Examples"> <t>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"/>.</t>
</section>
</section>
<section numbered="true" toc="default">
<name>Certificate Verification</name>
<t>Some of message-exchange examples are illustrated in Figures 2 and 3. <t>Verification of an ITS certificate or certificate chain is described in
</t> section 5.1 of <xref target="IEEE1609.2" format="default"/>. 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"/>. In this case, the CertificateVerify message contains an
Ieee1609Dot2Data encoded with Canonical Octet Encoding Rules (OER)
<xref target="ITU-TX.696" format="default"/>
of type signed as specified in <xref target="IEEE1609.2"/> and <xref
target="IEEE1609.2b"/>, where:
<section title="TLS Server and TLS Client use the ITS Certificate"> </t>
<t>This section shows an example where the TLS client as well as the TLS server <ul spacing="normal">
use ITS certificates. In consequence, both the <li>payload contains an extDataHash containing the SHA-256 hash of
server and the client populate the client_certificate_type and server_certificat the data that the signature is calculated over. This is identical to the
e_type extension with the IEEE 1609 Dot 2 type as mentioned in figure 2. data that the signature is calculated over in standard TLS, which
is reproduced below for clarity.</li>
<li>headerInfo.psid indicates the application
activity that the certificate is authorizing.</li>
<li>headerInfo.generationTime is the time at which the data structure wa
s generated.</li>
<li>headerInfo.pduFunctionalType (as specified in <xref target="IEEE1609
.2b"/>)
is present and is set equal to tlsHandshake (1).</li>
</ul>
<t>
<figure anchor="msg_fltw" title="TLS Client and TLS Server use the ITS ce All other fields in the headerInfo are omitted. The certificate
rtificate"> appPermissions field <bcp14>SHALL</bcp14> be present and
<bcp14>SHALL</bcp14> permit (as defined in <xref target="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"/>, clauses 5.1.1 and
5.2.3.3.3. All other fields in the headerInfo are omitted.</t>
<t>The certificate appPermissions field <bcp14>SHALL</bcp14> be present an
d <bcp14>SHALL</bcp14>
permit (as defined in <xref target="IEEE1609.2"/>) signing of PDUs with th
e 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</bc
p14> also be
present.</t>
<t>The signature and verification are carried out as specified in <xref ta
rget="IEEE1609.2"/>.</t>
<t> 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"/>, consisting of pad, context string, separator, and
content, where content is Transcript-Hash(Handshake Context,
Certificate).</t>
<artwork> </section>
<section numbered="true" toc="default">
<name>Examples</name>
<t>Some of the message-exchange examples are illustrated in Figures
<xref target="msg_fltw" format="counter"/> and <xref
target="msg_fluw" format="counter"/>.</t>
<section numbered="true" toc="default">
<name>TLS Server and TLS Client Use the ITS Certificate</name>
<t>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"/>.
</t>
<figure anchor="msg_fltw">
<name>TLS Client and TLS Server Use the ITS Certificate</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
Client Server Client Server
ClientHello, ClientHello,
client_certificate_type=1609Dot2, client_certificate_type=1609Dot2,
server_certificate_type=1609Dot2, --------&gt; ServerHello, server_certificate_type=1609Dot2, --------> ServerHello,
{EncryptedExtensions} {EncryptedExtensions}
{client_certificate_type=1609Dot2} {client_certificate_type=1609Dot2}
{server_certificate_type=1609Dot2} {server_certificate_type=1609Dot2}
{CertificateRequest} {CertificateRequest}
{Certificate} {Certificate}
{CertificateVerify} {CertificateVerify}
{Finished} {Finished}
{Certificate} &lt;------- [Application Data] {Certificate} <------- [Application Data]
{CertificateVerify} {CertificateVerify}
{Finished} --------&gt; {Finished} -------->
[Application Data] &lt;-------&gt; [Application Data] [Application Data] <-------> [Application Data]
]]></artwork>
</artwork> </figure>
</figure></t> </section>
</section> <section numbered="true" toc="default">
<section title="TLS Client uses the ITS certificate and TLS Server uses the X.50 <name>TLS Client Uses the ITS Certificate and TLS Server Uses the X.509
9 certificate"> Certificate</name>
<t> This example shows the TLS authentication, where the TLS client
<t> This example shows the TLS authentication, where the TLS Client popul populates the server_certificate_type extension with the X.509
ates the certificate and raw public key type as presented in <xref
server_certificate_type extension with the X.509 certificate and Raw target="msg_fluw"/>. The client indicates its ability to receive and
Public Key type as presented in figure 3. The client indicates its ability to validate an X.509 certificate from the server. The server chooses the
receive and to validate an X.509 certificate X.509 certificate to make its authentication with the client. This is
from the server. The server chooses the X.509 certificate to make its authent applicable in the case of a raw public key supported by the server.
ication with the Client. This is applicable in case of Raw Public Key supported
by the server.
<figure anchor="msg_fluw" title="TLS Client uses the ITS certific </t>
ate and TLS Server uses the X.509 certificate"> <figure anchor="msg_fluw">
<artwork> <name>TLS Client Uses the ITS Certificate and TLS Server Uses the X.50
9 Certificate</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
Client Server Client Server
ClientHello, ClientHello,
client_certificate_type=(1609Dot2), client_certificate_type=(1609Dot2),
server_certificate_type=(1609Dot2, server_certificate_type=(1609Dot2,
X509,RawPublicKey), -----------&gt; ServerHello, X509,RawPublicKey), -----------> ServerHello,
{EncryptedExtensions} {EncryptedExtensions}
{client_certificate_type=1609Dot2} {client_certificate_type=1609Dot2}
{server_certificate_type=X509} {server_certificate_type=X509}
{CertificateRequest} {CertificateRequest}
{Certificate} {Certificate}
{CertificateVerify} {CertificateVerify}
{Finished} {Finished}
&lt;--------- [Application Data] <--------- [Application Data]
{Finished} ---------&gt; {Finished} --------->
[Application Data] &lt;--------&gt; [Application Data] [Application Data] <--------> [Application Data]
]]></artwork>
</artwork> </figure>
</figure></t> </section>
</section> </section>
</section> <section numbered="true" toc="default">
<name>Security Considerations</name>
<section title="Security Considerations"> <t>This section provides an overview of the basic security
<t>This section provides an overview of the basic security considerations which considerations that need to be taken into account before implementing
need to be taken into account before the necessary security mechanisms. The security considerations described
implementing the necessary security mechanisms. The security considerations desc throughout <xref target="RFC8446" format="default"/> apply here as
ribed throughout <xref target="RFC8446"/> apply here as well.</t> well.</t>
<section title="Securely Obtaining Certificates from an Online Repository"> <section numbered="true" toc="default">
<name>Securely Obtaining Certificates from an Online Repository</name>
<t>In particular, the certificates used to establish a secure connection MAY be <t>In particular, the certificates used to establish a secure connection
obtained from an online repository. An online repository may be used to obtain t <bcp14>MAY</bcp14> be obtained from an online repository. An online repository
he CA certificates in the chain of either participant in the secure session. may be used to obtain the CA certificates in the chain of either participant in
ETSI TS 102 941 <xref target="ETSI102941"/> provides a mechanism that can be use the secure session.
d to securely obtain ITS certificates.</t> ETSI TS 102 941 <xref target="TS102941" format="default"/> provides a mechanism
that can be used to securely obtain ITS certificates.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Expiry of Certificates"> <name>Expiry of Certificates</name>
<t>Conventions around certificate lifetime differ between ITS
<t>Conventions around certificate lifetime differ between ITS certificates and X certificates and X.509 certificates, and in particular, ITS
.509 certificates, and in particular ITS certificates may be relatively short-li certificates may be relatively short lived compared with typical X.509
ved compared with typical X.509 certificates. A party to a TLS session that acce certificates. A party to a TLS session that accepts ITS certificates
pts ITS <bcp14>MUST</bcp14> check the expiry time in the received ITS
certificates MUST check the expiry time in the received ITS certificate and SHOU certificate and <bcp14>SHOULD</bcp14> terminate a session when the
LD terminate a session when the certificate received in the handshake expires. < certificate received in the handshake expires. </t>
/t> </section>
<section numbered="true" toc="default">
</section> <name>Algorithms and Cryptographic Strength</name>
<t> All ITS certificates use public-key cryptographic algorithms with
<section title="Algorithms and Cryptographic Strength"> an estimated strength on the order of 128 bits or more, specifically,
Elliptic Curve Cryptography (ECC) based on curves with keys of length
<t> All ITS certificates use public-key cryptographic algorithms with an estimat 256 bits or longer. An implementation of the techniques specified in
ed strength on the order this document <bcp14>SHOULD</bcp14> require that if X.509 certificates
of 128 bits or more, specifically, Elliptic Curve Cryptography (ECC) based on cu are used by one of the parties to the session, those certificates are
rves with keys of length 256 bits or longer. An implementation of the techniques associated with cryptographic algorithms with (pre-quantum-computer)
specified in this document strength of at least 128 bits.</t>
SHOULD require that if X.509 certificates are used by one of the parties to the </section>
session, those certificates are associated with cryptographic algorithms with (p <section anchor="ITS-permissions" numbered="true" toc="default">
re-quantum-computer) strength of at least 128 bits.</t> <name>Interpreting ITS Certificate Permissions</name>
<t> ITS certificates in TLS express the certificate holders
</section> permissions using two fields: a PSID, also known as an ITS Application
Identifier (ITS-AID), which identifies a broad set of application
<section title="Interpreting ITS Certificate Permissions"> activities that provide a context for the certificate holder's
permissions, and a Service Specific Permissions (SSP) field associated
<t> ITS certificates in TLS express the certificate holders permissions using tw with that PSID, which identifies which specific application activities
o fields: a PSID, also known as an ITS Application Identifier (ITS-AID), which i the certificate holder is entitled to carry out within the broad set
dentifies a broad set of application activities which provide a context for of activities identified by that PSID. For example, SAE <xref
the certificate holder's permissions, and a Service Specific Permissions (SSP) f target="SAEJ29453" format="default"/> uses PSID 0204099 to indicate
ield associated with that PSID, which identifies which specific application acti activities around reporting weather and managing weather response
vities the certificate holder is entitled to carry out within the broad set of a activities, and an SSP that states whether the certificate holder is a
ctivities identified by that PSID. Weather Data Management System (WDMS, i.e., a central road manager),
For example, SAE <xref target="SAEJ29453"/> uses PSID 0204099 to indicate activ an ordinary vehicle, or a vehicle belonging to a managed road
ities around reporting weather and managing weather response activities, and an maintenance fleet. For more information about PSIDs, see <xref
SSP that states whether the certificate holder is a Weather Data Management Syst target="IEEE1609.12" format="default"/>, and for more information about
em the development of SSPs, see <xref target="SAEJ29455"
(WDMS, i.e. a central road manager), an ordinary vehicle, or a vehicle belongin format="default"/>.</t>
g to a managed road maintenance fleet. For more information about PSIDs, see <xr </section>
ef target="IEEE16092"/> and for more information about the development of SSPs, <section numbered="true" toc="default">
see <xref target="SAEJ29455"/></t> <name>Psid and Pdufunctionaltype in CertificateVerify</name>
</section>
<section title="Psid and Pdufunctionaltype in CertificateVerify">
<t> The CertificateVerify message for TLS 1.3 is an Ieee1609Dot2Data of type sig
ned, signed using an ITS certificate. This certificate may include multiple PSID
s. When a CertificateVerify message of this form is used, the HeaderInfo within
the Ieee1609Dot2Data MUST have the pduFunctionalType field present and set to tl
sHandshake. 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.</t>
<t> 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 wish
es to expand activities associated with an existing PSID (for example, to includ
e 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 act
ivities associated with that PSID.</t>
</section>
</section>
<section title="Privacy Considerations">
<t>For privacy considerations in a vehicular environment the ITS certificate is
used for many reasons:
<list style="symbolsi">
<t>In order to address the risk of a personal data leakag
e, messages exchanged for V2V communications are signed using ITS pseudonym cert
ificates</t>
<t>The purpose of these certificates is to provide privac
y and minimize the exchange of private data</t>
</list>
</t>
</section>
<section title="IANA Considerations">
<t>IANA maintains the "Transport Layer Security (TLS) Extensions" registr <t> The CertificateVerify message for TLS 1.3 is an Ieee1609Dot2Data
y with a subregistry called "TLS Certificate Types".</t> 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> 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="default">
<name>Privacy Considerations</name>
<t>For privacy considerations in a vehicular environment, the ITS
certificate is used for many reasons:
</t>
<ul spacing="normal">
<li>In order to address the risk of a personal data leakage, messages
exchanged for vehicle-to-vehicle (V2V) communications are signed using I
TS pseudonym
certificates.</li>
<li>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="default">
<name>IANA Considerations</name>
<t>IANA maintains the "Transport Layer Security (TLS) Extensions"
registry with a subregistry called "TLS Certificate Types".</t>
<t>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>
<t>IANA has previously assigned an entry (value 3) for "1609Dot2" with referen
ce set to draft-tls-certieee1609. IANA is requested to update
that entry to reference the RFC number of this document when it is published.
</t>
<!--<t>IANA is also asked to register two new values in the "TLS ClientCertif
icateType
Identifiers Registry", as follows:
<list style="symbols">
<t>TBD</t>
<t>TBD</t>
</list></t>-->
</section> </section>
<section anchor="ack" title="Acknowledgements"> </middle>
<back>
<t>The authors wish to thank Adrian Farrel , Eric Rescola , Russ Housley, Ilar <references>
i Liusvaara and Benjamin Kaduk for their feedback and suggestions on improving t <name>Normative References</name>
his 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.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="TS103097">
<front>
<title>
ETSI TS 103 097 : Intelligent Transport
Systems (ITS); Security; Security header and cert
ificate formats</title>
<author surname="ETSI"/>
<date year=""/>
</front>
</reference>
<reference anchor="ETSI102941">
<front>
<title>
ETSI TS 102 941 : Intelligent Transport Systems (
ITS); Security; Trust and Privacy Management </title>
<author surname="ETSI"/>
<date year="2018"/>
</front>
</reference>
<reference anchor="IEEE1609.2">
<front>
<title>IEEE Standard for Wireless Access in
Vehicular Environments - Security Services for Ap
plications and
Management Messages</title>
<author surname="IEEE"/>
<date year="2016"/>
</front>
</reference>
<reference anchor="IEEE1609.2b"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.
<front> xml"/>
<title> IEEE Standard for Wireless Access in Vehi <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.
cular Environments--Security Services for Applications and Management Messages - xml"/>
Amendment 2--PDU Functional Types and Encryption Key Management </title> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.
<author surname="IEEE"/> xml"/>
<date year="2019"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7250.
</front> xml"/>
</reference>
<reference anchor="RFC2119"> <reference anchor="TS103097">
<front> <front>
<title>Key words for use in RFCs to Indicate <title>Intelligent Transport Systems (ITS); Security; Security
Requirement Levels</title> header and certificate formats</title>
<author initials="S." surname="Bradner"/> <author>
<date month="March" year="1997"/> <organization>ETSI
</front> </organization>
</reference> </author>
<date>2017</date>
</front>
<refcontent>ETSI TS 103 097</refcontent>
</reference>
<reference anchor="RFC8446"> <reference anchor="TS102941">
<front> <front>
<title>The Transport Layer Security <title>
(TLS) Protocol Version 1.3</title> Intelligent Transport Systems (ITS); Security; Trust and
<author initials="E." surname="Rescorla"/> Privacy Management </title>
<date month="August" year="2018"/> <author>
</front> <organization>ETSI</organization>
</reference> </author>
<date year="2018"/>
</front>
<refcontent>ETSI TS 102 941</refcontent>
</reference>
<reference anchor="RFC8174"> <reference anchor="IEEE1609.2">
<front> <front>
<title>Ambiguity of Uppercase vs Lowercase in RFC <title>IEEE Standard for Wireless Access in Vehicular Environments --
2119 Key Words</title> Security Services for Applications and Management Messages</title>
<author initials="B." surname="Leiba"/> <author>
<date month="May" year="2017"/> <organization>IEEE</organization>
</front> </author>
</reference> <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="RFC7250"> <reference anchor="IEEE1609.2b">
<front> <front>
<title> Using Raw Public Keys in Transport Layer <title>
Security (TLS) IEEE Standard for Wireless Access in Vehicular Environments--Security Services
and Datagram Transport Layer Security (DTLS)</title> for Applications and Management Messages - Amendment 2--PDU Functional Types
<author initials="P." surname="Wouters"/> and Encryption Key Management
<author initials="H." surname="Tschofenig"/> </title>
<author initials="S." surname="Weiler"/> <author>
<author initials="T." surname=" Kivinen"/> <organization>IEEE</organization>
<date month="June" year="2014"/> </author>
</front> <date month="June" year="2019"/>
</reference> </front>
<refcontent>IEEE 1609.2b-2019</refcontent>
</reference>
<reference anchor="ITU-TX.696"> <reference anchor="ITU-TX.696">
<front> <front>
<title> Procedures for the operation of object id <title>Information technology - ASN.1 encoding rules: Specification
entifier registration authorities: General procedures and top arcs of the intern of Octet Encoding Rules (OER)
ational object identifier tree </title> </title>
<author initials="INTERNATIONAL STANDARD ISO " surname=""/> <author>
<date month="July" year="2011"/> <organization>ITU-T</organization>
</front> </author>
</reference> <date month="August" year="2015"/>
</front>
<refcontent>Recommendation ITU-T X.696</refcontent>
</reference>
<reference anchor="IEEE16092"> <reference anchor="IEEE1609.12">
<front> <front>
<title> IEEE Standard for Wireless Access in Vehi <title>IEEE Standard for Wireless Access in Vehicular Environments
cular Environments Identifier Allocations </title> (WAVE) - Identifier Allocations</title>
<author initials="IEEE " surname=""/> <author>
<date month="December" year="2016"/> <organization>IEEE</organization>
</front> </author>
</reference> <date month="December" year="2016"/>
</front>
<refcontent>IEEE 1609.12-2016</refcontent>
</reference>
<reference anchor="ISO21177"> <reference anchor="ISO21177">
<front> <front>
<title> Intelligent transport systems -- ITS stat <title>Intelligent transport systems - ITS station security services
ion security services for secure session establishment and authentication betwee for secure session establishment and authentication between trusted dev
n trusted devices </title> ices</title>
<author initials="INTERNATIONAL STANDARD ISO " surname=""/> <author>
<date month="" year=""/> <organization>ISO</organization>
</front> </author>
</reference> <date month="08" year="2019"/>
</front>
<refcontent>ISO/TS 21177:2019</refcontent>
</reference>
<reference anchor="SAEJ29453"> <reference anchor="SAEJ29453">
<front> <front>
<title> Requirements for V2I Weather Applications <title>Requirements for V2I Weather Applications</title>
</title> <author>
<author initials=" SAE " surname=""/> <organization>SAE
<date month="" year=""/> </organization>
</front> </author>
</reference> <date month="06" year="2017"/>
</front>
<refcontent>J2945/3</refcontent>
</reference>
<reference anchor="SAEJ29455"> <reference anchor="SAEJ29455">
<front> <front>
<title> Service Specific Permissions and Security <title>Service Specific Permissions and Security Guidelines for Connec
Guidelines for Connected Vehicle Applications </title> ted Vehicle Applications</title>
<author initials=" SAE " surname=""/> <author>
<date month="" year=""/> <organization>SAE</organization>
</front> </author>
</reference> <date month="02" year="2020"/>
</front>
<refcontent>J2945/5_202002</refcontent>
</reference>
</references>
<section anchor="ack" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>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 d
etailed
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>
</references> </back>
</back> </rfc>
</rfc>
 End of changes. 58 change blocks. 
691 lines changed or deleted 642 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/