RFC 9934 - Privacy-Enhanced Mail (PEM) File Format for Encrypted ClientHello (ECH) 日本語訳

原文URL : https://www.rfc-editor.org/rfc/rfc9934.html
タイトル : RFC 9934 - 暗号化された ClientHello (ECH) のためのプライバシー強化メール (PEM) ファイル形式
翻訳編集 : 自動生成

[要約] この文書は、TLS 1.3 の暗号化 ClientHello (ECH) で使用される鍵ペアを TLS サーバーに構成するための、標準的な PEM ファイル形式を規定しています。RFC 7468 で定義された他の PEM 形式と同様に、異なる TLS ライブラリ間での互換性を高めることを目的としています。これにより、定期的に更新される ECH 鍵ペアと構成情報の安全かつ容易な管理が可能になります。

Internet Engineering Task Force (IETF)                        S. Farrell
Request for Comments: 9934                        Trinity College Dublin
Category: Standards Track                                     March 2026
ISSN: 2070-1721

Privacy-Enhanced Mail (PEM) File Format for Encrypted ClientHello (ECH)

暗号化された ClientHello (ECH) のプライバシー強化メール (PEM) ファイル形式

Abstract

概要

Encrypted ClientHello (ECH) key pairs need to be configured into TLS servers, which can be built using different TLS libraries. This document specifies a standard file format for this purpose, similar to how RFC 7468 defines other Privacy-Enhanced Mail (PEM) file formats.

暗号化された ClientHello (ECH) キーペアは、さまざまな TLS ライブラリを使用して構築できる TLS サーバーに構成する必要があります。この文書では、RFC 7468 が他のプライバシー強化メール (PEM) ファイル形式を定義する方法と同様に、この目的のための標準ファイル形式を指定します。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはインターネット標準化トラックの文書です。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。インターネット標準の詳細については、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/rfc9934.

この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9934 で入手できます。

Copyright Notice

著作権表示

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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコードコンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンステキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。

1. Introduction

1. はじめに

Encrypted ClientHello (ECH) [RFC9849] for TLS1.3 [RFC8446] defines a confidentiality mechanism for server names and other ClientHello content in TLS. That requires publication of an ECHConfigList data structure in an HTTPS or SVCB RR [RFC9460] in the DNS. An ECHConfigList can contain one or more ECHConfig values. An ECHConfig structure contains the public component of a key pair that will typically be periodically (re-)generated by some key manager for a TLS server. TLS servers then need to be configured to use these key pairs, and given that various TLS servers can be built with different TLS libraries, there is a benefit in having a standard format for ECH key pairs and configs, just as was done with [RFC7468].

TLS1.3 [RFC8446] 用の暗号化 ClientHello (ECH) [RFC9849] は、TLS のサーバー名およびその他の ClientHello コンテンツの機密性メカニズムを定義します。それには、DNS の HTTPS または SVCB RR [RFC9460] で ECHConfigList データ構造を公開する必要があります。ECHConfigList には 1 つ以上の ECHConfig 値を含めることができます。ECHConfig 構造には、通常、TLS サーバーのキーマネージャーによって定期的に (再) 生成されるキーペアのパブリックコンポーネントが含まれています。次に、これらの鍵ペアを使用するように TLS サーバーを設定する必要があります。さまざまな TLS サーバーを異なる TLS ライブラリで構築できることを考えると、[RFC7468] で行われたのと同じように、ECH 鍵ペアと構成の標準形式を持つことには利点があります。

2. Terminology

2. 用語

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」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。

3. ECHConfig File

3. ECHConfig ファイル

A PEM ECH file contains zero or one private key and one encoded ECHConfigList.

PEM ECH ファイルには、0 または 1 つの秘密キーと 1 つのエンコードされた ECHConfigList が含まれています。

The public and private keys MUST both be PEM encoded [RFC7468]. The file contains the concatenation of the PEM encoding of the private key (if present) followed by the PEM encoding of the public key(s) as an ECHConfigList. When a private key is present, the ECHConfigList MUST contain an ECHConfig that matches the private key. The private key MUST be encoded as a PKCS #8 PrivateKey [RFC7468]. The public key(s) MUST be the base64-encoded form (see Section 4 of [RFC4648]) of an ECHConfigList value that can be published in the DNS using an HTTPS RR as described in [RFC9848]. The string "ECHCONFIG" MUST be used in the PEM file delimiter for the public key.

公開鍵と秘密鍵は両方とも PEM エンコードされなければなりません [RFC7468]。このファイルには、秘密キー (存在する場合) の PEM エンコーディングと、その後に続く公開キーの PEM エンコーディングの連結が ECHConfigList として含まれています。秘密鍵が存在する場合、ECHConfigList には秘密鍵と一致する ECHConfig が含まれなければなりません (MUST)。秘密鍵は PKCS #8 PrivateKey [RFC7468] としてエンコードされなければなりません (MUST)。公開鍵は、[RFC9848] で説明されているように、HTTPS RR を使用して DNS で公開できる ECHConfigList 値の Base64 エンコード形式 ([RFC4648] のセクション 4 を参照) でなければなりません (MUST)。文字列「ECHCONFIG」を公開キーの PEM ファイル区切り文字に使用する必要があります。

