Internet Engineering Task Force (IETF) M. Thomson
Request for Comments: 8188 Mozilla
Category: Standards Track June 2017
ISSN: 2070-1721
Internet Engineering Task Force (IETF) M. Thomson
Request for Comments: 8188 Mozilla
Category: Standards Track June 2017
ISSN: 2070-1721
Encrypted Content-Encoding for HTTP
HTTP的加密内容编码
Abstract
摘要
This memo introduces a content coding for HTTP that allows message payloads to be encrypted.
此备忘录介绍了HTTP的内容编码，允许对消息有效负载进行加密。
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 http://www.rfc-editor.org/info/rfc8188.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8188.
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 (http://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文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. The "aes128gcm" HTTP Content Coding . . . . . . . . . . . . . 3
2.1. Encryption Content-Coding Header . . . . . . . . . . . . 5
2.2. Content-Encryption Key Derivation . . . . . . . . . . . . 6
2.3. Nonce Derivation . . . . . . . . . . . . . . . . . . . . 6
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Encryption of a Response . . . . . . . . . . . . . . . . 7
3.2. Encryption with Multiple Records . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
4.1. Automatic Decryption . . . . . . . . . . . . . . . . . . 9
4.2. Message Truncation . . . . . . . . . . . . . . . . . . . 9
4.3. Key and Nonce Reuse . . . . . . . . . . . . . . . . . . . 9
4.4. Data Encryption Limits . . . . . . . . . . . . . . . . . 10
4.5. Content Integrity . . . . . . . . . . . . . . . . . . . . 10
4.6. Leaking Information in Header Fields . . . . . . . . . . 10
4.7. Poisoning Storage . . . . . . . . . . . . . . . . . . . . 11
4.8. Sizing and Timing Attacks . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
5.1. The "aes128gcm" HTTP Content Coding . . . . . . . . . . . 12
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Normative References . . . . . . . . . . . . . . . . . . 12
6.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. JWE Mapping . . . . . . . . . . . . . . . . . . . . 15
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. The "aes128gcm" HTTP Content Coding . . . . . . . . . . . . . 3
2.1. Encryption Content-Coding Header . . . . . . . . . . . . 5
2.2. Content-Encryption Key Derivation . . . . . . . . . . . . 6
2.3. Nonce Derivation . . . . . . . . . . . . . . . . . . . . 6
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Encryption of a Response . . . . . . . . . . . . . . . . 7
3.2. Encryption with Multiple Records . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
4.1. Automatic Decryption . . . . . . . . . . . . . . . . . . 9
4.2. Message Truncation . . . . . . . . . . . . . . . . . . . 9
4.3. Key and Nonce Reuse . . . . . . . . . . . . . . . . . . . 9
4.4. Data Encryption Limits . . . . . . . . . . . . . . . . . 10
4.5. Content Integrity . . . . . . . . . . . . . . . . . . . . 10
4.6. Leaking Information in Header Fields . . . . . . . . . . 10
4.7. Poisoning Storage . . . . . . . . . . . . . . . . . . . . 11
4.8. Sizing and Timing Attacks . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
5.1. The "aes128gcm" HTTP Content Coding . . . . . . . . . . . 12
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Normative References . . . . . . . . . . . . . . . . . . 12
6.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. JWE Mapping . . . . . . . . . . . . . . . . . . . . 15
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
It is sometimes desirable to encrypt the contents of an HTTP message (request or response) so that when the payload is stored (e.g., with an HTTP PUT), only someone with the appropriate key can read it.
有时需要加密HTTP消息（请求或响应）的内容，以便在存储有效负载时（例如，使用HTTP PUT），只有具有适当密钥的人才能读取有效负载。
For example, it might be necessary to store a file on a server without exposing its contents to that server. Furthermore, that same file could be replicated to other servers (to make it more resistant to server or network failure), downloaded by clients (to make it available offline), etc., without exposing its contents.
例如，可能需要在服务器上存储文件，而不向该服务器公开其内容。此外，相同的文件可以复制到其他服务器（使其更能抵抗服务器或网络故障）、由客户端下载（使其脱机可用）等，而不公开其内容。
These uses are not met by the use of Transport Layer Security (TLS) [RFC5246], since it only encrypts the channel between the client and server.
传输层安全性（TLS）[RFC5246]的使用不能满足这些用途，因为它只加密客户端和服务器之间的通道。
This document specifies a content coding (see Section 3.1.2 of [RFC7231]) for HTTP to serve these and other use cases.
本文件规定了HTTP的内容编码（见[RFC7231]第3.1.2节），以服务于这些和其他用例。
This content coding is not a direct adaptation of message-based encryption formats -- such as those that are described by [RFC4880], [RFC5652], [RFC7516], and [XMLENC]. Those formats are not suited to stream processing, which is necessary for HTTP. The format described here follows more closely to the lower-level constructs described in [RFC5116].
这种内容编码不是对基于消息的加密格式的直接改编，例如[RFC4880]、[RFC5652]、[RFC7516]和[XMLENC]中描述的加密格式。这些格式不适合于流处理，这是HTTP所必需的。这里描述的格式更接近于[RFC5116]中描述的低级构造。
To the extent that message-based encryption formats use the same primitives, the format can be considered to be a sequence of encrypted messages with a particular profile. For instance, Appendix A explains how the format is congruent with a sequence of JSON Web Encryption [RFC7516] values with a fixed header.
如果基于消息的加密格式使用相同的原语，则可以将该格式视为具有特定概要文件的加密消息序列。例如，附录A解释了该格式如何与JSON Web加密[RFC7516]值序列一致，并带有固定的头。
This mechanism is likely only a small part of a larger design that uses content encryption. How clients and servers acquire and identify keys will depend on the use case. In particular, a key management system is not described.
这种机制可能只是使用内容加密的大型设计的一小部分。客户端和服务器如何获取和识别密钥将取决于用例。特别地，未描述密钥管理系统。
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]所述进行解释。
The "aes128gcm" HTTP content coding indicates that a payload has been encrypted using Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) as identified as AEAD_AES_128_GCM in [RFC5116], Section 5.1. The AEAD_AES_128_GCM algorithm uses a 128-bit content-encryption key.
“aes128gcm”HTTP内容编码表示已使用Galois/计数器模式（GCM）中的高级加密标准（AES）对有效负载进行了加密，如[RFC5116]第5.1节中所述的AEAD_AES_128_GCM。AEAD_AES_128_GCM算法使用128位内容加密密钥。
Using this content coding requires knowledge of a key. How this key is acquired is not defined in this document.
使用此内容编码需要了解密钥。本文档中未定义如何获取此密钥。
The "aes128gcm" content coding uses a single fixed set of encryption primitives. Cipher agility is achieved by defining a new content-coding scheme. This ensures that only the HTTP Accept-Encoding header field is necessary to negotiate the use of encryption.
“aes128gcm”内容编码使用一组固定的加密原语。通过定义新的内容编码方案，实现了密码灵活性。这可以确保协商加密的使用只需要HTTP Accept Encoding标头字段。
The "aes128gcm" content coding uses a fixed record size. The final encoding consists of a header (see Section 2.1) and zero or more fixed-size encrypted records; the final record can be smaller than the record size.
“aes128gcm”内容编码使用固定的记录大小。最终编码包括一个标题（见第2.1节）和零个或多个固定大小的加密记录；最终记录可以小于记录大小。
The record size determines the length of each portion of plaintext that is enciphered. The record size ("rs") is included in the content-coding header (see Section 2.1).
记录大小决定被加密的明文的每一部分的长度。记录大小（“rs”）包含在内容编码标题中（见第2.1节）。
+-----------+ content
| data | any length up to rs-17 octets
+-----------+
|
v
+-----------+-----+ add a delimiter octet (0x01 or 0x02)
| data | pad | then 0x00-valued octets to rs-16
+-----------+-----+ (or less on the last record)
|
v
+--------------------+ encrypt with AEAD_AES_128_GCM;
| ciphertext | final size is rs;
+--------------------+ the last record can be smaller
+-----------+ content
| data | any length up to rs-17 octets
+-----------+
|
v
+-----------+-----+ add a delimiter octet (0x01 or 0x02)
| data | pad | then 0x00-valued octets to rs-16
+-----------+-----+ (or less on the last record)
|
v
+--------------------+ encrypt with AEAD_AES_128_GCM;
| ciphertext | final size is rs;
+--------------------+ the last record can be smaller
AEAD_AES_128_GCM produces ciphertext 16 octets longer than its input plaintext. Therefore, the unencrypted content of each record is shorter than the record size by 16 octets. Valid records always contain at least a padding delimiter octet and a 16-octet authentication tag.
AEAD_AES_128_GCM产生的密文比其输入明文长16个八位字节。因此，每个记录的未加密内容比记录大小短16个八位字节。有效记录始终至少包含一个填充分隔符八位字节和一个16位八位字节的身份验证标记。
Each record contains a single padding delimiter octet followed by any number of zero octets. The last record uses a padding delimiter octet set to the value 2, all other records have a padding delimiter octet value of 1.
每个记录都包含一个填充分隔符八位字节，后跟任意数量的零八位字节。最后一条记录使用的填充分隔符八位字节设置为值2，所有其他记录的填充分隔符八位字节值为1。
On decryption, the padding delimiter is the last non-zero-valued octet of the record. A decrypter MUST fail if the record contains no non-zero octet. A decrypter MUST fail if the last record contains a padding delimiter with a value other than 2 or if any record other than the last contains a padding delimiter with a value other than 1.
解密时，填充分隔符是记录的最后一个非零值八位字节。如果记录不包含非零八位字节，则解密程序必须失败。如果最后一条记录包含值不是2的填充分隔符，或者如果除最后一条记录以外的任何记录包含值不是1的填充分隔符，则解密程序必须失败。
The nonce for each record is a 96-bit value constructed from the record sequence number and the input-keying material. Nonce derivation is covered in Section 2.3.
每个记录的nonce是由记录序列号和输入键控材料构造的96位值。第2.3节介绍了暂时性衍生。
The additional data passed to each invocation of AEAD_AES_128_GCM is a zero-length octet sequence.
传递给AEAD_AES_128_GCM每次调用的附加数据是一个零长度八位组序列。
A consequence of this record structure is that range requests [RFC7233] and random access to encrypted payload bodies are possible at the granularity of the record size. Partial records at the ends of a range cannot be decrypted. Thus, it is best if range requests start and end on record boundaries. However, note that random access
这种记录结构的结果是，在记录大小的粒度上，范围请求[RFC7233]和对加密有效负载体的随机访问是可能的。无法解密范围末尾的部分记录。因此，范围请求最好在记录边界上开始和结束。但是，请注意，随机访问
to specific parts of encrypted data could be confounded by the presence of padding.
加密数据的特定部分可能会因存在填充而混淆。
Selecting the record size most appropriate for a given situation requires a trade-off. A smaller record size allows decrypted octets to be released more rapidly, which can be appropriate for applications that depend on responsiveness. Smaller records also reduce the additional data required if random access into the ciphertext is needed.
选择最适合给定情况的记录大小需要权衡。较小的记录大小允许更快地释放解密的八位字节，这适用于依赖于响应能力的应用程序。如果需要随机访问密文，较小的记录也会减少所需的额外数据。
Applications that don't depend on streaming, random access, or arbitrary padding can use larger records, or even a single record. A larger record size reduces processing and data overheads.
不依赖流、随机访问或任意填充的应用程序可以使用较大的记录，甚至单个记录。较大的记录大小可减少处理和数据开销。
The content coding uses a header block that includes all parameters needed to decrypt the content (other than the key). The header block is placed in the body of a message ahead of the sequence of records.
内容编码使用包含解密内容（密钥除外）所需的所有参数的头块。头块位于记录序列之前的消息体中。
+-----------+--------+-----------+---------------+
| salt (16) | rs (4) | idlen (1) | keyid (idlen) |
+-----------+--------+-----------+---------------+
+-----------+--------+-----------+---------------+
| salt (16) | rs (4) | idlen (1) | keyid (idlen) |
+-----------+--------+-----------+---------------+
salt: The "salt" parameter comprises the first 16 octets of the "aes128gcm" content-coding header. The same "salt" parameter value MUST NOT be reused for two different payload bodies that have the same input-keying material; generating a random salt for every application of the content coding ensures that content-encryption key reuse is highly unlikely.
salt：“salt”参数包含“aes128gcm”内容编码头的前16个八位字节。对于具有相同输入键控材料的两个不同有效载荷主体，不得重复使用相同的“salt”参数值；为内容编码的每个应用程序生成随机salt可确保内容加密密钥重用的可能性非常小。
rs: The "rs" or record size parameter contains an unsigned 32-bit integer in network byte order that describes the record size in octets. Note that it is, therefore, impossible to exceed the 2^36-31 limit on plaintext input to AEAD_AES_128_GCM. Values smaller than 18 are invalid.
rs：“rs”或记录大小参数包含一个以网络字节顺序表示的无符号32位整数，该整数以八位字节为单位描述记录大小。请注意，因此不可能超过AEAD_AES_128_GCM的明文输入限制2^36-31。小于18的值无效。
idlen: The "idlen" parameter is an unsigned 8-bit integer that defines the length of the "keyid" parameter.
idlen：“idlen”参数是一个无符号8位整数，用于定义“keyid”参数的长度。
keyid: The "keyid" parameter can be used to identify the keying material that is used. This field is the length determined by the "idlen" parameter. Recipients that receive a message are expected to know how to retrieve keys; the "keyid" parameter might be input to that process. A "keyid" parameter SHOULD be a UTF-8-encoded [RFC3629] string, particularly where the identifier might need to be rendered in a textual form.
keyid：“keyid”参数可用于标识所使用的键控材质。此字段是由“idlen”参数确定的长度。接收邮件的收件人应该知道如何检索密钥；“keyid”参数可能是该进程的输入。“keyid”参数应该是UTF-8编码的[RFC3629]字符串，特别是当标识符可能需要以文本形式呈现时。
In order to allow the reuse of keying material for multiple different HTTP messages, a content-encryption key is derived for each message. The content-encryption key is derived from the "salt" parameter using the HMAC-based key derivation function (HKDF) described in [RFC5869] using the SHA-256 hash algorithm [FIPS180-4].
为了允许为多个不同的HTTP消息重用密钥材料，将为每个消息派生一个内容加密密钥。内容加密密钥是使用[RFC5869]中描述的基于HMAC的密钥派生函数（HKDF）并使用SHA-256哈希算法[FIPS180-4]从“salt”参数派生而来的。
The value of the "salt" parameter is the salt input to the HKDF. The keying material identified by the "keyid" parameter is the input-keying material (IKM) to HKDF. Input-keying material is expected to be provided to recipients separately. The extract phase of HKDF, therefore, produces a pseudorandom key (PRK) as follows:
“salt”参数的值是HKDF的salt输入。“keyid”参数标识的键控材料是HKDF的输入键控材料（IKM）。输入键控材料应单独提供给收件人。因此，HKDF的提取阶段产生伪随机密钥（PRK），如下所示：
PRK = HMAC-SHA-256 (salt, IKM)
PRK=HMAC-SHA-256（盐，IKM）
The info parameter to HKDF is set to the ASCII-encoded string "Content-Encoding: aes128gcm" and a single zero octet:
HKDF的info参数设置为ASCII编码字符串“内容编码：aes128gcm”和单个零八位字节：
cek_info = "Content-Encoding: aes128gcm" || 0x00
cek|u info=“内容编码：aes128gcm”|| 0x00
Note(1): Concatenation of octet sequences is represented by the "||" operator.
注（1）：八位元序列的串联由“| |”运算符表示。
Note(2): The strings used here and in Section 2.3 do not include a terminating 0x00 octet, as is used in some programming languages.
注（2）：此处和第2.3节中使用的字符串不包括在某些编程语言中使用的终止0x00八位字节。
AEAD_AES_128_GCM requires a 16-octet (128-bit) content-encryption key (CEK), so the length (L) parameter to HKDF is 16. The second step of HKDF can, therefore, be simplified to the first 16 octets of a single HMAC:
AEAD_AES_128_GCM需要16个八位字节（128位）的内容加密密钥（CEK），因此HKDF的长度（L）参数为16。因此，HKDF的第二步可以简化为单个HMAC的前16个八位字节：
CEK = HMAC-SHA-256(PRK, cek_info || 0x01)
CEK=HMAC-SHA-256（PRK，CEK|U信息| 0x01）
The nonce input to AEAD_AES_128_GCM is constructed for each record. The nonce for each record is a 12-octet (96-bit) value that is derived from the record sequence number, input-keying material, and "salt" parameter.
为每个记录构造AEAD_AES_128_GCM的nonce输入。每个记录的nonce是一个12个八位组（96位）的值，该值是从记录序列号、输入键控材料和“salt”参数派生的。
The input-keying material and "salt" parameter are input to HKDF with different info and length (L) parameters.
输入键控材料和“salt”参数以不同的信息和长度（L）参数输入到HKDF。
The length (L) parameter is 12 octets. The info parameter for the nonce is the ASCII-encoded string "Content-Encoding: nonce", terminated by a single zero octet:
长度（L）参数为12个八位字节。nonce的info参数是ASCII编码的字符串“Content Encoding:nonce”，以一个零八位字节结尾：
nonce_info = "Content-Encoding: nonce" || 0x00
nonce_info=“内容编码：nonce”|| 0x00
The result is combined with the record sequence number -- using exclusive or -- to produce the nonce. The record sequence number (SEQ) is a 96-bit unsigned integer in network byte order that starts at zero.
结果与记录序列号结合（使用异或）生成nonce。记录序列号（SEQ）是一个96位无符号整数，网络字节顺序从零开始。
Thus, the final nonce for each record is a 12-octet value:
因此，每个记录的最终nonce是12个八位组的值：
NONCE = HMAC-SHA-256(PRK, nonce_info || 0x01) XOR SEQ
NONCE=HMAC-SHA-256（PRK，NONCE|u info | 0x01）异或序列
This nonce construction prevents removal or reordering of records.
此nonce结构可防止记录的删除或重新排序。
This section shows a few examples of the encrypted-content coding.
本节展示了一些加密内容编码的示例。
Note: All binary values in the examples in this section use base64 encoding with URL and filename safe alphabet [RFC4648]. This includes the bodies of requests. Whitespace and line wrapping is added to fit formatting constraints.
注意：本节示例中的所有二进制值都使用带URL和文件名安全字母表[RFC4648]的base64编码。这包括请求的主体。添加空白和换行以适应格式限制。
Here, a successful HTTP GET response has been encrypted. This uses a record size of 4096 octets and no padding (just the single-octet padding delimiter), so only a partial record is present. The input-keying material is identified by an empty string (that is, the "keyid" field in the header is zero octets in length).
这里，一个成功的HTTP GET响应已被加密。这将使用4096个八位字节的记录大小，并且没有填充（仅使用单个八位字节填充分隔符），因此仅存在部分记录。输入键控材料由空字符串标识（即，标题中的“keyid”字段长度为零个八位字节）。
The encrypted data in this example is the UTF-8-encoded string "I am the walrus". The input-keying material is the value "yqdlZ-tYemfogSmv7Ws5PQ" (in base64url). The 54-octet content body contains a single record and is shown here using 71 base64url characters for presentation reasons.
本例中的加密数据是UTF-8编码的字符串“我是海象”。输入键控材料是值“yqdlZ-tYemfogSmv7Ws5PQ”（在base64url中）。54个八位字节的内容体包含一条记录，出于表示原因，此处使用71个base64url字符显示。
HTTP/1.1 200 OK Content-Type: application/octet-stream Content-Length: 54 Content-Encoding: aes128gcm
HTTP/1.1 200 OK内容类型：应用程序/八位字节流内容长度：54内容编码：aes128gcm
I1BsxtFttlv3u_Oo94xnmwAAEAAA-NAVub2qFgBEuQKRapoZu-IxkIva3MEB1PD-ly8Thjg
I1BSXFTTLV3U_Oo94xnmwAAEAAA-NABUB2 QFGBEUQKRAPOZU-IxkIva3MEB1PD-ly8Thjg
Note that the media type has been changed to "application/octet-stream" to avoid exposing information about the content. Alternatively (and equivalently), the Content-Type header field can be omitted.
请注意，媒体类型已更改为“应用程序/八位字节流”，以避免暴露有关内容的信息。或者（等效地），可以省略内容类型标题字段。
Intermediate values for this example (all shown using base64url):
此示例的中间值（均使用base64url显示）：
salt (from header) = I1BsxtFttlv3u_Oo94xnmw PRK = zyeH5phsIsgUyd4oiSEIy35x-gIi4aM7y0hCF8mwn9g CEK = _wniytB-ofscZDh4tbSjHw NONCE = Bcs8gkIRKLI8GeI8 unencrypted data = SSBhbSB0aGUgd2FscnVzAg
salt（从标题）=I1BSXTTLV3U_Oo94xnmw PRK=ZYEH5PSGUYD4OISEIY35X-gIi4aM7y0hCF8mwn9g CEK=_wniytB-OFSCSDH4TBSJHW NONCE=Bcs8gkIRKLI8GeI8未加密数据=SSBHBSB0AGUGD2FSNVZAG
This example shows the same message with input-keying material of "BO3ZVPxUlnLORbVGMpbT1Q". In this example, the plaintext is split into records of 25 octets each (that is, the "rs" field in the header is 25). The first record includes one 0x00 padding octet. This means that there are 7 octets of message in the first record and 8 in the second. A key identifier of the UTF-8-encoded string "a1" is also included in the header.
此示例显示了输入键控材料为“BO3ZVPxUlnLORbVGMpbT1Q”的相同消息。在本例中，明文被拆分为25个八位字节的记录（即，报头中的“rs”字段为25）。第一条记录包括一个0x00填充八位字节。这意味着第一条记录中有7个八位字节的消息，第二条记录中有8个八位字节的消息。UTF-8编码字符串“a1”的密钥标识符也包括在报头中。
HTTP/1.1 200 OK Content-Length: 73 Content-Encoding: aes128gcm
HTTP/1.1 200 OK内容长度：73内容编码：aes128gcm
uNCkWiNYzKTnBN9ji3-qWAAAABkCYTHOG8chz_gnvgOqdGYovxyjuqRyJFjEDyoF 1Fvkj6hQPdPHI51OEUKEpgz3SsLWIqS_uA
UNKWINYZKTNBN9JI3-QWAAAABKCYTOG8CHZ_GNVGOQDGYOVXYJJKJJJJFJEDY1FKJ6HQPDPHI51OEUKEPGZ3SLWIQS_uA
This mechanism assumes the presence of a key management framework that is used to manage the distribution of keys between valid senders and receivers. Defining key management is part of composing this mechanism into a larger application, protocol, or framework.
此机制假设存在密钥管理框架，该框架用于管理有效发送方和接收方之间的密钥分发。定义密钥管理是将该机制组合到更大的应用程序、协议或框架中的一部分。
Implementation of cryptography -- and key management in particular -- can be difficult. For instance, implementations need to account for the potential for exposing keying material on side channels, such as might be exposed by the time it takes to perform a given operation. The requirements for a good implementation of cryptographic algorithms can change over time.
密码学的实现——特别是密钥管理——可能很困难。例如，实现需要考虑在侧通道上暴露键控材料的可能性，例如在执行给定操作时可能暴露的材料。密码算法的良好实现要求会随着时间的推移而变化。
As a content coding, a "aes128gcm" content coding might be automatically removed by a receiver in a way that is not obvious to the ultimate consumer of a message. Recipients that depend on content-origin authentication using this mechanism MUST reject messages that don't include the "aes128gcm" content coding.
作为一种内容编码，“aes128gcm”内容编码可能会被接收者以对消息的最终消费者不明显的方式自动删除。依赖使用此机制的内容源身份验证的收件人必须拒绝不包含“aes128gcm”内容编码的邮件。
This content encoding is designed to permit the incremental processing of large messages. It also permits random access to plaintext in a limited fashion. The content encoding permits a receiver to detect when a message is truncated.
此内容编码旨在允许增量处理大型消息。它还允许以有限的方式随机访问明文。内容编码允许接收者检测消息何时被截断。
A partially delivered message MUST NOT be processed as though the entire message was successfully delivered. For instance, a partially delivered message cannot be cached as though it were complete.
不能将部分传递的消息当作已成功传递整个消息来处理。例如，部分传递的消息不能像已完成一样进行缓存。
An attacker might exploit willingness to process partial messages to cause a receiver to remain in a specific intermediate state. Implementations performing processing on partial messages need to ensure that any intermediate processing states don't advantage an attacker.
攻击者可能利用处理部分消息的意愿，使接收方保持特定的中间状态。对部分消息执行处理的实现需要确保任何中间处理状态都不会对攻击者有利。
Encrypting different plaintext with the same content-encryption key and nonce in AES-GCM is not safe [RFC5116]. The scheme defined here uses a fixed progression of nonce values. Thus, a new content-encryption key is needed for every application of the content coding. Since input-keying material can be reused, a unique "salt" parameter is needed to ensure that a content-encryption key is not reused.
在AES-GCM中使用相同的内容加密密钥和nonce加密不同的明文是不安全的[RFC5116]。此处定义的方案使用固定的nonce值级数。因此，内容编码的每个应用都需要一个新的内容加密密钥。由于输入密钥材料可以重用，因此需要一个唯一的“salt”参数来确保内容加密密钥不被重用。
If a content-encryption key is reused -- that is, if input-keying material and "salt" parameter are reused -- this could expose the plaintext and the authentication key, nullifying the protection offered by encryption. Thus, if the same input-keying material is reused, then the "salt" parameter MUST be unique each time. This ensures that the content-encryption key is not reused. An implementation SHOULD generate a random "salt" parameter for every message.
如果重复使用内容加密密钥——也就是说，如果重复使用输入密钥材料和“salt”参数——这可能会公开明文和身份验证密钥，从而使加密提供的保护无效。因此，如果重复使用相同的输入键控材质，“salt”参数每次都必须是唯一的。这确保了内容加密密钥不会被重用。实现应该为每条消息生成一个随机的“salt”参数。
There are limits to the data that AEAD_AES_128_GCM can encipher. The maximum value for the record size is limited by the size of the "rs" field in the header (see Section 2.1), which ensures that the 2^36-31 limit for a single application of AEAD_AES_128_GCM is not reached [RFC5116]. In order to preserve a 2^-40 probability of indistinguishability under chosen plaintext attack (IND-CPA), the total amount of plaintext that can be enciphered with the key derived from the same input-keying material and salt MUST be less than 2^44.5 blocks of 16 octets [AEBounds].
AEAD_AES_128_GCM可以加密的数据有限制。记录大小的最大值受标题中“rs”字段大小的限制（参见第2.1节），这确保了AEAD_AES_128_GCM的单个应用程序不会达到2^36-31限制[RFC5116]。为了在选择明文攻击（IND-CPA）下保持2^-40的不可分辨性概率，可使用来自相同输入键控材料和salt的密钥加密的明文总量必须小于16个八位字节的2^-44.5个块[AEBounds]。
If the record size is a multiple of 16 octets, this means that 398 terabytes can be encrypted safely, including padding and overhead. However, if the record size is not a multiple of 16 octets, the total amount of data that can be safely encrypted is reduced because partial AES blocks are encrypted. The worst case is a record size of 18 octets, for which at most 74 terabytes of plaintext can be encrypted, of which at least half is padding.
如果记录大小是16个八位字节的倍数，这意味着可以安全加密398 TB，包括填充和开销。但是，如果记录大小不是16个八位字节的倍数，则可以安全加密的数据总量会减少，因为部分AES块是加密的。最糟糕的情况是记录大小为18个八位字节，最多可以加密74 TB的明文，其中至少一半是填充。
This mechanism only provides content-origin authentication. The authentication tag only ensures that an entity with access to the content-encryption key produced the encrypted data.
此机制仅提供内容源身份验证。身份验证标签仅确保能够访问内容加密密钥的实体生成加密数据。
Any entity with the content-encryption key can, therefore, produce content that will be accepted as valid. This includes all recipients of the same HTTP message.
因此，任何具有内容加密密钥的实体都可以生成将被接受为有效的内容。这包括同一HTTP消息的所有收件人。
Furthermore, any entity that is able to modify both the Content-Encoding header field and the HTTP message body can replace the contents. Without the content-encryption key or the input-keying material, modifications to, or replacement of, parts of a payload body are not possible.
此外，任何能够同时修改内容编码头字段和HTTP消息体的实体都可以替换内容。如果没有内容加密密钥或输入密钥材料，则不可能修改或更换有效负载主体的部件。
Because only the payload body is encrypted, information exposed in header fields is visible to anyone who can read the HTTP message. This could expose side-channel information.
因为只有有效负载主体是加密的，所以可以读取HTTP消息的任何人都可以看到头字段中公开的信息。这可能会暴露侧通道信息。
For example, the Content-Type header field can leak information about the payload body.
例如，Content-Type头字段可能泄漏有关有效负载主体的信息。
There are a number of strategies available to mitigate this threat, depending upon the application's threat model and the users' tolerance for leaked information:
根据应用程序的威胁模型和用户对泄漏信息的容忍度，有多种策略可用于缓解此威胁：
1. Determine that it is not an issue. For example, if it is expected that all content stored will be "application/json", or another very common media type, exposing the Content-Type header field could be an acceptable risk.
1. 确定这不是一个问题。例如，如果预期存储的所有内容都是“application/json”或另一种非常常见的媒体类型，那么暴露content-type头字段可能是一种可接受的风险。
2. If it is considered sensitive information and it is possible to determine it through other means (e.g., out of band, using hints in other representations, etc.), omit the relevant headers, and/ or normalize them. In the case of Content-Type, this could be accomplished by always sending Content-Type: application/octet-stream (the most generic media type), or no Content-Type at all.
2. 如果它被视为敏感信息，并且可以通过其他方式（例如带外、在其他表示中使用提示等）确定它，则省略相关标题，并/或将其规范化。对于内容类型，这可以通过始终发送内容类型来实现：应用程序/八位字节流（最通用的媒体类型），或者根本不发送内容类型。
3. If it is considered sensitive information and it is not possible to convey it elsewhere, encapsulate the HTTP message using the application/http media type (see Section 8.3.2 of [RFC7230]), encrypting that as the payload of the "outer" message.
3. 如果它被视为敏感信息，并且无法在其他地方传输，则使用应用程序/HTTP媒体类型（参见[RFC7230]第8.3.2节）封装HTTP消息，并将其加密为“外部”消息的有效负载。
This mechanism only offers data-origin authentication; it does not perform authentication or authorization of the message creator, which could still need to be performed (e.g., by HTTP authentication [RFC7235]).
此机制仅提供数据源身份验证；它不执行消息创建者的身份验证或授权，这可能仍然需要执行（例如，通过HTTP身份验证[RFC7235]）。
This is especially relevant when an HTTP PUT request is accepted by a server without decrypting the payload; if the request is unauthenticated, it becomes possible for a third party to deny service and/or poison the store.
当服务器接受HTTP PUT请求而不解密有效负载时，这尤其相关；如果请求未经验证，则第三方有可能拒绝服务和/或毒害存储。
Applications using this mechanism need to be aware that the size of encrypted messages, as well as their timing, HTTP methods, URIs and so on, may leak sensitive information. See, for example, [NETFLIX] or [CLINIC].
使用此机制的应用程序需要知道加密消息的大小以及它们的时间、HTTP方法、URI等可能会泄漏敏感信息。例如，参见[NETFLIX]或[CLINIC]。
This risk can be mitigated through the use of the padding that this mechanism provides. Alternatively, splitting up content into segments and storing them separately might reduce exposure. HTTP/2 [RFC7540] combined with TLS [RFC5246] might be used to hide the size of individual messages.
通过使用此机制提供的填充，可以减轻此风险。或者，将内容分为多个部分并单独存储可能会减少曝光。HTTP/2[RFC7540]结合TLS[RFC5246]可用于隐藏单个消息的大小。
Developing a padding strategy is difficult. A good padding strategy can depend on context. Common strategies include padding to a small set of fixed lengths, padding to multiples of a value, or padding to powers of 2. Even a good strategy can still cause size information to leak if processing activity of a recipient can be observed. This is especially true if the trailing records of a message contain only padding. Distributing non-padding data across records is recommended to avoid leaking size information.
制定填充策略是困难的。一个好的填充策略可以依赖于上下文。常用的策略包括填充到一小部分固定长度、填充到值的倍数或填充到2的幂。如果可以观察到收件人的处理活动，即使是好的策略也可能导致大小信息泄漏。如果消息的尾部记录仅包含填充，则尤其如此。建议跨记录分发非填充数据，以避免泄漏大小信息。
This memo registers the "aes128gcm" HTTP content coding in the "HTTP Content Coding Registry", as detailed in Section 2.
本备忘录在“HTTP内容编码注册表”中注册“aes128gcm”HTTP内容编码，详见第2节。
o Name: aes128gcm
o 名称：aes128gcm
o Description: AES-GCM encryption with a 128-bit content-encryption key
o 描述：使用128位内容加密密钥的AES-GCM加密
o Reference: this specification
o 参考：本规范
[FIPS180-4] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", FIPS PUB 180-4, DOI 10.6028/NIST.FIPS180-4, August 2015, <http://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.180-4.pdf>.
[FIPS180-4]国家标准与技术研究所，“安全哈希标准（SHS）”，FIPS PUB 180-4，DOI 10.6028/NIST.FIPS180-42015年8月<http://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.180-4.pdf>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，DOI 10.17487/RFC3629，2003年11月<http://www.rfc-editor.org/info/rfc3629>.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, <http://www.rfc-editor.org/info/rfc5116>.
[RFC5116]McGrew，D.“认证加密的接口和算法”，RFC 5116，DOI 10.17487/RFC5116，2008年1月<http://www.rfc-editor.org/info/rfc5116>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, <http://www.rfc-editor.org/info/rfc5869>.
[RFC5869]Krawczyk，H.和P.Eronen，“基于HMAC的提取和扩展密钥派生函数（HKDF）”，RFC 5869，DOI 10.17487/RFC5869，2010年5月<http://www.rfc-editor.org/info/rfc5869>.
[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, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7230]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：消息语法和路由”，RFC 7230，DOI 10.17487/RFC7230，2014年6月<http://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <http://www.rfc-editor.org/info/rfc7231>.
[RFC7231]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：语义和内容”，RFC 7231，DOI 10.17487/RFC72312014年6月<http://www.rfc-editor.org/info/rfc7231>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <http://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<http://www.rfc-editor.org/info/rfc8174>.
[AEBounds] Luykx, A. and K. Paterson, "Limits on Authenticated Encryption Use in TLS", March 2016, <http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf>.
[AEBounds]Luykx，A.和K.Paterson，“TLS中认证加密使用的限制”，2016年3月<http://www.isg.rhul.ac.uk/~kp/TLS AEbounds.pdf>。
[CLINIC] Miller, B., Huang, L., Joseph, A., and J. Tygar, "I Know Why You Went to the Clinic: Risks and Realization of HTTPS Traffic Analysis", DOI 10.1007/978-3-319-08506-7_8, March 2014, <https://arxiv.org/abs/1403.0297>.
[诊所]Miller，B.，Huang，L.，Joseph，A.，和J.Tygar，“我知道你为什么去诊所：HTTPS流量分析的风险和实现”，DOI 10.1007/978-3-319-08506-7_8，2014年3月<https://arxiv.org/abs/1403.0297>.
[NETFLIX] Reed, A. and M. Kranch, "Identifying HTTPS-Protected Netflix Videos in Real-Time", Proceedings of the Seventh ACM on Conference on Data and Application Security and Privacy CODASPY '17, DOI 10.1145/3029806.3029821, 2017.
[NETFLIX]Reed，A.和M.Kranch，“实时识别受HTTPS保护的NETFLIX视频”，数据和应用程序安全与隐私会议第七届ACM会议记录CODASPY'17，DOI 10.1145/3029806.30298212017。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <http://www.rfc-editor.org/info/rfc4648>.
[RFC4648]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC 4648，DOI 10.17487/RFC4648，2006年10月<http://www.rfc-editor.org/info/rfc4648>.
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, DOI 10.17487/RFC4880, November 2007, <http://www.rfc-editor.org/info/rfc4880>.
[RFC4880]Callas，J.，Donnerhacke，L.，Finney，H.，Shaw，D.，和R.Thayer，“OpenPGP消息格式”，RFC 4880，DOI 10.17487/RFC4880，2007年11月<http://www.rfc-editor.org/info/rfc4880>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<http://www.rfc-editor.org/info/rfc5246>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <http://www.rfc-editor.org/info/rfc5652>.
[RFC5652]Housley，R.，“加密消息语法（CMS）”，STD 70，RFC 5652，DOI 10.17487/RFC5652，2009年9月<http://www.rfc-editor.org/info/rfc5652>.
[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233, DOI 10.17487/RFC7233, June 2014, <http://www.rfc-editor.org/info/rfc7233>.
[RFC7233]Fielding，R.，Ed.，Lafon，Y.，Ed.，和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：范围请求”，RFC 7233，DOI 10.17487/RFC7233，2014年6月<http://www.rfc-editor.org/info/rfc7233>.
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, DOI 10.17487/RFC7235, June 2014, <http://www.rfc-editor.org/info/rfc7235>.
[RFC7235]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：认证”，RFC 7235，DOI 10.17487/RFC7235，2014年6月<http://www.rfc-editor.org/info/rfc7235>.
[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015, <http://www.rfc-editor.org/info/rfc7516>.
[RFC7516]Jones，M.和J.Hildebrand，“JSON Web加密（JWE）”，RFC 7516，DOI 10.17487/RFC7516，2015年5月<http://www.rfc-editor.org/info/rfc7516>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, <http://www.rfc-editor.org/info/rfc7540>.
[RFC7540]Belshe，M.，Paon，R.，和M.Thomson，编辑，“超文本传输协议版本2（HTTP/2）”，RFC 7540，DOI 10.17487/RFC7540，2015年5月<http://www.rfc-editor.org/info/rfc7540>.
[XMLENC] Eastlake, D., Reagle, J., Hirsch, F., and T. Roessler, "XML Encryption Syntax and Processing Version 1.1", World Wide Web Consortium Recommendation REC-xmlenc-core1-20130411, April 2013, <http://www.w3.org/TR/2013/REC-xmlenc-core1-20130411>.
[XMLENC]伊斯特莱克，D.，雷格尔，J.，赫希，F.，和T.罗斯勒，“XML加密语法和处理版本1.1”，万维网联盟建议REC-XMLENC-core1-201304111913年4月<http://www.w3.org/TR/2013/REC-xmlenc-core1-20130411>.
The "aes128gcm" content coding can be considered as a sequence of JSON Web Encryption (JWE) [RFC7516] objects, each corresponding to a single fixed-size record that includes trailing padding. The following transformations are applied to a JWE object that might be expressed using the JWE Compact Serialization:
“aes128gcm”内容编码可以被视为JSON Web Encryption（JWE）[RFC7516]对象的序列，每个对象对应于一个包含尾部填充的固定大小记录。以下转换应用于可能使用JWE压缩序列化表示的JWE对象：
o The JWE Protected Header is fixed to the value { "alg": "dir", "enc": "A128GCM" }, describing direct encryption using AES-GCM with a 128-bit content-encryption key. This header is not transmitted, it is instead implied by the value of the Content-Encoding header field.
o JWE受保护的头被固定为值{“alg”：“dir”，“enc”：“A128GCM”}，描述了使用AES-GCM和128位内容加密密钥的直接加密。此标头不会被传输，而是由内容编码标头字段的值暗示。
o The JWE Encrypted Key is empty, as stipulated by the direct encryption algorithm.
o 按照直接加密算法的规定，JWE加密密钥为空。
o The JWE Initialization Vector ("iv") for each record is set to the exclusive-or of the 96-bit record sequence number, starting at zero, and a value derived from the input-keying material (see Section 2.3). This value is also not transmitted.
o 每个记录的JWE初始化向量（“iv”）设置为96位记录序列号的异或，从零开始，并从输入键控材料中导出一个值（见第2.3节）。该值也不会被传输。
o The final value is the concatenated header, JWE Ciphertext, and JWE Authentication Tag, all expressed without base64url encoding. The "." separator is omitted, since the length of these fields is known.
o 最后一个值是连接的头、JWE密文和JWE身份验证标记，它们都是在没有base64url编码的情况下表示的。省略“.”分隔符，因为这些字段的长度是已知的。
Thus, the example in Section 3.1 can be rendered using the JWE Compact Serialization as:
因此，第3.1节中的示例可以使用JWE压缩序列化呈现为：
eyAiYWxnIjogImRpciIsICJlbmMiOiAiQTEyOEdDTSIgfQ..Bcs8gkIRKLI8GeI8. -NAVub2qFgBEuQKRapoZuw.4jGQi9rcwQHU8P6XLxOGOA
Eyaiywxnijogimrpcisicjlbmmioaiqteyoeddtsgfq..bcs8gkirkl8-NAVub2qFgBEuQKRapoZuw.4jGQi9rcwQHU8P6XLxOGOA
Where the first line represents the fixed JWE Protected Header, an empty JWE Encrypted Key, and the algorithmically determined JWE Initialization Vector. The second line contains the encoded body, split into JWE Ciphertext and JWE Authentication Tag.
其中第一行表示固定的JWE保护头、空的JWE加密密钥和算法确定的JWE初始化向量。第二行包含编码体，分为JWE密文和JWE身份验证标记。
Acknowledgements
致谢
Mark Nottingham was an original author of this document.
马克·诺丁汉是这份文件的原始作者。
The following people provided valuable input: Richard Barnes, David Benjamin, Peter Beverloo, JR Conlin, Mike Jones, Stephen Farrell, Adam Langley, James Manger, John Mattsson, Julian Reschke, Eric Rescorla, Jim Schaad, and Magnus Westerlund.
以下人员提供了宝贵的意见：理查德·巴恩斯、大卫·本杰明、彼得·贝弗洛、小康林、迈克·琼斯、斯蒂芬·法雷尔、亚当·兰利、詹姆斯·马格尔、约翰·马特森、朱利安·雷什克、埃里克·雷斯科拉、吉姆·沙德和马格纳斯·韦斯特隆德。
Author's Address
作者地址
Martin Thomson Mozilla
马丁·汤姆森·莫齐拉
Email: martin.thomson@gmail.com
Email: martin.thomson@gmail.com