[要約] RFC 9163は、HTTP通信におけるセキュリティを強化するためのExpect-CT拡張に関する文書です。この拡張機能は、ウェブサイトがCertificate Transparency（証明書の透明性）の要件を満たしていることをブラウザが検証するのを支援します。主に、セキュリティを重視するウェブサイトでの利用が想定されています。
Internet Engineering Task Force (IETF) E. Stark
Request for Comments: 9163 Google
Category: Experimental June 2022
ISSN: 2070-1721
Expect-CT Extension for HTTP
httpのexpect-ct拡張機能
Abstract
概要
This document defines a new HTTP header field named "Expect-CT", which allows web host operators to instruct user agents (UAs) to expect valid Signed Certificate Timestamps (SCTs) to be served on connections to these hosts. Expect-CT allows web host operators to discover misconfigurations in their Certificate Transparency (CT) deployments. Further, web host operators can use Expect-CT to ensure that if a UA that supports Expect-CT accepts a misissued certificate, that certificate will be discoverable in Certificate Transparency logs.
このドキュメントでは、「expect-ct」という名前の新しいHTTPヘッダーフィールドを定義します。これにより、Webホストオペレーターは、ユーザーエージェント（UAS）に、有効な署名証明書のタイムスタンプ（SCT）がこれらのホストへの接続で提供されることを期待するように指示できます。expect-ctを使用すると、Webホストオペレーターは、証明書の透明性（CT）の展開で誤った不明瞭さを発見できます。さらに、Webホストオペレーターは、expect-CTを使用して、誤った誤った証明書をサポートするUAが誤った証明書を受け入れることを確認できます。
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 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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、インターネットコミュニティの実験プロトコルを定義しています。このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。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/rfc9163.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9163で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 IETF Trustおよび文書著者として特定された人。全著作権所有。
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ドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、修正されたBSDライセンスで説明されているように保証なしで提供される修正されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction
1.1. Requirements Language
1.2. Terminology
2. Server and Client Behavior
2.1. Response Header Field Syntax
2.1.1. The report-uri Directive
2.1.2. The enforce Directive
2.1.3. The max-age Directive
2.1.4. Examples
2.2. Host Processing Model
2.2.1. HTTP-over-Secure-Transport Request Type
2.2.2. HTTP Request Type
2.3. User Agent Processing Model
2.3.1. Missing or Malformed Expect-CT Header Fields
2.3.2. Expect-CT Header Field Processing
2.3.3. Reporting
2.4. Evaluating Expect-CT Connections for CT Compliance
2.4.1. Skipping CT Compliance Checks
3. Reporting Expect-CT Failure
3.1. Generating a Violation Report
3.2. Sending a Violation Report
3.3. Receiving a Violation Report
4. Usability Considerations
5. Authoring Considerations
6. Privacy Considerations
7. Security Considerations
7.1. Hostile Header Attacks
7.2. Maximum max-age
7.3. Amplification Attacks
8. IANA Considerations
8.1. Header Field Registry
8.2. Media Types Registry
9. References
9.1. Normative References
9.2. Informative References
Author's Address
This document defines a new HTTP header field ([RFC9110], Section 6.3) that enables UAs to identify web hosts that expect the presence of Signed Certificate Timestamps (SCTs) [RFC9162] in subsequent Transport Layer Security (TLS) [RFC8446] connections.
このドキュメントでは、その後の輸送層セキュリティ（TLS）[RFC8446]接続に署名された証明書タイムスタンプ（SCT）[RFC9162]の存在を期待するWebホストを識別できるようにする新しいHTTPヘッダーフィールド（[RFC9110]、セクション6.3）を定義します。
Web hosts that serve the Expect-CT header field are noted by the UA as "Known Expect-CT Hosts". The UA evaluates each connection to a Known Expect-CT Host for compliance with the UA's Certificate Transparency (CT) Policy. If the connection violates the CT Policy, the UA sends a report to a URI configured by the Expect-CT Host and/ or fails the connection, depending on the configuration that the Expect-CT Host has chosen.
Regut-CTヘッダーフィールドにサービスを提供するWebホストは、UAによって「既知の期待ホスト」として注目されています。UAは、UAの証明書透明性（CT）ポリシーを順守するために、既知の期待ホストへの各接続を評価します。接続がCTポリシーに違反した場合、UAは、期待ホストが選択した構成に応じて、expect-CTホストによって構成されたURIにレポートを送信し、接続に失敗します。
If misconfigured, Expect-CT can cause unwanted connection failures (for example, if a host deploys Expect-CT but then switches to a legitimate certificate that is not logged in Certificate Transparency logs or if a web host operator believes their certificate to conform to all UAs' CT policies but is mistaken). Web host operators are advised to deploy Expect-CT with precautions by using the reporting feature and gradually increasing the time interval during which the UA regards the host as a Known Expect-CT Host. These precautions can help web host operators gain confidence that their Expect-CT deployment is not causing unwanted connection failures.
誤解されている場合、expect-CTは不要な接続障害を引き起こす可能性があります（たとえば、ホストがexpect-CTを展開するが、証明書の透明性ログに記録されていない正当な証明書に切り替えるか、ウェブホストオペレーターが証明書をすべてに適合させると信じている場合UASのCTポリシーですが、間違っています）。Webホストオペレーターは、レポート機能を使用し、UAがホストを既知の期待ホストと見なす時間間隔を徐々に増やすことにより、予防策を講じて展開することをお勧めします。これらの予防措置は、Webホストオペレーターが期待展開が不要な接続障害を引き起こしていないという自信を得るのに役立ちます。
Expect-CT is a trust-on-first-use (TOFU) mechanism. The first time a UA connects to a host, it lacks the information necessary to require SCTs for the connection. Thus, the UA will not be able to detect and thwart an attack on the UA's first connection to the host. Still, Expect-CT provides value by 1) allowing UAs to detect the use of unlogged certificates after the initial communication, and 2) allowing web hosts to be confident that UAs are only trusting publicly auditable certificates.
expect-ctは、ファーストオン（豆腐）の信頼メカニズムです。UAがホストに初めて接続したとき、接続にSCTを要求するために必要な情報が不足しています。したがって、UAは、ホストとのUAの最初の接続に対する攻撃を検出して阻止することはできません。それでも、expect-CTは1）UASが最初の通信後にログされていない証明書の使用を検出できるようにし、2）WebホストがUASが公的に監査可能な証明書のみを信頼していると確信できるようにする。
Expect-CT is similar to HTTP Strict Transport Security (HSTS) [RFC6797] and HTTP Public Key Pinning (HPKP) [RFC7469]. HSTS allows websites to declare themselves accessible only via secure connections, and HPKP allows websites to declare their cryptographic identifies. Similarly, Expect-CT allows websites to declare themselves accessible only via connections that are compliant with CT Policy.
Lead-CTは、HTTP Strict Transport Security（HSTS）[RFC6797]およびHTTP Public Key Pinning（HPKP）[RFC7469]に似ています。HSTSを使用すると、Webサイトは安全な接続を介してのみアクセス可能であると宣言でき、HPKPはWebサイトが暗号化の識別を宣言することができます。同様に、expect-ctを使用すると、WebサイトはCTポリシーに準拠した接続を介してのみアクセスできると宣言できます。
This Expect-CT specification is compatible with [RFC6962] and [RFC9162], but not necessarily with future versions of Certificate Transparency. UAs will ignore Expect-CT header fields from web hosts that use future versions of Certificate Transparency, unless a future version of this document specifies how they should be processed.
この期待-CT仕様は[RFC6962]および[RFC9162]と互換性がありますが、必ずしも証明書の透明性の将来のバージョンとは限りません。UASは、このドキュメントの将来のバージョンが処理方法を指定しない限り、証明書の透明性の将来のバージョンを使用するWebホストからの期待-CTヘッダーフィールドを無視します。
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
Terminology is defined in this section.
このセクションでは、用語が定義されています。
"Certificate Transparency Policy" A policy defined by the UA concerning the number, sources, and delivery mechanisms of Signed Certificate Timestamps that are associated with TLS connections. The policy defines the properties of a connection that must be met in order for the UA to consider it CT qualified.
「証明書の透明性ポリシー」TLS接続に関連付けられている署名された証明書タイムスタンプの数、ソース、および配信メカニズムに関するUAによって定義されたポリシー。ポリシーは、UAがCT資格を考慮するために満たさなければならない接続のプロパティを定義します。
"Certificate Transparency Qualified" Describes a TLS connection for which the UA has determined that a sufficient quantity and quality of Signed Certificate Timestamps have been provided.
「証明書の透明性資格」は、UAが署名された証明書のタイムスタンプの十分な量と品質が提供されていると判断したTLS接続について説明しています。
"CT Qualified" An abbreviation for "Certificate Transparency Qualified".
「CT資格」は、「証明書の透明性資格」の略語。
"CT Policy" An abbreviation for "Certificate Transparency Policy".
「CTポリシー」「証明書の透明性ポリシー」の略語。
"Effective Expect-CT Date" The time at which a UA observed a valid Expect-CT header field for a given host.
「効果的な予想-CT日付」UAが特定のホストの有効な予想ヘッダーフィールドを観察した時間。
"Expect-CT Host" A conformant host implementing the HTTP server aspects of Expect-CT. This means that an Expect-CT Host returns the Expect-CT response header field in its HTTP response messages sent over secure transport. The term "host" is equivalent to "server" in this specification.
「expect-ct host」は、httpサーバーのaspects aspects of quct-ctを実装するコンフォーマントホスト。これは、予想ホストがセキュアな輸送上で送信されたHTTP応答メッセージで、期待-CT応答ヘッダーフィールドを返すことを意味します。「ホスト」という用語は、この仕様の「サーバー」に相当します。
"Known Expect-CT Host" An Expect-CT Host that the UA has noted as such. See Section 2.3.2.1 for particulars.
「既知のexpect-ctホスト」は、UAがそのように指摘している期待ホストです。詳細については、セクション2.3.2.1を参照してください。
"User Agent (UA)" For the purposes of this specification, a UA is an HTTP client application typically actively manipulated by a user [RFC9110].
「ユーザーエージェント（UA）」この仕様の目的で、UAは通常、ユーザー[RFC9110]によって積極的に操作されるHTTPクライアントアプリケーションです。
"Unknown Expect-CT Host" An Expect-CT Host that the UA has not noted.
「不明なexpect-ctホスト」は、UAが指摘していない予想ホストです。
The Expect-CT response header field is a new field defined in this specification. It is used by a server to indicate that UAs should evaluate connections to the host emitting the header field for CT compliance (Section 2.4).
Lead-CT応答ヘッダーフィールドは、この仕様で定義されている新しいフィールドです。サーバーが使用して、UASがCTコンプライアンスのヘッダーフィールドをエミストするホストへの接続を評価する必要があることを示します（セクション2.4）。
Figure 1 describes the syntax (Augmented Backus-Naur Form) of the header field, using the grammar defined in [RFC5234] and the rules defined in Section 5 of [RFC9110]. The "#" ABNF extension is specified in Section 5.6.1 of [RFC9110].
図1は、[RFC5234]で定義されている文法と[RFC9110]のセクション5で定義されているルールを使用して、ヘッダーフィールドの構文（拡張バックスノール形式）を説明しています。「＃」ABNF拡張は、[RFC9110]のセクション5.6.1で指定されています。
Expect-CT = 1#expect-ct-directive
expect-ct-directive = directive-name [ "=" directive-value ]
directive-name = token
directive-value = token / quoted-string
Figure 1: Syntax of the Expect-CT Header Field
図1：expect-ctヘッダーフィールドの構文
The directives defined in this specification are described below. The overall requirements for directives are:
この仕様で定義されている指令は、以下に説明します。指令の全体的な要件は次のとおりです。
1. The order of appearance of directives is not significant.
1. 指令の外観の順序は重要ではありません。
2. A given directive MUST NOT appear more than once in a given header field. Directives are either optional or required, as stipulated in their definitions.
2. 特定のディレクティブは、特定のヘッダーフィールドに複数回表示してはなりません。ディレクティブは、定義に規定されているように、オプションまたは必要です。
3. Directive names are case insensitive.
3. ディレクティブ名はケースの鈍感です。
4. UAs MUST ignore any header fields containing directives, or other header field value data that does not conform to the syntax defined in this specification. In particular, UAs MUST NOT attempt to fix malformed header fields.
4. UASは、この仕様で定義されている構文に準拠していないディレクティブ、またはその他のヘッダーフィールド値データを含むヘッダーフィールドを無視する必要があります。特に、UASは奇形のヘッダーフィールドを修正しようとしてはなりません。
5. If a header field contains any directive(s) the UA does not recognize, the UA MUST ignore those directives.
5. ヘッダーフィールドに指令が含まれている場合、UAが認識していない場合、UAはこれらの指令を無視する必要があります。
6. If the Expect-CT header field otherwise satisfies the above requirements (1 through 5), and Expect-CT is not disabled for local policy reasons (as discussed in Section 2.4.1), the UA MUST process the directives it recognizes.
6. それ以外の場合は、上記の要件（1〜5）を満たしている場合（1〜5）、現地の政策上の理由（セクション2.4.1で説明しているように）の場合、expect-CTが無効になっていない場合、UAは認識する指令を処理する必要があります。
The OPTIONAL report-uri directive indicates the URI to which the UA SHOULD report Expect-CT failures (Section 2.4). The UA POSTs the reports to the given URI as described in Section 3.
オプションのレポート-URI指令は、UAが予想障害を報告するURIを示しています（セクション2.4）。UAは、セクション3で説明されているように、指定されたURIにレポートを投稿します。
The report-uri directive is REQUIRED to have a directive value, for which the syntax is defined in Figure 2.
Report-URI指令には、図2に構文が定義されている指令値が必要です。
report-uri-value = (DQUOTE absolute-URI DQUOTE) / absolute-URI
Figure 2: Syntax of the report-uri Directive Value
図2：Report-URIディレクティブ値の構文
The 'report-uri-value' MUST be quoted if it contains any character not allowed in 'token'.
「トークン」に許可されていないキャラクターが含まれている場合、「Report-uri-value」を引用する必要があります。
absolute-URI is defined in Section 4.3 of [RFC3986].
絶対-URIは、[RFC3986]のセクション4.3で定義されています。
UAs MUST ignore any report-uri that does not use the HTTPS scheme. UAs MUST check Expect-CT compliance when the host in the report-uri is a Known Expect-CT Host; similarly, UAs MUST apply HSTS [RFC6797] if the host in the report-uri is a Known HSTS Host.
UASは、HTTPSスキームを使用していないReport-URIを無視する必要があります。Report-uriのホストが既知の期待ホストである場合、UASは期待-CTコンプライアンスを確認する必要があります。同様に、Report-URIのホストが既知のHSTSホストである場合、UASはHSTS [RFC6797]を適用する必要があります。
UAs SHOULD make their best effort to report Expect-CT failures to the report-uri, but they may fail to report in exceptional conditions. For example, if connecting to the report-uri itself incurs an Expect-CT failure or other certificate validation failure, the UA MUST cancel the connection. Similarly, if Expect-CT Host A sets a report-uri referring to Expect-CT Host B, and if B sets a report-uri referring to A, and if both hosts fail to comply to the UA's CT Policy, the UA SHOULD detect and break the loop by failing to send reports to and about those hosts.
UASは、Report-URIに期待障害を報告するために最善の努力をする必要がありますが、例外的な条件で報告できない場合があります。たとえば、Report-URI自体に接続すると、予想障害またはその他の証明書の検証障害が発生した場合、UAは接続をキャンセルする必要があります。同様に、expect-CTホストAがexpect-CTホストBを参照してレポート-URIをセットし、bがAを参照するレポート-URIを設定する場合、両方のホストがUAのCTポリシーに準拠しない場合、UAは検出する必要がありますそして、それらのホストにレポートを送信しないことでループを破ります。
Note that the report-uri need not necessarily be in the same Internet domain or web origin as the host being reported about. Hosts are in fact encouraged to use a separate host as the report-uri so that CT failures on the Expect-CT Host do not prevent reports from being sent.
レポート-URIは、ホストが報告されているのと同じインターネットドメインまたはWeb起源にある必要はないことに注意してください。実際、ホストはレポート-URIとして別のホストを使用することをお勧めします。これにより、予想ホストのCT障害がレポートの送信を妨げないようにします。
UAs SHOULD limit the rate at which they send reports. For example, it is unnecessary to send the same report to the same report-uri more than once in the same web-browsing session.
UASは、レポートを送信するレートを制限する必要があります。たとえば、同じWebブラウジングセッションで同じレポート-URIに同じレポートを送信する必要はありません。
The OPTIONAL enforce directive is a valueless directive that, if present (i.e., it is "asserted"), signals to the UA that compliance to the CT Policy should be enforced (rather than report-only) and that the UA should refuse future connections that violate its CT Policy. When both the enforce directive and report-uri directive (as defined in Figure 2) are present, the configuration is referred to as an "enforce-and-report" configuration, signaling to the UA that both compliance to the CT Policy should be enforced and violations should be reported.
オプションの強制指令は、存在する（つまり、「主張」されている場合）、CTポリシーへのコンプライアンスを（レポートのみではなく）施行する必要があることをUAに信号する価値のない指令であり、UAは将来の接続を拒否する必要があることを示します。CTポリシーに違反しています。Enforce DirectiveとReport-URI指令（図2で定義されている）の両方が存在する場合、構成は「施行とレポート」構成と呼ばれ、CTポリシーへのコンプライアンスの両方を施行する必要があることをUAに通知します。違反を報告する必要があります。
The max-age directive specifies the number of seconds after the reception of the Expect-CT header field during which the UA SHOULD regard the host from whom the message was received as a Known Expect-CT Host.
Max-Ageディレクティブは、UAがメッセージが既知の期待ホストとして受信されたホストを考慮する予想ヘッダーフィールドを受信してから秒数を指定します。
If a response contains an Expect-CT header field, then the response MUST contain an Expect-CT header field with a max-age directive. (A max-age directive need not appear in every Expect-CT header field in the response.) The max-age directive is REQUIRED to have a directive value, for which the syntax (after quoted-string unescaping, if necessary) is defined in Figure 3.
応答にexpect-CTヘッダーフィールドが含まれている場合、応答には、最大年齢の指令を持つ予想ヘッダーフィールドを含める必要があります。（最大年齢の指令は、応答のすべての予想ヘッダーフィールドに表示される必要はありません。）最大年齢の指令は、指令値を持つ必要があります。図3で。
max-age-value = delta-seconds delta-seconds = 1*DIGIT
max-age-value = delta-seconds delta-seconds = 1*digit
Figure 3: Syntax of the max-age Directive Value
図3：最大年齢のディレクティブ値の構文
delta-seconds is used as defined in Section 1.3 of [RFC9111].
Delta-Secondsは、[RFC9111]のセクション1.3で定義されているように使用されます。
The following three examples demonstrate valid Expect-CT response header fields (where the second splits the directives into two field instances):
次の3つの例は、有効な予想応答ヘッダーフィールドを示しています（2番目はディレクティブを2つのフィールドインスタンスに分割します）：
Expect-CT: max-age=86400, enforce
expect-ct：max-age = 86400、Enforce
Expect-CT: max-age=86400,enforce
Expect-CT: report-uri="https://foo.example/report"
Expect-CT: max-age=86400,report-uri="https://foo.example/report"
Figure 4: Examples of Valid Expect-CT ResponseHeader Fields
図4：有効な予想応答ヘッダーフィールドの例
This section describes the processing model that Expect-CT Hosts implement. The model has 2 parts: (1) the processing rules for HTTP request messages received over a secure transport (e.g., authenticated, non-anonymous TLS); and (2) the processing rules for HTTP request messages received over non-secure transports, such as TCP.
このセクションでは、Host-CTホストが実装する処理モデルについて説明します。モデルには2つの部分があります。（1）安全なトランスポート（例えば、認証された、非匿名TLSなど）で受信されたHTTP要求メッセージの処理ルール。（2）TCPなどの非安全なトランスポートを介して受信したHTTP要求メッセージの処理ルール。
An Expect-CT Host includes an Expect-CT header field in its response. The header field MUST satisfy the grammar specified in Section 2.1.
Repd-CTホストには、その応答にPeosd-CTヘッダーフィールドが含まれています。ヘッダーフィールドは、セクション2.1で指定された文法を満たす必要があります。
Establishing a given host as an Expect-CT Host, in the context of a given UA, is accomplished as follows:
特定のUAのコンテキストで、特定のホストを期待ホストとして確立することは、次のように達成されます。
1. Over the HTTP protocol running over secure transport, by correctly returning (per this specification) a valid Expect-CT header field to the UA.
1. 安全なトランスポートを介して実行されているHTTPプロトコルを介して、この仕様に従って（この仕様に従って）有効な予想ヘッダーフィールドをUAに正しく返すことにより。
2. Through other mechanisms such as a client-side preloaded Expect-CT Host list.
2. クライアント側のプリロードされた予想ホストリストなどの他のメカニズムを介して。
Expect-CT Hosts SHOULD NOT include the Expect-CT header field in HTTP responses conveyed over non-secure transport.
expect-CTホストには、非セキュアな輸送で伝えられるHTTP応答に、期待値ヘッダーフィールドを含めるべきではありません。
The UA processing model relies on parsing domain names. Note that internationalized domain names SHALL be canonicalized by the UA according to the scheme in Section 10 of [RFC6797].
UA処理モデルは、ドメイン名の解析に依存しています。国際化されたドメイン名は、[RFC6797]のセクション10のスキームに従ってUAによって正規化されるものとすることに注意してください。
The UA stores Known Expect-CT Hosts and their associated Expect-CT directives. This data is collectively known as a host's "Expect-CT metadata".
UAストアは、既知のexpect-ctホストとそれに関連するexpect-ctディレクティブです。このデータは、ホストの「予想メタデータ」として集合的に知られています。
If an HTTP response does not include an Expect-CT header field that conforms to the grammar specified in Section 2.1, then the UA MUST NOT update any Expect-CT metadata.
HTTP応答に、セクション2.1で指定された文法に準拠する予想ヘッダーフィールドが含まれていない場合、UAは予想メタデータを更新してはなりません。
If the UA receives an HTTP response over a secure transport that includes an Expect-CT header field conforming to the grammar specified in Section 2.1, the UA MUST evaluate the connection on which the header field was received for compliance with the UA's CT Policy, and then process the Expect-CT header field as follows. UAs MUST ignore any Expect-CT header field received in an HTTP response conveyed over non-secure transport.
UAがセクション2.1で指定された文法に準拠した予想ヘッダーフィールドを含む安全なトランスポートを介してHTTP応答を受信した場合、UAはUAのCTポリシーの準拠のためにヘッダーフィールドが受信された接続を評価する必要があり、次に、次のように期待値ヘッダーフィールドを処理します。UASは、非セキュアな輸送を介して伝えられたHTTP応答で受け取った予想ヘッダーフィールドを無視する必要があります。
If the connection does not comply with the UA's CT Policy (i.e., the connection is not CT qualified), then the UA MUST NOT update any Expect-CT metadata. If the header field includes a report-uri directive, the UA SHOULD send a report to the specified report-uri (Section 2.3.3).
接続がUAのCTポリシーに準拠していない場合（つまり、接続がCT資格ではありません）、UAは予想メタデータを更新してはなりません。ヘッダーフィールドにReport-URI指令が含まれている場合、UAは指定されたレポート-URI（セクション2.3.3）にレポートを送信する必要があります。
If the connection complies with the UA's CT Policy (i.e., the connection is CT qualified), then the UA MUST either:
接続がUAのCTポリシーに準拠している場合（つまり、接続はCT資格があります）、UAは次のとおりです。
* Note the host as a Known Expect-CT Host if it is not already so noted (see Section 2.3.2.1) or
* まだ注意されていない場合は、既知の期待ホストとしてのホストに注意してください（セクション2.3.2.1を参照）または
* Update the UA's cached information for the Known Expect-CT Host if the enforce, max-age, or report-uri header field value directives convey information different from that already maintained by the UA. If the max-age directive has a value of 0, the UA MUST remove its cached Expect-CT information if the host was previously noted as a Known Expect-CT Host and MUST NOT note this host as a Known Expect-CT Host if it is not already noted.
* Enforce、Max-Age、またはReport-URI Header Field Value DirectivesがUAが維持しているものとは異なる情報を伝えている場合、既知の期待ホストのUAのキャッシュされた情報を更新します。Max-Ageディレクティブの値は0の場合、UAはホストが以前に既知の期待ホストとして記載されていた場合はキャッシュされた予想情報情報を削除する必要があり、このホストが既知の期待ホストとしてメモしてはなりません。まだ注目されていません。
If a UA receives an Expect-CT header field over a CT-compliant connection that uses a version of Certificate Transparency other than [RFC6962] or [RFC9162], the UA MUST ignore the Expect-CT header field and clear any Expect-CT metadata associated with the host.
UAが[RFC6962]または[RFC9162]以外の証明書透明性のバージョンを使用するCTに準拠した接続を介して、期待-CTヘッダーフィールドを受信した場合、UAは予想ヘッダーフィールドを無視し、期待-CTメタデータをクリアする必要があります。ホストに関連付けられています。
Upon receipt of the Expect-CT response header field over an error-free TLS connection (with X.509 certificate chain validation as described in [RFC5280], as well as the validation described in Section 2.4 of this document), the UA MUST note the host as a Known Expect-CT Host, storing the host's domain name and its associated Expect-CT directives in non-volatile storage.
エラーのないTLS接続（[RFC5280]に記載されているX.509証明書チェーン検証と、このドキュメントのセクション2.4に記載されている検証）を介した予想応答ヘッダーフィールドを受信すると、UAは注意する必要があります。既知の期待ホストとしてのホストは、ホストのドメイン名とそれに関連する予想CTディレクティブを不揮発性ストレージに保存します。
To note a host as a Known Expect-CT Host, the UA MUST set its Expect-CT metadata in its Known Expect-CT Host cache (as specified in Section 2.3.2.2), using the metadata given in the most recently received valid Expect-CT header field.
ホストを既知の予想ホストとして注目するために、UAは、最近受信した有効な期待値に与えられたメタデータを使用して、既知の予想ホストキャッシュ（セクション2.3.2.2で指定）に期待-CTメタデータを設定する必要があります。-CTヘッダーフィールド。
For forward compatibility, the UA MUST ignore any unrecognized Expect-CT header field directives while still processing those directives it does recognize. Section 2.1 specifies the directives enforce, max-age, and report-uri, but future specifications and implementations might use additional directives.
順方向の互換性のために、UAは、認識されているディレクティブを処理しながら、認識されていない予想ヘッダーフィールドディレクティブを無視する必要があります。セクション2.1は、ディレクティブの強制、最大年齢、およびレポートURIを指定しますが、将来の仕様と実装では追加のディレクティブが使用される場合があります。
If the substring matching the host production from the Request-URI (of the message to which the host responded) does not exactly match an existing Known Expect-CT Host's domain name, per the matching procedure for a Congruent Match specified in Section 8.2 of [RFC6797], then the UA MUST add this host to the Known Expect-CT Host cache. The UA caches:
[ホストが応答したメッセージの）のホスト制作と一致するサブストリングが、[既存の既知の既知のホストのドメイン名と正確に一致しない場合、[]のセクション8.2で指定された一致する一致手順に従って、[RFC6797]、UAはこのホストを既知のLecd-CTホストキャッシュに追加する必要があります。UAキャッシュ：
* the Expect-CT Host's domain name.
* expect-CTホストのドメイン名。
* whether the enforce directive is present.
* Enforce Directiveが存在するかどうか。
* the Effective Expiration Date, which is the Effective Expect-CT Date plus the value of the max-age directive. Alternatively, the UA MAY cache enough information to calculate the Effective Expiration Date. The Effective Expiration Date is calculated from when the UA observed the Expect-CT header field and is independent of when the response was generated.
* 有効な有効期限は、有効な予想-CT日付と最大年齢指令の値です。あるいは、UAは、有効な有効期限を計算するのに十分な情報をキャッシュすることができます。有効な有効期限は、UAが予想ヘッダーフィールドを観察したときから計算され、応答が生成されたときとは独立しています。
* the value of the report-uri directive, if present.
* 存在する場合、レポート-URI指令の値。
If any other metadata from optional or future Expect-CT header directives are present in the Expect-CT header field, and the UA understands them, the UA MAY note them as well.
オプションまたは将来のexpect-CTヘッダーディレクティブからの他のメタデータがexpect-CTヘッダーフィールドに存在し、UAがそれらを理解している場合、UAも同様にそれらに注意するかもしれません。
UAs MAY set an upper limit on the value of max-age so that UAs that have noted erroneous Expect-CT Hosts (whether by accident or due to attack) have some chance of recovering over time. If the server sets a max-age greater than the UA's upper limit, the UA may behave as if the server set the max-age to the UA's upper limit. For example, if the UA caps max-age at 5,184,000 seconds (60 days), and an Expect-CT Host sets a max-age directive of 90 days in its Expect-CT header field, the UA may behave as if the max-age were effectively 60 days. (One way to achieve this behavior is for the UA to simply store a value of 60 days instead of the 90-day value provided by the Expect-CT Host.)
UASは、最大年齢の価値に上限を設定することができ、誤った期待ホスト（偶然または攻撃のために）に誤って回復する可能性があることに気付いたUASが時間の経過とともに回復する可能性があります。サーバーがUAの上限よりも最大年齢を設定する場合、UAはサーバーが最大年齢をUAの上限に設定するかのように動作する可能性があります。たとえば、UAが最大年齢を5,184,000秒（60日）に上限し、予想ホストが予想ヘッダーフィールドで90日間の最大年齢指令を設定する場合、UAは最大のように振る舞う可能性があります。年齢は事実上60日でした。（この動作を達成する1つの方法は、UAが期待ホストが提供する90日間の値ではなく60日の値を単純に保存することです。）
If the UA receives, over a secure transport, an HTTP response that includes an Expect-CT header field with a report-uri directive, and the connection does not comply with the UA's CT Policy (i.e., the connection is not CT qualified), and the UA has not already sent an Expect-CT report for this connection, then the UA SHOULD send a report to the specified report-uri as specified in Section 3.
UAが安全なトランスポートを受信した場合、Report-URIディレクティブを備えた予想ヘッダーフィールドを含むHTTP応答があり、接続がUAのCTポリシーに準拠していません（つまり、接続はCT資格がありません）。また、UAはこの接続の予想レポートをまだ送信していないため、UAはセクション3で指定されているように、指定されたレポート-URIにレポートを送信する必要があります。
When a UA sets up a TLS connection, the UA determines whether the host is a Known Expect-CT Host according to its Known Expect-CT Host cache. An Expect-CT Host is "expired" if the Effective Expiration Date refers to a date in the past. The UA MUST ignore any expired Expect-CT Hosts in its cache and not treat such hosts as Known Expect-CT Hosts.
UAがTLS接続を設定すると、UAは、既知の期待ホストキャッシュに従ってホストが既知の期待ホストであるかどうかを決定します。有効な有効期限が過去の日付を参照している場合、予想ホストは「期限切れ」です。UAは、キャッシュで期限切れの予想ホストを無視する必要があり、既知の期待ホストなどのホストを扱わない必要があります。
When a UA connects to a Known Expect-CT Host using a TLS connection, if the TLS connection has no errors, then the UA will apply an additional correctness check: compliance with a CT Policy. A UA should evaluate compliance with its CT Policy whenever connecting to a Known Expect-CT Host. However, the check can be skipped for local policy reasons (as discussed in Section 2.4.1) or in the event that other checks cause the UA to terminate the connection before CT compliance is evaluated. For example, a Public Key Pinning failure [RFC7469] could cause the UA to terminate the connection before CT compliance is checked. Similarly, if the UA terminates the connection due to an Expect-CT failure, this could cause the UA to skip subsequent correctness checks. When the CT compliance check is skipped or bypassed, Expect-CT reports (Section 3) will not be sent.
UAがTLS接続を使用して既知の期待ホストに接続すると、TLS接続にエラーがない場合、UAは追加の正確性チェックを適用します：CTポリシーのコンプライアンス。UAは、既知の期待ホストに接続するたびに、CTポリシーのコンプライアンスを評価する必要があります。ただし、チェックは、地域のポリシー上の理由（セクション2.4.1で説明した）または他のチェックでCTコンプライアンスが評価される前にUAが接続を終了させた場合にスキップできます。たとえば、公開キーピン留め障害[RFC7469]により、CTコンプライアンスがチェックされる前にUAが接続を終了させる可能性があります。同様に、UAが予想障害のために接続を終了した場合、これによりUAが後続の正確さチェックをスキップする可能性があります。CTコンプライアンスチェックがスキップまたはバイパスされた場合、予想レポート（セクション3）は送信されません。
When CT compliance is evaluated for a Known Expect-CT Host, the UA MUST evaluate compliance when setting up the TLS session, before beginning an HTTP conversation over the TLS channel.
既知の期待ホストについてCTコンプライアンスが評価される場合、UAはTLSチャネルでHTTP会話を開始する前に、TLSセッションを設定するときにコンプライアンスを評価する必要があります。
If a connection to a Known Expect-CT Host violates the UA's CT Policy (i.e., the connection is not CT qualified), and if the Known Expect-CT Host's Expect-CT metadata indicates an enforce configuration, the UA MUST treat the CT compliance failure as an error. The UA MAY allow the user to bypass the error unless connection errors should have no user recourse due to other policies in effect (such as HSTS, as described in Section 12.1 of [RFC6797]).
既知の期待ホストへの接続がUAのCTポリシーに違反している場合（つまり、接続はCT資格がありません）、既知の期待ホストのexpect-CTメタデータがエンフォース構成を示した場合、UAはCTコンプライアンスを処理する必要がありますエラーとしての障害。UAは、他のポリシー（[RFC6797]のセクション12.1で説明されているように、HSTなど）のために接続エラーがユーザーの頼りにならない限り、ユーザーがエラーをバイパスすることを許可する場合があります。
If a connection to a Known Expect-CT Host violates the UA's CT Policy, and if the Known Expect-CT Host's Expect-CT metadata includes a report-uri, the UA SHOULD send an Expect-CT report to that report-uri (Section 3).
既知の予想ホストへの接続がUAのCTポリシーに違反し、既知の期待ホストのexpect-CTメタデータにレポート-URIが含まれている場合、UAはそのReport-URI（セクション）にexpect-CTレポートを送信する必要があります。3）。
It is acceptable for a UA to skip CT compliance checks for some hosts according to local policy. For example, a UA MAY disable CT compliance checks for hosts whose validated certificate chain terminates at a user-defined trust anchor rather than a trust anchor built in to the UA (or underlying platform).
UAがローカルポリシーに従って一部のホストのCTコンプライアンスチェックをスキップすることは許容されます。たとえば、UAは、検証された証明書チェーンがUA（または基礎となるプラットフォーム）に組み込まれた信頼アンカーではなく、ユーザー定義の信頼アンカーで終了するホストのCTコンプライアンスチェックを無効にする場合があります。
If the UA does not evaluate CT compliance, e.g., because the user has elected to disable it, or because a presented certificate chain chains up to a user-defined trust anchor, UAs SHOULD NOT send Expect-CT reports.
UAがCTコンプライアンスを評価していない場合、たとえばユーザーがそれを無効にすることを選択したため、または提示された証明書チェーンがユーザー定義のトラストアンカーにチェーンチェーンチェーンをチェーンするため、UASはexpect-CTレポートを送信すべきではありません。
When the UA attempts to connect to a Known Expect-CT Host and the connection is not CT qualified, the UA SHOULD report Expect-CT failures to the report-uri, if any, in the Known Expect-CT Host's Expect-CT metadata.
UAが既知の期待ホストに接続しようとし、接続がCT資格ではない場合、UAは既知の期待ホストのexpect-CTメタデータで、レポート障害をレポートURIに報告する必要があります。
When the UA receives an Expect-CT response header field over a connection that is not CT qualified, if the UA has not already sent an Expect-CT report for this connection, then the UA SHOULD report Expect-CT failures to the configured report-uri, if any.
UAがCT資格のない接続を介して期待-CT応答ヘッダーフィールドを受信した場合、UAがこの接続のexpect-CTレポートをまだ送信していない場合、UAは設定されたレポートにexpect-CT障害を報告する必要があります - URI、もしあれば。
To generate a violation report object, the UA constructs a JSON [RFC8259] object with the following keys and values:
違反レポートオブジェクトを生成するには、UAは次のキーと値を持つJSON [RFC8259]オブジェクトを構築します。
"date-time" The value for this key indicates the UTC time that the UA observed the CT compliance failure. The value is a string formatted according to Section 5.6 of [RFC3339], "Internet Date/Time Format".
「日付」このキーの値は、UAがCTコンプライアンスの障害を観察したUTC時間を示します。値は、[RFC3339]のセクション5.6「インターネット日付/時刻形式」に従ってフォーマットされています。
"hostname" The value is the hostname to which the UA made the original request that failed the CT compliance check. The value is provided as a string.
「ホスト名」値は、UAがCTコンプライアンスチェックに失敗した元のリクエストを行ったホスト名です。値は文字列として提供されます。
"port" The value is the port to which the UA made the original request that failed the CT compliance check. The value is provided as an integer.
「ポート」値は、UAがCTコンプライアンスチェックに失敗した元の要求を行ったポートです。値は整数として提供されます。
"scheme" (optional) The value is the scheme with which the UA made the original request that failed the CT compliance check. The value is provided as a string. This key is optional and is assumed to be "https" if not present.
「スキーム」（オプション）値は、UAがCTコンプライアンスチェックに失敗した元の要求を行ったスキームです。値は文字列として提供されます。このキーはオプションであり、存在しない場合は「https」であると想定されています。
"effective-expiration-date" The value indicates the Effective Expiration Date (see Section 2.3.2.2) for the Expect-CT Host that failed the CT compliance check, in UTC. The value is provided as a string formatted according to Section 5.6 of [RFC3339], "Internet Date/ Time Format".
「効果的なexpiration-date」値は、UTCのCTコンプライアンスチェックに失敗した予想ホストの有効な有効期限（セクション2.3.2.2を参照）を示します。値は、[RFC3339]のセクション5.6「インターネット日付/時刻形式」に従ってフォーマットされている文字列として提供されます。
"served-certificate-chain" The value is the certificate chain as served by the Expect-CT Host during TLS session setup. The value is provided as an array of strings, which MUST appear in the order that the certificates were served; each string in the array is the Privacy-Enhanced Mail (PEM) representation of each X.509 certificate as described in [RFC7468].
「提供された認証チェーン」は、TLSセッションのセットアップ中に予想ホストが提供する証明書チェーンです。値は一連の文字列として提供され、証明書が提供される順に表示されなければなりません。配列内の各文字列は、[RFC7468]で説明されている各X.509証明書のプライバシー強化メール（PEM）表現です。
"validated-certificate-chain" The value is the certificate chain as constructed by the UA during certificate chain verification. (This may differ from the value of the "served-certificate-chain" key.) The value is provided as an array of strings, which MUST appear in the order matching the chain that the UA validated; each string in the array is the PEM representation of each X.509 certificate as described in [RFC7468]. The first certificate in the chain represents the end-entity certificate being verified. UAs that build certificate chains in more than one way during the validation process SHOULD send the last chain built.
「検証済みの認証チェーン」値は、証明書チェーンの検証中にUAによって構築された証明書チェーンです。（これは、「提供された認証チェーン」キーの値とは異なる場合があります。）値は、UAが検証したチェーンと一致する順序で表示する必要がある文字列の配列として提供されます。配列内の各文字列は、[RFC7468]で説明されている各X.509証明書のPEM表現です。チェーン内の最初の証明書は、検証されているエンドエンティティ証明書を表します。検証プロセス中に複数の方法で証明書チェーンを構築するUASは、最後に構築されたチェーンを送信する必要があります。
"scts" The value represents the SCTs (if any) that the UA received for the Expect-CT Host and their validation statuses. The value is provided as an array of JSON objects. The SCTs may appear in any order. Each JSON object in the array has the following keys:
「SCT」値は、UAが期待ホストとその検証ステータスで受け取ったSCT（もしあれば）を表します。値は、JSONオブジェクトの配列として提供されます。SCTは任意の順序で表示される場合があります。配列内の各JSONオブジェクトには、次のキーがあります。
* A "version" key, with an integer value. The UA MUST set this value to 1 if the SCT is in the format defined in Section 3.2 of [RFC6962] or 2 if it is in the format defined in Section 4.5 of [RFC9162].
* 整数値を持つ「バージョン」キー。UAは、SCTが[RFC6962]のセクション3.2で定義されている形式である場合、[RFC9162]のセクション4.5で定義されている形式の場合は、この値を1に設定する必要があります。
* The "status" key, with a string value that the UA MUST set to one of the following values: "unknown" (indicating that the UA does not have or does not trust the public key of the log from which the SCT was issued); "valid" (indicating that the UA successfully validated the SCT as described in Section 5.2 of [RFC6962] or Section 8.1.3 of [RFC9162]); or "invalid" (indicating that the SCT validation failed because of a bad signature or an invalid timestamp).
* 「ステータス」キーは、UAが次の値のいずれかに設定する必要がある文字列値：「不明」（UAがSCTが発行されたログの公開鍵を持っていない、または信頼していないことを示しています）;「有効」（[RFC6962]のセクション5.2または[RFC9162]のセクション8.1.3で説明されているように、UAがSCTを正常に検証したことを示しています）;または「無効」（SCT検証が悪い署名または無効なタイムスタンプのために失敗したことを示す）。
* The "source" key, with a string value that indicates from where the UA obtained the SCT, as defined in Section 3 of [RFC6962] and Section 6 of [RFC9162]. The UA MUST set the value to one of the following: "tls-extension", "ocsp", or "embedded". These correspond to the three methods of delivering SCTs in the TLS handshake that are described in Section 3.3 of [RFC6962].
* [RFC6962]のセクション3および[RFC9162]のセクション6で定義されているように、UAがSCTを取得した場所から示す文字列値を使用して、「ソース」キー。UAは、値を次のいずれかのいずれかに設定する必要があります：「TLS-Extension」、「OCSP」、または「埋め込まれた」。これらは、[RFC6962]のセクション3.3で説明されているTLSハンドシェイクにSCTを提供する3つの方法に対応しています。
* The "serialized_sct" key, with a string value. If the value of the "version" key is 1, the UA MUST set this value to the base64-encoded [RFC4648] serialized SignedCertificateTimestamp structure from Section 3.2 of [RFC6962]. The base64 encoding is defined in Section 4 of [RFC4648]. If the value of the "version" key is 2, the UA MUST set this value to the base64-encoded [RFC4648] serialized TransItem structure representing the SCT, as defined in Section 4.5 of [RFC9162].
* 文字列値を持つ「Serialized_Sct」キー。「バージョン」キーの値が1の場合、UAは[RFC6962]のセクション3.2からSignedCertificateTimestamp構造をシリアル化したBase64エンコード[RFC4648]にこの値を設定する必要があります。base64エンコーディングは、[RFC4648]のセクション4で定義されています。「バージョン」キーの値が2の場合、UAはこの値を[RFC9162]のセクション4.5で定義しているように、SCTを表すSCTを表すSerialized Transitem構造にベース64エンコード[RFC4648]に設定する必要があります。
"failure-mode" The value indicates whether the Expect-CT report was triggered by an Expect-CT policy in enforce or report-only mode. The value is provided as a string. The UA MUST set this value to "enforce" if the Expect-CT metadata indicates an enforce configuration, and "report-only" otherwise.
「故障モード」値は、Expect-CTレポートが実施またはレポートのみのモードでの予想ポリシーによってトリガーされたかどうかを示します。値は文字列として提供されます。UAは、期待-CTメタデータがエンフォース構成を示し、それ以外の場合は「レポートのみ」を示す場合、この値を「強制」する必要があります。
"test-report" (optional) The value is set to true if the report is being sent by a testing client to verify that the report server behaves correctly. The value is provided as a boolean and MUST be set to true if the report serves to test the server's behavior and can be discarded.
「テストレポート」（オプション）レポートがテストクライアントによって送信されている場合、レポートサーバーが正しく動作していることを確認する場合、値はtrueに設定されます。値はブール値として提供され、レポートがサーバーの動作をテストし、破棄できる場合は真に設定する必要があります。
The UA SHOULD report Expect-CT failures for Known Expect-CT Hosts: that is, when a connection to a Known Expect-CT Host does not comply with the UA's CT Policy and the host's Expect-CT metadata contains a report-uri.
UAは、既知の期待ホストの期待-CT障害を報告する必要があります。つまり、既知の予想ホストへの接続がUAのCTポリシーに準拠しておらず、ホストのexpect-CTメタデータにレポート-URIが含まれている場合です。
Additionally, the UA SHOULD report Expect-CT failures for hosts for which it does not have any stored Expect-CT metadata; that is, when the UA connects to a host and receives an Expect-CT header field that contains the report-uri directive, the UA SHOULD report an Expect-CT failure if the connection does not comply with the UA's CT Policy.
さらに、UAは、保存されているexpect-CTメタデータがないホストに、予想障害を報告する必要があります。つまり、UAがホストに接続し、Report-URI指令を含む予想ヘッダーフィールドを受信する場合、UAは、接続がUAのCTポリシーに準拠していない場合、予想障害を報告する必要があります。
The steps to report an Expect-CT failure are as follows.
予想障害を報告する手順は次のとおりです。
1. Prepare a JSON object report object with the single key "expect-ct-report", whose value is the result of generating a violation report object as described in Section 3.1.
1. セクション3.1で説明されているように、違反レポートオブジェクトを生成した結果である単一のキー「expect-ct-report」を使用して、JSONオブジェクトレポートオブジェクトを準備します。
2. Let report body be the JSON stringification of report object.
2. レポート本文をレポートオブジェクトのJSON弦化とします。
3. Let report-uri be the value of the report-uri directive in the Expect-CT header field.
3. Report-uriを、Report-uri指令の値としてください。
4. Send an HTTP POST request to report-uri with a Content-Type header field of application/expect-ct-report+json and an entity body consisting of report body.
4. Report-URIへのHTTP POSTリクエストを送信して、アプリケーション/予想CT-CTレポートJSONのコンテンツタイプのヘッダーフィールドとレポート本体で構成されるエンティティボディを備えています。
The UA MAY perform other operations as part of sending the HTTP POST request, such as sending a Cross-Origin Resource Sharing (CORS) preflight as part of [FETCH].
UAは、[フェッチ]の一部としてクロスオリジンリソース共有（CORS）プリライトを送信するなど、HTTP POSTリクエストの送信の一部として他の操作を実行できます。
Future versions of this specification may need to modify or extend the Expect-CT report format. They may do so by defining a new top-level key to contain the report, replacing the "expect-ct-report" key. Section 3.3 defines how report servers should handle report formats that they do not support.
この仕様の将来のバージョンでは、expect-CTレポート形式を変更または拡張する必要がある場合があります。彼らは、レポートを封じ込めるために新しいトップレベルのキーを定義して、「予想されるCTレポート」キーを置き換えることでそうすることができます。セクション3.3は、レポートサーバーがサポートしていないレポート形式を処理する方法を定義しています。
Upon receiving an Expect-CT violation report, the report server MUST respond with a 2xx (Successful) status code if it can parse the request body as valid JSON, the report conforms to the format described in Section 3.1, and it recognizes the scheme, hostname, and port in the "scheme", "hostname", and "port" fields of the report. If the report body cannot be parsed or does not conform to the format described in Section 3.1, or the report server does not expect to receive reports for the scheme, hostname, or port in the report, then the report server MUST respond with a 400 Bad Request status code.
予想違反レポートを受信すると、レポートサーバーは、リクエストボディを有効なJSONとして解析できる場合、2XX（成功）ステータスコードで応答する必要があります。レポートはセクション3.1で説明されている形式に準拠し、スキームを認識します。レポートの「スキーム」、「ホスト名」、「ポート」フィールドのホスト名、およびポート。レポート本体を解析できないか、セクション3.1で説明されている形式に準拠していない場合、またはレポートサーバーがレポートのスキーム、ホスト名、またはポートのレポートを受信する予定である場合、レポートサーバーは400で応答する必要があります。悪い要求ステータスコード。
As described in Section 3.2, future versions of this specification may define new report formats that are sent with a different top-level key. If the report server does not recognize the report format, the report server MUST respond with a 501 Not Implemented status code.
セクション3.2で説明したように、この仕様の将来のバージョンは、異なるトップレベルキーで送信される新しいレポート形式を定義する場合があります。レポートサーバーがレポート形式を認識していない場合、レポートサーバーは501が実装されていないステータスコードで応答する必要があります。
If the report's "test-report" key is set to true, the server MAY discard the report without further processing but MUST still return a 2xx (Successful) status code. If the "test-report" key is absent or set to false, the server SHOULD store the report for processing and analysis by the owner of the Expect-CT Host.
レポートの「テストレポート」キーがTrueに設定されている場合、サーバーはさらに処理せずにレポートを破棄することができますが、2xx（成功）ステータスコードを返す必要があります。「テストレポート」キーが存在しない、またはfalseに設定されている場合、サーバーは、Repud-CTホストの所有者による処理と分析のためにレポートを保存する必要があります。
When the UA detects a Known Expect-CT Host in violation of the UA's CT Policy, end users will experience denials of service. It is advisable for UAs to explain to users why they cannot access the Expect-CT Host, e.g., in a user interface that explains that the host's certificate cannot be validated.
UAがUAのCTポリシーに違反して既知の予想ホストを検出すると、エンドユーザーはサービスの拒否を経験します。UASがユーザーに、Hostの証明書を検証できないことを説明するユーザーインターフェイスで、Host-CTホストにアクセスできない理由をユーザーに説明することをお勧めします。
Expect-CT could be specified as a TLS extension or X.509 certificate extension instead of an HTTP response header field. Using an HTTP header field as the mechanism for Expect-CT introduces a layering mismatch; for example, the software that terminates TLS and validates Certificate Transparency information might know nothing about HTTP. Nevertheless, an HTTP header field was chosen primarily for ease of deployment. In practice, deploying new certificate extensions requires certificate authorities to support them, and new TLS extensions require server software updates, including possibly to servers outside of the site owner's direct control (such as in the case of a third-party Content Delivery Network (CDN)). Ease of deployment is a high priority for Expect-CT because it is intended as a temporary transition mechanism for user agents that are transitioning to universal Certificate Transparency requirements.
HTTP応答ヘッダーフィールドではなく、TLS拡張子またはX.509証明書拡張機能として予想を指定できます。HTTPヘッダーフィールドを使用すると、expect-CTのメカニズムとしてレイヤー化の不一致が導入されます。たとえば、TLSを終了して証明書の透明性情報を検証するソフトウェアは、HTTPについて何も知らない場合があります。それにもかかわらず、HTTPヘッダーフィールドは、主に展開を容易にするために選択されました。実際には、新しい証明書拡張機能を展開するには証明書当局がそれらをサポートする必要があり、新しいTLS拡張機能には、サイト所有者の直接制御以外のサーバー（サードパーティのコンテンツ配信ネットワークの場合（CDNなど）などのサーバーソフトウェア更新が必要です。））。展開の容易さは、普遍的な証明書の透明性要件に移行しているユーザーエージェントの一時的な遷移メカニズムとして意図されているため、展開の容易さが最優先事項です。
Expect-CT can be used to infer what Certificate Transparency Policy a UA is using by attempting to retrieve specially configured websites that pass one user agent's policies but not another's. Note that this consideration is true of UAs that enforce CT policies without Expect-CT as well.
expect-CTは、1つのユーザーエージェントのポリシーを通過するが別のポリシーではなく、特別に構成されたWebサイトを取得しようとすることにより、UAが使用している証明書の透明性ポリシーを推測するために使用できます。この考慮事項は、予想なしでもCTポリシーを実施するUASに当てはまることに注意してください。
Additionally, reports submitted to the report-uri could reveal information to a third party about which web page is being accessed and by which IP address, by using individual report-uri values for individually tracked pages. This information could be leaked even if client-side scripting were disabled.
さらに、Report-URIに提出されたレポートは、個別に追跡されたページに個別のレポート-RI値を使用して、どのWebページがアクセスされているか、およびどのIPアドレスがどのIPアドレスにアクセスされているかについての情報を第三者に公開することができます。クライアント側のスクリプトが無効になっていても、この情報は漏れている可能性があります。
Implementations store state about Known Expect-CT Hosts and, hence, which domains the UA has contacted. Implementations may choose to not store this state subject to local policy (e.g., in the private browsing mode of a web browser).
実装では、既知の期待ホスト、したがって、UAが連絡したドメインについての状態を保存します。実装は、この状態をローカルポリシーの対象としないことを選択する場合があります（たとえば、Webブラウザーのプライベートブラウジングモード）。
Violation reports, as noted in Section 3, contain information about the certificate chain that has violated the CT Policy. In some cases, such as an organization-wide compromise of the end-to-end security of TLS, this may include information about the interception tools and design used by the organization that the organization would otherwise prefer not be disclosed.
セクション3に記載されているように、違反レポートには、CTポリシーに違反した証明書チェーンに関する情報が含まれています。TLSのエンドツーエンドのセキュリティの組織全体の妥協など、場合によっては、組織が開示しないことを好まない組織が使用する傍受ツールと設計に関する情報が含まれる場合があります。
Because Expect-CT causes remotely detectable behavior, it's advisable that UAs offer a way for privacy-sensitive end users to clear currently noted Expect-CT Hosts and allow users to query the current state of Known Expect-CT Hosts.
Lecd-CTはリモートで検出可能な動作を引き起こすため、UASがプライバシーに敏感なエンドユーザーが現在注目されているHost-CTホストをクリアし、ユーザーが既知の期待ホストの現在の状態を照会できるようにすることをお勧めします。
When UAs support the Expect-CT header field, it becomes a potential vector for hostile header attacks against site owners. If a site owner uses a certificate issued by a certificate authority that does not embed SCTs nor serve SCTs via the Online Certificate Status Protocol (OCSP) or TLS extension, a malicious server operator or attacker could temporarily reconfigure the host to comply with the UA's CT Policy and add the Expect-CT header field in enforcing mode with a long max-age. Implementing user agents would note this as an Expect-CT Host (see Section 2.3.2.1). After having done this, the configuration could then be reverted to not comply with the CT Policy, prompting failures. Note that this scenario would require the attacker to have substantial control over the infrastructure in question, being able to obtain different certificates, change server software, or act as a man in the middle in connections.
UASが予想ヘッダーフィールドをサポートすると、サイト所有者に対する敵対的なヘッダー攻撃の潜在的なベクトルになります。サイトの所有者が、SCTを埋め込んでいない、またはオンライン証明書ステータスプロトコル（OCSP）またはTLS拡張機能を介してSCTを提供しない証明書当局によって発行された証明書を使用する場合、悪意のあるサーバーオペレーターまたは攻撃者がHostに一時的に再構成してUAのCTに準拠することができますポリシーと、長い最大年齢で実施モードで期待-CTヘッダーフィールドを追加します。ユーザーエージェントの実装は、これを予想ホストとして指摘します（セクション2.3.2.1を参照）。これを行った後、CTポリシーに準拠しないように構成を戻すことができ、障害を促しました。このシナリオでは、攻撃者が問題のインフラストラクチャを大幅に制御し、さまざまな証明書を取得したり、サーバーソフトウェアを変更したり、接続されている中央の男性として機能したりする必要があることに注意してください。
Site operators can mitigate this situation by one of the following: reconfiguring their web server to transmit SCTs using the TLS extension defined in Section 6.5 of [RFC9162]; obtaining a certificate from an alternative certificate authority that provides SCTs by one of the other methods; or by waiting for the user agent's persisted notation of this as an Expect-CT Host to reach its max-age. User agents may choose to implement mechanisms for users to cure this situation, as noted in Section 4.
サイトオペレーターは、次のいずれかでこの状況を軽減できます。[RFC9162]のセクション6.5で定義されているTLS拡張機能を使用してSCTを送信するようにWebサーバーを再構成します。他の方法の1つによってSCTを提供する代替証明書当局から証明書を取得する。または、ユーザーエージェントが最大年齢に到達するための予想ホストとしてこれの永続的な表記を待つことによって。ユーザーエージェントは、セクション4に記載されているように、ユーザーがこの状況を治すためのメカニズムを実装することを選択できます。
There is a security trade-off in that low maximum values provide a narrow window of protection for users that visit the Known Expect-CT Host only infrequently, while high maximum values might result in a denial of service to a UA in the event of a hostile header attack or simply an error on the part of the site owner.
低い最大値にはセキュリティトレードオフがあります。既知の期待ホストに訪問するユーザーに狭い保護ウィンドウを提供することはまれですが、最大値が高い場合は、UAのサービス拒否をもたらす可能性があります。敵対的なヘッダー攻撃、またはサイト所有者の側の単にエラー。
There is probably no ideal maximum for the max-age directive. Since Expect-CT is primarily a policy-expansion and investigation technology rather than an end-user protection, a value on the order of 30 days (2,592,000 seconds) may be considered a balance between these competing security concerns.
おそらく、最大年齢指令に理想的な最大値はありません。予想CTは主にエンドユーザー保護ではなく、政策拡張および調査技術であるため、30日間（2,592,000秒）の価値は、これらの競合するセキュリティ上の懸念のバランスと見なされる場合があります。
Another kind of hostile header attack uses the report-uri mechanism on many hosts not currently exposing SCTs as a method to cause a denial of service to the host receiving the reports. If some highly trafficked websites emitted a non-enforcing Expect-CT header field with a report-uri, implementing UAs' reports could flood the reporting host. It is noted in Section 2.1.1 that UAs should limit the rate at which they emit reports, but an attacker may alter the Expect-CT header fields to induce UAs to submit different reports to different URIs to still cause the same effect.
別の種類の敵対的なヘッダー攻撃は、レポートを受け取るホストにサービスの拒否を引き起こす方法として現在SCTを暴露していない多くのホストに関するレポート-URIメカニズムを使用しています。いくつかの非常に人身売買されたWebサイトが、レポート-URIを使用して非強化されている予想ヘッダーフィールドを放出した場合、UASのレポートを実装すると、レポートホストに殺到する可能性があります。セクション2.1.1には、UASがレポートを発するレートを制限する必要があることが指摘されていますが、攻撃者は、期待-CTヘッダーフィールドを変更してUASに異なるReportsを異なるURIに送信して同じ効果を引き起こす可能性があります。
This document registers the "Expect-CT" header field in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" registry located at <https://www.iana.org/assignments/http-fields>.
このドキュメントは、<https://www.iana.org/assignments/http-fields>にある「HyperText Transfer Protocol（http）フィールド名レジストリ」レジストリの「expect-ct」ヘッダーフィールドを登録します。
Header field name: Expect-CT
ヘッダーフィールド名：expect-ct
Applicable protocol: http
該当するプロトコル：http
Status: permanent
ステータス：永続的
Author/Change controller: IETF
著者/変更コントローラー：IETF
Specification document(s): This document
仕様文書：このドキュメント
Related information: (empty)
関連情報：（空）
This document registers the application/expect-ct-report+json media type (which uses the suffix established in [RFC6839]) for Expect-CT violation reports in the "Media Types" registry as follows.
このドキュメントは、次のように、「メディアタイプ」レジストリの予想違反レポートのために、アプリケーション/expect-ct-ct-report JSONメディアタイプ（[RFC6839]で確立された接尾辞を使用）を登録します。
Type name: application
タイプ名：アプリケーション
Subtype name: expect-ct-report+json
サブタイプ名：expect-ct-report json
Required parameters: n/a
必要なパラメーター：n/a
Optional parameters: n/a
オプションのパラメーター：n/a
Encoding considerations: binary
考慮事項のエンコード：バイナリ
Security considerations: See Section 7
セキュリティ上の考慮事項：セクション7を参照してください
Interoperability considerations: n/a
相互運用性の考慮事項：n/a
Published specification: This document
公開された仕様：このドキュメント
Applications that use this media type: UAs that implement Certificate Transparency compliance checks and reporting
このメディアタイプを使用するアプリケーション：証明書の透明性コンプライアンスチェックとレポートを実装するUAS
Additional information:
追加情報：
Deprecated alias names for this type: n/a
このタイプの非推奨エイリアス名：n/a
Magic number(s): n/a
File extension(s): n/a
Macintosh file type code(s): n/a
Person & email address to contact for further information: Emily Stark (estark@google.com)
詳細については、人とメールアドレスをお問い合わせ：Emily Stark（ettark@google.com）
Intended usage: COMMON
意図された使用法：共通
Restrictions on usage: none
使用に関する制限：なし
Author: Emily Stark (estark@google.com)
著者：エミリー・スターク（ettark@google.com）
Change controller: IETF
Change Controller：IETF
[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。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487/RFC2119、1997年3月、<https://www.rfc-editor.org/info/RFC2119>。
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/info/rfc3339>.
[RFC3339] Klyne、G。and C. Newman、「インターネット上の日時：タイムスタンプ」、RFC 3339、DOI 10.17487/RFC3339、2002年7月、<https://www.rfc-editor.org/info/RFC3333999999999999999999999999999999999999999999999>。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、Std 66、RFC 3986、DOI 10.17487/RFC3986、2005年1月、<https：//www.rfc-editor.org/info/rfc3986>。
[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>.
[RFC4648] Josefsson、S。、「Base16、Base32、およびBase64 Data Encodings」、RFC 4648、DOI 10.17487/RFC4648、2006年10月、<https://www.rfc-editor.org/info/rfc4648>
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234] Crocker、D.、ed。P. Overell、「構文仕様のためのBNFの増強：ABNF：STD 68、RFC 5234、DOI 10.17487/RFC5234、2008年1月、<https://www.rfc-editor.org/info/rfc5234>。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW. Polk、 "Internet X.509 Public Key Infrastructure Certificate and Certificate Recocation List（CRL）プロファイル"、RFC 5280、DOI 10.17487/RFC5280、2008年5月、<https://www.rfc-editor.org/info/rfc5280>。
[RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict Transport Security (HSTS)", RFC 6797, DOI 10.17487/RFC6797, November 2012, <https://www.rfc-editor.org/info/rfc6797>.
[RFC6797] Hodges、J.、Jackson、C。、およびA. Barth、「HTTP Strict Transport Security（HSTS）」、RFC 6797、DOI 10.17487/RFC6797、2012年11月、<https：//www.rfc-editor。org/info/rfc6797>。
[RFC6839] Hansen, T. and A. Melnikov, "Additional Media Type Structured Syntax Suffixes", RFC 6839, DOI 10.17487/RFC6839, January 2013, <https://www.rfc-editor.org/info/rfc6839>.
[RFC6839] Hansen、T。およびA. Melnikov、「追加のメディア型構造化された構文接尾辞」、RFC 6839、DOI 10.17487/RFC6839、2013年1月、<https://www.rfc-editor.org/info/rfc6839>
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, <https://www.rfc-editor.org/info/rfc6962>.
[RFC6962] Laurie、B.、Langley、A。、およびE. Kasper、「証明書の透明性」、RFC 6962、DOI 10.17487/RFC6962、2013年6月、<https://www.rfc-editor.org/info/RFC69622>。
[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>.
[RFC7468] Josefsson、S。and S. Leonard、「PKIX、PKCS、およびCMS構造のテキストエンコーディング」、RFC 7468、DOI 10.17487/RFC7468、2015年4月、<https：//www.rfc-editor.org/info/RFC7468>。
[RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 2015, <https://www.rfc-editor.org/info/rfc7469>.
[RFC7469] Evans、C.、Palmer、C.、およびR. Sleevi、「HTTPの公開キーピンニング拡張」、RFC 7469、DOI 10.17487/RFC7469、2015年4月、<https://www.rfc-editor.org/info/rfc7469>。
[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>。
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.
[RFC8259] Bray、T.、ed。、「JavaScriptオブジェクト表記（JSON）データインターチェンジ形式」、STD 90、RFC 8259、DOI 10.17487/RFC8259、2017年12月、<https：//www.rfc-editor.org/info/rfc8259>。
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/info/rfc9110>.
[RFC9110] Fielding、R.、Ed。、Ed。、Nottingham、M.、Ed。、およびJ. Reschke、ed。、 "HTTP Semantics"、Std 97、RFC 9110、DOI 10.17487/RFC9110、2022年6月、<https：//www.rfc-editor.org/info/rfc9110>。
[RFC9111] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Caching", STD 98, RFC 9111, DOI 10.17487/RFC9111, June 2022, <https://www.rfc-editor.org/info/rfc9111>.
[RFC9111] Fielding、R.、Ed。、Ed。、Nottingham、M.、Ed。、およびJ. Reschke、ed。、 "Http Caching"、Std 98、RFC 9111、DOI 10.17487/RFC9111、2022年6月、<https：//www.rfc-editor.org/info/rfc9111>。
[RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162, December 2021, <https://www.rfc-editor.org/info/rfc9162>.
[RFC9162] Laurie、B.、Messeri、E。、およびR. Stradling、「証明書透明性バージョン2.0」、RFC 9162、DOI 10.17487/RFC9162、2021年12月、<https://www.rfc-editor.org/info/rfc9162>。
[FETCH] WHATWG, "Fetch - Living Standard", <https://fetch.spec.whatwg.org>.
[Fetch] Whatwg、 "Fetch -Living Standard"、<https://fetch.spec.whatwg.org>。
[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/rfc846>
Author's Address
著者の住所
Emily Stark Google Email: estark@google.com
Emily Stark Google電子メール：Estark@google.com