Any content after the PEM encoded ECHConfigList SHOULD be ignored.

PEM エンコードされた ECHConfigList 以降のコンテンツは無視されるべきです(SHOULD)。

Figure 1 shows an example ECHConfig PEM File

図 1 は、ECHConfig PEM ファイルの例を示しています

Figure 1: Example ECHConfig PEM File

図 1: ECHConfig PEM ファイルの例

If the above ECHConfigList were published in the DNS for foo.example.com, then one could access that as shown in Figure 2.

上記の ECHConfigList が foo.example.com の DNS で公開されている場合、図 2 に示すようにそれにアクセスできます。

   $ dig +short HTTPS foo.example.com
   1 . ech=AD7+DQA65wAgACA8wVN2BtscOl3vQheUzHeIkVmKIiydUhDCliA4iyQR
   wAEAAEAAQALZXhhbXBsZS5jb20AAA==

Figure 2: Use of Dig to Get the ECHConfigList from DNS

図 2: Dig を使用して DNS から ECHConfigList を取得する

TLS servers using this file format might configure multiple file names as part of their overall configuration, if, for example, only the ECHConfigList values from a subset of those files are to be used as the value for retry_configs in the ECH fallback scenario.

このファイル形式を使用する TLS サーバーは、たとえば、ECH フォールバックシナリオで、それらのファイルのサブセットの ECHConfigList 値のみを retry_configs の値として使用する場合、全体的な構成の一部として複数のファイル名を構成することがあります。

The ECHConfigList in a PEM file might contain more than one ECHConfig if, for example, those ECHConfig values contain different extensions or different public_name values. Consistent with [RFC9849], the ECHConfig values within an ECHConfigList appear in decreasing order of preference. If the ECHConfigList value is to be used as the retry_configs value, then that might contain different public keys. (Nonetheless, when a private key is present, that MUST match the public key from one of the ECHConfig values.)

たとえば、それらの ECHConfig 値に異なる拡張子または異なる public_name 値が含まれている場合、PEM ファイル内の ECHConfigList には複数の ECHConfig が含まれる可能性があります。[RFC9849] に従って、ECHConfigList 内の ECHConfig 値は優先順位の降順に表示されます。ECHConfigList 値が retry_configs 値として使用される場合、その値には異なる公開キーが含まれる可能性があります。(それでも、秘密キーが存在する場合、それは ECHConfig 値のいずれかの公開キーと一致する必要があります。)

4. Security Considerations

4. セキュリティに関する考慮事項

Storing cryptographic keys in files leaves them vulnerable should anyone get read access to the filesystem on which they are stored. The same protection mechanisms that would be used for a server's PEM-encoded HTTPS certificate private key should be used for the PEM ECH configuration.

暗号化キーをファイルに保存すると、暗号化キーが保存されているファイルシステムへの読み取りアクセスを誰かが取得した場合に脆弱な状態になります。サーバーの PEM エンコードされた HTTPS 証明書秘密キーに使用されるものと同じ保護メカニズムを、PEM ECH 構成にも使用する必要があります。

The security considerations of [RFC9848] apply when retrieving an ECHConfigList from the DNS.

[RFC9848] のセキュリティに関する考慮事項は、DNS から ECHConfigList を取得するときに適用されます。

For clarity, only the ECHConfigList is to be published in the DNS - the private key from an ECH PEM file MUST NOT be published in the DNS.

明確にするために、DNS で公開されるのは ECHConfigList のみです。ECH PEM ファイルの秘密キーは DNS で公開してはなりません (MUST NOT)。

5. IANA Considerations

5. IANAの考慮事項

This document has no IANA actions.

この文書には IANA のアクションはありません。

6. References

6. 参考文献

6.1. Normative References

6.1. 引用文献

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

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
              <https://www.rfc-editor.org/info/rfc4648>.

   [RFC7468]  Josefsson, S. and S. Leonard, "Textual Encodings of PKIX,
              PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468,
              April 2015, <https://www.rfc-editor.org/info/rfc7468>.

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

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

   [RFC9849]  Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS
              Encrypted Client Hello", RFC 9849, DOI 10.17487/RFC9849,
              March 2026, <https://www.rfc-editor.org/info/rfc9849>.

6.2. Informative References

6.2. 参考引用

   [RFC9460]  Schwartz, B., Bishop, M., and E. Nygren, "Service Binding
              and Parameter Specification via the DNS (SVCB and HTTPS
              Resource Records)", RFC 9460, DOI 10.17487/RFC9460,
              November 2023, <https://www.rfc-editor.org/info/rfc9460>.

   [RFC9848]  Schwartz, B., Bishop, M., and E. Nygren, "Bootstrapping
              TLS Encrypted ClientHello with DNS Service Bindings",
              RFC 9848, March 2026,
              <https://www.rfc-editor.org/info/rfc9848>.

Acknowledgements

謝辞

Thanks to Daniel McCarney, Jim Reid, and Peter Yee for comments.

コメントをくださった Daniel McCarney、Jim Reid、Peter Yee に感謝します。

Author's Address

著者の連絡先

   Stephen Farrell
   Trinity College Dublin
   Dublin
   2
   Ireland
   Phone: +353-1-896-2354
   Email: stephen.farrell@cs.tcd.ie