Internet Engineering Task Force (IETF) M. Thomson
Request for Comments: 8291 Mozilla
Category: Standards Track November 2017
ISSN: 2070-1721
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.
这是一份互联网标准跟踪文件。
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）的产品。它代表了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.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. 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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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]是必要的中间协议。来自应用服务器的消息通过推送服务传递给用户代理（UA），如图1所示。
+-------+ +--------------+ +-------------+
| UA | | Push Service | | Application |
+-------+ +--------------+ +-------------+
| | |
| Setup | |
|<====================>| |
| Provide Subscription |
|-------------------------------------------->|
| | |
: : :
| | Push Message |
| Push Message |<---------------------|
|<---------------------| |
| | |
+-------+ +--------------+ +-------------+
| 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.
实现推送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.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照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密钥对和随机salt。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.
推送消息的内容使用内容加密密钥和nonce进行加密或解密。这些值是通过将“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:
推送消息加密分为四个阶段：
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]中的过程导出内容加密密钥和nonce。
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].
对于用户代理为应用程序生成的每个新订阅，它还生成一个P-256[FIPS186]密钥对，用于ECDH[ECDH]。
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]生成。
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
IKM：使用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:
信息：ASCII编码字符串“WebPush:info”（此字符串不以NUL结尾）、零八位字节、用户代理ECDH公钥和应用程序服务器ECDH公钥的串联（两个ECDH公钥均采用[X9.62]中定义的未压缩点形式）。即：
key_info = "WebPush: info" || 0x00 || ua_public || as_public
key_info=“WebPush:info”| | 0x00 | | ua| U public | as|U 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:
这将导致使用以下序列生成最终内容加密密钥和nonce，该序列在伪码中显示，HKDF使用HMAC和SHA-256扩展为单独的离散步骤：
-- For a user agent:
ecdh_secret = ECDH(ua_private, as_public)
auth_secret = random(16)
salt = <from content coding header>
-- 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 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)
## 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]
## 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.
注意，由于推送消息只包含一条记录（参见第4节），且第一条记录的序列号为零，因此这省略了记录序列号的最终nonce的异或。
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个八位字节序列）构成了整个“keyid”。注意，这意味着“keyid”参数将不是[RFC8188]中建议的有效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节）。如果没有AEAD_AES_128_GCM（16个八位字节）的标头（86个八位字节）、填充（至少1个八位字节）和扩展，则最多相当于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.
应用程序服务器不得对推送消息使用其他内容编码。特别是，压缩的内容编码可能导致推送消息内容泄漏。因此，内容编码头字段只有一个值，即“aes128gcm”。不允许有多个“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”参数。如果未选中记录大小，则对于所有有效案例，解密都将很有可能失败。必须检查填充分隔符八位字节；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
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 MlMoziigDLL6WEQKK6PBRU3JL7a_yl95bQpu6cVPT PK4MQGKF1CxZTLVBST2KS3OZWBWWYOUBWGNWQEXSGSJ_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
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节规定了适当的验证程序。该过程包括三个步骤：
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，“第1节：椭圆曲线密码术”，版本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），“安全哈希标准（SHS）”，FIPS PUB 180-4，DOI 10.6028/NIST.FIPS.180-42015年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-42013年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.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 4086，DOI 10.17487/RFC4086，2005年6月<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，Ed.，“使用HTTP推送的通用事件交付”，RFC 8030，DOI 10.17487/RFC80302016年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，“推送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特别出版物800-56A，第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.，“TLS上的HTTP”，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.，“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]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：消息语法和路由”，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
Plaintext: V2hlbiBJIGdyb3cgdXAsIEkgd2FudCB0byBiZSBhIHdhdGVybWVsb24
Application server public key (as_public):
BP4z9KsN6nGRTbVYI_c7VJSPQTBtkgcy27mlmlMoZIIg
Dll6e3vCYLocInmYWAmS6TlzAC8wEqKK6PBru3jl7A8
Application server public key (as_public):
BP4z9KsN6nGRTbVYI_c7VJSPQTBtkgcy27mlmlMoZIIg
Dll6e3vCYLocInmYWAmS6TlzAC8wEqKK6PBru3jl7A8
Application server private key (as_private): yfWPiYE-n46HLnH0KqZOF1fJJU3MYrct3AELtAQ-oRw
应用程序服务器私钥（as_private）：yfWPiYE-N46HLNH0KQZOF1FJJJU3MYRCT3AELTAQ-oRw
User agent public key (ua_public): BCVxsr7N_eNgVRqvHtD0zTZsEc6-VV-
JvLexhqUzORcx aOzi6-AYWXvTBHm4bjyPjs7Vd8pZGH6SRpkNtoIAiw4
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.
请注意，只需要了解其中一个私钥。应用服务器随机生成salt值，而salt是输入到接收方的。
This produces the following intermediate values:
这将产生以下中间值：
Shared ECDH secret (ecdh_secret):
kyrL1jIIOHEzg3sM2ZWRHDRB62YACZhhSlknJ672kSs
Shared ECDH secret (ecdh_secret):
kyrL1jIIOHEzg3sM2ZWRHDRB62YACZhhSlknJ672kSs
Pseudorandom key (PRK) for key combining (PRK_key):
Snr3JMxaHVDXHWJn5wdC52WjpCtd2EIEGBykDcZW32k
Pseudorandom key (PRK) for key combining (PRK_key):
Snr3JMxaHVDXHWJn5wdC52WjpCtd2EIEGBykDcZW32k
Info for key combining (key_info): V2ViUHVzaDogaW5mbwAEJXGyvs3942BVG q8e0PTNNmwR zr5VX4m8t7GGpTM5FzFo7OLr4BhZe9MEebhuPI-OztV3 ylkYfpJGmQ22ggCLDgT-M_SrDepxkU21WCP3O1SUj0Ew bZIHMtu5pZpTKGSCIA5Zent7wmC6HCJ5mFgJkuk5cwAv MBKiiujwa7t45ewP
密钥组合信息（密钥信息）：V2ViUHVzaDogaW5mbwAEJXGyvs3942BVG q8e0PTNNmwR zr5VX4m8t7GGpTM5FzFo7OLr4BhZe9MEebhuPI-OztV3 YLKYFPJGMQ2GGCLDGT-M SrDepxkU21WCP3O1SUj0Ew BZIMTU5PZPTKSCIA5ZENT7WMC6HCJ5MFGJKUK5WAV MBKIUK7T45EWP
Input keying material for content encryption key derivation (IKM):
S4lYMb_L0FxCeq0WhDx813KgSYqU26kOyzWUdsXYyrg
Input keying material for content encryption key derivation (IKM):
S4lYMb_L0FxCeq0WhDx813KgSYqU26kOyzWUdsXYyrg
PRK for content encryption (PRK):
09_eUZGrsvxChDCGRCdkLiDXrReGOEVeSCdCcPBSJSc
PRK for content encryption (PRK):
09_eUZGrsvxChDCGRCdkLiDXrReGOEVeSCdCcPBSJSc
Info for content encryption key derivation (cek_info):
Q29udGVudC1FbmNvZGluZzogYWVzMTI4Z2NtAA
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
Info for content encryption nonce derivation (nonce_info):
Q29udGVudC1FbmNvZGluZzogbm9uY2UA
Nonce (NONCE): 4h_95klXJ5E_qnoN
Nonce（Nonce）：4h_95klXJ5E_qnoN
The salt, record size of 4096, and application server public key produce an 86-octet header of:
salt、4096的记录大小和应用程序服务器公钥生成86个八位字节的头：
DGv6ra1nlYgDCS1FRnbzlwAAEABBBP4z 9KsN6nGRTbVYI_c7VJSPQTBtkgcy27ml mlMoZIIgDll6e3vCYLocInmYWAmS6Tlz AC8wEqKK6PBru3jl7A8
DGV6RA1NLYGDCS1FRNBZLWAAEABBP4Z 9KsN6nGRTbVYI_c7VJSPQTBtkgcy27ml MlMoziigDLL6E3VcylocinmyWAMS6LZ AC8wEqKK6PBru3jl7A8
The push message plaintext has the padding delimiter octet (0x02) appended to produce:
推送消息明文附加了填充分隔符八位字节（0x02），以生成：
V2hlbiBJIGdyb3cgdXAsIEkgd2FudCB0 byBiZSBhIHdhdGVybWVsb24C
V2hlbiBJIGdyb3cgdXAsIEkgd2FudCB0 BYZSBHIHDGVYBWVSB24C
The plaintext is then encrypted with AES-GCM, which emits ciphertext of:
然后使用AES-GCM对明文进行加密，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
Email: martin.thomson@gmail.com