[要約] RFC 8902は、インテリジェントトランスポートシステム（ITS）の証明書を使用したTLS認証に関する文書です。このRFCの目的は、ITSアプリケーションでの安全な通信を確保するために、TLSプロトコル内でITS証明書を使用する方法を定義することにあります。主に車両間通信（V2V）や車両とインフラストラクチャ間通信（V2I）など、ITS環境での利用が想定されています。関連するRFCには、TLSプロトコルを定義するRFC 5246や、ITS通信の安全性を高めるための他のRFCが含まれます。
Independent Submission M. Msahli, Ed.
Request for Comments: 8902 Telecom Paris
Category: Experimental N. Cam-Winget, Ed.
ISSN: 2070-1721 Cisco
W. Whyte, Ed.
Qualcomm
A. Serhrouchni
H. Labiod
Telecom Paris
September 2020
TLS Authentication Using Intelligent Transport System (ITS) Certificates
インテリジェントトランスポートシステム（ITS）証明書を使用したTLS認証
Abstract
概要
The IEEE and ETSI have specified a type of end-entity certificate. This document defines an experimental change to TLS to support IEEE/ ETSI certificate types to authenticate TLS entities.
IEEEとETSIは、一種のエンドエンティティ証明書を指定しました。この文書は、TLSエンティティを認証するためのIEEE / ETSI証明書タイプをサポートするためのTLSへの実験的変更を定義しています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
この文書はインターネット標準のトラック仕様ではありません。検査、実験的実施、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
この文書は、インターネットコミュニティの実験的プロトコルを定義しています。これは、他のRFCストリームとは無関係にRFCシリーズへの貢献です。RFCエディタは、この文書を裁量で公開することを選択し、実装または展開のためのその値についてのステートメントを作成しません。RFCエディタによる出版の承認済みの文書は、インターネット規格のレベルレベルの候補者ではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8902.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/frfc8902で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（C）2020 IETFの信頼と文書著者として識別された人。全著作権所有。
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 to this document.
この文書は、この文書の公開日に有効なIETF文書（https://truste.ietf.org/License-info）に関するBCP 78とIETF信頼の法的規定を受けています。この文書に関してあなたの権利と制限を説明するので、これらの文書を慎重に見直してください。
Table of Contents
目次
1. Introduction
1.1. Experiment Overview
2. Requirements Terminology
3. Extension Overview
4. TLS Client and Server Handshake
4.1. Client Hello
4.2. Server Hello
5. Certificate Verification
6. Examples
6.1. TLS Server and TLS Client Use the ITS Certificate
6.2. TLS Client Uses the ITS Certificate and TLS Server Uses the
X.509 Certificate
7. Security Considerations
7.1. Securely Obtaining Certificates from an Online Repository
7.2. Expiry of Certificates
7.3. Algorithms and Cryptographic Strength
7.4. Interpreting ITS Certificate Permissions
7.5. Psid and Pdufunctionaltype in CertificateVerify
8. Privacy Considerations
9. IANA Considerations
10. Normative References
Acknowledgements
Authors' Addresses
The TLS protocol [RFC8446] allows the use of X.509 certificates and raw public keys to authenticate servers and clients. This document describes an experimental extension following the procedures laid out by [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]. These standards specify secure communications in vehicular environments. These certificates are referred to in this document as Intelligent Transport Systems (ITS) Certificates.
TLSプロトコル[RFC8446]は、X.509証明書と生の公開鍵を使用してサーバーとクライアントを認証できます。この文書では、[IEEE1609.2]で指定され、[TS103097]でヨーロッパの電気通信規格研究所（ETSI）によってプロファイルされた証明書フォーマットの使用をサポートするために[RFC7250]によってレイアウトされた手続きに続く実験的な拡張について説明します。これらの規格は車両環境で安全な通信を指定しています。この文書では、インテリジェントトランスポートシステム（ITS）証明書と呼ばれます。
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.
証明書の種類は、遅延に敏感なアプリケーションをサポートするための帯域幅と処理時間に最適化され、インテリジェントトランスポートシステム（ITS）で見つかったアドホックネットワークでの高速アクセス制御の決定を可能にするための認証と許可情報の両方を提供します。標準は、公開鍵インフラストラクチャ（PKI）仕様をサポートするためのさまざまな種類の証明書を指定しています。このコンテキストで使用される証明書は、エンドエンティティ証明書、すなわちIEEE 1609.2 AppPermissionsフィールドが存在する証明書です。
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.
証明書を使用することは、その設定では広くなっています。その通信は、実際には、6 Mbpsの典型的なスループットを持つ10 MHzチャンネルを重く使用します。（このスループットを与える802.11ocb変調は、最高のスループットを与えるものではありませんが、最大300~500 mの範囲でロバストな信号を提供します。これは、衝突のような動作のための「スイートスポット」通信範囲です。回避）。X.509証明書とは対照的にその証明書のコンパクトな性質は、この設定に適しています。
The ITS certificates are also suited to the machine-to-machine (M2M) ad hoc network setting because their direct encoding of permissions (see Section 7.4) allows a receiver to make an immediate accept/deny decision about an incoming message without having to refer to a remote identity and access management server. The EU has committed to the use of ITS certificates in Cooperative Intelligent Transport Systems deployments. A multi-year project developed a certificate policy for the use of ITS certificates, including a specification of how different root certificates can be trusted across the system (hosted at <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>).
その証明書は、アクセス許可の直接エンコーディング（セクション7.4を参照）が受信機が受信機が即時の承認/拒否を行わないようにすることを許可することを許可することを許可しているため、マシンからマシン（M2M）アドホックネットワーク設定に適しています。リモートIDとアクセス管理サーバーへ。EUは、協調インテリジェントトランスポートシステムの展開における証明書の使用に取り組んでいます。複数年プロジェクトでは、さまざまなルート証明書をシステム全体で信頼できる方法を含む証明書を使用するための証明書ポリシーが開発されました（<https：//ec.europa.eu/transport/themes/its/c-its_en>、<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 original equipment manufacturers (OEMs) and national road authorities to create root certificate authorities (CAs) and have them trusted. In the US, the US Department of Transportation (USDOT) published a proposed regulation, active as of late 2019 though not rapidly progressing, requiring all light vehicles in the US to implement vehicle-to-everything (V2X) communications, including the use of ITS certificates (available at <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 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.
EUは、最上位の信頼リストマネージャ企業の最初の5年間の運用のための資金を尽力しており、自動車のオリジナル機器メーカー（OEM）や国家道路当局（CAS）を作成し、それらを信頼させることができる。米国では、米国の交通部門（USDOT）は、急速に進歩していないが、急速に進歩していないが、提案された規制を発表し、急速に進歩しており、米国のすべての軽自動車を使用することができます。その証明書（<https://www.federalregister.gov/documents/2017/01/12/2016-31059/12/2016-31059/12/12/2016-31059/12/12/12v-v2v-communications>）。 2019年現在、米国、ヨーロッパ、およびオーストラリアの展開はその証明書を使用していました。フォルクスワーゲンは、証明書を使用してV2Xを展開することを約束しました。ニューヨーク、タンパ、およびワイオミングは、その証明書を使って交通管理システムを展開しています。 GMはその証明書を使用して、CADILLAC CTSにV2Xを展開しました。
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 [ISO21177], which builds a framework for exchanging multiple authentication tokens on top of the TLS variant specified in this document.
その証明書は、鋳造用IEEEおよびETSI規格、特に自動車エンジニア社会（SAE）J2945 / Xシリーズの社会（SAE）J2945 / Xシリーズの標準（SAE）、枠組みを建設する標準（SAE）J2945 / Xシリーズでも使用されています。このドキュメントで指定されたTLSバリアントの上に複数の認証トークンを交換するため。
This document describes an experimental extension to the TLS security model. It uses a form of certificate that has not previously been used in the Internet. Systems using this Experimental approach are segregated from systems using standard TLS by the use of a new certificate type value, reserved through IANA (see Section 9). An implementation of TLS that is not involved in the Experiment will not recognize this new certificate type and will not participate in the experiment; TLS sessions will either negotiate the use of existing X.509 certificates or fail to be established.
この文書では、TLSセキュリティモデルへの実験的拡張について説明します。これまでインターネットで使用されていなかった証明書の形式を使用します。この実験的アプローチを使用するシステムは、IANAを介して予約されている新しい証明書タイプの値を使用することによって標準TLSを使用してシステムから分離されます（セクション9を参照）。実験に関与していないTLSの実装は、この新しい証明書タイプを認識することはなく、実験に参加しません。TLSセッションは、既存のX.509証明書の使用をネゴシエートするか、または確立に失敗することができます。
This extension has been encouraged by stakeholders in the Cooperative ITS community in order to support ITS use-case deployment, and it is anticipated that its use will be widespread.
この延長は、その使用症例の展開をサポートするために協力的なコミュニティの利害関係者によって奨励されており、その使用は広くなると予想されています。
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.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
The TLS extensions "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 extensions allows for mixed deployments where the client and server can use certificates of different types. It is expected that ITS deployments will see both peers using ITS certificates due to the homogeneity of the ecosystem, but there is no barrier at a technical level that prevents mixed certificate usage. This document defines a new certificate type, 1609Dot2, for usage with TLS 1.3. The updated CertificateType enumeration and corresponding addition to the CertificateEntry structure are shown below. CertificateType values are sent in the "server_certificate_type" and "client_certificate_type" extensions, and the CertificateEntry structures are included in the certificate chain sent in the Certificate message. In the case of TLS 1.3, the "client_certificate_type" SHALL contain a list of supported certificate types proposed by the client as provided in the figure below:
TLS拡張「client_certificate_type」と「server_certificate_type」[RFC7250]は、TLSで使用されている証明書メッセージの種類をネゴシエートしてサーバーを認証し、オプションでクライアントを認証します。別々の拡張機能を使用すると、クライアントとサーバーがさまざまな種類の証明書を使用できる混在展開が可能になります。その展開は、生態系の均質性のためにその証明書を使用して両方のピアを使用することが予想されますが、証明書の使用を防ぐ技術的なレベルには障壁はありません。このドキュメントは、TLS 1.3で使用するための新しい証明書タイプ1609DOT2を定義します。更新された証明書タイプの列挙とそれに対応する証明書エントリー構造への追加は以下の通りです。 CertificateTypeの値は "server_certificate_type"および "client_certificate_type"拡張機能で送信され、CertacineEntry構造体は証明書メッセージで送信された証明書チェーンに含まれています。 TLS 1.3の場合、「client_certificate_type」は、以下の図で提供されているようにクライアントによって提案されているサポートされている証明書タイプのリストを含めるものとします。
/* 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 8446*/
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.
[RFC7250]と同様に、サーバーは受信した[エンドポイント] _certificate_type拡張子を処理し、提供されている証明書タイプの1つを選択し、ネゴシエートされた値をその暗号化範囲（TLS 1.3）メッセージに返します。同じメッセージで送信されたclient_certificate_typeおよびserver_certificate_type拡張機能では、ネゴシエートされた値が同じになる必要はありません。
Figure 1 shows the handshake message flow for a full TLS 1.3 handshake negotiating both certificate types.
図1は、フルTLS 1.3ハンドシェイクの両方の証明書タイプを交渉するためのハンドシェイクメッセージフローを示しています。
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.
{}は、[送信者] _handshake_traffic_secretから派生したキーを使用して保護されたメッセージを示します。
[] Indicates messages protected using keys derived from [sender]_application_traffic_secret_N.
[] [送信者] _Application_traffic_secret_nから派生したキーを使用して保護されたメッセージを示します。
Figure 1: Message Flow with Certificate Type Extension for Full TLS 1.3 Handshake
図1：FullTLS 1.3ハンドシェイクの証明書タイプ拡張子付きメッセージフロー
In the case of TLS 1.3, in order to negotiate the support of ITS certificate-based authentication, clients and servers include the extension of type "client_certificate_type" and "server_certificate_type" in the extended Client Hello and "EncryptedExtensions".
TLS 1.3の場合、その証明書ベースの認証のサポートをネゴシエートするために、クライアントとサーバーには、拡張クライアントhelloと "encryptedExtensions"の "client_certificate_type"と "server_certificate_type"と型の拡張子が含まれます。
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 [RFC8446] (TLS 1.3).
証明書のサポートを示すために、クライアントは、[RFC8446]（TLS 1.3）のセクション4.1.2で説明されているように、拡張クライアントhelloメッセージのタイプ "client_certificate_type"または "server_certificate_type"の拡張子を含める必要があります。
For TLS 1.3, the rules for when the Client Certificate and CertificateVerify messages appear are as follows:
TLS 1.3の場合、クライアント証明書と証明書認証メッセージが表示されたときの規則は次のとおりです。
* The client's Certificate message is present if and only if the server sent a CertificateRequest message.
* クライアントの証明書メッセージは、サーバーがCertificateRequestメッセージを送信した場合に限り、クライアントの証明書メッセージが存在します。
* 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.
最大限の互換性を得るためには、エンドエンティティ証明書を除いて、任意のTLSバージョンから「潜在的に」無関係の証明書と任意の順序付けを処理するように準備する必要があります。
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:
サーバーがclient_certificate_type拡張子および/またはserver_certificate_type拡張子を含むクライアントhelloを受信すると、次のシナリオが可能です。
* If both the 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".
* サーバーは、提案されている証明書タイプのいずれもサポートされておらず、「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).
* この文書で指定されている証明書タイプをサポートしています。この場合、このタイプの証明書で応答することがあります。それはまた暗号化された拡張子でclient_certificate_type拡張機能を含み得る。その後、サーバーはクライアントからの証明書を（証明書の不明のメッセージを介して）要求します。
The certificates in the TLS client or server certificate chain MAY be sent as part of the handshake, MAY 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 SHALL reject the other endpoint's certificate and close the connection. Protocols to support retrieving certificates from a repository are specified in ETSI [TS102941].
TLSクライアントまたはサーバー証明書チェーンの証明書は、ハンドシェイクの一部として送信されてもよいが、オンラインリポジトリから取得されてもよく、またはエンドポイントにすでに知られている可能性があります。ハンドシェイクにチェーン内のすべての証明書が含まれておらず、エンドポイントがリポジトリにアクセスできない場合は、Chainからの証明書がまだわからない場合は、他のエンドポイントの証明書を拒否して接続を閉じます。リポジトリから証明書を取得するためのプロトコルは、ETSI [TS102941]に指定されています。
Verification of an ITS certificate 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 an Ieee1609Dot2Data encoded with Canonical Octet Encoding Rules (OER) [ITU-TX.696] of type signed as specified in [IEEE1609.2] and [IEEE1609.2b], where:
証明書または証明書チェーンの検証は、[IEEE1609.2]のセクション5.1で説明されています。TLS 1.3の場合、およびcertificate_typeが1609.2の場合、[RFC8446]で、Certificate_Typeの他の値の値に指定された証明書認証メッセージおよび処理とは異なります。この場合、CertificateVerifyメッセージには、[IEEE1609.2]と[IEEE1609.2B]で指定されたタイプのCanonical Octet Encoding Rules（OER）[ITU-TX.696]でエンコードされたIEEE1609DOT2DATAが含まれています。
* payload contains an extDataHash containing the SHA-256 hash of the data that the signature is calculated over. This is identical to the data that the signature is calculated over in standard TLS, which is reproduced below for clarity.
* ペイロードには、シグネチャが計算されたデータのSHA-256ハッシュを含むextDataHashが含まれています。これは、標準的なTLSで署名が計算されるデータと同じです。これは明確にするために以下に再現されます。
* headerInfo.psid indicates the application activity that the certificate is authorizing.
* HeaderInfo.psid証明書が承認しているアプリケーションアクティビティを示します。
* headerInfo.generationTime is the time at which the data structure was generated.
* HeaderInfo.GenerationTimeは、データ構造が生成された時刻です。
* headerInfo.pduFunctionalType (as specified in [IEEE1609.2b]) is present and is set equal to tlsHandshake (1).
* headerInfo.pdufunctionalType（[IEEE1609.2b]で指定）が存在し、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.
headerInfoの他のすべてのフィールドは省略されています。証明書AppPermissionsフィールドは存在し、（IEEE1609.2]で（[IEEE1609.2]で定義されているとおり）SignedDataのheaderInfoに示されているPSIDを使用して、PDUの署名を許可します。TLShandShakeのPDUFunctionalTypeに署名するためのサービス固有の権限（SSP）が必要な場合は、このSSPも存在します。PSIDとSSPの使用方法について詳しくは、[IEEE1609.2]、句5.1.1および5.2.3.3.3を参照してください。headerInfoの他のすべてのフィールドは省略されています。
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.
証明書AppPermissionsフィールドは存在し、（IEEE1609.2]で（[IEEE1609.2]で定義されているとおり）SignedDataのheaderInfoに示されているPSIDを使用して、PDUの署名を許可します。TLShandShakeのPDUFunctionalTypeに署名するためのサービス固有の権限（SSP）が必要な場合は、このSSPも存在します。
The signature and verification are carried out as specified in [IEEE1609.2].
署名と検証は[IEEE1609.2]で指定されているとおりに実行されます。
The input to the hash process is identical to the message input for TLS 1.3, as specified in Section 4.4.3 of [RFC8446], consisting of pad, context string, separator, and content, where content is Transcript-Hash(Handshake Context, Certificate).
ハッシュプロセスへの入力は、PAD、コンテキスト文字列、区切り記号、およびコンテンツからなる[RFC8446]のセクション4.4.3で規定されているTLS 1.3のメッセージ入力と同じです。コンテンツ（ハンドシェイクコンテキスト、証明書）
Some of the message-exchange examples are illustrated in Figures 2 and 3.
メッセージ交換例のいくつかは図2および3に示されている。
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.
このセクションでは、TLSクライアントとTLSサーバーがその証明書を使用する例を示します。その結果、サーバとクライアントの両方が、図2に記載されているように、IEEE 1609 DOT 2タイプとともに、CLIENT_CERTIFIFIFIED_TYPEおよびSERVER_CERTIFIFATE_TYPE拡張子を入力します。
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
図2：TLSクライアントおよびTLSサーバーの証明書を使用する
6.2. TLS Client Uses the ITS Certificate and TLS Server Uses the X.509 Certificate
6.2. TLSクライアントはその証明書を使用し、TLSサーバーはX.509証明書を使用します。
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 validate an X.509 certificate from the server. The server chooses the X.509 certificate to make its authentication with the client. This is applicable in the case of a raw public key supported by the server.
この例では、図3に示すように、TLSクライアントがX.509証明書および生の公開鍵タイプでServer_Certificate_typeの拡張子を入力したTLS認証を示しています。クライアントは、サーバーからのX.509証明書を受信して検証する機能を示しています。サーバーはクライアントと認証を行うためにX.509証明書を選択します。これは、サーバーでサポートされている生の公開鍵の場合に適用されます。
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
図3：TLSクライアントはその証明書を使用し、TLS ServerはX.509証明書を使用します。
This section provides an overview of the basic security considerations that need to be taken into account before implementing the necessary security mechanisms. The security considerations described throughout [RFC8446] apply here as well.
このセクションでは、必要なセキュリティメカニズムを実装する前に考慮する必要がある基本的なセキュリティ上の考慮事項の概要について説明します。RFC8446を通して説明されているセキュリティ上の考慮事項もここに適用されます。
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 [TS102941] provides a mechanism that can be used to securely obtain ITS certificates.
特に、安全な接続を確立するために使用される証明書は、オンラインリポジトリから入手できます。セキュアセッションのいずれかの参加者のチェーン内のCA証明書を取得するためにオンラインリポジトリを使用することができます。ETSI TS 102 941 [TS102941]は、その証明書を確実に取得するために使用できるメカニズムを提供します。
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.
証明書の有効期間の周囲の規約は、証明書とX.509証明書の間で異なります。特に、その証明書は、典型的なX.509証明書と比較して比較的短い住まいがあります。証明書を受け入れるTLSセッションのパーティーは、受信した証明書の有効期限を確認し、ハンドシェイクで受信した証明書が期限切れになるとセッションを終了する必要があります。
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.
そのすべての証明書は、長さ256ビット以上の曲線を有する曲線に基づく128ビット以上、特に曲線に基づく楕円曲線暗号（ECC）のオーダーの推定強度を有する公開鍵暗号アルゴリズムを使用する。この文書で指定された技術の実装は、X.509証明書がセッションの一部の一部によって使用されている場合、それらの証明書は少なくとも128ビットの（前Quantum-Computer）強度を持つ暗号化アルゴリズムに関連付けられていることを必要とする必要があります。
ITS certificates in TLS express the certificate holders permissions using two fields: a PSID, also known as an ITS Application Identifier (ITS-AID), which identifies a broad set of application activities that provide a context for the certificate holder's permissions, and a Service Specific Permissions (SSP) field associated with that PSID, which identifies which specific application activities the certificate holder is entitled to carry out within the broad set of activities identified by that PSID. For example, SAE [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 [IEEE1609.12], and for more information about the development of SSPs, see [SAEJ29455].
TLSのその証明書は、2つのフィールドを使用して証明書保有者権限を表現しています.PSIDは、そのアプリケーション識別子（ITS-AID）とも呼ばれます。証明書保有者がどの特定のアプリケーションアクティビティに関連付けられている特定の権限（SSP）フィールドは、証明書保有者がそのPSIDによって識別される幅広い一連の活動内で実行される権利があるかを識別する。たとえば、SAE [SAEJ29453]はPSID 0204099を使用して天候のまわりの活動を示し、気象の対応活動の管理、および証明書保有者が気象データ管理システムであるかどうかを示すSSP、普通のものです。車両、あるいは管理された道路整備艦隊に属する車両。PSIDの詳細については、[IEEE1609.12]を参照してください.SSPSの開発の詳細については、[SAEJ29455]を参照してください。
The CertificateVerify message for TLS 1.3 is an Ieee1609Dot2Data of type signed, where the signature contained in this Ieee1609Dot2Data was generated using an ITS certificate. This certificate may include multiple PSIDs. When a CertificateVerify message of this form is used, the HeaderInfo within the Ieee1609Dot2Data MUST 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 MUST NOT be interpreted as a CertificateVerify.
TLS 1.3の証明書認証メッセージは、このIEEE1609DOT2DATAに含まれている署名がその証明書を使用して生成されたタイプのIEEE1609DOT2DATAです。この証明書は複数のPSIDを含めることができます。このフォームの証明書認証メッセージが使用されている場合、IEEE1609DOT2DATA内のHEADERINFOにはPDUFunctionalTypeフィールドが存在し、TLShandShakeに設定されている必要があります。この要件の背景は次のとおりです。その証明書は（PSIDに関連付けられているアプリケーションの定義に応じて）メッセージを直接署名するため、またはTLS証明書認証メッセージ、またはその両方に署名するために使用されます。 1つのコンテキストで生成された署名が異なるコンテキストで再生される可能性を防ぐこと、すなわちメッセージ署名を証明証明書として再生することができ、またはその逆の場合、PDUFunctionalTypeフィールドは、署名付きメッセージの使用目的の使用PDUFunctionalTypeフィールドが存在しない場合、メッセージはアプリケーションの直接署名されたメッセージであり、証明書認証として解釈されないでください。
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.
各PSIDは、そのPSIDに関連付けられているアクティビティを定義するための唯一の権限を持つ所有組織によって所有されています。アプリケーション指定子が既存のPSIDに関連付けられているアクティビティを展開したい場合（たとえば、このドキュメントで指定されているような安全なセッションを介してアクティビティを含めるために）アプリケーション指定子は、その機能が正式な仕様に追加されるように、PSIDの所有者と交渉する必要があります。そのPSIDに関連する活動の。
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 vehicle-to-vehicle (V2V) communications are signed using ITS pseudonym certificates.
* 個人データの漏洩のリスクに対処するために、車両から車への交換されたメッセージ（V2V）通信はその仮名証明書を使用して署名されます。
* The purpose of these certificates is to provide privacy and minimize the exchange of private data.
* これらの証明書の目的は、プライバシーを提供し、プライベートデータの交換を最小限に抑えることです。
IANA maintains the "Transport Layer Security (TLS) Extensions" registry with a subregistry called "TLS Certificate Types".
IANAは、「TLS証明書タイプ」と呼ばれるサブレジストリとの「トランスポートレイヤセキュリティ（TLS）拡張機能」を維持しています。
Value 3 was previously assigned for "1609Dot2" and included a reference to draft-tls-certieee1609. IANA has updated this entry to reference this RFC.
値3は以前は "1609DOT2"に割り当てられ、draft-tls-certieeee1609への参照を含めました。このRFCを参照するために、IANAがこのエントリを更新しました。
[IEEE1609.12] IEEE, "IEEE Standard for Wireless Access in Vehicular Environments (WAVE) - Identifier Allocations", IEEE 1609.12-2016, December 2016.
[IEEE1609.12] IEEE、「車両環境（Wave環境（WAVE） - 識別子の割り当てにおける無線アクセスのためのIEEE規格（Waye）、IEEE 1609.12-2016、2016年12月。
[IEEE1609.2] IEEE, "IEEE Standard for Wireless Access in Vehicular Environments -- Security Services for Applications and Management Messages", IEEE Standard 1609.2-2016, DOI 10.1109/IEEESTD.2016.7426684, March 2016, <https://doi.org/10.1109/IEEESTD.2016.7426684>.
[IEEE1609.2] IEEE、「自動車環境における無線アクセスのためのIEEE規格 - アプリケーションおよび管理メッセージのためのセキュリティサービス」、IEEE規格1609.2-2016、DOI 10.1109 / IEEESTD.2016.7426684、2016年3月、<https：// doi。ORG / 10.1109 / IEEESTD.2016.7426684>。
[IEEE1609.2b] IEEE, "IEEE Standard for Wireless Access in Vehicular Environments--Security Services for Applications and Management Messages - Amendment 2--PDU Functional Types and Encryption Key Management", IEEE 1609.2b-2019, June 2019.
[IEEE1609.2B] IEEE、「自動車環境での無線アクセスのためのIEEE規格 - アプリケーションおよび管理メッセージのためのセキュリティサービス - 改正2 - PDU機能タイプと暗号化キー管理」、IEEE 1609.2B-2019、2019年6月。
[ISO21177] ISO, "Intelligent transport systems - ITS station security services for secure session establishment and authentication between trusted devices", ISO/TS 21177:2019, August 2019.
[ISO21177] ISO、「インテリジェントなトランスポートシステム - 安全なセッション確立のためのそのステーションセキュリティサービスと信頼済みデバイス間の認証」、ISO / TS 21177：2019、2019年8月。
[ITU-TX.696] ITU-T, "Information technology - ASN.1 encoding rules: Specification of Octet Encoding Rules (OER)", Recommendation ITU-T X.696, August 2015.
[ITU-TX.696] ITU-T、「情報技術 - ASN.1エンコード規則：オクテットエンコーディング規則の仕様（OER）」、推奨ITU-T X.696、2015年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., Weiler, S., and T. Kivinen, "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, June 2014, <https://www.rfc-editor.org/info/rfc7250>.
[RFC7250] Wouters、P.、ED、Tschofenig、H.、ED。、Gilmore、J.、Weiler、S.、T.Kivinen、「トランスポート層セキュリティ（TLS）およびデータグラムトランスポート層での生の公開鍵を使用する」セキュリティ（DTLS） "、RFC 7250、DOI 10.17487 / RFC7250、2014年6月、<https://www.rfc-editor.org/info/rfc7250>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446] RESCORLA、E.、「トランスポート層セキュリティ（TLS）プロトコルバージョン1.3」、RFC 8446、DOI 10.17487 / RFC8446、2018年8月、<https：//www.rfc-editor.org/info/rfc8446>。
[SAEJ29453] SAE, "Requirements for V2I Weather Applications", J2945/3, June 2017.
[SAEJ29453] SAE、「V2I天気アプリケーションの要件」、J2945 / 3、2017年6月。
[SAEJ29455] SAE, "Service Specific Permissions and Security Guidelines for Connected Vehicle Applications", J2945/5_202002, February 2020.
[SAEJ29455] SAE、「接続車用のサービス固有の許可とセキュリティガイドライン」、J2945 / 5_202002、2020年2月。
[TS102941] ETSI, "Intelligent Transport Systems (ITS); Security; Trust and Privacy Management", ETSI TS 102 941, 2018.
[TS102941] ETSI、「インテリジェントなトランスポートシステム（ITS）;セキュリティ;信頼とプライバシー管理」、ETSI TS 102 941,2018。
[TS103097] ETSI, "Intelligent Transport Systems (ITS); Security; Security header and certificate formats", ETSI TS 103 097, 2017.
[TS103097] ETSI、「インテリジェントなトランスポートシステム（ITS）;セキュリティ;セキュリティヘッダと証明書フォーマット」、ETSI TS 103 097,2017。
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 document.
著者らは、Adrian Farrel、Eric Resvaara、Russ Ousle、Liluri Liusvaara、およびBenjamin Kadukに感謝します。ありがとうは、彼の貴重で詳細なコメントのためのショーンターナーが原因です。Panos Kampanakis、Jasja Tijink、およびドキュメントのサポートのためのBill Lattinに感謝します。
Authors' Addresses
著者の住所
Mounira Msahli (editor) Telecom Paris France
Mounira Msahli（編集）テレコムパリフランス
Email: mounira.msahli@telecom-paris.fr
Nancy Cam-Winget (editor) Cisco United States of America
Nancy Cam-Winget（編集）シスコアメリカ
Email: ncamwing@cisco.com
William Whyte (editor) Qualcomm United States of America
William Whitte（編集）クッターコミックスアメリカ合衆国
Email: wwhyte@qti.qualcomm.com
Ahmed Serhrouchni Telecom Paris France
Ahmed Serhrouchniテレコムパリフランス
Email: ahmed.serhrouchni@telecom-paris.fr
Houda Labiod Telecom Paris France
Houda Labiod Telecomパリフランス
Email: houda.labiod@telecom-paris.fr