Internet Engineering Task Force (IETF) J. Schaad
Request for Comments: 8152 August Cellars
Category: Standards Track July 2017
ISSN: 2070-1721
Internet Engineering Task Force (IETF) J. Schaad
Request for Comments: 8152 August Cellars
Category: Standards Track July 2017
ISSN: 2070-1721
CBOR Object Signing and Encryption (COSE)
CBOR对象签名和加密（COSE）
Abstract
摘要
Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need for the ability to have basic security services defined for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR.
简明二进制对象表示（CBOR）是专为小代码和小消息大小设计的数据格式。需要能够为此数据格式定义基本安全服务。本文件定义了CBOR对象签名和加密（COSE）协议。本规范描述了如何使用CBOR创建和处理签名、消息身份验证代码和加密以进行序列化。本规范还描述了如何使用CBOR表示加密密钥。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8152.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8152.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Design Changes from JOSE ...................................5
1.2. Requirements Terminology ...................................6
1.3. CBOR Grammar ...............................................6
1.4. CBOR-Related Terminology ...................................7
1.5. Document Terminology .......................................8
2. Basic COSE Structure ............................................8
3. Header Parameters ..............................................10
3.1. Common COSE Headers Parameters ............................12
4. Signing Objects ................................................16
4.1. Signing with One or More Signers ..........................16
4.2. Signing with One Signer ...................................18
4.3. Externally Supplied Data ..................................19
4.4. Signing and Verification Process ..........................20
4.5. Computing Counter Signatures ..............................22
5. Encryption Objects .............................................22
5.1. Enveloped COSE Structure ..................................23
5.1.1. Content Key Distribution Methods ...................24
5.2. Single Recipient Encrypted ................................25
5.3. How to Encrypt and Decrypt for AEAD Algorithms ............26
5.4. How to Encrypt and Decrypt for AE Algorithms ..............28
6. MAC Objects ....................................................29
6.1. MACed Message with Recipients .............................30
6.2. MACed Messages with Implicit Key ..........................31
6.3. How to Compute and Verify a MAC ...........................32
7. Key Objects ....................................................33
7.1. COSE Key Common Parameters ................................34
8. Signature Algorithms ...........................................37
8.1. ECDSA .....................................................38
8.1.1. Security Considerations ............................40
8.2. Edwards-Curve Digital Signature Algorithms (EdDSAs) .......40
8.2.1. Security Considerations ............................41
9. Message Authentication Code (MAC) Algorithms ...................42
9.1. Hash-Based Message Authentication Codes (HMACs) ...........42
9.1.1. Security Considerations ............................44
9.2. AES Message Authentication Code (AES-CBC-MAC) .............44
9.2.1. Security Considerations ............................45
10. Content Encryption Algorithms .................................45
10.1. AES GCM ..................................................46
10.1.1. Security Considerations ...........................47
10.2. AES CCM ..................................................47
10.2.1. Security Considerations ...........................50
10.3. ChaCha20 and Poly1305 ....................................50
10.3.1. Security Considerations ...........................51
11. Key Derivation Functions (KDFs) ...............................51
1. Introduction ....................................................4
1.1. Design Changes from JOSE ...................................5
1.2. Requirements Terminology ...................................6
1.3. CBOR Grammar ...............................................6
1.4. CBOR-Related Terminology ...................................7
1.5. Document Terminology .......................................8
2. Basic COSE Structure ............................................8
3. Header Parameters ..............................................10
3.1. Common COSE Headers Parameters ............................12
4. Signing Objects ................................................16
4.1. Signing with One or More Signers ..........................16
4.2. Signing with One Signer ...................................18
4.3. Externally Supplied Data ..................................19
4.4. Signing and Verification Process ..........................20
4.5. Computing Counter Signatures ..............................22
5. Encryption Objects .............................................22
5.1. Enveloped COSE Structure ..................................23
5.1.1. Content Key Distribution Methods ...................24
5.2. Single Recipient Encrypted ................................25
5.3. How to Encrypt and Decrypt for AEAD Algorithms ............26
5.4. How to Encrypt and Decrypt for AE Algorithms ..............28
6. MAC Objects ....................................................29
6.1. MACed Message with Recipients .............................30
6.2. MACed Messages with Implicit Key ..........................31
6.3. How to Compute and Verify a MAC ...........................32
7. Key Objects ....................................................33
7.1. COSE Key Common Parameters ................................34
8. Signature Algorithms ...........................................37
8.1. ECDSA .....................................................38
8.1.1. Security Considerations ............................40
8.2. Edwards-Curve Digital Signature Algorithms (EdDSAs) .......40
8.2.1. Security Considerations ............................41
9. Message Authentication Code (MAC) Algorithms ...................42
9.1. Hash-Based Message Authentication Codes (HMACs) ...........42
9.1.1. Security Considerations ............................44
9.2. AES Message Authentication Code (AES-CBC-MAC) .............44
9.2.1. Security Considerations ............................45
10. Content Encryption Algorithms .................................45
10.1. AES GCM ..................................................46
10.1.1. Security Considerations ...........................47
10.2. AES CCM ..................................................47
10.2.1. Security Considerations ...........................50
10.3. ChaCha20 and Poly1305 ....................................50
10.3.1. Security Considerations ...........................51
11. Key Derivation Functions (KDFs) ...............................51
11.1. HMAC-Based Extract-and-Expand Key Derivation
Function (HKDF) ..........................................52
11.2. Context Information Structure ............................54
12. Content Key Distribution Methods ..............................60
12.1. Direct Encryption ........................................60
12.1.1. Direct Key ........................................61
12.1.2. Direct Key with KDF ...............................61
12.2. Key Wrap ................................................63
12.2.1. AES Key Wrap ......................................64
12.3. Key Transport ...........................................65
12.4. Direct Key Agreement ....................................65
12.4.1. ECDH ..............................................66
12.4.2. Security Considerations ...........................69
12.5. Key Agreement with Key Wrap ..............................69
12.5.1. ECDH ..............................................70
13. Key Object Parameters .........................................72
13.1. Elliptic Curve Keys ......................................73
13.1.1. Double Coordinate Curves ..........................73
13.2. Octet Key Pair ...........................................74
13.3. Symmetric Keys ...........................................75
14. CBOR Encoder Restrictions .....................................76
15. Application Profiling Considerations ..........................76
16. IANA Considerations ...........................................78
16.1. CBOR Tag Assignment ......................................78
16.2. COSE Header Parameters Registry ..........................78
16.3. COSE Header Algorithm Parameters Registry ................79
16.4. COSE Algorithms Registry .................................79
16.5. COSE Key Common Parameters Registry ......................81
16.6. COSE Key Type Parameters Registry ........................81
16.7. COSE Key Types Registry ..................................82
16.8. COSE Elliptic Curves Registry ............................83
16.9. Media Type Registrations .................................84
16.9.1. COSE Security Message .............................84
16.9.2. COSE Key Media Type ...............................85
16.10. CoAP Content-Formats Registry ...........................87
16.11. Expert Review Instructions ..............................87
17. Security Considerations .......................................88
18. References ....................................................90
18.1. Normative References .....................................90
18.2. Informative References ...................................92
Appendix A. Guidelines for External Data Authentication of
Algorithms ............................................96
A.1. Algorithm Identification ..................................96
A.2. Counter Signature without Headers .........................99
Appendix B. Two Layers of Recipient Information ..................100
Appendix C. Examples .............................................102
C.1. Examples of Signed Messages ..............................103
C.1.1. Single Signature ..................................103
11.1. HMAC-Based Extract-and-Expand Key Derivation
Function (HKDF) ..........................................52
11.2. Context Information Structure ............................54
12. Content Key Distribution Methods ..............................60
12.1. Direct Encryption ........................................60
12.1.1. Direct Key ........................................61
12.1.2. Direct Key with KDF ...............................61
12.2. Key Wrap ................................................63
12.2.1. AES Key Wrap ......................................64
12.3. Key Transport ...........................................65
12.4. Direct Key Agreement ....................................65
12.4.1. ECDH ..............................................66
12.4.2. Security Considerations ...........................69
12.5. Key Agreement with Key Wrap ..............................69
12.5.1. ECDH ..............................................70
13. Key Object Parameters .........................................72
13.1. Elliptic Curve Keys ......................................73
13.1.1. Double Coordinate Curves ..........................73
13.2. Octet Key Pair ...........................................74
13.3. Symmetric Keys ...........................................75
14. CBOR Encoder Restrictions .....................................76
15. Application Profiling Considerations ..........................76
16. IANA Considerations ...........................................78
16.1. CBOR Tag Assignment ......................................78
16.2. COSE Header Parameters Registry ..........................78
16.3. COSE Header Algorithm Parameters Registry ................79
16.4. COSE Algorithms Registry .................................79
16.5. COSE Key Common Parameters Registry ......................81
16.6. COSE Key Type Parameters Registry ........................81
16.7. COSE Key Types Registry ..................................82
16.8. COSE Elliptic Curves Registry ............................83
16.9. Media Type Registrations .................................84
16.9.1. COSE Security Message .............................84
16.9.2. COSE Key Media Type ...............................85
16.10. CoAP Content-Formats Registry ...........................87
16.11. Expert Review Instructions ..............................87
17. Security Considerations .......................................88
18. References ....................................................90
18.1. Normative References .....................................90
18.2. Informative References ...................................92
Appendix A. Guidelines for External Data Authentication of
Algorithms ............................................96
A.1. Algorithm Identification ..................................96
A.2. Counter Signature without Headers .........................99
Appendix B. Two Layers of Recipient Information ..................100
Appendix C. Examples .............................................102
C.1. Examples of Signed Messages ..............................103
C.1.1. Single Signature ..................................103
C.1.2. Multiple Signers ..................................103
C.1.3. Counter Signature .................................104
C.1.4. Signature with Criticality ........................105
C.2. Single Signer Examples ...................................106
C.2.1. Single ECDSA Signature ...........................106
C.3. Examples of Enveloped Messages ...........................107
C.3.1. Direct ECDH .......................................107
C.3.2. Direct Plus Key Derivation ........................108
C.3.3. Counter Signature on Encrypted Content ............109
C.3.4. Encrypted Content with External Data ..............111
C.4. Examples of Encrypted Messages ...........................111
C.4.1. Simple Encrypted Message ..........................111
C.4.2. Encrypted Message with a Partial IV ...............112
C.5. Examples of MACed Messages ...............................112
C.5.1. Shared Secret Direct MAC ..........................112
C.5.2. ECDH Direct MAC ...................................113
C.5.3. Wrapped MAC .......................................114
C.5.4. Multi-Recipient MACed Message .....................115
C.6. Examples of MAC0 Messages ................................117
C.6.1. Shared Secret Direct MAC ..........................117
C.7. COSE Keys ................................................117
C.7.1. Public Keys .......................................117
C.7.2. Private Keys ......................................119
Acknowledgments ..................................................121
Author's Address .................................................121
C.1.2. Multiple Signers ..................................103
C.1.3. Counter Signature .................................104
C.1.4. Signature with Criticality ........................105
C.2. Single Signer Examples ...................................106
C.2.1. Single ECDSA Signature ...........................106
C.3. Examples of Enveloped Messages ...........................107
C.3.1. Direct ECDH .......................................107
C.3.2. Direct Plus Key Derivation ........................108
C.3.3. Counter Signature on Encrypted Content ............109
C.3.4. Encrypted Content with External Data ..............111
C.4. Examples of Encrypted Messages ...........................111
C.4.1. Simple Encrypted Message ..........................111
C.4.2. Encrypted Message with a Partial IV ...............112
C.5. Examples of MACed Messages ...............................112
C.5.1. Shared Secret Direct MAC ..........................112
C.5.2. ECDH Direct MAC ...................................113
C.5.3. Wrapped MAC .......................................114
C.5.4. Multi-Recipient MACed Message .....................115
C.6. Examples of MAC0 Messages ................................117
C.6.1. Shared Secret Direct MAC ..........................117
C.7. COSE Keys ................................................117
C.7.1. Public Keys .......................................117
C.7.2. Private Keys ......................................119
Acknowledgments ..................................................121
Author's Address .................................................121
There has been an increased focus on small, constrained devices that make up the Internet of Things (IoT). One of the standards that has come out of this process is "Concise Binary Object Representation (CBOR)" [RFC7049]. CBOR extended the data model of the JavaScript Object Notation (JSON) [RFC7159] by allowing for binary data, among other changes. CBOR is being adopted by several of the IETF working groups dealing with the IoT world as their encoding of data structures. CBOR was designed specifically to be both small in terms of messages transport and implementation size and be a schema-free decoder. A need exists to provide message security services for IoT, and using CBOR as the message-encoding format makes sense.
人们越来越关注构成物联网（IoT）的小型受限设备。这个过程产生的标准之一是“简明二进制对象表示法（CBOR）”[RFC7049]。CBOR扩展了JavaScript对象表示法（JSON）[RFC7159]的数据模型，允许二进制数据和其他更改。若干IETF工作组正在采用CBOR作为数据结构编码，以处理物联网世界。CBOR是专门设计的，在消息传输和实现大小方面都很小，并且是一个无模式的解码器。需要为物联网提供消息安全服务，使用CBOR作为消息编码格式是有意义的。
The JOSE working group produced a set of documents [RFC7515] [RFC7516] [RFC7517] [RFC7518] using JSON that specified how to process encryption, signatures, and Message Authentication Code (MAC) operations and how to encode keys using JSON. This document defines the CBOR Object Signing and Encryption (COSE) standard, which does the same thing for the CBOR encoding format. While there is a strong
JOSE工作组使用JSON生成了一组文件[RFC7515][RFC7516][RFC7517][RFC7518]，其中规定了如何处理加密、签名和消息验证码（MAC）操作，以及如何使用JSON对密钥进行编码。本文档定义了CBOR对象签名和加密（COSE）标准，该标准对CBOR编码格式做了相同的事情。虽然有一个强大的
attempt to keep the flavor of the original JSON Object Signing and Encryption (JOSE) documents, two considerations are taken into account:
为了保持原始JSON对象签名和加密（JOSE）文档的风格，需要考虑两个因素：
o CBOR has capabilities that are not present in JSON and are appropriate to use. One example of this is the fact that CBOR has a method of encoding binary directly without first converting it into a base64-encoded string.
o CBOR具有JSON中没有的功能，适合使用。这方面的一个例子是，CBOR有一种直接编码二进制的方法，而无需首先将其转换为base64编码字符串。
o COSE is not a direct copy of the JOSE specification. In the process of creating COSE, decisions that were made for JOSE were re-examined. In many cases, different results were decided on as the criteria were not always the same.
o COSE不是JOSE规范的直接副本。在创建COSE的过程中，重新审查了为JOSE做出的决策。在许多情况下，由于标准并不总是相同，因此决定了不同的结果。
o Define a single top message structure so that encrypted, signed, and MACed messages can easily be identified and still have a consistent view.
o 定义单个顶部消息结构，以便可以轻松识别加密、签名和标记的消息，并且仍然具有一致的视图。
o Signed messages distinguish between the protected and unprotected parameters that relate to the content from those that relate to the signature.
o 签名消息区分与内容相关的受保护参数和未受保护参数与与签名相关的参数。
o MACed messages are separated from signed messages.
o MACE消息与签名消息分开。
o MACed messages have the ability to use the same set of recipient algorithms as enveloped messages for obtaining the MAC authentication key.
o MACE消息能够使用与信封消息相同的一组收件人算法来获取MAC身份验证密钥。
o Use binary encodings for binary data rather than base64url encodings.
o 对二进制数据使用二进制编码，而不是base64url编码。
o Combine the authentication tag for encryption algorithms with the ciphertext.
o 将加密算法的身份验证标签与密文结合起来。
o The set of cryptographic algorithms has been expanded in some directions and trimmed in others.
o 密码算法集在某些方向上进行了扩展，在其他方向上进行了裁剪。
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]所述进行解释。
When the words appear in lowercase, this interpretation does not apply.
当文字以小写形式出现时，此解释不适用。
There is currently no standard CBOR grammar available for use by specifications. The CBOR structures are therefore described in prose.
目前没有标准的CBOR语法可供规范使用。因此，以散文形式描述CBOR结构。
The document was developed by first working on the grammar and then developing the prose to go with it. An artifact of this is that the prose was written using the primitive type strings defined by CBOR Data Definition Language (CDDL) [CDDL]. In this specification, the following primitive types are used:
该文件是通过首先研究语法，然后发展散文来完成的。这其中的一个缺陷是，散文是使用CBOR数据定义语言（CDDL）[CDDL]定义的原语类型字符串编写的。在本规范中，使用了以下基本类型：
any -- non-specific value that permits all CBOR values to be placed here.
any——允许将所有CBOR值置于此处的非特定值。
bool -- a boolean value (true: major type 7, value 21; false: major type 7, value 20).
bool——一个布尔值（true：主类型7，值21；false：主类型7，值20）。
bstr -- byte string (major type 2).
bstr—字节字符串（主要类型2）。
int -- an unsigned integer or a negative integer.
int—无符号整数或负整数。
nil -- a null value (major type 7, value 22).
nil——一个空值（主类型7，值22）。
nint -- a negative integer (major type 1).
nint——一个负整数（主要类型1）。
tstr -- a UTF-8 text string (major type 3).
tstr——一个UTF-8文本字符串（主要类型3）。
uint -- an unsigned integer (major type 0).
uint—无符号整数（主类型0）。
Two syntaxes from CDDL appear in this document as shorthand. These are:
CDDL中的两个语法作为速记出现在本文档中。这些是：
FOO / BAR -- indicates that either FOO or BAR can appear here.
FOO/BAR——表示可以在此处显示FOO或BAR。
[+ FOO] -- indicates that the type FOO appears one or more times in an array.
[+FOO]--表示FOO类型在数组中出现一次或多次。
As well as the prose description, a version of a CBOR grammar is presented in CDDL. Since CDDL has not been published in an RFC, this grammar may not work with the final version of CDDL. The CDDL grammar is informational; the prose description is normative.
除了散文描述外，CDDL还提供了CBOR语法的一个版本。由于CDDL尚未在RFC中发布，因此此语法可能无法用于CDDL的最终版本。CDDL语法是信息性的；散文描写规范。
The collected CDDL can be extracted from the XML version of this document via the following XPath expression below. (Depending on the XPath evaluator one is using, it may be necessary to deal with > as an entity.)
收集的CDDL可以通过下面的XPath表达式从本文档的XML版本中提取。（根据使用的XPath计算器，可能需要将>；作为一个实体处理。）
//artwork[@type='CDDL']/text()
//artwork[@type='CDDL']/text()
CDDL expects the initial non-terminal symbol to be the first symbol in the file. For this reason, the first fragment of CDDL is presented here.
CDDL希望初始非终端符号是文件中的第一个符号。因此，这里介绍了CDDL的第一个片段。
start = COSE_Messages / COSE_Key / COSE_KeySet / Internal_Types
start = COSE_Messages / COSE_Key / COSE_KeySet / Internal_Types
; This is defined to make the tool quieter:
Internal_Types = Sig_structure / Enc_structure / MAC_structure /
COSE_KDF_Context
; This is defined to make the tool quieter:
Internal_Types = Sig_structure / Enc_structure / MAC_structure /
COSE_KDF_Context
The non-terminal Internal_Types is defined for dealing with the automated validation tools used during the writing of this document. It references those non-terminals that are used for security computations but are not emitted for transport.
非终端内部_类型定义用于处理本文档编写过程中使用的自动验证工具。它引用那些用于安全计算但不用于传输的非终端。
In JSON, maps are called objects and only have one kind of map key: a string. In COSE, we use strings, negative integers, and unsigned integers as map keys. The integers are used for compactness of encoding and easy comparison. The inclusion of strings allows for an additional range of short encoded values to be used as well. Since the word "key" is mainly used in its other meaning, as a cryptographic key, we use the term "label" for this usage as a map key.
在JSON中，映射称为对象，并且只有一种映射键：字符串。在COSE中，我们使用字符串、负整数和无符号整数作为映射键。整数用于压缩编码和易于比较。字符串的包含也允许使用额外范围的短编码值。由于单词“key”主要用于其其他含义，因此作为加密密钥，我们使用术语“label”作为映射密钥。
The presence of a label in a COSE map that is not a string or an integer is an error. Applications can either fail processing or process messages with incorrect labels; however, they MUST NOT create messages with incorrect labels.
COSE映射中存在不是字符串或整数的标签是错误的。应用程序可能无法处理或处理标签不正确的消息；但是，他们不得创建标签不正确的邮件。
A CDDL grammar fragment defines the non-terminal 'label', as in the previous paragraph, and 'values', which permits any value to be used.
CDDL语法片段定义了非终端“label”（如前一段所述）和“values”（允许使用任何值）。
label = int / tstr values = any
label=int/tstr值=any
In this document, we use the following terminology:
在本文件中，我们使用以下术语：
Byte is a synonym for octet.
字节是八位字节的同义词。
Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use in constrained systems. It is defined in [RFC7252].
受限应用程序协议（CoAP）是一种专门用于受限系统的web传输协议。它在[RFC7252]中定义。
Authenticated Encryption (AE) [RFC5116] algorithms are those encryption algorithms that provide an authentication check of the contents algorithm with the encryption service.
认证加密（AE）[RFC5116]算法是通过加密服务对内容算法进行认证检查的加密算法。
Authenticated Encryption with Authenticated Data (AEAD) [RFC5116] algorithms provide the same content authentication service as AE algorithms, but they additionally provide for authentication of non-encrypted data as well.
使用已验证数据的已验证加密（AEAD）[RFC5116]算法提供与AE算法相同的内容验证服务，但它们还提供非加密数据的验证。
The COSE object structure is designed so that there can be a large amount of common code when parsing and processing the different types of security messages. All of the message structures are built on the CBOR array type. The first three elements of the array always contain the same information:
COSE对象结构的设计使得在解析和处理不同类型的安全消息时可以有大量的通用代码。所有消息结构都构建在CBOR数组类型上。数组的前三个元素始终包含相同的信息：
1. The set of protected header parameters wrapped in a bstr.
1. 包装在bstr中的受保护标头参数集。
2. The set of unprotected header parameters as a map.
2. 作为映射的未受保护的标头参数集。
3. The content of the message. The content is either the plaintext or the ciphertext as appropriate. The content may be detached, but the location is still used. The content is wrapped in a bstr when present and is a nil value when detached.
3. 消息的内容。内容可以是明文，也可以是密文（视情况而定）。可以分离内容，但仍然使用该位置。内容存在时包装在bstr中，分离时为零值。
Elements after this point are dependent on the specific message type.
此点之后的元素取决于特定的消息类型。
COSE messages are also built using the concept of layers to separate different types of cryptographic concepts. As an example of how this works, consider the COSE_Encrypt message (Section 5.1). This message type is broken into two layers: the content layer and the recipient layer. In the content layer, the plaintext is encrypted and information about the encrypted message is placed. In the recipient layer, the content encryption key (CEK) is encrypted and information about how it is encrypted for each recipient is placed. A single layer version of the encryption message COSE_Encrypt0 (Section 5.2) is provided for cases where the CEK is pre-shared.
COSE消息还使用层的概念来划分不同类型的加密概念。作为这种工作方式的一个例子，考虑COSeYEngRebug消息（第5.1节）。此消息类型分为两层：内容层和收件人层。在内容层，对明文进行加密，并放置有关加密消息的信息。在接收者层，内容加密密钥（CEK）被加密，并且关于如何为每个接收者加密的信息被放置。对于预共享CEK的情况，提供了单层版本的加密消息COSE_Encrypt0（第5.2节）。
Identification of which type of message has been presented is done by the following methods:
通过以下方法识别已呈现的消息类型：
1. The specific message type is known from the context. This may be defined by a marker in the containing structure or by restrictions specified by the application protocol.
1. 从上下文中可以知道特定的消息类型。这可以通过包含结构中的标记或应用协议指定的限制来定义。
2. The message type is identified by a CBOR tag. Messages with a CBOR tag are known in this specification as tagged messages, while those without the CBOR tag are known as untagged messages. This document defines a CBOR tag for each of the message structures. These tags can be found in Table 1.
2. 消息类型由CBOR标记标识。在本规范中，带有CBOR标记的消息称为标记消息，而没有CBOR标记的消息称为未标记消息。本文档为每个消息结构定义了一个CBOR标记。这些标签可以在表1中找到。
3. When a COSE object is carried in a media type of 'application/ cose', the optional parameter 'cose-type' can be used to identify the embedded object. The parameter is OPTIONAL if the tagged version of the structure is used. The parameter is REQUIRED if the untagged version of the structure is used. The value to use with the parameter for each of the structures can be found in Table 1.
3. 当在“应用程序/COSE”媒体类型中携带COSE对象时，可选参数“COSE类型”可用于标识嵌入对象。如果使用结构的标记版本，则该参数是可选的。如果使用结构的未标记版本，则该参数是必需的。与每个结构的参数一起使用的值可以在表1中找到。
4. When a COSE object is carried as a CoAP payload, the CoAP Content-Format Option can be used to identify the message content. The CoAP Content-Format values can be found in Table 26. The CBOR tag for the message structure is not required as each security message is uniquely identified.
4. 当COSE对象作为CoAP有效载荷携带时，CoAP内容格式选项可用于识别消息内容。CoAP内容格式值见表26。消息结构不需要CBOR标记，因为每个安全消息都是唯一标识的。
+-------+---------------+---------------+---------------------------+
| CBOR | cose-type | Data Item | Semantics |
| Tag | | | |
+-------+---------------+---------------+---------------------------+
| 98 | cose-sign | COSE_Sign | COSE Signed Data Object |
| 18 | cose-sign1 | COSE_Sign1 | COSE Single Signer Data |
| | | | Object |
| 96 | cose-encrypt | COSE_Encrypt | COSE Encrypted Data |
| | | | Object |
| 16 | cose-encrypt0 | COSE_Encrypt0 | COSE Single Recipient |
| | | | Encrypted Data Object |
| 97 | cose-mac | COSE_Mac | COSE MACed Data Object |
| 17 | cose-mac0 | COSE_Mac0 | COSE Mac w/o Recipients |
| | | | Object |
+-------+---------------+---------------+---------------------------+
+-------+---------------+---------------+---------------------------+
| CBOR | cose-type | Data Item | Semantics |
| Tag | | | |
+-------+---------------+---------------+---------------------------+
| 98 | cose-sign | COSE_Sign | COSE Signed Data Object |
| 18 | cose-sign1 | COSE_Sign1 | COSE Single Signer Data |
| | | | Object |
| 96 | cose-encrypt | COSE_Encrypt | COSE Encrypted Data |
| | | | Object |
| 16 | cose-encrypt0 | COSE_Encrypt0 | COSE Single Recipient |
| | | | Encrypted Data Object |
| 97 | cose-mac | COSE_Mac | COSE MACed Data Object |
| 17 | cose-mac0 | COSE_Mac0 | COSE Mac w/o Recipients |
| | | | Object |
+-------+---------------+---------------+---------------------------+
Table 1: COSE Message Identification
表1:COSE消息标识
The following CDDL fragment identifies all of the top messages defined in this document. Separate non-terminals are defined for the tagged and the untagged versions of the messages.
下面的CDDL片段标识了本文档中定义的所有顶级消息。为标记和未标记版本的消息定义了单独的非终端。
COSE_Messages = COSE_Untagged_Message / COSE_Tagged_Message
COSE_消息=COSE_未标记消息/COSE_标记消息
COSE_Untagged_Message = COSE_Sign / COSE_Sign1 /
COSE_Encrypt / COSE_Encrypt0 /
COSE_Mac / COSE_Mac0
COSE_Untagged_Message = COSE_Sign / COSE_Sign1 /
COSE_Encrypt / COSE_Encrypt0 /
COSE_Mac / COSE_Mac0
COSE_Tagged_Message = COSE_Sign_Tagged / COSE_Sign1_Tagged /
COSE_Encrypt_Tagged / COSE_Encrypt0_Tagged /
COSE_Mac_Tagged / COSE_Mac0_Tagged
COSE_Tagged_Message = COSE_Sign_Tagged / COSE_Sign1_Tagged /
COSE_Encrypt_Tagged / COSE_Encrypt0_Tagged /
COSE_Mac_Tagged / COSE_Mac0_Tagged
The structure of COSE has been designed to have two buckets of information that are not considered to be part of the payload itself, but are used for holding information about content, algorithms, keys, or evaluation hints for the processing of the layer. These two buckets are available for use in all of the structures except for keys. While these buckets are present, they may not all be usable in all instances. For example, while the protected bucket is defined as part of the recipient structure, some of the algorithms used for recipient structures do not provide for authenticated data. If this is the case, the protected bucket is left empty.
COSE的结构被设计为具有两个信息桶，这些信息桶不被视为有效载荷本身的一部分，而是用于保存有关内容、算法、密钥或层处理的评估提示的信息。这两个铲斗可用于除钥匙以外的所有结构。虽然存在这些存储桶，但它们可能并非在所有情况下都可用。例如，虽然受保护的bucket被定义为接收方结构的一部分，但用于接收方结构的一些算法不提供经过身份验证的数据。如果是这种情况，则受保护的存储桶为空。
Both buckets are implemented as CBOR maps. The map key is a 'label' (Section 1.4). The value portion is dependent on the definition for the label. Both maps use the same set of label/value pairs. The integer and string values for labels have been divided into several sections including a standard range, a private range, and a range that is dependent on the algorithm selected. The defined labels can be found in the "COSE Header Parameters" IANA registry (Section 16.2).
这两个bucket都实现为CBOR映射。映射键是一个“标签”（第1.4节）。值部分取决于标签的定义。两个贴图使用同一组标签/值对。标签的整数值和字符串值分为几个部分，包括标准范围、专用范围和取决于所选算法的范围。定义的标签可在IANA注册表的“COSE头参数”中找到（第16.2节）。
Two buckets are provided for each layer:
每层提供两个铲斗：
protected: Contains parameters about the current layer that are to be cryptographically protected. This bucket MUST be empty if it is not going to be included in a cryptographic computation. This bucket is encoded in the message as a binary object. This value is obtained by CBOR encoding the protected map and wrapping it in a bstr object. Senders SHOULD encode a zero-length map as a zero-length string rather than as a zero-length map (encoded as h'a0'). The zero-length binary encoding is preferred because it is both shorter and the version used in the serialization structures for cryptographic computation. After encoding the map, the value is
受保护：包含有关当前层的参数，该层将受到加密保护。如果此存储桶不包含在加密计算中，则它必须为空。该bucket在消息中作为二进制对象进行编码。该值是通过CBOR编码受保护映射并将其包装到bstr对象中获得的。发送方应将零长度映射编码为零长度字符串，而不是零长度映射（编码为h'a0'）。首选零长度二进制编码，因为它较短，并且是用于加密计算的序列化结构中使用的版本。对映射进行编码后，值为
wrapped in the binary object. Recipients MUST accept both a zero-length binary value and a zero-length map encoded in the binary value. The wrapping allows for the encoding of the protected map to be transported with a greater chance that it will not be altered in transit. (Badly behaved intermediates could decode and re-encode, but this will result in a failure to verify unless the re-encoded byte string is identical to the decoded byte string.) This avoids the problem of all parties needing to be able to do a common canonical encoding.
包装在二进制对象中。收件人必须同时接受零长度二进制值和二进制值中编码的零长度映射。包装使受保护地图的编码在运输过程中不被更改的可能性更大。（行为不良的中间产物可能会解码和重新编码，但这将导致验证失败，除非重新编码的字节字符串与解码的字节字符串相同。）这避免了各方需要能够进行通用规范编码的问题。
unprotected: Contains parameters about the current layer that are not cryptographically protected.
未受保护：包含有关当前层的参数，这些参数不受加密保护。
Only parameters that deal with the current layer are to be placed at that layer. As an example of this, the parameter 'content type' describes the content of the message being carried in the message. As such, this parameter is placed only in the content layer and is not placed in the recipient or signature layers. In principle, one should be able to process any given layer without reference to any other layer. With the exception of the COSE_Sign structure, the only data that needs to cross layers is the cryptographic key.
只有处理当前图层的参数才能放置在该图层上。例如，参数“content type”描述了消息中承载的消息的内容。因此，此参数仅放置在内容层中，而不放置在收件人层或签名层中。原则上，应能在不参考任何其他层的情况下处理任何给定层。除了COSE_符号结构之外，唯一需要跨层的数据是加密密钥。
The buckets are present in all of the security objects defined in this document. The fields in order are the 'protected' bucket (as a CBOR 'bstr' type) and then the 'unprotected' bucket (as a CBOR 'map' type). The presence of both buckets is required. The parameters that go into the buckets come from the IANA "COSE Header Parameters" registry (Section 16.2). Some common parameters are defined in the next section, but a number of parameters are defined throughout this document.
这些存储桶存在于本文档中定义的所有安全对象中。按顺序排列的字段是“受保护”存储桶（作为CBOR“bstr”类型），然后是“未受保护”存储桶（作为CBOR“映射”类型）。两个铲斗都必须存在。进入存储桶的参数来自IANA“COSE头参数”注册表（第16.2节）。下一节将定义一些常见参数，但本文档中定义了许多参数。
Labels in each of the maps MUST be unique. When processing messages, if a label appears multiple times, the message MUST be rejected as malformed. Applications SHOULD verify that the same label does not occur in both the protected and unprotected headers. If the message is not rejected as malformed, attributes MUST be obtained from the protected bucket before they are obtained from the unprotected bucket.
每个地图中的标签必须是唯一的。处理邮件时，如果标签多次出现，则必须将邮件视为格式错误而拒绝。应用程序应验证在受保护和未受保护的标头中没有出现相同的标签。如果消息未因格式错误而被拒绝，则必须先从受保护的bucket中获取属性，然后才能从未受保护的bucket中获取属性。
The following CDDL fragment represents the two header buckets. A group "Headers" is defined in CDDL that represents the two buckets in which attributes are placed. This group is used to provide these two fields consistently in all locations. A type is also defined that represents the map of common headers.
下面的CDDL片段表示两个标头存储桶。CDDL中定义了一个组“Headers”，它表示放置属性的两个bucket。该组用于在所有位置一致地提供这两个字段。还定义了一个表示公共头映射的类型。
Headers = (
protected : empty_or_serialized_map,
unprotected : header_map
)
Headers = (
protected : empty_or_serialized_map,
unprotected : header_map
)
header_map = {
Generic_Headers,
* label => values
}
header_map = {
Generic_Headers,
* label => values
}
empty_or_serialized_map = bstr .cbor header_map / bstr .size 0
空的或序列化的\u映射=bstr.cbor头\u映射/bstr.size 0
This section defines a set of common header parameters. A summary of these parameters can be found in Table 2. This table should be consulted to determine the value of label and the type of the value.
本节定义了一组通用标题参数。这些参数的汇总见表2。应参考此表确定标签的值和值的类型。
The set of header parameters defined in this section are:
本节中定义的标题参数集为：
alg: This parameter is used to indicate the algorithm used for the security processing. This parameter MUST be authenticated where the ability to do so exists. This support is provided by AEAD algorithms or construction (COSE_Sign, COSE_Sign0, COSE_Mac, and COSE_Mac0). This authentication can be done either by placing the header in the protected header bucket or as part of the externally supplied data. The value is taken from the "COSE Algorithms" registry (see Section 16.4).
alg：此参数用于指示用于安全处理的算法。如果存在验证此参数的能力，则必须验证此参数。这种支持由AEAD算法或构造（COSE_符号、COSE_符号0、COSE_Mac和COSE_Mac0）提供。此身份验证可以通过将头放在受保护的头存储桶中或作为外部提供的数据的一部分来完成。该值取自“COSE算法”注册表（见第16.4节）。
crit: The parameter is used to indicate which protected header labels an application that is processing a message is required to understand. Parameters defined in this document do not need to be included as they should be understood by all implementations. When present, this parameter MUST be placed in the protected header bucket. The array MUST have at least one value in it. Not all labels need to be included in the 'crit' parameter. The rules for deciding which header labels are placed in the array are:
crit：该参数用于指示处理消息的应用程序需要理解哪些受保护的头标签。本文档中定义的参数不需要包括在内，因为所有实现都应该理解这些参数。存在时，此参数必须置于受保护的收割台铲斗中。数组中必须至少有一个值。并非所有标签都需要包含在“crit”参数中。决定在数组中放置哪些标题标签的规则如下：
* Integer labels in the range of 0 to 8 SHOULD be omitted.
* 应省略0到8范围内的整数标签。
* Integer labels in the range -1 to -128 can be omitted as they are algorithm dependent. If an application can correctly process an algorithm, it can be assumed that it will correctly process all of the common parameters associated with that algorithm. Integer labels in the range -129 to -65536 SHOULD be included as these would be less common parameters that might not be generally supported.
* 范围为-1到-128的整数标签可以省略，因为它们依赖于算法。如果应用程序能够正确处理算法，则可以假定它将正确处理与该算法相关联的所有公共参数。应包括-129到-65536范围内的整数标签，因为这些参数不太常见，通常不受支持。
* Labels for parameters required for an application MAY be omitted. Applications should have a statement if the label can be omitted.
* 应用程序所需参数的标签可以省略。如果可以省略标签，应用程序应该有一个语句。
The header parameter values indicated by 'crit' can be processed by either the security library code or an application using a security library; the only requirement is that the parameter is processed. If the 'crit' value list includes a value for which the parameter is not in the protected bucket, this is a fatal error in processing the message.
“crit”指示的标题参数值可由安全库代码或使用安全库的应用程序处理；唯一的要求是处理参数。如果“crit”值列表包含参数不在受保护存储桶中的值，则这是处理消息时的致命错误。
content type: This parameter is used to indicate the content type of the data in the payload or ciphertext fields. Integers are from the "CoAP Content-Formats" IANA registry table [COAP.Formats]. Text values following the syntax of "<type-name>/<subtype-name>" where <type-name> and <subtype-name> are defined in Section 4.2 of [RFC6838]. Leading and trailing whitespace is also omitted. Textual content values along with parameters and subparameters can be located using the IANA "Media Types" registry. Applications SHOULD provide this parameter if the content structure is potentially ambiguous.
内容类型：此参数用于指示有效负载或密文字段中数据的内容类型。整数来自“CoAP内容格式”IANA注册表[CoAP.Formats]。[RFC6838]第4.2节定义了“<type name>/<subtype name>”语法后面的文本值，其中<type name>和<subtype name>。前导和尾随空格也被省略。文本内容值以及参数和子参数可以使用IANA“媒体类型”注册表进行定位。如果内容结构可能不明确，应用程序应提供此参数。
kid: This parameter identifies one piece of data that can be used as input to find the needed cryptographic key. The value of this parameter can be matched against the 'kid' member in a COSE_Key structure. Other methods of key distribution can define an equivalent field to be matched. Applications MUST NOT assume that 'kid' values are unique. There may be more than one key with the same 'kid' value, so all of the keys associated with this 'kid' may need to be checked. The internal structure of 'kid' values is not defined and cannot be relied on by applications. Key identifier values are hints about which key to use. This is not a security-critical field. For this reason, it can be placed in the unprotected headers bucket.
kid：该参数标识一段数据，该数据可用作查找所需加密密钥的输入。此参数的值可以与COSE_密钥结构中的“kid”成员匹配。其他密钥分配方法可以定义要匹配的等效字段。应用程序不得假定“kid”值是唯一的。可能有多个键具有相同的“kid”值，因此可能需要检查与此“kid”关联的所有键。“kid”值的内部结构未定义，应用程序无法依赖它。键标识符值是关于使用哪个键的提示。这不是一个安全关键字段。因此，可以将其放置在未受保护的headers bucket中。
IV: This parameter holds the Initialization Vector (IV) value. For some symmetric encryption algorithms, this may be referred to as a nonce. The IV can be placed in the unprotected header as modifying the IV will cause the decryption to yield plaintext that is readily detectable as garbled.
IV：此参数保存初始化向量（IV）值。对于某些对称加密算法，这可以称为nonce。IV可以放在未受保护的报头中，因为修改IV将导致解密产生易于检测为乱码的明文。
Partial IV: This parameter holds a part of the IV value. When using the COSE_Encrypt0 structure, a portion of the IV can be part of the context associated with the key. This field is used to carry a value that causes the IV to be changed for each message. The IV can be placed in the unprotected header as modifying the IV will cause the decryption to yield plaintext that is readily detectable as garbled. The 'Initialization Vector' and 'Partial Initialization Vector' parameters MUST NOT both be present in the same security layer.
Partial IV：此参数包含IV值的一部分。使用COSE_Encrypt0结构时，IV的一部分可以是与密钥关联的上下文的一部分。此字段用于携带一个值，该值会导致更改每条消息的IV。IV可以放在未受保护的报头中，因为修改IV将导致解密产生易于检测为乱码的明文。“初始化向量”和“部分初始化向量”参数不能同时出现在同一安全层中。
The message IV is generated by the following steps:
信息IV由以下步骤生成：
1. Left-pad the Partial IV with zeros to the length of IV.
1. 将部分IV用零填充到IV的长度。
2. XOR the padded Partial IV with the context IV.
2. 将填充的部分IV与上下文IV异或。
counter signature: This parameter holds one or more counter signature values. Counter signatures provide a method of having a second party sign some data. The counter signature parameter can occur as an unprotected attribute in any of the following structures: COSE_Sign1, COSE_Signature, COSE_Encrypt, COSE_recipient, COSE_Encrypt0, COSE_Mac, and COSE_Mac0. These structures all have the same beginning elements, so that a consistent calculation of the counter signature can be computed. Details on computing counter signatures are found in Section 4.5.
计数器签名：此参数包含一个或多个计数器签名值。反签名提供了一种让第二方对某些数据进行签名的方法。计数器签名参数可以作为未受保护的属性出现在以下任意结构中：COSE_Sign1、COSE_签名、COSE_Encrypt、COSE_recipient、COSE_Encrypt0、COSE_Mac和COSE_Mac0。这些结构都具有相同的起始元素，因此可以计算一致的反签名计算。有关计算反签名的详细信息，请参见第4.5节。
+-----------+-------+----------------+-------------+----------------+
| Name | Label | Value Type | Value | Description |
| | | | Registry | |
+-----------+-------+----------------+-------------+----------------+
| alg | 1 | int / tstr | COSE | Cryptographic |
| | | | Algorithms | algorithm to |
| | | | registry | use |
| crit | 2 | [+ label] | COSE Header | Critical |
| | | | Parameters | headers to be |
| | | | registry | understood |
| content | 3 | tstr / uint | CoAP | Content type |
| type | | | Content- | of the payload |
| | | | Formats or | |
| | | | Media Types | |
| | | | registries | |
| kid | 4 | bstr | | Key identifier |
| IV | 5 | bstr | | Full |
| | | | | Initialization |
| | | | | Vector |
| Partial | 6 | bstr | | Partial |
| IV | | | | Initialization |
| | | | | Vector |
| counter | 7 | COSE_Signature | | CBOR-encoded |
| signature | | / [+ | | signature |
| | | COSE_Signature | | structure |
| | | ] | | |
+-----------+-------+----------------+-------------+----------------+
+-----------+-------+----------------+-------------+----------------+
| Name | Label | Value Type | Value | Description |
| | | | Registry | |
+-----------+-------+----------------+-------------+----------------+
| alg | 1 | int / tstr | COSE | Cryptographic |
| | | | Algorithms | algorithm to |
| | | | registry | use |
| crit | 2 | [+ label] | COSE Header | Critical |
| | | | Parameters | headers to be |
| | | | registry | understood |
| content | 3 | tstr / uint | CoAP | Content type |
| type | | | Content- | of the payload |
| | | | Formats or | |
| | | | Media Types | |
| | | | registries | |
| kid | 4 | bstr | | Key identifier |
| IV | 5 | bstr | | Full |
| | | | | Initialization |
| | | | | Vector |
| Partial | 6 | bstr | | Partial |
| IV | | | | Initialization |
| | | | | Vector |
| counter | 7 | COSE_Signature | | CBOR-encoded |
| signature | | / [+ | | signature |
| | | COSE_Signature | | structure |
| | | ] | | |
+-----------+-------+----------------+-------------+----------------+
Table 2: Common Header Parameters
表2：通用标题参数
The CDDL fragment that represents the set of headers defined in this section is given below. Each of the headers is tagged as optional because they do not need to be in every map; headers required in specific maps are discussed above.
下面给出了表示本节中定义的头集的CDDL片段。每个标题都被标记为可选，因为它们不需要出现在每个地图中；上面讨论了特定映射中所需的标题。
Generic_Headers = (
? 1 => int / tstr, ; algorithm identifier
? 2 => [+label], ; criticality
? 3 => tstr / int, ; content type
? 4 => bstr, ; key identifier
? 5 => bstr, ; IV
? 6 => bstr, ; Partial IV
? 7 => COSE_Signature / [+COSE_Signature] ; Counter signature
)
Generic_Headers = (
? 1 => int / tstr, ; algorithm identifier
? 2 => [+label], ; criticality
? 3 => tstr / int, ; content type
? 4 => bstr, ; key identifier
? 5 => bstr, ; IV
? 6 => bstr, ; Partial IV
? 7 => COSE_Signature / [+COSE_Signature] ; Counter signature
)
COSE supports two different signature structures. COSE_Sign allows for one or more signatures to be applied to the same content. COSE_Sign1 is restricted to a single signer. The structures cannot be converted between each other; as the signature computation includes a parameter identifying which structure is being used, the converted structure will fail signature validation.
COSE支持两种不同的签名结构。COSE_Sign允许对同一内容应用一个或多个签名。COSE_Sign1仅限于一个签名者。结构之间不能相互转换；由于签名计算包括标识正在使用的结构的参数，因此转换后的结构将无法通过签名验证。
The COSE_Sign structure allows for one or more signatures to be applied to a message payload. Parameters relating to the content and parameters relating to the signature are carried along with the signature itself. These parameters may be authenticated by the signature, or just present. An example of a parameter about the content is the content type. Examples of parameters about the signature would be the algorithm and key used to create the signature and counter signatures.
COSE_签名结构允许将一个或多个签名应用于消息负载。与内容相关的参数和与签名相关的参数与签名本身一起携带。这些参数可以通过签名进行身份验证，也可以只是存在。内容类型是有关内容的参数的一个示例。关于签名的参数示例包括用于创建签名和反签名的算法和密钥。
RFC 5652 indicates that:
RFC 5652表明：
When more than one signature is present, the successful validation of one signature associated with a given signer is usually treated as a successful signature by that signer. However, there are some application environments where other rules are needed. An application that employs a rule other than one valid signature for each signer must specify those rules. Also, where simple matching of the signer identifier is not sufficient to determine whether the signatures were generated by the same signer, the application specification must describe how to determine which signatures were generated by the same signer. Support for different communities of recipients is the primary reason that signers choose to include more than one signature.
当存在多个签名时，与给定签名人关联的一个签名的成功验证通常被该签名人视为成功签名。但是，有些应用程序环境需要其他规则。对每个签名者使用一个有效签名以外的规则的应用程序必须指定这些规则。此外，如果签名者标识符的简单匹配不足以确定签名是否由同一签名者生成，则应用程序规范必须描述如何确定哪些签名由同一签名者生成。支持不同的收件人社区是签名者选择包含多个签名的主要原因。
For example, the COSE_Sign structure might include signatures generated with the Edwards-curve Digital Signature Algorithm (EdDSA) [RFC8032] and with the Elliptic Curve Digital Signature Algorithm (ECDSA) [DSS]. This allows recipients to verify the signature associated with one algorithm or the other. More-detailed information on multiple signature evaluations can be found in [RFC5752].
例如，COSE_签名结构可能包括用爱德华兹曲线数字签名算法（EdDSA）[RFC8032]和椭圆曲线数字签名算法（ECDSA）[DSS]生成的签名。这允许收件人验证与一种算法或另一种算法关联的签名。有关多个签名评估的更多详细信息，请参见[RFC5752]。
The signature structure can be encoded as either tagged or untagged depending on the context it will be used in. A tagged COSE_Sign structure is identified by the CBOR tag 98. The CDDL fragment that represents this is:
签名结构可以被编码为标记的或未标记的，这取决于它将在其中使用的上下文。标记的COSE_符号结构由CBOR标记98标识。代表这一点的CDDL片段是：
COSE_Sign_Tagged = #6.98(COSE_Sign)
COSE_Sign_Tagged = #6.98(COSE_Sign)
A COSE Signed Message is defined in two parts. The CBOR object that carries the body and information about the body is called the COSE_Sign structure. The CBOR object that carries the signature and information about the signature is called the COSE_Signature structure. Examples of COSE Signed Messages can be found in Appendix C.1.
COSE签名消息由两部分定义。承载身体和身体信息的CBOR对象称为COSE_符号结构。承载签名和签名相关信息的CBOR对象称为COSE_签名结构。COSE签署的消息示例见附录C.1。
The COSE_Sign structure is a CBOR array. The fields of the array in order are:
COSE_符号结构是CBOR数组。按顺序排列的数组字段包括：
protected: This is as described in Section 3.
受保护：如第3节所述。
unprotected: This is as described in Section 3.
无保护：如第3节所述。
payload: This field contains the serialized content to be signed. If the payload is not present in the message, the application is required to supply the payload separately. The payload is wrapped in a bstr to ensure that it is transported without changes. If the payload is transported separately ("detached content"), then a nil CBOR object is placed in this location, and it is the responsibility of the application to ensure that it will be transported without changes.
有效负载：此字段包含要签名的序列化内容。如果消息中不存在有效负载，则要求应用程序单独提供有效负载。有效负载被包装在bstr中，以确保其在传输时不会发生更改。如果有效载荷单独运输（“分离内容”），则在该位置放置一个nil CBOR对象，应用程序有责任确保其在运输时不会发生变化。
Note: When a signature with a message recovery algorithm is used (Section 8), the maximum number of bytes that can be recovered is the length of the payload. The size of the payload is reduced by the number of bytes that will be recovered. If all of the bytes of the payload are consumed, then the payload is encoded as a zero-length binary string rather than as being absent.
注意：当使用带有消息恢复算法的签名时（第8节），可以恢复的最大字节数是有效负载的长度。有效负载的大小将减少将要恢复的字节数。如果使用了有效负载的所有字节，则有效负载将被编码为零长度二进制字符串，而不是不存在。
signatures: This field is an array of signatures. Each signature is represented as a COSE_Signature structure.
签名：此字段是签名数组。每个签名都表示为一个COSE_签名结构。
The CDDL fragment that represents the above text for COSE_Sign follows.
下面是代表上述COSE_符号文本的CDDL片段。
COSE_Sign = [
Headers,
payload : bstr / nil,
signatures : [+ COSE_Signature]
]
COSE_Sign = [
Headers,
payload : bstr / nil,
signatures : [+ COSE_Signature]
]
The COSE_Signature structure is a CBOR array. The fields of the array in order are:
COSE_签名结构是一个CBOR数组。按顺序排列的数组字段包括：
protected: This is as described in Section 3.
受保护：如第3节所述。
unprotected: This is as described in Section 3.
无保护：如第3节所述。
signature: This field contains the computed signature value. The type of the field is a bstr. Algorithms MUST specify padding if the signature value is not a multiple of 8 bits.
签名：此字段包含计算的签名值。字段的类型是bstr。如果签名值不是8位的倍数，则算法必须指定填充。
The CDDL fragment that represents the above text for COSE_Signature follows.
下面是代表上述COSE_签名文本的CDDL片段。
COSE_Signature = [
Headers,
signature : bstr
]
COSE_Signature = [
Headers,
signature : bstr
]
The COSE_Sign1 signature structure is used when only one signature is going to be placed on a message. The parameters dealing with the content and the signature are placed in the same pair of buckets rather than having the separation of COSE_Sign.
当消息上只放置一个签名时，使用COSE_Sign1签名结构。处理内容和签名的参数被放置在同一对桶中，而不是分离COSE_符号。
The structure can be encoded as either tagged or untagged depending on the context it will be used in. A tagged COSE_Sign1 structure is identified by the CBOR tag 18. The CDDL fragment that represents this is:
根据将在其中使用的上下文，可以将结构编码为标记或未标记。标记的COSE_Sign1结构由CBOR标记18识别。代表这一点的CDDL片段是：
COSE_Sign1_Tagged = #6.18(COSE_Sign1)
COSE_Sign1_Tagged = #6.18(COSE_Sign1)
The CBOR object that carries the body, the signature, and the information about the body and signature is called the COSE_Sign1 structure. Examples of COSE_Sign1 messages can be found in Appendix C.2.
承载主体、签名以及有关主体和签名的信息的CBOR对象称为COSE_Sign1结构。COSE_Sign1信息示例见附录C.2。
The COSE_Sign1 structure is a CBOR array. The fields of the array in order are:
COSE_Sign1结构是一个CBOR数组。按顺序排列的数组字段包括：
protected: This is as described in Section 3.
受保护：如第3节所述。
unprotected: This is as described in Section 3.
无保护：如第3节所述。
payload: This is as described in Section 4.1.
有效载荷：如第4.1节所述。
signature: This field contains the computed signature value. The type of the field is a bstr.
签名：此字段包含计算的签名值。字段的类型是bstr。
The CDDL fragment that represents the above text for COSE_Sign1 follows.
下面是代表上述COSE_Sign1文本的CDDL片段。
COSE_Sign1 = [
Headers,
payload : bstr / nil,
signature : bstr
]
COSE_Sign1 = [
Headers,
payload : bstr / nil,
signature : bstr
]
One of the features offered in the COSE document is the ability for applications to provide additional data to be authenticated, but that is not carried as part of the COSE object. The primary reason for supporting this can be seen by looking at the CoAP message structure [RFC7252], where the facility exists for options to be carried before the payload. Examples of data that can be placed in this location would be the CoAP code or CoAP options. If the data is in the header section, then it is available for proxies to help in performing its operations. For example, the Accept Option can be used by a proxy to determine if an appropriate value is in the proxy's cache. But the sender can prevent a proxy from changing the set of values that it will accept by including that value in the resulting authentication tag. However, it may also be desired to protect these values so that if they are modified in transit, it can be detected.
COSE文档中提供的一个功能是应用程序能够提供额外的数据进行身份验证，但这些数据不是COSE对象的一部分。支持这一点的主要原因可以通过查看CoAP消息结构[RFC7252]来看出，其中存在用于在有效负载之前携带选项的设施。可放置在此位置的数据示例为CoAP代码或CoAP选项。如果数据位于header部分，则代理可以帮助执行其操作。例如，代理可以使用Accept选项来确定代理缓存中是否存在适当的值。但是，发送方可以通过在生成的身份验证标记中包含该值来防止代理更改它将接受的值集。然而，也可能需要保护这些值，以便在传输过程中对其进行修改时能够检测到。
This document describes the process for using a byte array of externally supplied authenticated data; however, the method of constructing the byte array is a function of the application. Applications that use this feature need to define how the externally supplied authenticated data is to be constructed. Such a construction needs to take into account the following issues:
本文档描述了使用外部提供的认证数据的字节数组的过程；然而，构造字节数组的方法是应用程序的一个功能。使用此功能的应用程序需要定义如何构造外部提供的经过身份验证的数据。这种建设需要考虑以下问题：
o If multiple items are included, applications need to ensure that the same byte string is not produced if there are different inputs. This could occur by appending the strings 'AB' and 'CDE'
o 如果包含多个项，应用程序需要确保在存在不同输入时不会产生相同的字节字符串。这可以通过附加字符串“AB”和“CDE”来实现
or by appending the strings 'ABC' and 'DE'. This is usually addressed by making fields a fixed width and/or encoding the length of the field as part of the output. Using options from CoAP [RFC7252] as an example, these fields use a TLV structure so they can be concatenated without any problems.
或者通过附加字符串“ABC”和“DE”。这通常通过将字段设置为固定宽度和/或将字段长度编码为输出的一部分来解决。以CoAP[RFC7252]中的选项为例，这些字段使用TLV结构，因此可以毫无问题地连接起来。
o If multiple items are included, an order for the items needs to be defined. Using options from CoAP as an example, an application could state that the fields are to be ordered by the option number.
o 如果包含多个项目，则需要定义项目的订单。以CoAP中的选项为例，应用程序可以声明字段将按选项编号排序。
o Applications need to ensure that the byte stream is going to be the same on both sides. Using options from CoAP might give a problem if the same relative numbering is kept. An intermediate node could insert or remove an option, changing how the relative number is done. An application would need to specify that the relative number must be re-encoded to be relative only to the options that are in the external data.
o 应用程序需要确保两边的字节流是相同的。如果保持相同的相对编号，使用CoAP中的选项可能会出现问题。中间节点可以插入或删除选项，从而更改相对编号的执行方式。应用程序需要指定必须重新编码相对数，使其仅与外部数据中的选项相关。
In order to create a signature, a well-defined byte stream is needed. The Sig_structure is used to create the canonical form. This signing and verification process takes in the body information (COSE_Sign or COSE_Sign1), the signer information (COSE_Signature), and the application data (external source). A Sig_structure is a CBOR array. The fields of the Sig_structure in order are:
为了创建签名，需要定义良好的字节流。Sig_结构用于创建规范形式。此签名和验证过程接收主体信息（COSE_签名或COSE_签名1）、签名者信息（COSE_签名）和应用程序数据（外部源）。Sig_结构是CBOR阵列。Sig_结构的字段顺序如下：
1. A text string identifying the context of the signature. The context string is:
1. 标识签名上下文的文本字符串。上下文字符串为：
"Signature" for signatures using the COSE_Signature structure.
“签名”用于使用COSE_签名结构的签名。
"Signature1" for signatures using the COSE_Sign1 structure.
“Signature1”用于使用COSE_Sign1结构的签名。
"CounterSignature" for signatures used as counter signature attributes.
用作反签名属性的签名的“反签名”。
2. The protected attributes from the body structure encoded in a bstr type. If there are no protected attributes, a bstr of length zero is used.
2. 来自bstr类型中编码的主体结构的受保护属性。如果没有受保护的属性，则使用长度为零的bstr。
3. The protected attributes from the signer structure encoded in a bstr type. If there are no protected attributes, a bstr of length zero is used. This field is omitted for the COSE_Sign1 signature structure.
3. bstr类型中编码的签名者结构的受保护属性。如果没有受保护的属性，则使用长度为零的bstr。对于COSE_Sign1签名结构，此字段被省略。
4. The protected attributes from the application encoded in a bstr type. If this field is not supplied, it defaults to a zero-length binary string. (See Section 4.3 for application guidance on constructing this field.)
4. 应用程序中的受保护属性以bstr类型编码。如果未提供此字段，则默认为零长度二进制字符串。（有关构建该领域的应用指南，请参见第4.3节。）
5. The payload to be signed encoded in a bstr type. The payload is placed here independent of how it is transported.
5. 要以bstr类型进行签名编码的有效负载。有效载荷放置在此处，与运输方式无关。
The CDDL fragment that describes the above text is:
描述上述文本的CDDL片段是：
Sig_structure = [
context : "Signature" / "Signature1" / "CounterSignature",
body_protected : empty_or_serialized_map,
? sign_protected : empty_or_serialized_map,
external_aad : bstr,
payload : bstr
]
Sig_structure = [
context : "Signature" / "Signature1" / "CounterSignature",
body_protected : empty_or_serialized_map,
? sign_protected : empty_or_serialized_map,
external_aad : bstr,
payload : bstr
]
How to compute a signature:
如何计算签名：
1. Create a Sig_structure and populate it with the appropriate fields.
1. 创建一个Sig_结构并用适当的字段填充它。
2. Create the value ToBeSigned by encoding the Sig_structure to a byte string, using the encoding described in Section 14.
2. 使用第14节中描述的编码，通过将Sig_结构编码为字节字符串来创建要设计的值。
3. Call the signature creation algorithm passing in K (the key to sign with), alg (the algorithm to sign with), and ToBeSigned (the value to sign).
3. 调用签名创建算法，传入K（要签名的密钥）、alg（要签名的算法）和ToBeSigned（要签名的值）。
4. Place the resulting signature value in the 'signature' field of the array.
4. 将生成的签名值放入数组的“签名”字段中。
The steps for verifying a signature are:
验证签名的步骤包括：
1. Create a Sig_structure object and populate it with the appropriate fields.
1. 创建一个Sig_结构对象并用适当的字段填充它。
2. Create the value ToBeSigned by encoding the Sig_structure to a byte string, using the encoding described in Section 14.
2. 使用第14节中描述的编码，通过将Sig_结构编码为字节字符串来创建要设计的值。
3. Call the signature verification algorithm passing in K (the key to verify with), alg (the algorithm used sign with), ToBeSigned (the value to sign), and sig (the signature to be verified).
3. 调用签名验证算法，传入K（要验证的密钥）、alg（使用sign with的算法）、ToBeSigned（要签名的值）和sig（要验证的签名）。
In addition to performing the signature verification, the application may also perform the appropriate checks to ensure that the key is correctly paired with the signing identity and that the signing identity is authorized before performing actions.
除了执行签名验证之外，应用程序还可以执行适当的检查，以确保密钥与签名身份正确配对，并且在执行操作之前签名身份被授权。
Counter signatures provide a method of associating a different signature generated by different signers with some piece of content. This is normally used to provide a signature on a signature allowing for a proof that a signature existed at a given time (i.e., a Timestamp). In this document, we allow for counter signatures to exist in a greater number of environments. As an example, it is possible to place a counter signature in the unprotected attributes of a COSE_Encrypt object. This would allow for an intermediary to either verify that the encrypted byte stream has not been modified, without being able to decrypt it, or assert that an encrypted byte stream either existed at a given time or passed through it in terms of routing (i.e., a proxy signature).
反签名提供了一种将不同签名者生成的不同签名与某些内容相关联的方法。这通常用于在签名上提供签名，以证明签名在给定时间（即时间戳）存在。在本文档中，我们允许在更多的环境中存在反签名。例如，可以在COSE_Encrypt对象的未受保护属性中放置反签名。这将允许中介验证加密字节流是否未被修改，而不能够对其进行解密，或者断言加密字节流在给定时间存在或在路由方面通过它（即，代理签名）。
An example of a counter signature on a signature can be found in Appendix C.1.3. An example of a counter signature in an encryption object can be found in Appendix C.3.3.
签名上的反签名示例见附录C.1.3。在附录C.3.3中可以找到加密对象中的反签名示例。
The creation and validation of counter signatures over the different items relies on the fact that the objects have the same structure. The elements are a set of protected attributes, a set of unprotected attributes, and a body, in that order. This means that the Sig_structure can be used in a uniform manner to get the byte stream for processing a signature. If the counter signature is going to be computed over a COSE_Encrypt structure, the body_protected and payload items can be mapped into the Sig_structure in the same manner as from the COSE_Sign structure.
不同项目上计数器签名的创建和验证依赖于对象具有相同结构这一事实。元素依次是一组受保护的属性、一组不受保护的属性和一个主体。这意味着可以以统一的方式使用Sig_结构来获取用于处理签名的字节流。如果要在COSE_加密结构上计算反签名，则可以使用与COSE_签名结构相同的方式将受body_保护的和有效负载项映射到Sig_结构。
It should be noted that only a signature algorithm with appendix (see Section 8) can be used for counter signatures. This is because the body should be able to be processed without having to evaluate the counter signature, and this is not possible for signature schemes with message recovery.
应该注意的是，只有带有附录（见第8节）的签名算法才能用于反签名。这是因为主体应该能够在不必计算反签名的情况下进行处理，而这对于具有消息恢复的签名方案是不可能的。
COSE supports two different encryption structures. COSE_Encrypt0 is used when a recipient structure is not needed because the key to be used is known implicitly. COSE_Encrypt is used the rest of the time. This includes cases where there are multiple recipients or a recipient algorithm other than direct is used.
COSE支持两种不同的加密结构。COSE_Encrypt0在不需要收件人结构时使用，因为要使用的密钥是隐式已知的。COSE_加密将在其余时间使用。这包括存在多个收件人或使用direct以外的收件人算法的情况。
The enveloped structure allows for one or more recipients of a message. There are provisions for parameters about the content and parameters about the recipient information to be carried in the message. The protected parameters associated with the content are authenticated by the content encryption algorithm. The protected parameters associated with the recipient are authenticated by the recipient algorithm (when the algorithm supports it). Examples of parameters about the content are the type of the content and the content encryption algorithm. Examples of parameters about the recipient are the recipient's key identifier and the recipient's encryption algorithm.
信封结构允许邮件的一个或多个收件人。有关于内容的参数和关于要在消息中携带的收件人信息的参数的规定。与内容关联的受保护参数通过内容加密算法进行身份验证。与收件人关联的受保护参数由收件人算法进行身份验证（如果算法支持）。有关内容的参数示例有内容类型和内容加密算法。有关收件人的参数示例包括收件人的密钥标识符和收件人的加密算法。
The same techniques and structures are used for encrypting both the plaintext and the keys. This is different from the approach used by both "Cryptographic Message Syntax (CMS)" [RFC5652] and "JSON Web Encryption (JWE)" [RFC7516] where different structures are used for the content layer and for the recipient layer. Two structures are defined: COSE_Encrypt to hold the encrypted content and COSE_recipient to hold the encrypted keys for recipients. Examples of encrypted messages can be found in Appendix C.3.
相同的技术和结构用于加密明文和密钥。这不同于“加密消息语法（CMS）”[RFC5652]和“JSON Web加密（JWE）”[RFC7516]所使用的方法，其中内容层和收件人层使用不同的结构。定义了两种结构：COSE_Encrypt用于保存加密内容，COSE_recipient用于保存收件人的加密密钥。加密消息的示例见附录C.3。
The COSE_Encrypt structure can be encoded as either tagged or untagged depending on the context it will be used in. A tagged COSE_Encrypt structure is identified by the CBOR tag 96. The CDDL fragment that represents this is:
COSE_Encrypt结构可以被编码为标记的或未标记的，这取决于它将在其中使用的上下文。标记的COSE_加密结构由CBOR标记96标识。代表这一点的CDDL片段是：
COSE_Encrypt_Tagged = #6.96(COSE_Encrypt)
COSE_Encrypt_Tagged = #6.96(COSE_Encrypt)
The COSE_Encrypt structure is a CBOR array. The fields of the array in order are:
COSE_加密结构是一个CBOR数组。按顺序排列的数组字段包括：
protected: This is as described in Section 3.
受保护：如第3节所述。
unprotected: This is as described in Section 3.
无保护：如第3节所述。
ciphertext: This field contains the ciphertext encoded as a bstr. If the ciphertext is to be transported independently of the control information about the encryption process (i.e., detached content), then the field is encoded as a nil value.
密文：此字段包含编码为bstr的密文。如果密文要独立于加密过程的控制信息（即分离的内容）进行传输，则该字段被编码为nil值。
recipients: This field contains an array of recipient information structures. The type for the recipient information structure is a COSE_recipient.
收件人：此字段包含收件人信息结构的数组。收件人信息结构的类型为COSE_收件人。
The CDDL fragment that corresponds to the above text is:
与上述文本相对应的CDDL片段为：
COSE_Encrypt = [
Headers,
ciphertext : bstr / nil,
recipients : [+COSE_recipient]
]
COSE_Encrypt = [
Headers,
ciphertext : bstr / nil,
recipients : [+COSE_recipient]
]
The COSE_recipient structure is a CBOR array. The fields of the array in order are:
COSE_接收方结构是一个CBOR数组。按顺序排列的数组字段包括：
protected: This is as described in Section 3.
受保护：如第3节所述。
unprotected: This is as described in Section 3.
无保护：如第3节所述。
ciphertext: This field contains the encrypted key encoded as a bstr. All encoded keys are symmetric keys; the binary value of the key is the content. If there is not an encrypted key, then this field is encoded as a nil value.
密文：此字段包含编码为bstr的加密密钥。所有编码密钥都是对称密钥；密钥的二进制值就是内容。如果没有加密密钥，则此字段将被编码为nil值。
recipients: This field contains an array of recipient information structures. The type for the recipient information structure is a COSE_recipient (an example of this can be found in Appendix B). If there are no recipient information structures, this element is absent.
收件人：此字段包含收件人信息结构的数组。收件人信息结构的类型为COSE_收件人（附录B中有一个示例）。如果没有收件人信息结构，则不存在此元素。
The CDDL fragment that corresponds to the above text for COSE_recipient is:
与上述COSE_收件人文本相对应的CDDL片段为：
COSE_recipient = [
Headers,
ciphertext : bstr / nil,
? recipients : [+COSE_recipient]
]
COSE_recipient = [
Headers,
ciphertext : bstr / nil,
? recipients : [+COSE_recipient]
]
An encrypted message consists of an encrypted content and an encrypted CEK for one or more recipients. The CEK is encrypted for each recipient, using a key specific to that recipient. The details of this encryption depend on which class the recipient algorithm falls into. Specific details on each of the classes can be found in Section 12. A short summary of the five content key distribution methods is:
加密邮件由加密内容和一个或多个收件人的加密CEK组成。使用特定于每个收件人的密钥对CEK进行加密。此加密的详细信息取决于收件人算法属于哪一类。关于每一类的具体细节见第12节。五种内容密钥分发方法的简短总结如下：
direct: The CEK is the same as the identified previously distributed symmetric key or is derived from a previously distributed secret. No CEK is transported in the message.
直接：CEK与已识别的先前分发的对称密钥相同，或源自先前分发的密钥。消息中没有传输CEK。
symmetric key-encryption keys (KEK): The CEK is encrypted using a previously distributed symmetric KEK. Also known as key wrap.
对称密钥加密密钥（KEK）：CEK使用以前分发的对称KEK进行加密。也称为密钥包裹。
key agreement: The recipient's public key and a sender's private key are used to generate a pairwise secret, a Key Derivation Function (KDF) is applied to derive a key, and then the CEK is either the derived key or encrypted by the derived key.
密钥协议：接收方的公钥和发送方的私钥用于生成成对密钥，密钥派生函数（KDF）用于派生密钥，然后CEK是派生密钥或由派生密钥加密。
key transport: The CEK is encrypted with the recipient's public key. No key transport algorithms are defined in this document.
密钥传输：CEK使用接收方的公钥进行加密。本文档中未定义密钥传输算法。
passwords: The CEK is encrypted in a KEK that is derived from a password. No password algorithms are defined in this document.
密码：CEK在从密码派生的KEK中加密。本文档中未定义密码算法。
The COSE_Encrypt0 encrypted structure does not have the ability to specify recipients of the message. The structure assumes that the recipient of the object will already know the identity of the key to be used in order to decrypt the message. If a key needs to be identified to the recipient, the enveloped structure ought to be used.
COSE_Encrypt0加密结构无法指定邮件的收件人。该结构假定对象的接收者已经知道用于解密消息的密钥的标识。如果需要向接收者标识钥匙，则应使用密封结构。
Examples of encrypted messages can be found in Appendix C.3.
加密消息的示例见附录C.3。
The COSE_Encrypt0 structure can be encoded as either tagged or untagged depending on the context it will be used in. A tagged COSE_Encrypt0 structure is identified by the CBOR tag 16. The CDDL fragment that represents this is:
COSE_Encrypt0结构可以编码为标记或未标记，具体取决于它将在其中使用的上下文。带标签的COSE_Encrypt0结构由CBOR标签16标识。代表这一点的CDDL片段是：
COSE_Encrypt0_Tagged = #6.16(COSE_Encrypt0)
COSE_Encrypt0_Tagged = #6.16(COSE_Encrypt0)
The COSE_Encrypt0 structure is a CBOR array. The fields of the array in order are:
COSE_Encrypt0结构是一个CBOR阵列。按顺序排列的数组字段包括：
protected: This is as described in Section 3.
受保护：如第3节所述。
unprotected: This is as described in Section 3.
无保护：如第3节所述。
ciphertext: This is as described in Section 5.1.
密文：如第5.1节所述。
The CDDL fragment for COSE_Encrypt0 that corresponds to the above text is:
与上述文本对应的COSE_Encrypt0的CDDL片段为：
COSE_Encrypt0 = [
Headers,
ciphertext : bstr / nil,
]
COSE_Encrypt0 = [
Headers,
ciphertext : bstr / nil,
]
The encryption algorithm for AEAD algorithms is fairly simple. The first step is to create a consistent byte stream for the authenticated data structure. For this purpose, we use an Enc_structure. The Enc_structure is a CBOR array. The fields of the Enc_structure in order are:
AEAD算法的加密算法相当简单。第一步是为经过身份验证的数据结构创建一致的字节流。为此，我们使用Enc_结构。Enc_结构是CBOR阵列。Enc_结构的字段顺序如下：
1. A text string identifying the context of the authenticated data structure. The context string is:
1. 标识已验证数据结构上下文的文本字符串。上下文字符串为：
"Encrypt0" for the content encryption of a COSE_Encrypt0 data structure.
“Encrypt0”用于COSE_Encrypt0数据结构的内容加密。
"Encrypt" for the first layer of a COSE_Encrypt data structure (i.e., for content encryption).
“加密”用于COSE_加密数据结构的第一层（即，用于内容加密）。
"Enc_Recipient" for a recipient encoding to be placed in an COSE_Encrypt data structure.
“Enc_Recipient”，用于将收件人编码置于COSE_Encrypt数据结构中。
"Mac_Recipient" for a recipient encoding to be placed in a MACed message structure.
“Mac_Recipient”，用于将收件人编码置于MACE消息结构中。
"Rec_Recipient" for a recipient encoding to be placed in a recipient structure.
“Rec_Recipient”，用于将收件人编码放置在收件人结构中。
2. The protected attributes from the body structure encoded in a bstr type. If there are no protected attributes, a bstr of length zero is used.
2. 来自bstr类型中编码的主体结构的受保护属性。如果没有受保护的属性，则使用长度为零的bstr。
3. The protected attributes from the application encoded in a bstr type. If this field is not supplied, it defaults to a zero-length bstr. (See Section 4.3 for application guidance on constructing this field.)
3. 应用程序中的受保护属性以bstr类型编码。如果未提供此字段，则默认为零长度bstr。（有关构建该领域的应用指南，请参见第4.3节。）
The CDDL fragment that describes the above text is:
描述上述文本的CDDL片段是：
Enc_structure = [
context : "Encrypt" / "Encrypt0" / "Enc_Recipient" /
"Mac_Recipient" / "Rec_Recipient",
protected : empty_or_serialized_map,
external_aad : bstr
]
Enc_structure = [
context : "Encrypt" / "Encrypt0" / "Enc_Recipient" /
"Mac_Recipient" / "Rec_Recipient",
protected : empty_or_serialized_map,
external_aad : bstr
]
How to encrypt a message:
如何加密邮件：
1. Create an Enc_structure and populate it with the appropriate fields.
1. 创建一个Enc_结构并用适当的字段填充它。
2. Encode the Enc_structure to a byte stream (Additional Authenticated Data (AAD)), using the encoding described in Section 14.
2. 使用第14节中描述的编码，将Enc_结构编码为字节流（附加认证数据（AAD））。
3. Determine the encryption key (K). This step is dependent on the class of recipient algorithm being used. For:
3. 确定加密密钥（K）。此步骤取决于所使用的收件人算法的类别。用于：
No Recipients: The key to be used is determined by the algorithm and key at the current layer. Examples are key transport keys (Section 12.3), key wrap keys (Section 12.2.1), or pre-shared secrets.
无收件人：要使用的密钥由当前层的算法和密钥决定。例如，密钥传输密钥（第12.3节）、密钥包裹密钥（第12.2.1节）或预共享密钥。
Direct Encryption and Direct Key Agreement: The key is determined by the key and algorithm in the recipient structure. The encryption algorithm and size of the key to be used are inputs into the KDF used for the recipient. (For direct, the KDF can be thought of as the identity operation.) Examples of these algorithms are found in Sections 12.1.2 and 12.4.1.
直接加密和直接密钥协商：密钥由接收方结构中的密钥和算法确定。将要使用的加密算法和密钥大小输入到用于收件人的KDF中。（对于direct，KDF可被视为身份操作。）这些算法的示例见第12.1.2节和第12.4.1节。
Other: The key is randomly or pseudorandomly generated.
其他：密钥是随机或伪随机生成的。
4. Call the encryption algorithm with K (the encryption key), P (the plaintext), and AAD. Place the returned ciphertext into the 'ciphertext' field of the structure.
4. 使用K（加密密钥）、P（明文）和AAD调用加密算法。将返回的密文放入结构的“ciphertext”字段中。
5. For recipients of the message, recursively perform the encryption algorithm for that recipient, using K (the encryption key) as the plaintext.
5. 对于消息的收件人，使用K（加密密钥）作为明文，递归地执行该收件人的加密算法。
How to decrypt a message:
如何解密邮件：
1. Create an Enc_structure and populate it with the appropriate fields.
1. 创建一个Enc_结构并用适当的字段填充它。
2. Encode the Enc_structure to a byte stream (AAD), using the encoding described in Section 14.
2. 使用第14节中描述的编码将Enc_结构编码为字节流（AAD）。
3. Determine the decryption key. This step is dependent on the class of recipient algorithm being used. For:
3. 确定解密密钥。此步骤取决于所使用的收件人算法的类别。用于：
No Recipients: The key to be used is determined by the algorithm and key at the current layer. Examples are key transport keys (Section 12.3), key wrap keys (Section 12.2.1), or pre-shared secrets.
无收件人：要使用的密钥由当前层的算法和密钥决定。例如，密钥传输密钥（第12.3节）、密钥包裹密钥（第12.2.1节）或预共享密钥。
Direct Encryption and Direct Key Agreement: The key is determined by the key and algorithm in the recipient structure. The encryption algorithm and size of the key to be used are inputs into the KDF used for the recipient. (For direct, the KDF can be thought of as the identity operation.) Examples of these algorithms are found in Sections 12.1.2 and 12.4.1.
直接加密和直接密钥协商：密钥由接收方结构中的密钥和算法确定。将要使用的加密算法和密钥大小输入到用于收件人的KDF中。（对于direct，KDF可被视为身份操作。）这些算法的示例见第12.1.2节和第12.4.1节。
Other: The key is determined by decoding and decrypting one of the recipient structures.
其他：密钥是通过对其中一个接收方结构进行解码和解密来确定的。
4. Call the decryption algorithm with K (the decryption key to use), C (the ciphertext), and AAD.
4. 使用K（要使用的解密密钥）、C（密文）和AAD调用解密算法。
How to encrypt a message:
如何加密邮件：
1. Verify that the 'protected' field is empty.
1. 验证“受保护”字段是否为空。
2. Verify that there was no external additional authenticated data supplied for this operation.
2. 验证是否没有为此操作提供任何外部附加身份验证数据。
3. Determine the encryption key. This step is dependent on the class of recipient algorithm being used. For:
3. 确定加密密钥。此步骤取决于所使用的收件人算法的类别。用于：
No Recipients: The key to be used is determined by the algorithm and key at the current layer. Examples are key transport keys (Section 12.3), key wrap keys (Section 12.2.1), or pre-shared secrets.
无收件人：要使用的密钥由当前层的算法和密钥决定。例如，密钥传输密钥（第12.3节）、密钥包裹密钥（第12.2.1节）或预共享密钥。
Direct Encryption and Direct Key Agreement: The key is determined by the key and algorithm in the recipient structure. The encryption algorithm and size of the key to be used are inputs into the KDF used for the recipient. (For direct, the KDF can be thought of as the identity operation.) Examples of these algorithms are found in Sections 12.1.2 and 12.4.1.
直接加密和直接密钥协商：密钥由接收方结构中的密钥和算法确定。将要使用的加密算法和密钥大小输入到用于收件人的KDF中。（对于direct，KDF可被视为身份操作。）这些算法的示例见第12.1.2节和第12.4.1节。
Other: The key is randomly generated.
其他：密钥是随机生成的。
4. Call the encryption algorithm with K (the encryption key to use) and P (the plaintext). Place the returned ciphertext into the 'ciphertext' field of the structure.
4. 使用K（要使用的加密密钥）和P（明文）调用加密算法。将返回的密文放入结构的“ciphertext”字段中。
5. For recipients of the message, recursively perform the encryption algorithm for that recipient, using K (the encryption key) as the plaintext.
5. 对于消息的收件人，使用K（加密密钥）作为明文，递归地执行该收件人的加密算法。
How to decrypt a message:
如何解密邮件：
1. Verify that the 'protected' field is empty.
1. 验证“受保护”字段是否为空。
2. Verify that there was no external additional authenticated data supplied for this operation.
2. 验证是否没有为此操作提供任何外部附加身份验证数据。
3. Determine the decryption key. This step is dependent on the class of recipient algorithm being used. For:
3. 确定解密密钥。此步骤取决于所使用的收件人算法的类别。用于：
No Recipients: The key to be used is determined by the algorithm and key at the current layer. Examples are key transport keys (Section 12.3), key wrap keys (Section 12.2.1), or pre-shared secrets.
无收件人：要使用的密钥由当前层的算法和密钥决定。例如，密钥传输密钥（第12.3节）、密钥包裹密钥（第12.2.1节）或预共享密钥。
Direct Encryption and Direct Key Agreement: The key is determined by the key and algorithm in the recipient structure. The encryption algorithm and size of the key to be used are inputs into the KDF used for the recipient. (For direct, the KDF can be thought of as the identity operation.) Examples of these algorithms are found in Sections 12.1.2 and 12.4.1.
直接加密和直接密钥协商：密钥由接收方结构中的密钥和算法确定。将要使用的加密算法和密钥大小输入到用于收件人的KDF中。（对于direct，KDF可被视为身份操作。）这些算法的示例见第12.1.2节和第12.4.1节。
Other: The key is determined by decoding and decrypting one of the recipient structures.
其他：密钥是通过对其中一个接收方结构进行解码和解密来确定的。
4. Call the decryption algorithm with K (the decryption key to use) and C (the ciphertext).
4. 使用K（要使用的解密密钥）和C（密文）调用解密算法。
COSE supports two different MAC structures. COSE_MAC0 is used when a recipient structure is not needed because the key to be used is implicitly known. COSE_MAC is used for all other cases. These include a requirement for multiple recipients, the key being unknown, and a recipient algorithm of other than direct.
COSE支持两种不同的MAC结构。COSE_MAC0在不需要收件人结构时使用，因为要使用的密钥是隐式已知的。COSE_MAC用于所有其他情况。其中包括对多个接收者的要求，密钥未知，以及非直接的接收者算法。
In this section, we describe the structure and methods to be used when doing MAC authentication in COSE. This document allows for the use of all of the same classes of recipient algorithms as are allowed for encryption.
在本节中，我们将描述在COSE中进行MAC身份验证时要使用的结构和方法。本文档允许使用与加密相同的所有收件人算法。
When using MAC operations, there are two modes in which they can be used. The first is just a check that the content has not been changed since the MAC was computed. Any class of recipient algorithm can be used for this purpose. The second mode is to both check that the content has not been changed since the MAC was computed and to use the recipient algorithm to verify who sent it. The classes of
在使用MAC操作时，有两种模式可供使用。第一个是检查内容在计算MAC后是否没有更改。任何类别的接收者算法都可以用于此目的。第二种模式是检查内容在计算MAC后是否没有更改，并使用收件人算法验证是谁发送了内容。阶级
recipient algorithms that support this are those that use a pre-shared secret or do static-static (SS) key agreement (without the key wrap step). In both of these cases, the entity that created and sent the message MAC can be validated. (This knowledge of the sender assumes that there are only two parties involved and that you did not send the message to yourself.) The origination property can be obtained with both of the MAC message structures.
支持这一点的接收者算法是那些使用预共享秘密或进行静态（SS）密钥协商（无密钥包装步骤）的算法。在这两种情况下，可以验证创建和发送消息MAC的实体。（对发送方的了解假设只有两方参与，并且您没有将消息发送给自己。）可以通过两种MAC消息结构获得origination属性。
The multiple recipient MACed message uses two structures: the COSE_Mac structure defined in this section for carrying the body and the COSE_recipient structure (Section 5.1) to hold the key used for the MAC computation. Examples of MACed messages can be found in Appendix C.5.
多收件人MACE消息使用两种结构：本节中定义的用于承载正文的COSE_Mac结构和用于保存Mac计算密钥的COSE_收件人结构（第5.1节）。MACE消息的示例见附录C.5。
The MAC structure can be encoded as either tagged or untagged depending on the context it will be used in. A tagged COSE_Mac structure is identified by the CBOR tag 97. The CDDL fragment that represents this is:
The MAC structure can be encoded as either tagged or untagged depending on the context it will be used in. A tagged COSE_Mac structure is identified by the CBOR tag 97. The CDDL fragment that represents this is:translate error, please retry
COSE_Mac_Tagged = #6.97(COSE_Mac)
COSE_Mac_Tagged = #6.97(COSE_Mac)
The COSE_Mac structure is a CBOR array. The fields of the array in order are:
COSE_Mac结构是CBOR阵列。按顺序排列的数组字段包括：
protected: This is as described in Section 3.
受保护：如第3节所述。
unprotected: This is as described in Section 3.
无保护：如第3节所述。
payload: This field contains the serialized content to be MACed. If the payload is not present in the message, the application is required to supply the payload separately. The payload is wrapped in a bstr to ensure that it is transported without changes. If the payload is transported separately (i.e., detached content), then a nil CBOR value is placed in this location, and it is the responsibility of the application to ensure that it will be transported without changes.
有效负载：此字段包含要缓冲的序列化内容。如果消息中不存在有效负载，则要求应用程序单独提供有效负载。有效负载被包装在bstr中，以确保其在传输时不会发生更改。如果有效载荷单独运输（即分离的内容），则在该位置放置一个nil CBOR值，应用程序有责任确保在不改变的情况下运输有效载荷。
tag: This field contains the MAC value.
标记：此字段包含MAC值。
recipients: This is as described in Section 5.1.
收件人：如第5.1节所述。
The CDDL fragment that represents the above text for COSE_Mac follows.
下面是代表上述COSE_Mac文本的CDDL片段。
COSE_Mac = [
Headers,
payload : bstr / nil,
tag : bstr,
recipients :[+COSE_recipient]
]
COSE_Mac = [
Headers,
payload : bstr / nil,
tag : bstr,
recipients :[+COSE_recipient]
]
In this section, we describe the structure and methods to be used when doing MAC authentication for those cases where the recipient is implicitly known.
在本节中，我们将描述在对接收方隐式已知的情况进行MAC身份验证时要使用的结构和方法。
The MACed message uses the COSE_Mac0 structure defined in this section for carrying the body. Examples of MACed messages with an implicit key can be found in Appendix C.6.
MACed消息使用本节中定义的COSE_Mac0结构来承载正文。带有隐式键的MACE消息示例见附录C.6。
The MAC structure can be encoded as either tagged or untagged depending on the context it will be used in. A tagged COSE_Mac0 structure is identified by the CBOR tag 17. The CDDL fragment that represents this is:
MAC结构可以被编码为标记的或未标记的，这取决于它将在其中使用的上下文。标记的COSE_Mac0结构由CBOR标记17标识。代表这一点的CDDL片段是：
COSE_Mac0_Tagged = #6.17(COSE_Mac0)
COSE_Mac0_Tagged = #6.17(COSE_Mac0)
The COSE_Mac0 structure is a CBOR array. The fields of the array in order are:
COSE_Mac0结构是一个CBOR阵列。按顺序排列的数组字段包括：
protected: This is as described in Section 3.
受保护：如第3节所述。
unprotected: This is as described in Section 3.
无保护：如第3节所述。
payload: This is as described in Section 6.1.
有效载荷：如第6.1节所述。
tag: This field contains the MAC value.
标记：此字段包含MAC值。
The CDDL fragment that corresponds to the above text is:
与上述文本相对应的CDDL片段为：
COSE_Mac0 = [
Headers,
payload : bstr / nil,
tag : bstr,
]
COSE_Mac0 = [
Headers,
payload : bstr / nil,
tag : bstr,
]
In order to get a consistent encoding of the data to be authenticated, the MAC_structure is used to have a canonical form. The MAC_structure is a CBOR array. The fields of the MAC_structure in order are:
为了获得待认证数据的一致编码，使用MAC_结构来具有标准形式。MAC_结构是CBOR阵列。MAC_结构的字段顺序如下：
1. A text string that identifies the structure that is being encoded. This string is "MAC" for the COSE_Mac structure. This string is "MAC0" for the COSE_Mac0 structure.
1. 标识正在编码的结构的文本字符串。这个字符串是COSE_MAC结构的“MAC”。对于COSE_MAC0结构，此字符串为“MAC0”。
2. The protected attributes from the COSE_MAC structure. If there are no protected attributes, a zero-length bstr is used.
2. COSE_MAC结构中受保护的属性。如果没有受保护的属性，则使用零长度的bstr。
3. The protected attributes from the application encoded as a bstr type. If this field is not supplied, it defaults to a zero-length binary string. (See Section 4.3 for application guidance on constructing this field.)
3. 应用程序中的受保护属性编码为bstr类型。如果未提供此字段，则默认为零长度二进制字符串。（有关构建该领域的应用指南，请参见第4.3节。）
4. The payload to be MACed encoded in a bstr type. The payload is placed here independent of how it is transported.
4. 要以bstr类型编码的MACE有效负载。有效载荷放置在此处，与运输方式无关。
The CDDL fragment that corresponds to the above text is:
与上述文本相对应的CDDL片段为：
MAC_structure = [
context : "MAC" / "MAC0",
protected : empty_or_serialized_map,
external_aad : bstr,
payload : bstr
]
MAC_structure = [
context : "MAC" / "MAC0",
protected : empty_or_serialized_map,
external_aad : bstr,
payload : bstr
]
The steps to compute a MAC are:
计算MAC的步骤如下：
1. Create a MAC_structure and populate it with the appropriate fields.
1. 创建MAC_结构并用适当的字段填充它。
2. Create the value ToBeMaced by encoding the MAC_structure to a byte stream, using the encoding described in Section 14.
2. 使用第14节中描述的编码，通过将MAC_结构编码为字节流来创建要交换的值。
3. Call the MAC creation algorithm passing in K (the key to use), alg (the algorithm to MAC with), and ToBeMaced (the value to compute the MAC on).
3. 调用MAC创建算法，传入K（要使用的密钥）、alg（用于MAC的算法）和ToBeMaced（用于计算MAC的值）。
4. Place the resulting MAC in the 'tag' field of the COSE_Mac or COSE_Mac0 structure.
4. 将生成的MAC放入COSE_MAC或COSE_Mac0结构的“标记”字段中。
5. Encrypt and encode the MAC key for each recipient of the message.
5. 对消息的每个收件人的MAC密钥进行加密和编码。
The steps to verify a MAC are:
验证MAC的步骤包括：
1. Create a MAC_structure object and populate it with the appropriate fields.
1. 创建MAC_结构对象并用适当的字段填充它。
2. Create the value ToBeMaced by encoding the MAC_structure to a byte stream, using the encoding described in Section 14.
2. 使用第14节中描述的编码，通过将MAC_结构编码为字节流来创建要交换的值。
3. Obtain the cryptographic key from one of the recipients of the message.
3. 从邮件的一个收件人处获取加密密钥。
4. Call the MAC creation algorithm passing in K (the key to use), alg (the algorithm to MAC with), and ToBeMaced (the value to compute the MAC on).
4. 调用MAC创建算法，传入K（要使用的密钥）、alg（用于MAC的算法）和ToBeMaced（用于计算MAC的值）。
5. Compare the MAC value to the 'tag' field of the COSE_Mac or COSE_Mac0 structure.
5. 将MAC值与COSE_MAC或COSE_Mac0结构的“标记”字段进行比较。
A COSE Key structure is built on a CBOR map object. The set of common parameters that can appear in a COSE Key can be found in the IANA "COSE Key Common Parameters" registry (Section 16.5). Additional parameters defined for specific key types can be found in the IANA "COSE Key Type Parameters" registry (Section 16.6).
COSE密钥结构构建在CBOR映射对象上。可以在IANA“COSE密钥公共参数”注册表中找到COSE密钥中出现的公共参数集（第16.5节）。为特定密钥类型定义的其他参数可在IANA“COSE密钥类型参数”注册表中找到（第16.6节）。
A COSE Key Set uses a CBOR array object as its underlying type. The values of the array elements are COSE Keys. A COSE Key Set MUST have at least one element in the array. Examples of COSE Key Sets can be found in Appendix C.7.
COSE密钥集使用CBOR数组对象作为其基础类型。数组元素的值是COSE键。COSE密钥集在数组中必须至少有一个元素。COSE密钥集示例见附录C.7。
Each element in a COSE Key Set MUST be processed independently. If one element in a COSE Key Set is either malformed or uses a key that is not understood by an application, that key is ignored and the other keys are processed normally.
COSE密钥集中的每个元素都必须独立处理。如果COSE密钥集中的一个元素的格式不正确或使用了应用程序无法理解的密钥，则会忽略该密钥，并正常处理其他密钥。
The element "kty" is a required element in a COSE_Key map.
元素“kty”是COSE_键映射中的必需元素。
The CDDL grammar describing COSE_Key and COSE_KeySet is:
描述COSE_键和COSE_键集的CDDL语法为：
COSE_Key = {
1 => tstr / int, ; kty
? 2 => bstr, ; kid
? 3 => tstr / int, ; alg
? 4 => [+ (tstr / int) ], ; key_ops
? 5 => bstr, ; Base IV
* label => values
}
COSE_Key = {
1 => tstr / int, ; kty
? 2 => bstr, ; kid
? 3 => tstr / int, ; alg
? 4 => [+ (tstr / int) ], ; key_ops
? 5 => bstr, ; Base IV
* label => values
}
COSE_KeySet = [+COSE_Key]
COSE_KeySet = [+COSE_Key]
This document defines a set of common parameters for a COSE Key object. Table 3 provides a summary of the parameters defined in this section. There are also parameters that are defined for specific key types. Key-type-specific parameters can be found in Section 13.
本文档为COSE密钥对象定义了一组公共参数。表3总结了本节中定义的参数。还有为特定键类型定义的参数。键类型特定参数可在第13节中找到。
+---------+-------+----------------+------------+-------------------+
| Name | Label | CBOR Type | Value | Description |
| | | | Registry | |
+---------+-------+----------------+------------+-------------------+
| kty | 1 | tstr / int | COSE Key | Identification of |
| | | | Common | the key type |
| | | | Parameters | |
| | | | | |
| kid | 2 | bstr | | Key |
| | | | | identification |
| | | | | value -- match to |
| | | | | kid in message |
| | | | | |
| alg | 3 | tstr / int | COSE | Key usage |
| | | | Algorithms | restriction to |
| | | | | this algorithm |
| | | | | |
| key_ops | 4 | [+ (tstr/int)] | | Restrict set of |
| | | | | permissible |
| | | | | operations |
| | | | | |
| Base IV | 5 | bstr | | Base IV to be |
| | | | | xor-ed with |
| | | | | Partial IVs |
+---------+-------+----------------+------------+-------------------+
+---------+-------+----------------+------------+-------------------+
| Name | Label | CBOR Type | Value | Description |
| | | | Registry | |
+---------+-------+----------------+------------+-------------------+
| kty | 1 | tstr / int | COSE Key | Identification of |
| | | | Common | the key type |
| | | | Parameters | |
| | | | | |
| kid | 2 | bstr | | Key |
| | | | | identification |
| | | | | value -- match to |
| | | | | kid in message |
| | | | | |
| alg | 3 | tstr / int | COSE | Key usage |
| | | | Algorithms | restriction to |
| | | | | this algorithm |
| | | | | |
| key_ops | 4 | [+ (tstr/int)] | | Restrict set of |
| | | | | permissible |
| | | | | operations |
| | | | | |
| Base IV | 5 | bstr | | Base IV to be |
| | | | | xor-ed with |
| | | | | Partial IVs |
+---------+-------+----------------+------------+-------------------+
Table 3: Key Map Labels
表3：关键地图标签
kty: This parameter is used to identify the family of keys for this structure and, thus, the set of key-type-specific parameters to be found. The set of values defined in this document can be found in Table 21. This parameter MUST be present in a key object. Implementations MUST verify that the key type is appropriate for the algorithm being processed. The key type MUST be included as part of the trust decision process.
kty：此参数用于标识此结构的键族，从而标识要查找的键类型特定参数集。本文件中定义的一组值见表21。此参数必须存在于密钥对象中。实现必须验证密钥类型是否适合正在处理的算法。密钥类型必须包括在信任决策过程中。
alg: This parameter is used to restrict the algorithm that is used with the key. If this parameter is present in the key structure, the application MUST verify that this algorithm matches the algorithm for which the key is being used. If the algorithms do not match, then this key object MUST NOT be used to perform the cryptographic operation. Note that the same key can be in a different key structure with a different or no algorithm specified; however, this is considered to be a poor security practice.
alg：此参数用于限制与密钥一起使用的算法。如果密钥结构中存在此参数，则应用程序必须验证此算法是否与使用密钥的算法匹配。如果算法不匹配，则不得使用此密钥对象执行加密操作。请注意，同一密钥可以在不同的密钥结构中使用不同的算法或不指定算法；然而，这被认为是一种糟糕的安全做法。
kid: This parameter is used to give an identifier for a key. The identifier is not structured and can be anything from a user-provided string to a value computed on the public portion of the key. This field is intended for matching against a 'kid' parameter in a message in order to filter down the set of keys that need to be checked.
kid：此参数用于为密钥提供标识符。标识符不是结构化的，可以是从用户提供的字符串到在密钥的公共部分计算的值的任何内容。此字段用于与消息中的“kid”参数匹配，以便筛选需要检查的密钥集。
key_ops: This parameter is defined to restrict the set of operations that a key is to be used for. The value of the field is an array of values from Table 4. Algorithms define the values of key ops that are permitted to appear and are required for specific operations. The set of values matches that in [RFC7517] and [W3C.WebCrypto].
key_ops：定义此参数是为了限制要使用密钥的操作集。该字段的值是表4中的值数组。算法定义允许出现且特定操作所需的关键操作的值。该组值与[RFC7517]和[W3C.WebCrypto]中的值匹配。
Base IV: This parameter is defined to carry the base portion of an IV. It is designed to be used with the Partial IV header parameter defined in Section 3.1. This field provides the ability to associate a Partial IV with a key that is then modified on a per message basis with the Partial IV.
Base IV：该参数定义为携带IV的基本部分。其设计用于第3.1节中定义的部分IV标题参数。此字段提供将部分IV与密钥关联的功能，然后根据每条消息对该密钥进行修改。
Extreme care needs to be taken when using a Base IV in an application. Many encryption algorithms lose security if the same IV is used twice.
在应用中使用Base IV时需要格外小心。如果使用同一个IV两次，许多加密算法就会失去安全性。
If different keys are derived for each sender, using the same Base IV with Partial IVs starting at zero is likely to ensure that the IV would not be used twice for a single key. If different keys are derived for each sender, starting at the same Base IV is likely to satisfy this condition. If the same key is used for multiple senders, then the application needs to provide for a method of dividing the IV space up between the senders. This could be done by providing a different base point to start from or a different Partial IV to start with and restricting the number of messages to be sent before rekeying.
如果为每个发送方派生不同的密钥，则使用相同的基本IV和从零开始的部分IV可能会确保不会对单个密钥使用两次IV。如果为每个发送方派生不同的密钥，则从相同的基IV开始很可能满足此条件。如果同一密钥用于多个发送方，则应用程序需要提供一种方法，在发送方之间划分IV空间。这可以通过提供一个不同的起点或一个不同的第四部分开始，并限制重新键入之前要发送的消息数量来实现。
+---------+-------+-------------------------------------------------+
| Name | Value | Description |
+---------+-------+-------------------------------------------------+
| sign | 1 | The key is used to create signatures. Requires |
| | | private key fields. |
| verify | 2 | The key is used for verification of signatures. |
| encrypt | 3 | The key is used for key transport encryption. |
| decrypt | 4 | The key is used for key transport decryption. |
| | | Requires private key fields. |
| wrap | 5 | The key is used for key wrap encryption. |
| key | | |
| unwrap | 6 | The key is used for key wrap decryption. |
| key | | Requires private key fields. |
| derive | 7 | The key is used for deriving keys. Requires |
| key | | private key fields. |
| derive | 8 | The key is used for deriving bits not to be |
| bits | | used as a key. Requires private key fields. |
| MAC | 9 | The key is used for creating MACs. |
| create | | |
| MAC | 10 | The key is used for validating MACs. |
| verify | | |
+---------+-------+-------------------------------------------------+
+---------+-------+-------------------------------------------------+
| Name | Value | Description |
+---------+-------+-------------------------------------------------+
| sign | 1 | The key is used to create signatures. Requires |
| | | private key fields. |
| verify | 2 | The key is used for verification of signatures. |
| encrypt | 3 | The key is used for key transport encryption. |
| decrypt | 4 | The key is used for key transport decryption. |
| | | Requires private key fields. |
| wrap | 5 | The key is used for key wrap encryption. |
| key | | |
| unwrap | 6 | The key is used for key wrap decryption. |
| key | | Requires private key fields. |
| derive | 7 | The key is used for deriving keys. Requires |
| key | | private key fields. |
| derive | 8 | The key is used for deriving bits not to be |
| bits | | used as a key. Requires private key fields. |
| MAC | 9 | The key is used for creating MACs. |
| create | | |
| MAC | 10 | The key is used for validating MACs. |
| verify | | |
+---------+-------+-------------------------------------------------+
Table 4: Key Operation Values
表4：关键操作值
There are two signature algorithm schemes. The first is signature with appendix. In this scheme, the message content is processed and a signature is produced; the signature is called the appendix. This is the scheme used by algorithms such as ECDSA and the RSA Probabilistic Signature Scheme (RSASSA-PSS). (In fact, the SSA in RSASSA-PSS stands for Signature Scheme with Appendix.)
有两种签名算法方案。第一个是带有附录的签名。在该方案中，处理消息内容并生成签名；签名被称为附录。这是ECDSA和RSA概率签名方案（RSASSA-PSS）等算法使用的方案。（实际上，RSASSA-PSS中的SSA代表带有附录的签名方案。）
The signature functions for this scheme are:
该方案的签名功能包括：
signature = Sign(message content, key)
签名=签名（消息内容、密钥）
valid = Verification(message content, key, signature)
有效=验证（消息内容、密钥、签名）
The second scheme is signature with message recovery (an example of such an algorithm is [PVSig]). In this scheme, the message content is processed, but part of it is included in the signature. Moving bytes of the message content into the signature allows for smaller signatures; the signature size is still potentially large, but the message content has shrunk. This has implications for systems implementing these algorithms and for applications that use them. The first is that the message content is not fully available until
第二个方案是带有消息恢复的签名（这种算法的一个例子是[PVSig]）。在该方案中，消息内容被处理，但部分内容被包含在签名中。将消息内容的字节移动到签名中允许更小的签名；签名大小仍然可能很大，但消息内容已缩小。这对实现这些算法的系统和使用它们的应用程序都有影响。第一个是消息内容直到
after a signature has been validated. Until that point, the part of the message contained inside of the signature is unrecoverable. The second is that the security analysis of the strength of the signature is very much based on the structure of the message content. Messages that are highly predictable require additional randomness to be supplied as part of the signature process. In the worst case, it becomes the same as doing a signature with appendix. Finally, in the event that multiple signatures are applied to a message, all of the signature algorithms are going to be required to consume the same number of bytes of message content. This means that the mixing of the different schemes in a single message is not supported, and if a recovery signature scheme is used, then the same amount of content needs to be consumed by all of the signatures.
签名验证后。在此之前，签名中包含的消息部分是不可恢复的。第二，签名强度的安全性分析很大程度上基于消息内容的结构。高度可预测的消息需要作为签名过程的一部分提供额外的随机性。在最坏的情况下，这与使用附录进行签名是一样的。最后，如果对一条消息应用了多个签名，则所有签名算法都需要消耗相同数量的消息内容字节。这意味着不支持在单个消息中混合使用不同的方案，如果使用恢复签名方案，则所有签名都需要消耗相同数量的内容。
The signature functions for this scheme are:
该方案的签名功能包括：
signature, message sent = Sign(message content, key)
签名，已发送消息=签名（消息内容，密钥）
valid, message content = Verification(message sent, key, signature)
有效，消息内容=验证（已发送消息、密钥、签名）
Signature algorithms are used with the COSE_Signature and COSE_Sign1 structures. At this time, only signatures with appendixes are defined for use with COSE; however, considerable interest has been expressed in using a signature with message recovery algorithm due to the effective size reduction that is possible. Implementations will need to keep this in mind for later possible integration.
签名算法与COSE_签名和COSE_签名1结构一起使用。此时，仅定义带有附录的签名用于COSE；然而，由于可以有效地减小签名的大小，人们对使用带有消息恢复算法的签名表示了极大的兴趣。在以后可能的集成中，实现需要记住这一点。
ECDSA [DSS] defines a signature algorithm using ECC. Implementations SHOULD use a deterministic version of ECDSA such as the one defined in [RFC6979]. The use of a deterministic signature algorithm allows for systems to avoid relying on random number generators in order to avoid generating the same value of 'k' (the per-message random value). Biased generation of the value 'k' can be attacked, and collisions of this value leads to leaked keys. It additionally allows for doing deterministic tests for the signature algorithm. The use of deterministic ECDSA does not lessen the need to have good random number generation when creating the private key.
ECDSA[DSS]使用ECC定义签名算法。实施应使用ECDSA的确定性版本，如[RFC6979]中定义的版本。使用确定性签名算法允许系统避免依赖随机数生成器，以避免生成相同的“k”（每条消息的随机值）值。值“k”的有偏生成可能受到攻击，该值的冲突会导致密钥泄漏。它还允许对签名算法进行确定性测试。使用确定性ECDSA并不会减少在创建私钥时生成良好随机数的需要。
The ECDSA signature algorithm is parameterized with a hash function (h). In the event that the length of the hash function output is greater than the group of the key, the leftmost bytes of the hash output are used.
ECDSA签名算法使用散列函数（h）进行参数化。如果哈希函数输出的长度大于密钥组，则使用哈希输出的最左侧字节。
The algorithms defined in this document can be found in Table 5.
本文件中定义的算法见表5。
+-------+-------+---------+------------------+
| Name | Value | Hash | Description |
+-------+-------+---------+------------------+
| ES256 | -7 | SHA-256 | ECDSA w/ SHA-256 |
| ES384 | -35 | SHA-384 | ECDSA w/ SHA-384 |
| ES512 | -36 | SHA-512 | ECDSA w/ SHA-512 |
+-------+-------+---------+------------------+
+-------+-------+---------+------------------+
| Name | Value | Hash | Description |
+-------+-------+---------+------------------+
| ES256 | -7 | SHA-256 | ECDSA w/ SHA-256 |
| ES384 | -35 | SHA-384 | ECDSA w/ SHA-384 |
| ES512 | -36 | SHA-512 | ECDSA w/ SHA-512 |
+-------+-------+---------+------------------+
Table 5: ECDSA Algorithm Values
表5:ECDSA算法值
This document defines ECDSA to work only with the curves P-256, P-384, and P-521. This document requires that the curves be encoded using the 'EC2' (2 coordinate elliptic curve) key type. Implementations need to check that the key type and curve are correct when creating and verifying a signature. Other documents can define it to work with other curves and points in the future.
本文档将ECDSA定义为仅适用于曲线P-256、P-384和P-521。本文档要求使用“EC2”（2坐标椭圆曲线）密钥类型对曲线进行编码。在创建和验证签名时，实现需要检查密钥类型和曲线是否正确。其他文档可以将其定义为将来使用其他曲线和点。
In order to promote interoperability, it is suggested that SHA-256 be used only with curve P-256, SHA-384 be used only with curve P-384, and SHA-512 be used with curve P-521. This is aligned with the recommendation in Section 4 of [RFC5480].
为了促进互操作性，建议SHA-256仅与曲线P-256一起使用，SHA-384仅与曲线P-384一起使用，SHA-512与曲线P-521一起使用。这与[RFC5480]第4节中的建议一致。
The signature algorithm results in a pair of integers (R, S). These integers will be the same length as the length of the key used for the signature process. The signature is encoded by converting the integers into byte strings of the same length as the key size. The length is rounded up to the nearest byte and is left padded with zero bits to get to the correct length. The two integers are then concatenated together to form a byte string that is the resulting signature.
签名算法产生一对整数（R，S）。这些整数的长度将与签名过程中使用的密钥的长度相同。签名通过将整数转换为与密钥大小相同长度的字节字符串进行编码。长度向上舍入到最接近的字节，并用零位填充，以获得正确的长度。然后将这两个整数连接在一起，形成一个字节字符串，即结果签名。
Using the function defined in [RFC8017], the signature is:
Signature = I2OSP(R, n) | I2OSP(S, n)
where n = ceiling(key_length / 8)
Using the function defined in [RFC8017], the signature is:
Signature = I2OSP(R, n) | I2OSP(S, n)
where n = ceiling(key_length / 8)
When using a COSE key for this algorithm, the following checks are made:
使用此算法的COSE密钥时，将进行以下检查：
o The 'kty' field MUST be present, and it MUST be 'EC2'.
o “kty”字段必须存在，并且必须是“EC2”。
o If the 'alg' field is present, it MUST match the ECDSA signature algorithm being used.
o 如果存在“alg”字段，则它必须与正在使用的ECDSA签名算法匹配。
o If the 'key_ops' field is present, it MUST include 'sign' when creating an ECDSA signature.
o 如果存在“密钥操作”字段，则在创建ECDSA签名时必须包含“签名”。
o If the 'key_ops' field is present, it MUST include 'verify' when verifying an ECDSA signature.
o 如果存在“密钥操作”字段，则在验证ECDSA签名时必须包含“验证”。
The security strength of the signature is no greater than the minimum of the security strength associated with the bit length of the key and the security strength of the hash function.
签名的安全强度不大于与密钥的位长度相关联的安全强度和哈希函数的安全强度中的最小值。
Note: Use of this technique is a good idea even when good random number generation exists. Doing so both reduces the possibility of having the same value of 'k' in two signature operations and allows for reproducible signature values, which helps testing.
注：即使存在良好的随机数生成，使用此技术也是一个好主意。这样做既减少了在两个签名操作中具有相同“k”值的可能性，又允许再现签名值，这有助于测试。
There are two substitution attacks that can theoretically be mounted against the ECDSA signature algorithm.
有两种替换攻击理论上可以针对ECDSA签名算法进行攻击。
o Changing the curve used to validate the signature: If one changes the curve used to validate the signature, then potentially one could have two messages with the same signature, each computed under a different curve. The only requirement on the new curve is that its order be the same as the old one and it be acceptable to the client. An example would be to change from using the curve secp256r1 (aka P-256) to using secp256k1. (Both are 256-bit curves.) We currently do not have any way to deal with this version of the attack except to restrict the overall set of curves that can be used.
o 更改用于验证签名的曲线：如果更改用于验证签名的曲线，则可能会有两条具有相同签名的消息，每条消息在不同的曲线下计算。新曲线的唯一要求是其顺序与旧曲线相同，且客户可接受。例如，从使用曲线secp256r1（又名P-256）改为使用secp256k1。（两个都是256位曲线。）我们目前没有任何方法来处理这个版本的攻击，除了限制可以使用的整个曲线集。
o Change the hash function used to validate the signature: If one either has two different hash functions of the same length or can truncate a hash function down, then one could potentially find collisions between the hash functions rather than within a single hash function (for example, truncating SHA-512 to 256 bits might collide with a SHA-256 bit hash value). As the hash algorithm is part of the signature algorithm identifier, this attack is mitigated by including a signature algorithm identifier in the protected header.
o 更改用于验证签名的哈希函数：如果其中一个具有相同长度的两个不同哈希函数，或者可以向下截断哈希函数，则可能会发现哈希函数之间的冲突，而不是单个哈希函数内的冲突（例如，将SHA-512截断为256位可能会与SHA-256位哈希值发生冲突）。由于哈希算法是签名算法标识符的一部分，因此可通过在受保护的标头中包含签名算法标识符来缓解此攻击。
[RFC8032] describes the elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). In that document, the signature algorithm is instantiated using parameters for edwards25519 and edwards448 curves. The document additionally describes two variants of the EdDSA algorithm: Pure EdDSA, where no hash function is applied to the content before signing, and HashEdDSA, where a hash function is applied to the content before signing and the result of that hash function is signed. For EdDSA, the content to be signed (either the
[RFC8032]描述了椭圆曲线签名方案爱德华兹曲线数字签名算法（EdDSA）。在该文档中，使用edwards25519和edwards448曲线的参数实例化了签名算法。本文档还描述了EdDSA算法的两种变体：纯EdDSA，其中签名前未对内容应用哈希函数；以及HashEdDSA，其中签名前对内容应用哈希函数，并对该哈希函数的结果进行签名。对于EdDSA，要签名的内容（或
message or the pre-hash value) is processed twice inside of the signature algorithm. For use with COSE, only the pure EdDSA version is used. This is because it is not expected that extremely large contents are going to be needed and, based on the arrangement of the message structure, the entire message is going to need to be held in memory in order to create or verify a signature. This means that there does not appear to be a need to be able to do block updates of the hash, followed by eliminating the message from memory. Applications can provide the same features by defining the content of the message as a hash value and transporting the COSE object (with the hash value) and the content as separate items.
消息（或预哈希值）在签名算法内处理两次。对于COSE，仅使用纯EdDSA版本。这是因为预计不需要非常大的内容，并且根据消息结构的安排，需要将整个消息保存在内存中以创建或验证签名。这意味着似乎不需要对哈希进行块更新，然后从内存中删除消息。应用程序可以通过将消息的内容定义为散列值并将COSE对象（具有散列值）和内容作为单独的项传输来提供相同的功能。
The algorithms defined in this document can be found in Table 6. A single signature algorithm is defined, which can be used for multiple curves.
本文件中定义的算法见表6。定义了一种可用于多条曲线的单一签名算法。
+-------+-------+-------------+
| Name | Value | Description |
+-------+-------+-------------+
| EdDSA | -8 | EdDSA |
+-------+-------+-------------+
+-------+-------+-------------+
| Name | Value | Description |
+-------+-------+-------------+
| EdDSA | -8 | EdDSA |
+-------+-------+-------------+
Table 6: EdDSA Algorithm Values
表6:EdDSA算法值
[RFC8032] describes the method of encoding the signature value.
[RFC8032]描述了对签名值进行编码的方法。
When using a COSE key for this algorithm, the following checks are made:
使用此算法的COSE密钥时，将进行以下检查：
o The 'kty' field MUST be present, and it MUST be 'OKP' (Octet Key Pair).
o “kty”字段必须存在，并且必须是“OKP”（八位字节密钥对）。
o The 'crv' field MUST be present, and it MUST be a curve defined for this signature algorithm.
o “crv”字段必须存在，并且必须是为此签名算法定义的曲线。
o If the 'alg' field is present, it MUST match 'EdDSA'.
o 如果存在“alg”字段，则它必须与“EdDSA”匹配。
o If the 'key_ops' field is present, it MUST include 'sign' when creating an EdDSA signature.
o 如果存在“密钥操作”字段，则在创建EdDSA签名时必须包含“签名”。
o If the 'key_ops' field is present, it MUST include 'verify' when verifying an EdDSA signature.
o 如果存在“密钥操作”字段，则在验证EdDSA签名时必须包含“验证”。
How public values are computed is not the same when looking at EdDSA and Elliptic Curve Diffie-Hellman (ECDH); for this reason, they should not be used with the other algorithm.
当考虑EdDSA和椭圆曲线Diffie-Hellman（ECDH）时，公共值的计算方式不同；因此，它们不应与其他算法一起使用。
If batch signature verification is performed, a well-seeded cryptographic random number generator is REQUIRED. Signing and non-batch signature verification are deterministic operations and do not need random numbers of any kind.
如果执行批签名验证，则需要一个种子良好的加密随机数生成器。签名和非批量签名验证是确定性操作，不需要任何类型的随机数。
Message Authentication Codes (MACs) provide data authentication and integrity protection. They provide either no or very limited data origination. A MAC, for example, can be used to prove the identity of the sender to a third party.
消息身份验证码（MAC）提供数据身份验证和完整性保护。它们提供的数据来源要么没有，要么非常有限。例如，MAC可以用来向第三方证明发送者的身份。
MACs use the same scheme as signature with appendix algorithms. The message content is processed and an authentication code is produced. The authentication code is frequently called a tag.
MAC使用与附录算法签名相同的方案。处理消息内容并生成身份验证代码。身份验证代码通常称为标记。
The MAC functions are:
MAC功能包括：
tag = MAC_Create(message content, key)
tag=MAC_Create（消息内容、密钥）
valid = MAC_Verify(message content, key, tag)
valid=MAC\u验证（消息内容、密钥、标记）
MAC algorithms can be based on either a block cipher algorithm (i.e., AES-MAC) or a hash algorithm (i.e., a Hash-based Message Authentication Code (HMAC)). This document defines a MAC algorithm using each of these constructions.
MAC算法可以基于分组密码算法（即AES-MAC）或散列算法（即基于散列的消息认证码（HMAC））。本文档定义了使用这些结构的MAC算法。
MAC algorithms are used in the COSE_Mac and COSE_Mac0 structures.
MAC算法用于COSE_MAC和COSE_Mac0结构。
HMAC [RFC2104] [RFC4231] was designed to deal with length extension attacks. The algorithm was also designed to allow for new hash algorithms to be directly plugged in without changes to the hash function. The HMAC design process has been shown as solid since, while the security of hash algorithms such as MD5 has decreased over time; the security of HMAC combined with MD5 has not yet been shown to be compromised [RFC6151].
HMAC[RFC2104][RFC4231]设计用于处理长度扩展攻击。该算法的设计还允许直接插入新的哈希算法，而无需更改哈希函数。HMAC的设计过程从那时起就被证明是可靠的，而散列算法（如MD5）的安全性随着时间的推移而降低；HMAC结合MD5的安全性尚未被证明受到损害[RFC6151]。
The HMAC algorithm is parameterized by an inner and outer padding, a hash function (h), and an authentication tag value length. For this specification, the inner and outer padding are fixed to the values set in [RFC2104]. The length of the authentication tag corresponds to the difficulty of producing a forgery. For use in constrained environments, we define a set of HMAC algorithms that are truncated.
HMAC算法由内部和外部填充、哈希函数（h）和身份验证标记值长度参数化。对于本规范，内部和外部填充固定为[RFC2104]中设置的值。认证标签的长度对应于产生伪造的难度。为了在受限环境中使用，我们定义了一组被截断的HMAC算法。
There are currently no known issues with truncation; however, the security strength of the message tag is correspondingly reduced in strength. When truncating, the leftmost tag length bits are kept and transmitted.
目前没有已知的截断问题；然而，消息标签的安全强度相应地降低。截断时，保留并传输最左边的标记长度位。
The algorithms defined in this document can be found in Table 7.
本文件中定义的算法见表7。
+-----------+-------+---------+----------+--------------------------+
| Name | Value | Hash | Tag | Description |
| | | | Length | |
+-----------+-------+---------+----------+--------------------------+
| HMAC | 4 | SHA-256 | 64 | HMAC w/ SHA-256 |
| 256/64 | | | | truncated to 64 bits |
| HMAC | 5 | SHA-256 | 256 | HMAC w/ SHA-256 |
| 256/256 | | | | |
| HMAC | 6 | SHA-384 | 384 | HMAC w/ SHA-384 |
| 384/384 | | | | |
| HMAC | 7 | SHA-512 | 512 | HMAC w/ SHA-512 |
| 512/512 | | | | |
+-----------+-------+---------+----------+--------------------------+
+-----------+-------+---------+----------+--------------------------+
| Name | Value | Hash | Tag | Description |
| | | | Length | |
+-----------+-------+---------+----------+--------------------------+
| HMAC | 4 | SHA-256 | 64 | HMAC w/ SHA-256 |
| 256/64 | | | | truncated to 64 bits |
| HMAC | 5 | SHA-256 | 256 | HMAC w/ SHA-256 |
| 256/256 | | | | |
| HMAC | 6 | SHA-384 | 384 | HMAC w/ SHA-384 |
| 384/384 | | | | |
| HMAC | 7 | SHA-512 | 512 | HMAC w/ SHA-512 |
| 512/512 | | | | |
+-----------+-------+---------+----------+--------------------------+
Table 7: HMAC Algorithm Values
表7:HMAC算法值
Some recipient algorithms carry the key while others derive a key from secret data. For those algorithms that carry the key (such as AES Key Wrap), the size of the HMAC key SHOULD be the same size as the underlying hash function. For those algorithms that derive the key (such as ECDH), the derived key MUST be the same size as the underlying hash function.
一些接收方算法携带密钥，而另一些则从秘密数据中派生密钥。对于那些携带密钥的算法（如AES密钥包裹），HMAC密钥的大小应该与基础哈希函数的大小相同。对于派生密钥的算法（如ECDH），派生密钥的大小必须与基础哈希函数的大小相同。
When using a COSE key for this algorithm, the following checks are made:
使用此算法的COSE密钥时，将进行以下检查：
o The 'kty' field MUST be present, and it MUST be 'Symmetric'.
o “kty”字段必须存在，并且必须是“对称”字段。
o If the 'alg' field is present, it MUST match the HMAC algorithm being used.
o 如果存在“alg”字段，则它必须与正在使用的HMAC算法匹配。
o If the 'key_ops' field is present, it MUST include 'MAC create' when creating an HMAC authentication tag.
o 如果存在“key_ops”字段，则在创建HMAC身份验证标签时，该字段必须包含“MAC create”。
o If the 'key_ops' field is present, it MUST include 'MAC verify' when verifying an HMAC authentication tag.
o 如果存在“key_ops”字段，则在验证HMAC身份验证标签时必须包含“MAC验证”。
Implementations creating and validating MAC values MUST validate that the key type, key length, and algorithm are correct and appropriate for the entities involved.
创建和验证MAC值的实现必须验证密钥类型、密钥长度和算法是否正确且适合所涉及的实体。
HMAC has proved to be resistant to attack even when used with weakened hash algorithms. The current best known attack is to brute force the key. This means that key size is going to be directly related to the security of an HMAC operation.
HMAC已证明即使与弱化的哈希算法一起使用，也能抵抗攻击。目前最著名的攻击是暴力破解钥匙。这意味着密钥大小将直接关系到HMAC操作的安全性。
AES-CBC-MAC is defined in [MAC]. (Note that this is not the same algorithm as AES Cipher-Based Message Authentication Code (AES-CMAC) [RFC4493].)
AES-CBC-MAC在[MAC]中定义。（注意，这与基于AES密码的消息认证码（AES-CMAC）[RFC4493]的算法不同。）
AES-CBC-MAC is parameterized by the key length, the authentication tag length, and the IV used. For all of these algorithms, the IV is fixed to all zeros. We provide an array of algorithms for various key lengths and tag lengths. The algorithms defined in this document are found in Table 8.
AES-CBC-MAC由密钥长度、认证标签长度和使用的IV参数化。对于所有这些算法，IV都固定为全零。我们为不同的密钥长度和标记长度提供了一系列算法。本文件中定义的算法见表8。
+-------------+-------+----------+----------+-----------------------+
| Name | Value | Key | Tag | Description |
| | | Length | Length | |
+-------------+-------+----------+----------+-----------------------+
| AES-MAC | 14 | 128 | 64 | AES-MAC 128-bit key, |
| 128/64 | | | | 64-bit tag |
| AES-MAC | 15 | 256 | 64 | AES-MAC 256-bit key, |
| 256/64 | | | | 64-bit tag |
| AES-MAC | 25 | 128 | 128 | AES-MAC 128-bit key, |
| 128/128 | | | | 128-bit tag |
| AES-MAC | 26 | 256 | 128 | AES-MAC 256-bit key, |
| 256/128 | | | | 128-bit tag |
+-------------+-------+----------+----------+-----------------------+
+-------------+-------+----------+----------+-----------------------+
| Name | Value | Key | Tag | Description |
| | | Length | Length | |
+-------------+-------+----------+----------+-----------------------+
| AES-MAC | 14 | 128 | 64 | AES-MAC 128-bit key, |
| 128/64 | | | | 64-bit tag |
| AES-MAC | 15 | 256 | 64 | AES-MAC 256-bit key, |
| 256/64 | | | | 64-bit tag |
| AES-MAC | 25 | 128 | 128 | AES-MAC 128-bit key, |
| 128/128 | | | | 128-bit tag |
| AES-MAC | 26 | 256 | 128 | AES-MAC 256-bit key, |
| 256/128 | | | | 128-bit tag |
+-------------+-------+----------+----------+-----------------------+
Table 8: AES-MAC Algorithm Values
表8:AES-MAC算法值
Keys may be obtained either from a key structure or from a recipient structure. Implementations creating and validating MAC values MUST validate that the key type, key length, and algorithm are correct and appropriate for the entities involved.
密钥可以从密钥结构或从接收方结构获得。创建和验证MAC值的实现必须验证密钥类型、密钥长度和算法是否正确且适合所涉及的实体。
When using a COSE key for this algorithm, the following checks are made:
使用此算法的COSE密钥时，将进行以下检查：
o The 'kty' field MUST be present, and it MUST be 'Symmetric'.
o “kty”字段必须存在，并且必须是“对称”字段。
o If the 'alg' field is present, it MUST match the AES-MAC algorithm being used.
o 如果存在“alg”字段，则它必须与正在使用的AES-MAC算法匹配。
o If the 'key_ops' field is present, it MUST include 'MAC create' when creating an AES-MAC authentication tag.
o 如果存在“key_ops”字段，则在创建AES-MAC身份验证标签时，该字段必须包含“MAC创建”。
o If the 'key_ops' field is present, it MUST include 'MAC verify' when verifying an AES-MAC authentication tag.
o 如果存在“key_ops”字段，则在验证AES-MAC身份验证标签时必须包含“MAC验证”。
A number of attacks exist against Cipher Block Chaining Message Authentication Code (CBC-MAC) that need to be considered.
存在许多针对密码块链接消息身份验证码（CBC-MAC）的攻击，需要加以考虑。
o A single key must only be used for messages of a fixed and known length. If this is not the case, an attacker will be able to generate a message with a valid tag given two message and tag pairs. This can be addressed by using different keys for messages of different lengths. The current structure mitigates this problem, as a specific encoding structure that includes lengths is built and signed. (CMAC also addresses this issue.)
o 单个密钥只能用于固定长度和已知长度的消息。如果不是这样，攻击者将能够在给定两个消息和标记对的情况下生成具有有效标记的消息。这可以通过对不同长度的消息使用不同的键来解决。当前的结构缓解了这个问题，因为构建了包含长度的特定编码结构并对其进行了签名。（CMAC也解决了这个问题。）
o Cipher Block Chaining (CBC) mode, if the same key is used for both encryption and authentication operations, an attacker can produce messages with a valid authentication code.
o 密码块链接（CBC）模式，如果加密和身份验证操作使用相同的密钥，攻击者可以生成具有有效身份验证代码的消息。
o If the IV can be modified, then messages can be forged. This is addressed by fixing the IV to all zeros.
o 如果可以修改IV，则可以伪造消息。这是通过将IV固定为全零来解决的。
Content encryption algorithms provide data confidentiality for potentially large blocks of data using a symmetric key. They provide integrity on the data that was encrypted; however, they provide either no or very limited data origination. (One cannot, for example, be used to prove the identity of the sender to a third party.) The ability to provide data origination is linked to how the CEK is obtained.
内容加密算法使用对称密钥为可能较大的数据块提供数据机密性。它们提供加密数据的完整性；然而，它们提供的数据来源要么没有，要么非常有限。（例如，不能用一个人向第三方证明发送者的身份。）提供数据来源的能力与如何获得CEK有关。
COSE restricts the set of legal content encryption algorithms to those that support authentication both of the content and additional data. The encryption process will generate some type of authentication value, but that value may be either explicit or implicit in terms of the algorithm definition. For simplicity's sake, the authentication code will normally be defined as being appended to the ciphertext stream. The encryption functions are:
COSE将一组合法的内容加密算法限制为支持内容和附加数据认证的算法。加密过程将生成某种类型的身份验证值，但根据算法定义，该值可能是显式的或隐式的。为了简单起见，身份验证代码通常被定义为附加到密文流中。加密功能包括：
ciphertext = Encrypt(message content, key, additional data)
密文=加密（消息内容、密钥、附加数据）
valid, message content = Decrypt(cipher text, key, additional data)
有效，消息内容=解密（密文、密钥、附加数据）
Most AEAD algorithms are logically defined as returning the message content only if the decryption is valid. Many but not all
大多数AEAD算法在逻辑上定义为仅当解密有效时才返回消息内容。很多，但不是全部
implementations will follow this convention. The message content MUST NOT be used if the decryption does not validate.
实现将遵循此约定。如果解密未验证，则不得使用消息内容。
These algorithms are used in COSE_Encrypt and COSE_Encrypt0.
这些算法用于COSE_Encrypt和COSE_Encrypt0。
The Galois/Counter Mode (GCM) mode is a generic authenticated encryption block cipher mode defined in [AES-GCM]. The GCM mode is combined with the AES block encryption algorithm to define an AEAD cipher.
Galois/计数器模式（GCM）是[AES-GCM]中定义的通用认证加密分组密码模式。GCM模式与AES块加密算法相结合，以定义AEAD密码。
The GCM mode is parameterized by the size of the authentication tag and the size of the nonce. This document fixes the size of the nonce at 96 bits. The size of the authentication tag is limited to a small set of values. For this document however, the size of the authentication tag is fixed at 128 bits.
GCM模式由身份验证标记的大小和nonce的大小参数化。本文档将nonce的大小固定为96位。身份验证标记的大小仅限于一小组值。但是，对于本文档，身份验证标记的大小固定为128位。
The set of algorithms defined in this document are in Table 9.
本文件中定义的算法集如表9所示。
+---------+-------+------------------------------------------+
| Name | Value | Description |
+---------+-------+------------------------------------------+
| A128GCM | 1 | AES-GCM mode w/ 128-bit key, 128-bit tag |
| A192GCM | 2 | AES-GCM mode w/ 192-bit key, 128-bit tag |
| A256GCM | 3 | AES-GCM mode w/ 256-bit key, 128-bit tag |
+---------+-------+------------------------------------------+
+---------+-------+------------------------------------------+
| Name | Value | Description |
+---------+-------+------------------------------------------+
| A128GCM | 1 | AES-GCM mode w/ 128-bit key, 128-bit tag |
| A192GCM | 2 | AES-GCM mode w/ 192-bit key, 128-bit tag |
| A256GCM | 3 | AES-GCM mode w/ 256-bit key, 128-bit tag |
+---------+-------+------------------------------------------+
Table 9: Algorithm Value for AES-GCM
表9:AES-GCM的算法值
Keys may be obtained either from a key structure or from a recipient structure. Implementations encrypting and decrypting MUST validate that the key type, key length, and algorithm are correct and appropriate for the entities involved.
密钥可以从密钥结构或从接收方结构获得。加密和解密的实现必须验证密钥类型、密钥长度和算法是否正确，是否适合所涉及的实体。
When using a COSE key for this algorithm, the following checks are made:
使用此算法的COSE密钥时，将进行以下检查：
o The 'kty' field MUST be present, and it MUST be 'Symmetric'.
o “kty”字段必须存在，并且必须是“对称”字段。
o If the 'alg' field is present, it MUST match the AES-GCM algorithm being used.
o 如果存在“alg”字段，则它必须与正在使用的AES-GCM算法匹配。
o If the 'key_ops' field is present, it MUST include 'encrypt' or 'wrap key' when encrypting.
o 如果存在“key_ops”字段，则在加密时必须包含“encrypt”或“wrap key”。
o If the 'key_ops' field is present, it MUST include 'decrypt' or 'unwrap key' when decrypting.
o 如果存在“密钥操作”字段，则在解密时必须包含“解密”或“解开密钥”。
When using AES-GCM, the following restrictions MUST be enforced:
使用AES-GCM时，必须执行以下限制：
o The key and nonce pair MUST be unique for every message encrypted.
o 对于每个加密的消息，密钥和nonce对必须是唯一的。
o The total amount of data encrypted for a single key MUST NOT exceed 2^39 - 256 bits. An explicit check is required only in environments where it is expected that it might be exceeded.
o 为单个密钥加密的数据总量不得超过2^39-256位。只有在预期可能超过显式检查的环境中，才需要显式检查。
Consideration was given to supporting smaller tag values; the constrained community would desire tag sizes in the 64-bit range. Doing so drastically changes both the maximum messages size (generally not an issue) and the number of times that a key can be used. Given that Counter with CBC-MAC (CCM) is the usual mode for constrained environments, restricted modes are not supported.
考虑支持较小的标签值；受限社区希望标签大小在64位范围内。这样做会极大地改变最大消息大小（通常不是问题）和密钥可使用的次数。鉴于带CBC-MAC（CCM）的计数器是受限环境的常用模式，因此不支持受限模式。
CCM is a generic authentication encryption block cipher mode defined in [RFC3610]. The CCM mode is combined with the AES block encryption algorithm to define a commonly used content encryption algorithm used in constrained devices.
CCM是[RFC3610]中定义的通用身份验证加密分组密码模式。CCM模式与AES块加密算法相结合，以定义在受限设备中使用的常用内容加密算法。
The CCM mode has two parameter choices. The first choice is M, the size of the authentication field. The choice of the value for M involves a trade-off between message growth (from the tag) and the probability that an attacker can undetectably modify a message. The second choice is L, the size of the length field. This value requires a trade-off between the maximum message size and the size of the Nonce.
CCM模式有两个参数选择。第一个选择是M，身份验证字段的大小。M值的选择涉及到消息增长（来自标记）和攻击者无法检测到修改消息的可能性之间的权衡。第二个选择是L，长度字段的大小。此值需要在最大消息大小和Nonce大小之间进行权衡。
It is unfortunate that the specification for CCM specified L and M as a count of bytes rather than a count of bits. This leads to possible misunderstandings where AES-CCM-8 is frequently used to refer to a version of CCM mode where the size of the authentication is 64 bits and not 8 bits. These values have traditionally been specified as bit counts rather than byte counts. This document will follow the convention of using bit counts so that it is easier to compare the different algorithms presented in this document.
不幸的是，CCM规范将L和M指定为字节计数，而不是位计数。这导致可能的误解，其中AES-CCM-8经常用于指认证大小为64位而非8位的CCM模式版本。这些值传统上被指定为位计数，而不是字节计数。本文档将遵循使用位计数的惯例，以便更容易比较本文档中介绍的不同算法。
We define a matrix of algorithms in this document over the values of L and M. Constrained devices are usually operating in situations where they use short messages and want to avoid doing recipient-specific cryptographic operations. This favors smaller values of
我们在本文档中定义了一个基于L和M值的算法矩阵。受约束的设备通常在使用短消息的情况下运行，并且希望避免执行特定于收件人的加密操作。这有利于较小的
both L and M. Less-constrained devices will want to be able to use larger messages and are more willing to generate new keys for every operation. This favors larger values of L and M.
L和M。约束较少的设备都希望能够使用更大的消息，并且更愿意为每个操作生成新密钥。这有利于L和M的较大值。
The following values are used for L:
以下值用于L：
16 bits (2): This limits messages to 2^16 bytes (64 KiB) in length. This is sufficiently long for messages in the constrained world. The nonce length is 13 bytes allowing for 2^(13*8) possible values of the nonce without repeating.
16位（2）：这将消息长度限制为2^16字节（64千字节）。这对于受限世界中的消息来说已经足够长了。nonce长度为13字节，允许2^（13*8）个可能的nonce值，而无需重复。
64 bits (8): This limits messages to 2^64 bytes in length. The nonce length is 7 bytes allowing for 2^56 possible values of the nonce without repeating.
64位（8）：这将消息长度限制为2^64字节。nonce长度为7字节，允许2^56个可能的nonce值，而无需重复。
The following values are used for M:
以下值用于M：
64 bits (8): This produces a 64-bit authentication tag. This implies that there is a 1 in 2^64 chance that a modified message will authenticate.
64位（8）：这将生成64位身份验证标记。这意味着修改后的邮件进行身份验证的概率为1/2^64。
128 bits (16): This produces a 128-bit authentication tag. This implies that there is a 1 in 2^128 chance that a modified message will authenticate.
128位（16）：这将生成128位身份验证标记。这意味着修改后的消息进行身份验证的可能性为1/2^128。
+--------------------+-------+----+-----+-----+---------------------+
| Name | Value | L | M | k | Description |
+--------------------+-------+----+-----+-----+---------------------+
| AES-CCM-16-64-128 | 10 | 16 | 64 | 128 | AES-CCM mode |
| | | | | | 128-bit key, 64-bit |
| | | | | | tag, 13-byte nonce |
| AES-CCM-16-64-256 | 11 | 16 | 64 | 256 | AES-CCM mode |
| | | | | | 256-bit key, 64-bit |
| | | | | | tag, 13-byte nonce |
| AES-CCM-64-64-128 | 12 | 64 | 64 | 128 | AES-CCM mode |
| | | | | | 128-bit key, 64-bit |
| | | | | | tag, 7-byte nonce |
| AES-CCM-64-64-256 | 13 | 64 | 64 | 256 | AES-CCM mode |
| | | | | | 256-bit key, 64-bit |
| | | | | | tag, 7-byte nonce |
| AES-CCM-16-128-128 | 30 | 16 | 128 | 128 | AES-CCM mode |
| | | | | | 128-bit key, |
| | | | | | 128-bit tag, |
| | | | | | 13-byte nonce |
| AES-CCM-16-128-256 | 31 | 16 | 128 | 256 | AES-CCM mode |
| | | | | | 256-bit key, |
| | | | | | 128-bit tag, |
| | | | | | 13-byte nonce |
| AES-CCM-64-128-128 | 32 | 64 | 128 | 128 | AES-CCM mode |
| | | | | | 128-bit key, |
| | | | | | 128-bit tag, 7-byte |
| | | | | | nonce |
| AES-CCM-64-128-256 | 33 | 64 | 128 | 256 | AES-CCM mode |
| | | | | | 256-bit key, |
| | | | | | 128-bit tag, 7-byte |
| | | | | | nonce |
+--------------------+-------+----+-----+-----+---------------------+
+--------------------+-------+----+-----+-----+---------------------+
| Name | Value | L | M | k | Description |
+--------------------+-------+----+-----+-----+---------------------+
| AES-CCM-16-64-128 | 10 | 16 | 64 | 128 | AES-CCM mode |
| | | | | | 128-bit key, 64-bit |
| | | | | | tag, 13-byte nonce |
| AES-CCM-16-64-256 | 11 | 16 | 64 | 256 | AES-CCM mode |
| | | | | | 256-bit key, 64-bit |
| | | | | | tag, 13-byte nonce |
| AES-CCM-64-64-128 | 12 | 64 | 64 | 128 | AES-CCM mode |
| | | | | | 128-bit key, 64-bit |
| | | | | | tag, 7-byte nonce |
| AES-CCM-64-64-256 | 13 | 64 | 64 | 256 | AES-CCM mode |
| | | | | | 256-bit key, 64-bit |
| | | | | | tag, 7-byte nonce |
| AES-CCM-16-128-128 | 30 | 16 | 128 | 128 | AES-CCM mode |
| | | | | | 128-bit key, |
| | | | | | 128-bit tag, |
| | | | | | 13-byte nonce |
| AES-CCM-16-128-256 | 31 | 16 | 128 | 256 | AES-CCM mode |
| | | | | | 256-bit key, |
| | | | | | 128-bit tag, |
| | | | | | 13-byte nonce |
| AES-CCM-64-128-128 | 32 | 64 | 128 | 128 | AES-CCM mode |
| | | | | | 128-bit key, |
| | | | | | 128-bit tag, 7-byte |
| | | | | | nonce |
| AES-CCM-64-128-256 | 33 | 64 | 128 | 256 | AES-CCM mode |
| | | | | | 256-bit key, |
| | | | | | 128-bit tag, 7-byte |
| | | | | | nonce |
+--------------------+-------+----+-----+-----+---------------------+
Table 10: Algorithm Values for AES-CCM
表10:AES-CCM的算法值
Keys may be obtained either from a key structure or from a recipient structure. Implementations encrypting and decrypting MUST validate that the key type, key length, and algorithm are correct and appropriate for the entities involved.
密钥可以从密钥结构或从接收方结构获得。加密和解密的实现必须验证密钥类型、密钥长度和算法是否正确，是否适合所涉及的实体。
When using a COSE key for this algorithm, the following checks are made:
使用此算法的COSE密钥时，将进行以下检查：
o The 'kty' field MUST be present, and it MUST be 'Symmetric'.
o “kty”字段必须存在，并且必须是“对称”字段。
o If the 'alg' field is present, it MUST match the AES-CCM algorithm being used.
o 如果存在“alg”字段，则它必须与正在使用的AES-CCM算法匹配。
o If the 'key_ops' field is present, it MUST include 'encrypt' or 'wrap key' when encrypting.
o 如果存在“key_ops”字段，则在加密时必须包含“encrypt”或“wrap key”。
o If the 'key_ops' field is present, it MUST include 'decrypt' or 'unwrap key' when decrypting.
o 如果存在“密钥操作”字段，则在解密时必须包含“解密”或“解开密钥”。
When using AES-CCM, the following restrictions MUST be enforced:
使用AES-CCM时，必须执行以下限制：
o The key and nonce pair MUST be unique for every message encrypted. Note that the value of L influences the number of unique nonces.
o 对于每个加密的消息，密钥和nonce对必须是唯一的。请注意，L的值会影响唯一nonce的数量。
o The total number of times the AES block cipher is used MUST NOT exceed 2^61 operations. This limitation is the sum of times the block cipher is used in computing the MAC value and in performing stream encryption operations. An explicit check is required only in environments where it is expected that it might be exceeded.
o 使用AES分组密码的总次数不得超过2^61次操作。此限制是分组密码用于计算MAC值和执行流加密操作的次数之和。只有在预期可能超过显式检查的环境中，才需要显式检查。
[RFC3610] additionally calls out one other consideration of note. It is possible to do a pre-computation attack against the algorithm in cases where portions of the plaintext are highly predictable. This reduces the security of the key size by half. Ways to deal with this attack include adding a random portion to the nonce value and/or increasing the key size used. Using a portion of the nonce for a random value will decrease the number of messages that a single key can be used for. Increasing the key size may require more resources in the constrained device. See Sections 5 and 10 of [RFC3610] for more information.
[RFC3610]还提出了另一个值得注意的问题。在纯文本部分高度可预测的情况下，可以对算法进行计算前攻击。这将密钥大小的安全性降低一半。处理此攻击的方法包括向nonce值添加随机部分和/或增加使用的密钥大小。将一部分nonce用作随机值将减少单个键可用于的消息数。增加密钥大小可能需要受约束设备中的更多资源。更多信息，请参见[RFC3610]第5节和第10节。
ChaCha20 and Poly1305 combined together is an AEAD mode that is defined in [RFC7539]. This is an algorithm defined to be a cipher that is not AES and thus would not suffer from any future weaknesses found in AES. These cryptographic functions are designed to be fast in software-only implementations.
ChaCha20和Poly1305组合在一起是[RFC7539]中定义的AEAD模式。这是一种定义为非AES密码的算法，因此不会受到AES中发现的任何未来弱点的影响。这些加密功能在仅软件实现中设计得非常快速。
The ChaCha20/Poly1305 AEAD construction defined in [RFC7539] has no parameterization. It takes a 256-bit key and a 96-bit nonce, as well as the plaintext and additional data as inputs and produces the ciphertext as an option. We define one algorithm identifier for this algorithm in Table 11.
[RFC7539]中定义的ChaCha20/Poly1305 AEAD构造没有参数化。它采用256位密钥和96位nonce，以及明文和附加数据作为输入，并生成密文作为选项。我们在表11中为该算法定义了一个算法标识符。
+-------------------+-------+---------------------------------------+
| Name | Value | Description |
+-------------------+-------+---------------------------------------+
| ChaCha20/Poly1305 | 24 | ChaCha20/Poly1305 w/ 256-bit key, |
| | | 128-bit tag |
+-------------------+-------+---------------------------------------+
+-------------------+-------+---------------------------------------+
| Name | Value | Description |
+-------------------+-------+---------------------------------------+
| ChaCha20/Poly1305 | 24 | ChaCha20/Poly1305 w/ 256-bit key, |
| | | 128-bit tag |
+-------------------+-------+---------------------------------------+
Table 11: Algorithm Value for AES-GCM
表11:AES-GCM的算法值
Keys may be obtained either from a key structure or from a recipient structure. Implementations encrypting and decrypting MUST validate that the key type, key length, and algorithm are correct and appropriate for the entities involved.
密钥可以从密钥结构或从接收方结构获得。加密和解密的实现必须验证密钥类型、密钥长度和算法是否正确，是否适合所涉及的实体。
When using a COSE key for this algorithm, the following checks are made:
使用此算法的COSE密钥时，将进行以下检查：
o The 'kty' field MUST be present, and it MUST be 'Symmetric'.
o “kty”字段必须存在，并且必须是“对称”字段。
o If the 'alg' field is present, it MUST match the ChaCha20/Poly1305 algorithm being used.
o 如果存在“alg”字段，则它必须与正在使用的ChaCha20/Poly1305算法相匹配。
o If the 'key_ops' field is present, it MUST include 'encrypt' or 'wrap key' when encrypting.
o 如果存在“key_ops”字段，则在加密时必须包含“encrypt”或“wrap key”。
o If the 'key_ops' field is present, it MUST include 'decrypt' or 'unwrap key' when decrypting.
o 如果存在“密钥操作”字段，则在解密时必须包含“解密”或“解开密钥”。
The key and nonce values MUST be a unique pair for every invocation of the algorithm. Nonce counters are considered to be an acceptable way of ensuring that they are unique.
对于算法的每次调用，key和nonce值必须是唯一的一对。临时计数器被认为是确保其唯一性的可接受方式。
KDFs are used to take some secret value and generate a different one. The secret value comes in three flavors:
KDF用于获取一些秘密值并生成不同的值。秘密值有三种类型：
o Secrets that are uniformly random: This is the type of secret that is created by a good random number generator.
o 一致随机的秘密：这是由一个好的随机数生成器创建的秘密类型。
o Secrets that are not uniformly random: This is type of secret that is created by operations like key agreement.
o 非均匀随机的秘密：这是一种由密钥协商等操作创建的秘密。
o Secrets that are not random: This is the type of secret that people generate for things like passwords.
o 非随机秘密：这是人们为密码之类的东西生成的秘密类型。
General KDFs work well with the first type of secret, can do reasonably well with the second type of secret, and generally do poorly with the last type of secret. None of the KDFs in this section are designed to deal with the type of secrets that are used for passwords. Functions like PBES2 [RFC8018] need to be used for that type of secret.
一般KDF可以很好地处理第一种类型的秘密，可以很好地处理第二种类型的秘密，但通常处理最后一种类型的秘密效果很差。本节中的KDF都不是为处理用于密码的机密类型而设计的。像PBES2[RFC8018]这样的函数需要用于该类型的机密。
The same KDF can be set up to deal with the first two types of secrets in a different way. The KDF defined in Section 11.1 is such a function. This is reflected in the set of algorithms defined for the HMAC-based Extract-and-Expand Key Derivation Function (HKDF).
可以设置相同的KDF，以不同的方式处理前两种类型的机密。第11.1节中定义的KDF就是这样一种功能。这反映在为基于HMAC的提取和扩展密钥派生函数（HKDF）定义的一组算法中。
When using KDFs, one component that is included is context information. Context information is used to allow for different keying information to be derived from the same secret. The use of context-based keying material is considered to be a good security practice.
使用KDFs时，包含的一个组件是上下文信息。上下文信息用于允许从同一机密中派生不同的密钥信息。使用基于上下文的键控材料被认为是一种良好的安全实践。
This document defines a single context structure and a single KDF. These elements are used for all of the recipient algorithms defined in this document that require a KDF process. These algorithms are defined in Sections 12.1.2, 12.4.1, and 12.5.1.
本文档定义了单个上下文结构和单个KDF。这些元素用于本文档中定义的所有需要KDF流程的收件人算法。第12.1.2节、第12.4.1节和第12.5.1节对这些算法进行了定义。
The HKDF key derivation algorithm is defined in [RFC5869].
[RFC5869]中定义了HKDF密钥推导算法。
The HKDF algorithm takes these inputs:
HKDF算法采用以下输入：
secret -- a shared value that is secret. Secrets may be either previously shared or derived from operations like a Diffie-Hellman (DH) key agreement.
秘密——一个秘密的共享值。秘密可以是先前共享的，也可以是从Diffie-Hellman（DH）密钥协议等操作中获得的。
salt -- an optional value that is used to change the generation process. The salt value can be either public or private. If the salt is public and carried in the message, then the 'salt' algorithm header parameter defined in Table 13 is used. While [RFC5869] suggests that the length of the salt be the same as the length of the underlying hash value, any amount of salt will improve the security as different key values will be generated. This parameter is protected by being included in the key computation and does not need to be separately authenticated. The salt value does not need to be unique for every message sent.
salt——用于更改生成过程的可选值。salt值可以是公共的，也可以是私有的。如果salt是公共的且在消息中携带，则使用表13中定义的“salt”算法头参数。虽然[RFC5869]建议salt的长度与基础哈希值的长度相同，但任何数量的salt都会提高安全性，因为会生成不同的键值。此参数通过包含在密钥计算中而受到保护，不需要单独进行身份验证。salt值不需要对发送的每条消息都是唯一的。
length -- the number of bytes of output that need to be generated.
长度——需要生成的输出字节数。
context information -- Information that describes the context in which the resulting value will be used. Making this information specific to the context in which the material is going to be used ensures that the resulting material will always be tied to that usage. The context structure defined in Section 11.2 is used by the KDFs in this document.
上下文信息——描述将在其中使用结果值的上下文的信息。将此信息特定于材料将要使用的上下文，可确保生成的材料始终与该用途相关联。本文件中的KDF使用第11.2节中定义的上下文结构。
PRF -- The underlying pseudorandom function to be used in the HKDF algorithm. The PRF is encoded into the HKDF algorithm selection.
PRF——HKDF算法中使用的基本伪随机函数。PRF编码到HKDF算法选择中。
HKDF is defined to use HMAC as the underlying PRF. However, it is possible to use other functions in the same construct to provide a different KDF that is more appropriate in the constrained world. Specifically, one can use AES-CBC-MAC as the PRF for the expand step, but not for the extract step. When using a good random shared secret of the correct length, the extract step can be skipped. For the AES algorithm versions, the extract step is always skipped.
HKDF定义为使用HMAC作为基础PRF。但是，可以在同一构造中使用其他函数来提供在受限世界中更合适的不同KDF。具体而言，可以使用AES-CBC-MAC作为扩展步骤的PRF，但不能用于提取步骤。当使用正确长度的好的随机共享秘密时，可以跳过提取步骤。对于AES算法版本，始终跳过提取步骤。
The extract step cannot be skipped if the secret is not uniformly random, for example, if it is the result of an ECDH key agreement step. This implies that the AES HKDF version cannot be used with ECDH. If the extract step is skipped, the 'salt' value is not used as part of the HKDF functionality.
如果秘密不是一致随机的，例如，如果它是ECDH密钥协商步骤的结果，则不能跳过提取步骤。这意味着AES HKDF版本不能与ECDH一起使用。如果跳过提取步骤，“salt”值不会用作HKDF功能的一部分。
The algorithms defined in this document are found in Table 12.
本文件中定义的算法见表12。
+---------------+-----------------+---------------------------------+
| Name | PRF | Description |
+---------------+-----------------+---------------------------------+
| HKDF SHA-256 | HMAC with | HKDF using HMAC SHA-256 as the |
| | SHA-256 | PRF |
| HKDF SHA-512 | HMAC with | HKDF using HMAC SHA-512 as the |
| | SHA-512 | PRF |
| HKDF AES- | AES-CBC-MAC-128 | HKDF using AES-MAC as the PRF |
| MAC-128 | | w/ 128-bit key |
| HKDF AES- | AES-CBC-MAC-256 | HKDF using AES-MAC as the PRF |
| MAC-256 | | w/ 256-bit key |
+---------------+-----------------+---------------------------------+
+---------------+-----------------+---------------------------------+
| Name | PRF | Description |
+---------------+-----------------+---------------------------------+
| HKDF SHA-256 | HMAC with | HKDF using HMAC SHA-256 as the |
| | SHA-256 | PRF |
| HKDF SHA-512 | HMAC with | HKDF using HMAC SHA-512 as the |
| | SHA-512 | PRF |
| HKDF AES- | AES-CBC-MAC-128 | HKDF using AES-MAC as the PRF |
| MAC-128 | | w/ 128-bit key |
| HKDF AES- | AES-CBC-MAC-256 | HKDF using AES-MAC as the PRF |
| MAC-256 | | w/ 256-bit key |
+---------------+-----------------+---------------------------------+
Table 12: HKDF Algorithms
表12:HKDF算法
+------+-------+------+-------------------------------+-------------+
| Name | Label | Type | Algorithm | Description |
+------+-------+------+-------------------------------+-------------+
| salt | -20 | bstr | direct+HKDF-SHA-256, direct | Random salt |
| | | | +HKDF-SHA-512, direct+HKDF- | |
| | | | AES-128, direct+HKDF-AES-256, | |
| | | | ECDH-ES+HKDF-256, ECDH- | |
| | | | ES+HKDF-512, ECDH- | |
| | | | SS+HKDF-256, ECDH- | |
| | | | SS+HKDF-512, ECDH-ES+A128KW, | |
| | | | ECDH-ES+A192KW, ECDH- | |
| | | | ES+A256KW, ECDH-SS+A128KW, | |
| | | | ECDH-SS+A192KW, ECDH- | |
| | | | SS+A256KW | |
+------+-------+------+-------------------------------+-------------+
+------+-------+------+-------------------------------+-------------+
| Name | Label | Type | Algorithm | Description |
+------+-------+------+-------------------------------+-------------+
| salt | -20 | bstr | direct+HKDF-SHA-256, direct | Random salt |
| | | | +HKDF-SHA-512, direct+HKDF- | |
| | | | AES-128, direct+HKDF-AES-256, | |
| | | | ECDH-ES+HKDF-256, ECDH- | |
| | | | ES+HKDF-512, ECDH- | |
| | | | SS+HKDF-256, ECDH- | |
| | | | SS+HKDF-512, ECDH-ES+A128KW, | |
| | | | ECDH-ES+A192KW, ECDH- | |
| | | | ES+A256KW, ECDH-SS+A128KW, | |
| | | | ECDH-SS+A192KW, ECDH- | |
| | | | SS+A256KW | |
+------+-------+------+-------------------------------+-------------+
Table 13: HKDF Algorithm Parameters
表13:HKDF算法参数
The context information structure is used to ensure that the derived keying material is "bound" to the context of the transaction. The context information structure used here is based on that defined in [SP800-56A]. By using CBOR for the encoding of the context information structure, we automatically get the same type and length separation of fields that is obtained by the use of ASN.1. This means that there is no need to encode the lengths for the base elements, as it is done by the encoding used in JOSE (Section 4.6.2 of [RFC7518]).
上下文信息结构用于确保派生的键控材料“绑定”到事务的上下文。此处使用的上下文信息结构基于[SP800-56A]中定义的上下文信息结构。通过使用CBOR对上下文信息结构进行编码，我们可以自动获得与ASN.1相同的字段类型和长度分隔。这意味着不需要对基本元素的长度进行编码，因为这是通过JOSE中使用的编码完成的（RFC7518第4.6.2节）。
The context information structure refers to PartyU and PartyV as the two parties that are doing the key derivation. Unless the application protocol defines differently, we assign PartyU to the entity that is creating the message and PartyV to the entity that is receiving the message. By doing this association, different keys will be derived for each direction as the context information is different in each direction.
上下文信息结构将PartyU和PartyV称为进行密钥派生的两方。除非应用程序协议定义不同，否则我们将PartyU分配给创建消息的实体，将PartyV分配给接收消息的实体。通过执行此关联，将为每个方向导出不同的键，因为每个方向上的上下文信息不同。
The context structure is built from information that is known to both entities. This information can be obtained from a variety of sources:
上下文结构是根据两个实体都知道的信息构建的。这些信息可以从各种来源获得：
o Fields can be defined by the application. This is commonly used to assign fixed names to parties, but it can be used for other items such as nonces.
o 字段可以由应用程序定义。这通常用于为参与方分配固定名称，但也可用于其他项，如nonce。
o Fields can be defined by usage of the output. Examples of this are the algorithm and key size that are being generated.
o 可以通过使用输出来定义字段。例如正在生成的算法和密钥大小。
o Fields can be defined by parameters from the message. We define a set of parameters in Table 14 that can be used to carry the values associated with the context structure. Examples of this are identities and nonce values. These parameters are designed to be placed in the unprotected bucket of the recipient structure; they do not need to be in the protected bucket since they already are included in the cryptographic computation by virtue of being included in the context structure.
o 字段可以由消息中的参数定义。我们在表14中定义了一组参数，可用于携带与上下文结构相关的值。例如标识和nonce值。这些参数被设计为放置在接收方结构的未受保护的存储桶中；它们不需要在受保护的bucket中，因为它们已经由于包含在上下文结构中而包含在加密计算中。
+----------+-------+------+---------------------------+-------------+
| Name | Label | Type | Algorithm | Description |
+----------+-------+------+---------------------------+-------------+
| PartyU | -21 | bstr | direct+HKDF-SHA-256, | Party U |
| identity | | | direct+HKDF-SHA-512, | identity |
| | | | direct+HKDF-AES-128, | information |
| | | | direct+HKDF-AES-256, | |
| | | | ECDH-ES+HKDF-256, ECDH- | |
| | | | ES+HKDF-512, ECDH- | |
| | | | SS+HKDF-256, ECDH- | |
| | | | SS+HKDF-512, ECDH- | |
| | | | ES+A128KW, ECDH- | |
| | | | ES+A192KW, ECDH- | |
| | | | ES+A256KW, ECDH- | |
| | | | SS+A128KW, ECDH- | |
| | | | SS+A192KW, ECDH-SS+A256KW | |
| | | | | |
| PartyU | -22 | bstr | direct+HKDF-SHA-256, | Party U |
| nonce | | / | direct+HKDF-SHA-512, | provided |
| | | int | direct+HKDF-AES-128, | nonce |
| | | | direct+HKDF-AES-256, | |
| | | | ECDH-ES+HKDF-256, ECDH- | |
| | | | ES+HKDF-512, ECDH- | |
| | | | SS+HKDF-256, ECDH- | |
| | | | SS+HKDF-512, ECDH- | |
| | | | ES+A128KW, ECDH- | |
| | | | ES+A192KW, ECDH- | |
| | | | ES+A256KW, ECDH- | |
| | | | SS+A128KW, ECDH- | |
| | | | SS+A192KW, ECDH-SS+A256KW | |
| | | | | |
| PartyU | -23 | bstr | direct+HKDF-SHA-256, | Party U |
| other | | | direct+HKDF-SHA-512, | other |
| | | | direct+HKDF-AES-128, | provided |
| | | | direct+HKDF-AES-256, | information |
| | | | ECDH-ES+HKDF-256, ECDH- | |
| | | | ES+HKDF-512, ECDH- | |
| | | | SS+HKDF-256, ECDH- | |
| | | | SS+HKDF-512, ECDH- | |
| | | | ES+A128KW, ECDH- | |
| | | | ES+A192KW, ECDH- | |
| | | | ES+A256KW, ECDH- | |
| | | | SS+A128KW, ECDH- | |
| | | | SS+A192KW, ECDH-SS+A256KW | |
+----------+-------+------+---------------------------+-------------+
| Name | Label | Type | Algorithm | Description |
+----------+-------+------+---------------------------+-------------+
| PartyU | -21 | bstr | direct+HKDF-SHA-256, | Party U |
| identity | | | direct+HKDF-SHA-512, | identity |
| | | | direct+HKDF-AES-128, | information |
| | | | direct+HKDF-AES-256, | |
| | | | ECDH-ES+HKDF-256, ECDH- | |
| | | | ES+HKDF-512, ECDH- | |
| | | | SS+HKDF-256, ECDH- | |
| | | | SS+HKDF-512, ECDH- | |
| | | | ES+A128KW, ECDH- | |
| | | | ES+A192KW, ECDH- | |
| | | | ES+A256KW, ECDH- | |
| | | | SS+A128KW, ECDH- | |
| | | | SS+A192KW, ECDH-SS+A256KW | |
| | | | | |
| PartyU | -22 | bstr | direct+HKDF-SHA-256, | Party U |
| nonce | | / | direct+HKDF-SHA-512, | provided |
| | | int | direct+HKDF-AES-128, | nonce |
| | | | direct+HKDF-AES-256, | |
| | | | ECDH-ES+HKDF-256, ECDH- | |
| | | | ES+HKDF-512, ECDH- | |
| | | | SS+HKDF-256, ECDH- | |
| | | | SS+HKDF-512, ECDH- | |
| | | | ES+A128KW, ECDH- | |
| | | | ES+A192KW, ECDH- | |
| | | | ES+A256KW, ECDH- | |
| | | | SS+A128KW, ECDH- | |
| | | | SS+A192KW, ECDH-SS+A256KW | |
| | | | | |
| PartyU | -23 | bstr | direct+HKDF-SHA-256, | Party U |
| other | | | direct+HKDF-SHA-512, | other |
| | | | direct+HKDF-AES-128, | provided |
| | | | direct+HKDF-AES-256, | information |
| | | | ECDH-ES+HKDF-256, ECDH- | |
| | | | ES+HKDF-512, ECDH- | |
| | | | SS+HKDF-256, ECDH- | |
| | | | SS+HKDF-512, ECDH- | |
| | | | ES+A128KW, ECDH- | |
| | | | ES+A192KW, ECDH- | |
| | | | ES+A256KW, ECDH- | |
| | | | SS+A128KW, ECDH- | |
| | | | SS+A192KW, ECDH-SS+A256KW | |
| PartyV | -24 | bstr | direct+HKDF-SHA-256, | Party V |
| identity | | | direct+HKDF-SHA-512, | identity |
| | | | direct+HKDF-AES-128, | information |
| | | | direct+HKDF-AES-256, | |
| | | | ECDH-ES+HKDF-256, ECDH- | |
| | | | ES+HKDF-512, ECDH- | |
| | | | SS+HKDF-256, ECDH- | |
| | | | SS+HKDF-512, ECDH- | |
| | | | ES+A128KW, ECDH- | |
| | | | ES+A192KW, ECDH- | |
| | | | ES+A256KW, ECDH- | |
| | | | SS+A128KW, ECDH- | |
| | | | SS+A192KW, ECDH-SS+A256KW | |
| | | | | |
| PartyV | -25 | bstr | direct+HKDF-SHA-256, | Party V |
| nonce | | / | direct+HKDF-SHA-512, | provided |
| | | int | direct+HKDF-AES-128, | nonce |
| | | | direct+HKDF-AES-256, | |
| | | | ECDH-ES+HKDF-256, ECDH- | |
| | | | ES+HKDF-512, ECDH- | |
| | | | SS+HKDF-256, ECDH- | |
| | | | SS+HKDF-512, ECDH- | |
| | | | ES+A128KW, ECDH- | |
| | | | ES+A192KW, ECDH- | |
| | | | ES+A256KW, ECDH- | |
| | | | SS+A128KW, ECDH- | |
| | | | SS+A192KW, ECDH-SS+A256KW | |
| | | | | |
| PartyV | -26 | bstr | direct+HKDF-SHA-256, | Party V |
| other | | | direct+HKDF-SHA-512, | other |
| | | | direct+HKDF-AES-128, | provided |
| | | | direct+HKDF-AES-256, | information |
| | | | ECDH-ES+HKDF-256, ECDH- | |
| | | | ES+HKDF-512, ECDH- | |
| | | | SS+HKDF-256, ECDH- | |
| | | | SS+HKDF-512, ECDH- | |
| | | | ES+A128KW, ECDH- | |
| | | | ES+A192KW, ECDH- | |
| | | | ES+A256KW, ECDH- | |
| | | | SS+A128KW, ECDH- | |
| | | | SS+A192KW, ECDH-SS+A256KW | |
+----------+-------+------+---------------------------+-------------+
| PartyV | -24 | bstr | direct+HKDF-SHA-256, | Party V |
| identity | | | direct+HKDF-SHA-512, | identity |
| | | | direct+HKDF-AES-128, | information |
| | | | direct+HKDF-AES-256, | |
| | | | ECDH-ES+HKDF-256, ECDH- | |
| | | | ES+HKDF-512, ECDH- | |
| | | | SS+HKDF-256, ECDH- | |
| | | | SS+HKDF-512, ECDH- | |
| | | | ES+A128KW, ECDH- | |
| | | | ES+A192KW, ECDH- | |
| | | | ES+A256KW, ECDH- | |
| | | | SS+A128KW, ECDH- | |
| | | | SS+A192KW, ECDH-SS+A256KW | |
| | | | | |
| PartyV | -25 | bstr | direct+HKDF-SHA-256, | Party V |
| nonce | | / | direct+HKDF-SHA-512, | provided |
| | | int | direct+HKDF-AES-128, | nonce |
| | | | direct+HKDF-AES-256, | |
| | | | ECDH-ES+HKDF-256, ECDH- | |
| | | | ES+HKDF-512, ECDH- | |
| | | | SS+HKDF-256, ECDH- | |
| | | | SS+HKDF-512, ECDH- | |
| | | | ES+A128KW, ECDH- | |
| | | | ES+A192KW, ECDH- | |
| | | | ES+A256KW, ECDH- | |
| | | | SS+A128KW, ECDH- | |
| | | | SS+A192KW, ECDH-SS+A256KW | |
| | | | | |
| PartyV | -26 | bstr | direct+HKDF-SHA-256, | Party V |
| other | | | direct+HKDF-SHA-512, | other |
| | | | direct+HKDF-AES-128, | provided |
| | | | direct+HKDF-AES-256, | information |
| | | | ECDH-ES+HKDF-256, ECDH- | |
| | | | ES+HKDF-512, ECDH- | |
| | | | SS+HKDF-256, ECDH- | |
| | | | SS+HKDF-512, ECDH- | |
| | | | ES+A128KW, ECDH- | |
| | | | ES+A192KW, ECDH- | |
| | | | ES+A256KW, ECDH- | |
| | | | SS+A128KW, ECDH- | |
| | | | SS+A192KW, ECDH-SS+A256KW | |
+----------+-------+------+---------------------------+-------------+
Table 14: Context Algorithm Parameters
表14：上下文算法参数
We define a CBOR object to hold the context information. This object is referred to as COSE_KDF_Context. The object is based on a CBOR array type. The fields in the array are:
我们定义一个CBOR对象来保存上下文信息。此对象称为COSE_KDF_上下文。对象基于CBOR数组类型。数组中的字段包括：
AlgorithmID: This field indicates the algorithm for which the key material will be used. This normally is either a key wrap algorithm identifier or a content encryption algorithm identifier. The values are from the "COSE Algorithms" registry. This field is required to be present. The field exists in the context information so that if the same environment is used for different algorithms, then completely different keys will be generated for each of those algorithms. This practice means if algorithm A is broken and thus is easier to find, the key derived for algorithm B will not be the same as the key derived for algorithm A.
AlgorithmID：此字段指示将使用关键材料的算法。这通常是密钥包裹算法标识符或内容加密算法标识符。这些值来自“COSE算法”注册表。此字段必须存在。该字段存在于上下文信息中，因此如果相同的环境用于不同的算法，则将为每个算法生成完全不同的密钥。这种做法意味着，如果算法A被破坏，因此更容易找到，那么为算法B派生的密钥将与为算法A派生的密钥不同。
PartyUInfo: This field holds information about party U. The PartyUInfo is encoded as a CBOR array. The elements of PartyUInfo are encoded in the order presented. The elements of the PartyUInfo array are:
PartyInfo：此字段保存有关参与方U的信息。PartyInfo编码为CBOR数组。PartyInfo的元素按显示的顺序编码。PartyInfo数组的元素包括：
identity: This contains the identity information for party U. The identities can be assigned in one of two manners. First, a protocol can assign identities based on roles. For example, the roles of "client" and "server" may be assigned to different entities in the protocol. Each entity would then use the correct label for the data they send or receive. The second way for a protocol to assign identities is to use a name based on a naming system (i.e., DNS, X.509 names).
身份：包含U方的身份信息。身份可以通过两种方式之一分配。首先，协议可以根据角色分配身份。例如，“客户端”和“服务器”的角色可以分配给协议中的不同实体。然后，每个实体将为其发送或接收的数据使用正确的标签。协议分配身份的第二种方法是使用基于命名系统的名称（即DNS、X.509名称）。
We define an algorithm parameter 'PartyU identity' that can be used to carry identity information in the message. However, identity information is often known as part of the protocol and can thus be inferred rather than made explicit. If identity information is carried in the message, applications SHOULD have a way of validating the supplied identity information. The identity information does not need to be specified and is set to nil in that case.
我们定义了一个算法参数“PartyU identity”，可用于在消息中携带身份信息。然而，身份信息通常被称为协议的一部分，因此可以推断而不是显式的。如果消息中包含身份信息，则应用程序应具有验证所提供身份信息的方法。标识信息不需要指定，在这种情况下设置为nil。
nonce: This contains a nonce value. The nonce can either be implicit from the protocol or be carried as a value in the unprotected headers.
nonce：它包含一个nonce值。nonce可以是协议中的隐式值，也可以作为未受保护的报头中的值携带。
We define an algorithm parameter 'PartyU nonce' that can be used to carry this value in the message; however, the nonce value could be determined by the application and the value determined from elsewhere.
我们定义了一个算法参数“PartyU nonce”，可用于在消息中携带该值；但是，nonce值可以由应用程序确定，也可以由其他地方确定。
This option does not need to be specified and is set to nil in that case.
此选项不需要指定，在这种情况下设置为nil。
other: This contains other information that is defined by the protocol. This option does not need to be specified and is set to nil in that case.
其他：包含协议定义的其他信息。此选项不需要指定，在这种情况下设置为nil。
PartyVInfo: This field holds information about party V. The content of the structure is the same as for the PartyUInfo but for party V.
PartyInfo：此字段保存有关party V的信息。结构的内容与PartyInfo相同，但适用于party V。
SuppPubInfo: This field contains public information that is mutually known to both parties.
SuppPubInfo：此字段包含双方都知道的公共信息。
keyDataLength: This is set to the number of bits of the desired output value. This practice means if algorithm A can use two different key lengths, the key derived for longer key size will not contain the key for shorter key size as a prefix.
keyDataLength：设置为所需输出值的位数。这种做法意味着，如果算法A可以使用两种不同的密钥长度，则为较长密钥大小派生的密钥将不包含为较短密钥大小派生的密钥作为前缀。
protected: This field contains the protected parameter field. If there are no elements in the protected field, then use a zero-length bstr.
受保护：此字段包含受保护的参数字段。如果受保护字段中没有元素，则使用零长度bstr。
other: This field is for free form data defined by the application. An example is that an application could define two different strings to be placed here to generate different keys for a data stream versus a control stream. This field is optional and will only be present if the application defines a structure for this information. Applications that define this SHOULD use CBOR to encode the data so that types and lengths are correctly included.
其他：此字段用于应用程序定义的自由格式数据。一个例子是，应用程序可以定义两个不同的字符串放在这里，为数据流和控制流生成不同的键。此字段是可选的，仅当应用程序定义此信息的结构时才会出现。定义此项的应用程序应使用CBOR对数据进行编码，以便正确包含类型和长度。
SuppPrivInfo: This field contains private information that is mutually known private information. An example of this information would be a preexisting shared secret. (This could, for example, be used in combination with an ECDH key agreement to provide a secondary proof of identity.) The field is optional and will only be present if the application defines a structure for this information. Applications that define this SHOULD use CBOR to encode the data so that types and lengths are correctly included.
SuppPrivInfo：此字段包含互为已知的私有信息。这种信息的一个例子是先前存在的共享秘密。（例如，该字段可与ECDH密钥协议结合使用，以提供二级身份证明。）该字段是可选的，仅当应用程序定义了该信息的结构时才会出现。定义此项的应用程序应使用CBOR对数据进行编码，以便正确包含类型和长度。
The following CDDL fragment corresponds to the text above.
下面的CDDL片段对应于上面的文本。
PartyInfo = (
identity : bstr / nil,
nonce : bstr / int / nil,
other : bstr / nil
)
PartyInfo = (
identity : bstr / nil,
nonce : bstr / int / nil,
other : bstr / nil
)
COSE_KDF_Context = [
AlgorithmID : int / tstr,
PartyUInfo : [ PartyInfo ],
PartyVInfo : [ PartyInfo ],
SuppPubInfo : [
keyDataLength : uint,
protected : empty_or_serialized_map,
? other : bstr
],
? SuppPrivInfo : bstr
]
COSE_KDF_Context = [
AlgorithmID : int / tstr,
PartyUInfo : [ PartyInfo ],
PartyVInfo : [ PartyInfo ],
SuppPubInfo : [
keyDataLength : uint,
protected : empty_or_serialized_map,
? other : bstr
],
? SuppPrivInfo : bstr
]
Content key distribution methods (recipient algorithms) can be defined into a number of different classes. COSE has the ability to support many classes of recipient algorithms. In this section, a number of classes are listed, and then a set of algorithms are specified for each of the classes. The names of the recipient algorithm classes used here are the same as those defined in [RFC7516]. Other specifications use different terms for the recipient algorithm classes or do not support some of the recipient algorithm classes.
内容密钥分发方法（收件人算法）可以定义为许多不同的类。COSE能够支持多种类型的接收方算法。在本节中，列出了许多类，然后为每个类指定了一组算法。此处使用的收件人算法类的名称与[RFC7516]中定义的名称相同。其他规范对收件人算法类使用不同的术语，或者不支持某些收件人算法类。
The direct encryption class algorithms share a secret between the sender and the recipient that is used either directly or after manipulation as the CEK. When direct encryption mode is used, it MUST be the only mode used on the message.
直接加密类算法在发送者和接收者之间共享一个秘密，该秘密可以直接使用，也可以在操作后作为CEK使用。使用直接加密模式时，它必须是消息上使用的唯一模式。
The COSE_Recipient structure for the recipient is organized as follows:
收件人的COSE_收件人结构组织如下：
o The 'protected' field MUST be a zero-length item unless it is used in the computation of the content key.
o “受保护”字段必须为零长度项，除非在计算内容键时使用它。
o The 'alg' parameter MUST be present.
o “alg”参数必须存在。
o A parameter identifying the shared secret SHOULD be present.
o 应该存在标识共享机密的参数。
o The 'ciphertext' field MUST be a zero-length item.
o “密文”字段必须为零长度项。
o The 'recipients' field MUST be absent.
o “收件人”字段必须不存在。
This recipient algorithm is the simplest; the identified key is directly used as the key for the next layer down in the message. There are no algorithm parameters defined for this algorithm. The algorithm identifier value is assigned in Table 15.
这种算法是最简单的；标识的密钥直接用作消息中下一层的密钥。没有为此算法定义任何算法参数。表15中分配了算法标识符值。
When this algorithm is used, the protected field MUST be zero length. The key type MUST be 'Symmetric'.
使用此算法时，受保护字段的长度必须为零。密钥类型必须为“对称”。
+--------+-------+-------------------+
| Name | Value | Description |
+--------+-------+-------------------+
| direct | -6 | Direct use of CEK |
+--------+-------+-------------------+
+--------+-------+-------------------+
| Name | Value | Description |
+--------+-------+-------------------+
| direct | -6 | Direct use of CEK |
+--------+-------+-------------------+
Table 15: Direct Key
表15：直接键
This recipient algorithm has several potential problems that need to be considered:
此收件人算法有几个需要考虑的潜在问题：
o These keys need to have some method to be regularly updated over time. All of the content encryption algorithms specified in this document have limits on how many times a key can be used without significant loss of security.
o 这些密钥需要有一些方法，以便随着时间的推移定期更新。本文档中指定的所有内容加密算法对密钥的使用次数都有限制，并且不会造成重大安全损失。
o These keys need to be dedicated to a single algorithm. There have been a number of attacks developed over time when a single key is used for multiple different algorithms. One example of this is the use of a single key for both the CBC encryption mode and the CBC-MAC authentication mode.
o 这些密钥需要专用于单个算法。当一个密钥用于多个不同的算法时，随着时间的推移，出现了许多攻击。这方面的一个示例是对CBC加密模式和CBC-MAC身份验证模式使用单个密钥。
o Breaking one message means all messages are broken. If an adversary succeeds in determining the key for a single message, then the key for all messages is also determined.
o 断开一条消息意味着所有消息都断开。如果对手成功地确定了单个消息的密钥，那么也将确定所有消息的密钥。
These recipient algorithms take a common shared secret between the two parties and applies the HKDF function (Section 11.1), using the context structure defined in Section 11.2 to transform the shared
这些接收方算法采用双方之间的公共共享秘密，并应用HKDF函数（第11.1节），使用第11.2节中定义的上下文结构转换共享密钥
secret into the CEK. The 'protected' field can be of non-zero length. Either the 'salt' parameter of HKDF or the 'PartyU nonce' parameter of the context structure MUST be present. The salt/nonce parameter can be generated either randomly or deterministically. The requirement is that it be a unique value for the shared secret in question.
进入CEK的秘密。“受保护”字段的长度可以为非零。HKDF的“salt”参数或上下文结构的“PartyU nonce”参数必须存在。salt/nonce参数可以随机生成，也可以确定生成。要求是它必须是所讨论的共享秘密的唯一值。
If the salt/nonce value is generated randomly, then it is suggested that the length of the random value be the same length as the hash function underlying HKDF. While there is no way to guarantee that it will be unique, there is a high probability that it will be unique. If the salt/nonce value is generated deterministically, it can be guaranteed to be unique, and thus there is no length requirement.
如果salt/nonce值是随机生成的，则建议随机值的长度与HKDF下面的哈希函数的长度相同。虽然无法保证它是唯一的，但它很可能是唯一的。如果确定地生成salt/nonce值，则可以保证它是唯一的，因此没有长度要求。
A new IV must be used for each message if the same key is used. The IV can be modified in a predictable manner, a random manner, or an unpredictable manner (i.e., encrypting a counter).
如果使用相同的密钥，则必须为每条消息使用新的IV。可以以可预测的方式、随机方式或不可预测的方式（即，加密计数器）修改IV。
The IV used for a key can also be generated from the same HKDF functionality as the key is generated. If HKDF is used for generating the IV, the algorithm identifier is set to "IV-GENERATION".
用于密钥的IV也可以通过与生成密钥相同的HKDF功能生成。如果HKDF用于生成IV，则算法标识符设置为“IV-GENERATION”。
When these algorithms are used, the key type MUST be 'symmetric'.
使用这些算法时，密钥类型必须为“对称”。
The set of algorithms defined in this document can be found in Table 16.
本文件中定义的算法集见表16。
+---------------------+-------+-------------+-----------------------+
| Name | Value | KDF | Description |
+---------------------+-------+-------------+-----------------------+
| direct+HKDF-SHA-256 | -10 | HKDF | Shared secret w/ HKDF |
| | | SHA-256 | and SHA-256 |
| direct+HKDF-SHA-512 | -11 | HKDF | Shared secret w/ HKDF |
| | | SHA-512 | and SHA-512 |
| direct+HKDF-AES-128 | -12 | HKDF AES- | Shared secret w/ AES- |
| | | MAC-128 | MAC 128-bit key |
| direct+HKDF-AES-256 | -13 | HKDF AES- | Shared secret w/ AES- |
| | | MAC-256 | MAC 256-bit key |
+---------------------+-------+-------------+-----------------------+
+---------------------+-------+-------------+-----------------------+
| Name | Value | KDF | Description |
+---------------------+-------+-------------+-----------------------+
| direct+HKDF-SHA-256 | -10 | HKDF | Shared secret w/ HKDF |
| | | SHA-256 | and SHA-256 |
| direct+HKDF-SHA-512 | -11 | HKDF | Shared secret w/ HKDF |
| | | SHA-512 | and SHA-512 |
| direct+HKDF-AES-128 | -12 | HKDF AES- | Shared secret w/ AES- |
| | | MAC-128 | MAC 128-bit key |
| direct+HKDF-AES-256 | -13 | HKDF AES- | Shared secret w/ AES- |
| | | MAC-256 | MAC 256-bit key |
+---------------------+-------+-------------+-----------------------+
Table 16: Direct Key with KDF
表16：使用KDF的直接键
When using a COSE key for this algorithm, the following checks are made:
使用此算法的COSE密钥时，将进行以下检查：
o The 'kty' field MUST be present, and it MUST be 'Symmetric'.
o “kty”字段必须存在，并且必须是“对称”字段。
o If the 'alg' field is present, it MUST match the algorithm being used.
o 如果存在“alg”字段，则它必须与正在使用的算法匹配。
o If the 'key_ops' field is present, it MUST include 'deriveKey' or 'deriveBits'.
o 如果存在“key_ops”字段，则必须包括“deriveKey”或“deriveBits”。
The shared secret needs to have some method to be regularly updated over time. The shared secret forms the basis of trust. Although not used directly, it should still be subject to scheduled rotation.
共享秘密需要有一些方法，以便随着时间的推移定期更新。共享的秘密构成信任的基础。虽然不直接使用，但仍应按计划进行轮换。
While these methods do not provide for perfect forward secrecy, as the same shared secret is used for all of the keys generated, if the key for any single message is discovered, only the message (or series of messages) using that derived key are compromised. A new key derivation step will generate a new key that requires the same amount of work to get the key.
虽然这些方法不能提供完美的前向保密性，但由于生成的所有密钥都使用相同的共享密钥，如果发现任何单个消息的密钥，则只有使用该派生密钥的消息（或一系列消息）被泄露。新的密钥派生步骤将生成一个新密钥，该密钥需要相同的工作量才能获得密钥。
In key wrap mode, the CEK is randomly generated and that key is then encrypted by a shared secret between the sender and the recipient. All of the currently defined key wrap algorithms for COSE are AE algorithms. Key wrap mode is considered to be superior to direct encryption if the system has any capability for doing random key generation. This is because the shared key is used to wrap random data rather than data that has some degree of organization and may in fact be repeating the same content. The use of key wrap loses the weak data origination that is provided by the direct encryption algorithms.
在密钥包装模式下，随机生成CEK，然后通过发送方和接收方之间的共享密钥对该密钥进行加密。目前为COSE定义的所有密钥包裹算法都是AE算法。如果系统具有生成随机密钥的能力，则认为密钥包裹模式优于直接加密。这是因为共享密钥用于包装随机数据，而不是具有某种程度的组织结构且实际上可能重复相同内容的数据。使用密钥包装会丢失直接加密算法提供的弱数据源。
The COSE_Encrypt structure for the recipient is organized as follows:
收件人的COSE_加密结构组织如下：
o The 'protected' field MUST be absent if the key wrap algorithm is an AE algorithm.
o 如果密钥换行算法是AE算法，则必须缺少“受保护”字段。
o The 'recipients' field is normally absent, but can be used. Applications MUST deal with a recipient field being present, not being able to decrypt that recipient is an acceptable way of dealing with it. Failing to process the message is not an acceptable way of dealing with it.
o “收件人”字段通常不存在，但可以使用。应用程序必须处理存在的收件人字段，不能解密该收件人是可以接受的处理方式。不处理该消息是不可接受的处理方式。
o The plaintext to be encrypted is the key from next layer down (usually the content layer).
o 要加密的明文是下一层（通常是内容层）的密钥。
o At a minimum, the 'unprotected' field MUST contain the 'alg' parameter and SHOULD contain a parameter identifying the shared secret.
o “unprotected”字段至少必须包含“alg”参数，并且应该包含标识共享机密的参数。
The AES Key Wrap algorithm is defined in [RFC3394]. This algorithm uses an AES key to wrap a value that is a multiple of 64 bits. As such, it can be used to wrap a key for any of the content encryption algorithms defined in this document. The algorithm requires a single fixed parameter, the initial value. This is fixed to the value specified in Section 2.2.3.1 of [RFC3394]. There are no public parameters that vary on a per-invocation basis. The protected header field MUST be empty.
[RFC3394]中定义了AES密钥包裹算法。此算法使用AES密钥包装64位倍数的值。因此，它可以用于包装本文档中定义的任何内容加密算法的密钥。该算法需要一个固定的参数，即初始值。该值固定为[RFC3394]第2.2.3.1节中规定的值。每个调用都没有不同的公共参数。受保护的标头字段必须为空。
Keys may be obtained either from a key structure or from a recipient structure. Implementations encrypting and decrypting MUST validate that the key type, key length, and algorithm are correct and appropriate for the entities involved.
密钥可以从密钥结构或从接收方结构获得。加密和解密的实现必须验证密钥类型、密钥长度和算法是否正确，是否适合所涉及的实体。
When using a COSE key for this algorithm, the following checks are made:
使用此算法的COSE密钥时，将进行以下检查：
o The 'kty' field MUST be present, and it MUST be 'Symmetric'.
o “kty”字段必须存在，并且必须是“对称”字段。
o If the 'alg' field is present, it MUST match the AES Key Wrap algorithm being used.
o 如果存在“alg”字段，则它必须与正在使用的AES密钥包裹算法匹配。
o If the 'key_ops' field is present, it MUST include 'encrypt' or 'wrap key' when encrypting.
o 如果存在“key_ops”字段，则在加密时必须包含“encrypt”或“wrap key”。
o If the 'key_ops' field is present, it MUST include 'decrypt' or 'unwrap key' when decrypting.
o 如果存在“密钥操作”字段，则在解密时必须包含“解密”或“解开密钥”。
+--------+-------+----------+-----------------------------+
| Name | Value | Key Size | Description |
+--------+-------+----------+-----------------------------+
| A128KW | -3 | 128 | AES Key Wrap w/ 128-bit key |
| A192KW | -4 | 192 | AES Key Wrap w/ 192-bit key |
| A256KW | -5 | 256 | AES Key Wrap w/ 256-bit key |
+--------+-------+----------+-----------------------------+
+--------+-------+----------+-----------------------------+
| Name | Value | Key Size | Description |
+--------+-------+----------+-----------------------------+
| A128KW | -3 | 128 | AES Key Wrap w/ 128-bit key |
| A192KW | -4 | 192 | AES Key Wrap w/ 192-bit key |
| A256KW | -5 | 256 | AES Key Wrap w/ 256-bit key |
+--------+-------+----------+-----------------------------+
Table 17: AES Key Wrap Algorithm Values
表17:AES密钥换行算法值
The shared secret needs to have some method to be regularly updated over time. The shared secret is the basis of trust.
共享秘密需要有一些方法，以便随着时间的推移定期更新。共享秘密是信任的基础。
Key transport mode is also called key encryption mode in some standards. Key transport mode differs from key wrap mode in that it uses an asymmetric encryption algorithm rather than a symmetric encryption algorithm to protect the key. This document does not define any key transport mode algorithms.
密钥传输模式在某些标准中也称为密钥加密模式。密钥传输模式与密钥包裹模式的不同之处在于，它使用非对称加密算法而不是对称加密算法来保护密钥。本文档未定义任何关键传输模式算法。
When using a key transport algorithm, the COSE_Encrypt structure for the recipient is organized as follows:
使用密钥传输算法时，收件人的COSE_加密结构组织如下：
o The 'protected' field MUST be absent.
o “受保护”字段必须不存在。
o The plaintext to be encrypted is the key from the next layer down (usually the content layer).
o 要加密的明文是下一层（通常是内容层）的密钥。
o At a minimum, the 'unprotected' field MUST contain the 'alg' parameter and SHOULD contain a parameter identifying the asymmetric key.
o “unprotected”字段至少必须包含“alg”参数，并且应该包含标识非对称密钥的参数。
The 'direct key agreement' class of recipient algorithms uses a key agreement method to create a shared secret. A KDF is then applied to the shared secret to derive a key to be used in protecting the data. This key is normally used as a CEK or MAC key, but could be used for other purposes if more than two layers are in use (see Appendix B).
“直接密钥协商”类接收方算法使用密钥协商方法创建共享密钥。然后将KDF应用于共享密钥，以导出用于保护数据的密钥。该密钥通常用作CEK或MAC密钥，但如果使用两层以上，则可用于其他目的（见附录B）。
The most commonly used key agreement algorithm is Diffie-Hellman, but other variants exist. Since COSE is designed for a store and forward environment rather than an online environment, many of the DH variants cannot be used as the receiver of the message cannot provide any dynamic key material. One side effect of this is that perfect forward secrecy (see [RFC4949]) is not achievable. A static key will always be used for the receiver of the COSE object.
最常用的密钥协商算法是Diffie-Hellman，但也存在其他变体。由于COSE是为存储转发环境而不是在线环境设计的，因此许多DH变体不能用作消息的接收者，也不能提供任何动态密钥材料。这样做的一个副作用是无法实现完美的前向保密（参见[RFC4949]）。静态密钥将始终用于COSE对象的接收器。
Two variants of DH that are supported are:
支持的DH的两个变体是：
Ephemeral-Static (ES) DH: where the sender of the message creates a one-time DH key and uses a static key for the recipient. The use of the ephemeral sender key means that no additional random input is needed as this is randomly generated for each message.
短暂静态（ES）DH：消息发送方创建一次性DH密钥，并为接收方使用静态密钥。使用临时发送者密钥意味着不需要额外的随机输入，因为这是为每条消息随机生成的。
Static-Static DH: where a static key is used for both the sender and the recipient. The use of static keys allows for the recipient to get a weak version of data origination for the message. When static-static key agreement is used, then some piece of unique data for the KDF is required to ensure that a different key is created for each message.
静态DH：其中静态密钥用于发送方和接收方。静态密钥的使用允许收件人获取邮件的弱版本数据源。使用静态密钥协议时，需要KDF的一些唯一数据，以确保为每条消息创建不同的密钥。
When direct key agreement mode is used, there MUST be only one recipient in the message. This method creates the key directly, and that makes it difficult to mix with additional recipients. If multiple recipients are needed, then the version with key wrap needs to be used.
使用直接密钥协议模式时，邮件中必须只有一个收件人。此方法直接创建密钥，因此很难与其他收件人混合。如果需要多个收件人，则需要使用具有密钥换行的版本。
The COSE_Encrypt structure for the recipient is organized as follows:
收件人的COSE_加密结构组织如下：
o At a minimum, headers MUST contain the 'alg' parameter and SHOULD contain a parameter identifying the recipient's asymmetric key.
o 标头至少必须包含“alg”参数，并且应该包含标识收件人非对称密钥的参数。
o The headers SHOULD identify the sender's key for the static-static versions and MUST contain the sender's ephemeral key for the ephemeral-static versions.
o 标头应该标识静态版本的发送方密钥，并且必须包含临时静态版本的发送方临时密钥。
The mathematics for ECDH can be found in [RFC6090]. In this document, the algorithm is extended to be used with the two curves defined in [RFC7748].
ECDH的数学可在[RFC6090]中找到。在本文件中，该算法被扩展用于[RFC7748]中定义的两条曲线。
ECDH is parameterized by the following:
ECDH由以下参数化：
o Curve Type/Curve: The curve selected controls not only the size of the shared secret, but the mathematics for computing the shared secret. The curve selected also controls how a point in the curve is represented and what happens for the identity points on the curve. In this specification, we allow for a number of different curves to be used. A set of curves are defined in Table 22. The math used to obtain the computed secret is based on the curve selected and not on the ECDH algorithm. For this reason, a new algorithm does not need to be defined for each of the curves.
o 曲线类型/曲线：所选曲线不仅控制共享机密的大小，还控制计算共享机密的数学。选定曲线还控制曲线中的点的表示方式以及曲线上的标识点的情况。在本规范中，我们允许使用许多不同的曲线。表22中定义了一组曲线。用于获取计算秘密的数学是基于所选曲线，而不是基于ECDH算法。因此，不需要为每条曲线定义新算法。
o Computed Secret to Shared Secret: Once the computed secret is known, the resulting value needs to be converted to a byte string to run the KDF. The x-coordinate is used for all of the curves defined in this document. For curves X25519 and X448, the resulting value is used directly as it is a byte string of a known length. For the P-256, P-384, and P-521 curves, the x-coordinate is run through the I2OSP function defined in [RFC8017], using the same computation for n as is defined in Section 8.1.
o 计算秘密到共享秘密：一旦计算秘密已知，结果值需要转换为字节字符串以运行KDF。x坐标用于本文档中定义的所有曲线。对于曲线X25519和X448，结果值直接使用，因为它是已知长度的字节字符串。对于P-256、P-384和P-521曲线，x坐标通过[RFC8017]中定义的I2OSP函数运行，使用与第8.1节中定义的相同的n计算。
o Ephemeral-Static or Static-Static: The key agreement process may be done using either a static or an ephemeral key for the sender's side. When using ephemeral keys, the sender MUST generate a new ephemeral key for every key agreement operation. The ephemeral key is placed in the 'ephemeral key' parameter and MUST be present for all algorithm identifiers that use ephemeral keys. When using static keys, the sender MUST either generate a new random value or create a unique value. For the KDFs used, this means either the 'salt' parameter for HKDF (Table 13) or the 'PartyU nonce' parameter for the context structure (Table 14) MUST be present (both can be present if desired). The value in the parameter MUST be unique for the pair of keys being used. It is acceptable to use a global counter that is incremented for every static-static operation and use the resulting value. When using static keys, the static key should be identified to the recipient. The static key can be identified either by providing the key ('static key') or by providing a key identifier for the static key ('static key id'). Both of these parameters are defined in Table 19.
o 临时静态或静态静态：密钥协商过程可以使用发送方的静态密钥或临时密钥来完成。使用临时密钥时，发送方必须为每个密钥协议操作生成新的临时密钥。临时密钥位于“临时密钥”参数中，并且必须为使用临时密钥的所有算法标识符提供临时密钥。使用静态键时，发送方必须生成新的随机值或创建唯一值。对于使用的KDF，这意味着HKDF的“salt”参数（表13）或上下文结构的“PartyU nonce”参数（表14）必须存在（如果需要，两者都可以存在）。参数中的值对于所使用的密钥对必须是唯一的。可以使用一个全局计数器，该计数器在每次静态操作时递增，并使用结果值。使用静态密钥时，应向收件人标识静态密钥。可以通过提供密钥（“静态密钥”）或通过提供静态密钥的密钥标识符（“静态密钥id”）来识别静态密钥。表19中定义了这两个参数。
o Key Derivation Algorithm: The result of an ECDH key agreement process does not provide a uniformly random secret. As such, it needs to be run through a KDF in order to produce a usable key. Processing the secret through a KDF also allows for the introduction of context material: how the key is going to be used and one-time material for static-static key agreement. All of the algorithms defined in this document use one of the HKDF algorithms defined in Section 11.1 with the context structure defined in Section 11.2.
o 密钥推导算法：ECDH密钥协商过程的结果不提供统一的随机密钥。因此，它需要通过KDF运行，以生成可用密钥。通过KDF处理机密还允许引入上下文材料：如何使用密钥以及静态密钥协议的一次性材料。本文件中定义的所有算法均使用第11.1节中定义的HKDF算法之一以及第11.2节中定义的上下文结构。
o Key Wrap Algorithm: No key wrap algorithm is used. This is represented in Table 18 as 'none'. The key size for the context structure is the content layer encryption algorithm size.
o 密钥换行算法：未使用密钥换行算法。这在表18中表示为“无”。上下文结构的密钥大小是内容层加密算法大小。
The set of direct ECDH algorithms defined in this document are found in Table 18.
本文件中定义的直接ECDH算法集见表18。
+-----------+-------+---------+------------+--------+---------------+
| Name | Value | KDF | Ephemeral- | Key | Description |
| | | | Static | Wrap | |
+-----------+-------+---------+------------+--------+---------------+
| ECDH-ES + | -25 | HKDF - | yes | none | ECDH ES w/ |
| HKDF-256 | | SHA-256 | | | HKDF - |
| | | | | | generate key |
| | | | | | directly |
| ECDH-ES + | -26 | HKDF - | yes | none | ECDH ES w/ |
| HKDF-512 | | SHA-512 | | | HKDF - |
| | | | | | generate key |
| | | | | | directly |
| ECDH-SS + | -27 | HKDF - | no | none | ECDH SS w/ |
| HKDF-256 | | SHA-256 | | | HKDF - |
| | | | | | generate key |
| | | | | | directly |
| ECDH-SS + | -28 | HKDF - | no | none | ECDH SS w/ |
| HKDF-512 | | SHA-512 | | | HKDF - |
| | | | | | generate key |
| | | | | | directly |
+-----------+-------+---------+------------+--------+---------------+
+-----------+-------+---------+------------+--------+---------------+
| Name | Value | KDF | Ephemeral- | Key | Description |
| | | | Static | Wrap | |
+-----------+-------+---------+------------+--------+---------------+
| ECDH-ES + | -25 | HKDF - | yes | none | ECDH ES w/ |
| HKDF-256 | | SHA-256 | | | HKDF - |
| | | | | | generate key |
| | | | | | directly |
| ECDH-ES + | -26 | HKDF - | yes | none | ECDH ES w/ |
| HKDF-512 | | SHA-512 | | | HKDF - |
| | | | | | generate key |
| | | | | | directly |
| ECDH-SS + | -27 | HKDF - | no | none | ECDH SS w/ |
| HKDF-256 | | SHA-256 | | | HKDF - |
| | | | | | generate key |
| | | | | | directly |
| ECDH-SS + | -28 | HKDF - | no | none | ECDH SS w/ |
| HKDF-512 | | SHA-512 | | | HKDF - |
| | | | | | generate key |
| | | | | | directly |
+-----------+-------+---------+------------+--------+---------------+
Table 18: ECDH Algorithm Values
表18:ECDH算法值
+-----------+-------+----------+---------------------+--------------+
| Name | Label | Type | Algorithm | Description |
+-----------+-------+----------+---------------------+--------------+
| ephemeral | -1 | COSE_Key | ECDH-ES+HKDF-256, | Ephemeral |
| key | | | ECDH-ES+HKDF-512, | public key |
| | | | ECDH-ES+A128KW, | for the |
| | | | ECDH-ES+A192KW, | sender |
| | | | ECDH-ES+A256KW | |
| static | -2 | COSE_Key | ECDH-SS+HKDF-256, | Static |
| key | | | ECDH-SS+HKDF-512, | public key |
| | | | ECDH-SS+A128KW, | for the |
| | | | ECDH-SS+A192KW, | sender |
| | | | ECDH-SS+A256KW | |
| static | -3 | bstr | ECDH-SS+HKDF-256, | Static |
| key id | | | ECDH-SS+HKDF-512, | public key |
| | | | ECDH-SS+A128KW, | identifier |
| | | | ECDH-SS+A192KW, | for the |
| | | | ECDH-SS+A256KW | sender |
+-----------+-------+----------+---------------------+--------------+
+-----------+-------+----------+---------------------+--------------+
| Name | Label | Type | Algorithm | Description |
+-----------+-------+----------+---------------------+--------------+
| ephemeral | -1 | COSE_Key | ECDH-ES+HKDF-256, | Ephemeral |
| key | | | ECDH-ES+HKDF-512, | public key |
| | | | ECDH-ES+A128KW, | for the |
| | | | ECDH-ES+A192KW, | sender |
| | | | ECDH-ES+A256KW | |
| static | -2 | COSE_Key | ECDH-SS+HKDF-256, | Static |
| key | | | ECDH-SS+HKDF-512, | public key |
| | | | ECDH-SS+A128KW, | for the |
| | | | ECDH-SS+A192KW, | sender |
| | | | ECDH-SS+A256KW | |
| static | -3 | bstr | ECDH-SS+HKDF-256, | Static |
| key id | | | ECDH-SS+HKDF-512, | public key |
| | | | ECDH-SS+A128KW, | identifier |
| | | | ECDH-SS+A192KW, | for the |
| | | | ECDH-SS+A256KW | sender |
+-----------+-------+----------+---------------------+--------------+
Table 19: ECDH Algorithm Parameters
表19:ECDH算法参数
This document defines these algorithms to be used with the curves P-256, P-384, P-521, X25519, and X448. Implementations MUST verify that the key type and curve are correct. Different curves are restricted to different key types. Implementations MUST verify that the curve and algorithm are appropriate for the entities involved.
本文件定义了用于曲线P-256、P-384、P-521、X25519和X448的这些算法。实现必须验证键类型和曲线是否正确。不同的曲线仅限于不同的关键点类型。实现必须验证曲线和算法是否适合所涉及的实体。
When using a COSE key for this algorithm, the following checks are made:
使用此算法的COSE密钥时，将进行以下检查：
o The 'kty' field MUST be present, and it MUST be 'EC2' or 'OKP'.
o “kty”字段必须存在，并且必须是“EC2”或“OKP”。
o If the 'alg' field is present, it MUST match the key agreement algorithm being used.
o 如果存在“alg”字段，则它必须与正在使用的密钥协商算法相匹配。
o If the 'key_ops' field is present, it MUST include 'derive key' or 'derive bits' for the private key.
o 如果“key_ops”字段存在，则它必须包含私钥的“派生密钥”或“派生位”。
o If the 'key_ops' field is present, it MUST be empty for the public key.
o 如果存在“key_ops”字段，则公钥字段必须为空。
There is a method of checking that points provided from external entities are valid. For the 'EC2' key format, this can be done by checking that the x and y values form a point on the curve. For the 'OKP' format, there is no simple way to do point validation.
有一种检查外部实体提供的点是否有效的方法。对于“EC2”键格式，可以通过检查x和y值是否在曲线上形成一个点来实现。对于“OKP”格式，没有简单的方法进行点验证。
Consideration was given to requiring that the public keys of both entities be provided as part of the key derivation process (as recommended in Section 6.1 of [RFC7748]). This was not done as COSE is used in a store and forward format rather than in online key exchange. In order for this to be a problem, either the receiver public key has to be chosen maliciously or the sender has to be malicious. In either case, all security evaporates anyway.
考虑要求作为密钥派生过程的一部分提供两个实体的公钥（如[RFC7748]第6.1节所建议）。由于COSE用于存储转发格式，而不是在线密钥交换，因此未执行此操作。为了使这成为一个问题，必须恶意地选择接收方公钥，或者必须恶意地选择发送方公钥。无论哪种情况，所有的安全都会消失。
A proof of possession of the private key associated with the public key is recommended when a key is moved from untrusted to trusted (either by the end user or by the entity that is responsible for making trust statements on keys).
当密钥从不受信任移动到受信任（由最终用户或负责对密钥进行信任声明的实体）时，建议提供与公钥相关联的私钥拥有证明。
Key Agreement with Key Wrap uses a randomly generated CEK. The CEK is then encrypted using a key wrap algorithm and a key derived from the shared secret computed by the key agreement algorithm. The function for this would be:
使用密钥包装的密钥协议使用随机生成的CEK。然后使用密钥包裹算法和由密钥协商算法计算的共享密钥派生的密钥对CEK进行加密。其功能是：
encryptedKey = KeyWrap(KDF(DH-Shared, context), CEK)
encryptedKey = KeyWrap(KDF(DH-Shared, context), CEK)
The COSE_Encrypt structure for the recipient is organized as follows:
收件人的COSE_加密结构组织如下：
o The 'protected' field is fed into the KDF context structure.
o “protected”字段被馈送到KDF上下文结构中。
o The plaintext to be encrypted is the key from the next layer down (usually the content layer).
o 要加密的明文是下一层（通常是内容层）的密钥。
o The 'alg' parameter MUST be present in the layer.
o 层中必须存在“alg”参数。
o A parameter identifying the recipient's key SHOULD be present. A parameter identifying the sender's key SHOULD be present.
o 应该存在标识收件人密钥的参数。应该存在标识发送方密钥的参数。
These algorithms are defined in Table 20.
这些算法定义见表20。
ECDH with Key Agreement is parameterized by the same parameters as for ECDH; see Section 12.4.1, with the following modifications:
具有密钥协议的ECDH通过与ECDH相同的参数进行参数化；见第12.4.1节，并进行以下修改：
o Key Wrap Algorithm: Any of the key wrap algorithms defined in Section 12.2.1 are supported. The size of the key used for the key wrap algorithm is fed into the KDF. The set of identifiers are found in Table 20.
o 密钥包裹算法：支持第12.2.1节中定义的任何密钥包裹算法。密钥包裹算法使用的密钥大小被输入KDF。标识符集见表20。
+-----------+-------+---------+------------+--------+---------------+
| Name | Value | KDF | Ephemeral- | Key | Description |
| | | | Static | Wrap | |
+-----------+-------+---------+------------+--------+---------------+
| ECDH-ES + | -29 | HKDF - | yes | A128KW | ECDH ES w/ |
| A128KW | | SHA-256 | | | Concat KDF |
| | | | | | and AES Key |
| | | | | | Wrap w/ |
| | | | | | 128-bit key |
| | | | | | |
| ECDH-ES + | -30 | HKDF - | yes | A192KW | ECDH ES w/ |
| A192KW | | SHA-256 | | | Concat KDF |
| | | | | | and AES Key |
| | | | | | Wrap w/ |
| | | | | | 192-bit key |
| | | | | | |
| ECDH-ES + | -31 | HKDF - | yes | A256KW | ECDH ES w/ |
| A256KW | | SHA-256 | | | Concat KDF |
| | | | | | and AES Key |
| | | | | | Wrap w/ |
| | | | | | 256-bit key |
| | | | | | |
| ECDH-SS + | -32 | HKDF - | no | A128KW | ECDH SS w/ |
| A128KW | | SHA-256 | | | Concat KDF |
| | | | | | and AES Key |
| | | | | | Wrap w/ |
| | | | | | 128-bit key |
| | | | | | |
| ECDH-SS + | -33 | HKDF - | no | A192KW | ECDH SS w/ |
| A192KW | | SHA-256 | | | Concat KDF |
| | | | | | and AES Key |
| | | | | | Wrap w/ |
| | | | | | 192-bit key |
| | | | | | |
| ECDH-SS + | -34 | HKDF - | no | A256KW | ECDH SS w/ |
| A256KW | | SHA-256 | | | Concat KDF |
| | | | | | and AES Key |
| | | | | | Wrap w/ |
| | | | | | 256-bit key |
+-----------+-------+---------+------------+--------+---------------+
+-----------+-------+---------+------------+--------+---------------+
| Name | Value | KDF | Ephemeral- | Key | Description |
| | | | Static | Wrap | |
+-----------+-------+---------+------------+--------+---------------+
| ECDH-ES + | -29 | HKDF - | yes | A128KW | ECDH ES w/ |
| A128KW | | SHA-256 | | | Concat KDF |
| | | | | | and AES Key |
| | | | | | Wrap w/ |
| | | | | | 128-bit key |
| | | | | | |
| ECDH-ES + | -30 | HKDF - | yes | A192KW | ECDH ES w/ |
| A192KW | | SHA-256 | | | Concat KDF |
| | | | | | and AES Key |
| | | | | | Wrap w/ |
| | | | | | 192-bit key |
| | | | | | |
| ECDH-ES + | -31 | HKDF - | yes | A256KW | ECDH ES w/ |
| A256KW | | SHA-256 | | | Concat KDF |
| | | | | | and AES Key |
| | | | | | Wrap w/ |
| | | | | | 256-bit key |
| | | | | | |
| ECDH-SS + | -32 | HKDF - | no | A128KW | ECDH SS w/ |
| A128KW | | SHA-256 | | | Concat KDF |
| | | | | | and AES Key |
| | | | | | Wrap w/ |
| | | | | | 128-bit key |
| | | | | | |
| ECDH-SS + | -33 | HKDF - | no | A192KW | ECDH SS w/ |
| A192KW | | SHA-256 | | | Concat KDF |
| | | | | | and AES Key |
| | | | | | Wrap w/ |
| | | | | | 192-bit key |
| | | | | | |
| ECDH-SS + | -34 | HKDF - | no | A256KW | ECDH SS w/ |
| A256KW | | SHA-256 | | | Concat KDF |
| | | | | | and AES Key |
| | | | | | Wrap w/ |
| | | | | | 256-bit key |
+-----------+-------+---------+------------+--------+---------------+
Table 20: ECDH Algorithm Values with Key Wrap
表20：带密钥换行的ECDH算法值
When using a COSE key for this algorithm, the following checks are made:
使用此算法的COSE密钥时，将进行以下检查：
o The 'kty' field MUST be present, and it MUST be 'EC2' or 'OKP'.
o “kty”字段必须存在，并且必须是“EC2”或“OKP”。
o If the 'alg' field is present, it MUST match the key agreement algorithm being used.
o 如果存在“alg”字段，则它必须与正在使用的密钥协商算法相匹配。
o If the 'key_ops' field is present, it MUST include 'derive key' or 'derive bits' for the private key.
o 如果“key_ops”字段存在，则它必须包含私钥的“派生密钥”或“派生位”。
o If the 'key_ops' field is present, it MUST be empty for the public key.
o 如果存在“key_ops”字段，则公钥字段必须为空。
The COSE_Key object defines a way to hold a single key object. It is still required that the members of individual key types be defined. This section of the document is where we define an initial set of members for specific key types.
COSE_Key对象定义了一种保存单个Key对象的方法。仍然需要定义各个键类型的成员。文档的这一部分是我们为特定键类型定义初始成员集的地方。
For each of the key types, we define both public and private members. The public members are what is transmitted to others for their usage. Private members allow for the archival of keys by individuals. However, there are some circumstances in which private keys may be distributed to entities in a protocol. Examples include: entities that have poor random number generation, centralized key creation for multi-cast type operations, and protocols in which a shared secret is used as a bearer token for authorization purposes.
对于每种密钥类型，我们都定义了公共成员和私有成员。公共成员是为其使用而传输给他人的内容。私人成员允许个人存档密钥。然而，在某些情况下，私钥可以分发给协议中的实体。示例包括：随机数生成较差的实体、多播类型操作的集中式密钥创建，以及将共享密钥用作承载令牌以进行授权的协议。
Key types are identified by the 'kty' member of the COSE_Key object. In this document, we define four values for the member:
密钥类型由COSE_密钥对象的“kty”成员标识。在本文档中，我们为成员定义了四个值：
+-----------+-------+-----------------------------------------------+
| Name | Value | Description |
+-----------+-------+-----------------------------------------------+
| OKP | 1 | Octet Key Pair |
| EC2 | 2 | Elliptic Curve Keys w/ x- and y-coordinate |
| | | pair |
| Symmetric | 4 | Symmetric Keys |
| Reserved | 0 | This value is reserved |
+-----------+-------+-----------------------------------------------+
+-----------+-------+-----------------------------------------------+
| Name | Value | Description |
+-----------+-------+-----------------------------------------------+
| OKP | 1 | Octet Key Pair |
| EC2 | 2 | Elliptic Curve Keys w/ x- and y-coordinate |
| | | pair |
| Symmetric | 4 | Symmetric Keys |
| Reserved | 0 | This value is reserved |
+-----------+-------+-----------------------------------------------+
Table 21: Key Type Values
表21：键类型值
Two different key structures are defined for elliptic curve keys. One version uses both an x-coordinate and a y-coordinate, potentially with point compression ('EC2'). This is the traditional EC point representation that is used in [RFC5480]. The other version uses only the x-coordinate as the y-coordinate is either to be recomputed or not needed for the key agreement operation ('OKP').
椭圆曲线密钥定义了两种不同的密钥结构。一个版本同时使用x坐标和y坐标，可能使用点压缩（“EC2”）。这是[RFC5480]中使用的传统EC点表示法。另一个版本仅使用x坐标，因为密钥协议操作（“OKP”）需要重新计算或不需要y坐标。
Applications MUST check that the curve and the key type are consistent and reject a key if they are not.
应用程序必须检查曲线和关键点类型是否一致，如果不一致，则拒绝关键点。
+---------+-------+----------+------------------------------------+
| Name | Value | Key Type | Description |
+---------+-------+----------+------------------------------------+
| P-256 | 1 | EC2 | NIST P-256 also known as secp256r1 |
| P-384 | 2 | EC2 | NIST P-384 also known as secp384r1 |
| P-521 | 3 | EC2 | NIST P-521 also known as secp521r1 |
| X25519 | 4 | OKP | X25519 for use w/ ECDH only |
| X448 | 5 | OKP | X448 for use w/ ECDH only |
| Ed25519 | 6 | OKP | Ed25519 for use w/ EdDSA only |
| Ed448 | 7 | OKP | Ed448 for use w/ EdDSA only |
+---------+-------+----------+------------------------------------+
+---------+-------+----------+------------------------------------+
| Name | Value | Key Type | Description |
+---------+-------+----------+------------------------------------+
| P-256 | 1 | EC2 | NIST P-256 also known as secp256r1 |
| P-384 | 2 | EC2 | NIST P-384 also known as secp384r1 |
| P-521 | 3 | EC2 | NIST P-521 also known as secp521r1 |
| X25519 | 4 | OKP | X25519 for use w/ ECDH only |
| X448 | 5 | OKP | X448 for use w/ ECDH only |
| Ed25519 | 6 | OKP | Ed25519 for use w/ EdDSA only |
| Ed448 | 7 | OKP | Ed448 for use w/ EdDSA only |
+---------+-------+----------+------------------------------------+
Table 22: Elliptic Curves
表22：椭圆曲线
The traditional way of sending ECs has been to send either both the x-coordinate and y-coordinate or the x-coordinate and a sign bit for the y-coordinate. The latter encoding has not been recommended in the IETF due to potential IPR issues. However, for operations in constrained environments, the ability to shrink a message by not sending the y-coordinate is potentially useful.
发送ECs的传统方式是同时发送x坐标和y坐标，或者发送x坐标和y坐标的符号位。由于潜在的知识产权问题，IETF中不建议使用后一种编码。但是，对于受限环境中的操作，通过不发送y坐标来收缩消息的功能可能非常有用。
For EC keys with both coordinates, the 'kty' member is set to 2 (EC2). The key parameters defined in this section are summarized in Table 23. The members that are defined for this key type are:
对于具有两个坐标的EC键，“kty”成员设置为2（EC2）。表23总结了本节中定义的关键参数。为此键类型定义的成员包括：
crv: This contains an identifier of the curve to be used with the key. The curves defined in this document for this key type can be found in Table 22. Other curves may be registered in the future, and private curves can be used as well.
crv：包含要与键一起使用的曲线的标识符。本文件中定义的该键类型的曲线见表22。将来可能会注册其他曲线，也可以使用专用曲线。
x: This contains the x-coordinate for the EC point. The integer is converted to an octet string as defined in [SEC1]. Leading zero octets MUST be preserved.
x：包含EC点的x坐标。整数转换为[SEC1]中定义的八位字节字符串。必须保留前导零八位字节。
y: This contains either the sign bit or the value of the y-coordinate for the EC point. When encoding the value y, the integer is converted to an octet string (as defined in [SEC1]) and encoded as a CBOR bstr. Leading zero octets MUST be preserved. The compressed point encoding is also supported. Compute the sign bit as laid out in the Elliptic-Curve-Point-to-Octet-String Conversion function of [SEC1]. If the sign bit is zero, then encode y as a CBOR false value; otherwise, encode y as a CBOR true value. The encoding of the infinity point is not supported.
y：包含符号位或EC点的y坐标值。对值y进行编码时，整数转换为八位字节字符串（如[SEC1]中所定义），并编码为CBOR bstr。必须保留前导零八位字节。还支持压缩点编码。按照[SEC1]的椭圆曲线点到八位字符串转换函数计算符号位。如果符号位为零，则将y编码为CBOR假值；否则，将y编码为CBOR真值。不支持无穷远点的编码。
d: This contains the private key.
d:这包含私钥。
For public keys, it is REQUIRED that 'crv', 'x', and 'y' be present in the structure. For private keys, it is REQUIRED that 'crv' and 'd' be present in the structure. For private keys, it is RECOMMENDED that 'x' and 'y' also be present, but they can be recomputed from the required elements and omitting them saves on space.
对于公钥，要求结构中存在“crv”、“x”和“y”。对于私钥，要求结构中存在“crv”和“d”。对于私钥，建议还存在“x”和“y”，但可以从所需元素重新计算它们，省略它们可以节省空间。
+-------+------+-------+--------+-----------------------------------+
| Key | Name | Label | CBOR | Description |
| Type | | | Type | |
+-------+------+-------+--------+-----------------------------------+
| 2 | crv | -1 | int / | EC identifier - Taken from the |
| | | | tstr | "COSE Elliptic Curves" registry |
| 2 | x | -2 | bstr | x-coordinate |
| 2 | y | -3 | bstr / | y-coordinate |
| | | | bool | |
| 2 | d | -4 | bstr | Private key |
+-------+------+-------+--------+-----------------------------------+
+-------+------+-------+--------+-----------------------------------+
| Key | Name | Label | CBOR | Description |
| Type | | | Type | |
+-------+------+-------+--------+-----------------------------------+
| 2 | crv | -1 | int / | EC identifier - Taken from the |
| | | | tstr | "COSE Elliptic Curves" registry |
| 2 | x | -2 | bstr | x-coordinate |
| 2 | y | -3 | bstr / | y-coordinate |
| | | | bool | |
| 2 | d | -4 | bstr | Private key |
+-------+------+-------+--------+-----------------------------------+
Table 23: EC Key Parameters
表23：EC关键参数
A new key type is defined for Octet Key Pairs (OKP). Do not assume that keys using this type are elliptic curves. This key type could be used for other curve types (for example, mathematics based on hyper-elliptic surfaces).
为八位字节密钥对（OKP）定义了一种新的密钥类型。不要假设使用此类型的键是椭圆曲线。此键类型可用于其他曲线类型（例如，基于超椭圆曲面的数学）。
The key parameters defined in this section are summarized in Table 24. The members that are defined for this key type are:
表24总结了本节中定义的关键参数。为此键类型定义的成员包括：
crv: This contains an identifier of the curve to be used with the key. The curves defined in this document for this key type can be found in Table 22. Other curves may be registered in the future and private curves can be used as well.
crv：包含要与键一起使用的曲线的标识符。本文件中定义的该键类型的曲线见表22。将来可能会注册其他曲线，也可以使用专用曲线。
x: This contains the x-coordinate for the EC point. The octet string represents a little-endian encoding of x.
x：包含EC点的x坐标。八位字节字符串表示x的一个小的endian编码。
d: This contains the private key.
d:这包含私钥。
For public keys, it is REQUIRED that 'crv' and 'x' be present in the structure. For private keys, it is REQUIRED that 'crv' and 'd' be present in the structure. For private keys, it is RECOMMENDED that 'x' also be present, but it can be recomputed from the required elements and omitting it saves on space.
对于公钥，要求结构中存在“crv”和“x”。对于私钥，要求结构中存在“crv”和“d”。对于私钥，建议还存在“x”，但可以从所需元素重新计算它，省略它可以节省空间。
+------+-------+-------+--------+-----------------------------------+
| Name | Key | Label | Type | Description |
| | Type | | | |
+------+-------+-------+--------+-----------------------------------+
| crv | 1 | -1 | int / | EC identifier - Taken from the |
| | | | tstr | "COSE Key Common Parameters" |
| | | | | registry |
| x | 1 | -2 | bstr | x-coordinate |
| d | 1 | -4 | bstr | Private key |
+------+-------+-------+--------+-----------------------------------+
+------+-------+-------+--------+-----------------------------------+
| Name | Key | Label | Type | Description |
| | Type | | | |
+------+-------+-------+--------+-----------------------------------+
| crv | 1 | -1 | int / | EC identifier - Taken from the |
| | | | tstr | "COSE Key Common Parameters" |
| | | | | registry |
| x | 1 | -2 | bstr | x-coordinate |
| d | 1 | -4 | bstr | Private key |
+------+-------+-------+--------+-----------------------------------+
Table 24: Octet Key Pair Parameters
表24：八位字节密钥对参数
Occasionally it is required that a symmetric key be transported between entities. This key structure allows for that to happen.
有时需要在实体之间传输对称密钥。这种关键结构允许这种情况发生。
For symmetric keys, the 'kty' member is set to 4 ('Symmetric'). The member that is defined for this key type is:
对于对称密钥，“kty”成员设置为4（“对称”）。为此键类型定义的成员是：
k: This contains the value of the key.
k:这包含键的值。
This key structure does not have a form that contains only public members. As it is expected that this key structure is going to be transmitted, care must be taken that it is never transmitted accidentally or insecurely. For symmetric keys, it is REQUIRED that 'k' be present in the structure.
此密钥结构没有只包含公共成员的表单。由于预计将要传输此密钥结构，因此必须注意，决不能意外或不安全地传输此密钥结构。对于对称密钥，要求结构中存在“k”。
+------+----------+-------+------+-------------+
| Name | Key Type | Label | Type | Description |
+------+----------+-------+------+-------------+
| k | 4 | -1 | bstr | Key Value |
+------+----------+-------+------+-------------+
+------+----------+-------+------+-------------+
| Name | Key Type | Label | Type | Description |
+------+----------+-------+------+-------------+
| k | 4 | -1 | bstr | Key Value |
+------+----------+-------+------+-------------+
Table 25: Symmetric Key Parameters
表25：对称密钥参数
There has been an attempt to limit the number of places where the document needs to impose restrictions on how the CBOR Encoder needs to work. We have managed to narrow it down to the following restrictions:
有人试图限制文件需要限制CBOR编码器工作方式的地方数量。我们已设法将其缩小到以下限制：
o The restriction applies to the encoding of the Sig_structure, the Enc_structure, and the MAC_structure.
o 该限制适用于Sig_结构、Enc_结构和MAC_结构的编码。
o The rules for "Canonical CBOR" (Section 3.9 of RFC 7049) MUST be used in these locations. The main rule that needs to be enforced is that all lengths in these structures MUST be encoded such that they are using definite lengths, and the minimum length encoding is used.
o 这些位置必须使用“规范CBOR”（RFC 7049第3.9节）规则。需要强制执行的主要规则是，必须对这些结构中的所有长度进行编码，以便它们使用确定的长度，并且使用最小长度编码。
o Applications MUST NOT generate messages with the same label used twice as a key in a single map. Applications MUST NOT parse and process messages with the same label used twice as a key in a single map. Applications can enforce the parse and process requirement by using parsers that will fail the parse step or by using parsers that will pass all keys to the application, and the application can perform the check for duplicate keys.
o 应用程序不得使用同一标签生成消息，该标签在单个映射中用作两次键。应用程序不得解析和处理具有同一标签的消息，该标签在单个映射中用作两次键。应用程序可以通过使用将使解析步骤失败的解析器，或者通过使用将所有密钥传递给应用程序的解析器来强制执行解析和处理要求，并且应用程序可以执行重复密钥的检查。
This document is designed to provide a set of security services, but not implementation requirements for specific usage. The interoperability requirements are provided for how each of the individual services are used and how the algorithms are to be used for interoperability. The requirements about which algorithms and which services are needed are deferred to each application.
本文档旨在提供一组安全服务，但不是特定用途的实现要求。互操作性要求是针对如何使用每个单独的服务以及如何将算法用于互操作性而提供的。关于需要哪些算法和哪些服务的需求将推迟到每个应用程序。
An example of a profile can be found in [OSCOAP] where two profiles are being developed. One is for carrying content by itself, and the other is for carrying content in combination with CoAP headers.
在[OSCOAP]中可以找到一个配置文件的示例，其中正在开发两个配置文件。一个用于单独承载内容，另一个用于结合CoAP头承载内容。
It is intended that a profile of this document be created that defines the interoperability requirements for that specific application. This section provides a set of guidelines and topics that need to be considered when profiling this document.
本文档旨在创建一个概要文件，定义该特定应用程序的互操作性要求。本节提供了在分析本文档时需要考虑的一组准则和主题。
o Applications need to determine the set of messages defined in this document that they will be using. The set of messages corresponds fairly directly to the set of security services that are needed and to the security levels needed.
o 应用程序需要确定他们将使用的在此文档中定义的消息集。消息集相当直接地对应于所需的安全服务集和所需的安全级别。
o Applications may define new header parameters for a specific purpose. Applications will often times select specific header parameters to use or not to use. For example, an application would normally state a preference for using either the IV or the Partial IV parameter. If the Partial IV parameter is specified, then the application would also need to define how the fixed portion of the IV would be determined.
o 应用程序可以为特定目的定义新的头参数。应用程序通常会多次选择要使用或不使用的特定标头参数。例如，应用程序通常会声明使用IV或部分IV参数的首选项。如果指定了Partial IV参数，那么应用程序还需要定义如何确定IV的固定部分。
o When applications use externally defined authenticated data, they need to define how that data is encoded. This document assumes that the data will be provided as a byte stream. More information can be found in Section 4.3.
o 当应用程序使用外部定义的身份验证数据时，它们需要定义该数据的编码方式。本文档假设数据将作为字节流提供。更多信息见第4.3节。
o Applications need to determine the set of security algorithms that are to be used. When selecting the algorithms to be used as the mandatory-to-implement set, consideration should be given to choosing different types of algorithms when two are chosen for a specific purpose. An example of this would be choosing HMAC-SHA512 and AES-CMAC as different MAC algorithms; the construction is vastly different between these two algorithms. This means that a weakening of one algorithm would be unlikely to lead to a weakening of the other algorithms. Of course, these algorithms do not provide the same level of security and thus may not be comparable for the desired security functionality.
o 应用程序需要确定要使用的安全算法集。当选择算法作为强制实现集合时，应考虑选择不同类型的算法（当为特定目的选择两种算法时）。例如，选择HMAC-SHA512和AES-CMAC作为不同的MAC算法；这两种算法的结构有很大的不同。这意味着削弱一种算法不太可能导致削弱其他算法。当然，这些算法不提供相同级别的安全性，因此可能无法与所需的安全功能进行比较。
o Applications may need to provide some type of negotiation or discovery method if multiple algorithms or message structures are permitted. The method can be as simple as requiring preconfiguration of the set of algorithms to providing a discovery method built into the protocol. S/MIME provided a number of different ways to approach the problem that applications could follow:
o 如果允许使用多种算法或消息结构，应用程序可能需要提供某种类型的协商或发现方法。该方法可以简单到要求预先配置一组算法，以提供内置于协议中的发现方法。S/MIME提供了许多不同的方法来解决应用程序可能遇到的问题：
* Advertising in the message (S/MIME capabilities) [RFC5751].
* 消息中的广告（S/MIME功能）[RFC5751]。
* Advertising in the certificate (capabilities extension) [RFC4262].
* 证书中的广告（功能扩展）[RFC4262]。
* Minimum requirements for the S/MIME, which have been updated over time [RFC2633] [RFC5751] (note that [RFC2633] has been obsoleted by [RFC5751]).
* S/MIME的最低要求，已随时间更新[RFC2633][RFC5751]（注意，[RFC2633]已被[RFC5751]淘汰）。
IANA has assigned the following tags from the "CBOR Tags" registry. The tags for COSE_Sign1, COSE_Encrypt0, and COSE_Mac0 were assigned in the 1 to 23 value range (one byte long when encoded). The tags for COSE_Sign, COSE_Encrypt, and COSE_Mac were assigned in the 24 to 255 value range (two bytes long when encoded).
IANA已从“CBOR标记”注册表中分配了以下标记。COSE_Sign1、COSE_Encrypt0和COSE_Mac0的标记分配在1到23的值范围内（编码时为一个字节长）。COSE_Sign、COSE_Encrypt和COSE_Mac的标记分配在24到255的值范围内（编码时长两个字节）。
The tags assigned are in Table 1.
分配的标签如表1所示。
IANA has created a new registry titled "COSE Header Parameters". The registry has been created to use the "Expert Review Required" registration procedure [RFC8126]. Guidelines for the experts are provided in Section 16.11. It should be noted that, in addition to the expert review, some portions of the registry require a specification, potentially a Standards Track RFC, be supplied as well.
IANA创建了一个名为“COSE头参数”的新注册表。创建该登记册是为了使用“需要专家审查”登记程序[RFC8126]。专家指南见第16.11节。应注意的是，除了专家审查外，登记册的某些部分还需要提供规范，可能是标准跟踪RFC。
The columns of the registry are:
注册表的列包括：
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.
姓名：提供姓名是为了便于查阅和讨论注册条目。该值未在协议中使用。名称在表中必须是唯一的。
Label: This is the value used for the label. The label can be either an integer or a string. Registration in the table is based on the value of the label requested. Integer values between 1 and 255 and strings of length 1 are designated as "Standards Action". Integer values from 256 to 65535 and strings of length 2 are designated as "Specification Required". Integer values of greater than 65535 and strings of length greater than 2 are designated as "Expert Review". Integer values in the range -1 to -65536 are "delegated to the COSE Header Algorithm Parameters registry". Integer values less than -65536 are marked as private use.
标签：这是用于标签的值。标签可以是整数或字符串。表中的注册基于所请求标签的值。介于1和255之间的整数值以及长度为1的字符串被指定为“标准操作”。256到65535之间的整数值和长度为2的字符串被指定为“所需规格”。大于65535的整数值和长度大于2的字符串被指定为“专家评审”。范围为-1到-65536的整数值“委托给COSE头算法参数注册表”。小于-65536的整数值标记为专用。
Value Type: This contains the CBOR type for the value portion of the label.
值类型：包含标签值部分的CBOR类型。
Value Registry: This contains a pointer to the registry used to contain values where the set is limited.
值注册表：它包含一个指向注册表的指针，该注册表用于包含集合受限的值。
Description: This contains a brief description of the header field.
描述：包含标题字段的简要描述。
Reference: This contains a pointer to the specification defining the header field (where public).
引用：它包含一个指向定义标题字段（其中为public）的规范的指针。
The initial contents of the registry can be found in Tables 2 and 27. All of the entries in the "References" column of this registry point to this document.
登记册的初始内容见表2和27。此注册表“引用”列中的所有条目都指向此文档。
Additionally, the label of 0 is to be marked as 'Reserved'.
此外，0的标签将标记为“保留”。
IANA has created a new registry titled "COSE Header Algorithm Parameters". The registry uses the "Expert Review Required" registration procedure. Expert review guidelines are provided in Section 16.11.
IANA创建了一个名为“COSE头算法参数”的新注册表。登记处采用“需要专家审查”的登记程序。第16.11节提供了专家评审指南。
The columns of the registry are:
注册表的列包括：
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.
姓名：提供姓名是为了便于查阅和讨论注册条目。该值未在协议中使用。
Algorithm: The algorithm(s) that this registry entry is used for. This value is taken from the "COSE Algorithms" registry. Multiple algorithms can be specified in this entry. For the table, the algorithm/label pair MUST be unique.
算法：此注册表项用于的算法。该值取自“COSE算法”注册表。可以在此条目中指定多个算法。对于表，算法/标签对必须是唯一的。
Label: This is the value used for the label. The label is an integer in the range of -1 to -65536.
标签：这是用于标签的值。标签是一个介于-1到-65536之间的整数。
Type: This contains the CBOR type for the value portion of the label.
类型：包含标签值部分的CBOR类型。
Description: This contains a brief description of the header field.
描述：包含标题字段的简要描述。
Reference: This contains a pointer to the specification defining the header field (where public).
引用：它包含一个指向定义标题字段（其中为public）的规范的指针。
The initial contents of the registry can be found in Tables 13, 14, and 19. All of the entries in the "References" column of this registry point to this document.
注册表的初始内容见表13、14和19。此注册表“引用”列中的所有条目都指向此文档。
IANA has created a new registry titled "COSE Algorithms". The registry has been created to use the "Expert Review Required" registration procedure. Guidelines for the experts are provided in
IANA创建了一个名为“COSE算法”的新注册表。设立登记处是为了使用“需要专家审查”登记程序。专家指南见
Section 16.11. It should be noted that, in addition to the expert review, some portions of the registry require a specification, potentially a Standards Track RFC, be supplied as well.
第16.11节。应注意的是，除了专家审查外，登记册的某些部分还需要提供规范，可能是标准跟踪RFC。
The columns of the registry are:
注册表的列包括：
Name: A value that can be used to identify an algorithm in documents for easier comprehension. The name SHOULD be unique. However, the 'Value' field is what is used to identify the algorithm, not the 'name' field.
名称：可用于标识文档中的算法以便于理解的值。名称应该是唯一的。但是，“值”字段是用于标识算法的字段，而不是“名称”字段。
Value: The value to be used to identify this algorithm. Algorithm values MUST be unique. The value can be a positive integer, a negative integer, or a string. Integer values between -256 and 255 and strings of length 1 are designated as "Standards Action". Integer values from -65536 to 65535 and strings of length 2 are designated as "Specification Required". Integer values greater than 65535 and strings of length greater than 2 are designated as "Expert Review". Integer values less than -65536 are marked as private use.
值：用于标识此算法的值。算法值必须是唯一的。该值可以是正整数、负整数或字符串。介于-256和255之间的整数值以及长度为1的字符串被指定为“标准操作”。从-65536到65535的整数值和长度为2的字符串被指定为“所需规格”。大于65535的整数值和长度大于2的字符串被指定为“专家评审”。小于-65536的整数值标记为专用。
Description: A short description of the algorithm.
描述：算法的简短描述。
Reference: A document where the algorithm is defined (if publicly available).
参考：定义算法的文档（如果公开提供）。
Recommended: Does the IETF have a consensus recommendation to use the algorithm? The legal values are 'Yes', 'No', and 'Deprecated'.
建议：IETF是否有使用该算法的一致建议？合法值为“是”、“否”和“已弃用”。
The initial contents of the registry can be found in Tables 5, 6, 7, 8, 9, 10, 11, 15, 16, 17, 18, and 20. All of the entries in the "References" column of this registry point to this document. All of the entries in the "Recommended" column are set to "Yes".
登记册的初始内容见表5、6、7、8、9、10、11、15、16、17、18和20。此注册表“引用”列中的所有条目都指向此文档。“推荐”列中的所有条目都设置为“是”。
Additionally, the label of 0 is to be marked as 'Reserved'.
此外，0的标签将标记为“保留”。
NOTE: The assignment of algorithm identifiers in this document was done so that positive numbers were used for the first layer objects (COSE_Sign, COSE_Sign1, COSE_Encrypt, COSE_Encrypt0, COSE_Mac, and COSE_Mac0). Negative numbers were used for second layer objects (COSE_Signature and COSE_recipient). Expert reviewers should consider this practice, but are not expected to be restricted by this precedent.
注：本文件中算法标识符的分配是为了将正数用于第一层对象（COSE_符号、COSE_符号1、COSE_加密、COSE_加密0、COSE_Mac和COSE_Mac0）。负数用于第二层对象（COSE_签名和COSE_收件人）。专家审稿人应考虑这一做法，但不应被这一先例所限制。
IANA has created a new registry titled "COSE Key Common Parameters". The registry has been created to use the "Expert Review Required" registration procedure. Guidelines for the experts are provided in Section 16.11. It should be noted that, in addition to the expert review, some portions of the registry require a specification, potentially a Standards Track RFC, be supplied as well.
IANA创建了一个名为“COSE密钥公共参数”的新注册表。设立登记处是为了使用“需要专家审查”登记程序。专家指南见第16.11节。应注意的是，除了专家审查外，登记册的某些部分还需要提供规范，可能是标准跟踪RFC。
The columns of the registry are:
注册表的列包括：
Name: This is a descriptive name that enables easier reference to the item. It is not used in the encoding.
名称：这是一个描述性名称，可以更轻松地引用项目。它不用于编码。
Label: The value to be used to identify this algorithm. Key map labels MUST be unique. The label can be a positive integer, a negative integer, or a string. Integer values between 0 and 255 and strings of length 1 are designated as "Standards Action". Integer values from 256 to 65535 and strings of length 2 are designated as "Specification Required". Integer values of greater than 65535 and strings of length greater than 2 are designated as "Expert Review". Integer values in the range -65536 to -1 are "used for key parameters specific to a single algorithm delegated to the COSE Key Type Parameters registry". Integer values less than -65536 are marked as private use.
标签：用于标识此算法的值。关键地图标签必须是唯一的。标签可以是正整数、负整数或字符串。0到255之间的整数值和长度为1的字符串被指定为“标准操作”。256到65535之间的整数值和长度为2的字符串被指定为“所需规格”。大于65535的整数值和长度大于2的字符串被指定为“专家评审”。范围-65536到-1的整数值“用于指定给COSE密钥类型参数注册表的单个算法的密钥参数”。小于-65536的整数值标记为专用。
CBOR Type: This field contains the CBOR type for the field.
CBOR类型：此字段包含该字段的CBOR类型。
Value Registry: This field denotes the registry that values come from, if one exists.
值注册表：此字段表示值来自的注册表（如果存在）。
Description: This field contains a brief description for the field.
说明：此字段包含该字段的简要说明。
Reference: This contains a pointer to the public specification for the field if one exists.
引用：如果存在字段的公共规范，则包含指向该字段公共规范的指针。
This registry has been initially populated by the values in Table 3. All of the entries in the "References" column of this registry point to this document.
该注册表最初由表3中的值填充。此注册表“引用”列中的所有条目都指向此文档。
IANA has created a new registry titled "COSE Key Type Parameters". The registry has been created to use the "Expert Review Required" registration procedure. Expert review guidelines are provided in Section 16.11.
IANA创建了一个名为“COSE密钥类型参数”的新注册表。设立登记处是为了使用“需要专家审查”登记程序。第16.11节提供了专家评审指南。
The columns of the table are:
表中的列为：
Key Type: This field contains a descriptive string of a key type. This should be a value that is in the "COSE Key Common Parameters" registry and is placed in the 'kty' field of a COSE Key structure.
键类型：此字段包含键类型的描述性字符串。这应该是“COSE密钥公共参数”注册表中的值，并放置在COSE密钥结构的“kty”字段中。
Name: This is a descriptive name that enables easier reference to the item. It is not used in the encoding.
名称：这是一个描述性名称，可以更轻松地引用项目。它不用于编码。
Label: The label is to be unique for every value of key type. The range of values is from -65536 to -1. Labels are expected to be reused for different keys.
标签：标签对于每个键类型的值都是唯一的。值的范围为-65536到-1。标签将被重新用于不同的键。
CBOR Type: This field contains the CBOR type for the field.
CBOR类型：此字段包含该字段的CBOR类型。
Description: This field contains a brief description for the field.
说明：此字段包含该字段的简要说明。
Reference: This contains a pointer to the public specification for the field if one exists.
引用：如果存在字段的公共规范，则包含指向该字段公共规范的指针。
This registry has been initially populated by the values in Tables 23, 24, and 25. All of the entries in the "References" column of this registry point to this document.
该注册表最初由表23、24和25中的值填充。此注册表“引用”列中的所有条目都指向此文档。
IANA has created a new registry titled "COSE Key Types". The registry has been created to use the "Expert Review Required" registration procedure. Expert review guidelines are provided in Section 16.11.
IANA创建了一个名为“COSE密钥类型”的新注册表。设立登记处是为了使用“需要专家审查”登记程序。第16.11节提供了专家评审指南。
The columns of this table are:
此表的列为：
Name: This is a descriptive name that enables easier reference to the item. The name MUST be unique. It is not used in the encoding.
名称：这是一个描述性名称，可以更轻松地引用项目。名称必须是唯一的。它不用于编码。
Value: This is the value used to identify the curve. These values MUST be unique. The value can be a positive integer, a negative integer, or a string.
值：这是用于标识曲线的值。这些值必须是唯一的。该值可以是正整数、负整数或字符串。
Description: This field contains a brief description of the curve.
描述：此字段包含曲线的简要描述。
References: This contains a pointer to the public specification for the curve if one exists.
引用：如果存在曲线的公共规范，则包含指向该规范的指针。
This registry has been initially populated by the values in Table 21. The specification column for all of these entries will be this document.
该注册表最初由表21中的值填充。所有这些条目的规格栏将在本文件中列出。
IANA has created a new registry titled "COSE Elliptic Curves". The registry has been created to use the "Expert Review Required" registration procedure. Guidelines for the experts are provided in Section 16.11. It should be noted that, in addition to the expert review, some portions of the registry require a specification, potentially a Standards Track RFC, be supplied as well.
IANA创建了一个名为“COSE椭圆曲线”的新注册表。设立登记处是为了使用“需要专家审查”登记程序。专家指南见第16.11节。应注意的是，除了专家审查外，登记册的某些部分还需要提供规范，可能是标准跟踪RFC。
The columns of the table are:
表中的列为：
Name: This is a descriptive name that enables easier reference to the item. It is not used in the encoding.
名称：这是一个描述性名称，可以更轻松地引用项目。它不用于编码。
Value: This is the value used to identify the curve. These values MUST be unique. The integer values from -256 to 255 are designated as "Standards Action". The integer values from 256 to 65535 and -65536 to -257 are designated as "Specification Required". Integer values over 65535 are designated as "Expert Review". Integer values less than -65536 are marked as private use.
值：这是用于标识曲线的值。这些值必须是唯一的。从-256到255的整数值被指定为“标准操作”。256到65535和-65536到-257之间的整数值被指定为“所需规格”。大于65535的整数值被指定为“专家评审”。小于-65536的整数值标记为专用。
Key Type: This designates the key type(s) that can be used with this curve.
关键点类型：指定可用于此曲线的关键点类型。
Description: This field contains a brief description of the curve.
描述：此字段包含曲线的简要描述。
Reference: This contains a pointer to the public specification for the curve if one exists.
参考：如果存在曲线的公共规范，则包含指向该规范的指针。
Recommended: Does the IETF have a consensus recommendation to use the algorithm? The legal values are 'Yes', 'No', and 'Deprecated'.
建议：IETF是否有使用该算法的一致建议？合法值为“是”、“否”和“已弃用”。
This registry has been initially populated by the values in Table 22. All of the entries in the "References" column of this registry point to this document. All of the entries in the "Recommended" column are set to "Yes".
该注册表最初由表22中的值填充。此注册表“引用”列中的所有条目都指向此文档。“推荐”列中的所有条目都设置为“是”。
This section registers the 'application/cose' media type in the "Media Types" registry. These media types are used to indicate that the content is a COSE message.
本节在“媒体类型”注册表中注册“应用程序/cose”媒体类型。这些媒体类型用于指示内容是COSE消息。
Type name: application
类型名称：应用程序
Subtype name: cose
子类型名称：cose
Required parameters: N/A
所需参数：不适用
Optional parameters: cose-type
可选参数：cose类型
Encoding considerations: binary
编码注意事项：二进制
Security considerations: See the Security Considerations section of RFC 8152.
安全注意事项：请参阅RFC 8152的安全注意事项部分。
Interoperability considerations: N/A
互操作性注意事项：不适用
Published specification: RFC 8152
已发布规范：RFC 8152
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): cbor
* 文件扩展名：cbor
* Macintosh file type code(s): N/A
* Macintosh文件类型代码：不适用
Person & email address to contact for further information: iesg@ietf.org
联系人和电子邮件地址，以获取更多信息：iesg@ietf.org
Intended usage: COMMON
预期用途：普通
Restrictions on usage: N/A
使用限制：不适用
Author: Jim Schaad, ietf@augustcellars.com
作者：Jim Schaad，ietf@augustcellars.com
Change Controller: IESG
更改控制器：IESG
Provisional registration? No
临时登记？不
This section registers the 'application/cose-key' and 'application/ cose-key-set' media types in the "Media Types" registry. These media types are used to indicate, respectively, that content is a COSE_Key or COSE_KeySet object.
本节在“媒体类型”注册表中注册“应用程序/cose密钥”和“应用程序/cose密钥集”媒体类型。这些媒体类型分别用于指示内容是COSE_键或COSE_键集对象。
The template for registering 'application/cose-key' is:
注册“应用程序/cose密钥”的模板为：
Type name: application
类型名称：应用程序
Subtype name: cose-key
子类型名称：cose密钥
Required parameters: N/A
所需参数：不适用
Optional parameters: N/A
可选参数：不适用
Encoding considerations: binary
编码注意事项：二进制
Security considerations: See the Security Considerations section of RFC 8152.
安全注意事项：请参阅RFC 8152的安全注意事项部分。
Interoperability considerations: N/A
互操作性注意事项：不适用
Published specification: RFC 8152
已发布规范：RFC 8152
Applications that use this media type: Distribution of COSE based keys for IoT applications.
使用此媒体类型的应用程序：为物联网应用程序分发基于COSE的密钥。
Fragment identifier considerations: N/A
片段标识符注意事项：不适用
Additional information:
其他信息：
* Deprecated alias names for this type: N/A
* 此类型的已弃用别名：不适用
* Magic number(s): N/A
* 幻数：不适用
* File extension(s): cbor
* 文件扩展名：cbor
* Macintosh file type code(s): N/A
* Macintosh文件类型代码：不适用
Person & email address to contact for further information: iesg@ietf.org
联系人和电子邮件地址，以获取更多信息：iesg@ietf.org
Intended usage: COMMON
预期用途：普通
Restrictions on usage: N/A
使用限制：不适用
Author: Jim Schaad, ietf@augustcellars.com
作者：Jim Schaad，ietf@augustcellars.com
Change Controller: IESG
更改控制器：IESG
Provisional registration? No
临时登记？不
The template for registering 'application/cose-key-set' is:
注册“应用程序/cose密钥集”的模板为：
Type name: application
类型名称：应用程序
Subtype name: cose-key-set
子类型名称：cose密钥集
Required parameters: N/A
所需参数：不适用
Optional parameters: N/A
可选参数：不适用
Encoding considerations: binary
编码注意事项：二进制
Security considerations: See the Security Considerations section of RFC 8152.
安全注意事项：请参阅RFC 8152的安全注意事项部分。
Interoperability considerations: N/A
互操作性注意事项：不适用
Published specification: RFC 8152
已发布规范：RFC 8152
Applications that use this media type: Distribution of COSE based keys for IoT applications.
使用此媒体类型的应用程序：为物联网应用程序分发基于COSE的密钥。
Fragment identifier considerations: N/A
片段标识符注意事项：不适用
Additional information:
其他信息：
* Deprecated alias names for this type: N/A
* 此类型的已弃用别名：不适用
* Magic number(s): N/A
* 幻数：不适用
* File extension(s): cbor
* 文件扩展名：cbor
* Macintosh file type code(s): N/A
* Macintosh文件类型代码：不适用
Person & email address to contact for further information: iesg@ietf.org
联系人和电子邮件地址，以获取更多信息：iesg@ietf.org
Intended usage: COMMON
预期用途：普通
Restrictions on usage: N/A
使用限制：不适用
Author: Jim Schaad, ietf@augustcellars.com
作者：Jim Schaad，ietf@augustcellars.com
Change Controller: IESG
更改控制器：IESG
Provisional registration? No
临时登记？不
IANA has added the following entries to the "CoAP Content-Formats" registry.
IANA已将以下条目添加到“CoAP内容格式”注册表中。
+--------------------------------------+----------+-----+-----------+
| Media Type | Encoding | ID | Reference |
+--------------------------------------+----------+-----+-----------+
| application/cose; cose-type="cose- | | 98 | [RFC8152] |
| sign" | | | |
| application/cose; cose-type="cose- | | 18 | [RFC8152] |
| sign1" | | | |
| application/cose; cose-type="cose- | | 96 | [RFC8152] |
| encrypt" | | | |
| application/cose; cose-type="cose- | | 16 | [RFC8152] |
| encrypt0" | | | |
| application/cose; cose-type="cose- | | 97 | [RFC8152] |
| mac" | | | |
| application/cose; cose-type="cose- | | 17 | [RFC8152] |
| mac0" | | | |
| application/cose-key | | 101 | [RFC8152] |
| application/cose-key-set | | 102 | [RFC8152] |
+--------------------------------------+----------+-----+-----------+
+--------------------------------------+----------+-----+-----------+
| Media Type | Encoding | ID | Reference |
+--------------------------------------+----------+-----+-----------+
| application/cose; cose-type="cose- | | 98 | [RFC8152] |
| sign" | | | |
| application/cose; cose-type="cose- | | 18 | [RFC8152] |
| sign1" | | | |
| application/cose; cose-type="cose- | | 96 | [RFC8152] |
| encrypt" | | | |
| application/cose; cose-type="cose- | | 16 | [RFC8152] |
| encrypt0" | | | |
| application/cose; cose-type="cose- | | 97 | [RFC8152] |
| mac" | | | |
| application/cose; cose-type="cose- | | 17 | [RFC8152] |
| mac0" | | | |
| application/cose-key | | 101 | [RFC8152] |
| application/cose-key-set | | 102 | [RFC8152] |
+--------------------------------------+----------+-----+-----------+
Table 26: CoAP Content-Formats for COSE
表26:COSE的CoAP内容格式
All of the IANA registries established in this document are defined as expert review. This section gives some general guidelines for what the experts should be looking for, but they are being designated as experts for a reason, so they should be given substantial latitude.
本文件中建立的所有IANA登记册均定义为专家评审。本节给出了专家应该寻找什么的一些一般指导原则，但他们被指定为专家是有原因的，因此应该给予他们很大的自由度。
Expert reviewers should take into consideration the following points:
专家审评员应考虑以下几点：
o Point squatting should be discouraged. Reviewers are encouraged to get sufficient information for registration requests to ensure that the usage is not going to duplicate one that is already registered, and that the point is likely to be used in
o 不鼓励点蹲。鼓励审核人员为注册请求获取足够的信息，以确保使用不会与已注册的重复，并且该点可能会在中使用
deployments. The zones tagged as private use are intended for testing purposes and closed environments; code points in other ranges should not be assigned for testing.
部署。标记为私人用途的区域用于测试目的和封闭环境；不应为测试分配其他范围内的代码点。
o Specifications are required for the standards track range of point assignment. Specifications should exist for specification required ranges, but early assignment before a specification is available is considered to be permissible. Specifications are needed for the first-come, first-serve range if they are expected to be used outside of closed environments in an interoperable way. When specifications are not provided, the description provided needs to have sufficient information to identify what the point is being used for.
o 指定点的标准轨道范围需要规范。规范要求的范围应存在规范，但在规范可用之前提前分配被认为是允许的。如果希望在封闭环境之外以可互操作的方式使用，则需要先到先得的服务范围的规范。当未提供规范时，所提供的说明需要有足够的信息来确定该点的用途。
o Experts should take into account the expected usage of fields when approving point assignment. The fact that there is a range for standards track documents does not mean that a standards track document cannot have points assigned outside of that range. The length of the encoded value should be weighed against how many code points of that length are left, the size of device it will be used on, and the number of code points left that encode to that size.
o 专家在批准点分配时应考虑字段的预期使用情况。标准跟踪文档存在一个范围这一事实并不意味着标准跟踪文档不能在该范围之外指定点。编码值的长度应与剩余的该长度代码点的数量、将在其上使用的设备的大小以及剩余的编码到该大小的代码点的数量进行权衡。
o When algorithms are registered, vanity registrations should be discouraged. One way to do this is to require registrations to provide additional documentation on security analysis of the algorithm. Another thing that should be considered is requesting an opinion on the algorithm from the Crypto Forum Research Group (CFRG). Algorithms that do not meet the security requirements of the community and the messages structures should not be registered.
o 当注册算法时，不鼓励虚荣注册。一种方法是要求注册提供关于算法安全性分析的附加文档。另一件需要考虑的事情是请求加密论坛研究小组（CFRG）对算法发表意见。不应注册不符合社区和消息结构安全要求的算法。
There are a number of security considerations that need to be taken into account by implementers of this specification. The security considerations that are specific to an individual algorithm are placed next to the description of the algorithm. While some considerations have been highlighted here, additional considerations may be found in the documents listed in the references.
本规范的实现者需要考虑许多安全方面的考虑。特定于单个算法的安全注意事项放在算法描述的旁边。虽然此处强调了一些注意事项，但在参考文献中列出的文件中可以找到其他注意事项。
Implementations need to protect the private key material for any individuals. There are some cases in this document that need to be highlighted on this issue.
实现需要保护任何个人的私钥资料。本文件中有一些案例需要在这个问题上加以强调。
o Using the same key for two different algorithms can leak information about the key. It is therefore recommended that keys be restricted to a single algorithm.
o 将同一密钥用于两种不同的算法可能会泄漏有关该密钥的信息。因此，建议将密钥限制为单一算法。
o Use of 'direct' as a recipient algorithm combined with a second recipient algorithm exposes the direct key to the second recipient.
o 将“direct”用作收件人算法，并与第二个收件人算法结合使用，将直接密钥公开给第二个收件人。
o Several of the algorithms in this document have limits on the number of times that a key can be used without leaking information about the key.
o 本文中的一些算法对密钥的使用次数有限制，而不会泄露密钥的相关信息。
The use of ECDH and direct plus KDF (with no key wrap) will not directly lead to the private key being leaked; the one way function of the KDF will prevent that. There is, however, a different issue that needs to be addressed. Having two recipients requires that the CEK be shared between two recipients. The second recipient therefore has a CEK that was derived from material that can be used for the weak proof of origin. The second recipient could create a message using the same CEK and send it to the first recipient; the first recipient would, for either static-static ECDH or direct plus KDF, make an assumption that the CEK could be used for proof of origin even though it is from the wrong entity. If the key wrap step is added, then no proof of origin is implied and this is not an issue.
使用ECDH和direct plus KDF（无密钥包装）不会直接导致私钥泄漏；KDF的单向功能将防止这种情况。然而，有一个不同的问题需要解决。有两个收件人需要在两个收件人之间共享CEK。因此，第二个接收者拥有一个CEK，该CEK来源于可用于弱原产地证明的材料。第二个收件人可以使用相同的CEK创建消息并将其发送给第一个收件人；对于静态ECDH或direct plus KDF，第一个接收人将假设CEK可用于原产地证明，即使它来自错误的实体。如果添加了密钥换行步骤，则不会暗示原产地证明，这不是问题。
Although it has been mentioned before, the use of a single key for multiple algorithms has been demonstrated in some cases to leak information about a key, provide the opportunity for attackers to forge integrity tags, or gain information about encrypted content. Binding a key to a single algorithm prevents these problems. Key creators and key consumers are strongly encouraged not only to create new keys for each different algorithm, but to include that selection of algorithm in any distribution of key material and strictly enforce the matching of algorithms in the key structure to algorithms in the message structure. In addition to checking that algorithms are correct, the key form needs to be checked as well. Do not use an 'EC2' key where an 'OKP' key is expected.
尽管之前已经提到过，但在某些情况下，已证明将单个密钥用于多个算法会泄漏密钥信息，为攻击者提供伪造完整性标记或获取加密内容信息的机会。将密钥绑定到单个算法可以防止这些问题。强烈鼓励密钥创建者和密钥使用者不仅为每个不同的算法创建新密钥，而且在密钥材料的任何分发中包括算法的选择，并严格执行密钥结构中的算法与消息结构中的算法的匹配。除了检查算法是否正确外，还需要检查密钥表单。不要在需要“OKP”密钥的地方使用“EC2”密钥。
Before using a key for transmission, or before acting on information received, a trust decision on a key needs to be made. Is the data or action something that the entity associated with the key has a right to see or a right to request? A number of factors are associated with this trust decision. Some of the ones that are highlighted here are:
在使用密钥进行传输之前，或者在对接收到的信息采取行动之前，需要对密钥做出信任决定。与密钥关联的实体有权查看或请求数据或操作吗？许多因素与此信任决策相关。此处突出显示的部分内容包括：
o What are the permissions associated with the key owner?
o 与密钥所有者关联的权限是什么？
o Is the cryptographic algorithm acceptable in the current context?
o 加密算法在当前上下文中是否可接受？
o Have the restrictions associated with the key, such as algorithm or freshness, been checked and are they correct?
o 是否检查了与密钥相关的限制，如算法或新鲜度，这些限制是否正确？
o Is the request something that is reasonable, given the current state of the application?
o 鉴于应用程序的当前状态，请求是否合理？
o Have any security considerations that are part of the message been enforced (as specified by the application or 'crit' parameter)?
o 是否实施了作为消息一部分的任何安全注意事项（由应用程序或“crit”参数指定）？
There are a large number of algorithms presented in this document that use nonce values. For all of the nonces defined in this document, there is some type of restriction on the nonce being a unique value either for a key or for some other conditions. In all of these cases, there is no known requirement on the nonce being both unique and unpredictable; under these circumstances, it's reasonable to use a counter for creation of the nonce. In cases where one wants the pattern of the nonce to be unpredictable as well as unique, one can use a key created for that purpose and encrypt the counter to produce the nonce value.
本文中介绍了大量使用nonce值的算法。对于本文档中定义的所有nonce，对nonce作为键或某些其他条件的唯一值存在某种类型的限制。在所有这些情况下，没有已知的关于暂时性是唯一的和不可预测的要求；在这种情况下，使用计数器创建nonce是合理的。在希望nonce模式不可预测且唯一的情况下，可以使用为此目的创建的密钥并加密计数器以生成nonce值。
One area that has been starting to get exposure is doing traffic analysis of encrypted messages based on the length of the message. This specification does not provide for a uniform method of providing padding as part of the message structure. An observer can distinguish between two different strings (for example, 'YES' and 'NO') based on the length for all of the content encryption algorithms that are defined in this document. This means that it is up to the applications to document how content padding is to be done in order to prevent or discourage such analysis. (For example, the strings could be defined as 'YES' and 'NO '.)
一个已经开始曝光的领域是根据消息长度对加密消息进行流量分析。本规范未提供作为消息结构一部分提供填充的统一方法。观察者可以根据本文档中定义的所有内容加密算法的长度来区分两个不同的字符串（例如“是”和“否”）。这意味着由应用程序来记录如何进行内容填充，以防止或阻止此类分析。（例如，字符串可以定义为“是”和“否”。）
[AES-GCM] National Institute of Standards and Technology, "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC", NIST Special Publication 800-38D, DOI 10.6028/NIST.SP.800-38D, November 2007, <https://csrc.nist.gov/publications/nistpubs/800- 38D/SP-800-38D.pdf>.
[AES-GCM]国家标准与技术研究所，“分组密码操作模式建议：Galois/计数器模式（GCM）和GMAC”，NIST特别出版物800-38D，DOI 10.6028/NIST.SP.800-38D，2007年11月<https://csrc.nist.gov/publications/nistpubs/800- 38D/SP-800-38D.pdf>。
[COAP.Formats] IANA, "Constrained RESTful Environments (CoRE) Parameters", <http://www.iana.org/assignments/core-parameters/>.
[COAP.Formats]IANA，“受限RESTful环境（核心）参数”<http://www.iana.org/assignments/core-parameters/>.
[DSS] National Institute of Standards and Technology, "Digital
Signature Standard (DSS)", FIPS PUB 186-4,
DOI 10.6028/NIST.FIPS.186-4, July 2013,
<http://nvlpubs.nist.gov/nistpubs/FIPS/
[DSS] National Institute of Standards and Technology, "Digital
Signature Standard (DSS)", FIPS PUB 186-4,
DOI 10.6028/NIST.FIPS.186-4, July 2013,
<http://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.186-4.pdf>.
NIST.FIPS.186-4.pdf>。
[MAC] National Institute of Standards and Technology, "Computer Data Authentication", FIPS PUB 113, May 1985, <http://csrc.nist.gov/publications/fips/fips113/ fips113.html>.
[MAC]国家标准与技术研究所，“计算机数据认证”，FIPS PUB 113，1985年5月<http://csrc.nist.gov/publications/fips/fips113/ fips113.html>。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, <http://www.rfc-editor.org/info/rfc2104>.
[RFC2104]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，DOI 10.17487/RFC2104，1997年2月<http://www.rfc-editor.org/info/rfc2104>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, September 2002, <http://www.rfc-editor.org/info/rfc3394>.
[RFC3394]Schaad，J.和R.Housley，“高级加密标准（AES）密钥包裹算法”，RFC 3394，DOI 10.17487/RFC3394，2002年9月<http://www.rfc-editor.org/info/rfc3394>.
[RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September 2003, <http://www.rfc-editor.org/info/rfc3610>.
[RFC3610]Whiting，D.，Housley，R.，和N.Ferguson，“CBC-MAC（CCM）计数器”，RFC 3610，DOI 10.17487/RFC3610，2003年9月<http://www.rfc-editor.org/info/rfc3610>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, <http://www.rfc-editor.org/info/rfc5869>.
[RFC5869]Krawczyk，H.和P.Eronen，“基于HMAC的提取和扩展密钥派生函数（HKDF）”，RFC 5869，DOI 10.17487/RFC5869，2010年5月<http://www.rfc-editor.org/info/rfc5869>.
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, DOI 10.17487/RFC6090, February 2011, <http://www.rfc-editor.org/info/rfc6090>.
[RFC6090]McGrew，D.，Igoe，K.，和M.Salter，“基本椭圆曲线密码算法”，RFC 6090，DOI 10.17487/RFC6090，2011年2月<http://www.rfc-editor.org/info/rfc6090>.
[RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 2013, <http://www.rfc-editor.org/info/rfc6979>.
[RFC6979]Pornin，T，“数字签名算法（DSA）和椭圆曲线数字签名算法（ECDSA）的确定性使用”，RFC 6979，DOI 10.17487/RFC6979，2013年8月<http://www.rfc-editor.org/info/rfc6979>.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013, <http://www.rfc-editor.org/info/rfc7049>.
[RFC7049]Bormann，C.和P.Hoffman，“简明二进制对象表示法（CBOR）”，RFC 7049，DOI 10.17487/RFC7049，2013年10月<http://www.rfc-editor.org/info/rfc7049>.
[RFC7539] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015, <http://www.rfc-editor.org/info/rfc7539>.
[RFC7539]Nir，Y.和A.Langley，“IETF协议的ChaCha20和Poly1305”，RFC 7539，DOI 10.17487/RFC7539，2015年5月<http://www.rfc-editor.org/info/rfc7539>.
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, January 2016, <http://www.rfc-editor.org/info/rfc7748>.
[RFC7748]兰利，A.，汉堡，M.和S.特纳，“安全的椭圆曲线”，RFC 7748，DOI 10.17487/RFC7748，2016年1月<http://www.rfc-editor.org/info/rfc7748>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, <http://www.rfc-editor.org/info/rfc8032>.
[RFC8032]Josefsson，S.和I.Liusvaara，“爱德华兹曲线数字签名算法（EdDSA）”，RFC 8032，DOI 10.17487/RFC8032，2017年1月<http://www.rfc-editor.org/info/rfc8032>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <http://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<http://www.rfc-editor.org/info/rfc8174>.
[SEC1] Certicom Research, "SEC 1: Elliptic Curve Cryptography", Standards for Efficient Cryptography, Version 2.0, May 2009, <http://www.secg.org/sec1-v2.pdf>.
[SEC1]Certicom Research，“第1节：椭圆曲线加密”，高效加密标准，版本2.0，2009年5月<http://www.secg.org/sec1-v2.pdf>.
[CDDL] Vigano, C. and H. Birkholz, "CBOR data definition language (CDDL): a notational convention to express CBOR data structures", Work in Progress, draft-greevenbosch-appsawg-cbor-cddl-09, March 2017.
[CDDL]Vigano，C.和H.Birkholz，“CBOR数据定义语言（CDDL）：表达CBOR数据结构的符号约定”，正在进行的工作，草稿-greevenbosch-appsawg-CBOR-CDDL-09，2017年3月。
[OSCOAP] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security of CoAP (OSCOAP)", Work in Progress, draft-ietf-core-object-security-03, May 2017.
[OSCOAP]Selander，G.，Mattsson，J.，Palombini，F.，和L.Seitz，“CoAP的对象安全性（OSCOAP）”，正在进行的工作，草案-ietf-core-Object-Security-032017年5月。
[PVSig] Brown, D. and D. Johnson, "Formal Security Proofs for a Signature Scheme with Partial Message Recovery", DOI 10.1007/3-540-45353-9_11, LNCS Volume 2020, June 2000.
[PVSig]Brown，D.和D.Johnson，“具有部分消息恢复的签名方案的正式安全性证明”，DOI 10.1007/3-540-45353-9_11，LNCS卷2020，2000年6月。
[RFC2633] Ramsdell, B., Ed., "S/MIME Version 3 Message Specification", RFC 2633, DOI 10.17487/RFC2633, June 1999, <http://www.rfc-editor.org/info/rfc2633>.
[RFC2633]拉姆斯代尔，B.，编辑，“S/MIME版本3消息规范”，RFC 2633，DOI 10.17487/RFC2633，1999年6月<http://www.rfc-editor.org/info/rfc2633>.
[RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", RFC 4231, DOI 10.17487/RFC4231, December 2005, <http://www.rfc-editor.org/info/rfc4231>.
[RFC4231]Nystrom，M.“HMAC-SHA-224、HMAC-SHA-256、HMAC-SHA-384和HMAC-SHA-512的标识符和测试向量”，RFC 4231，DOI 10.17487/RFC4231，2005年12月<http://www.rfc-editor.org/info/rfc4231>.
[RFC4262] Santesson, S., "X.509 Certificate Extension for Secure/ Multipurpose Internet Mail Extensions (S/MIME) Capabilities", RFC 4262, DOI 10.17487/RFC4262, December 2005, <http://www.rfc-editor.org/info/rfc4262>.
[RFC4262]Santesson，S.，“用于安全/多用途Internet邮件扩展（S/MIME）功能的X.509证书扩展”，RFC 4262，DOI 10.17487/RFC4262，2005年12月<http://www.rfc-editor.org/info/rfc4262>.
[RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June 2006, <http://www.rfc-editor.org/info/rfc4493>.
[RFC4493]Song，JH.，Poovendran，R.，Lee，J.，和T.Iwata，“AES-CMAC算法”，RFC 4493，DOI 10.17487/RFC4493，2006年6月<http://www.rfc-editor.org/info/rfc4493>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, <http://www.rfc-editor.org/info/rfc4949>.
[RFC4949]Shirey，R.，“互联网安全词汇表，第2版”，FYI 36，RFC 4949，DOI 10.17487/RFC4949，2007年8月<http://www.rfc-editor.org/info/rfc4949>.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, <http://www.rfc-editor.org/info/rfc5116>.
[RFC5116]McGrew，D.“认证加密的接口和算法”，RFC 5116，DOI 10.17487/RFC5116，2008年1月<http://www.rfc-editor.org/info/rfc5116>.
[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, "Elliptic Curve Cryptography Subject Public Key Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, <http://www.rfc-editor.org/info/rfc5480>.
[RFC5480]Turner，S.，Brown，D.，Yiu，K.，Housley，R.，和T.Polk，“椭圆曲线加密主题公钥信息”，RFC 5480，DOI 10.17487/RFC5480，2009年3月<http://www.rfc-editor.org/info/rfc5480>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <http://www.rfc-editor.org/info/rfc5652>.
[RFC5652]Housley，R.，“加密消息语法（CMS）”，STD 70，RFC 5652，DOI 10.17487/RFC5652，2009年9月<http://www.rfc-editor.org/info/rfc5652>.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, DOI 10.17487/RFC5751, January 2010, <http://www.rfc-editor.org/info/rfc5751>.
[RFC5751]Ramsdell，B.和S.Turner，“安全/多用途Internet邮件扩展（S/MIME）版本3.2消息规范”，RFC 5751，DOI 10.17487/RFC5751，2010年1月<http://www.rfc-editor.org/info/rfc5751>.
[RFC5752] Turner, S. and J. Schaad, "Multiple Signatures in Cryptographic Message Syntax (CMS)", RFC 5752, DOI 10.17487/RFC5752, January 2010, <http://www.rfc-editor.org/info/rfc5752>.
[RFC5752]Turner，S.和J.Schaad，“加密消息语法（CMS）中的多重签名”，RFC 5752，DOI 10.17487/RFC5752，2010年1月<http://www.rfc-editor.org/info/rfc5752>.
[RFC5990] Randall, J., Kaliski, B., Brainard, J., and S. Turner, "Use of the RSA-KEM Key Transport Algorithm in the Cryptographic Message Syntax (CMS)", RFC 5990, DOI 10.17487/RFC5990, September 2010, <http://www.rfc-editor.org/info/rfc5990>.
[RFC5990]Randall，J.，Kaliski，B.，Brainard，J.，和S.Turner，“在加密消息语法（CMS）中使用RSA-KEM密钥传输算法”，RFC 5990，DOI 10.17487/RFC5990，2010年9月<http://www.rfc-editor.org/info/rfc5990>.
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, DOI 10.17487/RFC6151, March 2011, <http://www.rfc-editor.org/info/rfc6151>.
[RFC6151]Turner，S.和L.Chen，“MD5消息摘要和HMAC-MD5算法的更新安全注意事项”，RFC 6151，DOI 10.17487/RFC6151，2011年3月<http://www.rfc-editor.org/info/rfc6151>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <http://www.rfc-editor.org/info/rfc6838>.
[RFC6838]Freed，N.，Klensin，J.和T.Hansen，“介质类型规范和注册程序”，BCP 13，RFC 6838，DOI 10.17487/RFC6838，2013年1月<http://www.rfc-editor.org/info/rfc6838>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, <http://www.rfc-editor.org/info/rfc7159>.
[RFC7159]Bray，T.，Ed.“JavaScript对象表示法（JSON）数据交换格式”，RFC 7159，DOI 10.17487/RFC7159，2014年3月<http://www.rfc-editor.org/info/rfc7159>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <http://www.rfc-editor.org/info/rfc7252>.
[RFC7252]Shelby，Z.，Hartke，K.，和C.Bormann，“受限应用协议（CoAP）”，RFC 7252，DOI 10.17487/RFC7252，2014年6月<http://www.rfc-editor.org/info/rfc7252>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <http://www.rfc-editor.org/info/rfc7515>.
[RFC7515]Jones，M.，Bradley，J.和N.Sakimura，“JSON网络签名（JWS）”，RFC 7515，DOI 10.17487/RFC7515，2015年5月<http://www.rfc-editor.org/info/rfc7515>.
[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015, <http://www.rfc-editor.org/info/rfc7516>.
[RFC7516]Jones，M.和J.Hildebrand，“JSON Web加密（JWE）”，RFC 7516，DOI 10.17487/RFC7516，2015年5月<http://www.rfc-editor.org/info/rfc7516>.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, <http://www.rfc-editor.org/info/rfc7517>.
[RFC7517]Jones，M.，“JSON Web密钥（JWK）”，RFC 7517，DOI 10.17487/RFC75172015年5月<http://www.rfc-editor.org/info/rfc7517>.
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015, <http://www.rfc-editor.org/info/rfc7518>.
[RFC7518]Jones，M.，“JSON网络算法（JWA）”，RFC 7518，DOI 10.17487/RFC7518，2015年5月<http://www.rfc-editor.org/info/rfc7518>.
[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, DOI 10.17487/RFC8017, November 2016, <http://www.rfc-editor.org/info/rfc8017>.
[RFC8017]Moriarty，K.，Ed.，Kaliski，B.，Jonsson，J.，和A.Rusch，“PKCS#1:RSA加密规范版本2.2”，RFC 8017，DOI 10.17487/RFC8017，2016年11月<http://www.rfc-editor.org/info/rfc8017>.
[RFC8018] Moriarty, K., Ed., Kaliski, B., and A. Rusch, "PKCS #5: Password-Based Cryptography Specification Version 2.1", RFC 8018, DOI 10.17487/RFC8018, January 2017, <http://www.rfc-editor.org/info/rfc8018>.
[RFC8018]Moriarty，K.，Ed.，Kaliski，B.，和A.Rusch，“PKCS#5：基于密码的加密规范版本2.1”，RFC 8018，DOI 10.17487/RFC8018，2017年1月<http://www.rfc-editor.org/info/rfc8018>.
[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, <http://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月<http://www.rfc-editor.org/info/rfc8126>.
[SP800-56A] Barker, E., Chen, L., Roginsky, A., and M. Smid, "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography", NIST Special Publication 800-56A, Revision 2, DOI 10.6028/NIST.SP.800-56Ar2, May 2013, <http://nvlpubs.nist.gov/nistpubs/SpecialPublications/ NIST.SP.800-56Ar2.pdf>.
[SP800-56A]Barker，E.，Chen，L.，Roginsky，A.，和M.Smid，“使用离散对数加密的成对密钥建立方案的建议”，NIST特别出版物800-56A，第2版，DOI 10.6028/NIST.SP.800-56Ar2，2013年5月<http://nvlpubs.nist.gov/nistpubs/SpecialPublications/ NIST.SP.800-56Ar2.pdf>。
[W3C.WebCrypto] Watson, M., "Web Cryptography API", W3C Recommendation, January 2017, <https://www.w3.org/TR/WebCryptoAPI/>.
[W3C.WebCrypto]Watson，M.，“网络加密API”，W3C建议，2017年1月<https://www.w3.org/TR/WebCryptoAPI/>.
A portion of the working group has expressed a strong desire to relax the rule that the algorithm identifier be required to appear in each level of a COSE object. There are two basic reasons that have been advanced to support this position. First, the resulting message will be smaller if the algorithm identifier is omitted from the most common messages in a CoAP environment. Second, there is a potential bug that will arise if full checking is not done correctly between the different places that an algorithm identifier could be placed (the message itself, an application statement, the key structure that the sender possesses, and the key structure the recipient possesses).
工作组的一部分成员表示强烈希望放宽要求算法标识符出现在COSE对象的每个级别的规则。支持这一立场有两个基本原因。首先，如果在CoAP环境中最常见的消息中省略了算法标识符，则生成的消息将更小。第二，如果在算法标识符可能放置的不同位置（消息本身、应用程序语句、发送方拥有的密钥结构和接收方拥有的密钥结构）之间没有正确地进行完全检查，则可能会出现一个潜在的错误。
This appendix lays out how such a change can be made and the details that an application needs to specify in order to use this option. Two different sets of details are specified: those needed to omit an algorithm identifier and those needed to use a variant on the counter signature attribute that contains no attributes about itself.
本附录列出了如何进行此类更改，以及应用程序使用此选项需要指定的详细信息。指定了两组不同的详细信息：省略算法标识符所需的详细信息，以及在计数器签名属性上使用不包含自身属性的变量所需的详细信息。
In this section, three sets of recommendations are laid out. The first set of recommendations apply to having an implicit algorithm identified for a single layer of a COSE object. The second set of recommendations apply to having multiple implicit algorithms identified for multiple layers of a COSE object. The third set of recommendations apply to having implicit algorithms for multiple COSE object constructs.
在本节中，提出了三套建议。第一组建议适用于为COSE对象的单层识别隐式算法。第二组建议适用于为COSE对象的多个层识别多个隐式算法。第三组建议适用于多个COSE对象构造的隐式算法。
The key words from RFC 2119 are deliberately not used here. This specification can provide recommendations, but it cannot enforce them.
这里故意不使用RFC2119中的关键词。该规范可以提供建议，但不能强制执行。
This set of recommendations applies to the case where an application is distributing a fixed algorithm along with the key information for use in a single COSE object. This normally applies to the smallest of the COSE objects, specifically COSE_Sign1, COSE_Mac0, and COSE_Encrypt0, but could apply to the other structures as well.
这组建议适用于应用程序分发固定算法以及在单个COSE对象中使用的密钥信息的情况。这通常适用于最小的COSE对象，特别是COSE_Sign1、COSE_Mac0和COSE_Encrypt0，但也可以应用于其他结构。
The following items should be taken into account:
应考虑以下各项：
o Applications need to list the set of COSE structures that implicit algorithms are to be used in. Applications need to require that the receipt of an explicit algorithm identifier in one of these structures will lead to the message being rejected. This requirement is stated so that there will never be a case where there is any ambiguity about the question of which algorithm should be used, the implicit or the explicit one. This applies
o 应用程序需要列出隐式算法将在其中使用的COSE结构集。应用程序需要要求在这些结构之一中接收到显式算法标识符将导致消息被拒绝。说明这一要求的目的是，在任何情况下，对于应使用哪种算法（隐式算法还是显式算法）的问题都不会存在任何歧义。这是适用的
even if the transported algorithm identifier is a protected attribute. This applies even if the transported algorithm is the same as the implicit algorithm.
即使传输的算法标识符是受保护的属性。即使传输的算法与隐式算法相同，这也适用。
o Applications need to define the set of information that is to be considered to be part of a context when omitting algorithm identifiers. At a minimum, this would be the key identifier (if needed), the key, the algorithm, and the COSE structure it is used with. Applications should restrict the use of a single key to a single algorithm. As noted for some of the algorithms in this document, the use of the same key in different related algorithms can lead to leakage of information about the key, leakage about the data or the ability to perform forgeries.
o 当省略算法标识符时，应用程序需要定义一组信息，这些信息将被视为上下文的一部分。至少，这将是密钥标识符（如果需要）、密钥、算法以及与之一起使用的COSE结构。应用程序应将单个密钥的使用限制为单个算法。正如本文中的一些算法所述，在不同的相关算法中使用相同的密钥可能会导致密钥信息泄漏、数据泄漏或伪造。
o In many cases, applications that make the algorithm identifier implicit will also want to make the context identifier implicit for the same reason. That is, omitting the context identifier will decrease the message size (potentially significantly depending on the length of the identifier). Applications that do this will need to describe the circumstances where the context identifier is to be omitted and how the context identifier is to be inferred in these cases. (An exhaustive search over all of the keys would normally not be considered to be acceptable.) An example of how this can be done is to tie the context to a transaction identifier. Both would be sent on the original message, but only the transaction identifier would need to be sent after that point as the context is tied into the transaction identifier. Another way would be to associate a context with a network address. All messages coming from a single network address can be assumed to be associated with a specific context. (In this case, the address would normally be distributed as part of the context.)
o 在许多情况下，出于同样的原因，使算法标识符隐式的应用程序也希望使上下文标识符隐式。也就是说，省略上下文标识符将减小消息大小（可能会显著地取决于标识符的长度）。执行此操作的应用程序需要描述省略上下文标识符的情况，以及在这些情况下如何推断上下文标识符。（对所有键进行彻底搜索通常被认为是不可接受的。）如何做到这一点的一个例子是将上下文绑定到事务标识符。两者都将在原始消息上发送，但在该点之后只需要发送事务标识符，因为上下文绑定到事务标识符中。另一种方法是将上下文与网络地址相关联。可以假设来自单个网络地址的所有消息都与特定上下文关联。（在这种情况下，地址通常作为上下文的一部分分发。）
o Applications cannot rely on key identifiers being unique unless they take significant efforts to ensure that they are computed in such a way as to create this guarantee. Even when an application does this, the uniqueness might be violated if the application is run in different contexts (i.e., with a different context provider) or if the system combines the security contexts from different applications together into a single store.
o 应用程序不能依赖唯一的密钥标识符，除非它们付出巨大的努力来确保它们的计算方式能够创建这种保证。即使应用程序执行此操作，如果应用程序在不同的上下文中运行（即使用不同的上下文提供程序），或者如果系统将来自不同应用程序的安全上下文组合到一个存储中，也可能会违反唯一性。
o Applications should continue the practice of protecting the algorithm identifier. Since this is not done by placing it in the protected attributes field, applications should define an application-specific external data structure that includes this value. This external data field can be used as such for content encryption, MAC, and signature algorithms. It can be used in the SuppPrivInfo field for those algorithms that use a KDF to derive a
o 应用程序应继续保护算法标识符的实践。由于这不是通过将其放置在protected attributes（受保护的属性）字段中来实现的，因此应用程序应该定义包含此值的特定于应用程序的外部数据结构。该外部数据字段可用于内容加密、MAC和签名算法。对于那些使用KDF来派生数据的算法，它可以在SuppPrivInfo字段中使用
key value. Applications may also want to protect other information that is part of the context structure as well. It should be noted that those fields, such as the key or a Base IV, are protected by virtue of being used in the cryptographic computation and do not need to be included in the external data field.
键值。应用程序可能还希望保护作为上下文结构一部分的其他信息。应当注意，那些字段，例如密钥或基数IV，由于在密码计算中使用而受到保护，并且不需要包括在外部数据字段中。
The second case is having multiple implicit algorithm identifiers specified for a multiple layer COSE object. An example of how this would work is the encryption context that an application specifies, which contains a content encryption algorithm, a key wrap algorithm, a key identifier, and a shared secret. The sender omits sending the algorithm identifier for both the content layer and the recipient layer leaving only the key identifier. The receiver then uses the key identifier to get the implicit algorithm identifiers.
第二种情况是为多层COSE对象指定多个隐式算法标识符。这将如何工作的一个示例是应用程序指定的加密上下文，其中包含内容加密算法、密钥包装算法、密钥标识符和共享密钥。发送方忽略发送内容层和接收方层的算法标识符，只留下密钥标识符。然后，接收器使用密钥标识符来获得隐式算法标识符。
The following additional items need to be taken into consideration:
需要考虑以下附加项目：
o Applications that want to support this will need to define a structure that allows for, and clearly identifies, both the COSE structure to be used with a given key and the structure and algorithm to be used for the secondary layer. The key for the secondary layer is computed as normal from the recipient layer.
o 想要支持这一点的应用程序将需要定义一个结构，该结构允许并明确标识与给定密钥一起使用的COSE结构以及用于第二层的结构和算法。第二层的关键帧是从接收方层按法线计算的。
The third case is having multiple implicit algorithm identifiers, but targeted at potentially unrelated layers or different COSE objects. There are a number of different scenarios where this might be applicable. Some of these scenarios are:
第三种情况是具有多个隐式算法标识符，但目标是可能不相关的层或不同的COSE对象。这可能适用于许多不同的场景。其中一些场景是：
o Two contexts are distributed as a pair. Each of the contexts is for use with a COSE_Encrypt message. Each context will consist of distinct secret keys and IVs and potentially even different algorithms. One context is for sending messages from party A to party B, and the second context is for sending messages from party B to party A. This means that there is no chance for a reflection attack to occur as each party uses different secret keys to send its messages; a message that is reflected back to it would fail to decrypt.
o 两个上下文成对分布。每个上下文都用于COSE_加密消息。每个上下文将由不同的密钥和IV以及可能甚至不同的算法组成。一个上下文用于从甲方向乙方发送消息，第二个上下文用于从乙方向甲方发送消息。这意味着由于各方使用不同的密钥发送其消息，因此不可能发生反射攻击；反射回它的消息将无法解密。
o Two contexts are distributed as a pair. The first context is used for encryption of the message, and the second context is used to place a counter signature on the message. The intention is that the second context can be distributed to other entities independently of the first context. This allows these entities to validate that the message came from an individual without being able to decrypt the message and see the content.
o 两个上下文成对分布。第一个上下文用于消息加密，第二个上下文用于在消息上放置反签名。其目的是第二上下文可以独立于第一上下文而被分发到其他实体。这允许这些实体验证消息是否来自个人，而不必解密消息和查看内容。
o Two contexts are distributed as a pair. The first context contains a key for dealing with MACed messages, and the second context contains a key for dealing with encrypted messages. This allows for a unified distribution of keys to participants for different types of messages that have different keys, but where the keys may be used in a coordinated manner.
o 两个上下文成对分布。第一个上下文包含用于处理MACE消息的密钥，第二个上下文包含用于处理加密消息的密钥。这允许为具有不同密钥的不同类型的消息的参与者统一分配密钥，但是密钥可以以协调的方式使用。
For these cases, the following additional items need to be considered:
对于这些情况，需要考虑以下附加项目：
o Applications need to ensure that the multiple contexts stay associated. If one of the contexts is invalidated for any reason, all of the contexts associated with it should also be invalidated.
o 应用程序需要确保多个上下文保持关联。如果其中一个上下文因任何原因无效，则与之关联的所有上下文也应无效。
There is a group of people who want to have a counter signature parameter that is directly tied to the value being signed, and thus the authenticated and unauthenticated buckets can be removed from the message being sent. The focus on this is an even smaller size, as all of the information on the process of creating the counter signature is implicit rather than being explicitly carried in the message. This includes not only the algorithm identifier as presented above, but also items such as the key identification, which is always external to the signature structure. This means that the entities that are doing the validation of the counter signature are required to infer which key is to be used from context rather than being explicit. One way of doing this would be to presume that all data coming from a specific port (or to a specific URL) is to be validated by a specific key. (Note that this does not require that the key identifier be part of the value signed as it does not serve a cryptographic purpose. If the key validates the counter signature, then it should be presumed that the entity associated with that key produced the signature.)
有一群人希望拥有一个直接绑定到被签名值的反签名参数，因此可以从发送的消息中删除经过身份验证和未经身份验证的bucket。对这一点的关注甚至更小，因为创建反签名过程中的所有信息都是隐式的，而不是显式地包含在消息中。这不仅包括如上所述的算法标识符，还包括诸如密钥标识之类的项目，密钥标识始终位于签名结构之外。这意味着进行反签名验证的实体需要根据上下文推断要使用哪个密钥，而不是显式的。一种方法是假定来自特定端口（或特定URL）的所有数据都将由特定密钥验证。（请注意，这并不要求密钥标识符是已签名值的一部分，因为它不用于加密目的。如果密钥验证了反签名，则应假定与该密钥关联的实体生成了签名。）
When computing the signature for the bare counter signature header, the same Sig_structure defined in Section 4.4 is used. The sign_protected field is omitted, as there is no protected header field in this counter signature header. The value of "CounterSignature0" is placed in the context field of the Sig_stucture.
计算裸计数器签名头的签名时，使用第4.4节中定义的相同Sig_结构。由于此计数器签名标头中没有受保护的标头字段，因此省略了sign_protected字段。“会签0”的值放在Sig_结构的上下文字段中。
+-------------------+-------+-------+-------+-----------------------+
| Name | Label | Value | Value | Description |
| | | Type | | |
+-------------------+-------+-------+-------+-----------------------+
| CounterSignature0 | 9 | bstr | | Counter signature |
| | | | | with implied signer |
| | | | | and headers |
+-------------------+-------+-------+-------+-----------------------+
+-------------------+-------+-------+-------+-----------------------+
| Name | Label | Value | Value | Description |
| | | Type | | |
+-------------------+-------+-------+-------+-----------------------+
| CounterSignature0 | 9 | bstr | | Counter signature |
| | | | | with implied signer |
| | | | | and headers |
+-------------------+-------+-------+-------+-----------------------+
Table 27: Header Parameter for CounterSignature0
表27：会签的标题参数0
All of the currently defined recipient algorithm classes only use two layers of the COSE_Encrypt structure. The first layer is the message content, and the second layer is the content key encryption. However, if one uses a recipient algorithm such as the RSA Key Encapsulation Mechanism (RSA-KEM) (see Appendix A of RSA-KEM [RFC5990]), then it makes sense to have three layers of the COSE_Encrypt structure.
所有当前定义的收件人算法类仅使用两层COSE_加密结构。第一层是消息内容，第二层是内容密钥加密。但是，如果使用诸如RSA密钥封装机制（RSA-KEM）（参见RSA-KEM[RFC5990]的附录a）之类的接收方算法，则有必要使用三层COSE_加密结构。
These layers would be:
这些层将是：
o Layer 0: The content encryption layer. This layer contains the payload of the message.
o 第0层：内容加密层。该层包含消息的有效负载。
o Layer 1: The encryption of the CEK by a KEK.
o 第1层：通过KEK对CEK进行加密。
o Layer 2: The encryption of a long random secret using an RSA key and a key derivation function to convert that secret into the KEK.
o 第2层：使用RSA密钥和密钥派生函数对长随机密钥进行加密，以将该密钥转换为KEK。
This is an example of what a triple layer message would look like. The message has the following layers:
这是一个三层消息的示例。该消息具有以下层：
o Layer 0: Has a content encrypted with AES-GCM using a 128-bit key.
o 第0层：具有使用128位密钥用AES-GCM加密的内容。
o Layer 1: Uses the AES Key Wrap algorithm with a 128-bit key.
o 第1层：使用具有128位密钥的AES密钥包裹算法。
o Layer 2: Uses ECDH Ephemeral-Static direct to generate the layer 1 key.
o 第2层：使用ECDH临时静态直接生成第1层密钥。
In effect, this example is a decomposed version of using the ECDH-ES+A128KW algorithm.
实际上，该示例是使用ECDH-ES+A128KW算法的分解版本。
Size of binary file is 183 bytes
二进制文件的大小为183字节
96(
[
/ protected / h'a10101' / {
\ alg \ 1:1 \ AES-GCM 128 \
} / ,
/ unprotected / {
/ iv / 5:h'02d1f7e6f26c43d4868d87ce'
},
/ ciphertext / h'64f84d913ba60a76070a9a48f26e97e863e2852948658f0
811139868826e89218a75715b',
/ recipients / [
[
/ protected / h'',
/ unprotected / {
/ alg / 1:-3 / A128KW /
},
/ ciphertext / h'dbd43c4e9d719c27c6275c67d628d493f090593db82
18f11',
/ recipients / [
[
/ protected / h'a1013818' / {
\ alg \ 1:-25 \ ECDH-ES + HKDF-256 \
} / ,
/ unprotected / {
/ ephemeral / -1:{
/ kty / 1:2,
/ crv / -1:1,
/ x / -2:h'b2add44368ea6d641f9ca9af308b4079aeb519f11
e9b8a55a600b21233e86e68',
/ y / -3:false
},
/ kid / 4:'meriadoc.brandybuck@buckland.example'
},
/ ciphertext / h''
]
]
]
]
]
)
96(
[
/ protected / h'a10101' / {
\ alg \ 1:1 \ AES-GCM 128 \
} / ,
/ unprotected / {
/ iv / 5:h'02d1f7e6f26c43d4868d87ce'
},
/ ciphertext / h'64f84d913ba60a76070a9a48f26e97e863e2852948658f0
811139868826e89218a75715b',
/ recipients / [
[
/ protected / h'',
/ unprotected / {
/ alg / 1:-3 / A128KW /
},
/ ciphertext / h'dbd43c4e9d719c27c6275c67d628d493f090593db82
18f11',
/ recipients / [
[
/ protected / h'a1013818' / {
\ alg \ 1:-25 \ ECDH-ES + HKDF-256 \
} / ,
/ unprotected / {
/ ephemeral / -1:{
/ kty / 1:2,
/ crv / -1:1,
/ x / -2:h'b2add44368ea6d641f9ca9af308b4079aeb519f11
e9b8a55a600b21233e86e68',
/ y / -3:false
},
/ kid / 4:'meriadoc.brandybuck@buckland.example'
},
/ ciphertext / h''
]
]
]
]
]
)
This appendix includes a set of examples that show the different features and message types that have been defined in this document. To make the examples easier to read, they are presented using the extended CBOR diagnostic notation (defined in [CDDL]) rather than as a binary dump.
本附录包括一组示例，展示了本文档中定义的不同功能和消息类型。为了使示例更易于阅读，它们使用扩展的CBOR诊断符号（在[CDDL]中定义）而不是二进制转储来表示。
A GitHub project has been created at <https://github.com/cose-wg/ Examples> that contains not only the examples presented in this document, but a more complete set of testing examples as well. Each example is found in a JSON file that contains the inputs used to create the example, some of the intermediate values that can be used in debugging the example and the output of the example presented in both a hex and a CBOR diagnostic notation format. Some of the examples at the site are designed failure testing cases; these are clearly marked as such in the JSON file. If errors in the examples in this document are found, the examples on GitHub will be updated, and a note to that effect will be placed in the JSON file.
已在上创建GitHub项目<https://github.com/cose-wg/ Examples>不仅包含本文档中提供的示例，还包含一组更完整的测试示例。每个示例都可以在一个JSON文件中找到，该文件包含用于创建示例的输入、可用于调试示例的一些中间值以及以十六进制和CBOR诊断符号格式显示的示例输出。现场的一些示例是设计的故障测试用例；JSON文件中清楚地标记了这些内容。如果在本文档中的示例中发现错误，那么GitHub上的示例将被更新，并在JSON文件中添加一条注释。
As noted, the examples are presented using the CBOR's diagnostic notation. A Ruby-based tool exists that can convert between the diagnostic notation and binary. This tool can be installed with the command line:
如前所述，使用CBOR的诊断符号给出了示例。存在一个基于Ruby的工具，可以在诊断符号和二进制之间进行转换。此工具可与命令行一起安装：
gem install cbor-diag
gem安装cbor diag
The diagnostic notation can be converted into binary files using the following command line:
可以使用以下命令行将诊断符号转换为二进制文件：
diag2cbor.rb < inputfile > outputfile
diag2cbor.rb<inputfile>outputfile
The examples can be extracted from the XML version of this document via an XPath expression as all of the artwork is tagged with the attribute type='CBORdiag'. (Depending on the XPath evaluator one is using, it may be necessary to deal with > as an entity.)
这些示例可以通过XPath表达式从本文档的XML版本中提取，因为所有的插图都带有type='CBORdiag'属性标记。（根据使用的XPath计算器，可能需要将>；作为一个实体处理。）
//artwork[@type='CDDL']/text()
//artwork[@type='CDDL']/text()
This example uses the following:
此示例使用以下内容：
o Signature Algorithm: ECDSA w/ SHA-256, Curve P-256
o 签名算法：ECDSA w/SHA-256，曲线P-256
Size of binary file is 103 bytes
二进制文件的大小为103字节
98(
[
/ protected / h'',
/ unprotected / {},
/ payload / 'This is the content.',
/ signatures / [
[
/ protected / h'a10126' / {
\ alg \ 1:-7 \ ECDSA 256 \
} / ,
/ unprotected / {
/ kid / 4:'11'
},
/ signature / h'e2aeafd40d69d19dfe6e52077c5d7ff4e408282cbefb
5d06cbf414af2e19d982ac45ac98b8544c908b4507de1e90b717c3d34816fe926a2b
98f53afd2fa0f30a'
]
]
]
)
98(
[
/ protected / h'',
/ unprotected / {},
/ payload / 'This is the content.',
/ signatures / [
[
/ protected / h'a10126' / {
\ alg \ 1:-7 \ ECDSA 256 \
} / ,
/ unprotected / {
/ kid / 4:'11'
},
/ signature / h'e2aeafd40d69d19dfe6e52077c5d7ff4e408282cbefb
5d06cbf414af2e19d982ac45ac98b8544c908b4507de1e90b717c3d34816fe926a2b
98f53afd2fa0f30a'
]
]
]
)
This example uses the following:
此示例使用以下内容：
o Signature Algorithm: ECDSA w/ SHA-256, Curve P-256
o 签名算法：ECDSA w/SHA-256，曲线P-256
o Signature Algorithm: ECDSA w/ SHA-512, Curve P-521
o 签名算法：ECDSA w/SHA-512，曲线P-521
Size of binary file is 277 bytes
二进制文件的大小为277字节
98(
[
/ protected / h'',
/ unprotected / {},
/ payload / 'This is the content.',
/ signatures / [
[
/ protected / h'a10126' / {
\ alg \ 1:-7 \ ECDSA 256 \
} / ,
/ unprotected / {
/ kid / 4:'11'
},
/ signature / h'e2aeafd40d69d19dfe6e52077c5d7ff4e408282cbefb
5d06cbf414af2e19d982ac45ac98b8544c908b4507de1e90b717c3d34816fe926a2b
98f53afd2fa0f30a'
],
[
/ protected / h'a1013823' / {
\ alg \ 1:-36
} / ,
/ unprotected / {
/ kid / 4:'bilbo.baggins@hobbiton.example'
},
/ signature / h'00a2d28a7c2bdb1587877420f65adf7d0b9a06635dd1
de64bb62974c863f0b160dd2163734034e6ac003b01e8705524c5c4ca479a952f024
7ee8cb0b4fb7397ba08d009e0c8bf482270cc5771aa143966e5a469a09f613488030
c5b07ec6d722e3835adb5b2d8c44e95ffb13877dd2582866883535de3bb03d01753f
83ab87bb4f7a0297'
]
]
]
)
98(
[
/ protected / h'',
/ unprotected / {},
/ payload / 'This is the content.',
/ signatures / [
[
/ protected / h'a10126' / {
\ alg \ 1:-7 \ ECDSA 256 \
} / ,
/ unprotected / {
/ kid / 4:'11'
},
/ signature / h'e2aeafd40d69d19dfe6e52077c5d7ff4e408282cbefb
5d06cbf414af2e19d982ac45ac98b8544c908b4507de1e90b717c3d34816fe926a2b
98f53afd2fa0f30a'
],
[
/ protected / h'a1013823' / {
\ alg \ 1:-36
} / ,
/ unprotected / {
/ kid / 4:'bilbo.baggins@hobbiton.example'
},
/ signature / h'00a2d28a7c2bdb1587877420f65adf7d0b9a06635dd1
de64bb62974c863f0b160dd2163734034e6ac003b01e8705524c5c4ca479a952f024
7ee8cb0b4fb7397ba08d009e0c8bf482270cc5771aa143966e5a469a09f613488030
c5b07ec6d722e3835adb5b2d8c44e95ffb13877dd2582866883535de3bb03d01753f
83ab87bb4f7a0297'
]
]
]
)
This example uses the following:
此示例使用以下内容：
o Signature Algorithm: ECDSA w/ SHA-256, Curve P-256
o 签名算法：ECDSA w/SHA-256，曲线P-256
o The same parameters are used for both the signature and the counter signature.
o 签名和反签名使用相同的参数。
Size of binary file is 180 bytes
二进制文件的大小为180字节
98(
[
/ protected / h'',
/ unprotected / {
/ countersign / 7:[
/ protected / h'a10126' / {
\ alg \ 1:-7 \ ECDSA 256 \
} / ,
/ unprotected / {
/ kid / 4:'11'
},
/ signature / h'5ac05e289d5d0e1b0a7f048a5d2b643813ded50bc9e4
9220f4f7278f85f19d4a77d655c9d3b51e805a74b099e1e085aacd97fc29d72f887e
8802bb6650cceb2c'
]
},
/ payload / 'This is the content.',
/ signatures / [
[
/ protected / h'a10126' / {
\ alg \ 1:-7 \ ECDSA 256 \
} / ,
/ unprotected / {
/ kid / 4:'11'
},
/ signature / h'e2aeafd40d69d19dfe6e52077c5d7ff4e408282cbefb
5d06cbf414af2e19d982ac45ac98b8544c908b4507de1e90b717c3d34816fe926a2b
98f53afd2fa0f30a'
]
]
]
)
98(
[
/ protected / h'',
/ unprotected / {
/ countersign / 7:[
/ protected / h'a10126' / {
\ alg \ 1:-7 \ ECDSA 256 \
} / ,
/ unprotected / {
/ kid / 4:'11'
},
/ signature / h'5ac05e289d5d0e1b0a7f048a5d2b643813ded50bc9e4
9220f4f7278f85f19d4a77d655c9d3b51e805a74b099e1e085aacd97fc29d72f887e
8802bb6650cceb2c'
]
},
/ payload / 'This is the content.',
/ signatures / [
[
/ protected / h'a10126' / {
\ alg \ 1:-7 \ ECDSA 256 \
} / ,
/ unprotected / {
/ kid / 4:'11'
},
/ signature / h'e2aeafd40d69d19dfe6e52077c5d7ff4e408282cbefb
5d06cbf414af2e19d982ac45ac98b8544c908b4507de1e90b717c3d34816fe926a2b
98f53afd2fa0f30a'
]
]
]
)
This example uses the following:
此示例使用以下内容：
o Signature Algorithm: ECDSA w/ SHA-256, Curve P-256
o 签名算法：ECDSA w/SHA-256，曲线P-256
o There is a criticality marker on the "reserved" header parameter
o “保留”标题参数上有一个临界标记
Size of binary file is 125 bytes
二进制文件的大小为125字节
98(
[
/ protected / h'a2687265736572766564f40281687265736572766564' /
{
"reserved":false,
\ crit \ 2:[
"reserved"
]
} / ,
/ unprotected / {},
/ payload / 'This is the content.',
/ signatures / [
[
/ protected / h'a10126' / {
\ alg \ 1:-7 \ ECDSA 256 \
} / ,
/ unprotected / {
/ kid / 4:'11'
},
/ signature / h'3fc54702aa56e1b2cb20284294c9106a63f91bac658d
69351210a031d8fc7c5ff3e4be39445b1a3e83e1510d1aca2f2e8a7c081c7645042b
18aba9d1fad1bd9c'
]
]
]
)
98(
[
/ protected / h'a2687265736572766564f40281687265736572766564' /
{
"reserved":false,
\ crit \ 2:[
"reserved"
]
} / ,
/ unprotected / {},
/ payload / 'This is the content.',
/ signatures / [
[
/ protected / h'a10126' / {
\ alg \ 1:-7 \ ECDSA 256 \
} / ,
/ unprotected / {
/ kid / 4:'11'
},
/ signature / h'3fc54702aa56e1b2cb20284294c9106a63f91bac658d
69351210a031d8fc7c5ff3e4be39445b1a3e83e1510d1aca2f2e8a7c081c7645042b
18aba9d1fad1bd9c'
]
]
]
)
This example uses the following:
此示例使用以下内容：
o Signature Algorithm: ECDSA w/ SHA-256, Curve P-256
o 签名算法：ECDSA w/SHA-256，曲线P-256
Size of binary file is 98 bytes
二进制文件的大小为98字节
18(
[
/ protected / h'a10126' / {
\ alg \ 1:-7 \ ECDSA 256 \
} / ,
/ unprotected / {
/ kid / 4:'11'
},
/ payload / 'This is the content.',
/ signature / h'8eb33e4ca31d1c465ab05aac34cc6b23d58fef5c083106c4
d25a91aef0b0117e2af9a291aa32e14ab834dc56ed2a223444547e01f11d3b0916e5
a4c345cacb36'
]
)
18(
[
/ protected / h'a10126' / {
\ alg \ 1:-7 \ ECDSA 256 \
} / ,
/ unprotected / {
/ kid / 4:'11'
},
/ payload / 'This is the content.',
/ signature / h'8eb33e4ca31d1c465ab05aac34cc6b23d58fef5c083106c4
d25a91aef0b0117e2af9a291aa32e14ab834dc56ed2a223444547e01f11d3b0916e5
a4c345cacb36'
]
)
This example uses the following:
此示例使用以下内容：
o CEK: AES-GCM w/ 128-bit key
o CEK:AES-GCM，带128位密钥
o Recipient class: ECDH Ephemeral-Static, Curve P-256
o 收件人类别：ECDH短期静态，曲线P-256
Size of binary file is 151 bytes
二进制文件的大小为151字节
96(
[
/ protected / h'a10101' / {
\ alg \ 1:1 \ AES-GCM 128 \
} / ,
/ unprotected / {
/ iv / 5:h'c9cf4df2fe6c632bf7886413'
},
/ ciphertext / h'7adbe2709ca818fb415f1e5df66f4e1a51053ba6d65a1a0
c52a357da7a644b8070a151b0',
/ recipients / [
[
/ protected / h'a1013818' / {
\ alg \ 1:-25 \ ECDH-ES + HKDF-256 \
} / ,
/ unprotected / {
/ ephemeral / -1:{
/ kty / 1:2,
/ crv / -1:1,
/ x / -2:h'98f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbf
bf054e1c7b4d91d6280',
/ y / -3:true
},
/ kid / 4:'meriadoc.brandybuck@buckland.example'
},
/ ciphertext / h''
]
]
]
)
96(
[
/ protected / h'a10101' / {
\ alg \ 1:1 \ AES-GCM 128 \
} / ,
/ unprotected / {
/ iv / 5:h'c9cf4df2fe6c632bf7886413'
},
/ ciphertext / h'7adbe2709ca818fb415f1e5df66f4e1a51053ba6d65a1a0
c52a357da7a644b8070a151b0',
/ recipients / [
[
/ protected / h'a1013818' / {
\ alg \ 1:-25 \ ECDH-ES + HKDF-256 \
} / ,
/ unprotected / {
/ ephemeral / -1:{
/ kty / 1:2,
/ crv / -1:1,
/ x / -2:h'98f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbf
bf054e1c7b4d91d6280',
/ y / -3:true
},
/ kid / 4:'meriadoc.brandybuck@buckland.example'
},
/ ciphertext / h''
]
]
]
)
This example uses the following:
此示例使用以下内容：
o CEK: AES-CCM w/ 128-bit key, truncate the tag to 64 bits
o CEK:AES-CCM w/128位密钥，将标记截断为64位
o Recipient class: Use HKDF on a shared secret with the following implicit fields as part of the context.
o Recipient类：在共享机密上使用HKDF，并将以下隐式字段作为上下文的一部分。
* salt: "aabbccddeeffgghh"
* 盐：“aabbccddeffgghh”
* PartyU identity: "lighting-client"
* PartyU标识：“照明客户端”
* PartyV identity: "lighting-server"
* PartyV标识：“照明服务器”
* Supplementary Public Other: "Encryption Example 02"
* 补充公共其他：“加密示例02”
Size of binary file is 91 bytes
二进制文件的大小为91字节
96(
[
/ protected / h'a1010a' / {
\ alg \ 1:10 \ AES-CCM-16-64-128 \
} / ,
/ unprotected / {
/ iv / 5:h'89f52f65a1c580933b5261a76c'
},
/ ciphertext / h'753548a19b1307084ca7b2056924ed95f2e3b17006dfe93
1b687b847',
/ recipients / [
[
/ protected / h'a10129' / {
\ alg \ 1:-10
} / ,
/ unprotected / {
/ salt / -20:'aabbccddeeffgghh',
/ kid / 4:'our-secret'
},
/ ciphertext / h''
]
]
]
)
96(
[
/ protected / h'a1010a' / {
\ alg \ 1:10 \ AES-CCM-16-64-128 \
} / ,
/ unprotected / {
/ iv / 5:h'89f52f65a1c580933b5261a76c'
},
/ ciphertext / h'753548a19b1307084ca7b2056924ed95f2e3b17006dfe93
1b687b847',
/ recipients / [
[
/ protected / h'a10129' / {
\ alg \ 1:-10
} / ,
/ unprotected / {
/ salt / -20:'aabbccddeeffgghh',
/ kid / 4:'our-secret'
},
/ ciphertext / h''
]
]
]
)
This example uses the following:
此示例使用以下内容：
o CEK: AES-GCM w/ 128-bit key
o CEK:AES-GCM，带128位密钥
o Recipient class: ECDH Ephemeral-Static, Curve P-256
o 收件人类别：ECDH短期静态，曲线P-256
Size of binary file is 326 bytes
二进制文件的大小为326字节
96(
[
/ protected / h'a10101' / {
\ alg \ 1:1 \ AES-GCM 128 \
} / ,
/ unprotected / {
/ iv / 5:h'c9cf4df2fe6c632bf7886413',
/ countersign / 7:[
/ protected / h'a1013823' / {
\ alg \ 1:-36
} / ,
/ unprotected / {
/ kid / 4:'bilbo.baggins@hobbiton.example'
},
/ signature / h'00929663c8789bb28177ae28467e66377da12302d7f9
594d2999afa5dfa531294f8896f2b6cdf1740014f4c7f1a358e3a6cf57f4ed6fb02f
cf8f7aa989f5dfd07f0700a3a7d8f3c604ba70fa9411bd10c2591b483e1d2c31de00
3183e434d8fba18f17a4c7e3dfa003ac1cf3d30d44d2533c4989d3ac38c38b71481c
c3430c9d65e7ddff'
]
},
/ ciphertext / h'7adbe2709ca818fb415f1e5df66f4e1a51053ba6d65a1a0
c52a357da7a644b8070a151b0',
/ recipients / [
[
/ protected / h'a1013818' / {
\ alg \ 1:-25 \ ECDH-ES + HKDF-256 \
} / ,
/ unprotected / {
/ ephemeral / -1:{
/ kty / 1:2,
/ crv / -1:1,
/ x / -2:h'98f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbf
bf054e1c7b4d91d6280',
/ y / -3:true
},
/ kid / 4:'meriadoc.brandybuck@buckland.example'
},
/ ciphertext / h''
]
]
]
)
96(
[
/ protected / h'a10101' / {
\ alg \ 1:1 \ AES-GCM 128 \
} / ,
/ unprotected / {
/ iv / 5:h'c9cf4df2fe6c632bf7886413',
/ countersign / 7:[
/ protected / h'a1013823' / {
\ alg \ 1:-36
} / ,
/ unprotected / {
/ kid / 4:'bilbo.baggins@hobbiton.example'
},
/ signature / h'00929663c8789bb28177ae28467e66377da12302d7f9
594d2999afa5dfa531294f8896f2b6cdf1740014f4c7f1a358e3a6cf57f4ed6fb02f
cf8f7aa989f5dfd07f0700a3a7d8f3c604ba70fa9411bd10c2591b483e1d2c31de00
3183e434d8fba18f17a4c7e3dfa003ac1cf3d30d44d2533c4989d3ac38c38b71481c
c3430c9d65e7ddff'
]
},
/ ciphertext / h'7adbe2709ca818fb415f1e5df66f4e1a51053ba6d65a1a0
c52a357da7a644b8070a151b0',
/ recipients / [
[
/ protected / h'a1013818' / {
\ alg \ 1:-25 \ ECDH-ES + HKDF-256 \
} / ,
/ unprotected / {
/ ephemeral / -1:{
/ kty / 1:2,
/ crv / -1:1,
/ x / -2:h'98f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbf
bf054e1c7b4d91d6280',
/ y / -3:true
},
/ kid / 4:'meriadoc.brandybuck@buckland.example'
},
/ ciphertext / h''
]
]
]
)
This example uses the following:
此示例使用以下内容：
o CEK: AES-GCM w/ 128-bit key
o CEK:AES-GCM，带128位密钥
o Recipient class: ECDH static-Static, Curve P-256 with AES Key Wrap
o 收件人类别：ECDH静态，曲线P-256，带AES密钥包裹
o Externally Supplied AAD: h'0011bbcc22dd44ee55ff660077'
o 外部供应的AAD:h'0011bbcc22dd44ee55ff660077'
Size of binary file is 173 bytes
二进制文件的大小为173字节
96(
[
/ protected / h'a10101' / {
\ alg \ 1:1 \ AES-GCM 128 \
} / ,
/ unprotected / {
/ iv / 5:h'02d1f7e6f26c43d4868d87ce'
},
/ ciphertext / h'64f84d913ba60a76070a9a48f26e97e863e28529d8f5335
e5f0165eee976b4a5f6c6f09d',
/ recipients / [
[
/ protected / h'a101381f' / {
\ alg \ 1:-32 \ ECHD-SS+A128KW \
} / ,
/ unprotected / {
/ static kid / -3:'peregrin.took@tuckborough.example',
/ kid / 4:'meriadoc.brandybuck@buckland.example',
/ U nonce / -22:h'0101'
},
/ ciphertext / h'41e0d76f579dbd0d936a662d54d8582037de2e366fd
e1c62'
]
]
]
)
96(
[
/ protected / h'a10101' / {
\ alg \ 1:1 \ AES-GCM 128 \
} / ,
/ unprotected / {
/ iv / 5:h'02d1f7e6f26c43d4868d87ce'
},
/ ciphertext / h'64f84d913ba60a76070a9a48f26e97e863e28529d8f5335
e5f0165eee976b4a5f6c6f09d',
/ recipients / [
[
/ protected / h'a101381f' / {
\ alg \ 1:-32 \ ECHD-SS+A128KW \
} / ,
/ unprotected / {
/ static kid / -3:'peregrin.took@tuckborough.example',
/ kid / 4:'meriadoc.brandybuck@buckland.example',
/ U nonce / -22:h'0101'
},
/ ciphertext / h'41e0d76f579dbd0d936a662d54d8582037de2e366fd
e1c62'
]
]
]
)
This example uses the following:
此示例使用以下内容：
o CEK: AES-CCM w/ 128-bit key and a 64-bit tag
o CEK:AES-CCM，带128位密钥和64位标记
Size of binary file is 52 bytes
二进制文件的大小为52字节
16(
[
/ protected / h'a1010a' / {
\ alg \ 1:10 \ AES-CCM-16-64-128 \
} / ,
/ unprotected / {
/ iv / 5:h'89f52f65a1c580933b5261a78c'
},
/ ciphertext / h'5974e1b99a3a4cc09a659aa2e9e7fff161d38ce71cb45ce
460ffb569'
]
)
16(
[
/ protected / h'a1010a' / {
\ alg \ 1:10 \ AES-CCM-16-64-128 \
} / ,
/ unprotected / {
/ iv / 5:h'89f52f65a1c580933b5261a78c'
},
/ ciphertext / h'5974e1b99a3a4cc09a659aa2e9e7fff161d38ce71cb45ce
460ffb569'
]
)
This example uses the following:
此示例使用以下内容：
o CEK: AES-CCM w/ 128-bit key and a 64-bit tag
o CEK:AES-CCM，带128位密钥和64位标记
o Prefix for IV is 89F52F65A1C580933B52
o IV的前缀是89F52F65A1C580933B52
Size of binary file is 41 bytes
二进制文件的大小为41字节
16(
[
/ protected / h'a1010a' / {
\ alg \ 1:10 \ AES-CCM-16-64-128 \
} / ,
/ unprotected / {
/ partial iv / 6:h'61a7'
},
/ ciphertext / h'252a8911d465c125b6764739700f0141ed09192de139e05
3bd09abca'
]
)
16(
[
/ protected / h'a1010a' / {
\ alg \ 1:10 \ AES-CCM-16-64-128 \
} / ,
/ unprotected / {
/ partial iv / 6:h'61a7'
},
/ ciphertext / h'252a8911d465c125b6764739700f0141ed09192de139e05
3bd09abca'
]
)
This example uses the following:
此示例使用以下内容：
o MAC: AES-CMAC, 256-bit key, truncated to 64 bits
o MAC:AES-CMAC，256位密钥，截断为64位
o Recipient class: direct shared secret
o 收件人类别：直接共享机密
Size of binary file is 57 bytes
二进制文件的大小为57字节
97(
[
/ protected / h'a1010f' / {
\ alg \ 1:15 \ AES-CBC-MAC-256//64 \
} / ,
/ unprotected / {},
/ payload / 'This is the content.',
/ tag / h'9e1226ba1f81b848',
/ recipients / [
[
/ protected / h'',
/ unprotected / {
/ alg / 1:-6 / direct /,
/ kid / 4:'our-secret'
},
/ ciphertext / h''
]
]
]
)
97(
[
/ protected / h'a1010f' / {
\ alg \ 1:15 \ AES-CBC-MAC-256//64 \
} / ,
/ unprotected / {},
/ payload / 'This is the content.',
/ tag / h'9e1226ba1f81b848',
/ recipients / [
[
/ protected / h'',
/ unprotected / {
/ alg / 1:-6 / direct /,
/ kid / 4:'our-secret'
},
/ ciphertext / h''
]
]
]
)
This example uses the following:
此示例使用以下内容：
o MAC: HMAC w/SHA-256, 256-bit key
o MAC:HMAC w/SHA-256，256位密钥
o Recipient class: ECDH key agreement, two static keys, HKDF w/ context structure
o 收件人类别：ECDH密钥协议，两个静态密钥，带上下文结构的HKDF
Size of binary file is 214 bytes
二进制文件的大小为214字节
97(
[
/ protected / h'a10105' / {
\ alg \ 1:5 \ HMAC 256//256 \
} / ,
/ unprotected / {},
/ payload / 'This is the content.',
/ tag / h'81a03448acd3d305376eaa11fb3fe416a955be2cbe7ec96f012c99
4bc3f16a41',
/ recipients / [
[
/ protected / h'a101381a' / {
\ alg \ 1:-27 \ ECDH-SS + HKDF-256 \
} / ,
/ unprotected / {
/ static kid / -3:'peregrin.took@tuckborough.example',
/ kid / 4:'meriadoc.brandybuck@buckland.example',
/ U nonce / -22:h'4d8553e7e74f3c6a3a9dd3ef286a8195cbf8a23d
19558ccfec7d34b824f42d92bd06bd2c7f0271f0214e141fb779ae2856abf585a583
68b017e7f2a9e5ce4db5'
},
/ ciphertext / h''
]
]
]
)
97(
[
/ protected / h'a10105' / {
\ alg \ 1:5 \ HMAC 256//256 \
} / ,
/ unprotected / {},
/ payload / 'This is the content.',
/ tag / h'81a03448acd3d305376eaa11fb3fe416a955be2cbe7ec96f012c99
4bc3f16a41',
/ recipients / [
[
/ protected / h'a101381a' / {
\ alg \ 1:-27 \ ECDH-SS + HKDF-256 \
} / ,
/ unprotected / {
/ static kid / -3:'peregrin.took@tuckborough.example',
/ kid / 4:'meriadoc.brandybuck@buckland.example',
/ U nonce / -22:h'4d8553e7e74f3c6a3a9dd3ef286a8195cbf8a23d
19558ccfec7d34b824f42d92bd06bd2c7f0271f0214e141fb779ae2856abf585a583
68b017e7f2a9e5ce4db5'
},
/ ciphertext / h''
]
]
]
)
This example uses the following:
此示例使用以下内容：
o MAC: AES-MAC, 128-bit key, truncated to 64 bits
o MAC:AES-MAC，128位密钥，截断为64位
o Recipient class: AES Key Wrap w/ a pre-shared 256-bit key
o 收件人类别：AES密钥包装，带有预共享的256位密钥
Size of binary file is 109 bytes
二进制文件的大小为109字节
97(
[
/ protected / h'a1010e' / {
\ alg \ 1:14 \ AES-CBC-MAC-128//64 \
} / ,
/ unprotected / {},
/ payload / 'This is the content.',
/ tag / h'36f5afaf0bab5d43',
/ recipients / [
[
/ protected / h'',
/ unprotected / {
/ alg / 1:-5 / A256KW /,
/ kid / 4:'018c0ae5-4d9b-471b-bfd6-eef314bc7037'
},
/ ciphertext / h'711ab0dc2fc4585dce27effa6781c8093eba906f227
b6eb0'
]
]
]
)
97(
[
/ protected / h'a1010e' / {
\ alg \ 1:14 \ AES-CBC-MAC-128//64 \
} / ,
/ unprotected / {},
/ payload / 'This is the content.',
/ tag / h'36f5afaf0bab5d43',
/ recipients / [
[
/ protected / h'',
/ unprotected / {
/ alg / 1:-5 / A256KW /,
/ kid / 4:'018c0ae5-4d9b-471b-bfd6-eef314bc7037'
},
/ ciphertext / h'711ab0dc2fc4585dce27effa6781c8093eba906f227
b6eb0'
]
]
]
)
This example uses the following:
此示例使用以下内容：
o MAC: HMAC w/ SHA-256, 128-bit key
o MAC:HMAC w/SHA-256，128位密钥
o Recipient class: Uses three different methods
o Recipient类：使用三种不同的方法
1. ECDH Ephemeral-Static, Curve P-521, AES Key Wrap w/ 128-bit key
1. ECDH瞬时静态，曲线P-521，AES密钥包，带128位密钥
2. AES Key Wrap w/ 256-bit key
2. 带256位密钥的AES密钥换行
Size of binary file is 309 bytes
二进制文件的大小为309字节
97(
[
/ protected / h'a10105' / {
\ alg \ 1:5 \ HMAC 256//256 \
} / ,
/ unprotected / {},
/ payload / 'This is the content.',
/ tag / h'bf48235e809b5c42e995f2b7d5fa13620e7ed834e337f6aa43df16
1e49e9323e',
/ recipients / [
[
/ protected / h'a101381c' / {
\ alg \ 1:-29 \ ECHD-ES+A128KW \
} / ,
/ unprotected / {
/ ephemeral / -1:{
/ kty / 1:2,
/ crv / -1:3,
/ x / -2:h'0043b12669acac3fd27898ffba0bcd2e6c366d53bc4db
71f909a759304acfb5e18cdc7ba0b13ff8c7636271a6924b1ac63c02688075b55ef2
d613574e7dc242f79c3',
/ y / -3:true
},
/ kid / 4:'bilbo.baggins@hobbiton.example'
},
/ ciphertext / h'339bc4f79984cdc6b3e6ce5f315a4c7d2b0ac466fce
a69e8c07dfbca5bb1f661bc5f8e0df9e3eff5'
],
[
/ protected / h'',
/ unprotected / {
/ alg / 1:-5 / A256KW /,
/ kid / 4:'018c0ae5-4d9b-471b-bfd6-eef314bc7037'
},
/ ciphertext / h'0b2c7cfce04e98276342d6476a7723c090dfdd15f9a
518e7736549e998370695e6d6a83b4ae507bb'
]
]
]
)
97(
[
/ protected / h'a10105' / {
\ alg \ 1:5 \ HMAC 256//256 \
} / ,
/ unprotected / {},
/ payload / 'This is the content.',
/ tag / h'bf48235e809b5c42e995f2b7d5fa13620e7ed834e337f6aa43df16
1e49e9323e',
/ recipients / [
[
/ protected / h'a101381c' / {
\ alg \ 1:-29 \ ECHD-ES+A128KW \
} / ,
/ unprotected / {
/ ephemeral / -1:{
/ kty / 1:2,
/ crv / -1:3,
/ x / -2:h'0043b12669acac3fd27898ffba0bcd2e6c366d53bc4db
71f909a759304acfb5e18cdc7ba0b13ff8c7636271a6924b1ac63c02688075b55ef2
d613574e7dc242f79c3',
/ y / -3:true
},
/ kid / 4:'bilbo.baggins@hobbiton.example'
},
/ ciphertext / h'339bc4f79984cdc6b3e6ce5f315a4c7d2b0ac466fce
a69e8c07dfbca5bb1f661bc5f8e0df9e3eff5'
],
[
/ protected / h'',
/ unprotected / {
/ alg / 1:-5 / A256KW /,
/ kid / 4:'018c0ae5-4d9b-471b-bfd6-eef314bc7037'
},
/ ciphertext / h'0b2c7cfce04e98276342d6476a7723c090dfdd15f9a
518e7736549e998370695e6d6a83b4ae507bb'
]
]
]
)
This example uses the following:
此示例使用以下内容：
o MAC: AES-CMAC, 256-bit key, truncated to 64 bits
o MAC:AES-CMAC，256位密钥，截断为64位
o Recipient class: direct shared secret
o 收件人类别：直接共享机密
Size of binary file is 37 bytes
二进制文件的大小为37字节
17(
[
/ protected / h'a1010f' / {
\ alg \ 1:15 \ AES-CBC-MAC-256//64 \
} / ,
/ unprotected / {},
/ payload / 'This is the content.',
/ tag / h'726043745027214f'
]
)
17(
[
/ protected / h'a1010f' / {
\ alg \ 1:15 \ AES-CBC-MAC-256//64 \
} / ,
/ unprotected / {},
/ payload / 'This is the content.',
/ tag / h'726043745027214f'
]
)
Note that this example uses the same inputs as Appendix C.5.1.
注意，本示例使用与附录C.5.1相同的输入。
This is an example of a COSE Key Set. This example includes the public keys for all of the previous examples.
这是COSE密钥集的一个示例。此示例包括前面所有示例的公钥。
In order the keys are:
按顺序，键为：
o An EC key with a kid of "meriadoc.brandybuck@buckland.example"
o 一把EC钥匙和一个叫“meriadoc”的孩子。brandybuck@buckland.example"
o An EC key with a kid of "peregrin.took@tuckborough.example"
o 一把EC钥匙和一个叫“peregrin”的孩子。took@tuckborough.example"
o An EC key with a kid of "bilbo.baggins@hobbiton.example"
o 一把EC钥匙和一个叫“比尔博”的孩子。baggins@hobbiton.example"
o An EC key with a kid of "11"
o 一把EC钥匙和一个11岁的孩子
Size of binary file is 481 bytes
二进制文件的大小为481字节
[
{
-1:1,
-2:h'65eda5a12577c2bae829437fe338701a10aaa375e1bb5b5de108de439c0
8551d',
-3:h'1e52ed75701163f7f9e40ddf9f341b3dc9ba860af7e0ca7ca7e9eecd008
4d19c',
1:2,
2:'meriadoc.brandybuck@buckland.example'
},
{
-1:1,
-2:h'bac5b11cad8f99f9c72b05cf4b9e26d244dc189f745228255a219a86d6a
09eff',
-3:h'20138bf82dc1b6d562be0fa54ab7804a3a64b6d72ccfed6b6fb6ed28bbf
c117e',
1:2,
2:'11'
},
{
-1:3,
-2:h'0072992cb3ac08ecf3e5c63dedec0d51a8c1f79ef2f82f94f3c737bf5de
7986671eac625fe8257bbd0394644caaa3aaf8f27a4585fbbcad0f2457620085e5c8
f42ad',
-3:h'01dca6947bce88bc5790485ac97427342bc35f887d86d65a089377e247e
60baa55e4e8501e2ada5724ac51d6909008033ebc10ac999b9d7f5cc2519f3fe1ea1
d9475',
1:2,
2:'bilbo.baggins@hobbiton.example'
},
{
-1:1,
-2:h'98f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4d91
d6280',
-3:h'f01400b089867804b8e9fc96c3932161f1934f4223069170d924b7e03bf
822bb',
1:2,
2:'peregrin.took@tuckborough.example'
}
]
[
{
-1:1,
-2:h'65eda5a12577c2bae829437fe338701a10aaa375e1bb5b5de108de439c0
8551d',
-3:h'1e52ed75701163f7f9e40ddf9f341b3dc9ba860af7e0ca7ca7e9eecd008
4d19c',
1:2,
2:'meriadoc.brandybuck@buckland.example'
},
{
-1:1,
-2:h'bac5b11cad8f99f9c72b05cf4b9e26d244dc189f745228255a219a86d6a
09eff',
-3:h'20138bf82dc1b6d562be0fa54ab7804a3a64b6d72ccfed6b6fb6ed28bbf
c117e',
1:2,
2:'11'
},
{
-1:3,
-2:h'0072992cb3ac08ecf3e5c63dedec0d51a8c1f79ef2f82f94f3c737bf5de
7986671eac625fe8257bbd0394644caaa3aaf8f27a4585fbbcad0f2457620085e5c8
f42ad',
-3:h'01dca6947bce88bc5790485ac97427342bc35f887d86d65a089377e247e
60baa55e4e8501e2ada5724ac51d6909008033ebc10ac999b9d7f5cc2519f3fe1ea1
d9475',
1:2,
2:'bilbo.baggins@hobbiton.example'
},
{
-1:1,
-2:h'98f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4d91
d6280',
-3:h'f01400b089867804b8e9fc96c3932161f1934f4223069170d924b7e03bf
822bb',
1:2,
2:'peregrin.took@tuckborough.example'
}
]
This is an example of a COSE Key Set. This example includes the private keys for all of the previous examples.
这是COSE密钥集的一个示例。此示例包括前面所有示例的私钥。
In order the keys are:
按顺序，键为：
o An EC key with a kid of "meriadoc.brandybuck@buckland.example"
o 一把EC钥匙和一个叫“meriadoc”的孩子。brandybuck@buckland.example"
o A shared-secret key with a kid of "our-secret"
o 与“我们的秘密”的孩子共享密钥
o An EC key with a kid of "peregrin.took@tuckborough.example"
o 一把EC钥匙和一个叫“peregrin”的孩子。took@tuckborough.example"
o A shared-secret key with a kid of "018c0ae5-4d9b-471b-bfd6-eef314bc7037"
o 与孩子“018c0ae5-4d9b-471b-bfd6-eef314bc7037”共享密钥
o An EC key with a kid of "bilbo.baggins@hobbiton.example"
o 一把EC钥匙和一个叫“比尔博”的孩子。baggins@hobbiton.example"
o An EC key with a kid of "11"
o 一把EC钥匙和一个11岁的孩子
Size of binary file is 816 bytes
二进制文件的大小为816字节
[
{
1:2,
2:'meriadoc.brandybuck@buckland.example',
-1:1,
-2:h'65eda5a12577c2bae829437fe338701a10aaa375e1bb5b5de108de439c0
8551d',
-3:h'1e52ed75701163f7f9e40ddf9f341b3dc9ba860af7e0ca7ca7e9eecd008
4d19c',
-4:h'aff907c99f9ad3aae6c4cdf21122bce2bd68b5283e6907154ad911840fa
208cf'
},
{
1:2,
2:'11',
-1:1,
-2:h'bac5b11cad8f99f9c72b05cf4b9e26d244dc189f745228255a219a86d6a
09eff',
-3:h'20138bf82dc1b6d562be0fa54ab7804a3a64b6d72ccfed6b6fb6ed28bbf
c117e',
-4:h'57c92077664146e876760c9520d054aa93c3afb04e306705db609030850
7b4d3'
},
{
1:2,
2:'bilbo.baggins@hobbiton.example',
[
{
1:2,
2:'meriadoc.brandybuck@buckland.example',
-1:1,
-2:h'65eda5a12577c2bae829437fe338701a10aaa375e1bb5b5de108de439c0
8551d',
-3:h'1e52ed75701163f7f9e40ddf9f341b3dc9ba860af7e0ca7ca7e9eecd008
4d19c',
-4:h'aff907c99f9ad3aae6c4cdf21122bce2bd68b5283e6907154ad911840fa
208cf'
},
{
1:2,
2:'11',
-1:1,
-2:h'bac5b11cad8f99f9c72b05cf4b9e26d244dc189f745228255a219a86d6a
09eff',
-3:h'20138bf82dc1b6d562be0fa54ab7804a3a64b6d72ccfed6b6fb6ed28bbf
c117e',
-4:h'57c92077664146e876760c9520d054aa93c3afb04e306705db609030850
7b4d3'
},
{
1:2,
2:'bilbo.baggins@hobbiton.example',
-1:3,
-2:h'0072992cb3ac08ecf3e5c63dedec0d51a8c1f79ef2f82f94f3c737bf5de
7986671eac625fe8257bbd0394644caaa3aaf8f27a4585fbbcad0f2457620085e5c8
f42ad',
-3:h'01dca6947bce88bc5790485ac97427342bc35f887d86d65a089377e247e
60baa55e4e8501e2ada5724ac51d6909008033ebc10ac999b9d7f5cc2519f3fe1ea1
d9475',
-4:h'00085138ddabf5ca975f5860f91a08e91d6d5f9a76ad4018766a476680b
55cd339e8ab6c72b5facdb2a2a50ac25bd086647dd3e2e6e99e84ca2c3609fdf177f
eb26d'
},
{
1:4,
2:'our-secret',
-1:h'849b57219dae48de646d07dbb533566e976686457c1491be3a76dcea6c4
27188'
},
{
1:2,
-1:1,
2:'peregrin.took@tuckborough.example',
-2:h'98f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4d91
d6280',
-3:h'f01400b089867804b8e9fc96c3932161f1934f4223069170d924b7e03bf
822bb',
-4:h'02d1f7e6f26c43d4868d87ceb2353161740aacf1f7163647984b522a848
df1c3'
},
{
1:4,
2:'our-secret2',
-1:h'849b5786457c1491be3a76dcea6c4271'
},
{
1:4,
2:'018c0ae5-4d9b-471b-bfd6-eef314bc7037',
-1:h'849b57219dae48de646d07dbb533566e976686457c1491be3a76dcea6c4
27188'
}
]
-1:3,
-2:h'0072992cb3ac08ecf3e5c63dedec0d51a8c1f79ef2f82f94f3c737bf5de
7986671eac625fe8257bbd0394644caaa3aaf8f27a4585fbbcad0f2457620085e5c8
f42ad',
-3:h'01dca6947bce88bc5790485ac97427342bc35f887d86d65a089377e247e
60baa55e4e8501e2ada5724ac51d6909008033ebc10ac999b9d7f5cc2519f3fe1ea1
d9475',
-4:h'00085138ddabf5ca975f5860f91a08e91d6d5f9a76ad4018766a476680b
55cd339e8ab6c72b5facdb2a2a50ac25bd086647dd3e2e6e99e84ca2c3609fdf177f
eb26d'
},
{
1:4,
2:'our-secret',
-1:h'849b57219dae48de646d07dbb533566e976686457c1491be3a76dcea6c4
27188'
},
{
1:2,
-1:1,
2:'peregrin.took@tuckborough.example',
-2:h'98f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbfbf054e1c7b4d91
d6280',
-3:h'f01400b089867804b8e9fc96c3932161f1934f4223069170d924b7e03bf
822bb',
-4:h'02d1f7e6f26c43d4868d87ceb2353161740aacf1f7163647984b522a848
df1c3'
},
{
1:4,
2:'our-secret2',
-1:h'849b5786457c1491be3a76dcea6c4271'
},
{
1:4,
2:'018c0ae5-4d9b-471b-bfd6-eef314bc7037',
-1:h'849b57219dae48de646d07dbb533566e976686457c1491be3a76dcea6c4
27188'
}
]
Acknowledgments
致谢
This document is a product of the COSE working group of the IETF.
本文件是IETF COSE工作组的成果。
The following individuals are to blame for getting me started on this project in the first place: Richard Barnes, Matt Miller, and Martin Thomson.
首先，让我开始这个项目的人有以下几位：理查德·巴恩斯、马特·米勒和马丁·汤姆森。
The initial version of the specification was based to some degree on the outputs of the JOSE and S/MIME working groups.
该规范的初始版本在某种程度上基于JOSE和S/MIME工作组的输出。
The following individuals provided input into the final form of the document: Carsten Bormann, John Bradley, Brain Campbell, Michael B. Jones, Ilari Liusvaara, Francesca Palombini, Ludwig Seitz, and Goran Selander.
以下个人为文件的最终形式提供了输入：卡斯滕·鲍曼、约翰·布拉德利、布莱恩·坎贝尔、迈克尔·琼斯、伊拉里·柳斯瓦拉、弗朗西斯卡·帕隆比尼、路德维希·塞茨和戈兰·塞兰德。
Author's Address
作者地址
Jim Schaad August Cellars
吉姆·沙德八月酒窖
Email: ietf@augustcellars.com
Email: ietf@augustcellars.com