[要約] RFC 8291は、Web Pushプロトコルにおけるメッセージの暗号化に関する規定を定めた文書です。このRFCの目的は、Webアプリケーションがサーバーからクライアントへ安全にメッセージを送信できるようにすることにあります。具体的には、プッシュ通知を介してユーザーのデバイスに送信されるデータのプライバシーとセキュリティを保護するための暗号化メカニズムを提供します。このRFCは、Web Pushプロトコルを使用するアプリケーション開発者やサービスプロバイダーにとって重要であり、関連するRFCにはRFC 8030（Web Pushプロトコル自体を定義）などがあります。
Internet Engineering Task Force (IETF) M. Thomson
Request for Comments: 8291 Mozilla
Category: Standards Track November 2017
ISSN: 2070-1721
Message Encryption for Web Push
Webプッシュのメッセージ暗号化
Abstract
概要
This document describes a message encryption scheme for the Web Push protocol. This scheme provides confidentiality and integrity for messages sent from an application server to a user agent.
このドキュメントでは、Webプッシュプロトコルのメッセージ暗号化スキームについて説明します。このスキームは、アプリケーションサーバーからユーザーエージェントに送信されるメッセージの機密性と整合性を提供します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc8291.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8291で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限について説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Notational Conventions .....................................3
2. Push Message Encryption Overview ................................3
2.1. Key and Secret Distribution ................................4
3. Push Message Encryption .........................................4
3.1. Diffie-Hellman Key Agreement ...............................5
3.2. Push Message Authentication ................................5
3.3. Combining Shared and Authentication Secrets ................5
3.4. Encryption Summary .........................................6
4. Restrictions on Use of "aes128gcm" Content Coding ...............7
5. Push Message Encryption Example .................................8
6. IANA Considerations .............................................8
7. Security Considerations .........................................8
8. References .....................................................10
8.1. Normative References ......................................10
8.2. Informative References ....................................11
Appendix A. Intermediate Values for Encryption ...................12
Author's Address ..................................................13
The Web Push protocol [RFC8030] is an intermediated protocol by necessity. Messages from an application server are delivered to a user agent (UA) via a push service, as shown in Figure 1.
Webプッシュプロトコル[RFC8030]は、必要に応じて中間的なプロトコルです。図1に示すように、アプリケーションサーバーからのメッセージは、プッシュサービスを介してユーザーエージェント（UA）に配信されます。
+-------+ +--------------+ +-------------+
| UA | | Push Service | | Application |
+-------+ +--------------+ +-------------+
| | |
| Setup | |
|<====================>| |
| Provide Subscription |
|-------------------------------------------->|
| | |
: : :
| | Push Message |
| Push Message |<---------------------|
|<---------------------| |
| | |
Figure 1
図1
This document describes how messages sent using this protocol can be secured against inspection, modification, and forgery by a push service.
このドキュメントでは、このプロトコルを使用して送信されたメッセージを、プッシュサービスによる検査、変更、および偽造から保護する方法について説明します。
Web Push messages are the payload of an HTTP message [RFC7230]. These messages are encrypted using an encrypted content encoding [RFC8188]. This document describes how this content encoding is applied and describes a recommended key management scheme.
Webプッシュメッセージは、HTTPメッセージのペイロードです[RFC7230]。これらのメッセージは、暗号化されたコンテンツエンコーディング[RFC8188]を使用して暗号化されます。このドキュメントでは、このコンテンツエンコーディングの適用方法と、推奨されるキー管理スキームについて説明します。
Multiple users of Web Push at the same user agent often share a central agent that aggregates push functionality. This agent can enforce the use of this encryption scheme by applications that use push messaging. An agent that only delivers messages that are properly encrypted strongly encourages the end-to-end protection of messages.
同じユーザーエージェントでWebプッシュの複数のユーザーが、プッシュ機能を集約する中央エージェントを共有することがよくあります。このエージェントは、プッシュメッセージングを使用するアプリケーションによるこの暗号化スキームの使用を強制できます。適切に暗号化されたメッセージのみを配信するエージェントは、メッセージのエンドツーエンドの保護を強く推奨します。
A web browser that implements the Push API [API] can enforce the use of encryption by forwarding only those messages that were properly encrypted.
Push API [API]を実装するWebブラウザは、適切に暗号化されたメッセージのみを転送することにより、暗号化の使用を強制できます。
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]で説明されているように解釈されます。
This document uses the terminology from [RFC8030], primarily "user agent", "push service", and "application server".
このドキュメントでは、[RFC8030]の用語、主に「ユーザーエージェント」、「プッシュサービス」、「アプリケーションサーバー」を使用します。
Encrypting a push message uses Elliptic Curve Diffie-Hellman (ECDH) [ECDH] on the P-256 curve [FIPS186] to establish a shared secret (see Section 3.1) and a symmetric secret for authentication (see Section 3.2).
プッシュメッセージの暗号化では、P-256曲線[FIPS186]の楕円曲線Diffie-Hellman（ECDH）[ECDH]を使用して、共有シークレット（セクション3.1を参照）と認証用の対称シークレット（セクション3.2を参照）を確立します。
A user agent generates an ECDH key pair and authentication secret that it associates with each subscription it creates. The ECDH public key and the authentication secret are sent to the application server with other details of the push subscription.
ユーザーエージェントは、作成する各サブスクリプションに関連付けるECDHキーペアと認証シークレットを生成します。 ECDH公開鍵と認証シークレットは、プッシュサブスクリプションの他の詳細とともにアプリケーションサーバーに送信されます。
When sending a message, an application server generates an ECDH key pair and a random salt. The ECDH public key is encoded into the "keyid" parameter of the encrypted content coding header, and the salt is encoded into the "salt" parameter of that same header (see Section 2.1 of [RFC8188]). The ECDH key pair can be discarded after encrypting the message.
メッセージを送信するとき、アプリケーションサーバーはECDHキーペアとランダムソルトを生成します。 ECDH公開鍵は暗号化されたコンテンツコーディングヘッダーの「keyid」パラメーターにエンコードされ、saltは同じヘッダーの「salt」パラメーターにエンコードされます（[RFC8188]のセクション2.1を参照）。 ECDHキーペアは、メッセージの暗号化後に破棄できます。
The content of the push message is encrypted or decrypted using a content encryption key and nonce. These values are derived by taking the "keyid" and "salt" as input to the process described in Section 3.
プッシュメッセージのコンテンツは、コンテンツ暗号化キーとナンスを使用して暗号化または復号化されます。これらの値は、「keyid」と「salt」をセクション3で説明するプロセスへの入力として取得することによって得られます。
The application using the subscription distributes the subscription public key and authentication secret to an authorized application server. This could be sent along with other subscription information that is provided by the user agent, such as the push subscription URI.
サブスクリプションを使用するアプリケーションは、サブスクリプションの公開鍵と認証シークレットを許可されたアプリケーションサーバーに配布します。これは、プッシュサブスクリプションURIなど、ユーザーエージェントによって提供される他のサブスクリプション情報と共に送信できます。
An application MUST use an authenticated, confidentiality-protected communications medium for this purpose. In addition to the reasons described in [RFC8030], this use ensures that the authentication secret is not revealed to unauthorized entities, which would allow those entities to generate push messages that will be accepted by the user agent.
アプリケーションは、この目的のために、認証され、機密性が保護された通信メディアを使用する必要があります。 [RFC8030]で説明されている理由に加えて、この使用により、認証シークレットが許可されていないエンティティに明らかにされないため、これらのエンティティはユーザーエージェントによって受け入れられるプッシュメッセージを生成できます。
Most applications that use push messaging have a preexisting relationship with an application server that can be used for distribution of subscription data. An authenticated communication mechanism that provides adequate confidentiality and integrity protection, such as HTTPS [RFC2818], is sufficient.
プッシュメッセージングを使用するほとんどのアプリケーションには、サブスクリプションデータの配布に使用できるアプリケーションサーバーとの既存の関係があります。 HTTPS [RFC2818]などの適切な機密性と整合性保護を提供する認証された通信メカニズムで十分です。
Push message encryption happens in four phases:
プッシュメッセージの暗号化は4つのフェーズで行われます。
o A shared secret is derived using ECDH [ECDH] (see Section 3.1 of this document).
o 共有秘密はECDH [ECDH]を使用して導出されます（このドキュメントのセクション3.1を参照）。
o The shared secret is then combined with the authentication secret to produce the input keying material (IKM) used in [RFC8188] (see Section 3.3 of this document).
o 共有シークレットは認証シークレットと組み合わされて、[RFC8188]で使用される入力キーイングマテリアル（IKM）を生成します（このドキュメントのセクション3.3を参照）。
o A content encryption key and nonce are derived using the process in [RFC8188].
o コンテンツ暗号化キーとノンスは、[RFC8188]のプロセスを使用して導出されます。
o Encryption or decryption follows according to [RFC8188].
o 暗号化または復号化は、[RFC8188]に従って行われます。
The key derivation process is summarized in Section 3.4. Restrictions on the use of the encrypted content coding are described in Section 4.
主要な導出プロセスはセクション3.4に要約されています。暗号化されたコンテンツコーディングの使用に関する制限については、セクション4で説明します。
For each new subscription that the user agent generates for an application, it also generates a P-256 [FIPS186] key pair for use in ECDH [ECDH].
ユーザーエージェントがアプリケーションに対して生成する新しいサブスクリプションごとに、ECDH [ECDH]で使用するためのP-256 [FIPS186]キーペアも生成します。
When sending a push message, the application server also generates a new ECDH key pair on the same P-256 curve.
プッシュメッセージを送信するとき、アプリケーションサーバーは同じP-256曲線上に新しいECDHキーペアも生成します。
The ECDH public key for the application server is included as the "keyid" parameter in the encrypted content coding header (see Section 2.1 of [RFC8188]).
アプリケーションサーバーのECDH公開鍵は、暗号化されたコンテンツコーディングヘッダーの「keyid」パラメーターとして含まれています（[RFC8188]のセクション2.1を参照）。
An application server combines its ECDH private key with the public key provided by the user agent using the process described in [ECDH]; on receipt of the push message, a user agent combines its private key with the public key provided by the application server in the "keyid" parameter in the same way. These operations produce the same value for the ECDH shared secret.
アプリケーションサーバーは、ECDH秘密キーを、[ECDH]で説明されているプロセスを使用してユーザーエージェントによって提供された公開キーと結合します。プッシュメッセージを受信すると、ユーザーエージェントは、その秘密鍵を、アプリケーションサーバーから「keyid」パラメーターで提供された公開鍵と同じ方法で結合します。これらの操作により、ECDH共有秘密に同じ値が生成されます。
To ensure that push messages are correctly authenticated, a symmetric authentication secret is added to the information generated by a user agent. The authentication secret is mixed into the key derivation process described in Section 3.3.
プッシュメッセージが正しく認証されるように、対称認証シークレットがユーザーエージェントによって生成される情報に追加されます。認証シークレットは、セクション3.3で説明する鍵導出プロセスに組み込まれています。
A user agent MUST generate and provide a hard-to-guess sequence of 16 octets that is used for authentication of push messages. This SHOULD be generated by a cryptographically strong random number generator [RFC4086].
ユーザーエージェントは、プッシュメッセージの認証に使用される16オクテットの推測しにくいシーケンスを生成および提供する必要があります。これは、暗号学的に強力な乱数ジェネレータ[RFC4086]によって生成されるべきです（SHOULD）。
The shared secret produced by ECDH is combined with the authentication secret using the HMAC-based key derivation function (HKDF) [RFC5869]. This produces the input keying material used by [RFC8188].
ECDHによって生成された共有秘密は、HMACベースの鍵導出関数（HKDF）[RFC5869]を使用して認証秘密と結合されます。これにより、[RFC8188]で使用される入力鍵情報が生成されます。
The HKDF function uses the SHA-256 hash algorithm [FIPS180-4] with the following inputs:
HKDF関数は、SHA-256ハッシュアルゴリズム[FIPS180-4]を使用し、次の入力を使用します。
salt: the authentication secret
salt：認証シークレット
IKM: the shared secret derived using ECDH info: the concatenation of the ASCII-encoded string "WebPush: info" (this string is not NUL-terminated), a zero octet, the user agent ECDH public key, and the application server ECDH public key, (both ECDH public keys are in the uncompressed point form defined in [X9.62]. That is:
IKM：ECDH情報を使用して導出された共有秘密：ASCIIエンコードされた文字列「WebPush：info」（この文字列はNULで終了しない）、ゼロオクテット、ユーザーエージェントECDH公開鍵、およびアプリケーションサーバーECDH公開の連結key（両方のECDH公開鍵は、[X9.62]で定義されている非圧縮ポイント形式です。つまり、
key_info = "WebPush: info" || 0x00 || ua_public || as_public
key_info = "WebPush：info" || 0x00 || ua_public || as_public
L: 32 octets (i.e., the output is the length of the underlying SHA-256 HMAC function output)
L：32オクテット（つまり、出力は、基になるSHA-256 HMAC関数出力の長さです）
This results in a final content encryption key and nonce generation using the following sequence, which is shown here in pseudocode with HKDF expanded into separate discrete steps using HMAC with SHA-256:
これにより、次のシーケンスを使用して最終的なコンテンツ暗号化キーとノンスが生成されます。これは、SHA-256でHMACを使用して、HKDFを個別の個別のステップに展開した疑似コードで示しています。
-- For a user agent:
ecdh_secret = ECDH(ua_private, as_public)
auth_secret = random(16)
salt = <from content coding header>
-- For an application server:
ecdh_secret = ECDH(as_private, ua_public)
auth_secret = <from user agent>
salt = random(16)
-- For both:
- 両方のための：
## Use HKDF to combine the ECDH and authentication secrets
# HKDF-Extract(salt=auth_secret, IKM=ecdh_secret)
PRK_key = HMAC-SHA-256(auth_secret, ecdh_secret)
# HKDF-Expand(PRK_key, key_info, L_key=32)
key_info = "WebPush: info" || 0x00 || ua_public || as_public
IKM = HMAC-SHA-256(PRK_key, key_info || 0x01)
## HKDF calculations from RFC 8188
# HKDF-Extract(salt, IKM)
PRK = HMAC-SHA-256(salt, IKM)
# HKDF-Expand(PRK, cek_info, L_cek=16)
cek_info = "Content-Encoding: aes128gcm" || 0x00
CEK = HMAC-SHA-256(PRK, cek_info || 0x01)[0..15]
# HKDF-Expand(PRK, nonce_info, L_nonce=12)
nonce_info = "Content-Encoding: nonce" || 0x00
NONCE = HMAC-SHA-256(PRK, nonce_info || 0x01)[0..11]
Note that this omits the exclusive-OR of the final nonce with the record sequence number, since push messages contain only a single record (see Section 4) and the sequence number of the first record is zero.
プッシュメッセージには1つのレコードのみが含まれ（セクション4を参照）、最初のレコードのシーケンス番号はゼロであるため、これは最後のナンスとレコードシーケンス番号の排他的ORを省略していることに注意してください。
An application server MUST encrypt a push message with a single record. This allows for a minimal receiver implementation that handles a single record. An application server MUST set the "rs" parameter in the "aes128gcm" content coding header to a size that is greater than the sum of the lengths of the plaintext, the padding delimiter (1 octet), any padding, and the authentication tag (16 octets).
アプリケーションサーバーは、単一のレコードでプッシュメッセージを暗号化する必要があります。これにより、単一のレコードを処理する最小限のレシーバー実装が可能になります。アプリケーションサーバーは、「aes128gcm」コンテンツコーディングヘッダーの「rs」パラメーターを、平文の長さ、パディング区切り文字（1オクテット）、パディング、および認証タグ（ 16オクテット）。
A push message MUST include the application server ECDH public key in the "keyid" parameter of the encrypted content coding header. The uncompressed point form defined in [X9.62] (that is, a 65-octet sequence that starts with a 0x04 octet) forms the entirety of the "keyid". Note that this means that the "keyid" parameter will not be valid UTF-8 as recommended in [RFC8188].
プッシュメッセージは、暗号化されたコンテンツコーディングヘッダーの「keyid」パラメーターにアプリケーションサーバーECDH公開鍵を含める必要があります。 [X9.62]で定義された非圧縮ポイント形式（つまり、0x04オクテットで始まる65オクテットシーケンス）が「キーID」全体を形成します。これは、[RFC8188]で推奨されているように、「keyid」パラメータが有効なUTF-8ではないことに注意してください。
A push service is not required to support more than 4096 octets of payload body (see Section 7.2 of [RFC8030]). Absent header (86 octets), padding (minimum 1 octet), and expansion for AEAD_AES_128_GCM (16 octets), this equates to, at most, 3993 octets of plaintext.
4096オクテットを超えるペイロード本体をサポートするためにプッシュサービスは必要ありません（[RFC8030]のセクション7.2を参照）。ヘッダー（86オクテット）、パディング（最小1オクテット）、およびAEAD_AES_128_GCM（16オクテット）の拡張がない場合、これは最大で3993オクテットの平文に相当します。
An application server MUST NOT use other content encodings for push messages. In particular, content encodings that compress could result in leaking of push message contents. The Content-Encoding header field therefore has exactly one value, which is "aes128gcm". Multiple "aes128gcm" values are not permitted.
アプリケーションサーバーは、プッシュメッセージに他のコンテンツエンコーディングを使用してはなりません（MUST NOT）。特に、圧縮するコンテンツエンコーディングにより、プッシュメッセージのコンテンツが漏洩する可能性があります。したがって、Content-Encodingヘッダーフィールドには、「aes128gcm」という1つの値しかありません。複数の「aes128gcm」値は許可されていません。
A user agent is not required to support multiple records. A user agent MAY ignore the "rs" parameter. If a record size is unchecked, decryption will fail with high probability for all valid cases. The padding delimiter octet MUST be checked; values other than 0x02 MUST cause the message to be discarded.
ユーザーエージェントは、複数のレコードをサポートする必要はありません。ユーザーエージェントは、「rs」パラメーターを無視してもよい（MAY）。レコードサイズがチェックされていない場合、すべての有効なケースで高い確率で復号化が失敗します。パディング区切り文字のオクテットをチェックする必要があります。 0x02以外の値では、メッセージが破棄される必要があります。
The following example shows a push message being sent to a push service.
次の例は、プッシュサービスに送信されるプッシュメッセージを示しています。
POST /push/JzLQ3raZJfFBR0aqvOMsLrt54w4rJUsV HTTP/1.1
Host: push.example.net
TTL: 10
Content-Length: 145
Content-Encoding: aes128gcm
DGv6ra1nlYgDCS1FRnbzlwAAEABBBP4z9KsN6nGRTbVYI_c7VJSPQTBtkgcy27ml mlMoZIIgDll6e3vCYLocInmYWAmS6TlzAC8wEqKK6PBru3jl7A_yl95bQpu6cVPT pK4Mqgkf1CXztLVBSt2Ks3oZwbuwXPXLWyouBWLVWGNWQexSgSxsj_Qulcy4a-fN
DGv6ra1nlYgDCS1FRnbzlwAAEABBBP4z9KsN6nGRTbVYI_c7VJSPQTBtkgcy27ml mlMoZIIgDll6e3vCYLocInmYWAmS6TlzAC8wEqKK6PBru3jl7A_yl95bQpu6cVPT pK4Mqgkf1CXztLVBSt2Ks3oZwbuwXPXLWyouBWLVWGNWQexSgSxsj_Qulcy4a-FN
This example shows the ASCII-encoded string, "When I grow up, I want to be a watermelon". The content body is shown here with line wrapping and URL-safe base64url [RFC4648] encoding to meet presentation constraints.
この例は、ASCIIでエンコードされた文字列「大人になったらスイカになりたい」を示しています。コンテンツの本文は、表示の制約を満たすために、行の折り返しとURLセーフのbase64url [RFC4648]エンコーディングでここに示されています。
The keys used are shown below using the uncompressed form [X9.62] encoded using base64url.
使用されるキーは、base64urlを使用してエンコードされた非圧縮形式[X9.62]を使用して以下に示されています。
Authentication Secret: BTBZMqHH6r4Tts7J_aSIgg
Receiver:
private key: q1dXpw3UpT5VOmu_cf_v6ih07Aems3njxI-JWgLcM94
public key: BCVxsr7N_eNgVRqvHtD0zTZsEc6-VV-JvLexhqUzORcx
aOzi6-AYWXvTBHm4bjyPjs7Vd8pZGH6SRpkNtoIAiw4
Sender:
private key: yfWPiYE-n46HLnH0KqZOF1fJJU3MYrct3AELtAQ-oRw
public key: BP4z9KsN6nGRTbVYI_c7VJSPQTBtkgcy27mlmlMoZIIg
Dll6e3vCYLocInmYWAmS6TlzAC8wEqKK6PBru3jl7A8
Intermediate values for this example are included in Appendix A.
この例の中間値は、付録Aに含まれています。
This document does not require any IANA actions.
このドキュメントでは、IANAアクションは必要ありません。
The privacy and security considerations of [RFC8030] all apply to the use of this mechanism.
[RFC8030]のプライバシーとセキュリティに関する考慮事項はすべて、このメカニズムの使用に適用されます。
The Security Considerations section of [RFC8188] describes the limitations of the content encoding. In particular, no HTTP header fields are protected by the content encoding scheme. A user agent MUST consider HTTP header fields to have come from the push service.
[RFC8188]のセキュリティに関する考慮事項のセクションでは、コンテンツエンコーディングの制限について説明しています。特に、HTTPヘッダーフィールドはコンテンツエンコーディングスキームによって保護されません。ユーザーエージェントは、HTTPヘッダーフィールドがプッシュサービスからのものであると見なす必要があります。
Though header fields might be necessary for processing an HTTP response correctly, they are not needed for correct operation of the protocol. An application on the user agent that uses information from header fields to alter their processing of a push message is exposed to a risk of attack by the push service.
ヘッダーフィールドはHTTP応答を正しく処理するために必要な場合がありますが、プロトコルの正しい操作には必要ありません。ヘッダーフィールドの情報を使用してプッシュメッセージの処理を変更するユーザーエージェント上のアプリケーションは、プッシュサービスによる攻撃のリスクにさらされます。
The timing and length of communication cannot be hidden from the push service. While an outside observer might see individual messages intermixed with each other, the push service will see which application server is talking to which user agent and the subscription that is used. Additionally, the length of messages could be revealed unless the padding provided by the content encoding scheme is used to obscure length.
通信のタイミングと長さをプッシュサービスから隠すことはできません。外部のオブザーバーは、個々のメッセージが互いに混ざり合っているのを見る可能性がありますが、プッシュサービスは、どのアプリケーションサーバーがどのユーザーエージェントと通信しているか、使用されているサブスクリプションを確認できます。さらに、コンテンツエンコーディングスキームによって提供されるパディングを使用して長さを不明瞭にしない限り、メッセージの長さが明らかになる可能性があります。
The user agent and application MUST verify that the public key they receive is on the P-256 curve. Failure to validate a public key can allow an attacker to extract a private key. The appropriate validation procedures are defined in Section 4.3.7 of [X9.62] and, alternatively, in Section 5.6.2.3 of [KEYAGREEMENT]. This process consists of three steps:
ユーザーエージェントとアプリケーションは、受け取った公開鍵がP-256曲線上にあることを確認する必要があります。公開鍵の検証に失敗すると、攻撃者が秘密鍵を抽出する可能性があります。適切な検証手順は、[X9.62]のセクション4.3.7、または[KEYAGREEMENT]のセクション5.6.2.3で定義されています。このプロセスは、3つのステップで構成されています。
1. Verify that Y is not the point at infinity (O),
1. Yが無限遠点（O）ではないことを確認します。
2. Verify that for Y = (x, y), both integers are in the correct interval,
2. Y =（x、y）の場合、両方の整数が正しい間隔にあることを確認します。
3. Ensure that (x, y) is a correct solution to the elliptic curve equation.
3. （x、y）が楕円曲線方程式の正しい解であることを確認してください。
For these curves, implementers do not need to verify membership in the correct subgroup.
これらの曲線の場合、実装者は正しいサブグループのメンバーシップを確認する必要はありません。
In the event that this encryption scheme would need to be replaced, a new content coding scheme could be defined. In order to manage progressive deployment of the new scheme, the user agent can expose information on the content coding schemes that it supports. The "supportedContentEncodings" parameter of the Push API [API] is an example of how this might be done.
この暗号化スキームを置き換える必要がある場合は、新しいコンテンツコーディングスキームを定義できます。新しいスキームの漸進的な展開を管理するために、ユーザーエージェントは、サポートするコンテンツコーディングスキームに関する情報を公開できます。プッシュAPI [API]の "supportedContentEncodings"パラメータは、これを行う方法の例です。
[ECDH] SECG, "SEC 1: Elliptic Curve Cryptography", Version 2.0, May 2009, <http://www.secg.org/>.
[ECDH] SECG、「SEC 1：Elliptic Curve Cryptography」、バージョン2.0、2009年5月、<http://www.secg.org/>。
[FIPS180-4] National Institute of Standards and Technology (NIST), "Secure Hash Standard (SHS)", FIPS PUB 180-4, DOI 10.6028/NIST.FIPS.180-4, August 2015.
[FIPS180-4]米国国立標準技術研究所（NIST）、「Secure Hash Standard（SHS）」、FIPS PUB 180-4、DOI 10.6028 / NIST.FIPS.180-4、2015年8月。
[FIPS186] National Institute of Standards and Technology (NIST), "Digital Signature Standard (DSS)", FIPS PUB 186-4, DOI 10.6028/NIST.FIPS.186-4, July 2013.
[FIPS186]米国国立標準技術研究所（NIST）、「デジタル署名標準（DSS）」、FIPS PUB 186-4、DOI 10.6028 / NIST.FIPS.186-4、2013年7月。
[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>。
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <https://www.rfc-editor.org/info/rfc4086>.
[RFC4086] Eastlake 3rd、D.、Schiller、J.、and S. Crocker、 "Randomness Requirements for Security"、BCP 106、RFC 4086、DOI 10.17487 / RFC4086、June 2005、<https：//www.rfc-editor .org / info / rfc4086>。
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, <https://www.rfc-editor.org/info/rfc5869>.
[RFC5869] Krawczyk、H。およびP. Eronen、「HMACベースの抽出および拡張キー導出関数（HKDF）」、RFC 5869、DOI 10.17487 / RFC5869、2010年5月、<https：//www.rfc-editor .org / info / rfc5869>。
[RFC8030] Thomson, M., Damaggio, E., and B. Raymor, Ed., "Generic Event Delivery Using HTTP Push", RFC 8030, DOI 10.17487/RFC8030, December 2016, <https://www.rfc-editor.org/info/rfc8030>.
[RFC8030] Thomson、M.、Damaggio、E。、およびB. Raymor、編、「HTTPプッシュを使用した一般的なイベント配信」、RFC 8030、DOI 10.17487 / RFC8030、2016年12月、<https：//www.rfc- editor.org/info/rfc8030>。
[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>。
[RFC8188] Thomson, M., "Encrypted Content-Encoding for HTTP", RFC 8188, DOI 10.17487/RFC8188, June 2017, <https://www.rfc-editor.org/info/rfc8188>.
[RFC8188] Thomson、M。、「HTTPの暗号化されたコンテンツエンコーディング」、RFC 8188、DOI 10.17487 / RFC8188、2017年6月、<https://www.rfc-editor.org/info/rfc8188>。
[X9.62] ANSI, "Public Key Cryptography for the Financial Services Industry: the Elliptic Curve Digital Signature Algorithm (ECDSA)", ANSI X9.62, 2005.
[X9.62] ANSI、「金融サービス業界の公開鍵暗号化：楕円曲線デジタル署名アルゴリズム（ECDSA）」、ANSI X9.62、2005年。
[API] Beverloo, P., Thomson, M., van Ouwerkerk, M., Sullivan, B., and E. Fullea, "Push API", October 2017, <https://www.w3.org/TR/push-api/>.
[API] Beverloo、P.、Thomson、M.、van Ouwerkerk、M.、Sullivan、B。、およびE. Fullea、「Push API」、2017年10月、<https://www.w3.org/TR/ push-api />。
[KEYAGREEMENT] Barker, E., Chen, L., Roginsky, A., and M. Smid, "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography", NIST Special Publication 800-56A, Revision 2, DOI 10.6028/NIST.SP.800-56Ar2, May 2013.
[KEYAGREEMENT] Barker、E.、Chen、L.、Roginsky、A。、およびM. Smid、「離散対数暗号化を使用したペアワイズキー確立スキームの推奨」、NIST Special Publication 800-56A、Revision 2、DOI 10.6028 /NIST.SP.800-56Ar2、2013年5月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <https://www.rfc-editor.org/info/rfc2818>.
[RFC2818] Rescorla、E。、「HTTP Over TLS」、RFC 2818、DOI 10.17487 / RFC2818、2000年5月、<https://www.rfc-editor.org/info/rfc2818>。
[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。、「The Base16、Base32、およびBase64データエンコーディング」、RFC 4648、DOI 10.17487 / RFC4648、2006年10月、<https://www.rfc-editor.org/info/rfc4648>。
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>.
[RFC7230]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Message Syntax and Routing」、RFC 7230、DOI 10.17487 / RFC7230、2014年6月、<https://www.rfc-editor.org/info/ rfc7230>。
The intermediate values calculated for the example in Section 5 are shown here. The base64url values in these examples include whitespace that can be removed.
セクション5の例で計算された中間値を以下に示します。これらの例のbase64url値には、削除可能な空白が含まれています。
The following are inputs to the calculation:
以下は、計算への入力です。
Plaintext: V2hlbiBJIGdyb3cgdXAsIEkgd2FudCB0byBiZSBhIHdhdGVybWVsb24
Application server public key (as_public):
BP4z9KsN6nGRTbVYI_c7VJSPQTBtkgcy27mlmlMoZIIg
Dll6e3vCYLocInmYWAmS6TlzAC8wEqKK6PBru3jl7A8
Application server private key (as_private): yfWPiYE-n46HLnH0KqZOF1fJJU3MYrct3AELtAQ-oRw
アプリケーションサーバーの秘密キー（as_private）：yfWPiYE-n46HLnH0KqZOF1fJJU3MYrct3AELtAQ-oRw
User agent public key (ua_public): BCVxsr7N_eNgVRqvHtD0zTZsEc6-VV-
JvLexhqUzORcx aOzi6-AYWXvTBHm4bjyPjs7Vd8pZGH6SRpkNtoIAiw4
User agent private key (ua_private): q1dXpw3UpT5VOmu_cf_v6ih07Aems3njxI-JWgLcM94
ユーザーエージェントの秘密キー（ua_private）：q1dXpw3UpT5VOmu_cf_v6ih07Aems3njxI-JWgLcM94
Salt: DGv6ra1nlYgDCS1FRnbzlw
塩：DGv6ra1nlYgDCS1FRnbzlw
Authentication secret (auth_secret): BTBZMqHH6r4Tts7J_aSIgg
認証シークレット（auth_secret）：BTBZMqHH6r4Tts7J_aSIgg
Note that knowledge of just one of the private keys is necessary. The application server randomly generates the salt value, whereas salt is input to the receiver.
秘密鍵の1つだけの知識が必要であることに注意してください。アプリケーションサーバーはランダムにソルト値を生成しますが、ソルトはレシーバーに入力されます。
This produces the following intermediate values:
これにより、次の中間値が生成されます。
Shared ECDH secret (ecdh_secret):
kyrL1jIIOHEzg3sM2ZWRHDRB62YACZhhSlknJ672kSs
Pseudorandom key (PRK) for key combining (PRK_key):
Snr3JMxaHVDXHWJn5wdC52WjpCtd2EIEGBykDcZW32k
Info for key combining (key_info): V2ViUHVzaDogaW5mbwAEJXGyvs3942BVG q8e0PTNNmwR zr5VX4m8t7GGpTM5FzFo7OLr4BhZe9MEebhuPI-OztV3 ylkYfpJGmQ22ggCLDgT-M_SrDepxkU21WCP3O1SUj0Ew bZIHMtu5pZpTKGSCIA5Zent7wmC6HCJ5mFgJkuk5cwAv MBKiiujwa7t45ewP
（key_info）を組み合わせたキーの情報：V2ViUHVzaDogaW5mbwAEJXGyvs3942BVG q8e0PTNNmwR zr5VX4m8t7GGpTM5FzFo7OLr4BhZe9MEebhuPI-OztV3 ylkYfpJGmQ22ggCLDgT-M_SrDepxkU21WCP3O1SUj0Ew bZIHMtu5pZpTKGSCIA5Zent7wmC6HCJ5mFgJkuk5cwAv MBKiiujwa7t45ewP
Input keying material for content encryption key derivation (IKM):
S4lYMb_L0FxCeq0WhDx813KgSYqU26kOyzWUdsXYyrg
PRK for content encryption (PRK):
09_eUZGrsvxChDCGRCdkLiDXrReGOEVeSCdCcPBSJSc
Info for content encryption key derivation (cek_info):
Q29udGVudC1FbmNvZGluZzogYWVzMTI4Z2NtAA
Content encryption key (CEK): oIhVW04MRdy2XN9CiKLxTg
コンテンツ暗号化キー（CEK）：oIhVW04MRdy2XN9CiKLxTg
Info for content encryption nonce derivation (nonce_info):
Q29udGVudC1FbmNvZGluZzogbm9uY2UA
Nonce (NONCE): 4h_95klXJ5E_qnoN
ノンス（NONCE）：4h_95klXJ5E_qnoN
The salt, record size of 4096, and application server public key produce an 86-octet header of:
ソルト、レコードサイズ4096、およびアプリケーションサーバーの公開鍵は、次の86オクテットヘッダーを生成します。
DGv6ra1nlYgDCS1FRnbzlwAAEABBBP4z 9KsN6nGRTbVYI_c7VJSPQTBtkgcy27ml mlMoZIIgDll6e3vCYLocInmYWAmS6Tlz AC8wEqKK6PBru3jl7A8
DGv6ra1nlYgDCS1FRnbzlwAAEABBBP4z 9KsN6nGRTbVYI_c7VJSPQTBtkgcy27ml mlMoZIIgDll6e3vCYLocInmYWAmS6Tlz AC8wEqKK6PBru3jl7A8
The push message plaintext has the padding delimiter octet (0x02) appended to produce:
プッシュメッセージのプレーンテキストには、以下を生成するためにパディング区切り文字オクテット（0x02）が追加されています。
V2hlbiBJIGdyb3cgdXAsIEkgd2FudCB0 byBiZSBhIHdhdGVybWVsb24C
V2hlbiBJIGdyb3cgdXAsIEkgd2FudCB0 byBiZSBhIHdhdGVybWVsb24C
The plaintext is then encrypted with AES-GCM, which emits ciphertext of:
次に、平文はAES-GCMで暗号化され、次の暗号文が送信されます。
8pfeW0KbunFT06SuDKoJH9Ql87S1QUrd irN6GcG7sFz1y1sqLgVi1VhjVkHsUoEs bI_0LpXMuGvnzQ
8pfeW0KbunFT06SuDKoJH9Ql87S1QUrd irN6GcG7sFz1y1sqLgVi1VhjVkHsUoEs bI_0LpXMuGvnzQ
The header and ciphertext are concatenated and produce the result shown in Section 5.
ヘッダーと暗号文が連結され、セクション5に示す結果が生成されます。
Author's Address
著者のアドレス
Martin Thomson Mozilla
マーティン・トムソン・モジラ
Email: martin.thomson@gmail.com