Internet Engineering Task Force (IETF) G. Selander
Request for Comments: 8613 J. Mattsson
Updates: 7252 F. Palombini
Category: Standards Track Ericsson AB
ISSN: 2070-1721 L. Seitz
RISE
July 2019
Internet Engineering Task Force (IETF) G. Selander
Request for Comments: 8613 J. Mattsson
Updates: 7252 F. Palombini
Category: Standards Track Ericsson AB
ISSN: 2070-1721 L. Seitz
RISE
July 2019
Object Security for Constrained RESTful Environments (OSCORE)
受限RESTful环境的对象安全性（OSCORE）
Abstract
摘要
This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols.
本文档定义了受限RESTful环境的对象安全性（OSCORE），这是一种使用CBOR对象签名和加密（COSE）对受限应用程序协议（CoAP）进行应用层保护的方法。OSCORE在使用CoAP或CoAP可映射HTTP进行通信的端点之间提供端到端保护。OSCORE设计用于支持一系列代理操作的受限节点和网络，包括不同传输协议之间的转换。
Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration. Therefore, this document updates RFC 7252.
尽管是CoAP的可选功能，但OSCORE改变了CoAP选项处理和IANA注册。因此，本文件更新了RFC 7252。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8613.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8613.
Copyright Notice
版权公告
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
版权（c）2019 IETF信托基金和被确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
2. The OSCORE Option . . . . . . . . . . . . . . . . . . . . . . 8
3. The Security Context . . . . . . . . . . . . . . . . . . . . 8
3.1. Security Context Definition . . . . . . . . . . . . . . . 9
3.2. Establishment of Security Context Parameters . . . . . . 11
3.3. Requirements on the Security Context Parameters . . . . . 14
4. Protected Message Fields . . . . . . . . . . . . . . . . . . 15
4.1. CoAP Options . . . . . . . . . . . . . . . . . . . . . . 16
4.2. CoAP Header Fields and Payload . . . . . . . . . . . . . 24
4.3. Signaling Messages . . . . . . . . . . . . . . . . . . . 25
5. The COSE Object . . . . . . . . . . . . . . . . . . . . . . . 26
5.1. ID Context and 'kid context' . . . . . . . . . . . . . . 27
5.2. AEAD Nonce . . . . . . . . . . . . . . . . . . . . . . . 28
5.3. Plaintext . . . . . . . . . . . . . . . . . . . . . . . . 29
5.4. Additional Authenticated Data . . . . . . . . . . . . . . 30
6. OSCORE Header Compression . . . . . . . . . . . . . . . . . . 31
6.1. Encoding of the OSCORE Option Value . . . . . . . . . . . 32
6.2. Encoding of the OSCORE Payload . . . . . . . . . . . . . 33
6.3. Examples of Compressed COSE Objects . . . . . . . . . . . 33
7. Message Binding, Sequence Numbers, Freshness, and Replay
Protection . . . . . . . . . . . . . . . . . . . . . . . . . 36
7.1. Message Binding . . . . . . . . . . . . . . . . . . . . . 36
7.2. Sequence Numbers . . . . . . . . . . . . . . . . . . . . 36
7.3. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 36
7.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 37
7.5. Losing Part of the Context State . . . . . . . . . . . . 38
8. Processing . . . . . . . . . . . . . . . . . . . . . . . . . 39
8.1. Protecting the Request . . . . . . . . . . . . . . . . . 39
8.2. Verifying the Request . . . . . . . . . . . . . . . . . . 40
8.3. Protecting the Response . . . . . . . . . . . . . . . . . 41
8.4. Verifying the Response . . . . . . . . . . . . . . . . . 43
9. Web Linking . . . . . . . . . . . . . . . . . . . . . . . . . 44
10. CoAP-to-CoAP Forwarding Proxy . . . . . . . . . . . . . . . . 45
11. HTTP Operations . . . . . . . . . . . . . . . . . . . . . . . 46
11.1. The HTTP OSCORE Header Field . . . . . . . . . . . . . . 46
11.2. CoAP-to-HTTP Mapping . . . . . . . . . . . . . . . . . . 47
11.3. HTTP-to-CoAP Mapping . . . . . . . . . . . . . . . . . . 48
11.4. HTTP Endpoints . . . . . . . . . . . . . . . . . . . . . 48
11.5. Example: HTTP Client and CoAP Server . . . . . . . . . . 48
11.6. Example: CoAP Client and HTTP Server . . . . . . . . . . 50
12. Security Considerations . . . . . . . . . . . . . . . . . . . 51
12.1. End-to-end Protection . . . . . . . . . . . . . . . . . 51
12.2. Security Context Establishment . . . . . . . . . . . . . 52
12.3. Master Secret . . . . . . . . . . . . . . . . . . . . . 52
12.4. Replay Protection . . . . . . . . . . . . . . . . . . . 53
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
2. The OSCORE Option . . . . . . . . . . . . . . . . . . . . . . 8
3. The Security Context . . . . . . . . . . . . . . . . . . . . 8
3.1. Security Context Definition . . . . . . . . . . . . . . . 9
3.2. Establishment of Security Context Parameters . . . . . . 11
3.3. Requirements on the Security Context Parameters . . . . . 14
4. Protected Message Fields . . . . . . . . . . . . . . . . . . 15
4.1. CoAP Options . . . . . . . . . . . . . . . . . . . . . . 16
4.2. CoAP Header Fields and Payload . . . . . . . . . . . . . 24
4.3. Signaling Messages . . . . . . . . . . . . . . . . . . . 25
5. The COSE Object . . . . . . . . . . . . . . . . . . . . . . . 26
5.1. ID Context and 'kid context' . . . . . . . . . . . . . . 27
5.2. AEAD Nonce . . . . . . . . . . . . . . . . . . . . . . . 28
5.3. Plaintext . . . . . . . . . . . . . . . . . . . . . . . . 29
5.4. Additional Authenticated Data . . . . . . . . . . . . . . 30
6. OSCORE Header Compression . . . . . . . . . . . . . . . . . . 31
6.1. Encoding of the OSCORE Option Value . . . . . . . . . . . 32
6.2. Encoding of the OSCORE Payload . . . . . . . . . . . . . 33
6.3. Examples of Compressed COSE Objects . . . . . . . . . . . 33
7. Message Binding, Sequence Numbers, Freshness, and Replay
Protection . . . . . . . . . . . . . . . . . . . . . . . . . 36
7.1. Message Binding . . . . . . . . . . . . . . . . . . . . . 36
7.2. Sequence Numbers . . . . . . . . . . . . . . . . . . . . 36
7.3. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 36
7.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 37
7.5. Losing Part of the Context State . . . . . . . . . . . . 38
8. Processing . . . . . . . . . . . . . . . . . . . . . . . . . 39
8.1. Protecting the Request . . . . . . . . . . . . . . . . . 39
8.2. Verifying the Request . . . . . . . . . . . . . . . . . . 40
8.3. Protecting the Response . . . . . . . . . . . . . . . . . 41
8.4. Verifying the Response . . . . . . . . . . . . . . . . . 43
9. Web Linking . . . . . . . . . . . . . . . . . . . . . . . . . 44
10. CoAP-to-CoAP Forwarding Proxy . . . . . . . . . . . . . . . . 45
11. HTTP Operations . . . . . . . . . . . . . . . . . . . . . . . 46
11.1. The HTTP OSCORE Header Field . . . . . . . . . . . . . . 46
11.2. CoAP-to-HTTP Mapping . . . . . . . . . . . . . . . . . . 47
11.3. HTTP-to-CoAP Mapping . . . . . . . . . . . . . . . . . . 48
11.4. HTTP Endpoints . . . . . . . . . . . . . . . . . . . . . 48
11.5. Example: HTTP Client and CoAP Server . . . . . . . . . . 48
11.6. Example: CoAP Client and HTTP Server . . . . . . . . . . 50
12. Security Considerations . . . . . . . . . . . . . . . . . . . 51
12.1. End-to-end Protection . . . . . . . . . . . . . . . . . 51
12.2. Security Context Establishment . . . . . . . . . . . . . 52
12.3. Master Secret . . . . . . . . . . . . . . . . . . . . . 52
12.4. Replay Protection . . . . . . . . . . . . . . . . . . . 53
12.5. Client Aliveness . . . . . . . . . . . . . . . . . . . . 53
12.6. Cryptographic Considerations . . . . . . . . . . . . . . 53
12.7. Message Segmentation . . . . . . . . . . . . . . . . . . 54
12.8. Privacy Considerations . . . . . . . . . . . . . . . . . 54
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55
13.1. COSE Header Parameters Registry . . . . . . . . . . . . 55
13.2. CoAP Option Numbers Registry . . . . . . . . . . . . . . 55
13.3. CoAP Signaling Option Numbers Registry . . . . . . . . . 56
13.4. Header Field Registrations . . . . . . . . . . . . . . . 57
13.5. Media Type Registration . . . . . . . . . . . . . . . . 57
13.6. CoAP Content-Formats Registry . . . . . . . . . . . . . 58
13.7. OSCORE Flag Bits Registry . . . . . . . . . . . . . . . 58
13.8. Expert Review Instructions . . . . . . . . . . . . . . . 59
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 60
14.1. Normative References . . . . . . . . . . . . . . . . . . 60
14.2. Informative References . . . . . . . . . . . . . . . . . 62
Appendix A. Scenario Examples . . . . . . . . . . . . . . . . . 65
A.1. Secure Access to Sensor . . . . . . . . . . . . . . . . . 65
A.2. Secure Subscribe to Sensor . . . . . . . . . . . . . . . 66
Appendix B. Deployment Examples . . . . . . . . . . . . . . . . 68
B.1. Security Context Derived Once . . . . . . . . . . . . . . 68
B.2. Security Context Derived Multiple Times . . . . . . . . . 70
Appendix C. Test Vectors . . . . . . . . . . . . . . . . . . . . 75
C.1. Test Vector 1: Key Derivation with Master Salt . . . . . 75
C.2. Test Vector 2: Key Derivation without Master Salt . . . . 77
C.3. Test Vector 3: Key Derivation with ID Context . . . . . . 78
C.4. Test Vector 4: OSCORE Request, Client . . . . . . . . . . 80
C.5. Test Vector 5: OSCORE Request, Client . . . . . . . . . . 81
C.6. Test Vector 6: OSCORE Request, Client . . . . . . . . . . 82
C.7. Test Vector 7: OSCORE Response, Server . . . . . . . . . 84
C.8. Test Vector 8: OSCORE Response with Partial IV, Server . 85
Appendix D. Overview of Security Properties . . . . . . . . . . 86
D.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 86
D.2. Supporting Proxy Operations . . . . . . . . . . . . . . . 87
D.3. Protected Message Fields . . . . . . . . . . . . . . . . 87
D.4. Uniqueness of (key, nonce) . . . . . . . . . . . . . . . 88
D.5. Unprotected Message Fields . . . . . . . . . . . . . . . 89
Appendix E. CDDL Summary . . . . . . . . . . . . . . . . . . . . 93
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 94
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 94
12.5. Client Aliveness . . . . . . . . . . . . . . . . . . . . 53
12.6. Cryptographic Considerations . . . . . . . . . . . . . . 53
12.7. Message Segmentation . . . . . . . . . . . . . . . . . . 54
12.8. Privacy Considerations . . . . . . . . . . . . . . . . . 54
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55
13.1. COSE Header Parameters Registry . . . . . . . . . . . . 55
13.2. CoAP Option Numbers Registry . . . . . . . . . . . . . . 55
13.3. CoAP Signaling Option Numbers Registry . . . . . . . . . 56
13.4. Header Field Registrations . . . . . . . . . . . . . . . 57
13.5. Media Type Registration . . . . . . . . . . . . . . . . 57
13.6. CoAP Content-Formats Registry . . . . . . . . . . . . . 58
13.7. OSCORE Flag Bits Registry . . . . . . . . . . . . . . . 58
13.8. Expert Review Instructions . . . . . . . . . . . . . . . 59
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 60
14.1. Normative References . . . . . . . . . . . . . . . . . . 60
14.2. Informative References . . . . . . . . . . . . . . . . . 62
Appendix A. Scenario Examples . . . . . . . . . . . . . . . . . 65
A.1. Secure Access to Sensor . . . . . . . . . . . . . . . . . 65
A.2. Secure Subscribe to Sensor . . . . . . . . . . . . . . . 66
Appendix B. Deployment Examples . . . . . . . . . . . . . . . . 68
B.1. Security Context Derived Once . . . . . . . . . . . . . . 68
B.2. Security Context Derived Multiple Times . . . . . . . . . 70
Appendix C. Test Vectors . . . . . . . . . . . . . . . . . . . . 75
C.1. Test Vector 1: Key Derivation with Master Salt . . . . . 75
C.2. Test Vector 2: Key Derivation without Master Salt . . . . 77
C.3. Test Vector 3: Key Derivation with ID Context . . . . . . 78
C.4. Test Vector 4: OSCORE Request, Client . . . . . . . . . . 80
C.5. Test Vector 5: OSCORE Request, Client . . . . . . . . . . 81
C.6. Test Vector 6: OSCORE Request, Client . . . . . . . . . . 82
C.7. Test Vector 7: OSCORE Response, Server . . . . . . . . . 84
C.8. Test Vector 8: OSCORE Response with Partial IV, Server . 85
Appendix D. Overview of Security Properties . . . . . . . . . . 86
D.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 86
D.2. Supporting Proxy Operations . . . . . . . . . . . . . . . 87
D.3. Protected Message Fields . . . . . . . . . . . . . . . . 87
D.4. Uniqueness of (key, nonce) . . . . . . . . . . . . . . . 88
D.5. Unprotected Message Fields . . . . . . . . . . . . . . . 89
Appendix E. CDDL Summary . . . . . . . . . . . . . . . . . . . . 93
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 94
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 94
The Constrained Application Protocol (CoAP) [RFC7252] is a web transfer protocol designed for constrained nodes and networks [RFC7228]; CoAP may be mapped from HTTP [RFC8075]. CoAP specifies the use of proxies for scalability and efficiency and references DTLS [RFC6347] for security. CoAP-to-CoAP, HTTP-to-CoAP, and CoAP-to-HTTP proxies require DTLS or TLS [RFC8446] to be terminated at the proxy. Therefore, the proxy not only has access to the data required for performing the intended proxy functionality, but is also able to eavesdrop on, or manipulate any part of, the message payload and metadata in transit between the endpoints. The proxy can also inject, delete, or reorder packets since they are no longer protected by (D)TLS.
受限应用协议（CoAP）[RFC7252]是为受限节点和网络设计的web传输协议[RFC7228]；CoAP可以从HTTP[RFC8075]映射。CoAP指定使用代理以实现可伸缩性和效率，并参考DTLS[RFC6347]以实现安全性。CoAP到CoAP、HTTP到CoAP和CoAP到HTTP代理要求DTL或TLS[RFC8446]在代理处终止。因此，代理不仅可以访问执行预期代理功能所需的数据，而且还能够窃听或操纵端点之间传输的消息有效负载和元数据的任何部分。代理还可以注入、删除或重新排序数据包，因为它们不再受（D）TLS的保护。
This document defines the Object Security for Constrained RESTful Environments (OSCORE) security protocol, protecting CoAP and CoAP-mappable HTTP requests and responses end-to-end across intermediary nodes such as CoAP forward proxies and cross-protocol translators including HTTP-to-CoAP proxies [RFC8075]. In addition to the core CoAP features defined in [RFC7252], OSCORE supports the Observe [RFC7641], Block-wise [RFC7959], and No-Response [RFC7967] options, as well as the PATCH and FETCH methods [RFC8132]. An analysis of end-to-end security for CoAP messages through some types of intermediary nodes is performed in [CoAP-E2E-Sec]. OSCORE essentially protects the RESTful interactions: the request method, the requested resource, the message payload, etc. (see Section 4), where "RESTful" refers to the Representational State Transfer (REST) Architecture [REST]. OSCORE protects neither the CoAP messaging layer nor the CoAP Token, which may change between the endpoints; therefore, those are processed as defined in [RFC7252]. Additionally, since the message formats for CoAP over unreliable transport [RFC7252] and for CoAP over reliable transport [RFC8323] differ only in terms of CoAP messaging layer, OSCORE can be applied to both unreliable and reliable transports (see Figure 1).
本文档定义了受限RESTful环境（OSCORE）安全协议的对象安全性，保护跨中间节点（如CoAP转发代理和跨协议转换器，包括HTTP到CoAP代理）的端到端的CoAP和CoAP可映射HTTP请求和响应[RFC8075]。除了[RFC7252]中定义的核心CoAP功能外，OSCORE还支持观察[RFC7641]、分块[RFC7959]和无响应[RFC7967]选项，以及修补和获取方法[RFC8132]。[CoAP-E2E-Sec]中对通过某些类型的中间节点的CoAP消息的端到端安全性进行了分析。OSCORE本质上保护RESTful交互：请求方法、请求的资源、消息负载等（参见第4节），其中“RESTful”指的是表示性状态转移（REST）体系结构[REST]。OSCORE既不保护CoAP消息传递层，也不保护CoAP令牌，后者可能在端点之间发生变化；因此，按照[RFC7252]中的定义对其进行处理。此外，由于CoAP over reliable transport[RFC7252]和CoAP over reliable transport[RFC8323]的消息格式仅在CoAP消息层方面不同，因此OSCORE可应用于不可靠和可靠传输（见图1）。
OSCORE works in very constrained nodes and networks, thanks to its small message size and the restricted code and memory requirements in addition to what is required by CoAP. Examples of the use of OSCORE are given in Appendix A. OSCORE may be used over any underlying layer, such as UDP or TCP, and with non-IP transports (e.g., [CoAP-802.15.4]). OSCORE may also be used in different ways with HTTP. OSCORE messages may be transported in HTTP, and OSCORE may also be used to protect CoAP-mappable HTTP messages, as described below.
OSCORE可以在非常受限的节点和网络中工作，这要归功于它的小消息大小和受限的代码和内存需求，以及CoAP所要求的。OSCORE的使用示例见附录A。OSCORE可用于任何底层，如UDP或TCP，以及非IP传输（如[CoAP-802.15.4]）。OSCORE也可以以不同的方式与HTTP一起使用。OSCORE消息可以在HTTP中传输，并且OSCORE还可以用于保护CoAP可映射HTTP消息，如下所述。
+-----------------------------------+
| Application |
+-----------------------------------+
+-----------------------------------+ \
| Requests / Responses / Signaling | |
|-----------------------------------| |
| OSCORE | | CoAP
|-----------------------------------| |
| Messaging Layer / Message Framing | |
+-----------------------------------+ /
+-----------------------------------+
| UDP / TCP / ... |
+-----------------------------------+
+-----------------------------------+
| Application |
+-----------------------------------+
+-----------------------------------+ \
| Requests / Responses / Signaling | |
|-----------------------------------| |
| OSCORE | | CoAP
|-----------------------------------| |
| Messaging Layer / Message Framing | |
+-----------------------------------+ /
+-----------------------------------+
| UDP / TCP / ... |
+-----------------------------------+
Figure 1: Abstract Layering of CoAP with OSCORE
图1:CoAP与OSCORE的抽象分层
OSCORE is designed to protect as much information as possible while still allowing CoAP proxy operations (Section 10). It works with existing CoAP-to-CoAP forward proxies [RFC7252], but an OSCORE-aware proxy will be more efficient. HTTP-to-CoAP proxies [RFC8075] and CoAP-to-HTTP proxies can also be used with OSCORE, as specified in Section 11. OSCORE may be used together with TLS or DTLS over one or more hops in the end-to-end path, e.g., transported with HTTPS in one hop and with plain CoAP in another hop. The use of OSCORE does not affect the URI scheme; therefore, OSCORE can be used with any URI scheme defined for CoAP or HTTP. The application decides the conditions for which OSCORE is required.
OSCORE旨在保护尽可能多的信息，同时仍然允许CoAP代理操作（第10节）。它与现有的CoAP-to-CoAP转发代理一起工作[RFC7252]，但支持OSCORE的代理将更有效。HTTP-to-CoAP代理[RFC8075]和CoAP-to-HTTP代理也可以与OSCORE一起使用，如第11节所述。OSCORE可在端到端路径中的一个或多个跃点上与TLS或DTL一起使用，例如，在一个跃点中使用HTTPS传输，在另一个跃点中使用普通CoAP传输。OSCORE的使用不影响URI方案；因此，OSCORE可以与为CoAP或HTTP定义的任何URI方案一起使用。应用程序决定需要OSCORE的条件。
OSCORE uses pre-shared keys that may have been established out-of-band or with a key establishment protocol (see Section 3.2). The technical solution builds on CBOR Object Signing and Encryption (COSE) [RFC8152], providing end-to-end encryption, integrity, replay protection, and binding of response to request. A compressed version of COSE is used, as specified in Section 6. The use of OSCORE is signaled in CoAP with a new option (Section 2), and in HTTP with a new header field (Section 11.1) and content type (Section 13.5). The solution transforms a CoAP/HTTP message into an "OSCORE message" before sending, and vice versa after receiving. The OSCORE message is a CoAP/HTTP message related to the original message in the following way: the original CoAP/HTTP message is translated to CoAP (if not already in CoAP) and protected in a COSE object. The encrypted message fields of this COSE object are transported in the CoAP payload/HTTP body of the OSCORE message, and the OSCORE option/ header field is included in the message. A sketch of an exchange of OSCORE messages, in the case of the original message being CoAP, is provided in Figure 2. The use of OSCORE with HTTP is detailed in Section 11.
OSCORE使用预先共享的密钥，这些密钥可能是在带外建立的，也可能是通过密钥建立协议建立的（见第3.2节）。该技术解决方案以CBOR对象签名和加密（COSE）[RFC8152]为基础，提供端到端加密、完整性、重播保护和请求响应绑定。按照第6节的规定，使用COSE的压缩版本。OSCORE的使用在CoAP中用一个新选项（第2节）表示，在HTTP中用一个新的头字段（第11.1节）和内容类型（第13.5节）表示。该解决方案在发送前将CoAP/HTTP消息转换为“OSCORE消息”，在接收后将CoAP/HTTP消息转换为“OSCORE消息”。OSCORE消息是与原始消息相关的CoAP/HTTP消息，其方式如下：原始CoAP/HTTP消息被转换为CoAP（如果尚未在CoAP中），并在COSE对象中受到保护。此COSE对象的加密消息字段在OSCORE消息的CoAP有效负载/HTTP正文中传输，并且OSCORE选项/头字段包含在消息中。在原始消息为CoAP的情况下，OSCORE消息交换的示意图如图2所示。第11节详细介绍了OSCORE与HTTP的结合使用。
Client Server
| OSCORE request - POST example.com: |
| Header, Token, |
| Options: OSCORE, ..., |
| Payload: COSE ciphertext |
+--------------------------------------------->|
| |
|<---------------------------------------------+
| OSCORE response - 2.04 (Changed): |
| Header, Token, |
| Options: OSCORE, ..., |
| Payload: COSE ciphertext |
| |
Client Server
| OSCORE request - POST example.com: |
| Header, Token, |
| Options: OSCORE, ..., |
| Payload: COSE ciphertext |
+--------------------------------------------->|
| |
|<---------------------------------------------+
| OSCORE response - 2.04 (Changed): |
| Header, Token, |
| Options: OSCORE, ..., |
| Payload: COSE ciphertext |
| |
Figure 2: Sketch of CoAP with OSCORE
图2：带OSCORE的CoAP示意图
An implementation supporting this specification MAY implement only the client part, MAY implement only the server part, or MAY implement only one of the proxy parts.
支持此规范的实现可以只实现客户端部分，也可以只实现服务器部分，或者只实现一个代理部分。
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]所述进行解释。
Readers are expected to be familiar with the terms and concepts described in CoAP [RFC7252], COSE [RFC8152], Concise Binary Object Representation (CBOR) [RFC7049], Concise Data Definition Language (CDDL) [RFC8610] as summarized in Appendix E, and constrained environments [RFC7228]. Additional optional features include Observe [RFC7641], Block-wise [RFC7959], No-Response [RFC7967] and CoAP over reliable transport [RFC8323].
读者应熟悉CoAP[RFC7252]、COSE[RFC8152]、简明二进制对象表示法（CBOR）[RFC7049]、简明数据定义语言（CDDL）[RFC8610]中描述的术语和概念，如附录E所述，以及约束环境[RFC7228]。其他可选功能包括观察[RFC7641]、分块[RFC7959]、无响应[RFC7967]和CoAP过可靠传输[RFC8323]。
The term "hop" is used to denote a particular leg in the end-to-end path. The concept "hop-by-hop" (as in "hop-by-hop encryption" or "hop-by-hop fragmentation") opposed to "end-to-end", is used in this document to indicate that the messages are processed accordingly in the intermediaries, rather than just forwarded to the next node.
术语“跳跃”用于表示端到端路径中的特定分支。与“端到端”相反的概念“逐跳”（如“逐跳加密”或“逐跳分段”）在本文档中用于指示消息在中介中相应地处理，而不是仅转发到下一个节点。
The term "stop processing" is used throughout the document to denote that the message is not passed up to the CoAP request/response layer (see Figure 1).
在整个文档中使用术语“停止处理”来表示消息没有传递到CoAP请求/响应层（参见图1）。
The terms Common Context, Sender Context, Recipient Context, Master Secret, Master Salt, Sender ID, Sender Key, Recipient ID, Recipient Key, ID Context, and Common IV are defined in Section 3.1.
第3.1节定义了术语公共上下文、发送方上下文、接收方上下文、主密钥、主盐、发送方ID、发送方密钥、接收方ID、接收方密钥、ID上下文和公共IV。
The OSCORE option defined in this section (see Figure 3, which extends "Table 4: Options" of [RFC7252]) indicates that the CoAP message is an OSCORE message and that it contains a compressed COSE object (see Sections 5 and 6). The OSCORE option is critical, safe to forward, part of the cache key, and not repeatable.
本节中定义的OSCORE选项（参见图3，它扩展了[RFC7252]的“表4：选项”）表明CoAP消息是一条OSCORE消息，它包含一个压缩的COSE对象（参见第5节和第6节）。OSCORE选项至关重要，可以安全转发，是缓存密钥的一部分，并且不可重复。
+------+---+---+---+---+----------------+--------+--------+---------+
| No. | C | U | N | R | Name | Format | Length | Default |
+------+---+---+---+---+----------------+--------+--------+---------+
| 9 | x | | | | OSCORE | (*) | 0-255 | (none) |
+------+---+---+---+---+----------------+--------+--------+---------+
+------+---+---+---+---+----------------+--------+--------+---------+
| No. | C | U | N | R | Name | Format | Length | Default |
+------+---+---+---+---+----------------+--------+--------+---------+
| 9 | x | | | | OSCORE | (*) | 0-255 | (none) |
+------+---+---+---+---+----------------+--------+--------+---------+
C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable (*) See below.
C=临界，U=不安全，N=NoCacheKey，R=可重复（*）见下文。
Figure 3: The OSCORE Option
图3：OSCORE选项
The OSCORE option includes the OSCORE flag bits (Section 6), the Sender Sequence Number, the Sender ID, and the ID Context when these fields are present (Section 3). The detailed format and length is specified in Section 6. If the OSCORE flag bits are all zero (0x00), the option value SHALL be empty (Option Length = 0). An endpoint receiving a CoAP message without payload that also contains an OSCORE option SHALL treat it as malformed and reject it.
OSCORE选项包括OSCORE标志位（第6节）、发送方序列号、发送方ID以及存在这些字段时的ID上下文（第3节）。第6节规定了详细的格式和长度。如果OSCORE标志位均为零（0x00），则选项值应为空（选项长度=0）。接收不带有效负载的CoAP消息（也包含OSCORE选项）的端点应将其视为格式错误并拒绝。
A successful response to a request with the OSCORE option SHALL contain the OSCORE option. Whether error responses contain the OSCORE option depends on the error type (see Section 8).
使用OSCORE选项对请求的成功响应应包含OSCORE选项。错误响应是否包含OSCORE选项取决于错误类型（参见第8节）。
For CoAP proxy operations, see Section 10.
有关CoAP代理操作，请参见第10节。
OSCORE requires that client and server establish a shared security context used to process the COSE objects. OSCORE uses COSE with an Authenticated Encryption with Associated Data (AEAD, [RFC5116]) algorithm for protecting message data between a client and a server. In this section, we define the security context and how it is derived in client and server based on a shared secret and a key derivation function.
OSCORE要求客户端和服务器建立用于处理COSE对象的共享安全上下文。OSCORE使用COSE和关联数据的身份验证加密（AEAD，[RFC5116]）算法来保护客户端和服务器之间的消息数据。在本节中，我们将定义安全上下文，以及如何基于共享密钥和密钥派生函数在客户端和服务器中派生安全上下文。
The security context is the set of information elements necessary to carry out the cryptographic operations in OSCORE. For each endpoint, the security context is composed of a "Common Context", a "Sender Context", and a "Recipient Context".
安全上下文是在OSCORE中执行加密操作所必需的一组信息元素。对于每个端点，安全上下文由“公共上下文”、“发送方上下文”和“接收方上下文”组成。
The endpoints protect messages to send using the Sender Context and verify messages received using the Recipient Context; both contexts being derived from the Common Context and other data. Clients and servers need to be able to retrieve the correct security context to use.
端点使用发送方上下文保护要发送的消息，并验证使用接收方上下文接收的消息；这两个上下文都是从公共上下文和其他数据派生的。客户端和服务器需要能够检索要使用的正确安全上下文。
An endpoint uses its Sender ID (SID) to derive its Sender Context; the other endpoint uses the same ID, now called Recipient ID (RID), to derive its Recipient Context. In communication between two endpoints, the Sender Context of one endpoint matches the Recipient Context of the other endpoint, and vice versa. Thus, the two security contexts identified by the same IDs in the two endpoints are not the same, but they are partly mirrored. Retrieval and use of the security context are shown in Figure 4.
端点使用其发送方ID（SID）派生其发送方上下文；另一个端点使用相同的ID（现在称为收件人ID（RID））来派生其收件人上下文。在两个端点之间的通信中，一个端点的发送方上下文与另一个端点的接收方上下文匹配，反之亦然。因此，由两个端点中的相同id标识的两个安全上下文并不相同，但它们是部分镜像的。安全上下文的检索和使用如图4所示。
.---------------------. .---------------------.
| Common Context | = | Common Context |
+---------------------+ +---------------------+
| Sender Context | = | Recipient Context |
+---------------------+ +---------------------+
| Recipient Context | = | Sender Context |
'---------------------' '---------------------'
Client Server
| |
Retrieve context for | OSCORE request: |
target resource | Token = Token1, |
Protect request with | kid = SID, ... |
Sender Context +---------------------->| Retrieve context with
| | RID = kid
| | Verify request with
| | Recipient Context
| OSCORE response: | Protect response with
| Token = Token1, ... | Sender Context
Retrieve context with |<----------------------+
Token = Token1 | |
Verify request with | |
Recipient Context | |
.---------------------. .---------------------.
| Common Context | = | Common Context |
+---------------------+ +---------------------+
| Sender Context | = | Recipient Context |
+---------------------+ +---------------------+
| Recipient Context | = | Sender Context |
'---------------------' '---------------------'
Client Server
| |
Retrieve context for | OSCORE request: |
target resource | Token = Token1, |
Protect request with | kid = SID, ... |
Sender Context +---------------------->| Retrieve context with
| | RID = kid
| | Verify request with
| | Recipient Context
| OSCORE response: | Protect response with
| Token = Token1, ... | Sender Context
Retrieve context with |<----------------------+
Token = Token1 | |
Verify request with | |
Recipient Context | |
Figure 4: Retrieval and Use of the Security Context
图4：安全上下文的检索和使用
The Common Context contains the following parameters:
公共上下文包含以下参数：
o AEAD Algorithm. The COSE AEAD algorithm to use for encryption.
o AEAD算法。用于加密的COSE AEAD算法。
o HKDF Algorithm. An HMAC-based key derivation function (HKDF, [RFC5869]) used to derive the Sender Key, Recipient Key, and Common IV.
o HKDF算法。基于HMAC的密钥派生函数（HKDF，[RFC5869]），用于派生发送方密钥、接收方密钥和公共IV。
o Master Secret. Variable length, random byte string (see Section 12.3) used to derive AEAD keys and Common IV.
o 掌握秘密。用于派生AEAD键和公共IV的可变长度随机字节字符串（见第12.3节）。
o Master Salt. Optional variable-length byte string containing the salt used to derive AEAD keys and Common IV.
o 主盐。可选的可变长度字节字符串，包含用于派生AEAD键和公共IV的salt。
o ID Context. Optional variable-length byte string providing additional information to identify the Common Context and to derive AEAD keys and Common IV. The use of ID Context is described in Section 5.1.
o ID上下文。可选可变长度字节字符串，提供额外信息，以识别公共上下文并派生AEAD密钥和公共IV。第5.1节介绍了ID上下文的使用。
o Common IV. Byte string derived from the Master Secret, Master Salt, and ID Context. Used to generate the AEAD nonce (see Section 5.2). Same length as the nonce of the AEAD Algorithm.
o 从主密钥、主Salt和ID上下文派生的公共IV.字节字符串。用于生成AEAD nonce（参见第5.2节）。与AEAD算法的nonce相同的长度。
The Sender Context contains the following parameters:
发件人上下文包含以下参数：
o Sender ID. Byte string used to identify the Sender Context, to derive AEAD keys and Common IV, and to contribute to the uniqueness of AEAD nonces. Maximum length is determined by the AEAD Algorithm.
o 发送方ID。字节字符串，用于标识发送方上下文，派生AEAD密钥和公共IV，并有助于AEAD nonce的唯一性。最大长度由AEAD算法确定。
o Sender Key. Byte string containing the symmetric AEAD key to protect messages to send. Derived from Common Context and Sender ID. Length is determined by the AEAD Algorithm.
o 发送方密钥。包含对称AEAD密钥的字节字符串，用于保护要发送的消息。从公共上下文和发件人ID派生。长度由AEAD算法确定。
o Sender Sequence Number. Non-negative integer used by the sender to enumerate requests and certain responses, e.g., Observe notifications. Used as "Partial IV" [RFC8152] to generate unique AEAD nonces. Maximum value is determined by the AEAD Algorithm. Initialization is described in Section 3.2.2.
o 发送方序列号。发送方用于枚举请求和某些响应（例如，观察通知）的非负整数。用作“部分IV”[RFC8152]以生成唯一的AEAD时值。最大值由AEAD算法确定。第3.2.2节描述了初始化。
The Recipient Context contains the following parameters:
收件人上下文包含以下参数：
o Recipient ID. Byte string used to identify the Recipient Context, to derive AEAD keys and Common IV, and to contribute to the uniqueness of AEAD nonces. Maximum length is determined by the AEAD Algorithm.
o 收件人ID。字节字符串，用于标识收件人上下文、派生AEAD密钥和Common IV，并有助于AEAD nonce的唯一性。最大长度由AEAD算法确定。
o Recipient Key. Byte string containing the symmetric AEAD key to verify messages received. Derived from Common Context and Recipient ID. Length is determined by the AEAD Algorithm.
o 收件人密钥。包含对称AEAD密钥的字节字符串，用于验证收到的消息。从公共上下文和收件人ID派生。长度由AEAD算法确定。
o Replay Window (Server only). The replay window used to verify requests received. Replay protection is described in Section 7.4 and Section 3.2.2.
o 重播窗口（仅限服务器）。用于验证收到的请求的replay窗口。第7.4节和第3.2.2节描述了重放保护。
All parameters except Sender Sequence Number and Replay Window are immutable once the security context is established. An endpoint may free up memory by not storing the Common IV, Sender Key, and Recipient Key, deriving them when needed. Alternatively, an endpoint may free up memory by not storing the Master Secret and Master Salt after the other parameters have been derived.
一旦建立安全上下文，除发送方序列号和重播窗口外的所有参数都是不可变的。端点可以通过不存储公共IV、发送方密钥和接收方密钥来释放内存，并在需要时派生它们。或者，端点可以通过在导出其他参数之后不存储主秘密和主盐来释放内存。
Endpoints MAY operate as both client and server and use the same security context for those roles. Independent of being client or server, the endpoint protects messages to send using its Sender Context, and verifies messages received using its Recipient Context. The endpoints MUST NOT change the Sender/Recipient ID when changing roles. In other words, changing the roles does not change the set of AEAD keys to be used.
端点可以同时作为客户端和服务器运行，并为这些角色使用相同的安全上下文。端点独立于客户端或服务器，使用其发送方上下文保护要发送的消息，并使用其接收方上下文验证接收到的消息。在更改角色时，端点不得更改发件人/收件人ID。换句话说，更改角色不会更改要使用的AEAD密钥集。
Each endpoint derives the parameters in the security context from a small set of input parameters. The following input parameters SHALL be preestablished:
每个端点从一组小的输入参数派生安全上下文中的参数。应预先设定以下输入参数：
o Master Secret
o 主秘密
o Sender ID
o 寄件者身份
o Recipient ID
o 收件人ID
The following input parameters MAY be preestablished. In case any of these parameters is not preestablished, the default value indicated below is used:
可以预先设定以下输入参数。如果未预先设定这些参数中的任何一个，则使用以下所示的默认值：
o AEAD Algorithm
o AEAD算法
* Default is AES-CCM-16-64-128 (COSE algorithm encoding: 10)
* 默认值为AES-CCM-16-64-128（COSE算法编码：10）
o Master Salt
o 主盐
* Default is the empty byte string
* 默认值为空字节字符串
o HKDF Algorithm
o HKDF算法
* Default is HKDF SHA-256
* 默认值为HKDF SHA-256
o Replay Window
o 重播窗口
* The default mechanism is an anti-replay sliding window (see Section 4.1.2.6 of [RFC6347] with a window size of 32
* 默认机制是一个窗口大小为32的防重放滑动窗口（见[RFC6347]第4.1.2.6节）
All input parameters need to be known and agreed on by both endpoints, but the Replay Window may be different in the two endpoints. The way the input parameters are preestablished is application specific. Considerations of security context establishment are given in Section 12.2 and examples of deploying OSCORE in Appendix B.
所有输入参数都需要两个端点都知道并同意，但两个端点中的重播窗口可能不同。预先设定输入参数的方式是特定于应用程序的。第12.2节给出了建立安全上下文的注意事项，附录B给出了部署OSCORE的示例。
The HKDF MUST be one of the HMAC-based HKDF [RFC5869] algorithms defined for COSE [RFC8152]. HKDF SHA-256 is mandatory to implement. The security context parameters Sender Key, Recipient Key, and Common IV SHALL be derived from the input parameters using the HKDF, which consists of the composition of the HKDF-Extract and HKDF-Expand steps [RFC5869]:
HKDF必须是为COSE[RFC8152]定义的基于HMAC的HKDF[RFC5869]算法之一。必须执行HKDF SHA-256。安全上下文参数Sender Key、Recipient Key和Common IV应使用HKDF从输入参数中派生，HKDF由HKDF提取和HKDF扩展步骤组成[RFC5869]：
output parameter = HKDF(salt, IKM, info, L)
输出参数=HKDF（salt、IKM、info、L）
where:
哪里：
o salt is the Master Salt as defined above
o 盐是上述定义的主盐
o IKM is the Master Secret as defined above
o IKM是上面定义的主秘密
o info is the serialization of a CBOR array consisting of (the notation follows [RFC8610] as summarized in Appendix E):
o info是CBOR数组的序列化，包括（符号如下[RFC8610]，见附录E）：
info = [
id : bstr,
id_context : bstr / nil,
alg_aead : int / tstr,
type : tstr,
L : uint,
]
info = [
id : bstr,
id_context : bstr / nil,
alg_aead : int / tstr,
type : tstr,
L : uint,
]
where:
哪里：
o id is the Sender ID or Recipient ID when deriving Sender Key and Recipient Key, respectively, and the empty byte string when deriving the Common IV.
o id是分别派生发件人密钥和收件人密钥时的发件人id或收件人id，以及派生公共IV时的空字节字符串。
o id_context is the ID Context, or nil if ID Context is not provided.
o id_context是id上下文，如果未提供id上下文，则为nil。
o alg_aead is the AEAD Algorithm, encoded as defined in [RFC8152].
o alg_aead是aead算法，按照[RFC8152]中的定义进行编码。
o type is "Key" or "IV". The label is an ASCII string and does not include a trailing NUL byte.
o 类型为“键”或“IV”。标签是ASCII字符串，不包括尾随的NUL字节。
o L is the size of the key/nonce for the AEAD Algorithm used, in bytes.
o L是所用AEAD算法的键/nonce的大小，以字节为单位。
For example, if the algorithm AES-CCM-16-64-128 (see Section 10.2 in [RFC8152]) is used, the integer value for alg_aead is 10, the value for L is 16 for keys and 13 for the Common IV. Assuming use of the default algorithms HKDF SHA-256 and AES-CCM-16-64-128, the extract phase of HKDF produces a pseudorandom key (PRK) as follows:
例如，如果使用算法AES-CCM-16-64-128（参见[RFC8152]中的第10.2节），alg_aead的整数值为10，L的值为16表示密钥，13表示公共IV。假设使用默认算法HKDF SHA-256和AES-CCM-16-64-128，HKDF的提取阶段产生伪随机密钥（PRK），如下所示：
PRK = HMAC-SHA-256(Master Salt, Master Secret)
PRK=HMAC-SHA-256（主盐，主秘密）
and as L is smaller than the hash function output size, the expand phase of HKDF consists of a single HMAC invocation; therefore, the Sender Key, Recipient Key, and Common IV are the first 16 or 13 bytes of
由于L小于哈希函数输出大小，HKDF的扩展阶段由单个HMAC调用组成；因此，发送方密钥、接收方密钥和公共IV是数据的前16或13个字节
output parameter = HMAC-SHA-256(PRK, info || 0x01)
输出参数=HMAC-SHA-256（PRK，信息| | 0x01）
where different values of info are used for each derived parameter and where || denotes byte string concatenation.
其中，每个派生参数使用不同的信息值，| |表示字节字符串串联。
Note that [RFC5869] specifies that if the salt is not provided, it is set to a string of zeros. For implementation purposes, not providing the salt is the same as setting the salt to the empty byte string. OSCORE sets the salt default value to empty byte string, which is converted to a string of zeroes (see Section 2.2 of [RFC5869]).
注意，[RFC5869]指定如果未提供salt，则将其设置为一个零字符串。出于实现目的，不提供salt与将salt设置为空字节字符串相同。OSCORE将salt默认值设置为空字节字符串，并将其转换为零字符串（参见[RFC5869]第2.2节）。
The Sender Sequence Number is initialized to 0.
发送方序列号已初始化为0。
The supported types of replay protection and replay window size is application specific and depends on how OSCORE is transported (see Section 7.4). The default mechanism is the anti-replay window of received messages used by IPsec AH/ESP and DTLS (see Section 4.1.2.6 of [RFC6347]) with a window size of 32.
支持的重播保护类型和重播窗口大小是特定于应用程序的，取决于OSCORE的传输方式（参见第7.4节）。默认机制是IPsec AH/ESP和DTL使用的接收消息的反重播窗口（见[RFC6347]第4.1.2.6节），窗口大小为32。
To ensure unique Sender Keys, the quartet (Master Secret, Master Salt, ID Context, Sender ID) MUST be unique, i.e., the pair (ID Context, Sender ID) SHALL be unique in the set of all security contexts using the same Master Secret and Master Salt. This means that Sender ID SHALL be unique in the set of all security contexts using the same Master Secret, Master Salt, and ID Context; such a requirement guarantees unique (key, nonce) pairs for the AEAD.
为确保发送方密钥的唯一性，四方（主密钥、主盐、ID上下文、发送方ID）必须是唯一的，即该对（ID上下文、发送方ID）在使用相同主密钥和主盐的所有安全上下文集中应是唯一的。这意味着，发送方ID在使用相同主密钥、主Salt和ID上下文的所有安全上下文集中应是唯一的；这样的需求保证了AEAD的唯一（键、nonce）对。
Different methods can be used to assign Sender IDs: a protocol that allows the parties to negotiate locally unique identifiers, a trusted third party (e.g., [ACE-OAuth]), or the identifiers can be assigned out-of-band. The Sender IDs can be very short (note that the empty string is a legitimate value). The maximum length of Sender ID in bytes equals the length of the AEAD nonce minus 6, see Section 5.2. For AES-CCM-16-64-128 the maximum length of Sender ID is 7 bytes.
可以使用不同的方法来分配发送方ID：允许双方协商本地唯一标识符的协议、可信第三方（例如，[ACE OAuth]），或者可以在带外分配标识符。发送方ID可以很短（请注意，空字符串是合法值）。发送方ID的最大长度（以字节为单位）等于AEAD nonce的长度减去6，请参见第5.2节。对于AES-CCM-16-64-128，发送方ID的最大长度为7字节。
To simplify retrieval of the right Recipient Context, the Recipient ID SHOULD be unique in the sets of all Recipient Contexts used by an endpoint. If an endpoint has the same Recipient ID with different Recipient Contexts, i.e., the Recipient Contexts are derived from different Common Contexts, then the endpoint may need to try multiple times before verifying the right security context associated to the Recipient ID.
为了简化对正确收件人上下文的检索，收件人ID在端点使用的所有收件人上下文集中应该是唯一的。如果端点具有相同的接收者ID和不同的接收者上下文，即，接收者上下文来自不同的公共上下文，那么端点可能需要在验证与接收者ID关联的正确安全上下文之前尝试多次。
The ID Context is used to distinguish between security contexts. The methods used for assigning Sender ID can also be used for assigning the ID Context. Additionally, the ID Context can be used to introduce randomness into new Sender and Recipient Contexts (see Appendix B.2). ID Context can be arbitrarily long.
ID上下文用于区分安全上下文。用于分配发件人ID的方法也可用于分配ID上下文。此外，ID上下文可用于将随机性引入新的发送者和接收者上下文（见附录B.2）。ID上下文可以任意长。
OSCORE transforms a CoAP message (which may have been generated from an HTTP message) into an OSCORE message, and vice versa. OSCORE protects as much of the original message as possible while still allowing certain proxy operations (see Sections 10 and 11). This section defines how OSCORE protects the message fields and transfers them end-to-end between client and server (in any direction).
OSCORE将CoAP消息（可能由HTTP消息生成）转换为OSCORE消息，反之亦然。OSCORE尽可能多地保护原始消息，同时仍允许某些代理操作（请参见第10节和第11节）。本节定义了OSCORE如何保护消息字段，以及如何在客户端和服务器之间（以任何方向）端到端地传输消息字段。
The remainder of this section and later sections focus on the behavior in terms of CoAP messages. If HTTP is used for a particular hop in the end-to-end path, then this section applies to the conceptual CoAP message that is mappable to/from the original HTTP message as discussed in Section 11. That is, an HTTP message is conceptually transformed to a CoAP message and then to an OSCORE message, and similarly in the reverse direction. An actual implementation might translate directly from HTTP to OSCORE without the intervening CoAP representation.
本节的其余部分和后面的部分将重点讨论CoAP消息方面的行为。如果HTTP用于端到端路径中的特定跃点，则本节适用于概念CoAP消息，该消息可映射到原始HTTP消息，如第11节所述。也就是说，HTTP消息在概念上被转换为CoAP消息，然后再转换为OSCORE消息，并且类似地以相反的方向转换。实际实现可能直接从HTTP转换到OSCORE，而不需要介入CoAP表示。
Protection of signaling messages (Section 5 of [RFC8323]) is specified in Section 4.3. The other parts of this section target request/response messages.
第4.3节规定了信令消息的保护（RFC8323第5节）。本节的其他部分以请求/响应消息为目标。
Message fields of the CoAP message may be protected end-to-end between CoAP client and CoAP server in different ways:
CoAP消息的消息字段可以在CoAP客户端和CoAP服务器之间以不同的方式进行端到端保护：
o Class E: encrypted and integrity protected,
o E类：加密和完整性保护，
o Class I: integrity protected only, or
o I类：仅保护完整性，或
o Class U: unprotected.
o U类：无保护。
The sending endpoint SHALL transfer Class E message fields in the ciphertext of the COSE object in the OSCORE message. The sending endpoint SHALL include Class I message fields in the AAD of the AEAD algorithm, allowing the receiving endpoint to detect if the value has changed in transfer. Class U message fields SHALL NOT be protected in transfer. Class I and Class U message field values are transferred in the header or options part of the OSCORE message, which is visible to proxies.
发送端点应传输OSCORE消息中COSE对象密文中的E类消息字段。发送端点应在AEAD算法的AAD中包含I类消息字段，允许接收端点检测值是否在传输过程中发生变化。U类消息字段在传输过程中不受保护。I类和U类消息字段值在OSCORE消息的头或选项部分传输，代理可见。
Message fields not visible to proxies, i.e., transported in the ciphertext of the COSE object, are called "Inner" (Class E). Message fields transferred in the header or options part of the OSCORE message, which is visible to proxies, are called "Outer" (Class I or Class U). There are currently no Class I options defined.
代理不可见的消息字段（即，以COSE对象的密文传输）称为“内部”（e类）。在OSCORE消息头或选项部分传输的消息字段（代理可见）称为“外部”（I类或U类）。目前没有定义I类选项。
An OSCORE message may contain both an Inner and an Outer instance of a certain CoAP message field. Inner message fields are intended for the receiving endpoint, whereas Outer message fields are used to enable proxy operations.
OSCORE消息可以包含某个CoAP消息字段的内部和外部实例。内部消息字段用于接收端点，而外部消息字段用于启用代理操作。
A summary of how options are protected is shown in Figure 5. Note that some options may have both Inner and Outer message fields, which are protected accordingly. Certain options require special processing as is described in Section 4.1.3.
图5显示了如何保护选项的摘要。请注意，某些选项可能同时具有内部和外部消息字段，它们受到相应的保护。某些选项需要特殊处理，如第4.1.3节所述。
Options that are unknown or for which OSCORE processing is not defined SHALL be processed as Class E (and no special processing). Specifications of new CoAP options SHOULD define how they are processed with OSCORE. A new COAP option SHOULD be of Class E unless it requires proxy processing. If a new CoAP option is of class U, the potential issues with the option being unprotected SHOULD be documented (see Appendix D.5).
未知或未定义OSCORE处理的选项应按E级处理（无特殊处理）。新CoAP选项的规范应定义如何使用OSCORE处理这些选项。除非需要代理处理，否则新的COAP选项应为E类。如果新的CoAP选项为U类，则应记录未受保护选项的潜在问题（见附录D.5）。
Inner option message fields (Class E) are used to communicate directly with the other endpoint.
内部选项消息字段（E类）用于直接与其他端点通信。
The sending endpoint SHALL write the Inner option message fields present in the original CoAP message into the plaintext of the COSE object (Section 5.3) and then remove the Inner option message fields from the OSCORE message.
发送端点应将原始CoAP消息中的内部选项消息字段写入COSE对象的明文（第5.3节），然后从OSCORE消息中删除内部选项消息字段。
The processing of Inner option message fields by the receiving endpoint is specified in Sections 8.2 and 8.4.
第8.2节和第8.4节规定了接收端点对内部选项消息字段的处理。
+------+-----------------+---+---+
| No. | Name | E | U |
+------+-----------------+---+---+
| 1 | If-Match | x | |
| 3 | Uri-Host | | x |
| 4 | ETag | x | |
| 5 | If-None-Match | x | |
| 6 | Observe | x | x |
| 7 | Uri-Port | | x |
| 8 | Location-Path | x | |
| 9 | OSCORE | | x |
| 11 | Uri-Path | x | |
| 12 | Content-Format | x | |
| 14 | Max-Age | x | x |
| 15 | Uri-Query | x | |
| 17 | Accept | x | |
| 20 | Location-Query | x | |
| 23 | Block2 | x | x |
| 27 | Block1 | x | x |
| 28 | Size2 | x | x |
| 35 | Proxy-Uri | | x |
| 39 | Proxy-Scheme | | x |
| 60 | Size1 | x | x |
| 258 | No-Response | x | x |
+------+-----------------+---+---+
+------+-----------------+---+---+
| No. | Name | E | U |
+------+-----------------+---+---+
| 1 | If-Match | x | |
| 3 | Uri-Host | | x |
| 4 | ETag | x | |
| 5 | If-None-Match | x | |
| 6 | Observe | x | x |
| 7 | Uri-Port | | x |
| 8 | Location-Path | x | |
| 9 | OSCORE | | x |
| 11 | Uri-Path | x | |
| 12 | Content-Format | x | |
| 14 | Max-Age | x | x |
| 15 | Uri-Query | x | |
| 17 | Accept | x | |
| 20 | Location-Query | x | |
| 23 | Block2 | x | x |
| 27 | Block1 | x | x |
| 28 | Size2 | x | x |
| 35 | Proxy-Uri | | x |
| 39 | Proxy-Scheme | | x |
| 60 | Size1 | x | x |
| 258 | No-Response | x | x |
+------+-----------------+---+---+
E = Encrypt and Integrity Protect (Inner) U = Unprotected (Outer)
E=加密和完整性保护（内部）U=未受保护（外部）
Figure 5: Protection of CoAP Options
图5：CoAP选项的保护
Outer option message fields (Class U or I) are used to support proxy operations, see Appendix D.2.
外部选项消息字段（U类或I类）用于支持代理操作，见附录D.2。
The sending endpoint SHALL include the Outer option message field present in the original message in the options part of the OSCORE message. All Outer option message fields, including the OSCORE option, SHALL be encoded as described in Section 3.1 of [RFC7252], where the delta is the difference from the previously included instance of Outer option message field.
发送端点应包括OSCORE消息选项部分原始消息中存在的外部选项消息字段。所有外部选项信息字段，包括OSCORE选项，应按照[RFC7252]第3.1节所述进行编码，其中增量是与先前包含的外部选项信息字段实例的差异。
The processing of Outer options by the receiving endpoint is specified in Sections 8.2 and 8.4.
第8.2节和第8.4节规定了接收端点对外部选项的处理。
A procedure for integrity-protection-only of Class I option message fields is specified in Section 5.4. Specifications that introduce repeatable Class I options MUST specify that proxies MUST NOT change the order of the instances of such an option in the CoAP message.
第5.4节规定了仅对I类选项消息字段进行完整性保护的程序。引入可重复I类选项的规范必须规定代理不得改变CoAP消息中此类选项实例的顺序。
Note: There are currently no Class I option message fields defined.
注意：目前没有定义I类选项消息字段。
Some options require special processing as specified in this section.
某些选项需要本节规定的特殊处理。
An Inner Max-Age message field is used to indicate the maximum time a response may be cached by the client (as defined in [RFC7252]), end-to-end from the server to the client, taking into account that the option is not accessible to proxies. The Inner Max-Age SHALL be processed by OSCORE as a normal Inner option, specified in Section 4.1.1.
考虑到代理无法访问该选项，内部最大年龄消息字段用于指示客户端（如[RFC7252]中所定义）端到端从服务器到客户端缓存响应的最长时间。按照第4.1.1节的规定，内部最大使用年限应由OSCORE作为正常内部选项进行处理。
An Outer Max-Age message field is used to avoid unnecessary caching of error responses caused by OSCORE processing at OSCORE-unaware intermediary nodes. A server MAY set a Class U Max-Age message field with value zero to such error responses, described in Sections 7.4, 8.2, and 8.4, since these error responses are cacheable, but subsequent OSCORE requests would never create a hit in the intermediary node caching it. Setting the Outer Max-Age to zero relieves the intermediary from uselessly caching responses. Successful OSCORE responses do not need to include an Outer Max-Age option. Except when the Observe option (see Section 4.1.3.5) is used, responses appear to the OSCORE-unaware intermediary as 2.04 (Changed) responses, which are non-cacheable (see Section 4.2). For Observe responses, which are cacheable, an Outer Max-Age option with value 0 may be used to avoid unnecessary proxy caching.
外部“最大年龄”消息字段用于避免在OSCORE节点上进行OSCORE处理而导致错误响应的不必要缓存。服务器可以将值为零的Class U Max Age消息字段设置为此类错误响应，如第7.4节、第8.2节和第8.4节所述，因为这些错误响应是可缓存的，但后续的OSCORE请求永远不会在缓存它的中间节点中创建命中。将“外部最大年龄”设置为零将使中介不再无用地缓存响应。成功的OSCORE响应不需要包括外部最大年龄选项。除使用观察选项（见第4.1.3.5节）外，响应在OSCORE中显示为2.04（更改）响应，不可缓存（见第4.2节）。对于可缓存的观察响应，可以使用值为0的外部最大年龄选项来避免不必要的代理缓存。
The Outer Max-Age message field is processed according to Section 4.1.2.
根据第4.1.2节处理外部最大年龄消息字段。
When the Uri-Host and Uri-Port are set to their default values (see Section 5.10.1 [RFC7252]), they are omitted from the message (Section 5.4.4 of [RFC7252]), which is favorable both for overhead and privacy.
当Uri主机和Uri端口设置为它们的默认值时（参见第5.10.1节[RFC7252]），它们将从消息中省略（第5.4.4节[RFC7252]），这对开销和隐私都有利。
In order to support forward proxy operations, Proxy-Scheme, Uri-Host, and Uri-Port need to be Class U. For the use of Proxy-Uri, see Section 4.1.3.3.
为了支持转发代理操作，代理方案、Uri主机和Uri端口需要为U类。有关代理Uri的使用，请参阅第4.1.3.3节。
Manipulation of unprotected message fields (including Uri-Host, Uri-Port, destination IP/port or request scheme) MUST NOT lead to an OSCORE message becoming verified by an unintended server. Different servers SHALL have different security contexts.
操纵未受保护的消息字段（包括Uri主机、Uri端口、目标IP/端口或请求方案）不得导致OSCORE消息被意外服务器验证。不同的服务器应具有不同的安全上下文。
When Proxy-Uri is present, the client SHALL first decompose the Proxy-Uri value of the original CoAP message into the Proxy-Scheme, Uri-Host, Uri-Port, Uri-Path, and Uri-Query options according to Section 6.4 of [RFC7252].
当存在代理Uri时，客户端应首先根据[RFC7252]第6.4节将原始CoAP消息的代理Uri值分解为代理方案、Uri主机、Uri端口、Uri路径和Uri查询选项。
Uri-Path and Uri-Query are Class E options and SHALL be protected and processed as Inner options (Section 4.1.1).
Uri路径和Uri查询为E类选项，应作为内部选项进行保护和处理（第4.1.1节）。
The Proxy-Uri option of the OSCORE message SHALL be set to the composition of Proxy-Scheme, Uri-Host, and Uri-Port options as specified in Section 6.5 of [RFC7252] and processed as an Outer option of Class U (Section 4.1.2).
OSCORE消息的代理Uri选项应设置为[RFC7252]第6.5节规定的代理方案、Uri主机和Uri端口选项的组合，并作为U类外部选项处理（第4.1.2节）。
Note that replacing the Proxy-Uri value with the Proxy-Scheme and Uri-* options works by design for all CoAP URIs (see Section 6 of [RFC7252]). OSCORE-aware HTTP servers should not use the userinfo component of the HTTP URI (as defined in Section 3.2.1 of [RFC3986]), so that this type of replacement is possible in the presence of CoAP-to-HTTP proxies (see Section 11.2). In future specifications of cross-protocol proxying behavior using different URI structures, it is expected that the authors will create Uri-* options that allow decomposing the Proxy-Uri, and specifying the OSCORE processing.
请注意，使用代理方案和Uri-*选项替换代理Uri值可通过设计对所有CoAP Uri起作用（请参阅[RFC7252]第6节）。支持OSCORE的HTTP服务器不应使用HTTP URI的userinfo组件（如[RFC3986]第3.2.1节所定义），因此，在存在CoAP到HTTP代理的情况下，可以进行此类替换（见第11.2节）。在未来使用不同URI结构的跨协议代理行为规范中，预期作者将创建URI-*选项，允许分解代理URI，并指定OSCORE处理。
An example of how Proxy-Uri is processed is given here. Assume that the original CoAP message contains:
这里给出了如何处理代理Uri的示例。假设原始CoAP消息包含：
o Proxy-Uri = "coap://example.com/resource?q=1"
o 代理Uri=”coap://example.com/resource?q=1"
During OSCORE processing, Proxy-Uri is split into:
在OSCORE处理过程中，代理Uri分为：
o Proxy-Scheme = "coap"
o 代理方案=“coap”
o Uri-Host = "example.com"
o Uri Host=“example.com”
o Uri-Port = "5683" (default)
o Uri Port=“5683”（默认值）
o Uri-Path = "resource"
o Uri Path=“资源”
o Uri-Query = "q=1"
o Uri Query=“q=1”
Uri-Path and Uri-Query follow the processing defined in Section 4.1.1; thus, they are encrypted and transported in the COSE object:
Uri路径和Uri查询遵循第4.1.1节中定义的处理；因此，它们在COSE对象中被加密和传输：
o Uri-Path = "resource"
o Uri Path=“资源”
o Uri-Query = "q=1"
o Uri Query=“q=1”
The remaining options are composed into the Proxy-Uri included in the options part of the OSCORE message, which has value:
其余选项组成OSCORE消息选项部分中包含的代理Uri，其值为：
o Proxy-Uri = "coap://example.com"
o 代理Uri=”coap://example.com"
See Sections 6.1 and 12.6 of [RFC7252] for more details.
详见[RFC7252]第6.1节和第12.6节。
Block-wise [RFC7959] is an optional feature. An implementation MAY support CoAP [RFC7252] and the OSCORE option without supporting block-wise transfers. The Block options (Block1, Block2, Size1, Size2), when Inner message fields, provide secure message segmentation such that each segment can be verified. The Block options, when Outer message fields, enable hop-by-hop fragmentation of the OSCORE message. Inner and Outer block processing may have different performance properties depending on the underlying transport. The end-to-end integrity of the message can be verified both in case of Inner and Outer Block-wise transfers, provided all blocks are received.
分块[RFC7959]是可选功能。实现可以支持CoAP[RFC7252]和OSCORE选项，而不支持分块传输。块选项（Block1、Block2、Size1、Size2）在内部消息字段中提供安全消息分段，以便可以验证每个分段。在外部消息字段中，块选项启用OSCORE消息的逐跳分段。内部和外部块处理可能具有不同的性能属性，具体取决于底层传输。如果接收到所有块，则可以在内部和外部按块传输的情况下验证消息的端到端完整性。
The sending CoAP endpoint MAY fragment a CoAP message as defined in [RFC7959] before the message is processed by OSCORE. In this case, the Block options SHALL be processed by OSCORE as normal Inner options (Section 4.1.1). The receiving CoAP endpoint SHALL process the OSCORE message before processing Block-wise as defined in [RFC7959].
在OSCORE处理CoAP消息之前，发送CoAP端点可以对[RFC7959]中定义的CoAP消息进行分段。在这种情况下，OSCORE应将块选项作为正常内部选项处理（第4.1.1节）。按照[RFC7959]中的定义，接收CoAP端点应在按块处理之前处理OSCORE消息。
Proxies MAY fragment an OSCORE message using [RFC7959] by introducing Block option message fields that are Outer (Section 4.1.2). Note that the Outer Block options are neither encrypted nor integrity protected. As a consequence, a proxy can maliciously inject block fragments indefinitely, since the receiving endpoint needs to receive the last block (see [RFC7959]) to be able to compose the OSCORE message and verify its integrity. Therefore, applications supporting OSCORE and [RFC7959] MUST specify a security policy defining a
代理可以通过引入外部的块选项消息字段（第4.1.2节），使用[RFC7959]对OSCORE消息进行分段。请注意，外部块选项既不加密，也不受完整性保护。因此，代理可以无限期地恶意注入块片段，因为接收端点需要接收最后一个块（请参见[RFC7959]）才能编写OSCORE消息并验证其完整性。因此，支持OSCORE和[RFC7959]的应用程序必须指定定义
maximum unfragmented message size (MAX_UNFRAGMENTED_SIZE) considering the maximum size of message that can be handled by the endpoints. Messages exceeding this size SHOULD be fragmented by the sending endpoint using Inner Block options (Section 4.1.3.4.1).
最大未分段消息大小（MAX_unfragmented_size），考虑到端点可以处理的最大消息大小。超过此大小的消息应由发送端点使用内部块选项进行分段（第4.1.3.4.1节）。
An endpoint receiving an OSCORE message with an Outer Block option SHALL first process this option according to [RFC7959], until all blocks of the OSCORE message have been received or the cumulated message size of the blocks exceeds MAX_UNFRAGMENTED_SIZE. In the former case, the processing of the OSCORE message continues as defined in this document. In the latter case, the message SHALL be discarded.
接收带有外部块选项的OSCORE消息的端点应首先根据[RFC7959]处理该选项，直到接收到OSCORE消息的所有块或块的累积消息大小超过最大未分段大小。在前一种情况下，OSCORE消息的处理将按照本文档中的定义继续进行。在后一种情况下，应丢弃该消息。
Because of encryption of Uri-Path and Uri-Query, messages to the same server may, from the point of view of a proxy, look like they also target the same resource. A proxy SHOULD mitigate a potential mix-up of blocks from concurrent requests to the same server, for example, using the Request-Tag processing specified in Section 3.3.2 of [CoAP-ECHO-REQ-TAG].
由于Uri路径和Uri查询的加密，从代理的角度来看，发送到同一服务器的消息可能看起来也是针对同一资源的。代理应缓解来自对同一服务器的并发请求的潜在块混淆，例如，使用[CoAP ECHO REQ Tag]第3.3.2节中规定的请求标记处理。
Observe [RFC7641] is an optional feature. An implementation MAY support CoAP [RFC7252] and the OSCORE option without supporting [RFC7641], in which case the Observe-related processing can be omitted.
观察[RFC7641]是可选功能。实现可以支持CoAP[RFC7252]和OSCORE选项，而不支持[RFC7641]，在这种情况下，可以省略观察相关的处理。
The support for Observe [RFC7641] with OSCORE targets the requirements on forwarding of Section 2.2.1 of [CoAP-E2E-Sec], i.e., that observations go through intermediary nodes, as illustrated in Figure 8 of [RFC7641].
使用OSCORE对观测[RFC7641]的支持针对[CoAP-E2E-Sec]第2.2.1节的转发要求，即观测通过中间节点，如[RFC7641]的图8所示。
Inner Observe SHALL be used to protect the value of the Observe option between the endpoints. Outer Observe SHALL be used to support forwarding by intermediary nodes.
内部观察应用于保护端点之间观察选项的值。外部观察应用于支持中间节点的转发。
The server SHALL include a new Partial IV (see Section 5) in responses (with or without the Observe option) to Observe registrations, except for the first response where Partial IV MAY be omitted.
服务器应在响应中包括一个新的第四部分（见第5节）以观察注册（有或没有观察选项），但第一个响应中可能省略第四部分的情况除外。
For cancellations, Section 3.6 of [RFC7641] specifies that all options MUST be identical to those in the registration request except for the Observe option and the set of ETag options. For OSCORE messages, this matching is to be done to the options in the decrypted message.
对于取消，[RFC7641]第3.6节规定，除观察选项和ETag选项集外，所有选项必须与注册请求中的选项相同。对于OSCORE消息，将对解密消息中的选项进行匹配。
[RFC7252] does not specify how the server should act upon receiving the same Token in different requests. When using OSCORE, the server SHOULD NOT remove an active observation just because it receives a request with the same Token.
[RFC7252]未指定服务器在不同请求中接收相同令牌时应如何操作。当使用OSCORE时，服务器不应该仅仅因为接收到具有相同令牌的请求就删除活动的观察。
Since POST with the Observe option is not defined, for messages with the Observe option, the Outer Code MUST be set to 0.05 (FETCH) for requests and to 2.05 (Content) for responses (see Section 4.2).
由于未定义带有观察选项的POST，因此对于带有观察选项的消息，外部代码必须设置为0.05（获取）表示请求，设置为2.05（内容）表示响应（参见第4.2节）。
The Inner and Outer Observe options in the request MUST contain the Observe value of the original CoAP request; 0 (registration) or 1 (cancellation).
请求中的内部和外部观察选项必须包含原始CoAP请求的观察值；0（注册）或1（取消）。
Every time a client issues a new request with the Observe option, a new Partial IV MUST be used (see Section 5), and so the payload and OSCORE option are changed. The server uses the Partial IV of the new request as the 'request_piv' of all associated notifications (see Section 5.4).
每次客户端使用Observe选项发出新请求时，都必须使用新的Partial IV（参见第5节），因此payload和OSCORE选项都会发生更改。服务器使用新请求的第IV部分作为所有相关通知的“请求piv”（参见第5.4节）。
Intermediaries are not assumed to have access to the OSCORE security context used by the endpoints; thus, they cannot make requests or transform responses with the OSCORE option that pass verification (at the receiving endpoint) as having come from the other endpoint. This has the following consequences and limitations for Observe operations.
假定中介机构没有访问端点使用的OSCORE安全上下文的权限；因此，它们不能使用OSCORE选项发出请求或转换响应，这些请求或响应通过了验证（在接收端点处），因为它们来自另一个端点。这对观察操作具有以下后果和限制。
o An intermediary node removing the Outer Observe 0 option does not change the registration request to a request without the Observe option (see Section 2 of [RFC7641]). Instead other means for cancellation may be used as described in Section 3.6 of [RFC7641].
o 删除外部观察0选项的中间节点不会将注册请求更改为没有观察选项的请求（请参阅[RFC7641]第2节）。相反，可使用[RFC7641]第3.6节所述的其他取消方式。
o An intermediary node is not able to transform a normal response into an OSCORE-protected Observe notification (see Figure 7 of [RFC7641]) that verifies as coming from the server.
o 中间节点无法将正常响应转换为OSCORE保护的观察通知（请参见[RFC7641]的图7），以验证是否来自服务器。
o An intermediary node is not able to initiate an OSCORE protected Observe registration (Observe option with value 0) that verifies as coming from the client. An OSCORE-aware intermediary SHALL NOT initiate registrations of observations (see Section 10). If an OSCORE-unaware proxy resends an old registration message from a client, the replay protection mechanism in the server will be triggered. To prevent this from resulting in the OSCORE-unaware proxy canceling the registration, a server MAY respond to a replayed registration request with a replay of a cached notification. Alternatively, the server MAY send a new notification.
o 中间节点无法启动OSCORE保护的观察注册（值为0的观察选项），以验证是否来自客户端。具有OSCORE意识的中介机构不得发起观测注册（见第10节）。如果OSCORE Unknowledge代理从客户端重新发送旧的注册消息，则会触发服务器中的重播保护机制。为了防止这导致OSCORE Unknowledge代理取消注册，服务器可以通过重播缓存通知来响应重播的注册请求。或者，服务器可以发送新通知。
o An intermediary node is not able to initiate an OSCORE-protected Observe cancellation (Observe option with value 1) that verifies as coming from the client. An application MAY decide to allow intermediaries to cancel Observe registrations, e.g., to send the Observe option with value 1 (see Section 3.6 of [RFC7641]); however, that can also be done with other methods, e.g., by sending a RST message. This is out of scope for this specification.
o 中间节点无法启动OSCORE保护的观察取消（值为1的观察选项），以验证是否来自客户端。应用程序可决定允许中介机构取消观察注册，例如发送值为1的观察选项（见[RFC7641]第3.6节）；然而，这也可以通过其他方法实现，例如，通过发送RST消息。这超出了本规范的范围。
If the server accepts an Observe registration, a Partial IV MUST be included in all notifications (both successful and error), except for the first one where the Partial IV MAY be omitted. To protect against replay, the client SHALL maintain a Notification Number for each Observation it registers. The Notification Number is a non-negative integer containing the largest Partial IV of the received notifications for the associated Observe registration. Further details of replay protection of notifications are specified in Section 7.4.1.
如果服务器接受观察注册，则所有通知（成功通知和错误通知）中都必须包含部分IV，但第一个通知中可以省略部分IV的通知除外。为防止重播，客户应为其登记的每次观察保留一个通知编号。通知编号是一个非负整数，其中包含所接收到的关联注册通知的最大部分IV。第7.4.1节规定了通知重播保护的更多详细信息。
For notifications, the Inner Observe option value MUST be empty (see Section 3.2 of [RFC7252]). The Outer Observe option in a notification is needed for intermediary nodes to allow multiple responses to one request, and it MAY be set to the value of the Observe option in the original CoAP message. The client performs ordering of notifications and replay protection by comparing their Partial IVs and SHALL ignore the Outer Observe option value.
对于通知，内部观察选项值必须为空（参见[RFC7252]第3.2节）。中间节点需要通知中的外部观察选项以允许对一个请求进行多个响应，并且可以将其设置为原始CoAP消息中观察选项的值。客户端通过比较部分IVs来执行通知和重播保护的排序，并应忽略外部观察选项值。
If the client receives a response to an Observe request without an Inner Observe option, then it verifies the response as a non-Observe response, as specified in Section 8.4. If the client receives a response to a non-Observe request with an Inner Observe option, then it stops processing the message, as specified in Section 8.4.
如果客户机收到对观察请求的响应，但没有内部观察选项，则按照第8.4节的规定，将该响应验证为非观察响应。如果客户端接收到带有内部观察选项的非观察请求响应，则它将停止处理消息，如第8.4节所述。
A client MUST consider the notification with the highest Partial IV as the freshest, regardless of the order of arrival. In order to support existing Observe implementations, the OSCORE client implementation MAY set the Observe option value to the three least significant bytes of the Partial IV. Implementations need to make sure that the notification without Partial IV is considered the oldest.
客户必须考虑最高IV的通知作为最新鲜的，不管到达的顺序。为了支持现有的Observe实现，OSCORE客户端实现可以将Observe选项值设置为Partial IV的三个最低有效字节。实现需要确保没有Partial IV的通知被视为最早的通知。
No-Response [RFC7967] is an optional feature used by the client to communicate its disinterest in certain classes of responses to a particular request. An implementation MAY support [RFC7252] and the OSCORE option without supporting [RFC7967].
无响应[RFC7967]是一个可选功能，客户端使用它来传达对特定请求的特定响应类的不感兴趣。实现可能支持[RFC7252]和OSCORE选项，而不支持[RFC7967]。
If used, No-Response MUST be Inner. The Inner No-Response SHALL be processed by OSCORE as specified in Section 4.1.1. The Outer option SHOULD NOT be present. The server SHALL ignore the Outer No-Response option. The client MAY set the Outer No-Response value to 26 (suppress all known codes) if the Inner value is set to 26. The client MUST be prepared to receive and discard 5.04 (Gateway Timeout) error messages from intermediaries potentially resulting from destination time out due to no response.
如果使用，则响应必须是内部的。内部No响应应由OSCORE按照第4.1.1节的规定进行处理。外部选项不应存在。服务器应忽略外部无响应选项。如果内部值设置为26，则客户端可以将外部无响应值设置为26（抑制所有已知代码）。客户端必须准备好接收和丢弃来自中介的5.04（网关超时）错误消息，这些消息可能是由于没有响应而导致的目标超时。
The OSCORE option is only defined to be present in OSCORE messages as an indication that OSCORE processing has been performed. The content in the OSCORE option is neither encrypted nor integrity protected as a whole, but some part of the content of this option is protected (see Section 5.4). Nested use of OSCORE is not supported: If OSCORE processing detects an OSCORE option in the original CoAP message, then processing SHALL be stopped.
OSCORE选项仅定义为出现在OSCORE消息中，作为已执行OSCORE处理的指示。OSCORE选项中的内容既不是加密的，也不是整体完整性保护的，但该选项的部分内容受到保护（见第5.4节）。不支持嵌套使用OSCORE：如果OSCORE处理在原始CoAP消息中检测到OSCORE选项，则应停止处理。
A summary of how the CoAP header fields and payload are protected is shown in Figure 6, including fields specific to CoAP over UDP and CoAP over TCP (marked accordingly in the table).
图6显示了如何保护CoAP头字段和有效负载的摘要，包括特定于UDP上的CoAP和TCP上的CoAP的字段（在表中相应标记）。
+------------------+---+---+
| Field | E | U |
+------------------+---+---+
| Version (UDP) | | x |
| Type (UDP) | | x |
| Length (TCP) | | x |
| Token Length | | x |
| Code | x | |
| Message ID (UDP) | | x |
| Token | | x |
| Payload | x | |
+------------------+---+---+
E = Encrypt and Integrity Protect (Inner)
U = Unprotected (Outer)
+------------------+---+---+
| Field | E | U |
+------------------+---+---+
| Version (UDP) | | x |
| Type (UDP) | | x |
| Length (TCP) | | x |
| Token Length | | x |
| Code | x | |
| Message ID (UDP) | | x |
| Token | | x |
| Payload | x | |
+------------------+---+---+
E = Encrypt and Integrity Protect (Inner)
U = Unprotected (Outer)
Figure 6: Protection of CoAP Header Fields and Payload
图6:CoAP报头字段和有效载荷的保护
Most CoAP header fields (i.e., the message fields in the fixed 4-byte header) are required to be read and/or changed by CoAP proxies; thus, they cannot, in general, be protected end-to-end from one endpoint to the other. As mentioned in Section 1, OSCORE protects the CoAP request/response layer only and not the CoAP messaging layer (Section 2 of [RFC7252]), so fields such as Type and Message ID are not protected with OSCORE.
大多数CoAP头字段（即固定4字节头中的消息字段）需要由CoAP代理读取和/或更改；因此，一般来说，它们不能从一个端点到另一个端点进行端到端的保护。如第1节所述，OSCORE仅保护CoAP请求/响应层，而不保护CoAP消息传递层（RFC7252第2节），因此类型和消息ID等字段不受OSCORE保护。
The CoAP header field Code is protected by OSCORE. Code SHALL be encrypted and integrity protected (Class E) to prevent an intermediary from eavesdropping on or manipulating it (e.g., changing from GET to DELETE).
CoAP头字段代码受OSCORE保护。应对代码进行加密和完整性保护（E级），以防止中间人窃听或操纵代码（例如，从GET更改为DELETE）。
The sending endpoint SHALL write the Code of the original CoAP message into the plaintext of the COSE object (see Section 5.3). After that, the sending endpoint writes an Outer Code to the OSCORE message. With one exception (see Section 4.1.3.5), the Outer Code SHALL be set to 0.02 (POST) for requests and to 2.04 (Changed) for responses. The receiving endpoint SHALL discard the Outer Code in the OSCORE message and write the Code of the COSE object plaintext (Section 5.3) into the decrypted CoAP message.
发送端点应将原始CoAP消息的代码写入COSE对象的明文（见第5.3节）。之后，发送端点将外部代码写入OSCORE消息。除了一个例外（见第4.1.3.5节），对于请求，外部代码应设置为0.02（POST），对于响应，外部代码应设置为2.04（更改）。接收端点应丢弃OSCORE消息中的外部代码，并将COSE对象明文（第5.3节）的代码写入解密的CoAP消息中。
The other currently defined CoAP header fields are Unprotected (Class U). The sending endpoint SHALL write all other header fields of the original message into the header of the OSCORE message. The receiving endpoint SHALL write the header fields from the received OSCORE message into the header of the decrypted CoAP message.
其他当前定义的CoAP头字段不受保护（U类）。发送端点应将原始消息的所有其他头字段写入OSCORE消息的头中。接收端点应将接收到的OSCORE消息的报头字段写入解密的CoAP消息的报头中。
The CoAP Payload, if present in the original CoAP message, SHALL be encrypted and integrity protected; thus, it is an Inner message field. The sending endpoint writes the payload of the original CoAP message into the plaintext (Section 5.3) input to the COSE object. The receiving endpoint verifies and decrypts the COSE object, and it recreates the payload of the original CoAP message.
如果原始CoAP报文中存在CoAP有效载荷，则应对其进行加密并保护其完整性；因此，它是一个内部消息字段。发送端点将原始CoAP消息的有效负载写入COSE对象的明文（第5.3节）输入。接收端点验证和解密COSE对象，并重新创建原始CoAP消息的有效负载。
Signaling messages (CoAP Code 7.00-7.31) were introduced to exchange information related to an underlying transport connection in the specific case of CoAP over reliable transports [RFC8323].
引入信令消息（CoAP代码7.00-7.31）以交换与可靠传输上的CoAP特定情况下的底层传输连接相关的信息[RFC8323]。
OSCORE MAY be used to protect signaling if the endpoints for OSCORE coincide with the endpoints for the signaling message. If OSCORE is used to protect signaling then:
如果OSCORE的端点与信令消息的端点重合，则OSCORE可用于保护信令。如果OSCORE用于保护信令，则：
o To comply with [RFC8323], an initial empty Capabilities and Settings Message (CSM) SHALL be sent. The subsequent signaling message SHALL be protected.
o 为符合[RFC8323]，应发送初始空能力和设置消息（CSM）。应保护后续的信令消息。
o Signaling messages SHALL be protected as CoAP request messages, except in the case in which the signaling message is a response to a previous signaling message; then it SHALL be protected as a CoAP response message. For example, 7.02 (Ping) is protected as a CoAP request and 7.03 (Pong) as a CoAP response.
o 信令消息应作为CoAP请求消息进行保护，除非信令消息是对先前信令消息的响应；然后，应将其作为CoAP响应消息进行保护。例如，7.02（Ping）作为CoAP请求进行保护，7.03（Pong）作为CoAP响应进行保护。
o The Outer Code for signaling messages SHALL be set to 0.02 (POST), unless it is a response to a previous signaling message, in which case it SHALL be set to 2.04 (Changed).
o 信号消息的外部代码应设置为0.02（POST），除非它是对先前信号消息的响应，在这种情况下，应设置为2.04（更改）。
o All signaling options, except the OSCORE option, SHALL be Inner (Class E).
o 除OSCORE选项外，所有信号选项均应为内部（E级）。
NOTE: Option numbers for signaling messages are specific to the CoAP Code (see Section 5.2 of [RFC8323]).
注：信令消息的选项编号特定于CoAP代码（见[RFC8323]第5.2节）。
If OSCORE is not used to protect signaling, Signaling messages SHALL be unaltered by OSCORE.
如果OSCORE不用于保护信令，则OSCORE应不改变信令消息。
This section defines how to use COSE [RFC8152] to wrap and protect data in the original message. OSCORE uses the untagged COSE_Encrypt0 structure (see Section 5.2 of [RFC8152]) with an AEAD algorithm. The AEAD key lengths, AEAD nonce length, and maximum Sender Sequence Number are algorithm dependent.
本节定义如何使用COSE[RFC8152]包装和保护原始消息中的数据。OSCORE使用未标记的COSE_Encrypt0结构（参见[RFC8152]第5.2节）和AEAD算法。AEAD密钥长度、AEAD nonce长度和最大发送方序列号取决于算法。
The AEAD algorithm AES-CCM-16-64-128 defined in Section 10.2 of [RFC8152] is mandatory to implement. For AES-CCM-16-64-128, the length of Sender Key and Recipient Key is 128 bits; the length of AEAD nonce and Common IV is 13 bytes. The maximum Sender Sequence Number is specified in Section 12.
必须实施[RFC8152]第10.2节中定义的AEAD算法AES-CCM-16-64-128。对于AES-CCM-16-64-128，发送方密钥和接收方密钥的长度为128位；AEAD nonce和Common IV的长度为13字节。第12节规定了最大发送方序列号。
As specified in [RFC5116], plaintext denotes the data that is to be encrypted and integrity protected, and Additional Authenticated Data (AAD) denotes the data that is to be integrity protected only.
如[RFC5116]所述，明文表示要加密和完整性保护的数据，附加认证数据（AAD）表示仅要完整性保护的数据。
The COSE object SHALL be a COSE_Encrypt0 object with fields defined as follows:
COSE对象应为COSE_Encrypt0对象，其字段定义如下：
o The 'protected' field is empty.
o “受保护”字段为空。
o The 'unprotected' field includes:
o “未受保护”字段包括：
* The 'Partial IV' parameter. The value is set to the Sender Sequence Number. All leading bytes of value zero SHALL be removed when encoding the Partial IV, except in the case of Partial IV value 0, which is encoded to the byte string 0x00.
* “部分IV”参数。该值设置为发送方序列号。编码部分IV时，应删除值为0的所有前导字节，部分IV值为0的情况除外，该值被编码为字节字符串0x00。
This parameter SHALL be present in requests and will not typically be present in responses (for two exceptions, see Observe notifications (Section 4.1.3.5.2) and Replay Window synchronization (Appendix B.1.2)).
该参数应出现在请求中，通常不会出现在响应中（关于两种例外情况，请参见观察通知（第4.1.3.5.2节）和回放窗口同步（附录B.1.2））。
* The 'kid' parameter. The value is set to the Sender ID. This parameter SHALL be present in requests and will not typically be present in responses. An example where the Sender ID is included in a response is the extension of OSCORE to group communication [Group-OSCORE].
* “kid”参数。该值设置为发件人ID。此参数应出现在请求中，通常不会出现在响应中。响应中包含发送方ID的一个示例是OSCORE到组通信[group OSCORE]的扩展。
* Optionally, a 'kid context' parameter (see Section 5.1). This parameter MAY be present in requests and, if so, MUST contain an ID Context (see Section 3.1). This parameter SHOULD NOT be present in responses: an example of how 'kid context' can be used in responses is given in Appendix B.2. If 'kid context' is present in the request, then the server SHALL use a security context with that ID Context when verifying the request.
* （可选）一个“儿童上下文”参数（见第5.1节）。此参数可能存在于请求中，如果存在，则必须包含ID上下文（参见第3.1节）。此参数不应出现在响应中：附录B.2给出了如何在响应中使用“儿童上下文”的示例。如果请求中存在“kid context”，则服务器在验证请求时应使用具有该ID上下文的安全上下文。
o The 'ciphertext' field is computed from the secret key (Sender Key or Recipient Key), AEAD nonce (see Section 5.2), plaintext (see Section 5.3), and the AAD (see Section 5.4) following Section 5.2 of [RFC8152].
o 根据[RFC8152]第5.2节之后的密钥（发送方密钥或接收方密钥）、AEAD nonce（见第5.2节）、明文（见第5.3节）和AAD（见第5.4节）计算“密文”字段。
The encryption process is described in Section 5.3 of [RFC8152].
[RFC8152]第5.3节描述了加密过程。
For certain use cases, e.g., deployments where the same Sender ID is used with multiple contexts, it is possible (and sometimes necessary, see Section 3.3) for the client to use an ID Context to distinguish the security contexts (see Section 3.1). For example:
对于某些用例，例如同一发送方ID用于多个上下文的部署，客户端可以（有时是必要的，请参见第3.3节）使用ID上下文来区分安全上下文（请参见第3.1节）。例如：
o If the client has a unique identifier in some namespace, then that identifier can be used as ID Context.
o 如果客户机在某个命名空间中具有唯一标识符，则该标识符可以用作ID上下文。
o The ID Context may be used to add randomness into new Sender and Recipient Contexts, see Appendix B.2.
o ID上下文可用于将随机性添加到新的发送者和接收者上下文中，见附录B.2。
o In the case of group communication [Group-OSCORE], a group identifier is used as ID Context to enable different security contexts for a server belonging to multiple groups.
o 在组通信[group OSCORE]的情况下，组标识符用作ID上下文，以便为属于多个组的服务器启用不同的安全上下文。
The Sender ID and ID Context are used to establish the necessary input parameters and in the derivation of the security context (see Section 3.2).
发送方ID和ID上下文用于建立必要的输入参数和安全上下文的派生（见第3.2节）。
While the 'kid' parameter is used to transport the Sender ID, the new COSE header parameter 'kid context' is used to transport the ID Context in requests, see Figure 7.
虽然'kid'参数用于传输发送方ID，但新的COSE头参数'kid context'用于传输请求中的ID上下文，见图7。
+----------+--------+------------+----------------+-----------------+
| Name | Label | Value Type | Value Registry | Description |
+----------+--------+------------+----------------+-----------------+
| kid | 10 | bstr | | Identifies the |
| context | | | | context for the |
| | | | | key identifier |
+----------+--------+------------+----------------+-----------------+
+----------+--------+------------+----------------+-----------------+
| Name | Label | Value Type | Value Registry | Description |
+----------+--------+------------+----------------+-----------------+
| kid | 10 | bstr | | Identifies the |
| context | | | | context for the |
| | | | | key identifier |
+----------+--------+------------+----------------+-----------------+
Figure 7: Common Header Parameter 'kid context' for the COSE Object
图7:COSE对象的公共头参数“kid context”
If ID Context is non-empty and the client sends a request without 'kid context' resulting in an error indicating that the server could not find the security context, then the client could include the ID Context in the 'kid context' when making another request. Note that since the error is unprotected, it may have been spoofed and the real response blocked by an on-path attacker.
如果ID上下文为非空，并且客户端发送的请求没有“kid Context”，导致错误，表明服务器找不到安全上下文，那么客户端在发出另一个请求时可以将ID上下文包含在“kid Context”中。请注意，由于错误未受保护，因此可能已被路径上的攻击者欺骗并阻止了真正的响应。
The high-level design of the AEAD nonce follows Section 4.4 of [IV-GEN]. The detailed construction of the AEAD nonce is presented here (see Figure 8):
AEAD nonce的高级设计遵循[IV-GEN]第4.4节。此处给出了AEAD nonce的详细结构（见图8）：
1. left-pad the Partial IV (PIV) with zeroes to exactly 5 bytes,
1. 左键将部分IV（PIV）填充为0，精确到5个字节，
2. left-pad the Sender ID of the endpoint that generated the Partial IV (ID_PIV) with zeroes to exactly nonce length minus 6 bytes,
2. 左键填充生成部分IV（ID_PIV）的端点的发送方ID，其零正好等于当前长度减去6个字节，
3. concatenate the size of the ID_PIV (a single byte S) with the padded ID_PIV and the padded PIV,
3. 将ID_PIV（单字节S）的大小与填充ID_PIV和填充PIV连接起来，
4. and then XOR with the Common IV.
4. 然后用普通IV进行异或运算。
Note that in this specification, only AEAD algorithms that use nonces equal or greater than 7 bytes are supported. The nonce construction with S, ID_PIV, and PIV together with endpoint-unique IDs and encryption keys makes it easy to verify that the nonces used with a specific key will be unique, see Appendix D.4.
请注意，在本规范中，仅支持使用等于或大于7字节的nonce的AEAD算法。带有S、ID_PIV和PIV以及端点唯一ID和加密密钥的nonce构造使得验证与特定密钥一起使用的nonce是否唯一变得容易，请参见附录D.4。
If the Partial IV is not present in a response, the nonce from the request is used. For responses that are not notifications (i.e., when there is a single response to a request), the request and the response should typically use the same nonce to reduce message overhead. Both alternatives provide all the required security
如果响应中不存在部分IV，则使用请求中的nonce。对于不是通知的响应（即，当请求只有一个响应时），请求和响应通常应使用相同的nonce来减少消息开销。这两种方案都提供了所需的所有安全性
properties, see Section 7.4 and Appendix D.4. Another non-Observe scenario where a Partial IV is included in a response is when the server is unable to perform replay protection, see Appendix B.1.2. For processing instructions see Section 8.
属性，见第7.4节和附录D.4。响应中包含部分IV的另一个不可观察场景是服务器无法执行重播保护时，请参见附录B.1.2。有关处理说明，请参见第8节。
<- nonce length minus 6 B -> <-- 5 bytes -->
+---+-------------------+--------+---------+-----+
| S | padding | ID_PIV | padding | PIV |----+
+---+-------------------+--------+---------+-----+ |
|
<---------------- nonce length ----------------> |
+------------------------------------------------+ |
| Common IV |->(XOR)
+------------------------------------------------+ |
|
<---------------- nonce length ----------------> |
+------------------------------------------------+ |
| Nonce |<---+
+------------------------------------------------+
<- nonce length minus 6 B -> <-- 5 bytes -->
+---+-------------------+--------+---------+-----+
| S | padding | ID_PIV | padding | PIV |----+
+---+-------------------+--------+---------+-----+ |
|
<---------------- nonce length ----------------> |
+------------------------------------------------+ |
| Common IV |->(XOR)
+------------------------------------------------+ |
|
<---------------- nonce length ----------------> |
+------------------------------------------------+ |
| Nonce |<---+
+------------------------------------------------+
Figure 8: AEAD Nonce Formation
图8:AEAD Nonce地层
The plaintext is formatted as a CoAP message with a subset of the header (see Figure 9) consisting of:
明文被格式化为CoAP消息，其标题子集（见图9）包括：
o the Code of the original CoAP message as defined in Section 3 of [RFC7252]; and
o [RFC7252]第3节中定义的原始CoAP报文代码；和
o all Inner option message fields (see Section 4.1.1) present in the original CoAP message (see Section 4.1). The options are encoded as described in Section 3.1 of [RFC7252], where the delta is the difference from the previously included instance of Class E option; and
o 原始CoAP消息（见第4.1节）中存在的所有内部选项消息字段（见第4.1.1节）。选项按照[RFC7252]第3.1节所述进行编码，其中增量是与之前包含的E类选项实例的差异；和
o the Payload of original CoAP message, if present, and in that case prefixed by the one-byte Payload Marker (0xff).
o 原始CoAP消息的有效负载（如果存在），在这种情况下，以单字节有效负载标记（0xff）为前缀。
NOTE: The plaintext contains all CoAP data that needs to be encrypted end-to-end between the endpoints.
注意：明文包含端点之间需要端到端加密的所有CoAP数据。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Class E options (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1| Payload (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(only if there is payload)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Class E options (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1| Payload (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(only if there is payload)
Figure 9: Plaintext
图9：纯文本
The external_aad SHALL be a CBOR array wrapped in a bstr object as defined below, following the notation of [RFC8610] as summarized in Appendix E:
按照附录E中总结的[RFC8610]符号，外部_aad应为包裹在bstr对象中的CBOR阵列，定义如下：
external_aad = bstr .cbor aad_array
外部\u aad=bstr.cbor aad\u数组
aad_array = [
oscore_version : uint,
algorithms : [ alg_aead : int / tstr ],
request_kid : bstr,
request_piv : bstr,
options : bstr,
]
aad_array = [
oscore_version : uint,
algorithms : [ alg_aead : int / tstr ],
request_kid : bstr,
request_piv : bstr,
options : bstr,
]
where:
哪里：
o oscore_version: contains the OSCORE version number. Implementations of this specification MUST set this field to 1. Other values are reserved for future versions.
o oscore_版本：包含oscore版本号。此规范的实现必须将此字段设置为1。其他值保留给将来的版本。
o algorithms: contains (for extensibility) an array of algorithms, according to this specification only containing alg_aead.
o 算法：包含（为了扩展性）一组算法，根据本规范，仅包含alg_aead。
o alg_aead: contains the AEAD Algorithm from the security context used for the exchange (see Section 3.1).
o alg_aead：包含用于交换的安全上下文中的aead算法（参见第3.1节）。
o request_kid: contains the value of the 'kid' in the COSE object of the request (see Section 5).
o request_kid：包含请求的COSE对象中“kid”的值（参见第5节）。
o request_piv: contains the value of the 'Partial IV' in the COSE object of the request (see Section 5).
o request_piv：包含请求的COSE对象中“Partial IV”的值（参见第5节）。
o options: contains the Class I options (see Section 4.1.2) present in the original CoAP message encoded as described in Section 3.1 of [RFC7252], where the delta is the difference from the previously included instance of class I option.
o 选项：包含[RFC7252]第3.1节所述编码的原始CoAP消息中存在的I类选项（见第4.1.2节），其中增量是与先前包含的I类选项实例的差异。
The oscore_version and algorithms parameters are established out-of-band; thus, they are not transported in OSCORE, but the external_aad allows to verify that they are the same in both endpoints.
在带外建立oscore_版本和算法参数；因此，它们不会在OSCORE中传输，但外部aad允许验证它们在两个端点中是否相同。
NOTE: The format of the external_aad is, for simplicity, the same for requests and responses, although some parameters, e.g., request_kid, need not be integrity protected in all requests.
注意：为简单起见，外部_aad的格式与请求和响应的格式相同，尽管某些参数（例如，request_kid）不需要在所有请求中都进行完整性保护。
The AAD is composed from the external_aad as described in Section 5.3 of [RFC8152] (the notation follows [RFC8610] as summarized in Appendix E):
AAD由[RFC8152]第5.3节所述的外部AAD组成（符号如下[RFC8610]，见附录E）：
AAD = Enc_structure = [ "Encrypt0", h'', external_aad ]
AAD = Enc_structure = [ "Encrypt0", h'', external_aad ]
The following is an example of AAD constructed using AEAD Algorithm = AES-CCM-16-64-128 (10), request_kid = 0x00, request_piv = 0x25 and no Class I options:
以下是使用AEAD算法=AES-CCM-16-64-128（10）、请求\u kid=0x00、请求\u piv=0x25和无I类选项构建的AAD示例：
o oscore_version: 0x01 (1 byte)
o oscore_版本：0x01（1字节）
o algorithms: 0x810a (2 bytes)
o 算法：0x810a（2字节）
o request_kid: 0x00 (1 byte)
o 请求：0x00（1字节）
o request_piv: 0x25 (1 byte)
o 请求\u piv:0x25（1字节）
o options: 0x (0 bytes)
o 选项：0x（0字节）
o aad_array: 0x8501810a4100412540 (9 bytes)
o aad_阵列：0x8501810a4100412540（9字节）
o external_aad: 0x498501810a4100412540 (10 bytes)
o 外部地址：0x498501810a4100412540（10字节）
o AAD: 0x8368456e63727970743040498501810a4100412540 (21 bytes)
o AAD:0x8368456e63727970743040498501810a4100412540（21字节）
Note that the AAD consists of a fixed string of 11 bytes concatenated with the external_aad.
请注意，AAD由一个11字节的固定字符串组成，该字符串与外部AAD连接在一起。
The Concise Binary Object Representation (CBOR) [RFC7049] combines very small message sizes with extensibility. The CBOR Object Signing and Encryption (COSE) [RFC8152] uses CBOR to create compact encoding of signed and encrypted data. However, COSE is constructed to
简明二进制对象表示法（CBOR）[RFC7049]结合了非常小的消息大小和可扩展性。CBOR对象签名和加密（COSE）[RFC8152]使用CBOR创建签名和加密数据的压缩编码。然而，COSE的构建是为了
support a large number of different stateless use cases and is not fully optimized for use as a stateful security protocol, leading to a larger than necessary message expansion. In this section, we define a stateless header compression mechanism, simply removing redundant information from the COSE objects, which significantly reduces the per-packet overhead. The result of applying this mechanism to a COSE object is called the "compressed COSE object".
支持大量不同的无状态用例，并且没有完全优化以用作有状态安全协议，导致了超出必要的消息扩展。在本节中，我们定义了一种无状态报头压缩机制，只需从COSE对象中删除冗余信息，即可显著降低每个数据包的开销。将此机制应用于COSE对象的结果称为“压缩COSE对象”。
The COSE_Encrypt0 object used in OSCORE is transported in the OSCORE option and in the Payload. The Payload contains the ciphertext of the COSE object. The headers of the COSE object are compactly encoded as described in the next section.
OSCORE中使用的COSE_Encrypt0对象在OSCORE选项和有效负载中传输。有效负载包含COSE对象的密文。COSE对象的头被压缩编码，如下一节所述。
The value of the OSCORE option SHALL contain the OSCORE flag bits, the 'Partial IV' parameter, the 'kid context' parameter (length and value), and the 'kid' parameter as follows:
OSCORE选项的值应包含OSCORE标志位、“部分IV”参数、“kid上下文”参数（长度和值）和“kid”参数，如下所示：
0 1 2 3 4 5 6 7 <------------- n bytes -------------->
+-+-+-+-+-+-+-+-+--------------------------------------
|0 0 0|h|k| n | Partial IV (if any) ...
+-+-+-+-+-+-+-+-+--------------------------------------
0 1 2 3 4 5 6 7 <------------- n bytes -------------->
+-+-+-+-+-+-+-+-+--------------------------------------
|0 0 0|h|k| n | Partial IV (if any) ...
+-+-+-+-+-+-+-+-+--------------------------------------
<- 1 byte -> <----- s bytes ------>
+------------+----------------------+------------------+
| s (if any) | kid context (if any) | kid (if any) ... |
+------------+----------------------+------------------+
<- 1 byte -> <----- s bytes ------>
+------------+----------------------+------------------+
| s (if any) | kid context (if any) | kid (if any) ... |
+------------+----------------------+------------------+
Figure 10: The OSCORE Option Value
图10：OSCORE选项值
o The first byte, containing the OSCORE flag bits, encodes the following set of bits and the length of the 'Partial IV' parameter:
o 包含OSCORE标志位的第一个字节对以下一组位和“Partial IV”参数的长度进行编码：
* The three least significant bits encode the Partial IV length n. If n = 0, then the Partial IV is not present in the compressed COSE object. The values n = 6 and n = 7 are reserved.
* 三个最低有效位对部分IV长度n进行编码。如果n=0，则压缩的COSE对象中不存在部分IV。保留值n=6和n=7。
* The fourth least significant bit is the 'kid' flag, k. It is set to 1 if 'kid' is present in the compressed COSE object.
* 第四个最低有效位是“kid”标志k。如果压缩的COSE对象中存在“kid”，则将其设置为1。
* The fifth least significant bit is the 'kid context' flag, h. It is set to 1 if the compressed COSE object contains a 'kid context' (see Section 5.1).
* 第五个最低有效位是“kid context”标志h。如果压缩的COSE对象包含“儿童上下文”，则将其设置为1（参见第5.1节）。
* The sixth-to-eighth least significant bits are reserved for future use. These bits SHALL be set to zero when not in use. According to this specification, if any of these bits are set to 1, the message is considered to be malformed and decompression fails as specified in item 2 of Section 8.2.
* 第六至第八最低有效位保留供将来使用。不使用时，这些位应设置为零。根据本规范，如果这些位中的任何一位被设置为1，则视为消息格式错误，并且按照第8.2节第2项的规定，解压缩失败。
The flag bits are registered in the "OSCORE Flag Bits" registry specified in Section 13.7.
标志位在第13.7节规定的“OSCORE标志位”注册表中注册。
o The following n bytes encode the value of the Partial IV, if the Partial IV is present (n > 0).
o 如果存在部分IV（n>0），则以下n个字节对部分IV的值进行编码。
o The following 1 byte encodes the length s of the 'kid context' (Section 5.1), if the 'kid context' flag is set (h = 1).
o 如果设置了“kid context”标志（h=1），则以下1字节编码“kid context”的长度s（第5.1节）。
o The following s bytes encode the 'kid context', if the 'kid context' flag is set (h = 1).
o 如果设置了“kid context”标志（h=1），则以下s字节对“kid context”进行编码。
o The remaining bytes encode the value of the 'kid', if the 'kid' is present (k = 1).
o 如果存在“kid”（k=1），则剩余字节对“kid”的值进行编码。
Note that the 'kid' MUST be the last field of the OSCORE option value, even in the case in which reserved bits are used and additional fields are added to it.
请注意，“kid”必须是OSCORE选项值的最后一个字段，即使在使用保留位并向其添加其他字段的情况下也是如此。
The length of the OSCORE option thus depends on the presence and length of Partial IV, 'kid context', 'kid', as specified in this section, and on the presence and length of additional parameters, as defined in the future documents registering those parameters.
因此，OSCORE选项的长度取决于本节规定的第四部分“kid上下文”、“kid”的存在和长度，以及其他参数的存在和长度，如注册这些参数的未来文档中所定义。
The payload of the OSCORE message SHALL encode the ciphertext of the COSE object.
OSCORE消息的有效载荷应编码COSE对象的密文。
This section covers a list of OSCORE Header Compression examples for requests and responses. The examples assume the COSE_Encrypt0 object is set (which means the CoAP message and cryptographic material is known). Note that the full CoAP unprotected message, as well as the full security context, is not reported in the examples, but only the input necessary to the compression mechanism, i.e., the COSE_Encrypt0 object. The output is the compressed COSE object as defined in Section 6, divided into two parts, since the object is transported in two CoAP fields: the OSCORE option and payload.
本节介绍请求和响应的OSCORE头压缩示例列表。示例假定设置了COSE_Encrypt0对象（这意味着CoAP消息和加密材料是已知的）。请注意，示例中未报告完整的CoAP未受保护消息以及完整的安全上下文，而仅报告压缩机制所需的输入，即COSE_Encrypt0对象。输出是第6节中定义的压缩COSE对象，分为两部分，因为对象在两个CoAP字段中传输：OSCORE选项和有效载荷。
1. Request with ciphertext = 0xaea0155667924dff8a24e4cb35b9, kid = 0x25, and Partial IV = 0x05
1. 密文为0xaea0155667924dff8a24e4cb35b9、kid为0x25、部分IV为0x05的请求
Before compression (24 bytes):
压缩前（24字节）：
[ h'', { 4:h'25', 6:h'05' }, h'aea0155667924dff8a24e4cb35b9', ]
[h'，{4:h'25'，6:h'05'}，h'aea0155667924dff8a24e4cb35b9'，]
After compression (17 bytes):
压缩后（17字节）：
Flag byte: 0b00001001 = 0x09 (1 byte)
标志字节：0b00001001=0x09（1字节）
Option Value: 0x090525 (3 bytes)
选项值：0x090525（3字节）
Payload: 0xaea0155667924dff8a24e4cb35b9 (14 bytes)
有效负载：0xaea0155667924dff8a24e4cb35b9（14字节）
2. Request with ciphertext = 0xaea0155667924dff8a24e4cb35b9, kid = empty string, and Partial IV = 0x00
2. 密文为0xaea0155667924dff8a24e4cb35b9、kid为空字符串、部分IV为0x00的请求
Before compression (23 bytes):
压缩前（23字节）：
[ h'', { 4:h'', 6:h'00' }, h'aea0155667924dff8a24e4cb35b9', ]
[h'，{4:h'，6:h'00'，h'aea0155667924dff8a24e4cb35b9'，]
After compression (16 bytes):
压缩后（16字节）：
Flag byte: 0b00001001 = 0x09 (1 byte)
标志字节：0b00001001=0x09（1字节）
Option Value: 0x0900 (2 bytes)
选项值：0x0900（2字节）
Payload: 0xaea0155667924dff8a24e4cb35b9 (14 bytes)
有效负载：0xaea0155667924dff8a24e4cb35b9（14字节）
3. Request with ciphertext = 0xaea0155667924dff8a24e4cb35b9, kid = empty string, Partial IV = 0x05, and kid context = 0x44616c656b
3. 密文为0xaea0155667924dff8a24e4cb35b9、kid为空字符串、部分IV为0x05、kid上下文为0x44616c656b的请求
Before compression (30 bytes):
压缩前（30字节）：
[ h'', { 4:h'', 6:h'05', 10:h'44616c656b' }, h'aea0155667924dff8a24e4cb35b9', ]
[h'，{4:h'，6:h'05'，10:h'44616c656b'}，h'aea0155667924dff8a24e4cb35b9'，]
After compression (22 bytes):
压缩后（22字节）：
Flag byte: 0b00011001 = 0x19 (1 byte)
标志字节：0b00011001=0x19（1字节）
Option Value: 0x19050544616c656b (8 bytes)
选项值：0x19050544616c656b（8字节）
Payload: 0xae a0155667924dff8a24e4cb35b9 (14 bytes)
有效负载：0xae a0155667924dff8a24e4cb35b9（14字节）
4. Response with ciphertext = 0xaea0155667924dff8a24e4cb35b9 and no Partial IV
4. 密文为0xaea0155667924dff8a24e4cb35b9且无部分IV的响应
Before compression (18 bytes):
压缩前（18字节）：
[ h'', {}, h'aea0155667924dff8a24e4cb35b9', ]
[h'，{}，h'aea0155667924dff8a24e4cb35b9'，]
After compression (14 bytes):
压缩后（14字节）：
Flag byte: 0b00000000 = 0x00 (1 byte)
标志字节：0b00000000=0x00（1字节）
Option Value: 0x (0 bytes)
选项值：0x（0字节）
Payload: 0xaea0155667924dff8a24e4cb35b9 (14 bytes)
有效负载：0xaea0155667924dff8a24e4cb35b9（14字节）
5. Response with ciphertext = 0xaea0155667924dff8a24e4cb35b9 and Partial IV = 0x07
5. 密文为0xaea0155667924dff8a24e4cb35b9且部分IV为0x07的响应
Before compression (21 bytes):
压缩前（21字节）：
[ h'', { 6:h'07' }, h'aea0155667924dff8a24e4cb35b9', ]
[h'，{6:h'07'}，h'aea0155667924dff8a24e4cb35b9'，]
After compression (16 bytes):
压缩后（16字节）：
Flag byte: 0b00000001 = 0x01 (1 byte)
标志字节：0b00000001=0x01（1字节）
Option Value: 0x0107 (2 bytes)
选项值：0x0107（2字节）
Payload: 0xaea0155667924dff8a24e4cb35b9 (14 bytes)
有效负载：0xaea0155667924dff8a24e4cb35b9（14字节）
In order to prevent response delay and mismatch attacks [CoAP-Actuators] from on-path attackers and compromised intermediaries, OSCORE binds responses to the requests by including the 'kid' and Partial IV of the request in the AAD of the response. Therefore, the server needs to store the 'kid' and Partial IV of the request until all responses have been sent.
为了防止响应延迟和不匹配攻击[CoAP Actuators]来自路径攻击者和受损中介，OSCORE通过在响应的AAD中包含请求的“kid”和部分IV来绑定对请求的响应。因此，服务器需要存储请求的“kid”和部分IV，直到发送所有响应为止。
An AEAD nonce MUST NOT be used more than once per AEAD key. The uniqueness of (key, nonce) pairs is shown in Appendix D.4, and in particular depends on a correct usage of Partial IVs (which encode the Sender Sequence Numbers, see Section 5). If messages are processed concurrently, the operation of reading and increasing the Sender Sequence Number MUST be atomic.
每个AEAD密钥不能使用AEAD nonce超过一次。附录D.4中显示了（键、非键）对的唯一性，尤其取决于部分IV的正确使用（对发送方序列号进行编码，见第5节）。如果同时处理消息，则读取和增加发送方序列号的操作必须是原子操作。
The maximum Sender Sequence Number is algorithm dependent (see Section 12) and SHALL be less than 2^40. If the Sender Sequence Number exceeds the maximum, the endpoint MUST NOT process any more messages with the given Sender Context. If necessary, the endpoint SHOULD acquire a new security context before this happens. The latter is out of scope of this document.
最大发送方序列号取决于算法（见第12节），且应小于2^40。如果发件人序列号超过最大值，则终结点不得再处理具有给定发件人上下文的任何消息。如有必要，端点应在发生这种情况之前获取新的安全上下文。后者超出了本文件的范围。
For requests, OSCORE provides only the guarantee that the request is not older than the security context. For applications having stronger demands on request freshness (e.g., control of actuators), OSCORE needs to be augmented with mechanisms providing freshness (for example, as specified in [CoAP-ECHO-REQ-TAG]).
对于请求，OSCORE仅提供请求不早于安全上下文的保证。对于对请求新鲜度有更高要求的应用（例如，执行器的控制），OSCORE需要增加提供新鲜度的机制（例如，如[CoAP ECHO REQ TAG]中规定的）。
Assuming an honest server (see Appendix D), the message binding guarantees that a response is not older than its request. For responses that are not notifications (i.e., when there is a single response to a request), this gives absolute freshness. For notifications, the absolute freshness gets weaker with time, and it is RECOMMENDED that the client regularly re-register the observation. Note that the message binding does not guarantee that a misbehaving server created the response before receiving the request, i.e., it does not verify server aliveness.
假设是一个诚实的服务器（参见附录D），消息绑定保证响应不早于其请求。对于不是通知的响应（即，当一个请求只有一个响应时），这将提供绝对新鲜度。对于通知，绝对新鲜度会随着时间的推移而减弱，建议客户定期重新注册观察结果。请注意，消息绑定不能保证行为不正常的服务器在接收请求之前创建了响应，也就是说，它不能验证服务器的有效性。
For requests and notifications, OSCORE also provides relative freshness in the sense that the received Partial IV allows a recipient to determine the relative order of requests or responses.
对于请求和通知，OSCORE还提供了相对新鲜度，即接收到的部分IV允许接收者确定请求或响应的相对顺序。
In order to protect from replay of requests, the server's Recipient Context includes a Replay Window. A server SHALL verify that the Sender Sequence Number received in the 'Partial IV' parameter of the COSE object (see Section 6.1) has not been received before. If this verification fails, the server SHALL stop processing the message, and it MAY optionally respond with a 4.01 (Unauthorized) error message. Also, the server MAY set an Outer Max-Age option with value zero to inform any intermediary that the response is not to be cached. The diagnostic payload MAY contain the string "Replay detected". The size and type of the Replay Window depends on the use case and the protocol with which the OSCORE message is transported. In case of reliable and ordered transport from endpoint to endpoint, e.g., TCP, the server MAY just store the last received Partial IV and require that newly received Partial IVs equal the last received Partial IV + 1. However, in the case of mixed reliable and unreliable transports and where messages may be lost, such a replay mechanism may be too restrictive and the default replay window may be more suitable (see Section 3.2.2).
为了防止请求重播，服务器的收件人上下文包括重播窗口。服务器应验证在COSE对象的“Partial IV”参数中收到的发送方序列号（见第6.1节）以前未收到过。如果该验证失败，服务器应停止处理该消息，并可选择使用4.01（未经授权）错误消息进行响应。此外，服务器可以设置值为零的外部Max Age选项，以通知任何中介不缓存响应。诊断有效负载可能包含字符串“Replay detected”。重播窗口的大小和类型取决于用例和传输OSCORE消息的协议。在端点到端点的可靠有序传输（例如TCP）的情况下，服务器可能只存储最后接收到的部分IV，并要求新接收到的部分IV等于最后接收到的部分IV+1。但是，在混合可靠和不可靠传输以及消息可能丢失的情况下，这种重播机制可能限制太多，默认重播窗口可能更合适（见第3.2.2节）。
Responses (with or without Partial IV) are protected against replay as they are bound to the request and the fact that only a single response is accepted. In this case the Partial IV is not used for replay protection of responses.
响应（带或不带部分IV）受到保护，以防止重播，因为它们绑定到请求，并且只接受单个响应。在这种情况下，部分IV不用于响应的重播保护。
The operation of validating the Partial IV and updating the replay protection MUST be atomic.
验证部分IV和更新重播保护的操作必须是原子操作。
The following applies additionally when the Observe option is supported.
当支持“观察”选项时，以下内容也适用。
The Notification Number (see Section 4.1.3.5.2) is initialized to the Partial IV of the first successfully verified notification in response to the registration request. A client MUST only accept at most one Observe notification without Partial IV, and treat it as the oldest notification received. A client receiving a notification containing a Partial IV SHALL compare the Partial IV with the Notification Number associated to that Observe registration. The client MUST stop processing notifications with a Partial IV that has
响应注册请求，将通知编号（见第4.1.3.5.2节）初始化为第一次成功验证通知的第IV部分。客户端最多只能接受一个不带部分IV的Observe通知，并将其视为收到的最早的通知。收到包含部分IV的通知的客户应将部分IV与该注册相关的通知编号进行比较。客户端必须停止处理具有已删除的部分IV的通知
been previously received. Applications MAY decide that a client only processes notifications that have a greater Partial IV than the Notification Number.
以前收到过。应用程序可能会决定客户端只处理部分IV大于通知编号的通知。
If the verification of the response succeeds, and the received Partial IV was greater than the Notification Number, then the client SHALL overwrite the corresponding Notification Number with the received Partial IV.
如果响应验证成功，且收到的部分IV大于通知编号，则客户应使用收到的部分IV覆盖相应的通知编号。
To prevent reuse of an AEAD nonce with the same AEAD key or the acceptance of replayed messages, an endpoint needs to handle the situation of losing rapidly changing parts of the context, such as the Sender Sequence Number and Replay Window. These are typically stored in RAM and therefore lost in the case of, e.g., an unplanned reboot. There are different alternatives to recover, for example:
为了防止重用具有相同AEAD密钥的AEAD nonce或接受重播消息，端点需要处理丢失快速变化的上下文部分（如发送方序列号和重播窗口）的情况。它们通常存储在RAM中，因此在意外重启时丢失。有不同的恢复方法，例如：
1. The endpoints can reuse an existing Security Context after updating the mutable parts of the security context (Sender Sequence Number and Replay Window). This requires that the mutable parts of the security context are available throughout the lifetime of the device or that the device can establish a fresh security context after loss of mutable security context data. Examples are given based on careful use of nonvolatile memory, see Appendix B.1.1 and the use of the Echo option, see Appendix B.1.2. If an endpoint makes use of a partial security context stored in nonvolatile memory, it MUST NOT reuse a previous Sender Sequence Number and MUST NOT accept previously received messages.
1. 在更新安全上下文的可变部分（发送方序列号和重播窗口）后，端点可以重用现有的安全上下文。这要求安全上下文的可变部分在设备的整个生命周期内都可用，或者在可变安全上下文数据丢失后，设备可以建立新的安全上下文。示例基于非易失性存储器的谨慎使用（见附录B.1.1）和回声选项的使用（见附录B.1.2）。如果端点使用存储在非易失性内存中的部分安全上下文，则它不得重用以前的发送方序列号，也不得接受以前收到的消息。
2. The endpoints can reuse an existing shared Master Secret and derive new Sender and Recipient Contexts, see Appendix B.2 for an example. This typically requires a good source of randomness.
2. 端点可以重用现有的共享主密钥并派生新的发送方和接收方上下文，有关示例，请参见附录B.2。这通常需要一个良好的随机性来源。
3. The endpoints can use a trusted third-party-assisted key establishment protocol such as [OSCORE-PROFILE]. This requires the execution of a three-party protocol and may require a good source of randomness.
3. 端点可以使用可信的第三方辅助密钥建立协议，如[OSCORE-PROFILE]。这需要执行三方协议，并且可能需要良好的随机性来源。
4. The endpoints can run a key exchange protocol providing forward secrecy resulting in a fresh Master Secret, from which an entirely new Security Context is derived. This requires a good source of randomness, and additionally, the transmission and processing of the protocol may have a non-negligible cost, e.g., in terms of power consumption.
4. 端点可以运行提供前向保密性的密钥交换协议，从而产生一个新的主密钥，从中派生出一个全新的安全上下文。这需要良好的随机性源，此外，协议的传输和处理可能具有不可忽略的成本，例如，在功耗方面。
The endpoints need to be configured with information about which method is used. The choice of method may depend on capabilities of the devices deployed and the solution architecture. Using a key exchange protocol is necessary for deployments that require forward secrecy.
端点需要配置有关使用哪种方法的信息。方法的选择可能取决于所部署设备的能力和解决方案体系结构。对于需要前向保密的部署，必须使用密钥交换协议。
This section describes the OSCORE message processing. Additional processing for Observe or Block-wise are described in subsections.
本节介绍OSCORE消息处理。观察或分块的附加处理在小节中描述。
Note that, analogously to [RFC7252] where the Token and source/ destination pair are used to match a response with a request, both endpoints MUST keep the association (Token, {Security Context, Partial IV of the request}), in order to be able to find the Security Context and compute the AAD to protect or verify the response. The association MAY be forgotten after it has been used to successfully protect or verify the response, with the exception of Observe processing, where the association MUST be kept as long as the Observation is active.
注意，与[RFC7252]类似，在[RFC7252]中，令牌和源/目标对用于将响应与请求匹配，两个端点必须保持关联（令牌，{Security Context，Partial IV of the request}），以便能够找到安全上下文并计算AAD以保护或验证响应。在成功保护或验证响应后，关联可能会被遗忘，但观察处理除外，只要观察处于活动状态，关联就必须保持。
The processing of the Sender Sequence Number follows the procedure described in Section 3 of [IV-GEN].
发送方序列号的处理遵循[IV-GEN]第3节所述的程序。
Given a CoAP request, the client SHALL perform the following steps to create an OSCORE request:
给定CoAP请求，客户应执行以下步骤创建OSCORE请求：
1. Retrieve the Sender Context associated with the target resource.
1. 检索与目标资源关联的发件人上下文。
2. Compose the AAD and the plaintext, as described in Sections 5.3 and 5.4.
2. 如第5.3节和第5.4节所述，编写AAD和纯文本。
3. Encode the Partial IV (Sender Sequence Number in network byte order) and increment the Sender Sequence Number by one. Compute the AEAD nonce from the Sender ID, Common IV, and Partial IV as described in Section 5.2.
3. 对部分IV（网络字节顺序的发送方序列号）进行编码，并将发送方序列号增加1。如第5.2节所述，根据发送方ID、公共IV和部分IV计算AEAD nonce。
4. Encrypt the COSE object using the Sender Key. Compress the COSE object as specified in Section 6.
4. 使用发送方密钥加密COSE对象。按照第6节的规定压缩COSE对象。
5. Format the OSCORE message according to Section 4. The OSCORE option is added (see Section 4.1.2).
5. 根据第4节格式化OSCORE消息。增加了OSCORE选项（见第4.1.2节）。
A server receiving a request containing the OSCORE option SHALL perform the following steps:
接收包含OSCORE选项的请求的服务器应执行以下步骤：
1. Discard Code and all Class E options (marked in Figure 5 with 'x' in column E) present in the received message. For example, an If-Match Outer option is discarded, but an Uri-Host Outer option is not discarded.
1. 丢弃接收到的消息中存在的代码和所有E类选项（在图5中用E列中的“x”标记）。例如，将放弃If Match外部选项，但不会放弃Uri主机外部选项。
2. Decompress the COSE object (Section 6) and retrieve the Recipient Context associated with the Recipient ID in the 'kid' parameter, additionally using the 'kid context', if present. Note that the Recipient Context MAY be retrieved by deriving a new security context, e.g. as described in Appendix B.2. If either the decompression or the COSE message fails to decode, or the server fails to retrieve a Recipient Context with Recipient ID corresponding to the 'kid' parameter received, then the server SHALL stop processing the request.
2. 解压缩COSE对象（第6节），并在“kid”参数中检索与收件人ID关联的收件人上下文，如果存在，还可以使用“kid Context”。请注意，可通过派生新的安全上下文来检索收件人上下文，如附录B.2所述。如果解压或COSE消息未能解码，或者服务器未能检索到收件人ID与接收到的“kid”参数对应的收件人上下文，则服务器应停止处理该请求。
* If either the decompression or the COSE message fails to decode, the server MAY respond with a 4.02 (Bad Option) error message. The server MAY set an Outer Max-Age option with value zero. The diagnostic payload MAY contain the string "Failed to decode COSE".
* 如果解压或COSE消息未能解码，服务器可能会响应4.02（错误选项）错误消息。服务器可以设置值为零的外部最大年龄选项。诊断有效负载可能包含字符串“未能解码COSE”。
* If the server fails to retrieve a Recipient Context with Recipient ID corresponding to the 'kid' parameter received, the server MAY respond with a 4.01 (Unauthorized) error message. The server MAY set an Outer Max-Age option with value zero. The diagnostic payload MAY contain the string "Security context not found".
* 如果服务器检索到收件人ID与接收到的“kid”参数对应的收件人上下文失败，服务器可能会响应4.01（未经授权）错误消息。服务器可以设置值为零的外部最大年龄选项。诊断有效负载可能包含字符串“未找到安全上下文”。
3. Verify that the Partial IV has not been received before using the Replay Window, as described in Section 7.4.
3. 如第7.4节所述，在使用回放窗口之前，确认未收到部分IV。
4. Compose the AAD, as described in Section 5.4.
4. 如第5.4节所述，组成AAD。
5. Compute the AEAD nonce from the Recipient ID, Common IV, and the Partial IV, received in the COSE object.
5. 从COSE对象中接收的收件人ID、公共IV和部分IV计算AEAD nonce。
6. Decrypt the COSE object using the Recipient Key, as per Section 5.3 of [RFC8152]. (The decrypt operation includes the verification of the integrity.)
6. 根据[RFC8152]第5.3节，使用收件人密钥解密COSE对象。（解密操作包括完整性验证。）
* If decryption fails, the server MUST stop processing the request and MAY respond with a 4.00 (Bad Request) error message. The server MAY set an Outer Max-Age option with value zero. The diagnostic payload MAY contain the string "Decryption failed".
* 如果解密失败，服务器必须停止处理请求，并可能会以4.00（错误请求）错误消息响应。服务器可以设置值为零的外部最大年龄选项。诊断有效负载可能包含字符串“解密失败”。
* If decryption succeeds, update the Replay Window, as described in Section 7.
* 如果解密成功，请更新重播窗口，如第7节所述。
7. Add decrypted Code, options, and payload to the decrypted request. The OSCORE option is removed.
7. 将解密的代码、选项和有效负载添加到解密的请求中。OSCORE选项将被删除。
8. The decrypted CoAP request is processed according to [RFC7252].
8. 根据[RFC7252]处理解密的CoAP请求。
If Block-wise is supported, insert the following step before any other:
如果支持分块，请在任何其他步骤之前插入以下步骤：
A. If Block-wise is present in the request, then process the Outer Block options according to [RFC7959], until all blocks of the request have been received (see Section 4.1.3.4).
A.如果请求中存在分块，则根据[RFC7959]处理外部块选项，直到收到请求的所有块（见第4.1.3.4节）。
If a CoAP response is generated in response to an OSCORE request, the server SHALL perform the following steps to create an OSCORE response. Note that CoAP error responses derived from CoAP processing (step 8 in Section 8.2) are protected, as well as successful CoAP responses, while the OSCORE errors (steps 2, 3, and 6 in Section 8.2) do not follow the processing below but are sent as simple CoAP responses, without OSCORE processing.
如果响应OSCORE请求生成CoAP响应，则服务器应执行以下步骤以创建OSCORE响应。请注意，从CoAP处理（第8.2节中的步骤8）导出的CoAP错误响应以及成功的CoAP响应都受到保护，而OSCORE错误（第8.2节中的步骤2、3和6）不遵循以下处理，而是作为简单的CoAP响应发送，而不进行OSCORE处理。
1. Retrieve the Sender Context in the Security Context associated with the Token.
1. 在与令牌关联的安全上下文中检索发送方上下文。
2. Compose the AAD and the plaintext, as described in Sections 5.3 and 5.4.
2. 如第5.3节和第5.4节所述，编写AAD和纯文本。
3. Compute the AEAD nonce as described in Section 5.2:
3. 按照第5.2节所述计算AEAD nonce：
* Either use the AEAD nonce from the request, or
* 使用请求中的AEAD nonce，或
* Encode the Partial IV (Sender Sequence Number in network byte order) and increment the Sender Sequence Number by one. Compute the AEAD nonce from the Sender ID, Common IV, and Partial IV.
* 对部分IV（网络字节顺序的发送方序列号）进行编码，并将发送方序列号增加1。根据发送方ID、公共IV和部分IV计算AEAD nonce。
4. Encrypt the COSE object using the Sender Key. Compress the COSE object as specified in Section 6. If the AEAD nonce was constructed from a new Partial IV, this Partial IV MUST be included in the message. If the AEAD nonce from the request was used, the Partial IV MUST NOT be included in the message.
4. 使用发送方密钥加密COSE对象。按照第6节的规定压缩COSE对象。如果AEAD nonce是从新的部分IV构造的，则该部分IV必须包含在消息中。如果使用了请求中的AEAD nonce，则消息中不得包含部分IV。
5. Format the OSCORE message according to Section 4. The OSCORE option is added (see Section 4.1.2).
5. 根据第4节格式化OSCORE消息。增加了OSCORE选项（见第4.1.2节）。
If Observe is supported, insert the following step between steps 2 and 3 of Section 8.3:
如果支持观察，则在第8.3节的步骤2和3之间插入以下步骤：
A. If the response is an Observe notification:
A.如果响应为观察通知：
o If the response is the first notification:
o 如果响应是第一个通知：
* compute the AEAD nonce as described in Section 5.2:
* 按照第5.2节所述计算AEAD nonce：
+ Either use the AEAD nonce from the request, or
+ 使用请求中的AEAD nonce，或
+ Encode the Partial IV (Sender Sequence Number in network byte order) and increment the Sender Sequence Number by one. Compute the AEAD nonce from the Sender ID, Common IV, and Partial IV.
+ 对部分IV（网络字节顺序的发送方序列号）进行编码，并将发送方序列号增加1。根据发送方ID、公共IV和部分IV计算AEAD nonce。
Then, go to 4.
然后，转到4。
o If the response is not the first notification:
o 如果响应不是第一次通知：
* encode the Partial IV (Sender Sequence Number in network byte order) and increment the Sender Sequence Number by one. Compute the AEAD nonce from the Sender ID, Common IV, and Partial IV, then go to 4.
* 对部分IV（网络字节顺序的发送方序列号）进行编码，并将发送方序列号增加1。根据发送方ID、公共IV和部分IV计算AEAD nonce，然后转到4。
A client receiving a response containing the OSCORE option SHALL perform the following steps:
接收到包含OSCORE选项的响应的客户端应执行以下步骤：
1. Discard Code and all Class E options (marked in Figure 5 with 'x' in column E) present in the received message. For example, ETag Outer option is discarded, as well as Max-Age Outer option.
1. 丢弃接收到的消息中存在的代码和所有E类选项（在图5中用E列中的“x”标记）。例如，ETag外部选项和最大年限外部选项都将被放弃。
2. Retrieve the Recipient Context in the Security Context associated with the Token. Decompress the COSE object (Section 6). If either the decompression or the COSE message fails to decode, then go to 8.
2. 在与令牌关联的安全上下文中检索收件人上下文。解压缩COSE对象（第6节）。如果解压或COSE消息解码失败，则转到8。
3. Compose the AAD, as described in Section 5.4.
3. 如第5.4节所述，组成AAD。
4. Compute the AEAD nonce
4. 计算AEAD nonce
* If the Partial IV is not present in the response, the AEAD nonce from the request is used.
* 如果响应中不存在部分IV，则使用来自请求的AEAD nonce。
* If the Partial IV is present in the response, compute the AEAD nonce from the Recipient ID, Common IV, and the Partial IV, received in the COSE object.
* 如果部分IV存在于响应中，则根据接收方ID、公共IV和在COSE对象中接收的部分IV计算AEAD nonce。
5. Decrypt the COSE object using the Recipient Key, as per Section 5.3 of [RFC8152]. (The decrypt operation includes the verification of the integrity.) If decryption fails, then go to 8.
5. 根据[RFC8152]第5.3节，使用收件人密钥解密COSE对象。（解密操作包括完整性验证。）如果解密失败，则转到8。
6. Add decrypted Code, options and payload to the decrypted request. The OSCORE option is removed.
6. 将解密的代码、选项和有效负载添加到解密的请求中。OSCORE选项将被删除。
7. The decrypted CoAP response is processed according to [RFC7252].
7. 根据[RFC7252]处理解密的CoAP响应。
8. In case any of the previous erroneous conditions apply: the client SHALL stop processing the response.
8. 如果适用任何先前的错误条件：客户应停止处理响应。
If Block-wise is supported, insert the following step before any other:
如果支持分块，请在任何其他步骤之前插入以下步骤：
A. If Block-wise is present in the response, then process the Outer Block options according to [RFC7959], until all blocks of the response have been received (see Section 4.1.3.4).
A.如果响应中存在分块，则根据[RFC7959]处理外部分块选项，直到收到响应的所有分块（见第4.1.3.4节）。
If Observe is supported:
如果支持观察：
Insert the following step between step 5 and step 6:
在步骤5和步骤6之间插入以下步骤：
A. If the request was an Observe registration, then:
A.如果请求是观察注册，则：
o If the Partial IV is not present in the response, and the Inner Observe option is present, and the AEAD nonce from the request was already used once, then go to 8.
o 如果响应中不存在部分IV，并且存在内部观察选项，并且请求中的AEAD nonce已经使用过一次，则转到8。
o If the Partial IV is present in the response and the Inner Observe option is present, then follow the processing described in Section 4.1.3.5.2 and Section 7.4.1, then:
o 如果响应中存在部分IV，且存在内部观察选项，则按照第4.1.3.5.2节和第7.4.1节中描述的处理，然后：
* initialize the Notification Number (if first successfully verified notification), or
* 初始化通知编号（如果首次成功验证通知），或
* overwrite the Notification Number (if the received Partial IV was greater than the Notification Number).
* 覆盖通知编号（如果收到的部分IV大于通知编号）。
Replace step 8 of Section 8.4 with:
将第8.4节的步骤8替换为：
B. In case any of the previous erroneous conditions apply: the client SHALL stop processing the response. An error condition occurring while processing a response to an observation request does not cancel the observation. A client MUST NOT react to failure by re-registering the observation immediately.
B.如果之前的任何错误条件适用：客户应停止处理响应。处理对观察请求的响应时发生的错误情况不会取消观察。客户端不得通过立即重新注册观察结果来对故障作出反应。
The use of OSCORE MAY be indicated by a target "osc" attribute in a web link [RFC8288] to a resource, e.g., using a link-format document [RFC6690] if the resource is accessible over CoAP.
OSCORE的使用可通过指向资源的web链接[RFC8288]中的目标“osc”属性来指示，例如，如果资源可通过CoAP访问，则使用链接格式文档[RFC6690]。
The "osc" attribute is a hint indicating that the destination of that link is only accessible using OSCORE, and unprotected access to it is not supported. Note that this is simply a hint, it does not include any security context material or any other information required to run OSCORE.
“osc”属性是一个提示，表明该链接的目的地只能使用OSCORE访问，不支持对其进行无保护的访问。请注意，这只是一个提示，它不包括任何安全上下文材料或运行OSCORE所需的任何其他信息。
A value MUST NOT be given for the "osc" attribute; any present value MUST be ignored by parsers. The "osc" attribute MUST NOT appear more than once in a given link-value; occurrences after the first MUST be ignored by parsers.
不得为“osc”属性指定值；解析器必须忽略任何当前值。“osc”属性在给定链接值中不得出现多次；解析器必须忽略第一个事件之后出现的事件。
The example in Figure 11 shows a use of the "osc" attribute: the client does resource discovery on a server and gets back a list of resources, one of which includes the "osc" attribute indicating that the resource is protected with OSCORE. The link-format notation (see Section 5 of [RFC6690]) is used.
图11中的示例显示了“osc”属性的用法：客户机在服务器上进行资源发现，并返回一个资源列表，其中一个包括“osc”属性，该属性指示资源受OSCORE保护。使用链接格式符号（见[RFC6690]第5节）。
REQ: GET /.well-known/core
REQ: GET /.well-known/core
RES: 2.05 Content
</sensors/temp>;osc,
</sensors/light>;if="sensor"
RES: 2.05 Content
</sensors/temp>;osc,
</sensors/light>;if="sensor"
Figure 11: The Web Link
图11：Web链接
CoAP is designed for proxy operations (see Section 5.7 of [RFC7252]).
CoAP设计用于代理操作（见[RFC7252]第5.7节）。
OSCORE is designed to work with OSCORE-unaware CoAP proxies. Security requirements for forwarding are listed in Section 2.2.1 of [CoAP-E2E-Sec]. Proxy processing of the (Outer) Proxy-Uri option works as defined in [RFC7252]. Proxy processing of the (Outer) Block options works as defined in [RFC7959].
OSCORE设计用于与OSCORE代理协作。[CoAP-E2E-Sec]第2.2.1节列出了转发的安全要求。（外部）代理Uri选项的代理处理按照[RFC7252]中的定义工作。（外部）块选项的代理处理按照[RFC7959]中的定义工作。
However, not all CoAP proxy operations are useful:
但是，并非所有CoAP代理操作都有用：
o Since a CoAP response is only applicable to the original CoAP request, caching is in general not useful. In support of existing proxies, OSCORE uses the Outer Max-Age option, see Section 4.1.3.1.
o 由于CoAP响应仅适用于原始CoAP请求，因此缓存通常没有用处。为支持现有代理，OSCORE使用外部最大年龄选项，见第4.1.3.1节。
o Proxy processing of the (Outer) Observe option as defined in [RFC7641] is specified in Section 4.1.3.5.
o 第4.1.3.5节规定了[RFC7641]中定义的（外部）观察选项的代理处理。
Optionally, a CoAP proxy MAY detect OSCORE and act accordingly. An OSCORE-aware CoAP proxy:
可选地，CoAP代理可以检测OSCORE并相应地采取行动。支持OSCORE的CoAP代理：
o SHALL bypass caching for the request if the OSCORE option is present.
o 如果存在OSCORE选项，则应绕过请求的缓存。
o SHOULD avoid caching responses to requests with an OSCORE option.
o 应避免使用OSCORE选项缓存对请求的响应。
In the case of Observe (see Section 4.1.3.5), the OSCORE-aware CoAP proxy:
在观察的情况下（见第4.1.3.5节），支持OSCORE的CoAP代理：
o SHALL NOT initiate an Observe registration.
o 不得发起注册。
o MAY verify the order of notifications using Partial IV rather than the Observe option.
o 可以使用Partial IV而不是Observe选项验证通知顺序。
The CoAP request/response model may be mapped to HTTP and vice versa as described in Section 10 of [RFC7252]. The HTTP-CoAP mapping is further detailed in [RFC8075]. This section defines the components needed to map and transport OSCORE messages over HTTP hops. By mapping between HTTP and CoAP and by using cross-protocol proxies, OSCORE may be used end-to-end between, e.g., an HTTP client and a CoAP server. Examples are provided in Sections 11.5 and 11.6.
CoAP请求/响应模型可以映射到HTTP，反之亦然，如[RFC7252]第10节所述。[RFC8075]中进一步详细介绍了HTTP CoAP映射。本节定义了通过HTTP跃点映射和传输OSCORE消息所需的组件。通过HTTP和CoAP之间的映射以及使用跨协议代理，可以在HTTP客户端和CoAP服务器之间端到端地使用OSCORE。第11.5节和第11.6节提供了示例。
The HTTP OSCORE header field (see Section 13.4) is used for carrying the content of the CoAP OSCORE option when transporting OSCORE messages over HTTP hops.
HTTP OSCORE头字段（见第13.4节）用于在HTTP跃点上传输OSCORE消息时承载CoAP OSCORE选项的内容。
The HTTP OSCORE header field is only used in POST requests and responses with HTTP Status Code 200 (OK). When used, the HTTP header field Content-Type is set to 'application/oscore' (see Section 13.5) indicating that the HTTP body of this message contains the OSCORE payload (see Section 6.2). No additional semantics are provided by other message fields.
HTTP OSCORE头字段仅用于HTTP状态代码为200（OK）的POST请求和响应。使用时，HTTP头字段内容类型设置为“应用程序/oscore”（参见第13.5节），表示此消息的HTTP正文包含oscore有效负载（参见第6.2节）。其他消息字段不提供其他语义。
Using the Augmented Backus-Naur Form (ABNF) notation of [RFC5234], including the following core ABNF syntax rules defined by that specification: ALPHA (letters) and DIGIT (decimal digits), the HTTP OSCORE header field value is as follows.
使用[RFC5234]的扩充巴科斯诺尔形式（ABNF）表示法，包括该规范定义的以下核心ABNF语法规则：阿尔法（字母）和数字（十进制数字），HTTP OSCORE头字段值如下所示。
base64url-char = ALPHA / DIGIT / "-" / "_"
base64url-char = ALPHA / DIGIT / "-" / "_"
OSCORE = 2*base64url-char
OSCORE=2*base64url字符
The HTTP OSCORE header field is not appropriate to list in the Connection header field (see Section 6.1 of [RFC7230]) since it is not hop-by-hop. OSCORE messages are generally not useful when served from cache (i.e., they will generally be marked Cache-Control: no-cache) and so interaction with Vary is not relevant (Section 7.1.4 of [RFC7231]). Since the HTTP OSCORE header field is critical for message processing, moving it from headers to trailers renders the message unusable in case trailers are ignored (see Section 4.1 of [RFC7230]).
HTTP OSCORE头字段不适合在连接头字段中列出（请参阅[RFC7230]第6.1节），因为它不是逐跳的。当从缓存提供服务时，OSCORE消息通常不有用（即，它们通常被标记为缓存控制：无缓存），因此与VARIE的交互不相关（RFC7231的第7.1.4节）。由于HTTP OSCORE头字段对于消息处理至关重要，因此将其从头字段移动到尾字段会在忽略尾字段的情况下导致消息不可用（请参见[RFC7230]第4.1节）。
In general, intermediaries are not allowed to insert, delete, or modify the OSCORE header. In general, changes to the HTTP OSCORE header field will violate the integrity of the OSCORE message resulting in an error. For the same reason the HTTP OSCORE header field is generally not preserved across redirects.
通常，不允许中介机构插入、删除或修改OSCORE标头。通常，对HTTP OSCORE头字段的更改会破坏OSCORE消息的完整性，从而导致错误。出于同样的原因，HTTP OSCORE头字段通常不会跨重定向保留。
Since redirects are not defined in the mappings between HTTP and CoAP ([RFC8075] [RFC7252]), a number of conditions need to be fulfilled for redirects to work. For CoAP-client-to-HTTP-server redirects, such conditions include:
由于HTTP和CoAP之间的映射（[RFC8075][RFC7252]）中未定义重定向，因此需要满足许多条件才能使重定向正常工作。对于CoAP客户端到HTTP服务器的重定向，此类条件包括：
o the CoAP-to-HTTP proxy follows the redirect, instead of the CoAP client as in the HTTP case.
o CoAP到HTTP代理遵循重定向，而不是HTTP情况下的CoAP客户端。
o the CoAP-to-HTTP proxy copies the HTTP OSCORE header field and body to the new request.
o CoAP到HTTP代理将HTTP OSCORE头字段和正文复制到新请求。
o the target of the redirect has the necessary OSCORE security context required to decrypt and verify the message.
o 重定向的目标具有解密和验证消息所需的OSCORE安全上下文。
Since OSCORE requires the HTTP body to be preserved across redirects, the HTTP server is RECOMMENDED to reply with 307 (Temporary Redirect) or 308 (Permanent Redirect) instead of 301 (Moved Permanently) or 302 (Found).
由于OSCORE要求跨重定向保留HTTP正文，建议HTTP服务器使用307（临时重定向）或308（永久重定向）而不是301（永久移动）或302（找到）进行回复。
For the case of HTTP-client-to-CoAP-server redirects, although redirect is not defined for CoAP servers [RFC7252], an HTTP client receiving a redirect should generate a new OSCORE request for the server it was redirected to.
对于HTTP客户端到CoAP服务器的重定向，虽然没有为CoAP服务器定义重定向[RFC7252]，但接收重定向的HTTP客户端应为其重定向到的服务器生成新的OSCORE请求。
Section 10.1 of [RFC7252] describes the fundamentals of the CoAP-to-HTTP cross-protocol mapping process. The additional rules for OSCORE messages are as follows:
[RFC7252]的第10.1节描述了CoAP到HTTP跨协议映射过程的基本原理。OSCORE消息的附加规则如下所示：
o The HTTP OSCORE header field value is set to:
o HTTP OSCORE标头字段值设置为：
* AA if the CoAP OSCORE option is empty; otherwise,
* AA如果CoAP OSCORE选项为空；否则
* the value of the CoAP OSCORE option (Section 6.1) in base64url (Section 5 of [RFC4648]) encoding without padding. Implementation notes for this encoding are given in Appendix C of [RFC7515].
* base64url（RFC4648的第5节）编码中不带填充的CoAP OSCORE选项（第6.1节）的值。[RFC7515]的附录C中给出了该编码的实施说明。
o The HTTP Content-Type is set to 'application/oscore' (see Section 13.5), independent of CoAP Content-Format.
o HTTP内容类型设置为“应用程序/oscore”（参见第13.5节），与CoAP内容格式无关。
Section 10.2 of [RFC7252] and [RFC8075] specify the behavior of an HTTP-to-CoAP proxy. The additional rules for HTTP messages with the OSCORE header field are as follows.
[RFC7252]和[RFC8075]的第10.2节规定了HTTP到CoAP代理的行为。具有OSCORE头字段的HTTP消息的附加规则如下所示。
o The CoAP OSCORE option is set as follows:
o CoAP OSCORE选项设置如下：
* empty if the value of the HTTP OSCORE header field is a single zero byte (0x00) represented by AA; otherwise,
* 如果HTTP OSCORE头字段的值是由AA表示的单个零字节（0x00），则为空；否则
* the value of the HTTP OSCORE header field decoded from base64url (Section 5 of [RFC4648]) without padding. Implementation notes for this encoding are given in Appendix C of [RFC7515].
* 从base64url（RFC4648的第5节）解码的HTTP OSCORE头字段的值，不带填充。[RFC7515]的附录C中给出了该编码的实施说明。
o The CoAP Content-Format option is omitted, the content format for OSCORE (Section 13.6) MUST NOT be used.
o 省略CoAP内容格式选项，不得使用OSCORE的内容格式（第13.6节）。
Restricted to subsets of HTTP and CoAP supporting a bijective mapping, OSCORE can be originated or terminated in HTTP endpoints.
仅限于支持双射映射的HTTP和CoAP子集，OSCORE可以在HTTP端点中发起或终止。
The sending HTTP endpoint uses [RFC8075] to translate the HTTP message into a CoAP message. The CoAP message is then processed with OSCORE as defined in this document. The OSCORE message is then mapped to HTTP as described in Section 11.2 and sent in compliance with the rules in Section 11.1.
发送HTTP端点使用[RFC8075]将HTTP消息转换为CoAP消息。然后使用本文档中定义的OSCORE处理CoAP消息。然后，按照第11.2节所述，将OSCORE消息映射到HTTP，并按照第11.1节中的规则发送。
The receiving HTTP endpoint maps the HTTP message to a CoAP message using [RFC8075] and Section 11.3. The resulting OSCORE message is processed as defined in this document. If successful, the plaintext CoAP message is translated to HTTP for normal processing in the endpoint.
接收HTTP端点使用[RFC8075]和第11.3节将HTTP消息映射到CoAP消息。生成的OSCORE消息将按照本文档中的定义进行处理。如果成功，则将明文CoAP消息转换为HTTP，以便在端点中进行正常处理。
This section gives an example of what a request and a response between an HTTP client and a CoAP server could look like. The example is not a test vector but intended as an illustration of how the message fields are translated in the different steps.
本节给出了HTTP客户端和CoAP服务器之间的请求和响应的示例。该示例不是测试向量，而是用于说明如何在不同步骤中转换消息字段。
Mapping and notation here is based on "Simple Form" (Section 5.4.1 of [RFC8075]).
此处的映射和符号基于“简单形式”（RFC8075第5.4.1节）。
[HTTP request -- Before client object security processing]
[HTTP请求--在客户端对象安全处理之前]
GET http://proxy.url/hc/?target_uri=coap://server.url/orders
HTTP/1.1
GET http://proxy.url/hc/?target_uri=coap://server.url/orders
HTTP/1.1
[HTTP request -- HTTP Client to Proxy]
[HTTP请求--HTTP客户端到代理]
POST http://proxy.url/hc/?target_uri=coap://server.url/ HTTP/1.1
Content-Type: application/oscore
OSCORE: CSU
Body: 09 07 01 13 61 f7 0f d2 97 b1 [binary]
POST http://proxy.url/hc/?target_uri=coap://server.url/ HTTP/1.1
Content-Type: application/oscore
OSCORE: CSU
Body: 09 07 01 13 61 f7 0f d2 97 b1 [binary]
[CoAP request -- Proxy to CoAP Server]
[CoAP请求--到CoAP服务器的代理]
POST coap://server.url/
OSCORE: 09 25
Payload: 09 07 01 13 61 f7 0f d2 97 b1 [binary]
POST coap://server.url/
OSCORE: 09 25
Payload: 09 07 01 13 61 f7 0f d2 97 b1 [binary]
[CoAP request -- After server object security processing]
[CoAP请求--服务器对象安全处理后]
GET coap://server.url/orders
GET coap://server.url/orders
[CoAP response -- Before server object security processing]
[CoAP响应--服务器对象安全处理之前]
2.05 Content Content-Format: 0 Payload: Exterminate! Exterminate!
2.05 内容格式：0有效负载：清除！灭绝
[CoAP response -- CoAP Server to Proxy]
[CoAP响应--CoAP服务器到代理]
2.04 Changed OSCORE: [empty] Payload: 00 31 d1 fc f6 70 fb 0c 1d d5 ... [binary]
2.04 更改的OSCORE:[空]有效负载：00 31 d1 fc f6 70 fb 0c 1d d5。。。[二进制]
[HTTP response -- Proxy to HTTP Client]
[HTTP响应--HTTP客户端的代理]
HTTP/1.1 200 OK
Content-Type: application/oscore
OSCORE: AA
Body: 00 31 d1 fc f6 70 fb 0c 1d d5 ... [binary]
HTTP/1.1 200 OK
Content-Type: application/oscore
OSCORE: AA
Body: 00 31 d1 fc f6 70 fb 0c 1d d5 ... [binary]
[HTTP response -- After client object security processing]
[HTTP响应--在客户端对象安全处理之后]
HTTP/1.1 200 OK
Content-Type: text/plain
Body: Exterminate! Exterminate!
HTTP/1.1 200 OK
Content-Type: text/plain
Body: Exterminate! Exterminate!
Note that the HTTP Status Code 200 (OK) in the next-to-last message is the mapping of CoAP Code 2.04 (Changed), whereas the HTTP Status Code 200 (OK) in the last message is the mapping of the CoAP Code 2.05 (Content), which was encrypted within the compressed COSE object carried in the Body of the HTTP response.
请注意，上一条消息中的HTTP状态代码200（OK）是CoAP代码2.04（更改）的映射，而上一条消息中的HTTP状态代码200（OK）是CoAP代码2.05（内容）的映射，该映射在HTTP响应主体中携带的压缩COSE对象内加密。
This section gives an example of what a request and a response between a CoAP client and an HTTP server could look like. The example is not a test vector but intended as an illustration of how the message fields are translated in the different steps.
本节给出了CoAP客户端和HTTP服务器之间的请求和响应的示例。该示例不是测试向量，而是用于说明如何在不同步骤中转换消息字段。
[CoAP request -- Before client object security processing]
[CoAP请求--在客户端对象安全处理之前]
GET coap://proxy.url/
Proxy-Uri=http://server.url/orders
GET coap://proxy.url/
Proxy-Uri=http://server.url/orders
[CoAP request -- CoAP Client to Proxy]
[CoAP请求——CoAP客户端到代理]
POST coap://proxy.url/
Proxy-Uri=http://server.url/
OSCORE: 09 25
Payload: 09 07 01 13 61 f7 0f d2 97 b1 [binary]
POST coap://proxy.url/
Proxy-Uri=http://server.url/
OSCORE: 09 25
Payload: 09 07 01 13 61 f7 0f d2 97 b1 [binary]
[HTTP request -- Proxy to HTTP Server]
[HTTP请求--HTTP服务器的代理]
POST http://server.url/ HTTP/1.1
Content-Type: application/oscore
OSCORE: CSU
Body: 09 07 01 13 61 f7 0f d2 97 b1 [binary]
POST http://server.url/ HTTP/1.1
Content-Type: application/oscore
OSCORE: CSU
Body: 09 07 01 13 61 f7 0f d2 97 b1 [binary]
[HTTP request -- After server object security processing]
[HTTP请求--服务器对象安全处理后]
GET http://server.url/orders HTTP/1.1
GET http://server.url/orders HTTP/1.1
[HTTP response -- Before server object security processing]
[HTTP响应--在服务器对象安全处理之前]
HTTP/1.1 200 OK
Content-Type: text/plain
Body: Exterminate! Exterminate!
HTTP/1.1 200 OK
Content-Type: text/plain
Body: Exterminate! Exterminate!
[HTTP response -- HTTP Server to Proxy]
[HTTP响应--HTTP服务器到代理]
HTTP/1.1 200 OK
Content-Type: application/oscore
OSCORE: AA
Body: 00 31 d1 fc f6 70 fb 0c 1d d5 ... [binary]
HTTP/1.1 200 OK
Content-Type: application/oscore
OSCORE: AA
Body: 00 31 d1 fc f6 70 fb 0c 1d d5 ... [binary]
[CoAP response -- Proxy to CoAP Client]
[CoAP响应——CoAP客户端的代理]
2.04 Changed OSCORE: [empty] Payload: 00 31 d1 fc f6 70 fb 0c 1d d5 ... [binary]
2.04 更改的OSCORE:[空]有效负载：00 31 d1 fc f6 70 fb 0c 1d d5。。。[二进制]
[CoAP response -- After client object security processing]
[CoAP响应--客户端对象安全处理后]
2.05 Content Content-Format: 0 Payload: Exterminate! Exterminate!
2.05 内容格式：0有效负载：清除！灭绝
Note that the HTTP Code 2.04 (Changed) in the next-to-last message is the mapping of HTTP Status Code 200 (OK), whereas the CoAP Code 2.05 (Content) in the last message is the value that was encrypted within the compressed COSE object carried in the Body of the HTTP response.
请注意，上一条消息中的HTTP代码2.04（更改）是HTTP状态代码200（确定）的映射，而上一条消息中的CoAP代码2.05（内容）是在HTTP响应主体中携带的压缩COSE对象内加密的值。
An overview of the security properties is given in Appendix D.
附录D中给出了安全属性的概述。
In scenarios with intermediary nodes such as proxies or gateways, transport layer security such as (D)TLS only protects data hop-by-hop. As a consequence, the intermediary nodes can read and modify any information. The trust model where all intermediary nodes are considered trustworthy is problematic, not only from a privacy perspective, but also from a security perspective, as the intermediaries are free to delete resources on sensors and falsify commands to actuators (such as "unlock door", "start fire alarm", "raise bridge"). Even in the rare cases where all the owners of the intermediary nodes are fully trusted, attacks and data breaches make such an architecture brittle.
在具有中间节点（如代理或网关）的场景中，传输层安全性（如（D）TLS）仅逐跳保护数据。因此，中间节点可以读取和修改任何信息。所有中间节点都被认为是可信的信任模型是有问题的，不仅从隐私角度来看，而且从安全角度来看，因为中间节点可以自由删除传感器上的资源，并伪造对执行器的命令（如“解锁门”、“启动火警”、“升起桥”）。即使在极少数情况下，中间节点的所有所有者都完全受信任，攻击和数据泄露也会使这种体系结构变得脆弱。
(D)TLS protects hop-by-hop the entire message. OSCORE protects end-to-end all information that is not required for proxy operations (see Section 4). (D)TLS and OSCORE can be combined, thereby enabling end-to-end security of the message payload, in combination with hop-by-hop protection of the entire message, during transport between endpoint and intermediary node. In particular, when OSCORE is used with HTTP, the additional TLS protection of HTTP hops is RECOMMENDED, e.g., between an HTTP endpoint and a proxy translating between HTTP and CoAP.
（D） TLS逐跳保护整个消息。OSCORE保护端到端代理操作不需要的所有信息（参见第4节）。（D） TLS和OSCORE可以结合使用，从而在端点和中间节点之间的传输期间，结合对整个消息的逐跳保护，实现消息有效负载的端到端安全。特别是，当OSCORE与HTTP一起使用时，建议对HTTP跳进行额外的TLS保护，例如，在HTTP端点和HTTP与CoAP之间转换的代理之间。
Applications need to consider that certain message fields and messages types are not protected end-to-end and may be spoofed or manipulated. The consequences of unprotected message fields are analyzed in Appendix D.5.
应用程序需要考虑某些消息字段和消息类型不受端到端保护，可能会被欺骗或操作。附录D.5分析了未受保护的消息字段的后果。
The use of COSE_Encrypt0 and AEAD to protect messages as specified in this document requires an established security context. The method to establish the security context described in Section 3.2 is based on a common Master Secret and unique Sender IDs. The necessary input parameters may be preestablished or obtained using a key establishment protocol augmented with establishment of Sender/ Recipient ID, such as a key exchange protocol or the OSCORE profile of the Authentication and Authorization for Constrained Environments (ACE) framework [OSCORE-PROFILE]. Such a procedure must ensure that the requirements of the security context parameters for the intended use are complied with (see Section 3.3) even in error situations. While recipient IDs are allowed to coincide between different security contexts (see Section 3.3), this may cause a server to process multiple verifications before finding the right security context or rejecting a message. Considerations for deploying OSCORE with a fixed Master Secret are given in Appendix B.
使用COSE_Encrypt0和AEAD保护本文档中指定的消息需要建立安全上下文。第3.2节中描述的建立安全上下文的方法基于公共主密钥和唯一发送方ID。必要的输入参数可以使用通过建立发送者/接收者ID而增强的密钥建立协议预先建立或获得，例如密钥交换协议或受限环境认证和授权（ACE）框架的OSCORE简档[OSCORE-profile]。该程序必须确保即使在错误情况下也符合预期用途的安全上下文参数要求（见第3.3节）。虽然允许收件人ID在不同的安全上下文之间重合（参见第3.3节），但这可能会导致服务器在找到正确的安全上下文或拒绝消息之前处理多次验证。附录B中给出了使用固定主密钥部署OSCORE的注意事项。
OSCORE uses HKDF [RFC5869] and the established input parameters to derive the security context. The required properties of the security context parameters are discussed in Section 3.3; in this section, we focus on the Master Secret. In this specification, HKDF denotes the composition of the expand and extract functions as defined in [RFC5869] and the Master Secret is used as Input Keying Material (IKM).
OSCORE使用HKDF[RFC5869]和已建立的输入参数来派生安全上下文。第3.3节讨论了安全上下文参数的所需属性；在本节中，我们将重点介绍主秘密。在本规范中，HKDF表示[RFC5869]中定义的扩展和提取函数的组成，主密钥用作输入键控材料（IKM）。
Informally, HKDF takes as source an IKM containing some good amount of randomness but not necessarily distributed uniformly (or for which an attacker has some partial knowledge) and derive from it one or more cryptographically strong secret keys [RFC5869].
非正式地说，HKDF将包含一定数量的随机性但不一定均匀分布的IKM作为源，并从中派生出一个或多个加密强密钥[RFC5869]。
Therefore, the main requirement for the OSCORE Master Secret, in addition to being secret, is that it have a good amount of randomness. The selected key establishment schemes must ensure that the necessary properties for the Master Secret are fulfilled. For pre-shared key deployments and key transport solutions such as [OSCORE-PROFILE], the Master Secret can be generated offline using a good random number generator. Randomness requirements for security are described in [RFC4086].
因此，OSCORE主密钥的主要要求是，除了保密之外，它还具有良好的随机性。所选密钥建立方案必须确保满足主密钥的必要属性。对于预共享密钥部署和密钥传输解决方案，如[OSCORE-PROFILE]，可以使用良好的随机数生成器离线生成主密钥。[RFC4086]中描述了安全性的随机性要求。
Replay attacks need to be considered in different parts of the implementation. Most AEAD algorithms require a unique nonce for each message, for which the Sender Sequence Numbers in the COSE message field 'Partial IV' is used. If the recipient accepts any sequence number larger than the one previously received, then the problem of sequence number synchronization is avoided. With reliable transport, it may be defined that only messages with sequence numbers that are equal to the previous sequence number + 1 are accepted. An adversary may try to induce a device reboot for the purpose of replaying a message (see Section 7.5).
重放攻击需要在实现的不同部分加以考虑。大多数AEAD算法要求每条消息具有唯一的nonce，其中使用COSE消息字段“Partial IV”中的发送方序列号。如果接收方接受任何大于先前接收的序列号的序列号，则可以避免序列号同步问题。对于可靠传输，可以定义为仅接受序列号等于先前序列号+1的消息。对手可能会试图诱导设备重新启动以重播消息（见第7.5节）。
Note that sharing a security context between servers may open up for replay attacks, for example, if the Replay Windows are not synchronized.
请注意，在服务器之间共享安全上下文可能会导致重播攻击，例如，如果重播窗口未同步。
A verified OSCORE request enables the server to verify the identity of the entity who generated the message. However, it does not verify that the client is currently involved in the communication, since the message may be a delayed delivery of a previously generated request, which now reaches the server. To verify the aliveness of the client the server may use the Echo option in the response to a request from the client (see [CoAP-ECHO-REQ-TAG]).
验证的OSCORE请求使服务器能够验证生成消息的实体的身份。但是，它不会验证客户端当前是否参与通信，因为消息可能是先前生成的请求的延迟传递，该请求现在到达服务器。为了验证客户端的有效性，服务器可以在响应客户端的请求时使用Echo选项（参见[CoAP Echo REQ TAG]）。
The maximum Sender Sequence Number is dependent on the AEAD algorithm. The maximum Sender Sequence Number is 2^40 - 1, or any algorithm-specific lower limit, after which a new security context must be generated. The mechanism to build the AEAD nonce (Section 5.2) assumes that the nonce is at least 56 bits, and the Partial IV is at most 40 bits. The mandatory-to-implement AEAD algorithm AES-CCM-16-64-128 is selected for compatibility with CCM*. AEAD algorithms that require unpredictable nonces are not supported.
最大发送方序列号取决于AEAD算法。最大发送方序列号为2^40-1，或任何特定于算法的下限，之后必须生成新的安全上下文。构建AEAD nonce的机制（第5.2节）假设nonce至少为56位，而部分IV最多为40位。选择强制执行AEAD算法AES-CCM-16-64-128是为了与CCM*兼容。不支持需要不可预测的nonce的AEAD算法。
In order to prevent cryptanalysis when the same plaintext is repeatedly encrypted by many different users with distinct AEAD keys, the AEAD nonce is formed by mixing the sequence number with a secret per-context initialization vector (Common IV) derived along with the keys (see Section 3.1 of [RFC8152]), and by using a Master Salt in the key derivation (see [MF00] for an overview). The Master Secret, Sender Key, Recipient Key, and Common IV must be secret, the rest of the parameters may be public. The Master Secret must have a good amount of randomness (see Section 12.3).
当相同的明文被许多不同的用户使用不同的AEAD密钥重复加密时，为了防止密码分析，AEAD nonce是通过将序列号与密钥（参见[RFC8152]第3.1节）一起导出的每上下文初始化向量（公共IV）相混合而形成的，并在密钥派生中使用主盐（参见[MF00]了解概述）。主密钥、发送方密钥、接收方密钥和公共IV必须是机密的，其余参数可能是公共的。主秘密必须具有一定的随机性（见第12.3节）。
The ID Context, Sender ID, and Partial IV are always at least implicitly integrity protected, as manipulation leads to the wrong nonce or key being used and therefore results in decryption failure.
ID上下文、发送方ID和部分IV始终至少受到隐式完整性保护，因为操纵会导致使用错误的nonce或密钥，从而导致解密失败。
The Inner Block options enable the sender to split large messages into OSCORE-protected blocks such that the receiving endpoint can verify blocks before having received the complete message. The Outer Block options allow for arbitrary proxy fragmentation operations that cannot be verified by the endpoints but that can, by policy, be restricted in size since the Inner Block options allow for secure fragmentation of very large messages. A maximum message size (above which the sending endpoint fragments the message and the receiving endpoint discards the message, if complying to the policy) may be obtained as part of normal resource discovery.
内部块选项使发送方能够将大型消息拆分为受OSCORE保护的块，以便接收端点可以在接收完整消息之前验证块。外部块选项允许任意代理碎片操作，这些操作无法由端点验证，但可以根据策略限制大小，因为内部块选项允许对非常大的消息进行安全碎片化。作为正常资源发现的一部分，可以获得最大消息大小（如果符合策略，则发送端点会将消息分段，接收端点会丢弃该消息）。
Privacy threats executed through intermediary nodes are considerably reduced by means of OSCORE. End-to-end integrity protection and encryption of the message payload and all options that are not used for proxy operations provide mitigation against attacks on sensor and actuator communication, which may have a direct impact on the personal sphere.
通过OSCORE，通过中间节点执行的隐私威胁大大减少。消息有效负载的端到端完整性保护和加密以及所有未用于代理操作的选项可缓解对传感器和执行器通信的攻击，这可能会对个人领域产生直接影响。
The unprotected options (Figure 5) may reveal privacy-sensitive information, see Appendix D.5. CoAP headers sent in plaintext allow, for example, matching of CON and ACK (CoAP Message Identifier), matching of request and responses (Token) and traffic analysis. OSCORE does not provide protection for HTTP header fields that are not both CoAP-mappable and Class E. The HTTP message fields that are visible to on-path entities are only used for the purpose of transporting the OSCORE message, whereas the application-layer message is encoded in CoAP and encrypted.
未受保护的选项（图5）可能会泄露隐私敏感信息，见附录D.5。例如，以明文形式发送的CoAP报头允许CON和ACK（CoAP消息标识符）的匹配、请求和响应（令牌）的匹配以及流量分析。OSCORE不为不能同时映射CoAP和E类的HTTP头字段提供保护。路径实体可见的HTTP消息字段仅用于传输OSCORE消息，而应用层消息在CoAP中编码并加密。
COSE message fields, i.e., the OSCORE option, may reveal information about the communicating endpoints. For example, 'kid' and 'kid context', which are intended to help the server find the right context, may reveal information about the client. Tracking 'kid' and 'kid context' to one server may be used for correlating requests from one client.
COSE消息字段，即OSCORE选项，可以显示关于通信端点的信息。例如，“kid”和“kid context”用于帮助服务器找到正确的上下文，可能会显示有关客户端的信息。将“kid”和“kid上下文”跟踪到一台服务器可用于关联来自一个客户端的请求。
Unprotected error messages reveal information about the security state in the communication between the endpoints. Unprotected signaling messages reveal information about the reliable transport
未受保护的错误消息显示有关端点之间通信中安全状态的信息。未受保护的信令消息显示有关可靠传输的信息
used on a leg of the path. Using the mechanisms described in Section 7.5 may reveal when a device goes through a reboot. This can be mitigated by the device storing the precise state of Sender Sequence Number and Replay Window on a clean shutdown.
在小路的一条腿上使用。使用第7.5节中描述的机制可能会揭示设备何时重新启动。这可以通过在干净关机时存储发送方序列号和重播窗口的精确状态来缓解。
The length of message fields can reveal information about the message. Applications may use a padding scheme to protect against traffic analysis.
消息字段的长度可以显示有关消息的信息。应用程序可以使用填充方案来防止流量分析。
The 'kid context' parameter has been added to the "COSE Header Parameters" registry:
“kid context”参数已添加到“COSE头参数”注册表中：
o Name: kid context
o 姓名：kid context
o Label: 10
o 标签：10
o Value Type: bstr
o 值类型：bstr
o Value Registry:
o 值注册表：
o Description: Identifies the context for the key identifier
o 描述：标识密钥标识符的上下文
o Reference: Section 5.1 of this document
o 参考：本文件第5.1节
The OSCORE option has been added to the "CoAP Option Numbers" registry:
OSCORE选项已添加到“CoAP选项编号”注册表中：
+--------+-----------------+-------------------+
| Number | Name | Reference |
+--------+-----------------+-------------------+
| 9 | OSCORE | [RFC8613] |
+--------+-----------------+-------------------+
+--------+-----------------+-------------------+
| Number | Name | Reference |
+--------+-----------------+-------------------+
| 9 | OSCORE | [RFC8613] |
+--------+-----------------+-------------------+
Furthermore, the following existing entries in the "CoAP Option Numbers" registry have been updated with a reference to the document specifying OSCORE processing of that option:
此外，“CoAP选项编号”注册表中的以下现有条目已根据指定该选项OSCORE处理的文件进行更新：
+--------+-----------------+-------------------------------+
| Number | Name | Reference |
+--------+-----------------+-------------------------------+
| 1 | If-Match | [RFC7252] [RFC8613] |
| 3 | Uri-Host | [RFC7252] [RFC8613] |
| 4 | ETag | [RFC7252] [RFC8613] |
| 5 | If-None-Match | [RFC7252] [RFC8613] |
| 6 | Observe | [RFC7641] [RFC8613] |
| 7 | Uri-Port | [RFC7252] [RFC8613] |
| 8 | Location-Path | [RFC7252] [RFC8613] |
| 11 | Uri-Path | [RFC7252] [RFC8613] |
| 12 | Content-Format | [RFC7252] [RFC8613] |
| 14 | Max-Age | [RFC7252] [RFC8613] |
| 15 | Uri-Query | [RFC7252] [RFC8613] |
| 17 | Accept | [RFC7252] [RFC8613] |
| 20 | Location-Query | [RFC7252] [RFC8613] |
| 23 | Block2 | [RFC7959] [RFC8323] [RFC8613] |
| 27 | Block1 | [RFC7959] [RFC8323] [RFC8613] |
| 28 | Size2 | [RFC7959] [RFC8613] |
| 35 | Proxy-Uri | [RFC7252] [RFC8613] |
| 39 | Proxy-Scheme | [RFC7252] [RFC8613] |
| 60 | Size1 | [RFC7252] [RFC8613] |
| 258 | No-Response | [RFC7967] [RFC8613] |
+--------+-----------------+-------------------------------+
+--------+-----------------+-------------------------------+
| Number | Name | Reference |
+--------+-----------------+-------------------------------+
| 1 | If-Match | [RFC7252] [RFC8613] |
| 3 | Uri-Host | [RFC7252] [RFC8613] |
| 4 | ETag | [RFC7252] [RFC8613] |
| 5 | If-None-Match | [RFC7252] [RFC8613] |
| 6 | Observe | [RFC7641] [RFC8613] |
| 7 | Uri-Port | [RFC7252] [RFC8613] |
| 8 | Location-Path | [RFC7252] [RFC8613] |
| 11 | Uri-Path | [RFC7252] [RFC8613] |
| 12 | Content-Format | [RFC7252] [RFC8613] |
| 14 | Max-Age | [RFC7252] [RFC8613] |
| 15 | Uri-Query | [RFC7252] [RFC8613] |
| 17 | Accept | [RFC7252] [RFC8613] |
| 20 | Location-Query | [RFC7252] [RFC8613] |
| 23 | Block2 | [RFC7959] [RFC8323] [RFC8613] |
| 27 | Block1 | [RFC7959] [RFC8323] [RFC8613] |
| 28 | Size2 | [RFC7959] [RFC8613] |
| 35 | Proxy-Uri | [RFC7252] [RFC8613] |
| 39 | Proxy-Scheme | [RFC7252] [RFC8613] |
| 60 | Size1 | [RFC7252] [RFC8613] |
| 258 | No-Response | [RFC7967] [RFC8613] |
+--------+-----------------+-------------------------------+
Future additions to the "CoAP Option Numbers" registry need to provide a reference to the document where the OSCORE processing of that CoAP Option is defined.
“CoAP选项编号”注册表的未来添加内容需要提供对定义该CoAP选项OSCORE处理的文件的参考。
The OSCORE option has been added to the "CoAP Signaling Option Numbers" registry:
OSCORE选项已添加到“CoAP信令选项编号”注册表中：
+------------+--------+---------------------+-------------------+
| Applies to | Number | Name | Reference |
+------------+--------+---------------------+-------------------+
| 7.xx (all) | 9 | OSCORE | [RFC8613] |
+------------+--------+---------------------+-------------------+
+------------+--------+---------------------+-------------------+
| Applies to | Number | Name | Reference |
+------------+--------+---------------------+-------------------+
| 7.xx (all) | 9 | OSCORE | [RFC8613] |
+------------+--------+---------------------+-------------------+
The HTTP OSCORE header field has been added to the "Message Headers" registry:
HTTP OSCORE标头字段已添加到“消息标头”注册表中：
+-------------------+----------+----------+---------------------+
| Header Field Name | Protocol | Status | Reference |
+-------------------+----------+----------+---------------------+
| OSCORE | http | standard | [RFC8613], |
| | | | Section 11.1 |
+-------------------+----------+----------+---------------------+
+-------------------+----------+----------+---------------------+
| Header Field Name | Protocol | Status | Reference |
+-------------------+----------+----------+---------------------+
| OSCORE | http | standard | [RFC8613], |
| | | | Section 11.1 |
+-------------------+----------+----------+---------------------+
This section registers the 'application/oscore' media type in the "Media Types" registry. This media type is used to indicate that the content is an OSCORE message. The OSCORE body cannot be understood without the OSCORE header field value and the security context.
本节在“媒体类型”注册表中注册“应用程序/oscore”媒体类型。此媒体类型用于指示内容是OSCORE消息。如果没有OSCORE头字段值和安全上下文，则无法理解OSCORE正文。
Type name: application
类型名称：应用程序
Subtype name: oscore
子类型名称：oscore
Required parameters: N/A
所需参数：不适用
Optional parameters: N/A
可选参数：不适用
Encoding considerations: binary
编码注意事项：二进制
Security considerations: See the Security Considerations section of [RFC8613].
安全注意事项：请参阅[RFC8613]的安全注意事项部分。
Interoperability considerations: N/A
互操作性注意事项：不适用
Published specification: [RFC8613]
已发布规范：[RFC8613]
Applications that use this media type: IoT applications sending security content over HTTP(S) transports.
使用此媒体类型的应用程序：通过HTTP（S）传输发送安全内容的物联网应用程序。
Fragment identifier considerations: N/A
片段标识符注意事项：不适用
Additional information:
其他信息：
* Deprecated alias names for this type: N/A * Magic number(s): N/A * File extension(s): N/A * Macintosh file type code(s): N/A
* 此类型的不推荐别名：N/A*幻数：N/A*文件扩展名：N/A*Macintosh文件类型代码：N/A
Person & email address to contact for further information:
IESG <iesg@ietf.org>
Person & email address to contact for further information:
IESG <iesg@ietf.org>
Intended usage: COMMON
预期用途：普通
Restrictions on usage: N/A
使用限制：不适用
Author: Goeran Selander <goran.selander@ericsson.com>
Author: Goeran Selander <goran.selander@ericsson.com>
Change Controller: IESG
更改控制器：IESG
Provisional registration? No
临时登记？不
This section registers the media type 'application/oscore' media type in the "CoAP Content-Formats" registry. This Content-Format for the OSCORE payload is defined for potential future use cases and SHALL NOT be used in the OSCORE message. The OSCORE payload cannot be understood without the OSCORE option value and the security context.
本节在“CoAP内容格式”注册表中注册“应用程序/oscore”媒体类型。OSCORE有效载荷的此内容格式是为将来的潜在用例定义的，不应在OSCORE消息中使用。如果没有OSCORE选项值和安全上下文，就无法理解OSCORE负载。
+----------------------+----------+----------+-------------------+
| Media Type | Encoding | ID | Reference |
+----------------------+----------+----------+-------------------+
| application/oscore | | 10001 | [RFC8613] |
+----------------------+----------+----------+-------------------+
+----------------------+----------+----------+-------------------+
| Media Type | Encoding | ID | Reference |
+----------------------+----------+----------+-------------------+
| application/oscore | | 10001 | [RFC8613] |
+----------------------+----------+----------+-------------------+
This document defines a subregistry for the OSCORE flag bits within the "CoRE Parameters" registry. The name of the subregistry is "OSCORE Flag Bits". The registry has been created with the Expert Review policy [RFC8126]. Guidelines for the experts are provided in Section 13.8.
本文件为“核心参数”注册表中的OSCORE标志位定义了一个子区域。子区域的名称为“OSCORE标志位”。已使用专家评审政策[RFC8126]创建注册表。专家指南见第13.8节。
The columns of the registry are as follows:
注册表的列如下：
o Bit Position: This indicates the position of the bit in the set of OSCORE flag bits, starting at 0 for the most significant bit. The bit position must be an integer or a range of integers, in the range 0 to 63.
o 位位置：表示位在OSCORE标志位集合中的位置，最高有效位从0开始。位位置必须是一个整数或整数范围，范围在0到63之间。
o Name: The name is present to make it easier to refer to and discuss the registration entry. The value is not used in the protocol. Names are to be unique in the table.
o 姓名：提供姓名是为了便于查阅和讨论注册条目。该值未在协议中使用。名称在表中必须是唯一的。
o Description: This contains a brief description of the use of the bit.
o 描述：这包含位使用的简要说明。
o Reference: This contains a pointer to the specification defining the entry.
o 引用：它包含一个指向定义条目的规范的指针。
The initial contents of the registry are in the table below. The reference column for all rows is this document. The entries with Bit Position of 0 and 1 are marked as 'Reserved'. The entry with Bit Position of 1 will be specified in a future document and will be used to expand the space for the OSCORE flag bits in Section 6.1, so that entries 8-63 of the registry are defined.
注册表的初始内容如下表所示。所有行的引用列都是此文档。位位置为0和1的条目标记为“保留”。位位置为1的条目将在未来的文档中指定，并用于扩展第6.1节中OSCORE标志位的空间，以便定义注册表的条目8-63。
+--------------+-------------+-----------------------------+-----------+
| Bit Position | Name | Description | Reference |
+--------------+-------------+-----------------------------+-----------+
| 0 | Reserved | | |
+--------------+-------------+-----------------------------+-----------+
| 1 | Reserved | | |
+--------------+-------------+-----------------------------+-----------+
| 2 | Unassigned | | |
+--------------+-------------+-----------------------------+-----------+
| 3 | Kid Context | Set to 1 if kid context | [RFC8613] |
| | Flag | is present in the | |
| | | compressed COSE object | |
+--------------+-------------+-----------------------------+-----------+
| 4 | Kid Flag | Set to 1 if kid is present | [RFC8613] |
| | | in the compressed COSE | |
| | | object | |
+--------------+-------------+-----------------------------+-----------+
| 5-7 | Partial IV | Encodes the Partial IV | [RFC8613] |
| | Length | length; can have value | |
| | | 0 to 5 | |
+--------------+-------------+-----------------------------+-----------+
| 8-63 | Unassigned | | |
+--------------+-------------+-----------------------------+-----------+
+--------------+-------------+-----------------------------+-----------+
| Bit Position | Name | Description | Reference |
+--------------+-------------+-----------------------------+-----------+
| 0 | Reserved | | |
+--------------+-------------+-----------------------------+-----------+
| 1 | Reserved | | |
+--------------+-------------+-----------------------------+-----------+
| 2 | Unassigned | | |
+--------------+-------------+-----------------------------+-----------+
| 3 | Kid Context | Set to 1 if kid context | [RFC8613] |
| | Flag | is present in the | |
| | | compressed COSE object | |
+--------------+-------------+-----------------------------+-----------+
| 4 | Kid Flag | Set to 1 if kid is present | [RFC8613] |
| | | in the compressed COSE | |
| | | object | |
+--------------+-------------+-----------------------------+-----------+
| 5-7 | Partial IV | Encodes the Partial IV | [RFC8613] |
| | Length | length; can have value | |
| | | 0 to 5 | |
+--------------+-------------+-----------------------------+-----------+
| 8-63 | Unassigned | | |
+--------------+-------------+-----------------------------+-----------+
The expert reviewers for the registry defined in this document are expected to ensure that the usage solves a valid use case that could not be solved better in a different way, that it is not going to duplicate one that is already registered, and that the registered point is likely to be used in deployments. They are furthermore expected to check the clarity of purpose and use of the requested code points. Experts should take into account the expected usage of entries when approving point assignment, and the length of the encoded value should be weighed against the number of code points left that encode to that size and the size of device it will be used
本文档中定义的注册中心的专家评审员应确保该用法解决了无法以其他方式更好地解决的有效用例，不会重复已注册的用例，并且注册点可能会在部署中使用。此外，他们还应检查所需代码点的用途和使用是否清晰。专家在批准点分配时应考虑到条目的预期用途，编码值的长度应与编码到该尺寸的剩余码点数和将使用的设备尺寸进行权衡
on. Experts should block registration for entries 8-63 until these points are defined (i.e., until the mechanism for the OSCORE flag bits expansion via bit 1 is specified).
在…上专家应阻止条目8-63的注册，直到定义了这些点（即，直到指定了通过位1扩展OSCORE标志位的机制）。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <https://www.rfc-editor.org/info/rfc4086>.
[RFC4086]Eastlake 3rd，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 4086，DOI 10.17487/RFC4086，2005年6月<https://www.rfc-editor.org/info/rfc4086>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/info/rfc4648>.
[RFC4648]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC 4648，DOI 10.17487/RFC4648，2006年10月<https://www.rfc-editor.org/info/rfc4648>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<https://www.rfc-editor.org/info/rfc5234>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6347]Rescorla，E.和N.Modadugu，“数据报传输层安全版本1.2”，RFC 6347，DOI 10.17487/RFC6347，2012年1月<https://www.rfc-editor.org/info/rfc6347>.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013, <https://www.rfc-editor.org/info/rfc7049>.
[RFC7049]Bormann，C.和P.Hoffman，“简明二进制对象表示法（CBOR）”，RFC 7049，DOI 10.17487/RFC7049，2013年10月<https://www.rfc-editor.org/info/rfc7049>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>.
[RFC7230]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：消息语法和路由”，RFC 7230，DOI 10.17487/RFC7230，2014年6月<https://www.rfc-editor.org/info/rfc7230>.
[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, <https://www.rfc-editor.org/info/rfc7231>.
[RFC7231]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：语义和内容”，RFC 7231，DOI 10.17487/RFC72312014年6月<https://www.rfc-editor.org/info/rfc7231>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <https://www.rfc-editor.org/info/rfc7252>.
[RFC7252]Shelby，Z.，Hartke，K.，和C.Bormann，“受限应用协议（CoAP）”，RFC 7252，DOI 10.17487/RFC7252，2014年6月<https://www.rfc-editor.org/info/rfc7252>.
[RFC7641] Hartke, K., "Observing Resources in the Constrained Application Protocol (CoAP)", RFC 7641, DOI 10.17487/RFC7641, September 2015, <https://www.rfc-editor.org/info/rfc7641>.
[RFC7641]Hartke，K.，“受限应用协议（CoAP）中的观测资源”，RFC 7641，DOI 10.17487/RFC7641，2015年9月<https://www.rfc-editor.org/info/rfc7641>.
[RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in the Constrained Application Protocol (CoAP)", RFC 7959, DOI 10.17487/RFC7959, August 2016, <https://www.rfc-editor.org/info/rfc7959>.
[RFC7959]Bormann，C.和Z.Shelby，编辑，“受限应用协议（CoAP）中的分块传输”，RFC 7959，DOI 10.17487/RFC7959，2016年8月<https://www.rfc-editor.org/info/rfc7959>.
[RFC8075] Castellani, A., Loreto, S., Rahman, A., Fossati, T., and E. Dijk, "Guidelines for Mapping Implementations: HTTP to the Constrained Application Protocol (CoAP)", RFC 8075, DOI 10.17487/RFC8075, February 2017, <https://www.rfc-editor.org/info/rfc8075>.
[RFC8075]Castellani，A.，Loreto，S.，Rahman，A.，Fossati，T.，和E.Dijk，“映射实现指南：HTTP到受约束应用程序协议（CoAP）”，RFC 8075，DOI 10.17487/RFC8075，2017年2月<https://www.rfc-editor.org/info/rfc8075>.
[RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and FETCH Methods for the Constrained Application Protocol (CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017, <https://www.rfc-editor.org/info/rfc8132>.
[RFC8132]van der Stok，P.，Bormann，C.，和A.Sehgal，“受约束应用协议（CoAP）的补丁和获取方法”，RFC 8132，DOI 10.17487/RFC8132，2017年4月<https://www.rfc-editor.org/info/rfc8132>.
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", RFC 8152, DOI 10.17487/RFC8152, July 2017, <https://www.rfc-editor.org/info/rfc8152>.
[RFC8152]Schaad，J.，“CBOR对象签名和加密（COSE）”，RFC 8152，DOI 10.17487/RFC8152，2017年7月<https://www.rfc-editor.org/info/rfc8152>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC8288] Nottingham, M., "Web Linking", RFC 8288, DOI 10.17487/RFC8288, October 2017, <https://www.rfc-editor.org/info/rfc8288>.
[RFC8288]诺丁汉，M.，“网络链接”，RFC 8288，DOI 10.17487/RFC8288，2017年10月<https://www.rfc-editor.org/info/rfc8288>.
[RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets", RFC 8323, DOI 10.17487/RFC8323, February 2018, <https://www.rfc-editor.org/info/rfc8323>.
[RFC8323]Bormann，C.，Lemay，S.，Tschofenig，H.，Hartke，K.，Silverajan，B.，和B.Raymor，Ed.，“TCP，TLS和WebSocket上的CoAP（受限应用协议）”，RFC 8323，DOI 10.17487/RFC83232018年2月<https://www.rfc-editor.org/info/rfc8323>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446]Rescorla，E.“传输层安全（TLS）协议版本1.3”，RFC 8446，DOI 10.17487/RFC8446，2018年8月<https://www.rfc-editor.org/info/rfc8446>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC8610]Birkholz，H.，Vigano，C.，和C.Bormann，“简明数据定义语言（CDDL）：表示简明二进制对象表示（CBOR）和JSON数据结构的符号约定”，RFC 8610，DOI 10.17487/RFC8610，2019年6月<https://www.rfc-editor.org/info/rfc8610>.
[ACE-OAuth] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth)", Work in Progress, draft-ietf-ace-oauth-authz-24, March 2019.
[ACE OAuth]Seitz，L.，Selander，G.，Wahlstroem，E.，Erdtman，S.，和H.Tschofenig，“使用OAuth 2.0框架（ACE OAuth）的受限环境认证和授权（ACE）”，正在进行中的工作，草案-ietf-ACE-OAuth-authz-242019年3月。
[CoAP-802.15.4] Bormann, C., "Constrained Application Protocol (CoAP) over IEEE 802.15.4 Information Element for IETF", Work in Progress, draft-bormann-6lo-coap-802-15-ie-00, April 2016.
[CoAP-802.15.4]Bormann，C.“IETF的IEEE 802.15.4信息元素上的约束应用协议（CoAP）”，正在进行的工作，草稿-Bormann-6lo-CoAP-802-15-ie-00，2016年4月。
[CoAP-Actuators] Mattsson, J., Fornehed, J., Selander, G., Palombini, F., and C. Amsuess, "Controlling Actuators with CoAP", Work in Progress, draft-mattsson-core-coap-actuators-06, September 2018.
[CoAP致动器]Mattsson，J.，Fornehed，J.，Selander，G.，Palombini，F.，和C.Amsuess，“使用CoAP控制致动器”，在建工程，草稿-Mattsson-core-CoAP-致动器-06，2018年9月。
[CoAP-E2E-Sec] Selander, G., Palombini, F., and K. Hartke, "Requirements for CoAP End-To-End Security", Work in Progress, draft-hartke-core-e2e-security-reqs-03, July 2017.
[CoAP-E2E-Sec]Selander，G.，Palombini，F.，和K.Hartke，“CoAP端到端安全要求”，在建工程，草稿-Hartke-core-E2E-Security-reqs-032017年7月。
[CoAP-ECHO-REQ-TAG] Amsuess, C., Mattsson, J., and G. Selander, "CoAP: Echo, Request-Tag, and Token Processing", Work in Progress, draft-ietf-core-echo-request-tag-04, March 2019.
[CoAP ECHO REQ TAG]Amsuess，C.，Mattsson，J.，和G.Selander，“CoAP：回声，请求标记和令牌处理”，正在进行的工作，草稿-ietf-core-ECHO-Request-TAG-042019年3月。
[Group-OSCORE] Tiloca, M., Selander, G., Palombini, F., and J. Park, "Group OSCORE - Secure Group Communication for CoAP", Work in Progress, draft-ietf-core-oscore-groupcomm-04, March 2019.
[集团OSCORE]Tiloca，M.，Selander，G.，Palombini，F.，和J.Park，“集团OSCORE-CoAP的安全集团通信”，正在进行的工作，草案-ietf-core-OSCORE-groupcomm-042019年3月。
[IV-GEN] McGrew, D., "Generation of Deterministic Initialization Vectors (IVs) and Nonces", Work in Progress, draft-mcgrew-iv-gen-03, October 2013.
[IV-GEN]McGrew，D.，“确定性初始化向量（IVs）和nonce的生成”，正在进行的工作，draft-McGrew-IV-GEN-032013年10月。
[MF00] McGrew, D. and S. Fluhrer, "Attacks on Additive Encryption of Redundant Plaintext and Implications on Internet Security", Proceedings of the Seventh Annual Workshop on Selected Areas in Cryptography (SAC 2000) Springer-Verlag., pp. 14-28, 2000.
[MF00]McGrew，D.和S.Fluhrer，“对冗余明文加性加密的攻击及其对互联网安全的影响”，第七届密码学选定领域年度研讨会论文集（SAC 2000），Springer Verlag，第14-28页，2000年。
[OSCORE-PROFILE] Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, "OSCORE profile of the Authentication and Authorization for Constrained Environments Framework", Work in Progress, draft-ietf-ace-oscore-profile-07, February 2019.
[OSCORE-PROFILE]Palombini，F.，Seitz，L.，Selander，G.，和M.Gunnarsson，“受限环境认证和授权框架的OSCORE概要”，正在进行的工作，草案-ietf-ace-OSCORE-PROFILE-072019年2月。
[REST] Fielding, R., "Architectural Styles and the Design of Network-based Software Architectures", Ph.D. Dissertation, University of California, Irvine, 2010.
[REST]Fielding，R.，“架构风格和基于网络的软件架构的设计”，博士。毕业论文，加利福尼亚大学，尔湾，2010。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, <https://www.rfc-editor.org/info/rfc3552>.
[RFC3552]Rescorla，E.和B.Korver，“关于安全考虑的RFC文本编写指南”，BCP 72，RFC 3552，DOI 10.17487/RFC3552，2003年7月<https://www.rfc-editor.org/info/rfc3552>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，DOI 10.17487/RFC3986，2005年1月<https://www.rfc-editor.org/info/rfc3986>.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, <https://www.rfc-editor.org/info/rfc5116>.
[RFC5116]McGrew，D.“认证加密的接口和算法”，RFC 5116，DOI 10.17487/RFC5116，2008年1月<https://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, <https://www.rfc-editor.org/info/rfc5869>.
[RFC5869]Krawczyk，H.和P.Eronen，“基于HMAC的提取和扩展密钥派生函数（HKDF）”，RFC 5869，DOI 10.17487/RFC5869，2010年5月<https://www.rfc-editor.org/info/rfc5869>.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, <https://www.rfc-editor.org/info/rfc6690>.
[RFC6690]Shelby，Z.“受限RESTful环境（核心）链接格式”，RFC 6690，DOI 10.17487/RFC6690，2012年8月<https://www.rfc-editor.org/info/rfc6690>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, <https://www.rfc-editor.org/info/rfc7228>.
[RFC7228]Bormann，C.，Ersue，M.和A.Keranen，“受限节点网络的术语”，RFC 7228，DOI 10.17487/RFC7228，2014年5月<https://www.rfc-editor.org/info/rfc7228>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7515]Jones，M.，Bradley，J.和N.Sakimura，“JSON网络签名（JWS）”，RFC 7515，DOI 10.17487/RFC7515，2015年5月<https://www.rfc-editor.org/info/rfc7515>.
[RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T. Bose, "Constrained Application Protocol (CoAP) Option for No Server Response", RFC 7967, DOI 10.17487/RFC7967, August 2016, <https://www.rfc-editor.org/info/rfc7967>.
[RFC7967]Bhattacharyya，A.，Bandyopadhyay，S.，Pal，A.，和T.Bose，“无服务器响应的受限应用程序协议（CoAP）选项”，RFC 7967，DOI 10.17487/RFC7967，2016年8月<https://www.rfc-editor.org/info/rfc7967>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]Cotton，M.，Leiba，B.，和T.Narten，“在RFC中编写IANA考虑事项部分的指南”，BCP 26，RFC 8126，DOI 10.17487/RFC8126，2017年6月<https://www.rfc-editor.org/info/rfc8126>.
This section gives examples of OSCORE, targeting scenarios in Section 2.2.1.1 of [CoAP-E2E-Sec]. The message exchanges are made, based on the assumption that there is a security context established between client and server. For simplicity, these examples only indicate the content of the messages without going into detail of the (compressed) COSE message format.
本节给出了[CoAP-E2E-Sec]第2.2.1.1节中的OSCORE目标场景示例。消息交换是基于在客户端和服务器之间建立安全上下文的假设进行的。为简单起见，这些示例仅指示消息的内容，而没有详细说明（压缩的）COSE消息格式。
This example illustrates a client requesting the alarm status from a server.
此示例演示了从服务器请求报警状态的客户端。
Client Proxy Server
| | |
+------>| | Code: 0.02 (POST)
| POST | | Token: 0x8c
| | | OSCORE: [kid:5f, Partial IV:42]
| | | Payload: {Code:0.01,
| | | Uri-Path:"alarm_status"}
| | |
| +------>| Code: 0.02 (POST)
| | POST | Token: 0x7b
| | | OSCORE: [kid:5f, Partial IV:42]
| | | Payload: {Code:0.01,
| | | Uri-Path:"alarm_status"}
| | |
| |<------+ Code: 2.04 (Changed)
| | 2.04 | Token: 0x7b
| | | OSCORE: -
| | | Payload: {Code:2.05, "0"}
| | |
|<------+ | Code: 2.04 (Changed)
| 2.04 | | Token: 0x8c
| | | OSCORE: -
| | | Payload: {Code:2.05, "0"}
| | |
Client Proxy Server
| | |
+------>| | Code: 0.02 (POST)
| POST | | Token: 0x8c
| | | OSCORE: [kid:5f, Partial IV:42]
| | | Payload: {Code:0.01,
| | | Uri-Path:"alarm_status"}
| | |
| +------>| Code: 0.02 (POST)
| | POST | Token: 0x7b
| | | OSCORE: [kid:5f, Partial IV:42]
| | | Payload: {Code:0.01,
| | | Uri-Path:"alarm_status"}
| | |
| |<------+ Code: 2.04 (Changed)
| | 2.04 | Token: 0x7b
| | | OSCORE: -
| | | Payload: {Code:2.05, "0"}
| | |
|<------+ | Code: 2.04 (Changed)
| 2.04 | | Token: 0x8c
| | | OSCORE: -
| | | Payload: {Code:2.05, "0"}
| | |
Square brackets [ ... ] indicate content of compressed COSE object. Curly brackets { ... } indicate encrypted data.
方括号[…]表示压缩COSE对象的内容。花括号{…}表示加密数据。
Figure 12: Secure Access to Sensor
图12：安全接近传感器
The CoAP request/response Codes are encrypted by OSCORE and only dummy Codes (POST/Changed) are visible in the header of the OSCORE message. The option Uri-Path ("alarm_status") and payload ("0") are encrypted.
CoAP请求/响应代码由OSCORE加密，在OSCORE消息头中仅可见伪代码（POST/Changed）。选项Uri路径（“报警状态”）和有效负载（“0”）是加密的。
The COSE header of the request contains an identifier (5f), indicating which security context was used to protect the message and a Partial IV (42).
请求的COSE头包含一个标识符（5f），指示用于保护消息的安全上下文和部分IV（42）。
The server verifies the request as specified in Section 8.2. The client verifies the response as specified in Section 8.4.
服务器按照第8.2节的规定验证请求。客户机按照第8.4节的规定验证响应。
This example illustrates a client requesting subscription to a blood sugar measurement resource (GET /glucose), first receiving the value 220 mg/dl and then a second value 180 mg/dl.
此示例说明了请求订阅血糖测量资源（GET/glucose）的客户端，首先接收值220 mg/dl，然后接收第二个值180 mg/dl。
Client Proxy Server
| | |
+------>| | Code: 0.05 (FETCH)
| FETCH | | Token: 0x83
| | | Observe: 0
| | | OSCORE: [kid:ca, Partial IV:15]
| | | Payload: {Code:0.01,
| | | Observe:0,
| | | Uri-Path:"glucose"}
| | |
| +------>| Code: 0.05 (FETCH)
| | FETCH | Token: 0xbe
| | | Observe: 0
| | | OSCORE: [kid:ca, Partial IV:15]
| | | Payload: {Code:0.01,
| | | Observe:0,
| | | Uri-Path:"glucose"}
| | |
| |<------+ Code: 2.05 (Content)
| | 2.05 | Token: 0xbe
| | | Observe: 7
| | | OSCORE: -
| | | Payload: {Code:2.05,
| | | Observe:-,
| | | Content-Format:0, "220"}
| | |
|<------+ | Code: 2.05 (Content)
| 2.05 | | Token: 0x83
| | | Observe: 7
| | | OSCORE: -
| | | Payload: {Code:2.05,
| | | Observe:-,
| | | Content-Format:0, "220"}
... ... ...
| | |
Client Proxy Server
| | |
+------>| | Code: 0.05 (FETCH)
| FETCH | | Token: 0x83
| | | Observe: 0
| | | OSCORE: [kid:ca, Partial IV:15]
| | | Payload: {Code:0.01,
| | | Observe:0,
| | | Uri-Path:"glucose"}
| | |
| +------>| Code: 0.05 (FETCH)
| | FETCH | Token: 0xbe
| | | Observe: 0
| | | OSCORE: [kid:ca, Partial IV:15]
| | | Payload: {Code:0.01,
| | | Observe:0,
| | | Uri-Path:"glucose"}
| | |
| |<------+ Code: 2.05 (Content)
| | 2.05 | Token: 0xbe
| | | Observe: 7
| | | OSCORE: -
| | | Payload: {Code:2.05,
| | | Observe:-,
| | | Content-Format:0, "220"}
| | |
|<------+ | Code: 2.05 (Content)
| 2.05 | | Token: 0x83
| | | Observe: 7
| | | OSCORE: -
| | | Payload: {Code:2.05,
| | | Observe:-,
| | | Content-Format:0, "220"}
... ... ...
| | |
| |<------+ Code: 2.05 (Content)
| | 2.05 | Token: 0xbe
| | | Observe: 8
| | | OSCORE: [Partial IV:36]
| | | Payload: {Code:2.05,
| | | Observe:-,
| | | Content-Format:0, "180"}
| | |
|<------+ | Code: 2.05 (Content)
| 2.05 | | Token: 0x83
| | | Observe: 8
| | | OSCORE: [Partial IV:36]
| | | Payload: {Code:2.05,
| | | Observe:-,
| | | Content-Format:0, "180"}
| | |
| |<------+ Code: 2.05 (Content)
| | 2.05 | Token: 0xbe
| | | Observe: 8
| | | OSCORE: [Partial IV:36]
| | | Payload: {Code:2.05,
| | | Observe:-,
| | | Content-Format:0, "180"}
| | |
|<------+ | Code: 2.05 (Content)
| 2.05 | | Token: 0x83
| | | Observe: 8
| | | OSCORE: [Partial IV:36]
| | | Payload: {Code:2.05,
| | | Observe:-,
| | | Content-Format:0, "180"}
| | |
Square brackets [ ... ] indicate content of compressed COSE object header. Curly brackets { ... } indicate encrypted data.
方括号[…]表示压缩COSE对象标题的内容。花括号{…}表示加密数据。
Figure 13: Secure Subscribe to Sensor
图13：安全订阅传感器
The dummy Codes (FETCH/Content) are used to allow forwarding of Observe messages. The options Content-Format (0) and the payload ("220" and "180") are encrypted.
虚拟代码（获取/内容）用于允许转发消息。选项内容格式（0）和有效载荷（“220”和“180”）是加密的。
The COSE header of the request contains an identifier (ca), indicating the security context used to protect the message and a Partial IV (15). The COSE header of the second response contains the Partial IV (36). The first response uses the Partial IV of the request.
请求的COSE头包含一个标识符（ca），指示用于保护消息的安全上下文和一个部分IV（15）。第二个响应的COSE头包含部分IV（36）。第一个响应使用请求的第四部分。
The server verifies that the Partial IV has not been received before. The client verifies that the responses are bound to the request and that the Partial IVs are greater than any Partial IV previously received in a response bound to the request, except for the notification without Partial IV, which is considered the oldest.
服务器验证以前是否未收到部分IV。客户端验证响应是否绑定到请求，以及部分IV是否大于先前在绑定到请求的响应中接收到的任何部分IV，但不带部分IV的通知除外，该通知被视为最早的通知。
For many Internet of Things (IoT) deployments, a 128-bit uniformly random Master Key is sufficient for encrypting all data exchanged with the IoT device throughout its lifetime. Two examples are given in this section. In the first example, the security context is only derived once from the Master Secret. In the second example, security contexts are derived multiple times using random inputs.
对于许多物联网（IoT）部署，128位统一随机主密钥足以在其整个生命周期内加密与IoT设备交换的所有数据。本节给出了两个示例。在第一个示例中，安全上下文仅从主密钥派生一次。在第二个示例中，使用随机输入多次派生安全上下文。
An application that only derives the security context once needs to handle the loss of mutable security context parameters, e.g., due to reboot.
仅派生一次安全上下文的应用程序需要处理可变安全上下文参数的丢失，例如，由于重新启动。
In order to handle loss of Sender Sequence Numbers, the device may implement procedures for writing to nonvolatile memory during normal operations and updating the security context after reboot, provided that the procedures comply with the requirements on the security context parameters (Section 3.3). This section gives an example of such a procedure.
为了处理发送方序列号的丢失，设备可实施在正常操作期间写入非易失性存储器和在重启后更新安全上下文的程序，前提是这些程序符合安全上下文参数的要求（第3.3节）。本节给出了此类程序的示例。
There are known issues related to writing to nonvolatile memory. For example, flash drives may have a limited number of erase operations during its lifetime. Also, the time for a write operation to nonvolatile memory to be completed may be unpredictable, e.g., due to caching, which could result in important security context data not being stored at the time when the device reboots.
存在与写入非易失性存储器相关的已知问题。例如，闪存驱动器在其生命周期内的擦除操作数量可能有限。此外，完成对非易失性存储器的写入操作的时间可能是不可预测的，例如，由于高速缓存，这可能导致在设备重新启动时不存储重要的安全上下文数据。
However, many devices have predictable limits for writing to nonvolatile memory, are physically limited to only send a small amount of messages per minute, and may have no good source of randomness.
然而，许多设备对写入非易失性存储器具有可预测的限制，物理上仅限于每分钟发送少量消息，并且可能没有良好的随机性来源。
To prevent reuse of Sender Sequence Number, an endpoint may perform the following procedure during normal operations:
为防止重复使用发送方序列号，端点可在正常操作期间执行以下过程：
o Before using a Sender Sequence Number that is evenly divisible by K, where K is a positive integer, store the Sender Sequence Number (SSN1) in nonvolatile memory. After booting, the endpoint initiates the new Sender Sequence Number (SSN2) to the value stored in persistent memory plus K plus F: SSN2 = SSN1 + K + F, where F is a positive integer.
o 在使用可被K整除的发送方序列号（其中K为正整数）之前，请将发送方序列号（SSN1）存储在非易失性存储器中。启动后，端点将新的发送方序列号（SSN2）初始化为存储在持久内存中的值加上K+F:SSN2=SSN1+K+F，其中F为正整数。
* Writing to nonvolatile memory can be costly; the value K gives a trade-off between frequency of storage operations and efficient use of Sender Sequence Numbers.
* 写入非易失性存储器可能代价高昂；值K在存储操作的频率和发送方序列号的有效使用之间进行权衡。
* Writing to nonvolatile memory may be subject to delays, or failure; F MUST be set so that the last Sender Sequence Number used before reboot is never larger than SSN2.
* 写入非易失性存储器可能会出现延迟或故障；F必须设置为在重新启动前使用的最后一个发送方序列号永远不会大于SSN2。
If F cannot be set so SSN2 is always larger than the last Sender Sequence Number used before reboot, the method described in this section MUST NOT be used.
如果无法设置F，因此SSN2始终大于重新启动前使用的最后一个发送方序列号，则不得使用本节中描述的方法。
In case of loss of security context on the server, to prevent accepting replay of previously received requests, the server may perform the following procedure after booting:
如果服务器上的安全上下文丢失，为防止接受以前接收到的请求的重播，服务器可在引导后执行以下过程：
o The server updates its Sender Sequence Number as specified in Appendix B.1.1 to be used as Partial IV in the response containing the Echo option (next bullet).
o 服务器按照附录B.1.1中的规定更新其发送方序列号，以用作包含Echo选项（下一个项目符号）的响应中的第四部分。
o For each stored security context, the first time after booting, the server receives an OSCORE request, the server responds with an OSCORE protected 4.01 (Unauthorized), containing only the Echo option [CoAP-ECHO-REQ-TAG] and no diagnostic payload. The server MUST use its Partial IV when generating the AEAD nonce and MUST include the Partial IV in the response (see Section 5). If the server with use of the Echo option can verify a second OSCORE request as fresh, then the Partial IV of the second request is set as the lower limit of the Replay Window of that security context.
o 对于每个存储的安全上下文，在引导后的第一次，服务器接收到一个OSCORE请求，服务器用一个OSCORE protected 4.01（未经授权）响应，其中只包含Echo选项[CoAP Echo REQ TAG]，没有诊断负载。服务器在生成AEAD nonce时必须使用其部分IV，并且必须在响应中包含部分IV（参见第5节）。如果使用Echo选项的服务器可以验证第二个OSCORE请求是否为新请求，则第二个请求的部分IV将设置为该安全上下文的重播窗口的下限。
To prevent the acceptance of replay of previously received notifications, the client may perform the following procedure after booting:
为了防止接受以前接收到的通知的重播，客户端可以在引导后执行以下过程：
o The client forgets about earlier registrations and removes all Notification Numbers. The client then registers again using the Observe option.
o 客户端会忘记以前的注册并删除所有通知号码。然后，客户端使用“观察”选项再次注册。
An application that does not require forward secrecy may allow multiple security contexts to be derived from one Master Secret. The requirements on the security context parameters MUST be fulfilled (Section 3.3) even if the client or server is rebooted, recommissioned, or in error cases.
不需要前向保密的应用程序可能允许从一个主密钥派生多个安全上下文。即使客户机或服务器重新启动、重新调试或出现错误，也必须满足安全上下文参数的要求（第3.3节）。
This section gives an example of a protocol that adds randomness to the ID Context parameter and uses that together with input parameters preestablished between client and server, in particular Master Secret, Master Salt, and Sender/Recipient ID (see Section 3.2), to derive new security contexts. The random input is transported between client and server in the 'kid context' parameter. This protocol MUST NOT be used unless both endpoints have good sources of randomness.
本节给出了一个协议示例，该协议将随机性添加到ID上下文参数中，并将其与客户端和服务器之间预先建立的输入参数一起使用，特别是主密钥、主Salt和发送方/接收方ID（见第3.2节），以派生新的安全上下文。随机输入在“kid context”参数中在客户端和服务器之间传输。除非两个端点都具有良好的随机性来源，否则不得使用该协议。
During normal requests, the ID Context of an established security context may be sent in the 'kid context', which, together with 'kid', facilitates for the server to locate a security context. Alternatively, the 'kid context' may be omitted since the ID Context is expected to be known to both client and server; see Section 5.1.
在正常请求期间，已建立的安全上下文的ID上下文可以在“kid Context”中发送，这与“kid”一起有助于服务器定位安全上下文。或者，由于预期客户端和服务器都知道ID上下文，因此可以省略“kid上下文”；见第5.1节。
The protocol described in this section may only be needed when the mutable part of security context is lost in the client or server, e.g., when the endpoint has rebooted. The protocol may additionally be used whenever the client and server need to derive a new security context. For example, if a device is provisioned with one fixed set of input parameters (including Master Secret, Sender and Recipient Identifiers), then a randomized ID Context ensures that the security context is different for each deployment.
只有当客户端或服务器中的安全上下文的可变部分丢失时（例如，当端点重新启动时），才可能需要本节中描述的协议。当客户端和服务器需要派生新的安全上下文时，还可以使用该协议。例如，如果为设备提供了一组固定的输入参数（包括主密钥、发送方和接收方标识符），则随机化ID上下文可确保每个部署的安全上下文不同。
Note that the server needs to be configured to run this protocol when it is not able to retrieve an existing security context, instead of stopping processing the message as described in step 2 of Section 8.2.
请注意，服务器需要配置为在无法检索现有安全上下文时运行此协议，而不是按照第8.2节的步骤2停止处理消息。
The protocol is described below with reference to Figure 14. The client or the server may initiate the protocol, in the latter case step 1 is omitted.
下面参考图14描述该协议。客户端或服务器可以启动协议，在后一种情况下，省略步骤1。
Client Server
| |
1. Protect with | request #1 |
ID Context = ID1 |--------------------->| 2. Verify with
| kid_context = ID1 | ID Context = ID1
| |
| response #1 | Protect with
3. Verify with |<---------------------| ID Context = R2||ID1
ID Context = R2||ID1 | kid_context = R2 |
| |
Protect with | request #2 |
ID Context = R2||R3 |--------------------->| 4. Verify with
| kid_context = R2||R3 | ID Context = R2||R3
| |
| response #2 | Protect with
5. Verify with |<---------------------| ID Context = R2||R3
ID Context = R2||R3 | |
Client Server
| |
1. Protect with | request #1 |
ID Context = ID1 |--------------------->| 2. Verify with
| kid_context = ID1 | ID Context = ID1
| |
| response #1 | Protect with
3. Verify with |<---------------------| ID Context = R2||ID1
ID Context = R2||ID1 | kid_context = R2 |
| |
Protect with | request #2 |
ID Context = R2||R3 |--------------------->| 4. Verify with
| kid_context = R2||R3 | ID Context = R2||R3
| |
| response #2 | Protect with
5. Verify with |<---------------------| ID Context = R2||R3
ID Context = R2||R3 | |
Figure 14: Protocol for Establishing a New Security Context
图14：用于建立新安全上下文的协议
1. (Optional) If the client does not have a valid security context with the server, e.g., because of reboot or because this is the first time it contacts the server, then it generates a random string R1 and uses this as ID Context together with the input parameters shared with the server to derive a first security context. The client sends an OSCORE request to the server protected with the first security context, containing R1 wrapped in a CBOR bstr as 'kid context'. The request may target a special resource used for updating security contexts.
1. （可选）如果客户端与服务器之间没有有效的安全上下文，例如，由于重新启动或因为这是客户端第一次与服务器联系，则客户端将生成一个随机字符串R1，并将其用作ID上下文以及与服务器共享的输入参数，以派生第一个安全上下文。客户端向受第一个安全上下文保护的服务器发送一个OSCORE请求，其中包含包装在CBOR bstr中的R1作为“kid上下文”。该请求可以针对用于更新安全上下文的特殊资源。
2. The server receives an OSCORE request for which it does not have a valid security context, either because the client has generated a new security context ID1 = R1 or because the server has lost part of its security context, e.g., ID Context, Sender Sequence Number or Replay Window. If the server is able to verify the request (see Section 8.2) with the new derived first security context using the received ID1 (transported in 'kid context') as ID Context and the input parameters associated to the received 'kid', then the server generates a random string R2 and derives a second security context with ID Context = ID2 = R2 || ID1. The server sends a 4.01 (Unauthorized) response protected with the second security context, containing R2 wrapped in a CBOR bstr as 'kid context', and caches R2. R2 MUST NOT be reused as that may lead to reuse of key and nonce in response #1. Note that the server may receive several requests #1 associated with one security context, leading to multiple parallel protocol runs. Multiple instances of R2 may need to be cached until one of the protocol runs is completed, see Appendix B.2.1.
2. 服务器接收到的OSCORE请求没有有效的安全上下文，这可能是因为客户端生成了新的安全上下文ID1=R1，也可能是因为服务器丢失了部分安全上下文，例如ID上下文、发送方序列号或重播窗口。如果服务器能够使用接收到的ID1（在“kid context”中传输）作为ID上下文以及与接收到的“kid”关联的输入参数，使用新的派生第一安全上下文验证请求（参见第8.2节），然后，服务器生成一个随机字符串R2，并派生第二个ID context=ID2=R2 | | ID1的安全上下文。服务器发送一个受第二个安全上下文保护的4.01（未经授权）响应，其中包含作为“kid context”包装在CBOR bstr中的R2，并缓存R2。R2不得重复使用，因为这可能导致在响应#1时重复使用密钥和nonce。请注意，服务器可能会收到与一个安全上下文相关联的多个请求#1，从而导致多个并行协议运行。可能需要缓存多个R2实例，直到其中一个协议运行完成，见附录B.2.1。
3. The client receives a response with 'kid context' containing a CBOR bstr wrapping R2 to an OSCORE request it made with ID Context = ID1. The client derives a second security context using ID Context = ID2 = R2 || ID1. If the client can verify the response (see Section 8.4) using the second security context, then the client makes a request protected with a third security context derived from ID Context = ID3 = R2 || R3, where R3 is a random byte string generated by the client. The request includes R2 || R3 wrapped in a CBOR bstr as 'kid context'.
3. 客户端接收到一个带有“kid context”的响应，该响应包含一个CBOR bstr包装R2，以响应其ID context=ID1发出的OSCORE请求。客户端使用ID context=ID2=R2 | | ID1派生第二个安全上下文。如果客户端可以使用第二个安全上下文验证响应（参见第8.4节），则客户端会发出一个请求，该请求受第三个安全上下文的保护，该第三个安全上下文派生自ID context=ID3=R2 | | R3，其中R3是客户端生成的随机字节字符串。该请求包括包装在CBOR bstr中的R2 | | R3，作为“儿童上下文”。
4. If the server receives a request with 'kid context' containing a CBOR bstr wrapping ID3, where the first part of ID3 is identical to an R2 sent in a previous response #1, which it has not received before, then the server derives a third security context with ID Context = ID3. The server MUST NOT accept replayed request #2 messages. If the server can verify the request (see Section 8.2) with the third security context, then the server marks the third security context to be used with this client and removes all instances of R2 associated to this security context from the cache. This security context replaces the previous security context with the client, and the first and the second security contexts are deleted. The server responds using the same security context as in the request.
4. 如果服务器接收到包含CBOR bstr包装ID3的“kid context”请求，其中ID3的第一部分与之前未接收到的响应#1中发送的R2相同，则服务器派生出ID context=ID3的第三个安全上下文。服务器不能接受重播的请求#2消息。如果服务器可以使用第三个安全上下文验证请求（请参见第8.2节），则服务器将第三个安全上下文标记为与此客户端一起使用，并从缓存中删除与此安全上下文关联的所有R2实例。此安全上下文将使用客户端替换以前的安全上下文，并删除第一个和第二个安全上下文。服务器使用与请求中相同的安全上下文进行响应。
5. If the client receives a response to the request with the third security context and the response verifies (see Section 8.4), then the client marks the third security context to be used with this server. This security context replaces the previous security context with the server, and the first and second security contexts are deleted.
5. 如果客户端接收到具有第三个安全上下文的请求响应，并且该响应经过验证（请参见第8.4节），则客户端会将第三个安全上下文标记为此服务器使用。此安全上下文将用服务器替换以前的安全上下文，并删除第一个和第二个安全上下文。
If verification fails in any step, the endpoint stops processing that message.
如果验证在任何步骤中失败，端点将停止处理该消息。
The length of the nonces R1, R2, and R3 is application specific. The application needs to set the length of each nonce such that the probability of its value being repeated is negligible; typically, at least 8 bytes long. Since R2 may be generated as the result of a replayed request #1, the probability for collision of R2s is impacted by the birthday paradox. For example, setting the length of R2 to 8 bytes results in an average collision after 2^32 response #1 messages, which should not be an issue for a constrained server handling on the order of one request per second.
nonce R1、R2和R3的长度是特定于应用程序的。应用程序需要设置每个nonce的长度，以使其值被重复的概率可以忽略；通常，至少有8个字节长。由于R2可能是重播请求#1的结果，因此R2的碰撞概率受到生日悖论的影响。例如，将R2的长度设置为8字节会导致在2^32响应#1消息之后发生平均冲突，对于每秒处理一个请求的受限服务器来说，这不应该是一个问题。
Request #2 can be an ordinary request. The server performs the action of the request and sends response #2 after having successfully completed the operations related to the security context in step 4. The client acts on response #2 after having successfully completed step 5.
请求#2可以是普通请求。在成功完成步骤4中与安全上下文相关的操作后，服务器执行请求操作并发送响应#2。成功完成步骤5后，客户机根据响应#2进行操作。
When sending request #2, the client is assured that the Sender Key (derived with the random value R3) has never been used before. When receiving response #2, the client is assured that the response (protected with a key derived from the random value R3 and the Master Secret) was created by the server in response to request #2.
当发送请求#2时，客户机被确保发送方密钥（由随机值R3派生）以前从未使用过。当接收到响应#2时，客户机确信响应（使用从随机值R3和主密钥派生的密钥进行保护）是由服务器响应请求#2创建的。
Similarly, when receiving request #2, the server is assured that the request (protected with a key derived from the random value R2 and the Master Secret) was created by the client in response to response #1. When sending response #2, the server is assured that the Sender Key (derived with the random value R2) has never been used before.
类似地，当接收到请求#2时，服务器会确保该请求（受来自随机值R2和主密钥的密钥保护）是由客户端响应响应#1创建的。发送响应#2时，服务器会确保发送方密钥（由随机值R2派生）以前从未使用过。
Implementation and denial-of-service considerations are made in Appendix B.2.1 and Appendix B.2.2.
实施和拒绝服务注意事项见附录B.2.1和附录B.2.2。
This section add some implementation considerations to the protocol described in the previous section.
本节为上一节中描述的协议添加了一些实现注意事项。
The server may only have space for a few security contexts or only be able to handle a few protocol runs in parallel. The server may legitimately receive multiple request #1 messages using the same immutable security context, e.g., because of packet loss. Replays of old request #1 messages could be difficult for the server to distinguish from legitimate. The server needs to handle the case when the maximum number of cached R2s is reached. If the server receives a request #1 and is not capable of executing it then it may respond with an unprotected 5.03 (Service Unavailable) error message. The server may clear up state from protocol runs that never complete, e.g., set a timer when caching R2, and remove R2 and the associated security contexts from the cache at timeout. Additionally, state information can be flushed at reboot.
服务器可能只有几个安全上下文的空间，或者只能并行处理几个协议运行。服务器可以使用相同的不可变安全上下文合法地接收多个请求1消息，例如，由于数据包丢失。服务器很难区分旧请求1消息的重播与合法消息。当达到最大缓存R2s数时，服务器需要处理这种情况。如果服务器收到请求#1且无法执行该请求，则它可能会响应未受保护的5.03（服务不可用）错误消息。服务器可能会清除从未完成的协议运行的状态，例如，在缓存R2时设置计时器，并在超时时从缓存中删除R2和相关安全上下文。此外，可以在重新启动时刷新状态信息。
As an alternative to caching R2, the server could generate R2 in such a way that it can be sent (in response #1) and verified (at reception of request #2) as the value of R2 it had generated. Such a procedure MUST NOT lead to the server accepting replayed request #2 messages. One construction described in the following is based on using a secret random HMAC key K_HMAC per set of immutable security context parameters associated with a client. This construction allows the
作为缓存R2的替代方法，服务器可以生成R2，以便发送（响应#1）并验证（在接收请求#2时）它生成的R2值。这样的过程不能导致服务器接受重播的请求2消息。下面描述的一种构造基于对与客户端关联的每组不可变安全上下文参数使用秘密随机HMAC密钥K_HMAC。这种结构允许
server to handle verification of R2 in response #2 at the cost of storing the K_HMAC keys and a slightly larger message overhead in response #1. Steps below refer to modifications to Appendix B.2:
服务器在响应#2中处理R2验证，代价是存储K#U HMAC密钥和响应#1中稍大的消息开销。以下步骤涉及对附录B.2的修改：
o In step 2, R2 is generated in the following way. First, the server generates a random K_HMAC (unless it already has one associated with the security context), then it sets R2 = S2 || HMAC(K_HMAC, S2) where S2 is a random byte string, and the HMAC is truncated to 8 bytes. K_HMAC may have an expiration time, after which it is erased. Note that neither R2, S2, nor the derived first and second security contexts need to be cached.
o 在步骤2中，R2按以下方式生成。首先，服务器生成一个随机K|HMAC（除非它已经有一个与安全上下文关联），然后它设置R2=S2 | HMAC（K|HMAC，S2），其中S2是一个随机字节字符串，HMAC被截断为8个字节。K_HMAC可能有一个过期时间，过期后将被擦除。请注意，R2、S2和派生的第一和第二安全上下文都不需要缓存。
o In step 4, instead of verifying that R2 coincides with a cached value, the server looks up the associated K_HMAC and verifies the truncated HMAC, and the processing continues accordingly depending on verification success or failure. K_HMAC is used until a run of the protocol is completed (after verification of request #2), or until it expires (whatever comes first), after which K_HMAC is erased. (The latter corresponds to removing the cached values of R2 in step 4 of Appendix B.2 and makes the server reject replays of request #2.)
o 在步骤4中，服务器查找关联的K_HMAC并验证截断的HMAC，而不是验证R2是否与缓存的值一致，并且根据验证成功或失败，相应地继续处理。K#HMAC一直使用，直到协议运行完成（在验证请求#2之后），或者直到协议到期（无论先发生什么），之后K#HMAC被擦除。（后者对应于在附录B.2的步骤4中删除R2的缓存值，并使服务器拒绝请求#2的重播。）
The length of S2 is application specific and the probability for collision of S2s is impacted by the birthday paradox. For example, setting the length of S2 to 8 bytes results in an average collision after 2^32 response #1 messages, which should not be an issue for a constrained server handling on the order of one request per second.
S2的长度是特定于应用的，S2s的碰撞概率受生日悖论的影响。例如，将S2的长度设置为8字节会导致在2^32响应#1消息之后发生平均冲突，对于每秒处理一个请求的受限服务器来说，这不应该是一个问题。
Two endpoints sharing a security context may accidentally initiate two instances of the protocol at the same time, each in the role of client, e.g., after a power outage affecting both endpoints. Such a race condition could potentially lead to both protocols failing, and both endpoints repeatedly reinitiating the protocol without converging. Both endpoints can detect this situation, and it can be handled in different ways. The requests could potentially be more spread out in time, for example, by only initiating this protocol when the endpoint actually needs to make a request, potentially adding a random delay before requests immediately after reboot or if such parallel protocol runs are detected.
共享安全上下文的两个端点可能同时意外地启动协议的两个实例，每个实例都扮演客户端角色，例如，在影响两个端点的断电之后。这样的竞争条件可能会导致两个协议都失败，并且两个端点重复地重新初始化协议而不收敛。两个端点都可以检测到这种情况，并且可以以不同的方式处理。请求可能在时间上更分散，例如，仅当端点实际需要发出请求时才启动此协议，可能在重新启动后立即请求之前或检测到此类并行协议运行时添加随机延迟。
An on-path attacker may inject a message causing the endpoint to process verification of the message. A message crafted without access to the Master Secret will fail to verify.
路径上攻击者可能会注入消息，导致端点处理消息验证。未访问主密钥而创建的消息将无法验证。
Replaying an old request with a value of 'kid_context' that the server does not recognize could trigger the protocol. This causes the server to generate the first and second security context and send a response. But if the client did not expect a response, it will be discarded. This may still result in a denial-of-service attack against the server, e.g., because of not being able to manage the state associated with many parallel protocol runs, and it may prevent legitimate client requests. Implementation alternatives with less data caching per request #1 message are favorable in this respect; see Appendix B.2.1.
重播服务器无法识别的值为“kid_context”的旧请求可能会触发协议。这将导致服务器生成第一个和第二个安全上下文并发送响应。但是，如果客户机没有期望得到响应，则会将其丢弃。这仍然可能导致对服务器的拒绝服务攻击，例如，因为无法管理与许多并行协议运行相关的状态，并且可能会阻止合法的客户端请求。在这方面，每个请求（1条消息）具有较少数据缓存的实现方案是有利的；见附录B.2.1。
Replaying response #1 in response to some request other than request #1 will fail to verify, since response #1 is associated to request #1, through the dependencies of ID Contexts and the Partial IV of request #1 included in the external_aad of response #1.
由于响应1通过ID上下文的依赖关系和响应1的外部aad中包含的请求1的部分IV与请求1相关联，因此在响应除请求1外的某些请求时重播响应1将无法验证。
If request #2 has already been well received, then the server has a valid security context, so a replay of request #2 is handled by the normal replay protection mechanism. Similarly, if response #2 has already been received, a replay of response #2 to some other request from the client will fail by the normal verification of binding of response to request.
如果已经很好地接收到请求#2，则服务器具有有效的安全上下文，因此请求#2的重播由正常的重播保护机制处理。类似地，如果已经收到响应#2，则对来自客户端的某个其他请求的响应#2的重播将因响应与请求的绑定的正常验证而失败。
This appendix includes the test vectors for different examples of CoAP messages using OSCORE. Given a set of inputs, OSCORE defines how to set up the Security Context in both the client and the server.
本附录包括使用OSCORE的CoAP消息的不同示例的测试向量。给定一组输入，OSCORE定义如何在客户端和服务器中设置安全上下文。
Note that in Appendix C.4 and all following test vectors the Token and the Message ID of the OSCORE-protected CoAP messages are set to the same value of the unprotected CoAP message to help the reader with comparisons.
注意，在附录C.4和所有以下测试向量中，OSCORE保护的CoAP消息的令牌和消息ID设置为与未保护的CoAP消息相同的值，以帮助读者进行比较。
In this test vector, a Master Salt of 8 bytes is used. The default values are used for AEAD Algorithm and HKDF.
在此测试向量中，使用8字节的主Salt。默认值用于AEAD算法和HKDF。
Inputs:
投入：
o Master Secret: 0x0102030405060708090a0b0c0d0e0f10 (16 bytes)
o 主密钥：0x0102030405060708090a0b0c0d0e0f10（16字节）
o Master Salt: 0x9e7ca92223786340 (8 bytes)
o 主盐：0x9e7ca92223786340（8字节）
o Sender ID: 0x (0 byte)
o 发件人ID:0x（0字节）
o Recipient ID: 0x01 (1 byte)
o 收件人ID:0x01（1字节）
From the previous parameters,
根据前面的参数，
o info (for Sender Key): 0x8540f60a634b657910 (9 bytes)
o 信息（用于发送方密钥）：0x8540f60a634b657910（9字节）
o info (for Recipient Key): 0x854101f60a634b657910 (10 bytes)
o 信息（收件人密钥）：0x854101f60a634b657910（10字节）
o info (for Common IV): 0x8540f60a6249560d (8 bytes)
o 信息（通用IV）：0x8540f60a6249560d（8字节）
Outputs:
产出：
o Sender Key: 0xf0910ed7295e6ad4b54fc793154302ff (16 bytes)
o 发送方密钥：0xf0910ed7295e6ad4b54fc793154302ff（16字节）
o Recipient Key: 0xffb14e093c94c9cac9471648b4f98710 (16 bytes)
o 收件人密钥：0xffb14e093c94c9cac9471648b4f98710（16字节）
o Common IV: 0x4622d4dd6d944168eefb54987c (13 bytes)
o 通用IV:0x4622d4dd6d944168eefb54987c（13字节）
From the previous parameters and a Partial IV equal to 0 (both for sender and recipient):
根据前面的参数和等于0的部分IV（发件人和收件人）：
o sender nonce: 0x4622d4dd6d944168eefb54987c (13 bytes)
o 发送方nonce:0x4622d4dd6d944168eefb54987c（13字节）
o recipient nonce: 0x4722d4dd6d944169eefb54987c (13 bytes)
o 收件人当前值：0x4722d4dd6d944169eefb54987c（13字节）
Inputs:
投入：
o Master Secret: 0x0102030405060708090a0b0c0d0e0f10 (16 bytes)
o 主密钥：0x0102030405060708090a0b0c0d0e0f10（16字节）
o Master Salt: 0x9e7ca92223786340 (8 bytes)
o 主盐：0x9e7ca92223786340（8字节）
o Sender ID: 0x01 (1 byte)
o 发送方ID:0x01（1字节）
o Recipient ID: 0x (0 byte)
o 收件人ID:0x（0字节）
From the previous parameters,
根据前面的参数，
o info (for Sender Key): 0x854101f60a634b657910 (10 bytes)
o 信息（用于发送方密钥）：0x854101f60a634b657910（10字节）
o info (for Recipient Key): 0x8540f60a634b657910 (9 bytes)
o 信息（收件人密钥）：0x8540f60a634b657910（9字节）
o info (for Common IV): 0x8540f60a6249560d (8 bytes)
o 信息（通用IV）：0x8540f60a6249560d（8字节）
Outputs:
产出：
o Sender Key: 0xffb14e093c94c9cac9471648b4f98710 (16 bytes)
o 发送方密钥：0xffb14e093c94c9cac9471648b4f98710（16字节）
o Recipient Key: 0xf0910ed7295e6ad4b54fc793154302ff (16 bytes)
o 收件人密钥：0xf0910ed7295e6ad4b54fc793154302ff（16字节）
o Common IV: 0x4622d4dd6d944168eefb54987c (13 bytes)
o 通用IV:0x4622d4dd6d944168eefb54987c（13字节）
From the previous parameters and a Partial IV equal to 0 (both for sender and recipient):
根据前面的参数和等于0的部分IV（发件人和收件人）：
o sender nonce: 0x4722d4dd6d944169eefb54987c (13 bytes)
o 发送方nonce:0x4722d4dd6d944169eefb54987c（13字节）
o recipient nonce: 0x4622d4dd6d944168eefb54987c (13 bytes)
o 收件人当前值：0x4622d4dd6d944168eefb54987c（13字节）
In this test vector, the default values are used for AEAD Algorithm, HKDF, and Master Salt.
在此测试向量中，默认值用于AEAD算法、HKDF和主Salt。
Inputs:
投入：
o Master Secret: 0x0102030405060708090a0b0c0d0e0f10 (16 bytes)
o 主密钥：0x0102030405060708090a0b0c0d0e0f10（16字节）
o Sender ID: 0x00 (1 byte)
o 发送方ID:0x00（1字节）
o Recipient ID: 0x01 (1 byte)
o 收件人ID:0x01（1字节）
From the previous parameters,
根据前面的参数，
o info (for Sender Key): 0x854100f60a634b657910 (10 bytes)
o 信息（用于发送方密钥）：0x854100f60a634b657910（10字节）
o info (for Recipient Key): 0x854101f60a634b657910 (10 bytes)
o 信息（收件人密钥）：0x854101f60a634b657910（10字节）
o info (for Common IV): 0x8540f60a6249560d (8 bytes)
o 信息（通用IV）：0x8540f60a6249560d（8字节）
Outputs:
产出：
o Sender Key: 0x321b26943253c7ffb6003b0b64d74041 (16 bytes)
o 发送方密钥：0x321b26943253c7ffb6003b0b64d74041（16字节）
o Recipient Key: 0xe57b5635815177cd679ab4bcec9d7dda (16 bytes)
o 收件人密钥：0xE57B5635815177CD679AB4BEC9D7DDA（16字节）
o Common IV: 0xbe35ae297d2dace910c52e99f9 (13 bytes)
o 通用IV:0xbe35ae297d2dace910c52e99f9（13字节）
From the previous parameters and a Partial IV equal to 0 (both for sender and recipient):
根据前面的参数和等于0的部分IV（发件人和收件人）：
o sender nonce: 0xbf35ae297d2dace910c52e99f9 (13 bytes)
o 发送方nonce:0xbf35ae297d2dace910c52e99f9（13字节）
o recipient nonce: 0xbf35ae297d2dace810c52e99f9 (13 bytes)
o 收件人当前值：0xbf35ae297d2dace810c52e99f9（13字节）
Inputs:
投入：
o Master Secret: 0x0102030405060708090a0b0c0d0e0f10 (16 bytes)
o 主密钥：0x0102030405060708090a0b0c0d0e0f10（16字节）
o Sender ID: 0x01 (1 byte)
o 发送方ID:0x01（1字节）
o Recipient ID: 0x00 (1 byte)
o 收件人ID:0x00（1字节）
From the previous parameters,
根据前面的参数，
o info (for Sender Key): 0x854101f60a634b657910 (10 bytes)
o 信息（用于发送方密钥）：0x854101f60a634b657910（10字节）
o info (for Recipient Key): 0x854100f60a634b657910 (10 bytes)
o 信息（收件人密钥）：0x854100f60a634b657910（10字节）
o info (for Common IV): 0x8540f60a6249560d (8 bytes)
o 信息（通用IV）：0x8540f60a6249560d（8字节）
Outputs:
产出：
o Sender Key: 0xe57b5635815177cd679ab4bcec9d7dda (16 bytes)
o 发送方密钥：0xE57B5635815177CD679AB4BEC9D7DDA（16字节）
o Recipient Key: 0x321b26943253c7ffb6003b0b64d74041 (16 bytes)
o 收件人密钥：0x321b26943253c7ffb6003b0b64d74041（16字节）
o Common IV: 0xbe35ae297d2dace910c52e99f9 (13 bytes)
o 通用IV:0xbe35ae297d2dace910c52e99f9（13字节）
From the previous parameters and a Partial IV equal to 0 (both for sender and recipient):
根据前面的参数和等于0的部分IV（发件人和收件人）：
o sender nonce: 0xbf35ae297d2dace810c52e99f9 (13 bytes)
o 发送方nonce:0xbf35ae297d2dace810c52e99f9（13字节）
o recipient nonce: 0xbf35ae297d2dace910c52e99f9 (13 bytes)
o 收件人当前值：0xbf35ae297d2dace910c52e99f9（13字节）
In this test vector, a Master Salt of 8 bytes and an ID Context of 8 bytes are used. The default values are used for AEAD Algorithm and HKDF.
在此测试向量中，使用8字节的主Salt和8字节的ID上下文。默认值用于AEAD算法和HKDF。
Inputs:
投入：
o Master Secret: 0x0102030405060708090a0b0c0d0e0f10 (16 bytes)
o 主密钥：0x0102030405060708090a0b0c0d0e0f10（16字节）
o Master Salt: 0x9e7ca92223786340 (8 bytes)
o 主盐：0x9e7ca92223786340（8字节）
o Sender ID: 0x (0 byte)
o 发件人ID:0x（0字节）
o Recipient ID: 0x01 (1 byte)
o 收件人ID:0x01（1字节）
o ID Context: 0x37cbf3210017a2d3 (8 bytes)
o ID上下文：0x37cbf3210017a2d3（8字节）
From the previous parameters,
根据前面的参数，
o info (for Sender Key): 0x85404837cbf3210017a2d30a634b657910 (17 bytes)
o 信息（用于发送方密钥）：0x85404837cbf3210017a2d30a634b657910（17字节）
o info (for Recipient Key): 0x8541014837cbf3210017a2d30a634b657910 (18 bytes)
o 信息（收件人密钥）：0x8541014837cbf3210017a2d30a634b657910（18字节）
o info (for Common IV): 0x85404837cbf3210017a2d30a6249560d (16 bytes)
o 信息（通用IV）：0x85404837cbf3210017a2d30a6249560d（16字节）
Outputs:
产出：
o Sender Key: 0xaf2a1300a5e95788b356336eeecd2b92 (16 bytes)
o 发送方密钥：0xAF2A1300A5E95788B35636EEECD2B92（16字节）
o Recipient Key: 0xe39a0c7c77b43f03b4b39ab9a268699f (16 bytes)
o 收件人密钥：0xe39a0c7c77b43f03b4b39ab9a268699f（16字节）
o Common IV: 0x2ca58fb85ff1b81c0b7181b85e (13 bytes)
o 通用IV:0x2ca58fb85ff1b81c0b7181b85e（13字节）
From the previous parameters and a Partial IV equal to 0 (both for sender and recipient):
根据前面的参数和等于0的部分IV（发件人和收件人）：
o sender nonce: 0x2ca58fb85ff1b81c0b7181b85e (13 bytes)
o 发送方nonce:0x2ca58fb85ff1b81c0b7181b85e（13字节）
o recipient nonce: 0x2da58fb85ff1b81d0b7181b85e (13 bytes)
o 收件人当前值：0x2da58fb85ff1b81d0b7181b85e（13字节）
Inputs:
投入：
o Master Secret: 0x0102030405060708090a0b0c0d0e0f10 (16 bytes)
o 主密钥：0x0102030405060708090a0b0c0d0e0f10（16字节）
o Master Salt: 0x9e7ca92223786340 (8 bytes)
o 主盐：0x9e7ca92223786340（8字节）
o Sender ID: 0x01 (1 byte)
o 发送方ID:0x01（1字节）
o Recipient ID: 0x (0 byte)
o 收件人ID:0x（0字节）
o ID Context: 0x37cbf3210017a2d3 (8 bytes)
o ID上下文：0x37cbf3210017a2d3（8字节）
From the previous parameters,
根据前面的参数，
o info (for Sender Key): 0x8541014837cbf3210017a2d30a634b657910 (18 bytes)
o 信息（用于发送方密钥）：0x8541014837cbf3210017a2d30a634b657910（18字节）
o info (for Recipient Key): 0x85404837cbf3210017a2d30a634b657910 (17 bytes)
o 信息（收件人密钥）：0x85404837cbf3210017a2d30a634b657910（17字节）
o info (for Common IV): 0x85404837cbf3210017a2d30a6249560d (16 bytes)
o 信息（通用IV）：0x85404837cbf3210017a2d30a6249560d（16字节）
Outputs:
产出：
o Sender Key: 0xe39a0c7c77b43f03b4b39ab9a268699f (16 bytes)
o 发送方密钥：0xe39a0c7c77b43f03b4b39ab9a268699f（16字节）
o Recipient Key: 0xaf2a1300a5e95788b356336eeecd2b92 (16 bytes)
o 收件人密钥：0xAF2A1300A5E95788B35636EEECD2B92（16字节）
o Common IV: 0x2ca58fb85ff1b81c0b7181b85e (13 bytes)
o 通用IV:0x2ca58fb85ff1b81c0b7181b85e（13字节）
From the previous parameters and a Partial IV equal to 0 (both for sender and recipient):
根据前面的参数和等于0的部分IV（发件人和收件人）：
o sender nonce: 0x2da58fb85ff1b81d0b7181b85e (13 bytes)
o 发送方nonce:0x2da58fb85ff1b81d0b7181b85e（13字节）
o recipient nonce: 0x2ca58fb85ff1b81c0b7181b85e (13 bytes)
o 接收人当前值：0x2ca58fb85ff1b81c0b7181b85e（13字节）
This section contains a test vector for an OSCORE-protected CoAP GET request using the security context derived in Appendix C.1. The unprotected request only contains the Uri-Path and Uri-Host options.
本节包含使用附录C.1中导出的安全上下文的OSCORE保护CoAP GET请求的测试向量。未受保护的请求仅包含Uri路径和Uri主机选项。
Unprotected CoAP request: 0x44015d1f00003974396c6f63616c686f737483747631 (22 bytes)
未受保护的CoAP请求：0x44015D1F00003974396C6F63616C686F7377483747631（22字节）
Common Context:
共同背景：
o AEAD Algorithm: 10 (AES-CCM-16-64-128)
o AEAD算法：10（AES-CCM-16-64-128）
o Key Derivation Function: HKDF SHA-256
o 密钥派生函数：HKDF SHA-256
o Common IV: 0x4622d4dd6d944168eefb54987c (13 bytes)
o 通用IV:0x4622d4dd6d944168eefb54987c（13字节）
Sender Context:
发件人上下文：
o Sender ID: 0x (0 byte)
o 发件人ID:0x（0字节）
o Sender Key: 0xf0910ed7295e6ad4b54fc793154302ff (16 bytes)
o 发送方密钥：0xf0910ed7295e6ad4b54fc793154302ff（16字节）
o Sender Sequence Number: 20
o 发送者序号：20
The following COSE and cryptographic parameters are derived:
导出了以下COSE和加密参数：
o Partial IV: 0x14 (1 byte)
o 第四部分：0x14（1字节）
o kid: 0x (0 byte)
o kid:0x（0字节）
o aad_array: 0x8501810a40411440 (8 bytes)
o aad_阵列：0x8501810a40411440（8字节）
o AAD: 0x8368456e63727970743040488501810a40411440 (20 bytes)
o AAD:0x8368456e63727970743040488501810a40411440（20字节）
o plaintext: 0x01b3747631 (5 bytes)
o 纯文本：0x01b3747631（5字节）
o encryption key: 0xf0910ed7295e6ad4b54fc793154302ff (16 bytes)
o 加密密钥：0xf0910ed7295e6ad4b54fc793154302ff（16字节）
o nonce: 0x4622d4dd6d944168eefb549868 (13 bytes)
o nonce:0x4622d4dd6d944168eefb549868（13字节）
From the previous parameter, the following is derived:
根据上一个参数，将导出以下内容：
o OSCORE option value: 0x0914 (2 bytes)
o OSCORE选项值：0x0914（2字节）
o ciphertext: 0x612f1092f1776f1c1668b3825e (13 bytes)
o 密文：0x612f1092f1776f1c1668b3825e（13字节）
From there:
从那里：
o Protected CoAP request (OSCORE message): 0x44025d1f00003974396c6f6 3616c686f7374620914ff612f1092f1776f1c1668b3825e (35 bytes)
o 受保护的CoAP请求（OSCORE消息）：0x44025d1f00003974396c6f6 3616c686f7374620914ff612f1092f1776f1c1668b3825e（35字节）
This section contains a test vector for an OSCORE-protected CoAP GET request using the security context derived in Appendix C.2. The unprotected request only contains the Uri-Path and Uri-Host options.
本节包含使用附录C.2中导出的安全上下文的OSCORE保护CoAP GET请求的测试向量。未受保护的请求仅包含Uri路径和Uri主机选项。
Unprotected CoAP request: 0x440171c30000b932396c6f63616c686f737483747631 (22 bytes)
未受保护的CoAP请求：0x440171C30000B932396C6F63616C686F7377483747631（22字节）
Common Context:
共同背景：
o AEAD Algorithm: 10 (AES-CCM-16-64-128)
o AEAD算法：10（AES-CCM-16-64-128）
o Key Derivation Function: HKDF SHA-256
o 密钥派生函数：HKDF SHA-256
o Common IV: 0xbe35ae297d2dace910c52e99f9 (13 bytes)
o 通用IV:0xbe35ae297d2dace910c52e99f9（13字节）
Sender Context:
发件人上下文：
o Sender ID: 0x00 (1 bytes)
o 发件人ID:0x00（1字节）
o Sender Key: 0x321b26943253c7ffb6003b0b64d74041 (16 bytes)
o 发送方密钥：0x321b26943253c7ffb6003b0b64d74041（16字节）
o Sender Sequence Number: 20
o 发送者序号：20
The following COSE and cryptographic parameters are derived:
导出了以下COSE和加密参数：
o Partial IV: 0x14 (1 byte)
o 第四部分：0x14（1字节）
o kid: 0x00 (1 byte)
o kid:0x00（1字节）
o aad_array: 0x8501810a4100411440 (9 bytes)
o aad_阵列：0x8501810a4100411440（9字节）
o AAD: 0x8368456e63727970743040498501810a4100411440 (21 bytes)
o AAD:0x8368456e63727970743040498501810a4100411440（21字节）
o plaintext: 0x01b3747631 (5 bytes)
o 纯文本：0x01b3747631（5字节）
o encryption key: 0x321b26943253c7ffb6003b0b64d74041 (16 bytes)
o 加密密钥：0x321b26943253c7ffb6003b0b64d74041（16字节）
o nonce: 0xbf35ae297d2dace910c52e99ed (13 bytes)
o nonce:0xbf35ae297d2dace910c52e99ed（13字节）
From the previous parameter, the following is derived:
根据上一个参数，将导出以下内容：
o OSCORE option value: 0x091400 (3 bytes)
o OSCORE选项值：0x091400（3字节）
o ciphertext: 0x4ed339a5a379b0b8bc731fffb0 (13 bytes)
o 密文：0x4ED339A5A379B0B8BC731FFB0（13字节）
From there:
从那里：
o Protected CoAP request (OSCORE message): 0x440271c30000b932396c6f6 3616c686f737463091400ff4ed339a5a379b0b8bc731fffb0 (36 bytes)
o 受保护的CoAP请求（OSCORE消息）：0x440271c30000b932396c6f6 3616C686F737746309400FF4ED339A5A379B0B8BC731FFB0（36字节）
This section contains a test vector for an OSCORE-protected CoAP GET request for an application that sets the ID Context and requires it to be sent in the request, so 'kid context' is present in the protected message. This test vector uses the security context derived in Appendix C.3. The unprotected request only contains the Uri-Path and Uri-Host options.
本节包含应用程序的受OSCORE保护的CoAP GET请求的测试向量，该应用程序设置ID上下文并要求在请求中发送ID上下文，因此受保护消息中存在“kid Context”。该测试向量使用附录C.3中导出的安全上下文。未受保护的请求仅包含Uri路径和Uri主机选项。
Unprotected CoAP request: 0x44012f8eef9bbf7a396c6f63616c686f737483747631 (22 bytes)
未受保护的CoAP请求：0x44012F8EEF9BBF7A396C6F63616C686F7377483747631（22字节）
Common Context:
共同背景：
o AEAD Algorithm: 10 (AES-CCM-16-64-128)
o AEAD算法：10（AES-CCM-16-64-128）
o Key Derivation Function: HKDF SHA-256
o 密钥派生函数：HKDF SHA-256
o Common IV: 0x2ca58fb85ff1b81c0b7181b85e (13 bytes)
o 通用IV:0x2ca58fb85ff1b81c0b7181b85e（13字节）
o ID Context: 0x37cbf3210017a2d3 (8 bytes)
o ID上下文：0x37cbf3210017a2d3（8字节）
Sender Context:
发件人上下文：
o Sender ID: 0x (0 bytes)
o 发件人ID:0x（0字节）
o Sender Key: 0xaf2a1300a5e95788b356336eeecd2b92 (16 bytes)
o 发送方密钥：0xAF2A1300A5E95788B35636EEECD2B92（16字节）
o Sender Sequence Number: 20
o 发送者序号：20
The following COSE and cryptographic parameters are derived:
导出了以下COSE和加密参数：
o Partial IV: 0x14 (1 byte)
o 第四部分：0x14（1字节）
o kid: 0x (0 byte)
o kid:0x（0字节）
o kid context: 0x37cbf3210017a2d3 (8 bytes)
o 儿童上下文：0x37cbf3210017a2d3（8字节）
o aad_array: 0x8501810a40411440 (8 bytes)
o aad_阵列：0x8501810a40411440（8字节）
o AAD: 0x8368456e63727970743040488501810a40411440 (20 bytes)
o AAD:0x8368456e63727970743040488501810a40411440（20字节）
o plaintext: 0x01b3747631 (5 bytes)
o 纯文本：0x01b3747631（5字节）
o encryption key: 0xaf2a1300a5e95788b356336eeecd2b92 (16 bytes)
o 加密密钥：0xAF2A1300A5E95788B35636EEECD2B92（16字节）
o nonce: 0x2ca58fb85ff1b81c0b7181b84a (13 bytes)
o nonce:0x2ca58fb85ff1b81c0b7181b84a（13字节）
From the previous parameter, the following is derived:
根据上一个参数，将导出以下内容：
o OSCORE option value: 0x19140837cbf3210017a2d3 (11 bytes)
o OSCORE选项值：0x19140837cbf3210017a2d3（11字节）
o ciphertext: 0x72cd7273fd331ac45cffbe55c3 (13 bytes)
o 密文：0x72cd7273fd331ac45cffbe55c3（13字节）
From there:
从那里：
o Protected CoAP request (OSCORE message): 0x44022f8eef9bbf7a396c6f63616c686f73746b19140837cbf3210017a2d3ff 72cd7273fd331ac45cffbe55c3 (44 bytes)
o 受保护的CoAP请求（OSCORE消息）：0x44022f8eef9bbf7a396c6f63616c686f73746b19140837cbf3210017a2d3ff 72CD7273FD331A45CFFBE55C3（44字节）
This section contains a test vector for an OSCORE-protected 2.05 (Content) response to the request in Appendix C.4. The unprotected response has payload "Hello World!" and no options. The protected response does not contain a 'kid' nor a Partial IV. Note that some parameters are derived from the request.
本节包含针对附录C.4中请求的OSCORE保护2.05（内容）响应的测试向量。未受保护的响应具有有效负载“Hello World！”并且没有选项。受保护的响应不包含“kid”或部分IV。请注意，某些参数是从请求派生的。
Unprotected CoAP response: 0x64455d1f00003974ff48656c6c6f20576f726c6421 (21 bytes)
未受保护的CoAP响应：0x64455D1F00003974FF48656C6F20576F726C6421（21字节）
Common Context:
共同背景：
o AEAD Algorithm: 10 (AES-CCM-16-64-128)
o AEAD算法：10（AES-CCM-16-64-128）
o Key Derivation Function: HKDF SHA-256
o 密钥派生函数：HKDF SHA-256
o Common IV: 0x4622d4dd6d944168eefb54987c (13 bytes)
o 通用IV:0x4622d4dd6d944168eefb54987c（13字节）
Sender Context:
发件人上下文：
o Sender ID: 0x01 (1 byte)
o 发送方ID:0x01（1字节）
o Sender Key: 0xffb14e093c94c9cac9471648b4f98710 (16 bytes)
o 发送方密钥：0xffb14e093c94c9cac9471648b4f98710（16字节）
o Sender Sequence Number: 0
o 发件人序列号：0
The following COSE and cryptographic parameters are derived:
导出了以下COSE和加密参数：
o aad_array: 0x8501810a40411440 (8 bytes)
o aad_阵列：0x8501810a40411440（8字节）
o AAD: 0x8368456e63727970743040488501810a40411440 (20 bytes)
o AAD:0x8368456e63727970743040488501810a40411440（20字节）
o plaintext: 0x45ff48656c6c6f20576f726c6421 (14 bytes)
o 纯文本：0x45FF48656C6F20576F726C6421（14字节）
o encryption key: 0xffb14e093c94c9cac9471648b4f98710 (16 bytes)
o 加密密钥：0xffb14e093c94c9cac9471648b4f98710（16字节）
o nonce: 0x4622d4dd6d944168eefb549868 (13 bytes)
o nonce:0x4622d4dd6d944168eefb549868（13字节）
From the previous parameter, the following is derived:
根据上一个参数，将导出以下内容：
o OSCORE option value: 0x (0 bytes)
o OSCORE选项值：0x（0字节）
o ciphertext: 0xdbaad1e9a7e7b2a813d3c31524378303cdafae119106 (22 bytes)
o 密文：0xDBAA1E9A7E7B2A813D3C31524378303CDAFAE119106（22字节）
From there:
从那里：
o Protected CoAP response (OSCORE message): 0x64445d1f0000397490ffdbaad1e9a7e7b2a813d3c31524378303cdafae119106 (32 bytes)
o 受保护的CoAP响应（OSCORE消息）：0x64445D1F0000397490FFDBAA1E9A7E7B2A813D3C31524378303CDAFAE119106（32字节）
This section contains a test vector for an OSCORE protected 2.05 (Content) response to the request in Appendix C.4. The unprotected response has payload "Hello World!" and no options. The protected response does not contain a 'kid', but contains a Partial IV. Note that some parameters are derived from the request.
本节包含针对附录C.4中请求的OSCORE保护2.05（内容）响应的测试向量。未受保护的响应具有有效负载“Hello World！”并且没有选项。受保护的响应不包含“kid”，但包含部分IV。请注意，某些参数是从请求派生的。
Unprotected CoAP response: 0x64455d1f00003974ff48656c6c6f20576f726c6421 (21 bytes)
未受保护的CoAP响应：0x64455D1F00003974FF48656C6F20576F726C6421（21字节）
Common Context:
共同背景：
o AEAD Algorithm: 10 (AES-CCM-16-64-128)
o AEAD算法：10（AES-CCM-16-64-128）
o Key Derivation Function: HKDF SHA-256
o 密钥派生函数：HKDF SHA-256
o Common IV: 0x4622d4dd6d944168eefb54987c (13 bytes)
o 通用IV:0x4622d4dd6d944168eefb54987c（13字节）
Sender Context:
发件人上下文：
o Sender ID: 0x01 (1 byte)
o 发送方ID:0x01（1字节）
o Sender Key: 0xffb14e093c94c9cac9471648b4f98710 (16 bytes)
o 发送方密钥：0xffb14e093c94c9cac9471648b4f98710（16字节）
o Sender Sequence Number: 0
o 发件人序列号：0
The following COSE and cryptographic parameters are derived:
导出了以下COSE和加密参数：
o Partial IV: 0x00 (1 byte)
o 第四部分：0x00（1字节）
o aad_array: 0x8501810a40411440 (8 bytes)
o aad_阵列：0x8501810a40411440（8字节）
o AAD: 0x8368456e63727970743040488501810a40411440 (20 bytes)
o AAD:0x8368456e63727970743040488501810a40411440（20字节）
o plaintext: 0x45ff48656c6c6f20576f726c6421 (14 bytes)
o 纯文本：0x45FF48656C6F20576F726C6421（14字节）
o encryption key: 0xffb14e093c94c9cac9471648b4f98710 (16 bytes)
o 加密密钥：0xffb14e093c94c9cac9471648b4f98710（16字节）
o nonce: 0x4722d4dd6d944169eefb54987c (13 bytes)
o nonce:0x4722d4dd6d944169eefb54987c（13字节）
From the previous parameter, the following is derived:
根据上一个参数，将导出以下内容：
o OSCORE option value: 0x0100 (2 bytes)
o OSCORE选项值：0x0100（2字节）
o ciphertext: 0x4d4c13669384b67354b2b6175ff4b8658c666a6cf88e (22 bytes)
o 密文：0x4d4c13669384b67354b2b6175ff4b8658c666a6cf88e（22字节）
From there:
从那里：
o Protected CoAP response (OSCORE message): 0x64445d1f00003974920100 ff4d4c13669384b67354b2b6175ff4b8658c666a6cf88e (34 bytes)
o 受保护的CoAP响应（OSCORE消息）：0x64445D1F00003974920100FF4Dc13669384B67354B2B6175FF4B8658C666A6CF88E（34字节）
This section describes the threat model using the terms of [RFC3552].
本节使用[RFC3552]的术语描述威胁模型。
It is assumed that the endpoints running OSCORE have not themselves been compromised. The attacker is assumed to have control of the CoAP channel over which the endpoints communicate, including intermediary nodes. The attacker is capable of launching any passive or active on-path or off-path attacks; including eavesdropping, traffic analysis, spoofing, insertion, modification, deletion, delay, replay, man-in-the-middle, and denial-of-service attacks. This means that the attacker can read any CoAP message on the network and undetectably remove, change, or inject forged messages onto the wire.
假设运行OSCORE的端点本身没有受到损害。假定攻击者控制端点通信的CoAP通道，包括中间节点。攻击者能够发起任何被动或主动的路径上或路径外攻击；包括窃听、流量分析、欺骗、插入、修改、删除、延迟、重播、中间人攻击和拒绝服务攻击。这意味着攻击者可以读取网络上的任何CoAP消息，并在无法检测到的情况下删除、更改或将伪造消息注入网络。
OSCORE targets the protection of the CoAP request/response layer (Section 2 of [RFC7252]) between the endpoints, including the CoAP Payload, Code, Uri-Path/Uri-Query, and the other Class E option instances (Section 4.1).
OSCORE的目标是保护端点之间的CoAP请求/响应层（RFC7252第2节），包括CoAP有效负载、代码、Uri路径/Uri查询和其他E类选项实例（第4.1节）。
OSCORE does not protect the CoAP messaging layer (Section 2 of [RFC7252]) or other lower layers involved in routing and transporting the CoAP requests and responses.
OSCORE不保护CoAP消息层（RFC7252第2节）或路由和传输CoAP请求和响应所涉及的其他较低层。
Additionally, OSCORE does not protect Class U option instances (Section 4.1), as these are used to support CoAP forward proxy operations (see Section 5.7.2 of [RFC7252]). The supported proxies (forwarding, cross-protocol, e.g., CoAP to CoAP-mappable protocols such as HTTP) must be able to change certain Class U options (by instruction from the Client), resulting in the CoAP request being redirected to the server. Changes caused by the proxy may result in the request not reaching the server or reaching the wrong server. For cross-protocol proxies, mappings are done on the Outer part of
此外，OSCORE不保护U类选项实例（第4.1节），因为这些实例用于支持CoAP转发代理操作（见[RFC7252]第5.7.2节）。受支持的代理（转发、跨协议，例如，CoAP到CoAP可映射协议，如HTTP）必须能够更改某些U类选项（通过客户端的指令），从而将CoAP请求重定向到服务器。代理引起的更改可能导致请求未到达服务器或到达错误的服务器。对于跨协议代理，映射是在
the message so these protocols are essentially used as transport. Manipulation of these options may thus impact whether the protected message reaches or does not reach the destination endpoint.
因此，这些协议基本上用作传输。因此，对这些选项的操作可能会影响受保护消息是否到达目标端点。
Attacks on unprotected CoAP message fields generally causes denial-of-service attacks which are out of scope of this document, more details are given in Appendix D.5.
对未受保护的CoAP消息字段的攻击通常会导致拒绝服务攻击，这超出了本文档的范围，更多详细信息见附录D.5。
Attacks against the CoAP request-response layer are in scope. OSCORE is intended to protect against eavesdropping, spoofing, insertion, modification, deletion, replay, and man-in-the middle attacks.
针对CoAP请求响应层的攻击在范围内。OSCORE旨在防止窃听、欺骗、插入、修改、删除、重播和中间人攻击。
OSCORE is susceptible to traffic analysis as discussed later in Appendix D.
OSCORE易受流量分析的影响，详见附录D。
CoAP is designed to work with intermediaries reading and/or changing CoAP message fields to perform supporting operations in constrained environments, e.g., forwarding and cross-protocol translations.
CoAP旨在与读取和/或更改CoAP消息字段的中介机构协作，以在受限环境中执行支持操作，例如转发和跨协议转换。
Securing CoAP on the transport layer protects the entire message between the endpoints, in which case CoAP proxy operations are not possible. In order to enable proxy operations, security on the transport layer needs to be terminated at the proxy; in which case, the CoAP message in its entirety is unprotected in the proxy.
在传输层上保护CoAP可以保护端点之间的整个消息，在这种情况下，CoAP代理操作是不可能的。为了启用代理操作，需要在代理上终止传输层上的安全性；在这种情况下，整个CoAP消息在代理中不受保护。
Requirements for CoAP end-to-end security are specified in [CoAP-E2E-Sec], in particular, forwarding is detailed in Section 2.2.1. The client and server are assumed to be honest, while proxies and gateways are only trusted to perform their intended operations.
[CoAP-E2E-Sec]中规定了CoAP端到端安全要求，特别是第2.2.1节中详细说明了转发。客户机和服务器被认为是诚实的，而代理和网关只被信任来执行其预期的操作。
By working at the CoAP layer, OSCORE enables different CoAP message fields to be protected differently, which allows message fields required for proxy operations to be available to the proxy while message fields intended for the other endpoint remain protected. In the remainder of this section, we analyze how OSCORE protects the protected message fields and the consequences of message fields intended for proxy operation being unprotected.
通过在CoAP层工作，OSCORE可以以不同的方式保护不同的CoAP消息字段，这使得代理操作所需的消息字段可用于代理，而用于其他端点的消息字段保持保护。在本节的其余部分中，我们将分析OSCORE如何保护受保护的消息字段以及用于代理操作的消息字段未受保护的后果。
Protected message fields are included in the plaintext (Section 5.3) and the AAD (Section 5.4) of the COSE_Encrypt0 object and encrypted using an AEAD algorithm.
受保护的消息字段包含在COSE_Encrypt0对象的明文（第5.3节）和AAD（第5.4节）中，并使用AEAD算法进行加密。
OSCORE depends on a preestablished random Master Secret (Section 12.3) used to derive encryption keys, and a construction for making (key, nonce) pairs unique (Appendix D.4). Assuming this is true, and the keys are used for no more data than indicated in Section 7.2.1, OSCORE should provide the following guarantees:
OSCORE取决于用于导出加密密钥的预先建立的随机主密钥（第12.3节），以及使（密钥、非密钥）对唯一的构造（附录D.4）。假设这是真的，并且密钥用于的数据不超过第7.2.1节所述的数据，OSCORE应提供以下保证：
o Confidentiality: An attacker should not be able to determine the plaintext contents of a given OSCORE message or determine that different plaintexts are related (Section 5.3).
o 机密性：攻击者不应能够确定给定OSCORE消息的明文内容或确定不同的明文是相关的（第5.3节）。
o Integrity: An attacker should not be able to craft a new OSCORE message with protected message fields different from an existing OSCORE message that will be accepted by the receiver.
o 完整性：攻击者不应能够创建一个新的OSCORE消息，该消息具有与接收方将接受的现有OSCORE消息不同的受保护消息字段。
o Request-response binding: An attacker should not be able to make a client match a response to the wrong request.
o 请求-响应绑定：攻击者不应使客户端将响应与错误的请求相匹配。
o Non-replayability: An attacker should not be able to cause the receiver to accept a message that it has previously received and accepted.
o 不可重放性：攻击者不应使接收者接受其先前接收并接受的消息。
In the above, the attacker is anyone except the endpoints, e.g., a compromised intermediary. Informally, OSCORE provides these properties by AEAD-protecting the plaintext with a strong key and uniqueness of (key, nonce) pairs. AEAD encryption [RFC5116] provides confidentiality and integrity for the data. Response-request binding is provided by including the 'kid' and Partial IV of the request in the AAD of the response. Non-replayability of requests and notifications is provided by using unique (key, nonce) pairs and a replay protection mechanism (application dependent, see Section 7.4).
在上述情况下，攻击者是端点以外的任何人，例如，受损的中间人。非正式地说，OSCORE通过AEAD提供这些属性，使用强密钥和（密钥，nonce）对的唯一性保护明文。AEAD加密[RFC5116]为数据提供机密性和完整性。响应请求绑定是通过在响应的AAD中包含请求的“kid”和部分IV来提供的。请求和通知的不可重放性是通过使用唯一（键、nonce）对和重放保护机制提供的（依赖于应用程序，请参见第7.4节）。
OSCORE is susceptible to a variety of traffic analysis attacks based on observing the length and timing of encrypted packets. OSCORE does not provide any specific defenses against this form of attack, but the application may use a padding mechanism to prevent an attacker from directly determining the length of the padding. However, information about padding may still be revealed by side-channel attacks observing differences in timing.
OSCORE容易受到基于观察加密数据包的长度和时间的各种流量分析攻击。OSCORE没有针对这种形式的攻击提供任何特定的防御，但应用程序可以使用填充机制来防止攻击者直接确定填充的长度。然而，观察到时间上的差异，侧通道攻击仍然可能会泄露有关填充的信息。
In this section, we show that (key, nonce) pairs are unique as long as the requirements in Sections 3.3 and 7.2.1 are followed.
在本节中，我们将说明只要遵循第3.3节和第7.2.1节中的要求，（键、非键）对是唯一的。
Fix a Common Context (Section 3.1) and an endpoint, called the encrypting endpoint. An endpoint may alternate between client and server roles, but each endpoint always encrypts with the Sender Key of its Sender Context. Sender Keys are (stochastically) unique since
修复一个公共上下文（第3.1节）和一个称为加密端点的端点。端点可以在客户端和服务器角色之间交替，但每个端点始终使用其发送方上下文的发送方密钥进行加密。发件人密钥（随机）唯一，因为
they are derived with HKDF using unique Sender IDs, so messages encrypted by different endpoints use different keys. It remains to be proven that the nonces used by the fixed endpoint are unique.
它们由HKDF使用唯一的发送者ID派生，因此由不同端点加密的消息使用不同的密钥。固定端点使用的nonce是唯一的，这有待证明。
Since the Common IV is fixed, the nonces are determined by PIV, where PIV takes the value of the Partial IV of the request or of the response, and by the Sender ID of the endpoint generating that Partial IV (ID_PIV). The nonce construction (Section 5.2) with the size of the ID_PIV (S) creates unique nonces for different (ID_PIV, PIV) pairs. There are two cases:
由于公共IV是固定的，所以nonce由PIV确定，其中PIV取请求或响应的部分IV的值，并由生成该部分IV的端点的发送方ID（ID_PIV）确定。具有ID_PIV大小的nonce构造（第5.2节）为不同的（ID_PIV，PIV）对创建唯一的nonce。有两种情况：
A. For requests, and responses with Partial IV (e.g., Observe notifications):
A.对于部分IV的请求和响应（例如，遵守通知）：
o ID_PIV = Sender ID of the encrypting endpoint
o ID_PIV=加密端点的发送方ID
o PIV = current Partial IV of the encrypting endpoint
o PIV=加密端点的当前第IV部分
Since the encrypting endpoint steps the Partial IV for each use, the nonces used in case A are all unique as long as the number of encrypted messages is kept within the required range (Section 7.2.1).
由于加密端点在每次使用时都会执行部分IV，因此只要加密消息的数量保持在要求的范围内（第7.2.1节），案例A中使用的nonce都是唯一的。
B. For responses without Partial IV (e.g., single response to a request):
B.对于没有部分IV的响应（例如，对请求的单个响应）：
o ID_PIV = Sender ID of the endpoint generating the request
o ID_PIV=生成请求的端点的发送方ID
o PIV = Partial IV of the request
o PIV=请求的第四部分
Since the Sender IDs are unique, ID_PIV is different from the Sender ID of the encrypting endpoint. Therefore, the nonces in case B are different compared to nonces in case A, where the encrypting endpoint generated the Partial IV. Since the Partial IV of the request is verified for replay (Section 7.4) associated to this Recipient Context, PIV is unique for this ID_PIV, which makes all nonces in case B distinct.
由于发送方ID是唯一的，因此ID_PIV与加密端点的发送方ID不同。因此，情况B中的nonce与情况A中的nonce不同，在情况A中，加密端点生成了部分IV。由于请求的部分IV被验证为与此接收方上下文相关联的重播（第7.4节），因此对于此ID_PIV，PIV是唯一的，这使得情况B中的所有nonce都不同。
This section analyzes attacks on message fields that are not protected by OSCORE according to the threat model Appendix D.1.
根据威胁模型附录D.1，本节分析对未受OSCORE保护的消息字段的攻击。
o Version. The CoAP version [RFC7252] is not expected to be sensitive to disclosure. Currently, there is only one CoAP version defined. A change of this parameter is potentially a
o 版本CoAP版本[RFC7252]预计对披露不敏感。目前，仅定义了一个CoAP版本。此参数的更改可能是错误的
denial-of-service attack. Future versions of CoAP need to analyze attacks to OSCORE-protected messages due to an adversary changing the CoAP version.
拒绝服务攻击。由于对手更改CoAP版本，CoAP的未来版本需要分析对OSCORE保护消息的攻击。
o Token/Token Length. The Token field is a client-local identifier for differentiating between concurrent requests [RFC7252]. CoAP proxies are allowed to read and change Token and Token Length between hops. An eavesdropper reading the Token can match requests to responses that can be used in traffic analysis. In particular, this is true for notifications, where multiple responses are matched to one request. Modifications of Token and Token Length by an on-path attacker may become a denial-of-service attack, since it may prevent the client to identify to which request the response belongs or to find the correct information to verify integrity of the response.
o 令牌/令牌长度。令牌字段是用于区分并发请求的客户端本地标识符[RFC7252]。允许CoAP代理读取和更改令牌以及跃点之间的令牌长度。读取令牌的窃听者可以将请求与可用于流量分析的响应进行匹配。特别是对于通知来说，这是正确的，其中多个响应与一个请求匹配。路径上攻击者对令牌和令牌长度的修改可能会成为拒绝服务攻击，因为这可能会阻止客户端识别响应所属的请求或找到正确的信息以验证响应的完整性。
o Code. The Outer CoAP Code of an OSCORE message is POST or FETCH for requests with corresponding response codes. An endpoint receiving the message discards the Outer CoAP Code and uses the Inner CoAP Code instead (see Section 4.2). Hence, modifications from attackers to the Outer Code do not impact the receiving endpoint. However, changing the Outer Code from FETCH to a Code value for a method that does not work with Observe (such as POST) may, depending on proxy implementation since Observe is undefined for several Codes, cause the proxy to not forward notifications, which is a denial-of-service attack. The use of FETCH rather than POST reveals no more than what is revealed by the presence of the Outer Observe option.
o 密码OSCORE消息的外部CoAP代码是具有相应响应代码的请求的POST或FETCH。接收消息的端点丢弃外部CoAP代码，而使用内部CoAP代码（参见第4.2节）。因此，攻击者对外部代码的修改不会影响接收端点。但是，将外部代码从FETCH更改为不使用Observe（如POST）的方法的代码值可能会导致代理不转发通知，这是一种拒绝服务攻击，这取决于代理实现，因为Observe对多个代码没有定义。使用FETCH而不是POST只显示了外部Observe选项所显示的内容。
o Type/Message ID. The Type/Message ID fields [RFC7252] reveal information about the UDP transport binding, e.g., an eavesdropper reading the Type or Message ID gain information about how UDP messages are related to each other. CoAP proxies are allowed to change Type and Message ID. These message fields are not present in CoAP over TCP [RFC8323] and do not impact the request/response message. A change of these fields in a UDP hop is a denial-of-service attack. By sending an ACK, an attacker can make the endpoint believe that it does not need to retransmit the previous message. By sending a RST, an attacker may be able to cancel an observation. By changing a NON to a CON, the attacker can cause the receiving endpoint to ACK messages for which no ACK was requested.
o 类型/消息ID。类型/消息ID字段[RFC7252]显示有关UDP传输绑定的信息，例如，读取类型或消息ID的窃听者获取有关UDP消息如何相互关联的信息。允许CoAP代理更改类型和消息ID。这些消息字段不存在于通过TCP的CoAP[RFC8323]中，并且不会影响请求/响应消息。UDP跃点中这些字段的更改是拒绝服务攻击。通过发送ACK，攻击者可以使端点相信它不需要重新传输以前的消息。通过发送RST，攻击者可以取消观察。通过将非更改为CON，攻击者可以使接收端点确认未请求任何ACK的消息。
o Length. This field contains the length of the message [RFC8323], which may be used for traffic analysis. This message field is not present in CoAP over UDP and does not impact the request/response message. A change of Length is a denial-of-service attack similar to changing TCP header fields.
o 长此字段包含消息[RFC8323]的长度，可用于流量分析。此消息字段不存在于通过UDP的CoAP中，并且不会影响请求/响应消息。更改长度是一种拒绝服务攻击，类似于更改TCP头字段。
o Max-Age. The Outer Max-Age is set to zero to avoid unnecessary caching of OSCORE error responses. Changing this value thus may cause unnecessary caching. No additional information is carried with this option.
o 最大年龄。Outer Max Age设置为零，以避免对OSCORE错误响应进行不必要的缓存。因此，更改此值可能会导致不必要的缓存。此选项不附带任何附加信息。
o Proxy-Uri/Proxy-Scheme. These options are used in CoAP forward proxy deployments. With OSCORE, the Proxy-Uri option does not contain the Uri-Path/Uri-Query parts of the URI. The other parts of Proxy-Uri cannot be protected because forward proxies need to change them in order to perform their functions. The server can verify what scheme is used in the last hop, but not what was requested by the client or what was used in previous hops.
o 代理Uri/代理方案。这些选项用于CoAP转发代理部署。对于OSCORE，代理Uri选项不包含Uri的Uri路径/Uri查询部分。无法保护代理Uri的其他部分，因为转发代理需要更改它们才能执行其功能。服务器可以验证在最后一个跃点中使用的方案，但不能验证客户端请求的方案或在以前的跃点中使用的方案。
o Uri-Host/Uri-Port. In forward proxy deployments, the Uri-Host/ Uri-Port may be changed by an adversary, and the application needs to handle the consequences of that (see Section 4.1.3.2). The Uri-Host may either be omitted, reveal information equivalent to that of the IP address, or reveal more privacy-sensitive information, which is discouraged.
o Uri主机/Uri端口。在前向代理部署中，Uri主机/Uri端口可能会被对手更改，应用程序需要处理由此产生的后果（请参阅第4.1.3.2节）。Uri主机可能被省略，显示与IP地址相同的信息，或者显示更多隐私敏感信息，这是不鼓励的。
o Observe. The Outer Observe option is intended for a proxy to support forwarding of Observe messages, but it is ignored by the endpoints since the Inner Observe option determines the processing in the endpoints. Since the Partial IV provides absolute ordering of notifications, it is not possible for an intermediary to spoof reordering (see Section 4.1.3.5). The absence of Partial IV, since only allowed for the first notification, does not prevent correct ordering of notifications. The size and distributions of notifications over time may reveal information about the content or nature of the notifications. Cancellations (Section 4.1.3.5.1) are not bound to the corresponding registrations in the same way responses are bound to requests in OSCORE (see Appendix D.3). However, that does not make attacks based on mismatched cancellations possible, since for cancellations to be accepted, all options in the decrypted message except for ETag options MUST be the same (see Section 4.1.3.5).
o 看到外部观察选项用于代理以支持观察消息的转发，但端点会忽略它，因为内部观察选项决定端点中的处理。由于Partial IV提供了通知的绝对排序，因此中间人不可能伪造重新排序（见第4.1.3.5节）。由于第四部分的缺失仅允许第一次通知，因此并不妨碍通知的正确排序。通知的大小和随时间的分布可能会揭示有关通知内容或性质的信息。取消（第4.1.3.5.1节）不受相应注册的约束，正如响应受OSCORE中请求的约束一样（见附录D.3）。但是，这并不能使基于不匹配取消的攻击成为可能，因为要接受取消，解密消息中除ETag选项外的所有选项必须相同（请参见第4.1.3.5节）。
o Block1/Block2/Size1/Size2. The Outer Block options enable fragmentation of OSCORE messages in addition to segmentation performed by the Inner Block options. The presence of these options indicates a large message being sent, and the message size can be estimated and used for traffic analysis. Manipulating these options is a potential denial-of-service attack, e.g., injection of alleged Block fragments. The specification of a
o Block1/Block2/Size1/Size2。除了由内部块选项执行的分段之外，外部块选项还支持OSCORE消息的分段。这些选项的存在表明发送了一条大消息，可以估计消息大小并用于流量分析。操纵这些选项是一种潜在的拒绝服务攻击，例如，注入所谓的块碎片。a的说明
maximum size of message, MAX_UNFRAGMENTED_SIZE (Section 4.1.3.4.2), above which messages will be dropped, is intended as one measure to mitigate this kind of attack.
消息的最大大小，最大未分段大小（第4.1.3.4.2节），超过该大小，消息将被丢弃，旨在作为缓解此类攻击的一种措施。
o No-Response. The Outer No-Response option is used to support proxy functionality, specifically to avoid error transmissions from proxies to clients, and to avoid bandwidth reduction to servers by proxies applying congestion control when not receiving responses. Modifying or introducing this option is a potential denial-of-service attack against the proxy operations, but since the option has an Inner value, its use can be securely agreed upon between the endpoints. The presence of this option is not expected to reveal any sensitive information about the message exchange.
o 没有回应。外部无响应选项用于支持代理功能，特别是避免从代理到客户端的错误传输，并避免代理在不接收响应时应用拥塞控制，从而减少服务器的带宽。修改或引入此选项是针对代理操作的潜在拒绝服务攻击，但由于此选项具有内部值，因此可以在端点之间安全地约定其使用。此选项的存在预计不会泄露有关消息交换的任何敏感信息。
o OSCORE. The OSCORE option contains information about the compressed COSE header. Changing this field may cause OSCORE verification to fail.
o 奥斯科尔。OSCORE选项包含有关压缩COSE头的信息。更改此字段可能会导致OSCORE验证失败。
Error messages occurring during CoAP processing are protected end-to-end. Error messages occurring during OSCORE processing are not always possible to protect, e.g., if the receiving endpoint cannot locate the right security context. For this setting, unprotected error messages are allowed as specified to prevent extensive retransmissions. Those error messages can be spoofed or manipulated, which is a potential denial-of-service attack.
CoAP处理过程中出现的错误消息受到端到端的保护。OSCORE处理期间发生的错误消息并不总是能够得到保护，例如，如果接收端点无法找到正确的安全上下文。对于此设置，允许未受保护的错误消息（如指定），以防止大量重新传输。这些错误消息可能被欺骗或操纵，这是一种潜在的拒绝服务攻击。
This document specifies OPTIONAL error codes and specific diagnostic payloads for OSCORE processing error messages. Such messages might reveal information about how many and which security contexts exist on the server. Servers MAY want to omit the diagnostic payload of error messages, use the same error code for all errors, or avoid responding altogether in case of OSCORE processing errors, if that is a security concern for the application. Moreover, clients MUST NOT rely on the error code or the diagnostic payload to trigger specific actions, as these errors are unprotected and can be spoofed or manipulated.
本文档为OSCORE处理错误消息指定可选错误代码和特定诊断有效载荷。这些消息可能会显示服务器上存在多少安全上下文以及哪些安全上下文的信息。服务器可能希望省略错误消息的诊断负载，对所有错误使用相同的错误代码，或者避免在发生OSCORE处理错误时完全响应，如果这是应用程序的安全问题。此外，客户端不得依赖错误代码或诊断有效负载来触发特定操作，因为这些错误不受保护，可能被欺骗或操纵。
Signaling messages used in CoAP over TCP [RFC8323] are intended to be hop-by-hop; spoofing signaling messages can be used as a denial-of-service attack of a TCP connection.
TCP上的CoAP[RFC8323]中使用的信令消息旨在逐跳发送；欺骗信令消息可以用作TCP连接的拒绝服务攻击。
In contrast to CoAP, where OSCORE does not protect header fields to enable CoAP-CoAP proxy operations, the use of OSCORE with HTTP is restricted to transporting a protected CoAP message over an HTTP hop. Any unprotected HTTP message fields may reveal information about the transport of the OSCORE message and enable various denial-of-service attacks. It is RECOMMENDED to additionally use TLS [RFC8446] for HTTP hops, which enables encryption and integrity protection of headers, but still leaves some information for traffic analysis.
与CoAP不同，OSCORE不保护头字段以启用CoAP CoAP代理操作，而将OSCORE与HTTP一起使用仅限于通过HTTP跃点传输受保护的CoAP消息。任何未受保护的HTTP消息字段都可能泄露有关OSCORE消息传输的信息，并启用各种拒绝服务攻击。建议对HTTP跃点另外使用TLS[RFC8446]，这可以实现头的加密和完整性保护，但仍为流量分析留下一些信息。
Data structure definitions in the present specification employ the CDDL language for conciseness and precision [RFC8610]. This appendix summarizes the small subset of CDDL that is used in the present specification.
本规范中的数据结构定义采用CDDL语言，以实现简洁性和精确性[RFC8610]。本附录总结了本规范中使用的CDDL的一小部分。
Within the subset being used here, a CDDL rule is of the form "name = type", where "name" is the name given to the "type". A "type" can be one of:
在这里使用的子集中，CDDL规则的形式为“name=type”，其中“name”是给定给“type”的名称。“类型”可以是以下类型之一：
o a reference to another named type, by giving its name. The predefined named types used in the present specification are as follows: "uint", an unsigned integer (as represented in CBOR by major type 0); "int", an unsigned or negative integer (as represented in CBOR by major type 0 or 1); "bstr", a byte string (as represented in CBOR by major type 2); "tstr", a text string (as represented in CBOR by major type 3);
o 通过提供另一命名类型的名称来引用该类型。本规范中使用的预定义命名类型如下：“uint”，一个无符号整数（在CBOR中由主类型0表示）；“int”，一个无符号或负整数（在CBOR中用主类型0或1表示）；“bstr”，一个字节字符串（在CBOR中由主类型2表示）；“tstr”，一个文本字符串（在CBOR中用主类型3表示）；
o a choice between two types, by giving both types separated by a "/";
o 在两种类型之间进行选择，给两种类型以“/”分隔；
o an array type (as represented in CBOR by major type 4), where the sequence of elements of the array is described by giving a sequence of entries separated by commas ",", and this sequence is enclosed by square brackets "[" and "]". Arrays described by an array description contain elements that correspond one-to-one to the sequence of entries given. Each entry of an array description is of the form "name : type", where "name" is the name given to the entry and "type" is the type of the array element corresponding to this entry.
o 一种数组类型（如CBOR中的主类型4所示），其中数组元素的顺序由逗号“，”分隔的条目序列描述，该序列由方括号“[”和“]”括起。由数组描述描述的数组包含与给定的条目序列一一对应的元素。数组描述的每个条目的形式为“name:type”，其中“name”是给定给该条目的名称，“type”是对应于该条目的数组元素的类型。
Acknowledgments
致谢
The following individuals provided input to this document: Christian Amsuess, Tobias Andersson, Carsten Bormann, Joakim Brorsson, Ben Campbell, Esko Dijk, Jaro Fietz, Thomas Fossati, Martin Gunnarsson, Klaus Hartke, Rikard Hoeglund, Mirja Kuehlewind, Kathleen Moriarty, Eric Rescorla, Michael Richardson, Adam Roach, Jim Schaad, Peter van der Stok, Dave Thaler, Martin Thomson, Marco Tiloca, William Vignat, and Malisa Vucinic.
以下个人为本文件提供了意见：克里斯蒂安·阿姆苏伊斯、托拜厄斯·安德森、卡斯滕·鲍曼、若阿金·布罗森、本·坎贝尔、埃斯科·迪克、雅罗·菲茨、托马斯·福萨蒂、马丁·甘纳森、克劳斯·哈特克、里卡德·霍格兰德、米迦·库勒温德、凯瑟琳·莫里亚蒂、埃里克·雷索拉、迈克尔·理查森、亚当·罗奇、吉姆·沙德、彼得·范德斯托克、，戴夫·泰勒、马丁·汤姆森、马可·蒂洛卡、威廉·维格纳特和玛丽莎·武奇尼奇。
Ludwig Seitz and Goeran Selander worked on this document as part of the CelticPlus project CyberWI, with funding from Vinnova. Ludwig Seitz had additional funding from the SSF project SEC4Factory under the grant RIT17-0032.
路德维希·塞茨（Ludwig Seitz）和戈兰·塞兰德（Goeran Selander）在文诺瓦（Vinnova）的资助下，作为CelticPlus项目CyberWI的一部分编写了本文件。路德维希·塞茨（Ludwig Seitz）从SSF项目SEC4Factory获得了RIT17-0032赠款项下的额外资金。
Authors' Addresses
作者地址
Goeran Selander Ericsson AB
戈兰·塞兰德·爱立信公司
Email: goran.selander@ericsson.com
Email: goran.selander@ericsson.com
John Mattsson Ericsson AB
约翰·马特森·爱立信律师事务所
Email: john.mattsson@ericsson.com
Email: john.mattsson@ericsson.com
Francesca Palombini Ericsson AB
弗朗西斯卡·帕隆比尼·爱立信股份有限公司
Email: francesca.palombini@ericsson.com
Email: francesca.palombini@ericsson.com
Ludwig Seitz RISE
路德维希塞茨高地
Email: ludwig.seitz@ri.se
Email: ludwig.seitz@ri.se