Internet Engineering Task Force (IETF) R. Barnes
Request for Comments: 7165 Mozilla
Category: Informational April 2014
ISSN: 2070-1721
Internet Engineering Task Force (IETF) R. Barnes
Request for Comments: 7165 Mozilla
Category: Informational April 2014
ISSN: 2070-1721
Use Cases and Requirements for JSON Object Signing and Encryption (JOSE)
JSON对象签名和加密（JOSE）的用例和要求
Abstract
摘要
Many Internet applications have a need for object-based security mechanisms in addition to security mechanisms at the network layer or transport layer. For many years, the Cryptographic Message Syntax (CMS) has provided a binary secure object format based on ASN.1. Over time, binary object encodings such as ASN.1 have become less common than text-based encodings, such as the JavaScript Object Notation (JSON). This document defines a set of use cases and requirements for a secure object format encoded using JSON, drawn from a variety of application security mechanisms currently in development.
除了网络层或传输层的安全机制外，许多Internet应用程序还需要基于对象的安全机制。多年来，加密消息语法（CMS）提供了一种基于ASN.1的二进制安全对象格式。随着时间的推移，二进制对象编码（如ASN.1）已不如基于文本的编码（如JavaScript对象表示法（JSON））常见。本文档定义了一组使用JSON编码的安全对象格式的用例和需求，这些安全对象格式来自当前正在开发的各种应用程序安全机制。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第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/rfc7165.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7165.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Basic Requirements . . . . . . . . . . . . . . . . . . . . . 5
4. Requirements on Application Protocols . . . . . . . . . . . . 6
5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Security Tokens . . . . . . . . . . . . . . . . . . . . . 7
5.2. OAuth . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.3. OpenID Connect . . . . . . . . . . . . . . . . . . . . . 9
5.4. XMPP . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.5. ALTO . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.6. Emergency Alerting . . . . . . . . . . . . . . . . . . . 13
5.7. Web Cryptography . . . . . . . . . . . . . . . . . . . . 15
5.8. Constrained Devices . . . . . . . . . . . . . . . . . . . 16
5.8.1. Example: MAC Based on ECDH-Derived Key . . . . . . . 16
5.8.2. Object Security for CoAP . . . . . . . . . . . . . . 17
6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 18
6.1. Functional Requirements . . . . . . . . . . . . . . . . . 18
6.2. Security Requirements . . . . . . . . . . . . . . . . . . 19
6.3. Desiderata . . . . . . . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Normative References . . . . . . . . . . . . . . . . . . 21
8.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 25
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Basic Requirements . . . . . . . . . . . . . . . . . . . . . 5
4. Requirements on Application Protocols . . . . . . . . . . . . 6
5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Security Tokens . . . . . . . . . . . . . . . . . . . . . 7
5.2. OAuth . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.3. OpenID Connect . . . . . . . . . . . . . . . . . . . . . 9
5.4. XMPP . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.5. ALTO . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.6. Emergency Alerting . . . . . . . . . . . . . . . . . . . 13
5.7. Web Cryptography . . . . . . . . . . . . . . . . . . . . 15
5.8. Constrained Devices . . . . . . . . . . . . . . . . . . . 16
5.8.1. Example: MAC Based on ECDH-Derived Key . . . . . . . 16
5.8.2. Object Security for CoAP . . . . . . . . . . . . . . 17
6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 18
6.1. Functional Requirements . . . . . . . . . . . . . . . . . 18
6.2. Security Requirements . . . . . . . . . . . . . . . . . . 19
6.3. Desiderata . . . . . . . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Normative References . . . . . . . . . . . . . . . . . . 21
8.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 25
Internet applications rest on the layered architecture of the Internet and take advantage of security mechanisms at all layers. Many applications rely primarily on channel-based security technologies such as IPsec and Transport Layer Security (TLS), which create a secure channel at the IP layer or transport layer over which application data can flow [RFC4301] [RFC5246]. These mechanisms, however, cannot provide end-to-end security in some cases. For example, in protocols with application-layer intermediaries, channel-based security protocols would protect messages from attackers between intermediaries, but not from the intermediaries themselves. These cases require object-based security technologies, which embed application data within a secure object that can be safely handled by untrusted entities.
Internet应用程序基于Internet的分层体系结构，并利用所有层的安全机制。许多应用程序主要依赖于基于通道的安全技术，如IPsec和传输层安全（TLS），它们在IP层或传输层创建一个安全通道，应用程序数据可以在该通道上流动[RFC4301][RFC5246]。但是，在某些情况下，这些机制无法提供端到端安全性。例如，在具有应用层中间层的协议中，基于通道的安全协议将保护消息免受中间层之间的攻击者的攻击，但不会保护消息免受中间层本身的攻击。这些情况需要基于对象的安全技术，将应用程序数据嵌入到可由不受信任的实体安全处理的安全对象中。
The most well-known example of such a protocol today is the use of Secure/Multipurpose Internet Mail Extensions (S/MIME) protections within the email system [RFC5751] [RFC5322]. An email message typically passes through a series of intermediate Mail Transfer Agents (MTAs) en route to its destination. While these MTAs often apply channel-based security protections to their interactions (e.g., STARTTLS [RFC3207]), these protections do not prevent the MTAs from interfering with the message. In order to provide end-to-end security protections in the presence of untrusted MTAs, mail users can use S/MIME to embed message bodies in a secure object format that can provide confidentiality, integrity, and data origin authentication.
如今，这种协议最著名的例子是在电子邮件系统[RFC5751][RFC5322]中使用安全/多用途Internet邮件扩展（S/MIME）保护。电子邮件通常在到达目的地的途中通过一系列中间邮件传输代理（MTA）。虽然这些MTA通常对其交互应用基于通道的安全保护（例如STARTTLS[RFC3207]），但这些保护并不能防止MTA干扰消息。为了在存在不受信任的MTA时提供端到端安全保护，邮件用户可以使用S/MIME以安全的对象格式嵌入邮件正文，该格式可以提供机密性、完整性和数据源身份验证。
S/MIME is based on the Cryptographic Message Syntax (CMS) for secure objects [RFC5652]. CMS is defined using Abstract Syntax Notation 1 (ASN.1) and typically encoded using the ASN.1 Distinguished Encoding Rules (DER), which define a binary encoding of the protected message and associated parameters [ITU.X690.2002]. In recent years, usage of ASN.1 has decreased (along with other binary encodings for general objects), while more applications have come to rely on text-based formats such as the Extensible Markup Language (XML) [W3C.REC-xml] or the JavaScript Object Notation (JSON) [RFC7159].
S/MIME基于安全对象的加密消息语法（CMS）[RFC5652]。CMS使用抽象语法符号1（ASN.1）进行定义，通常使用ASN.1可分辨编码规则（DER）进行编码，该规则定义了受保护消息和相关参数的二进制编码[ITU.X690.2002]。近年来，ASN.1的使用有所减少（以及其他针对一般对象的二进制编码），而更多的应用程序开始依赖基于文本的格式，如可扩展标记语言（XML）[W3C.REC XML]或JavaScript对象表示法（JSON）[RFC7159]。
Many current applications thus have much more robust support for processing objects in these text-based formats than ASN.1 objects; indeed, many lack the ability to process ASN.1 objects at all. To simplify the addition of object-based security features to these applications, the IETF JSON Object Signing and Encryption (JOSE) working group has been chartered to develop a secure object format based on JSON. While the basic requirements for this object format are straightforward -- namely, confidentiality and integrity mechanisms encoded in JSON -- discussions in the working group
因此，与ASN.1对象相比，许多当前的应用程序对处理这些基于文本的格式的对象具有更强大的支持；事实上，许多人根本不具备处理ASN.1对象的能力。为了简化向这些应用程序中添加基于对象的安全功能，IETF JSON对象签名和加密（JOSE）工作组已获得特许，以开发基于JSON的安全对象格式。虽然这种对象格式的基本要求很简单——即，用JSON编码的机密性和完整性机制——但在工作组中进行了讨论
indicated that different applications hoping to use the formats defined by JOSE have different requirements. This document summarizes the use cases for JOSE envisioned by those potential applications and the resulting requirements for security mechanisms and object encodings.
表示希望使用JOSE定义的格式的不同应用程序有不同的要求。本文档总结了这些潜在应用程序所设想的JOE用例，以及由此产生的安全机制和对象编码需求。
Some systems that use XML have specified the use of XML-based security mechanisms for object security, namely XML Digital Signatures and XML Encryption [W3C.xmldsig-core] [W3C.xmlenc-core]. These mechanisms are used by several security token systems (e.g., Security Assertion Markup Language (SAML) [OASIS.saml-core-2.0-os], Web Services Federation [WS-Federation]), and the Common Alerting Protocol (CAP) emergency alerting format [CAP]. In practice, however, XML-based secure object formats introduce similar levels of complexity to ASN.1 (e.g., due to the need for XML canonicalization), so developers that lack the tools or motivation to handle ASN.1 aren't likely to use XML security either. This situation motivates the creation of a JSON-based secure object format that is simple enough to implement and deploy that it can be easily adopted by developers with minimal effort and tools.
一些使用XML的系统指定使用基于XML的安全机制来实现对象安全，即XML数字签名和XML加密[W3C.xmldsig core][W3C.xmlenc core]。这些机制由多个安全令牌系统（例如，安全断言标记语言（SAML）[OASIS.SAML-core-2.0-os]、Web服务联盟[WS-Federation]）和通用警报协议（CAP）紧急警报格式[CAP]使用。然而，在实践中，基于XML的安全对象格式引入了与ASN.1类似的复杂性（例如，由于需要XML规范化），因此缺乏处理ASN.1的工具或动机的开发人员也不太可能使用XML安全性。这种情况促使创建基于JSON的安全对象格式，该格式非常简单，可以实现和部署，开发人员只需花费很少的精力和工具就可以轻松采用。
This document makes extensive use of standard security terminology [RFC4949]. In addition, because the use cases for JOSE and CMS are similar, we will sometimes make analogies to some CMS concepts [RFC5652].
本文档广泛使用了标准安全术语[RFC4949]。此外，由于JOE和CMS的用例相似，我们有时会对一些CMS概念进行类比[RFC5652]。
The JOSE working group charter calls for the group to define three basic JSON object formats:
JOSE工作组章程要求工作组定义三种基本的JSON对象格式：
1. Integrity-protected object format
1. 完整性保护对象格式
2. Confidentiality-protected object format
2. 机密保护对象格式
3. A format for expressing keys
3. 表示键的格式
In this document, we will refer to these as the "signed object format", the "encrypted object format", and the "key format", respectively. The JOSE working group items intended to describe these formats are JSON Web Signature [JWS], JSON Web Encryption [JWE], and JSON Web Key [JWK], respectively. Algorithms and algorithm identifiers used by JWS, JWE, and JWK are defined in JSON Web Algorithms [JWA].
在本文档中，我们将分别将其称为“签名对象格式”、“加密对象格式”和“密钥格式”。JOSE工作组旨在描述这些格式的项目分别是JSON Web签名[JWS]、JSON Web加密[JWE]和JSON Web密钥[JWK]。JWS、JWE和JWK使用的算法和算法标识符在JSON Web算法[JWA]中定义。
In general, where there is no need to distinguish between asymmetric and symmetric operations, we will use the terms "signing", "signature", etc., to denote both true digital signatures involving
一般来说，在不需要区分不对称和对称操作的情况下，我们将使用术语“签名”、“签名”等来表示涉及
asymmetric cryptography as well as Message Authentication Codes (MACs) using symmetric keys.
非对称加密以及使用对称密钥的消息身份验证码（MAC）。
In the lifespan of a secure object, there are two basic roles, an entity that creates the object (e.g., encrypting or signing a payload) and an entity that uses the object (decrypting and verifying). We will refer to these roles as "sender" and "recipient", respectively. Note that while some requirements and use cases may refer to these as single entities, each object may have multiple entities in each role. For example, a message may be signed by multiple senders or decrypted by multiple recipients.
在安全对象的生命周期中，有两个基本角色，一个是创建该对象的实体（例如，对有效负载进行加密或签名），另一个是使用该对象的实体（解密和验证）。我们将这些角色分别称为“发件人”和“收件人”。注意，虽然一些需求和用例可能将它们称为单个实体，但每个对象在每个角色中可能有多个实体。例如，一封邮件可能由多个发件人签名或由多个收件人解密。
For the encrypted and signed object formats, the necessary protections will be created using appropriate cryptographic mechanisms: symmetric or asymmetric encryption for confidentiality and MACs or digital signatures for integrity protection. In both cases, it is necessary for the JOSE format to support both symmetric and asymmetric operations.
对于加密和签名对象格式，将使用适当的加密机制创建必要的保护：对称或非对称加密用于保密，MAC或数字签名用于完整性保护。在这两种情况下，JOSE格式都必须支持对称和非对称操作。
o The JOSE encrypted object format must support object encryption in the case where the sender and receiver share a symmetric key.
o 在发送方和接收方共享对称密钥的情况下，JOSE加密对象格式必须支持对象加密。
o The JOSE encrypted object format must support object encryption in the case where the sender has only a public key for the receiver.
o 在发送方只有接收方的公钥的情况下，JOSE加密对象格式必须支持对象加密。
o The JOSE signed object format must support integrity protection using MACs, for the case where the sender and receiver share only a symmetric key.
o 对于发送方和接收方仅共享对称密钥的情况，JOSE签名对象格式必须支持使用MAC的完整性保护。
o The JOSE signed object format must support integrity protection using digital signatures, for the case where the receiver has only a public key for the sender.
o JOSE签名对象格式必须支持使用数字签名的完整性保护，适用于接收方只有发送方公钥的情况。
In some applications, the key used to process a JOSE object is indicated by application context, instead of directly in the JOSE object. However, in order to avoid confusion, endpoints that lack the necessary context need to be able to recognize this and fail cleanly. Other than keys, JOSE objects do not support pre-negotiation; all cryptographic parameters must be expressed directly in the JOSE object.
在某些应用程序中，用于处理JOSE对象的键由应用程序上下文指示，而不是直接在JOSE对象中指示。但是，为了避免混淆，缺少必要上下文的端点需要能够识别这一点，并清楚地失败。除密钥外，JOSE对象不支持预协商；所有加密参数必须直接在JOSE对象中表示。
o The JOSE signed and encrypted object formats must define the process by which an implementation recognizes whether it has the key required to process a given object, whether the key is specified by the object or by some out-of-band mechanism.
o JOSE签名和加密的对象格式必须定义一个过程，通过该过程，实现可以识别它是否拥有处理给定对象所需的密钥，该密钥是由对象指定的还是由某些带外机制指定的。
o Each algorithm used for JOSE must define which parameters are required to be present in a JOSE object using that algorithm.
o 用于JOSE的每个算法必须定义使用该算法的JOSE对象中需要存在哪些参数。
In cases where two entities are going to be exchanging several JOSE objects, it might be helpful to pre-negotiate some parameters so that they do not have to be signaled in every JOSE object. However, so as not to confuse endpoints that do not support pre-negotiation, it is useful to signal when pre-negotiated parameters are in use in those cases.
在两个实体将要交换多个JOSE对象的情况下，预先协商一些参数可能会有所帮助，这样就不必在每个JOSE对象中通知它们。但是，为了避免混淆不支持预协商的端点，在这些情况下，在使用预协商参数时发出信号是很有用的。
o It should be possible to extend the base JOSE signed and encrypted object formats to indicate that pre-negotiated parameters are to be used to process the object. This extension should also provide a means of indicating which parameters are to be used.
o 应该可以扩展基本的签名和加密对象格式，以指示将使用预先协商的参数来处理对象。此扩展还应提供一种指示将使用哪些参数的方法。
The purpose of the key format is to provide the recipient with sufficient information to use the encoded key to process cryptographic messages. Thus, it is sometimes necessary to include additional parameters along with the bare key.
密钥格式的目的是为接收方提供足够的信息，以便使用编码密钥处理加密消息。因此，有时有必要将附加参数与裸密钥一起包括在内。
o The JOSE key format must enable inclusion of all algorithm parameters necessary to use the encoded key, including an identifier for the algorithm with which the key is used as well as any additional parameters required by the algorithm (e.g., elliptic curve parameters).
o JOSE密钥格式必须能够包含使用编码密钥所需的所有算法参数，包括使用密钥的算法的标识符以及算法所需的任何附加参数（例如，椭圆曲线参数）。
The JOSE secure object formats describe how cryptographic processing is done on secured content, ensuring that the recipient of an object is able to properly decrypt an encrypted object or verify a signature. In order to make use of JOSE, however, applications will need to specify several aspects of how JOSE is to be used:
JOSE安全对象格式描述了如何对安全内容进行加密处理，以确保对象的收件人能够正确解密加密对象或验证签名。然而，为了使用JOE，应用程序需要指定如何使用JOE的几个方面：
o What application content is to be protected
o 要保护哪些应用程序内容
o Which cryptographic algorithms are to be used
o 将使用哪些加密算法
o How application protocol entities establish keys
o 应用程序协议实体如何建立密钥
o Whether keys are to be explicitly indicated in JOSE objects or associated by application context
o 键是在对象中显式指示还是由应用程序上下文关联
o Which serialization(s) of JOSE objects are to be used
o 要使用何塞对象的哪些序列化
Several IETF working groups developing application-layer protocols have expressed a desire to use the JOSE data formats in their designs for end-to-end security features. In this section, we summarize the use cases proposed by these groups and discuss the requirements that they imply for the JOSE object formats.
几个开发应用层协议的IETF工作组表示希望在设计端到端安全特性时使用JOSE数据格式。在本节中，我们总结了这些小组提出的用例，并讨论了它们对对象格式的要求。
Security tokens are a common use case for object-based security, for example, SAML assertions [OASIS.saml-core-2.0-os]. Security tokens are used to convey information about a subject entity ("claims" or "assertions") from an issuer to a recipient. The security features of a token format enable the recipient to verify that the claims came from the issuer and, if the object is confidentiality protected, that they were not visible to other parties.
安全令牌是基于对象的安全性的常见用例，例如SAML断言[OASIS.SAML-core-2.0-os]。安全令牌用于将主题实体（“声明”或“断言”）的信息从发行者传递给接收者。令牌格式的安全特性使接收方能够验证声明是否来自发行方，如果对象受保密保护，则验证声明是否对其他方不可见。
Security tokens are used in federation protocols such as SAML 2.0 [OASIS.saml-core-2.0-os], WS-Federation [WS-Federation], Mozilla Persona [Persona], and OpenID Connect [OpenID.Core], as well as in resource authorization protocols such as OAuth 2.0 [RFC6749], including for OAuth bearer tokens [RFC6750]. In some cases, security tokens are used for client authentication and for access control [JWT-BEARER] [SAML2].
安全令牌用于联盟协议，如SAML2.0[OASIS.SAML-core-2.0-os]、WS-federation[WS-federation]、Mozilla Persona[Persona]和OpenID Connect[OpenID.core]，以及资源授权协议，如OAuth 2.0[RFC6749]，包括OAuth承载令牌[RFC6750]。在某些情况下，安全令牌用于客户端身份验证和访问控制[JWT-BEARER][SAML2]。
JSON Web Token [JWT] is a security token format based on JSON and JOSE. It is used with Mozilla Persona, OpenID Connect, and OAuth. Because JWTs are often used in contexts with limited space (e.g., HTTP query parameters), it is a core requirement for JWTs, and thus JOSE, to have a compact, URL-safe representation.
JSON Web令牌[JWT]是一种基于JSON和JOSE的安全令牌格式。它与Mozilla角色、OpenID连接和OAuth一起使用。由于JWT通常用于空间有限的上下文（例如HTTP查询参数），因此JWT的核心要求是具有紧凑、URL安全的表示。
The OAuth protocol defines a mechanism for distributing and using authorization tokens using HTTP [RFC6749]. A client that wishes to access a protected resource requests authorization from the resource owner. If the resource owner allows this access, he directs an authorization server to issue an access token to the client. When the client wishes to access the protected resource, he presents the token to the relevant resource server, which verifies the validity of the token before providing access to the protected resource.
OAuth协议定义了一种使用HTTP[RFC6749]分发和使用授权令牌的机制。希望访问受保护资源的客户端向资源所有者请求授权。如果资源所有者允许此访问，他将指示授权服务器向客户端颁发访问令牌。当客户端希望访问受保护的资源时，他将令牌提供给相关的资源服务器，该服务器在提供对受保护资源的访问之前验证令牌的有效性。
+---------------+ +---------------+
| | | |
| Resource |<........>| Authorization |
| Server | | Server |
| | | |
+---------------+ +---------------+
^ |
| |
| |
| |
| |
+------------|--+ +--|------------+
| +----------------+ |
| | | Resource |
| Client | | Owner |
| | | |
+---------------+ +---------------+
+---------------+ +---------------+
| | | |
| Resource |<........>| Authorization |
| Server | | Server |
| | | |
+---------------+ +---------------+
^ |
| |
| |
| |
| |
+------------|--+ +--|------------+
| +----------------+ |
| | | Resource |
| Client | | Owner |
| | | |
+---------------+ +---------------+
Figure 1: The OAuth Process
图1:OAuth进程
In effect, this process moves the token from the authorization server (as a sender of the object) to the resource server (recipient) via the client as well as the resource owner (the latter because of the HTTP mechanics underlying the protocol). As with email, we have a case where an application object is transported via untrusted intermediaries.
实际上，此过程将令牌从授权服务器（作为对象的发送方）通过客户端和资源所有者（后者是因为协议的HTTP机制）移动到资源服务器（接收方）。与电子邮件一样，我们有一种情况，即应用程序对象通过不受信任的中介进行传输。
This application has two essential security requirements: integrity and data origin authentication. Integrity protection is required so that the resource owner and the client cannot modify the permission encoded in the token. Although the resource owner is ultimately the entity that grants authorization, it is not trusted to modify the authorization token, since this could, for example, grant access to resources not owned by the resource owner.
此应用程序有两个基本的安全要求：完整性和数据源身份验证。需要完整性保护，以便资源所有者和客户端无法修改令牌中编码的权限。尽管资源所有者最终是授予授权的实体，但不信任它修改授权令牌，因为这可能授予对资源所有者不拥有的资源的访问权。
Data origin authentication is required so that the resource server can verify that the token was issued by a trusted authorization server.
需要数据源身份验证，以便资源服务器可以验证令牌是否由受信任的授权服务器颁发。
Confidentiality protection may also be needed if the authorization server is concerned about the visibility of permissions information to the resource owner or client. For example, permissions related to social networking might be considered private information. Note, however, that OAuth already requires that the underlying HTTP transactions be protected by TLS, so tokens are already confidentiality protected from entities other than the resource owner and client.
如果授权服务器担心权限信息对资源所有者或客户端的可见性，则可能还需要进行保密保护。例如，与社交网络相关的权限可能被视为私人信息。但是，请注意，OAuth已经要求底层HTTP事务由TLS保护，因此令牌已经受到了来自除资源所有者和客户机之外的实体的机密性保护。
The confidentiality and integrity needs are met by the basic requirements for signed and encrypted object formats, whether the signing and encryption are provided using asymmetric or symmetric cryptography. The choice of which mechanism is applied will depend on the relationship between the two servers, namely whether they share a symmetric key or only public keys.
无论签名和加密是使用非对称还是对称加密技术提供的，签名和加密对象格式的基本要求都满足了机密性和完整性需求。应用哪种机制的选择将取决于两台服务器之间的关系，即它们是共享对称密钥还是仅共享公钥。
Authentication requirements will also depend on deployment characteristics. Where there is a relatively strong binding between the resource server and the authorization server, it may suffice for the authorization server issuing a token to be identified by the key used to sign the token. This requires that the protocol carry either the public key of the authorization server or an identifier for the public or symmetric key. In OAuth, the "client_id" parameter (external to the token) identifies the key to be used.
身份验证要求也将取决于部署特征。在资源服务器和授权服务器之间存在相对较强的绑定的情况下，授权服务器发出的令牌可以由用于签名令牌的密钥来标识。这要求协议携带授权服务器的公钥或公钥或对称密钥的标识符。在OAuth中，“client_id”参数（令牌外部）标识要使用的密钥。
There may also be more advanced cases where the authorization server's key is not known in advance to the resource server. This may happen, for instance, if an entity instantiated a collection of authorization servers (say for load balancing), each of which has an independent key pair. In these cases, it may be necessary to also include a certificate or certificate chain for the authorization server, so that the resource server can verify that the authorization server is an entity that it trusts.
还可能存在更高级的情况，即资源服务器事先不知道授权服务器的密钥。例如，如果一个实体实例化了一组授权服务器（例如用于负载平衡），其中每个服务器都有一个独立的密钥对，则可能会发生这种情况。在这些情况下，可能还需要包括授权服务器的证书或证书链，以便资源服务器可以验证授权服务器是否是其信任的实体。
The HTTP transport for OAuth imposes a particular constraint on the encoding. In the OAuth protocol, tokens frequently need to be passed as query parameters in HTTP URIs [RFC2616] after having been base64url encoded [RFC4648]. While there is no specified limit on the length of URIs (and thus of query parameters), in practice, URIs of more than 2,048 characters are rejected by some user agents. So this use case requires that JOSE objects be sufficiently small, even after being signed and possibly encrypted.
OAuth的HTTP传输对编码施加了特定的约束。在OAuth协议中，令牌在经过base64url编码[RFC4648]后，经常需要在HTTP URI[RFC2616]中作为查询参数传递。虽然对URI的长度（以及查询参数的长度）没有规定限制，但实际上，一些用户代理拒绝2048个字符以上的URI。所以这个用例要求JOSE对象足够小，即使在经过签名和可能的加密之后也是如此。
The OpenID Connect protocol [OpenID.Core] is a simple, REST/JSON-based identity federation protocol layered on OAuth 2.0. It uses the JWT and JOSE formats both to represent security tokens and to provide security for other protocol messages (performing signing and optionally encryption). OpenID Connect negotiates the algorithms to be used and distributes information about the keys to be used using protocol elements that are not part of the JWT and JOSE header parameters.
OpenID连接协议[OpenID.Core]是一个简单的、基于REST/JSON的身份联合协议，它是在OAuth 2.0上分层的。它使用JWT和JOSE格式来表示安全令牌，并为其他协议消息提供安全性（执行签名和可选加密）。OpenID Connect协商要使用的算法，并使用不属于JWT和JOSE头参数的协议元素分发有关要使用的密钥的信息。
In the OpenID Connect context, it is possible for the recipient of a JWT to accept it without integrity protection in the JWT itself. In such cases, the recipient chooses to rely on transport security
在OpenID连接上下文中，JWT的接收者可以在JWT本身没有完整性保护的情况下接受它。在这种情况下，收件人选择依赖运输安全
rather than object security. For example, if the payload is delivered over a TLS-protected channel, the recipient may regard the protections provided by TLS as sufficient, so JOSE protection would not be required.
而不是对象安全性。例如，如果有效载荷通过受TLS保护的信道传送，则接收方可能认为TLS提供的保护足够，因此不需要JOSE保护。
However, even in this case, it is desirable to associate some metadata with the JWT payload (claim set), such as the content type, or other application-specific metadata. In a signed or encrypted object, these metadata values could be carried in a header with other metadata required for signing or encryption. It would thus simplify the design of OpenID Connect if there could be a JOSE object format that does not apply cryptographic protections to its payload, but allows a header to be attached to the payload in the same way as a signed or encrypted object.
然而，即使在这种情况下，也希望将一些元数据与JWT有效负载（声明集）相关联，例如内容类型或其他特定于应用程序的元数据。在签名或加密的对象中，这些元数据值可以与签名或加密所需的其他元数据一起放在头中。因此，如果存在一种JOSE对象格式，该格式不向其有效负载应用加密保护，但允许以与签名或加密对象相同的方式将头附加到有效负载，则可以简化OpenID Connect的设计。
The Extensible Messaging and Presence Protocol (XMPP) routes messages from one end client to another by way of XMPP servers [RFC6120]. There are typically two servers involved in delivering any given message: The first client (Alice) sends a message for another client (Bob) to her server (A). Server A uses Bob's identity and the DNS to locate the server for Bob's domain (B) and then delivers the message to that server. Server B then routes the message to Bob.
可扩展消息和状态协议（XMPP）通过XMPP服务器将消息从一个终端客户端路由到另一个终端客户端[RFC6120]。传递任何给定消息通常涉及两个服务器：第一个客户端（Alice）将另一个客户端（Bob）的消息发送到她的服务器（a）。服务器A使用Bob的身份和DNS来定位Bob域（B）的服务器，然后将消息传递给该服务器。然后，服务器B将消息路由到Bob。
+-------+ +----------+ +----------+ +-----+
| Alice |-->| Server A |-->| Server B |-->| Bob |
+-------+ +----------+ +----------+ +-----+
+-------+ +----------+ +----------+ +-----+
| Alice |-->| Server A |-->| Server B |-->| Bob |
+-------+ +----------+ +----------+ +-----+
Figure 2: Delivering an XMPP Message
图2：传递XMPP消息
The untrusted-intermediary problems are especially acute for XMPP because in many current deployments, the holder of an XMPP domain outsources the operation of the domain's servers to a different entity. In this environment, there is a clear risk of exposing the domain holder's private information to the domain operator. XMPP already has a defined mechanism for end-to-end security using S/MIME, but it has failed to gain widespread deployment [RFC3923], in part because of key management challenges and in part because of the difficulty of processing S/MIME objects.
不受信任的中介问题对于XMPP来说尤其严重，因为在当前的许多部署中，XMPP域的持有者将域服务器的操作外包给不同的实体。在这种环境下，显然存在向域运营商公开域持有人的私人信息的风险。XMPP已经定义了一种使用S/MIME的端到端安全机制，但它未能得到广泛部署[RFC3923]，部分原因是密钥管理难题，部分原因是处理S/MIME对象的困难。
The XMPP working group is in the process of developing a new end-to-end encryption system with an encoding based on JOSE and a clearer key management system [XMPP-E2E]. The process of sending an encrypted message in this system involves two steps: First, the sender generates a symmetric Session Master Key (SMK), encrypts the message content (including a per-message Content Master Key), and sends the encrypted message to the desired set of recipients.
XMPP工作组正在开发一种新的端到端加密系统，其编码基于JOSE和更清晰的密钥管理系统[XMPP-E2E]。在该系统中发送加密消息的过程包括两个步骤：首先，发送方生成对称会话主密钥（SMK），加密消息内容（包括每消息内容主密钥），并将加密消息发送到所需的收件人集。
Second, each recipient "dials back" to the sender, providing his public key. The sender then responds with the relevant SMK, wrapped with the recipient's public key.
第二，每个接收者“回拨”给发送者，提供他的公钥。然后，发送方用相关的SMK进行响应，SMK用接收方的公钥包装。
+-------+ +----------+ +----------+ +-----+
| Alice |<->| Server A |<->| Server B |<->| Bob |
+-------+ +----------+ +----------+ +-----+
| | | |
|------------Encrypted message---------->|
| | | |
|<---------------Public key--------------|
| | | |
|---------------Wrapped SMK------------->|
| | | |
+-------+ +----------+ +----------+ +-----+
| Alice |<->| Server A |<->| Server B |<->| Bob |
+-------+ +----------+ +----------+ +-----+
| | | |
|------------Encrypted message---------->|
| | | |
|<---------------Public key--------------|
| | | |
|---------------Wrapped SMK------------->|
| | | |
Figure 3: Delivering a Secure XMPP Message
图3：传递安全的XMPP消息
The main thing that this system requires from the JOSE formats is confidentiality protection via content encryption, plus an integrity check via a MAC derived from the same symmetric key. The separation of the key exchange from the transmission of the encrypted content, however, requires that the JOSE encrypted object format allow wrapped symmetric keys to be carried separately from the encrypted payload. In addition, the encrypted object will need to have a tag for the key that was used to encrypt the content, so that the recipient (Bob) can present the tag to the sender (Alice) when requesting the wrapped key.
该系统对JOSE格式的主要要求是通过内容加密进行保密保护，再加上通过从同一对称密钥派生的MAC进行完整性检查。然而，将密钥交换与加密内容的传输分离需要JOSE加密对象格式允许包装的对称密钥与加密的有效载荷分开携带。此外，加密对象需要有一个用于加密内容的密钥的标记，以便接收者（Bob）在请求打包密钥时可以将该标记呈现给发送者（Alice）。
Another important feature of XMPP is that it allows for the simultaneous delivery of a message to multiple recipients. In the diagrams above, Server A could deliver the message not only to Server B (for Bob) but also to Servers C, D, E, etc., for other users. In such cases, to avoid the multiple "dial back" transactions implied by the above mechanism, XMPP systems will likely reuse a given SMK for multiple individual messages, refreshing the SMK on a periodic and/or event-driven basis (e.g., when the recipient's presence changes). They might also cache public keys for end recipients, so that wrapped keys can be sent along with content on future messages. This implies that the JOSE encrypted object format must support the provision of multiple versions of the same wrapped SMK (much as a CMS EnvelopedData structure can include multiple RecipientInfo structures).
XMPP的另一个重要特性是，它允许同时向多个收件人传递消息。在上图中，服务器A不仅可以将消息传递给服务器B（对于Bob），还可以传递给其他用户的服务器C、D、E等。在这种情况下，为了避免上述机制隐含的多个“回拨”事务，XMPP系统可能会对多个单独的消息重用给定的SMK，定期和/或事件驱动地刷新SMK（例如，当收件人的状态发生变化时）。它们还可以缓存最终收件人的公钥，以便包装的密钥可以与未来邮件的内容一起发送。这意味着JOSE加密的对象格式必须支持提供同一包装SMK的多个版本（就像CMS EnvelopedData结构可以包括多个RecipientInfo结构一样）。
In the current draft of the XMPP end-to-end security system, each party is authenticated by virtue of the other party's trust in the XMPP message routing system. The sender is authenticated to the receiver because he can receive messages for the identifier "Alice" (in particular, the request for wrapped keys) and can originate
在XMPP端到端安全系统的当前草案中，每一方都通过另一方对XMPP消息路由系统的信任进行身份验证。发送方通过接收方的身份验证，因为他可以接收标识符“Alice”的消息（特别是对包装密钥的请求），并且可以发起
messages for that identifier (the wrapped key). Likewise, the receiver is authenticated to the sender because he received the original encrypted message and originated the request for a wrapped key. So, the authentication here requires not only that XMPP routing be done properly, but also that TLS be used on every hop. Moreover, it requires that the TLS channels have strong authentication, since a man in the middle on any of the three hops can masquerade as Bob and obtain the key material for an encrypted message.
该标识符（包装密钥）的消息。同样，接收方也向发送方进行了身份验证，因为他收到了原始加密消息，并发起了对打包密钥的请求。因此，这里的身份验证不仅需要正确地执行XMPP路由，而且还需要在每个跃点上使用TLS。此外，它要求TLS信道具有强的认证，因为在三跳中的任何一个中间的人可以伪装成鲍伯并获得加密消息的密钥材料。
Because this authentication is quite weak (depending on the use of TLS on three hops) and unverifiable by the endpoints, it is possible that the XMPP working group will integrate some sort of credentials for end recipients, in which case there would need to be a way to associate these credentials with JOSE objects.
由于此身份验证非常弱（取决于三个跃点上TLS的使用）且端点无法验证，因此XMPP工作组可能会为最终收件人集成某种凭据，在这种情况下，需要有一种方法将这些凭据与对象关联。
Finally, it's worth noting that XMPP is based on XML, not JSON. So by using JOSE, XMPP will be carrying JSON objects within XML. It is thus a desirable property for JOSE objects to be encoded in such a way as to be safe for inclusion in XML. Otherwise, an explicit CDATA indication must be given to the parser to indicate that it is not to be parsed as XML. One way to meet this requirement would be to apply base64url encoding, but for XMPP messages of medium-to-large size, this could impose a fair degree of overhead.
最后，值得注意的是，XMPP基于XML，而不是JSON。因此，通过使用JOSE，XMPP将在XML中承载JSON对象。因此，对JOSE对象进行编码，使其能够安全地包含在XML中，这是一个理想的特性。否则，必须向解析器提供显式CDATA指示，以指示它不被解析为XML。满足此要求的一种方法是应用base64url编码，但对于中到大的XMPP消息，这可能会带来相当程度的开销。
Application-Layer Traffic Optimization (ALTO) is a system for distributing network topology information to end devices, so that those devices can modify their behavior to have a lower impact on the network [RFC6708]. The ALTO protocol distributes topology information in the form of JSON objects carried in HTTP [RFC2616] [ALTO]. The basic version of ALTO is simply a client-server protocol, so simple use of HTTPS suffices for this case [RFC2818]. However, there is beginning to be some discussion of use cases for ALTO in which these JSON objects will be distributed through a collection of intermediate servers before reaching the client, while still preserving the ability of the client to authenticate the original source of the object. Even the base ALTO protocol notes that "ALTO Clients obtaining ALTO information through redistribution must be able to validate the received ALTO information" to ensure that it was generated by an appropriate ALTO server.
应用层流量优化（ALTO）是一个将网络拓扑信息分发给终端设备的系统，以便这些设备可以修改其行为以降低对网络的影响[RFC6708]。ALTO协议以HTTP[RFC2616][ALTO]中携带的JSON对象的形式分发拓扑信息。ALTO的基本版本只是一个客户机-服务器协议，因此简单使用HTTPS就足够了[RFC2818]。然而，开始有一些关于ALTO用例的讨论，在这些用例中，这些JSON对象将在到达客户机之前通过一组中间服务器分发，同时仍然保留客户机验证对象原始源的能力。即使是基本ALTO协议也指出，“通过重新分发获得ALTO信息的ALTO客户端必须能够验证收到的ALTO信息”，以确保它是由适当的ALTO服务器生成的。
In this case, the security requirements are straightforward. JOSE objects carrying ALTO payloads will need to bear digital signatures from the originating servers, which will be bound to certificates attesting to the identities of the servers. There is no requirement for confidentiality in this case, since ALTO information is generally public.
在这种情况下，安全需求很简单。承载ALTO有效载荷的JOSE对象需要承载来自原始服务器的数字签名，该签名将绑定到证明服务器身份的证书上。在这种情况下不需要保密，因为ALTO信息通常是公开的。
The more interesting questions are encoding questions. ALTO objects are likely to be much larger than payloads in the two cases above, with sizes of up to several megabytes. Processing of such large objects can be done more quickly if it can be done in a single pass, which may be possible if JOSE objects require specific orderings of fields within the JSON structure.
更有趣的问题是编码问题。在上述两种情况下，ALTO对象可能比有效负载大得多，大小可达数兆字节。如果可以在一次传递中完成，那么可以更快地处理此类大型对象，如果JOSE对象需要JSON结构中字段的特定顺序，这是可能的。
In addition, because ALTO objects are also encoded as JSON, they are already safe for inclusion in a JOSE object. Signed JOSE objects will likely carry the signed data in a string alongside the signature. JSON objects have the property that they can be safely encoded in JSON strings. All they require is that unnecessary white space be removed, a much simpler transformation than, say, base64url encoding. This raises the question of whether it might be possible to optimize the JOSE encoding for certain "JSON-safe" cases.
此外，由于ALTO对象也被编码为JSON，因此它们已经可以安全地包含在JOSE对象中。签名对象可能会在签名旁边以字符串形式携带签名数据。JSON对象具有可以安全地用JSON字符串编码的属性。它们所需要的只是删除不必要的空白，这是一种比base64url编码简单得多的转换。这就提出了一个问题：是否有可能为某些“JSON安全”的情况优化JOSE编码。
Finally, it may be desirable for ALTO to have a "detached signature" mechanism, that is, a way to encode signature information separate from the protected content. This would allow the ALTO protocol to include the signature in an HTTPS header, with the signed content as the HTTPS entity body.
最后，ALTO可能希望具有“分离签名”机制，即，将签名信息编码为独立于受保护内容的方式。这将允许ALTO协议在HTTPS头中包含签名，签名内容作为HTTPS实体体。
Emergency alerting is an emerging use case for IP networks [ALERT-REQ]. Alerting systems allow authorities to warn users of impending danger by sending alert messages to connected devices. For example, in the event of a hurricane or tornado, alerts might be sent to all devices in the path of the storm.
紧急警报是IP网络的一个新兴用例[ALERT-REQ]。警报系统允许当局通过向连接的设备发送警报消息来警告用户即将发生的危险。例如，如果发生飓风或龙卷风，警报可能会发送到风暴路径中的所有设备。
The most critical security requirement for alerting systems is that it must not be possible for an attacker to send false alerts to devices. Such a capability would potentially allow an attacker to create wide-spread panic. In practice, alert systems prevent these attacks both by controls on sending messages at points where alerts are originated, and by having recipients of alerts verify that the alert was sent by an authorized source. The former type of control is implemented with local security on hosts from which alerts can be originated. The latter type is implemented by digital signatures on alert messages (using channel-based or object-based mechanisms). With an object-based mechanism, the signature value is encoded in a secure object. With a channel-based mechanism, the alert is "signed" by virtue of being sent over an authenticated, integrity-protected channel.
警报系统最关键的安全要求是，攻击者不得向设备发送错误警报。这种能力可能会让攻击者造成广泛的恐慌。实际上，警报系统通过控制在发出警报的地点发送消息，以及让警报接收者验证警报是否由授权来源发送，来防止这些攻击。前一种类型的控制是在可以发出警报的主机上通过本地安全性实现的。后一种类型是通过警报消息上的数字签名实现的（使用基于通道或基于对象的机制）。通过基于对象的机制，签名值被编码到安全对象中。通过基于通道的机制，警报通过经过身份验证、完整性保护的通道发送，从而“签名”。
Alerts typically reach end recipients via a series of intermediaries. For example, while a national weather service might originate a hurricane alert, it might first be delivered to a national gateway and then to network operators, who broadcast it to end subscribers.
警报通常通过一系列中介到达最终收件人。例如，虽然国家气象局可能会发出飓风警报，但它可能会首先发送到国家网关，然后发送给网络运营商，由网络运营商向终端用户广播。
+------------+ +------------+ +------------+
| Originator | | Originator | | Originator |
+------------+ +------------+ +------------+
| . .
+-----------------+..................
|
V
+---------+
| Gateway |
+---------+
|
+------------+------------+
| |
V V
+---------+ +---------+
| Network | | Network |
+---------+ +---------+
| |
+------+-----+ +------+-----+
| | | |
V V V V
+--------+ +--------+ +--------+ +--------+
| Device | | Device | | Device | | Device |
+--------+ +--------+ +--------+ +--------+
+------------+ +------------+ +------------+
| Originator | | Originator | | Originator |
+------------+ +------------+ +------------+
| . .
+-----------------+..................
|
V
+---------+
| Gateway |
+---------+
|
+------------+------------+
| |
V V
+---------+ +---------+
| Network | | Network |
+---------+ +---------+
| |
+------+-----+ +------+-----+
| | | |
V V V V
+--------+ +--------+ +--------+ +--------+
| Device | | Device | | Device | | Device |
+--------+ +--------+ +--------+ +--------+
Figure 4: Delivering an Emergency Alert
图4：发布紧急警报
In order to verify alert signatures, recipients must be provisioned with the proper public keys for trusted alert authorities. This trust may be "piece-wise" along the path the alert takes. For example, the alert relays operated by networks might have a full set of certificates for all alert originators, while end devices may only trust their local alert relay. Or, devices might require that a device be signed by an authorized originator and by its local network's relay.
为了验证警报签名，必须为收件人提供受信任警报机构的适当公钥。此信任可能在警报采取的路径上是“分段式”的。例如，由网络操作的警报中继可能具有针对所有警报发起人的全套证书，而终端设备可能仅信任其本地警报中继。或者，设备可能要求设备由授权发起人及其本地网络的中继进行签名。
This scenario creates a need for multiple signatures on alert documents, so that an alert can bear signatures from any or all of the entities that processed it along the path. In order to minimize complexity, these signatures should be "modular" in the sense that a new signature can be added without a need to alter or recompute previous signatures.
此场景需要在警报文档上创建多个签名，以便警报可以包含沿路径处理它的任何或所有实体的签名。为了最小化复杂性，这些签名应该是“模块化”的，即可以添加新签名，而无需更改或重新计算以前的签名。
The W3C Web Cryptography API defines a standard cryptographic API for the Web [WebCrypto]. If a browser exposes this API, then JavaScript provided as part of a Web page can ask the browser to perform cryptographic operations, such as digest, MAC, encryption, or digital signing.
W3C Web加密API为Web定义了标准加密API[WebCryptop]。如果浏览器公开此API，则作为网页一部分提供的JavaScript可以要求浏览器执行加密操作，例如摘要、MAC、加密或数字签名。
One of the key reasons to have the browser perform cryptographic operations is to avoid allowing JavaScript code to access the keying material used for these operations. For example, this separation would prevent code injected through a cross-site scripting (XSS) attack from reading and exfiltrating keys stored within a browser. While the malicious code could still use the key while running in the browser, this vulnerability can only be exercised while the malicious code is active in a user's browser.
让浏览器执行加密操作的关键原因之一是避免允许JavaScript代码访问用于这些操作的密钥材料。例如，这种分离可以防止通过跨站点脚本（XSS）攻击注入的代码读取和过滤存储在浏览器中的密钥。虽然恶意代码在浏览器中运行时仍可能使用密钥，但只有当恶意代码在用户浏览器中处于活动状态时，才能使用此漏洞。
However, the Web Cryptography API also provides a key export functionality, which can allow JavaScript to extract a key from the API in wrapped form. For example, JavaScript code might provide a public key for which the corresponding private key is held by another device. The wrapped key provided by the API could then be used to safely transport the key to the new device. While this could potentially allow malicious code to export a key, the need for an explicit export operation provides a control point, allowing for user notification or consent verification.
但是，Web加密API还提供密钥导出功能，允许JavaScript以包装形式从API中提取密钥。例如，JavaScript代码可能提供一个公钥，另一个设备持有该公钥对应的私钥。然后可以使用API提供的打包密钥将密钥安全地传输到新设备。虽然这可能允许恶意代码导出密钥，但显式导出操作的需要提供了一个控制点，允许用户通知或同意验证。
The Web Cryptography API also allows browsers to impose limitations on the usage of the keys it handles. For example, a symmetric key might be marked as usable only for encryption, and not for MAC. When a key is exported in wrapped form, these attributes should be carried along with it.
Web加密API还允许浏览器对其处理的密钥的使用施加限制。例如，对称密钥可能被标记为仅可用于加密，而不可用于MAC。当以包装形式导出密钥时，这些属性应与密钥一起携带。
The Web Cryptography API thus requires formats to express several forms of keys. Obviously, the public key from an asymmetric key pair can be freely imported to and exported from the browser, so there needs to be a format for public keys. There is also a need for a format to express private keys and symmetric keys. For non-public keys, the primary need is for a wrapped form, where the confidentiality and integrity of the key is assured cryptographically; these protections should also apply to any attributes of the key. It may also be useful to define a direct, unwrapped format for use within a security boundary.
因此，Web加密API需要格式来表示几种形式的密钥。显然，非对称密钥对中的公钥可以自由地导入浏览器或从浏览器导出，因此需要一种公钥格式。还需要一种格式来表示私钥和对称密钥。对于非公开密钥，主要需要一种包装形式，其中密钥的机密性和完整性通过加密方式得到保证；这些保护也应适用于密钥的任何属性。定义在安全边界内使用的直接未包装格式也可能有用。
This section describes use cases for constrained devices as defined in [CONSTRAINED]. Typical issues with this type of device are limited memory, limited power supply, low processing power, and severe message size limitations for the communication protocols.
本节描述了[constrained]中定义的受约束设备的用例。这类设备的典型问题是内存有限、电源有限、处理能力低以及通信协议的严重消息大小限制。
Suppose a small, low power device maker has decided on using the output of the JOSE working group as their encryption and authentication framework. The device maker has a limited budget for both gates and power. For this reason there are a number of short cuts and design decisions that have been made in order to minimize these needs.
假设一家小型低功耗设备制造商决定使用JOSE工作组的输出作为加密和身份验证框架。这家设备制造商在闸门和电源方面的预算有限。出于这个原因，为了最大限度地减少这些需求，已经制定了许多捷径和设计决策。
The design team has determined that the use of MACs is going to be sufficient to provide the necessary authentication. However, although a MAC is going to be used, they do not want to use a single long-term shared secret. Instead, they have adopted the following proposal for computing a shared secret that can be validated:
设计团队已确定，Mac的使用足以提供必要的认证。然而，尽管将使用MAC，但他们不想使用单一的长期共享秘密。相反，他们采用了以下方案来计算可验证的共享秘密：
o An Elliptic-Curve Diffie-Hellman (ECDH) key pair is generated for the device at the time of manufacturing. (Or, as part of the configuration process during installation.)
o 在制造时为设备生成椭圆曲线Diffie-Hellman（ECDH）密钥对。（或者，作为安装期间配置过程的一部分。）
o An ECDH public key for the controller is configured at the time of configuration.
o 在配置时配置控制器的ECDH公钥。
o The configuration system performs the ECDH computation and configures the device with the resulting shared secret. This process eliminates the need for the device to be able to perform the required ECDH processing. The security requirements on protecting this computed shared secret are the same as the requirements on protecting the private ECDH key.
o 配置系统执行ECDH计算，并使用得到的共享密钥配置设备。该过程消除了设备能够执行所需ECDH处理的需要。保护该计算共享秘密的安全要求与保护私有ECDH密钥的要求相同。
o A counter and an increment value are configured onto the device.
o 在设备上配置计数器和增量值。
o When a message is to be sent by the device, the counter is incremented and a new MAC key is computed from the ECDH secret and the counter value. A custom Key Derivation Function (KDF) based on AES-CBC is used to derive the required MAC key. The MAC key is then used to compute the MAC value for the message.
o 当设备发送消息时，计数器递增，并根据ECDH密钥和计数器值计算新的MAC密钥。基于AES-CBC的自定义密钥派生函数（KDF）用于派生所需的MAC密钥。然后使用MAC密钥计算消息的MAC值。
In a similar manner, the KDF function can be used to compute an Authenticated Encryption with Associated Data (AEAD) algorithm key when the system needs to provide confidentiality for the message. The controller, being a larger device, will perform the ECDH step and use a random number generator to generate the sender nonce value.
以类似的方式，当系统需要为消息提供机密性时，KDF函数可用于计算具有关联数据的认证加密（AEAD）算法密钥。控制器是一个较大的设备，将执行ECDH步骤，并使用随机数生成器生成发送方nonce值。
This use case deals with constrained devices of class C0/C1 (see [CONSTRAINED]). These devices communicate using RESTful requests and responses transferred using the Constrained Application Protocol [CoAP]. To simplify matters, all communication is assumed to be unicast; i.e., these security measures don't cover multicast or broadcast.
本用例涉及C0/C1类受约束设备（参见[受约束]）。这些设备使用RESTful请求进行通信，并使用受限应用程序协议[CoAP]传输响应。为了简化问题，假设所有通信都是单播的；i、 例如，这些安全措施不包括多播或广播。
In this type of setting, it may be too costly to use session-based security (e.g., to run a 4-pass authentication protocol) since receiving and in particular sending consumes a lot of power, especially for wireless devices. Therefore, to just secure the CoAP payload by replacing a plaintext payload of a request or response with a JWE object is an important alternative solution, which allows a trade-off between protection (the CoAP headers are not protected) and performance.
在这种类型的设置中，使用基于会话的安全性（例如，运行4-pass身份验证协议）可能代价太高，因为接收，特别是发送，消耗大量电力，尤其是对于无线设备。因此，通过用JWE对象替换请求或响应的明文负载来保护CoAP负载是一个重要的替代解决方案，它允许在保护（CoAP头不受保护）和性能之间进行权衡。
In a simple setting, consider the payload of a CoAP GET response from a sensor type device. The information in a sensor reading may be privacy or business sensitive and needs both integrity protection and encryption.
在一个简单的设置中，考虑来自传感器类型设备的COAP GET响应的有效载荷。传感器读数中的信息可能对隐私或业务敏感，需要完整性保护和加密。
However, some sensor readings are very short, say, a few bytes, and in this case, default encryption and integrity protection algorithms (such as 128-bit AES-CBC with HMAC_SHA256) may cause a dramatic expansion of the payload, even disregarding JWE headers.
然而，一些传感器读数非常短，比如说几个字节，在这种情况下，默认的加密和完整性保护算法（例如带有HMAC_SHA256的128位AES-CBC）可能会导致有效负载的急剧扩展，甚至忽略JWE头。
Also, the value of certain sensor readings may decline rapidly, e.g., traffic or environmental measurements, so it must be possible to reduce the security overhead.
此外，某些传感器读数的值可能会迅速下降，例如交通或环境测量，因此必须能够减少安全开销。
This leads to the following requirements that could be covered by specific JWE/JWS profiles:
这导致了特定JWE/JWS概要文件可能涵盖的以下需求：
o The size of the secure object shall be as small as possible. Receiving an object may cost orders of magnitude more in terms of power than performing, say, public key cryptography on the object, in particular in a wireless setting.
o 安全物体的尺寸应尽可能小。在功率方面，接收对象的成本可能比在对象上执行公钥加密（例如）高出几个数量级，特别是在无线设置中。
o Integrity protection: The object shall be able to support integrity protection, i.e., have a field containing a digital signature, both public key signatures and keyed MACs shall be supported.
o 完整性保护：对象应能够支持完整性保护，即具有包含数字签名的字段，应支持公钥签名和密钥MAC。
o Encryption: The object shall be able to support encryption as an optional addition to integrity protection. It shall be possible to exclude certain fields from encryption, which are needed before verifying integrity or decrypting the object.
o 加密：对象应能够支持加密，作为完整性保护的可选补充。在验证完整性或解密对象之前，可以将某些字段从加密中排除。
o Cipher suites: It should be possible to support a variety of cipher suites to support the constrained devices' use cases. For example:
o 密码套件：应该可以支持各种密码套件来支持受约束设备的用例。例如：
* Block ciphers with block sizes of, e.g., 96 bits, in addition to the standard 128 bits.
* 除标准128位外，块大小为96位的分组密码。
* Modes of operation for block ciphers that do not expand the message size to a block boundary, such as AES-GCM.
* 不将消息大小扩展到块边界的块密码的操作模式，如AES-GCM。
* Cipher suites that support combined encryption and MAC calculation (i.e., AEAD modes for block ciphers).
* 支持组合加密和MAC计算的密码套件（即分组密码的AEAD模式）。
This section summarizes the requirements from the above use cases and lists further requirements not directly derived from the above use cases. There are also some constraints that are not hard requirements but that are still desirable properties for the JOSE system to have.
本节总结了来自上述用例的需求，并列出了并非直接来自上述用例的进一步需求。还有一些约束不是硬性要求，但仍然是JOSE系统所需要的特性。
F1 Define formats for secure objects that provide the following security properties:
F1为提供以下安全属性的安全对象定义格式：
* Digital signature (integrity/authentication under an asymmetric key pair)
* 数字签名（非对称密钥对下的完整性/身份验证）
* Message authentication (integrity/authentication under a symmetric key)
* 消息身份验证（完整性/对称密钥下的身份验证）
* Authenticated encryption
* 认证加密
F2 Define a format for public keys and private keys for asymmetric cryptographic algorithms, with associated attributes, including a wrapped form for private keys.
为非对称加密算法定义公钥和私钥的格式，以及相关属性，包括私钥的包装形式。
F3 Define a format for symmetric keys with associated attributes, allowing for both wrapped and unwrapped keys.
F3为具有关联属性的对称密钥定义一种格式，同时允许已包装和未包装密钥。
F4 Define a JSON serialization for each of the above objects. An object in this encoding must be valid according to the JSON ABNF syntax [RFC7159].
F4为上述每个对象定义JSON序列化。根据JSON ABNF语法[RFC7159]，此编码中的对象必须有效。
F5 Define a compact, URL-safe text serialization for the encrypted and signed object formats.
F5为加密和签名的对象格式定义紧凑、URL安全的文本序列化。
F6 Allow for attributes associated to wrapped keys to be bound to them cryptographically.
F6允许以加密方式将与包装密钥关联的属性绑定到它们。
F7 Allow for wrapped keys to be separated from a secure object that uses a symmetric key. In such cases, cryptographic components of the secure object other than the wrapped key (e.g., ciphertext, MAC values) must be independent of the wrapped form of the key. For example, if an encrypted object is prepared for multiple recipients, then only the wrapped key may vary, not the ciphertext.
F7允许包装的密钥与使用对称密钥的安全对象分离。在这种情况下，安全对象的加密组件（包装密钥除外）（例如，密文、MAC值）必须独立于密钥的包装形式。例如，如果为多个收件人准备了一个加密对象，则只有包装的密钥可能会变化，而不是密文。
F8 Do not impose more overhead than is required to meet the requirements in this document, especially when a large amount of application content is being protected.
F8不要施加超过满足本文档要求所需的额外开销，尤其是当大量应用程序内容受到保护时。
S1 Provide mechanisms to avoid repeated use of the same symmetric key for encryption or MAC computation. Instead, long-lived keys should be used only for key wrapping, not for direct encryption/ MAC. It should be possible to use any of the key management techniques provided in CMS [RFC5652]:
S1提供了避免重复使用相同对称密钥进行加密或MAC计算的机制。相反，长寿命密钥应仅用于密钥包装，而不用于直接加密/MAC。应该可以使用CMS[RFC5652]中提供的任何密钥管理技术：
* Key transport (wrapping for a public key)
* 密钥传输（包装公钥）
* Key encipherment (wrapping for a symmetric key)
* 密钥加密（对称密钥的换行）
* Key agreement (wrapping for a Diffie-Hellman (DH) public key)
* 密钥协议（包装Diffie-Hellman（DH）公钥）
* Password-based encryption (wrapping under a key derived from a password)
* 基于密码的加密（包装在从密码派生的密钥下）
S2 Where long-lived symmetric keys are used directly for cryptographic operations (i.e., where requirement S1 is not met), provide deployment guidance on key management practices, such as the need to limit key lifetimes.
S2如果长寿命对称密钥直接用于加密操作（即，未满足要求S1），则提供密钥管理实践的部署指南，例如需要限制密钥寿命。
S3 Use cryptographic algorithms in a manner compatible with major validation processes. For example, if typical validation standards allow algorithm A to be used for purpose X but not purpose Y, then JOSE should not recommend using algorithm A for purpose Y.
S3以与主要验证过程兼容的方式使用加密算法。例如，如果典型的验证标准允许将算法A用于目的X而不是目的Y，则JOSE不应建议将算法A用于目的Y。
S4 Support operation with or without pre-negotiation. It must be possible to create or process secure objects without any configuration beyond key provisioning. If it is possible for keys to be derived from application context, it must be possible for a recipient to recognize when it does not have the appropriate key.
S4支持有或无预协商的操作。必须能够创建或处理安全对象，而无需密钥配置以外的任何配置。如果可以从应用程序上下文派生密钥，则接收方必须能够识别何时没有适当的密钥。
D1 Maximize compatibility with the W3C Web Crypto specifications, e.g., by coordinating with the Web Crypto working group to encourage alignment of algorithms and algorithm identifiers.
D1最大限度地提高与W3C Web Crypto规范的兼容性，例如，通过与Web Crypto工作组协调，鼓励算法和算法标识符的一致性。
D2 Avoid JSON canonicalization to the extent possible. That is, all other things being equal, techniques that rely on fixing a serialization of an object (e.g., by encoding it with base64url) are preferred over those that require converting an object to a canonical form.
D2尽可能避免JSON规范化。也就是说，在所有其他条件相同的情况下，依赖于修复对象序列化的技术（例如，通过使用base64url对其进行编码）比需要将对象转换为规范形式的技术更受欢迎。
D3 Maximize the extent to which the inputs and outputs of JOSE cryptographic operations can be controlled by the applications, as opposed to involving processing specific to JOSE. This allows JOSE the flexibility to address the needs of many cryptographic protocols. For example, in some cases, it might allow JOSE objects to be translated to legacy formats such as CMS without the need for re-encryption or re-signing.
D3最大化JOSE加密操作的输入和输出可由应用程序控制的程度，而不是涉及特定于JOSE的处理。这使得JOSE能够灵活地满足许多加密协议的需要。例如，在某些情况下，它可能允许将JOSE对象转换为CMS等传统格式，而无需重新加密或重新签名。
The primary focus of this document is the requirements for a JSON-based secure object format. At the level of general security considerations for object-based security technologies, the security considerations for this format are the same as for CMS [RFC5652]. The primary difference between the JOSE format and CMS is that JOSE is based on JSON, which does not have a canonical representation. The lack of a canonical form means that it is difficult to determine whether two JSON objects represent the same information, which could lead to vulnerabilities in some usages of JOSE.
本文档的主要重点是对基于JSON的安全对象格式的要求。在基于对象的安全技术的一般安全注意事项层面上，此格式的安全注意事项与CMS[RFC5652]相同。JOSE格式和CMS之间的主要区别在于JOSE基于JSON，而JSON没有规范表示。缺少规范形式意味着很难确定两个JSON对象是否代表相同的信息，这可能会导致某些JSON用法中存在漏洞。
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007.
[RFC4949]Shirey，R.，“互联网安全术语表，第2版”，RFC 49492007年8月。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
[RFC5652]Housley，R.，“加密消息语法（CMS）”，STD 70，RFC 56522009年9月。
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011.
[RFC6120]Saint Andre，P.，“可扩展消息和状态协议（XMPP）：核心”，RFC61202011年3月。
[RFC6708] Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and Y. Yang, "Application-Layer Traffic Optimization (ALTO) Requirements", RFC 6708, September 2012.
[RFC6708]Kiesel，S.，Previdi，S.，Stiemering，M.，Woundy，R.，和Y.Yang，“应用层流量优化（ALTO）要求”，RFC 67082012年9月。
[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 6749, October 2012.
[RFC6749]Hardt，D.，“OAuth 2.0授权框架”，RFC 6749，2012年10月。
[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, March 2014.
[RFC7159]Bray，T.，“JavaScript对象表示法（JSON）数据交换格式”，RFC 7159，2014年3月。
[W3C.REC-xml] Bray, T., Maler, E., Paoli, J., and C. Sperberg-McQueen, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", W3C Recommendation, November 2008, <http://www.w3.org/TR/2008/REC-xml-20081126/>.
[W3C.REC xml]Bray，T.，Maler，E.，Paoli，J.，和C.Sperberg McQueen，“可扩展标记语言（xml）1.0（第五版）”，W3C建议，2008年11月<http://www.w3.org/TR/2008/REC-xml-20081126/>.
[WebCrypto] Dahl, D. and R. Sleevi, "Web Cryptography API", W3C Working Draft, January 2013, <http://www.w3.org/TR/2013/WD-WebCryptoAPI-20130108/>.
[WebCrypto]Dahl，D.和R.Sleveti，“网络加密API”，W3C工作草案，2013年1月<http://www.w3.org/TR/2013/WD-WebCryptoAPI-20130108/>.
[ALERT-REQ] Schulzrinne, H., Norreys, S., Rosen, B., and H. Tschofenig, "Requirements, Terminology and Framework for Exigent Communications", Work in Progress, March 2012.
[ALERT-REQ]Schulzrinne，H.，Norreys，S.，Rosen，B.，和H.Tschofenig，“紧急通信的要求、术语和框架”，正在进行的工作，2012年3月。
[ALTO] Alimi, R., Ed., Penno, R., Ed., and Y. Yang, Ed., "ALTO Protocol", Work in Progress, March 2014.
[ALTO]Alimi，R.，Ed.，Penno，R.，Ed.，和Y.Yang，Ed.，“ALTO协议”，正在进行的工作，2014年3月。
[CAP] Botterell, A. and E. Jones, "Common Alerting Protocol, v1.1", OASIS Standard CAP-V1.1, October 2005, <http://www.oasis-open.org/committees/download.php/15135/ emergency-CAPv1.1-Corrected_DOM.pdf>.
[CAP]Botterell，A.和E.Jones，“通用警报协议，v1.1”，绿洲标准CAP-v1.1，2005年10月<http://www.oasis-open.org/committees/download.php/15135/ emergency-CAPv1.1-Corrected_DOM.pdf>。
[CONSTRAINED] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained Node Networks", Work in Progress, March 2014.
[受限]Bormann，C.，Ersue，M.和A.Keranen，“受限节点网络的术语”，正在进行的工作，2014年3月。
[CoAP] Shelby, Z., Hartke, K., and C. Bormann, "Constrained Application Protocol (CoAP)", Work in Progress, June 2013.
[CoAP]Shelby，Z.，Hartke，K.，和C.Bormann，“受限应用协议（CoAP）”，正在进行的工作，2013年6月。
[ITU.X690.2002] International Telecommunications Union, "Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, July 2002.
[ITU.X690.2002]国际电信联盟，“信息技术-ASN.1编码规则：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）的规范”，ITU-T建议X.690，2002年7月。
[JWA] Jones, M., "JSON Web Algorithms (JWA)", Work in Progress, March 2014.
[JWA]Jones，M.，“JSON Web算法（JWA）”，正在进行的工作，2014年3月。
[JWE] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", Work in Progress, March 2014.
[JWE]Jones，M.和J.Hildebrand，“JSON Web加密（JWE）”，正在进行的工作，2014年3月。
[JWK] Jones, M., "JSON Web Key (JWK)", Work in Progress, March 2014.
[JWK]Jones，M.，“JSON Web密钥（JWK）”，正在进行的工作，2014年3月。
[JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", Work in Progress, March 2014.
[JWS]Jones，M.，Bradley，J.，和N.Sakimura，“JSON网络签名（JWS）”，正在进行的工作，2014年3月。
[JWT-BEARER] Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants", Work in Progress, March 2014.
[JWT-Bearner]Jones，M.，Campbell，B.，和C.Mortimore，“OAuth 2.0客户端身份验证和授权授权的JSON Web令牌（JWT）配置文件”，正在进行的工作，2014年3月。
[JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", Work in Progress, March 2014.
[JWT]Jones，M.，Bradley，J.，和N.Sakimura，“JSON网络令牌（JWT）”，正在进行的工作，2014年3月。
[OASIS.saml-core-2.0-os] Cantor, S., Kemp, J., Maler, E., and R. Philpott, "Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0", Oasis Standard, March 2005, <http://docs.oasis-open.org/security/saml/v2.0/ saml-core-2.0-os.pdf>.
[OASIS.saml-core-2.0-os]Cantor，S.，Kemp，J.，Maler，E.，和R.Philpott，“OASIS安全断言标记语言（saml）V2.0的断言和协议”，OASIS标准，2005年3月<http://docs.oasis-open.org/security/saml/v2.0/ saml-core-2.0-os.pdf>。
[OpenID.Core] Bradley, J., de Medeiros, B., Jones, M., Mortimore, C., and N. Sakimura, "OpenID Connect Core 1.0", December 2013, <http://openid.net/specs/openid-connect-core-1_0.html>.
[OpenID.Core]Bradley，J.，de Medeiros，B.，Jones，M.，Mortimore，C.，和N.Sakimura，“OpenID连接核心1.0”，2013年12月<http://openid.net/specs/openid-connect-core-1_0.html>.
[Persona] Mozilla Developer Network, "Mozilla Persona", April 2013, <https://developer.mozilla.org/en-US/docs/Persona>.
[Persona]Mozilla开发者网络，“Mozilla Persona”，2013年4月<https://developer.mozilla.org/en-US/docs/Persona>.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC2818，2000年5月。
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.
[RFC3207]Hoffman，P.，“传输层安全SMTP的SMTP服务扩展”，RFC3207，2002年2月。
[RFC3923] Saint-Andre, P., "End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP)", RFC 3923, October 2004.
[RFC3923]Saint Andre，P.，“可扩展消息和状态协议（XMPP）的端到端签名和对象加密”，RFC 39232004年10月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC4648]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC4648，2006年10月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322]Resnick，P.，Ed.“互联网信息格式”，RFC5222008年10月。
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[RFC5751]Ramsdell，B.和S.Turner，“安全/多用途Internet邮件扩展（S/MIME）版本3.2消息规范”，RFC 57512010年1月。
[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, October 2012.
[RFC6750]Jones，M.和D.Hardt，“OAuth 2.0授权框架：承载令牌使用”，RFC 67502012年10月。
[SAML2] Campbell, B., Mortimore, C., and M. Jones, "SAML 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants", Work in Progress, March 2014.
[SAML2]Campbell，B.，Mortimore，C.，和M.Jones，“OAuth 2.0客户端身份验证和授权授权的SAML 2.0配置文件”，正在进行的工作，2014年3月。
[W3C.xmldsig-core] Eastlake, D., Reagle, J., and D. Solo, "XML-Signature Syntax and Processing", W3C Recommendation, June 2008, <http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/>.
[W3C.xmldsig core]Eastlake，D.，Reagle，J.，和D.Solo，“XML签名语法和处理”，W3C建议，2008年6月<http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/>.
[W3C.xmlenc-core] Eastlake, D. and J. Reagle, "XML Encryption Syntax and Processing", W3C Candidate Recommendation, December 2002, <http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/>.
[W3C.xmlenc core]Eastlake，D.和J.Reagle，“XML加密语法和处理”，W3C候选推荐，2002年12月<http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/>.
[WS-Federation] Goodner, M., Kaler, C., McIntosh, M., and A. Nadalin, "Web Services Federation Language (WS-Federation) Version 1.2", Oasis Standard, May 2009, <http://docs.oasis-open.org/ wsfed/federation/v1.2/os/ws-federation-1.2-spec-os.html>.
[WS-Federation]Goodner，M.，Kaler，C.，McIntosh，M.，和A.Nadalin，“Web服务联合语言（WS-Federation）版本1.2”，Oasis标准，2009年5月<http://docs.oasis-open.org/ wsfed/federation/v1.2/os/ws-federation-1.2-spec-os.html>。
[XMPP-E2E] Miller, M., "End-to-End Object Encryption and Signatures for the Extensible Messaging and Presence Protocol (XMPP)", Work in Progress, June 2013.
[XMPP-E2E]Miller，M.，“可扩展消息和状态协议（XMPP）的端到端对象加密和签名”，正在进行的工作，2013年6月。
Thanks to Matt Miller for discussions related to the XMPP end-to-end security model and to Mike Jones for considerations related to security tokens and XML security. Thanks to Mark Watson for raising the need for representing symmetric keys and binding attributes to them. Thanks to Ludwig Seitz for contributing the constrained device use case.
感谢Matt Miller对XMPP端到端安全模型的讨论，以及Mike Jones对安全令牌和XML安全性的考虑。感谢MarkWatson提出了表示对称密钥和向其绑定属性的需求。感谢Ludwig Seitz对受限设备用例的贡献。
Author's Address
作者地址
Richard Barnes Mozilla 331 E. Evelyn Ave. Mountain View, CA 94041 US
Richard Barnes Mozilla美国加利福尼亚州山景城伊夫林大道东331号，邮编94041
EMail: rlb@ipv.sx
EMail: rlb@ipv.sx