draft-ietf-cose-msg-14.txt   draft-ietf-cose-msg-15.txt 
COSE Working Group J. Schaad COSE Working Group J. Schaad
Internet-Draft August Cellars Internet-Draft August Cellars
Intended status: Standards Track June 23, 2016 Intended status: Standards Track July 25, 2016
Expires: December 25, 2016 Expires: January 26, 2017
CBOR Object Signing and Encryption (COSE) CBOR Object Signing and Encryption (COSE)
draft-ietf-cose-msg-14 draft-ietf-cose-msg-15
Abstract Abstract
Concise Binary Object Representation (CBOR) is data format designed Concise Binary Object Representation (CBOR) is data format designed
for small code size and small message size. There is a need for the for small code size and small message size. There is a need for the
ability to have the basic security services defined for this data ability to have the basic security services defined for this data
format. This document defines the CBOR Object Signing and Encyption format. This document defines the CBOR Object Signing and Encryption
(COSE) specification. This specification describes how to create and (COSE) specification. This specification describes how to create and
process signature, message authentication codes and encryption using process signature, message authentication codes and encryption using
CBOR for serialization. This specifiction additionally specifies how CBOR for serialization. This specification additionally specifies
to representat cryptographic keys using CBOR. how to represent cryptographic keys using CBOR.
Contributing to this document Contributing to this document
The source for this draft is being maintained in GitHub. Suggested The source for this draft is being maintained in GitHub. Suggested
changes should be submitted as pull requests at <https://github.com/ changes should be submitted as pull requests at <https://github.com/
cose-wg/cose-spec>. Instructions are on that page as well. cose-wg/cose-spec>. Instructions are on that page as well.
Editorial changes can be managed in GitHub, but any substantial Editorial changes can be managed in GitHub, but any substantial
issues need to be discussed on the COSE mailing list. issues need to be discussed on the COSE mailing list.
Status of This Memo Status of This Memo
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 25, 2016. This Internet-Draft will expire on January 26, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 42 skipping to change at page 2, line 42
4.1. Signing with One or More Signers . . . . . . . . . . . . 15 4.1. Signing with One or More Signers . . . . . . . . . . . . 15
4.2. Signing with One Signer . . . . . . . . . . . . . . . . . 17 4.2. Signing with One Signer . . . . . . . . . . . . . . . . . 17
4.3. Externally Supplied Data . . . . . . . . . . . . . . . . 18 4.3. Externally Supplied Data . . . . . . . . . . . . . . . . 18
4.4. Signing and Verification Process . . . . . . . . . . . . 19 4.4. Signing and Verification Process . . . . . . . . . . . . 19
4.5. Computing Counter Signatures . . . . . . . . . . . . . . 20 4.5. Computing Counter Signatures . . . . . . . . . . . . . . 20
5. Encryption Objects . . . . . . . . . . . . . . . . . . . . . 21 5. Encryption Objects . . . . . . . . . . . . . . . . . . . . . 21
5.1. Enveloped COSE Structure . . . . . . . . . . . . . . . . 21 5.1. Enveloped COSE Structure . . . . . . . . . . . . . . . . 21
5.1.1. Recipient Algorithm Classes . . . . . . . . . . . . . 23 5.1.1. Recipient Algorithm Classes . . . . . . . . . . . . . 23
5.2. Single Recipient Encrypted . . . . . . . . . . . . . . . 24 5.2. Single Recipient Encrypted . . . . . . . . . . . . . . . 24
5.3. Encryption Algorithm for AEAD algorithms . . . . . . . . 24 5.3. Encryption Algorithm for AEAD algorithms . . . . . . . . 24
5.4. Encryption algorithm for AE algorithms . . . . . . . . . 26 5.4. Encryption algorithm for AE algorithms . . . . . . . . . 27
6. MAC Objects . . . . . . . . . . . . . . . . . . . . . . . . . 28 6. MAC Objects . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.1. MACed Message with Recipients . . . . . . . . . . . . . . 28 6.1. MACed Message with Recipients . . . . . . . . . . . . . . 28
6.2. MACed Messages with Implicit Key . . . . . . . . . . . . 29 6.2. MACed Messages with Implicit Key . . . . . . . . . . . . 29
6.3. How to compute and verify a MAC . . . . . . . . . . . . . 30 6.3. How to compute and verify a MAC . . . . . . . . . . . . . 30
7. Key Objects . . . . . . . . . . . . . . . . . . . . . . . . . 31 7. Key Objects . . . . . . . . . . . . . . . . . . . . . . . . . 32
7.1. COSE Key Common Parameters . . . . . . . . . . . . . . . 32 7.1. COSE Key Common Parameters . . . . . . . . . . . . . . . 32
8. Signature Algorithms . . . . . . . . . . . . . . . . . . . . 35 8. Signature Algorithms . . . . . . . . . . . . . . . . . . . . 35
8.1. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 36 8.1. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 36
8.1.1. Security Considerations . . . . . . . . . . . . . . . 37 8.1.1. Security Considerations . . . . . . . . . . . . . . . 38
8.2. Edwards-curve Digital Signature Algorithms (EdDSA) . . . 38 8.2. Edwards-curve Digital Signature Algorithms (EdDSA) . . . 39
8.2.1. Security Considerations . . . . . . . . . . . . . . . 39 8.2.1. Security Considerations . . . . . . . . . . . . . . . 40
9. Message Authentication (MAC) Algorithms . . . . . . . . . . . 39 9. Message Authentication (MAC) Algorithms . . . . . . . . . . . 40
9.1. Hash-based Message Authentication Codes (HMAC) . . . . . 40 9.1. Hash-based Message Authentication Codes (HMAC) . . . . . 40
9.1.1. Security Considerations . . . . . . . . . . . . . . . 41 9.1.1. Security Considerations . . . . . . . . . . . . . . . 42
9.2. AES Message Authentication Code (AES-CBC-MAC) . . . . . . 41 9.2. AES Message Authentication Code (AES-CBC-MAC) . . . . . . 42
9.2.1. Security Considerations . . . . . . . . . . . . . . . 42 9.2.1. Security Considerations . . . . . . . . . . . . . . . 43
10. Content Encryption Algorithms . . . . . . . . . . . . . . . . 43 10. Content Encryption Algorithms . . . . . . . . . . . . . . . . 44
10.1. AES GCM . . . . . . . . . . . . . . . . . . . . . . . . 43 10.1. AES GCM . . . . . . . . . . . . . . . . . . . . . . . . 44
10.1.1. Security Considerations . . . . . . . . . . . . . . 44 10.1.1. Security Considerations . . . . . . . . . . . . . . 45
10.2. AES CCM . . . . . . . . . . . . . . . . . . . . . . . . 45 10.2. AES CCM . . . . . . . . . . . . . . . . . . . . . . . . 46
10.2.1. Security Considerations . . . . . . . . . . . . . . 48 10.2.1. Security Considerations . . . . . . . . . . . . . . 49
10.3. ChaCha20 and Poly1305 . . . . . . . . . . . . . . . . . 48 10.3. ChaCha20 and Poly1305 . . . . . . . . . . . . . . . . . 49
10.3.1. Security Considerations . . . . . . . . . . . . . . 49 10.3.1. Security Considerations . . . . . . . . . . . . . . 50
11. Key Derivation Functions (KDF) . . . . . . . . . . . . . . . 49 11. Key Derivation Functions (KDF) . . . . . . . . . . . . . . . 50
11.1. HMAC-based Extract-and-Expand Key Derivation Function 11.1. HMAC-based Extract-and-Expand Key Derivation Function
(HKDF) . . . . . . . . . . . . . . . . . . . . . . . . . 50 (HKDF) . . . . . . . . . . . . . . . . . . . . . . . . . 51
11.2. Context Information Structure . . . . . . . . . . . . . 52 11.2. Context Information Structure . . . . . . . . . . . . . 53
12. Recipient Algorithm Classes . . . . . . . . . . . . . . . . . 55 12. Recipient Algorithm Classes . . . . . . . . . . . . . . . . . 56
12.1. Direct Encryption . . . . . . . . . . . . . . . . . . . 56 12.1. Direct Encryption . . . . . . . . . . . . . . . . . . . 57
12.1.1. Direct Key . . . . . . . . . . . . . . . . . . . . . 56 12.1.1. Direct Key . . . . . . . . . . . . . . . . . . . . . 57
12.1.2. Direct Key with KDF . . . . . . . . . . . . . . . . 57 12.1.2. Direct Key with KDF . . . . . . . . . . . . . . . . 58
12.2. Key Wrapping . . . . . . . . . . . . . . . . . . . . . . 58 12.2. Key Wrapping . . . . . . . . . . . . . . . . . . . . . . 59
12.2.1. AES Key Wrapping . . . . . . . . . . . . . . . . . . 59 12.2.1. AES Key Wrapping . . . . . . . . . . . . . . . . . . 60
12.3. Key Encryption . . . . . . . . . . . . . . . . . . . . . 60 12.3. Key Transport . . . . . . . . . . . . . . . . . . . . . 61
12.4. Direct Key Agreement . . . . . . . . . . . . . . . . . . 60 12.4. Direct Key Agreement . . . . . . . . . . . . . . . . . . 61
12.4.1. ECDH . . . . . . . . . . . . . . . . . . . . . . . . 61 12.4.1. ECDH . . . . . . . . . . . . . . . . . . . . . . . . 62
12.4.2. Security Considerations . . . . . . . . . . . . . . 64 12.4.2. Security Considerations . . . . . . . . . . . . . . 65
12.5. Key Agreement with KDF . . . . . . . . . . . . . . . . . 65 12.5. Key Agreement with KDF . . . . . . . . . . . . . . . . . 66
12.5.1. ECDH . . . . . . . . . . . . . . . . . . . . . . . . 65 12.5.1. ECDH . . . . . . . . . . . . . . . . . . . . . . . . 66
13. Key Object Parameters . . . . . . . . . . . . . . . . . . . . 67 13. Key Object Parameters . . . . . . . . . . . . . . . . . . . . 68
13.1. Elliptic Curve Keys . . . . . . . . . . . . . . . . . . 67 13.1. Elliptic Curve Keys . . . . . . . . . . . . . . . . . . 68
13.1.1. Double Coordinate Curves . . . . . . . . . . . . . . 68 13.1.1. Double Coordinate Curves . . . . . . . . . . . . . . 69
13.2. Octet Key Pair . . . . . . . . . . . . . . . . . . . . . 69 13.2. Octet Key Pair . . . . . . . . . . . . . . . . . . . . . 70
13.3. Symmetric Keys . . . . . . . . . . . . . . . . . . . . . 70 13.3. Symmetric Keys . . . . . . . . . . . . . . . . . . . . . 71
14. CBOR Encoder Restrictions . . . . . . . . . . . . . . . . . . 71 14. CBOR Encoder Restrictions . . . . . . . . . . . . . . . . . . 72
15. Application Profiling Considerations . . . . . . . . . . . . 71 15. Application Profiling Considerations . . . . . . . . . . . . 72
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 73 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 74
16.1. CBOR Tag assignment . . . . . . . . . . . . . . . . . . 73 16.1. CBOR Tag assignment . . . . . . . . . . . . . . . . . . 74
16.2. COSE Header Parameters Registry . . . . . . . . . . . . 73 16.2. COSE Header Parameters Registry . . . . . . . . . . . . 74
16.3. COSE Header Algorithm Labels Registry . . . . . . . . . 74 16.3. COSE Header Algorithm Parameters Registry . . . . . . . 75
16.4. COSE Algorithms Registry . . . . . . . . . . . . . . . . 74 16.4. COSE Algorithms Registry . . . . . . . . . . . . . . . . 75
16.5. COSE Key Common Parameters Registry . . . . . . . . . . 75 16.5. COSE Key Common Parameters Registry . . . . . . . . . . 76
16.6. COSE Key Type Parameters Registry . . . . . . . . . . . 76 16.6. COSE Key Type Parameters Registry . . . . . . . . . . . 77
16.7. COSE Elliptic Curve Parameters Registry . . . . . . . . 77 16.7. COSE Key Type Registry . . . . . . . . . . . . . . . . . 78
16.8. Media Type Registrations . . . . . . . . . . . . . . . . 77 16.8. COSE Elliptic Curve Parameters Registry . . . . . . . . 78
16.8.1. COSE Security Message . . . . . . . . . . . . . . . 77 16.9. Media Type Registrations . . . . . . . . . . . . . . . . 79
16.8.2. COSE Key media type . . . . . . . . . . . . . . . . 78 16.9.1. COSE Security Message . . . . . . . . . . . . . . . 79
16.9. CoAP Content Format Registrations . . . . . . . . . . . 80 16.9.2. COSE Key media type . . . . . . . . . . . . . . . . 80
16.10. Expert Review Instructions . . . . . . . . . . . . . . . 81
17. Implementation Status . . . . . . . . . . . . . . . . . . . . 82 16.10. CoAP Content-Format Registrations . . . . . . . . . . . 82
17.1. Author's Versions . . . . . . . . . . . . . . . . . . . 83 16.11. Expert Review Instructions . . . . . . . . . . . . . . . 82
17.2. COSE Testing Library . . . . . . . . . . . . . . . . . . 83 17. Implementation Status . . . . . . . . . . . . . . . . . . . . 83
18. Security Considerations . . . . . . . . . . . . . . . . . . . 84 17.1. Author's Versions . . . . . . . . . . . . . . . . . . . 84
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 86 17.2. COSE Testing Library . . . . . . . . . . . . . . . . . . 85
19.1. Normative References . . . . . . . . . . . . . . . . . . 86 18. Security Considerations . . . . . . . . . . . . . . . . . . . 85
19.2. Informative References . . . . . . . . . . . . . . . . . 87 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 87
Appendix A. Making Mandatory Algorithm Header Optional . . . . . 89 19.1. Normative References . . . . . . . . . . . . . . . . . . 87
A.1. Algorithm Identification . . . . . . . . . . . . . . . . 90 19.2. Informative References . . . . . . . . . . . . . . . . . 88
A.2. Counter Signature Without Headers . . . . . . . . . . . . 93 Appendix A. Making Mandatory Algorithm Header Optional . . . . . 91
Appendix B. Two Layers of Recipient Information . . . . . . . . 93 A.1. Algorithm Identification . . . . . . . . . . . . . . . . 91
Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 95 A.2. Counter Signature Without Headers . . . . . . . . . . . . 94
C.1. Examples of Signed Message . . . . . . . . . . . . . . . 96 Appendix B. Two Layers of Recipient Information . . . . . . . . 95
C.1.1. Single Signature . . . . . . . . . . . . . . . . . . 96 Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 96
C.1.2. Multiple Signers . . . . . . . . . . . . . . . . . . 97 C.1. Examples of Signed Message . . . . . . . . . . . . . . . 97
C.1.3. Counter Signature . . . . . . . . . . . . . . . . . . 98 C.1.1. Single Signature . . . . . . . . . . . . . . . . . . 97
C.1.4. Signature w/ Criticality . . . . . . . . . . . . . . 99 C.1.2. Multiple Signers . . . . . . . . . . . . . . . . . . 98
C.2. Single Signer Examples . . . . . . . . . . . . . . . . . 100 C.1.3. Counter Signature . . . . . . . . . . . . . . . . . . 99
C.2.1. Single ECDSA signature . . . . . . . . . . . . . . . 100 C.1.4. Signature w/ Criticality . . . . . . . . . . . . . . 100
C.3. Examples of Enveloped Messages . . . . . . . . . . . . . 101 C.2. Single Signer Examples . . . . . . . . . . . . . . . . . 101
C.3.1. Direct ECDH . . . . . . . . . . . . . . . . . . . . . 101 C.2.1. Single ECDSA signature . . . . . . . . . . . . . . . 101
C.3.2. Direct plus Key Derivation . . . . . . . . . . . . . 102 C.3. Examples of Enveloped Messages . . . . . . . . . . . . . 102
C.3.3. Counter Signature on Encrypted Content . . . . . . . 103 C.3.1. Direct ECDH . . . . . . . . . . . . . . . . . . . . . 102
C.3.4. Encrypted Content with External Data . . . . . . . . 105 C.3.2. Direct plus Key Derivation . . . . . . . . . . . . . 103
C.4. Examples of Encrypted Messages . . . . . . . . . . . . . 105 C.3.3. Counter Signature on Encrypted Content . . . . . . . 104
C.4.1. Simple Encrypted Message . . . . . . . . . . . . . . 105 C.3.4. Encrypted Content with External Data . . . . . . . . 106
C.4.2. Encrypted Message w/ a Partial IV . . . . . . . . . . 106 C.4. Examples of Encrypted Messages . . . . . . . . . . . . . 106
C.5. Examples of MACed messages . . . . . . . . . . . . . . . 106 C.4.1. Simple Encrypted Message . . . . . . . . . . . . . . 106
C.5.1. Shared Secret Direct MAC . . . . . . . . . . . . . . 106 C.4.2. Encrypted Message w/ a Partial IV . . . . . . . . . . 107
C.5.2. ECDH Direct MAC . . . . . . . . . . . . . . . . . . . 107 C.5. Examples of MACed messages . . . . . . . . . . . . . . . 107
C.5.3. Wrapped MAC . . . . . . . . . . . . . . . . . . . . . 108 C.5.1. Shared Secret Direct MAC . . . . . . . . . . . . . . 107
C.5.4. Multi-recipient MACed message . . . . . . . . . . . . 109 C.5.2. ECDH Direct MAC . . . . . . . . . . . . . . . . . . . 108
C.6. Examples of MAC0 messages . . . . . . . . . . . . . . . . 110 C.5.3. Wrapped MAC . . . . . . . . . . . . . . . . . . . . . 109
C.6.1. Shared Secret Direct MAC . . . . . . . . . . . . . . 110 C.5.4. Multi-recipient MACed message . . . . . . . . . . . . 110
C.7. COSE Keys . . . . . . . . . . . . . . . . . . . . . . . . 111 C.6. Examples of MAC0 messages . . . . . . . . . . . . . . . . 111
C.7.1. Public Keys . . . . . . . . . . . . . . . . . . . . . 111 C.6.1. Shared Secret Direct MAC . . . . . . . . . . . . . . 111
C.7.2. Private Keys . . . . . . . . . . . . . . . . . . . . 112 C.7. COSE Keys . . . . . . . . . . . . . . . . . . . . . . . . 112
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 114 C.7.1. Public Keys . . . . . . . . . . . . . . . . . . . . . 112
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 115 C.7.2. Private Keys . . . . . . . . . . . . . . . . . . . . 113
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 115
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 116
1. Introduction 1. Introduction
There has been an increased focus on the small, constrained devices There has been an increased focus on the small, constrained devices
that make up the Internet of Things (IoT). One of the standards that that make up the Internet of Things (IoT). One of the standards that
has come out of this process is the Concise Binary Object has come out of this process is the Concise Binary Object
Representation (CBOR) [RFC7049]. CBOR extended the data model of the Representation (CBOR) [RFC7049]. CBOR extended the data model of the
JavaScript Object Notation (JSON) [RFC7159] by allowing for binary JavaScript Object Notation (JSON) [RFC7159] by allowing for binary
data, among other changes. CBOR is being adopted by several of the data, among other changes. CBOR is being adopted by several of the
IETF working groups dealing with the IoT world as their encoding of IETF working groups dealing with the IoT world as their encoding of
skipping to change at page 9, line 26 skipping to change at page 9, line 26
| Tag | | | | | Tag | | | |
+-------+---------------+---------------+---------------------------+ +-------+---------------+---------------+---------------------------+
| TBD1 | cose-sign | COSE_Sign | COSE Signed Data Object | | TBD1 | cose-sign | COSE_Sign | COSE Signed Data Object |
| | | | | | | | | |
| TBD7 | cose-sign1 | COSE_Sign1 | COSE Single Signer Data | | TBD7 | cose-sign1 | COSE_Sign1 | COSE Single Signer Data |
| | | | Object | | | | | Object |
| | | | | | | | | |
| TBD2 | cose-encrypt | COSE_Encrypt | COSE Encrypted Data | | TBD2 | cose-encrypt | COSE_Encrypt | COSE Encrypted Data |
| | | | Object | | | | | Object |
| | | | | | | | | |
| TBD3 | cose-encrypt1 | COSE_Encrypt0 | COSE Single Recipient | | TBD3 | cose-encrypt0 | COSE_Encrypt0 | COSE Single Recipient |
| | | | Encrypted Data Object | | | | | Encrypted Data Object |
| | | | | | | | | |
| TBD4 | cose-mac | COSE_Mac | COSE Mac-ed Data Object | | TBD4 | cose-mac | COSE_Mac | COSE Mac-ed Data Object |
| | | | | | | | | |
| TBD6 | cose-mac0 | COSE_Mac0 | COSE Mac w/o Recipients | | TBD6 | cose-mac0 | COSE_Mac0 | COSE Mac w/o Recipients |
| | | | Object | | | | | Object |
+-------+---------------+---------------+---------------------------+ +-------+---------------+---------------+---------------------------+
Table 1: COSE Message Identification Table 1: COSE Message Identification
skipping to change at page 12, line 6 skipping to change at page 12, line 6
3.1. Common COSE Headers Parameters 3.1. Common COSE Headers Parameters
This section defines a set of common header parameters. A summary of This section defines a set of common header parameters. A summary of
these parameters can be found in Table 2. This table should be 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. consulted to determine the value of label, and the type of the value.
The set of header parameters defined in this section are: The set of header parameters defined in this section are:
alg This parameter is used to indicate the algorithm used for the alg This parameter is used to indicate the algorithm used for the
security processing. This parameter MUST be present at each layer security processing. This parameter MUST be present in the
of a signed, encrypted or authenticated message except the COSE_Signature, COSE_Sign1, COSE_Encrypt, COSE_Encrypt0, COSE_Mac,
COSE_Sign structure. When the algorithm supports authenticating and COSE_Mac0 structures. When the algorithm supports
associated data, this parameter MUST be in the protected header authenticating associated data, this parameter MUST be in the
bucket. The value is taken from the "COSE Algorithms" Registry protected header bucket. The value is taken from the "COSE
(see Section 16.4). Algorithms" Registry (see Section 16.4).
crit The parameter is used to indicate which protected header labels crit The parameter is used to indicate which protected header labels
an application that is processing a message is required to an application that is processing a message is required to
understand. Parameters defined in this document do not need to be understand. Parameters defined in this document do not need to be
included as they should be understood by all implementations. included as they should be understood by all implementations.
When present, this parameter MUST be placed in the protected When present, this parameter MUST be placed in the protected
header bucket. The array MUST have at least one value in it. header bucket. The array MUST have at least one value in it.
Not all labels need to be included in the 'crit' parameter. The Not all labels need to be included in the 'crit' parameter. The
rules for deciding which header labels are placed in the array rules for deciding which header labels are placed in the array
are: are:
skipping to change at page 13, line 14 skipping to change at page 13, line 14
kid This parameter identifies one piece of data that can be used as kid This parameter identifies one piece of data that can be used as
input to find the needed cryptographic key. The value of this input to find the needed cryptographic key. The value of this
parameter can be matched against the 'kid' member in a COSE_Key parameter can be matched against the 'kid' member in a COSE_Key
structure. Other methods of key distribution can define an structure. Other methods of key distribution can define an
equivalent field to be matched. Applications MUST NOT assume that equivalent field to be matched. Applications MUST NOT assume that
'kid' values are unique. There may be more than one key with the 'kid' values are unique. There may be more than one key with the
same 'kid' value, so all of the keys may need to be checked to same 'kid' value, so all of the keys may need to be checked to
find the correct one. The internal structure of 'kid' values is find the correct one. The internal structure of 'kid' values is
not defined and cannot be relied on by applications. Key not defined and cannot be relied on by applications. Key
identifier values are hints about which key to use. They are not identifier values are hints about which key to use. This is not a
directly a security critical field. For this reason, they can be security critical field. For this reason, it SHOULD be placed in
placed in the unprotected headers bucket. the unprotected headers bucket.
Initialization Vector This parameter holds the Initialization Vector Initialization Vector This parameter holds the Initialization Vector
(IV) value. For some symmetric encryption algorithms this may be (IV) value. For some symmetric encryption algorithms this may be
referred to as a nonce. As the IV is authenticated by the referred to as a nonce. As the IV is authenticated by the
encryption process, it can be placed in the unprotected header encryption process, it SHOULD be placed in the unprotected header
bucket. bucket.
Partial Initialization Vector This parameter holds a part of the IV Partial Initialization Vector This parameter holds a part of the IV
value. When using the COSE_Encrypt0 structure, a portion of the value. When using the COSE_Encrypt0 structure, a portion of the
IV can be part of the context associated with the key. This field 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 is used to carry a value that causes the IV to be changed for each
message. As the IV is authenticated by the encryption process, message. As the IV is authenticated by the encryption process,
this value can be placed in the unprotected header bucket. The this value can be placed in the unprotected header bucket. The
'Initialization Vector' and 'Partial Initialization Vector' 'Initialization Vector' and 'Partial Initialization Vector'
parameters MUST NOT both be present in the same security layer. parameters MUST NOT both be present in the same security layer.
skipping to change at page 14, line 18 skipping to change at page 14, line 18
+-----------+-------+----------------+-------------+----------------+ +-----------+-------+----------------+-------------+----------------+
| alg | 1 | int / tstr | COSE | Cryptographic | | alg | 1 | int / tstr | COSE | Cryptographic |
| | | | Algorithms | algorithm to | | | | | Algorithms | algorithm to |
| | | | registry | use | | | | | registry | use |
| | | | | | | | | | | |
| crit | 2 | [+ label] | COSE Header | Critical | | crit | 2 | [+ label] | COSE Header | Critical |
| | | | Labels | headers to be | | | | | Labels | headers to be |
| | | | registry | understood | | | | | registry | understood |
| | | | | | | | | | | |
| content | 3 | tstr / uint | CoAP | Content type | | content | 3 | tstr / uint | CoAP | Content type |
| type | | | Content - | of the payload | | type | | | Content- | of the payload |
| | | | Formats or | | | | | | Formats or | |
| | | | Media Types | | | | | | Media Types | |
| | | | registry | | | | | | registry | |
| | | | | | | | | | | |
| kid | 4 | bstr | | key identifier | | kid | 4 | bstr | | Key identifier |
| | | | | | | | | | | |
| IV | 5 | bstr | | Full | | IV | 5 | bstr | | Full |
| | | | | Initialization | | | | | | Initialization |
| | | | | Vector | | | | | | Vector |
| | | | | | | | | | | |
| Partial | 6 | bstr | | Partial | | Partial | 6 | bstr | | Partial |
| IV | | | | Initialization | | IV | | | | Initialization |
| | | | | Vector | | | | | | Vector |
| | | | | | | | | | | |
| counter | 7 | COSE_Signature | | CBOR encoded | | counter | 7 | COSE_Signature | | CBOR encoded |
skipping to change at page 18, line 24 skipping to change at page 18, line 24
COSE_Sign1 = [ COSE_Sign1 = [
Headers, Headers,
payload : bstr / nil, payload : bstr / nil,
signature : bstr signature : bstr
] ]
4.3. Externally Supplied Data 4.3. Externally Supplied Data
One of the features supplied in the COSE document is the ability for One of the features supplied in the COSE document is the ability for
applications to provide additional data to be authenticated as part applications to provide additional data to be authenticated, but that
of the security, but that is not carried as part of the COSE object. is not carried as part of the COSE object. The primary reason for
The primary reason for supporting this can be seen by looking at the supporting this can be seen by looking at the CoAP message structure
CoAP message structure [RFC7252], where the facility exists for [RFC7252], where the facility exists for options to be carried before
options to be carried before the payload. Examples of data that can the payload. Examples of data that can be placed in this location
be placed in this location would be the CoAP code, CoAP token, or would be the CoAP code or CoAP options. If the data is in the header
CoAP options. If the data is in the header section, then it is section, then it is available for proxies to help in performing its
available for routers to help in performing the replay detection and operations. For example, the Accept Option can be used by a proxy to
prevention. However, it may also be desired to protect these values determine if an appropriate value is in the Proxy's cache. But the
so that if they are modified in transit, it can be detected. 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.
This document describes the process for using a byte array of This document describes the process for using a byte array of
externally supplied authenticated data; however, the method of externally supplied authenticated data; however, the method of
constructing the byte array is a function of the application. constructing the byte array is a function of the application.
Applications that use this feature need to define how the externally Applications that use this feature need to define how the externally
supplied authenticated data is to be constructed. Such a supplied authenticated data is to be constructed. Such a
construction needs to take into account the following issues: construction needs to take into account the following issues:
o If multiple items are included, care needs to be taken that data o If multiple items are included, care needs to be taken that data
cannot bleed between the items. This is usually addressed by cannot bleed between the items. This is usually addressed by
skipping to change at page 19, line 18 skipping to change at page 19, line 20
node could insert or remove an option, changing how the relative node could insert or remove an option, changing how the relative
number is done. An application would need to specify that the number is done. An application would need to specify that the
relative number must be re-encoded to be relative only to the relative number must be re-encoded to be relative only to the
options that are in the external data. options that are in the external data.
4.4. Signing and Verification Process 4.4. Signing and Verification Process
In order to create a signature, a well-defined byte stream is needed. In order to create a signature, a well-defined byte stream is needed.
This algorithm takes in the body information (COSE_Sign or This algorithm takes in the body information (COSE_Sign or
COSE_Sign1), the signer information (COSE_Signature), and the COSE_Sign1), the signer information (COSE_Signature), and the
application data (External). A CBOR array is used to construct the application data (external source). A CBOR array is used to
byte stream. The fields of the array in order are: construct the byte stream. The fields of the array in order are:
1. A text string identifying the context of the signature. The 1. A text string identifying the context of the signature. The
context string is: context string is:
"Signature" for signatures using the COSE_Signature structure. "Signature" for signatures using the COSE_Signature structure.
"Signature1" for signatures using the COSE_Sign1 structure. "Signature1" for signatures using the COSE_Sign1 structure.
"CounterSignature" for signatures used as counter signature "CounterSignature" for signatures used as counter signature
attributes. attributes.
skipping to change at page 22, line 6 skipping to change at page 22, line 6
message. The protected parameters associated with the content are message. The protected parameters associated with the content are
authenticated by the content encryption algorithm. The protected authenticated by the content encryption algorithm. The protected
parameters associated with the recipient are authenticated by the parameters associated with the recipient are authenticated by the
recipient algorithm (when the algorithm supports it). Examples of recipient algorithm (when the algorithm supports it). Examples of
parameters about the content are the type of the content and the parameters about the content are the type of the content and the
content encryption algorithm. Examples of parameters about the content encryption algorithm. Examples of parameters about the
recipient are the recipient's key identifier and the recipient's recipient are the recipient's key identifier and the recipient's
encryption algorithm. encryption algorithm.
The same techniques and structures are used for encrypting both the The same techniques and structures are used for encrypting both the
plain text and the keys used to protect the text. This is different plain text and the keys. This is different from the approach used by
from the approach used by both CMS [RFC5652] and JSON Web Encryption both CMS [RFC5652] and JSON Web Encryption (JWE) [RFC7516] where
(JWE) [RFC7516] where different structures are used for the content different structures are used for the content layer and for the
layer and for the recipient layer. Two structures are defined: recipient layer. Two structures are defined: COSE_Encrypt to hold
COSE_Encrypt to hold the encrypted content and COSE_recipient to hold the encrypted content and COSE_recipient to hold the encrypted keys
the encrypted keys for recipients. Examples of encrypted messages for recipients. Examples of encrypted messages can be found in
can be found in Appendix C.3. Appendix C.3.
The COSE_Encrypt structure can be encoded either tagged or untagged The COSE_Encrypt structure can be encoded either tagged or untagged
depending on the context it will be used in. A tagged COSE_Encrypt depending on the context it will be used in. A tagged COSE_Encrypt
structure is identified by the CBOR tag TBD2. The CDDL fragment that structure is identified by the CBOR tag TBD2. The CDDL fragment that
represents this is: represents this is:
COSE_Encrypt_Tagged = #6.992(COSE_Encrypt) ; Replace 992 with TBD2 COSE_Encrypt_Tagged = #6.992(COSE_Encrypt) ; Replace 992 with TBD2
The COSE_Encrypt structure is a CBOR array. The fields of the array The COSE_Encrypt structure is a CBOR array. The fields of the array
in order are: in order are:
skipping to change at page 25, line 47 skipping to change at page 25, line 47
1. Create an Enc_structure and populate it with the appropriate 1. Create an Enc_structure and populate it with the appropriate
fields. fields.
2. Encode the Enc_structure to a byte stream (AAD), using the 2. Encode the Enc_structure to a byte stream (AAD), using the
encoding described in Section 14. encoding described in Section 14.
3. Determine the encryption key (K). This step is dependent on the 3. Determine the encryption key (K). This step is dependent on the
class of recipient algorithm being used. For: class of recipient algorithm being used. For:
No Recipients: The key to be used is determined by the algorithm No Recipients: The key to be used is determined by the algorithm
and key at the current layer. 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.
Direct and Direct Key Agreement: The key is determined by the Direct and Direct Key Agreement: The key is determined by the
key and algorithm in the recipient structure. The encryption key and algorithm in the recipient structure. The encryption
algorithm and size of the key to be used are inputs into the algorithm and size of the key to be used are inputs into the
KDF used for the recipient. (For direct, the KDF can be KDF used for the recipient. (For direct, the KDF can be
thought of as the identity operation.) thought of as the identity operation.) Examples of these
algorithms are found in Section 12.1.2 and Section 12.4.1.
Other: The key is randomly generated. Other: The key is randomly generated.
4. Call the encryption algorithm with K (the encryption key), P (the 4. Call the encryption algorithm with K (the encryption key), P (the
plain text) and AAD. Place the returned cipher text into the plain text) and AAD. Place the returned cipher text into the
'ciphertext' field of the structure. 'ciphertext' field of the structure.
5. For recipients of the message, recursively perform the encryption 5. For recipients of the message, recursively perform the encryption
algorithm for that recipient, using K (the encryption key) as the algorithm for that recipient, using K (the encryption key) as the
plain text. plain text.
skipping to change at page 26, line 29 skipping to change at page 26, line 31
1. Create a Enc_structure and populate it with the appropriate 1. Create a Enc_structure and populate it with the appropriate
fields. fields.
2. Encode the Enc_structure to a byte stream (AAD), using the 2. Encode the Enc_structure to a byte stream (AAD), using the
encoding described in Section 14. encoding described in Section 14.
3. Determine the decryption key. This step is dependent on the 3. Determine the decryption key. This step is dependent on the
class of recipient algorithm being used. For: class of recipient algorithm being used. For:
No Recipients: The key to be used is determined by the algorithm No Recipients: The key to be used is determined by the algorithm
and key at the current layer. 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.
Direct and Direct Key Agreement: The key is determined by the Direct and Direct Key Agreement: The key is determined by the
key and algorithm in the recipient structure. The encryption key and algorithm in the recipient structure. The encryption
algorithm and size of the key to be used are inputs into the algorithm and size of the key to be used are inputs into the
KDF used for the recipient. (For direct, the KDF can be KDF used for the recipient. (For direct, the KDF can be
thought of as the identity operation.) thought of as the identity operation.) Examples of these
algorithms are found in Section 12.1.2 and Section 12.4.1.
Other: The key is determined by decoding and decrypting one of Other: The key is determined by decoding and decrypting one of
the recipient structures. the recipient structures.
4. Call the decryption algorithm with K (the decryption key to use), 4. Call the decryption algorithm with K (the decryption key to use),
C (the cipher text) and AAD. C (the cipher text) and AAD.
5.4. Encryption algorithm for AE algorithms 5.4. Encryption algorithm for AE algorithms
How to encrypt a message: How to encrypt a message:
1. Verify that the 'protected' field is empty. 1. Verify that the 'protected' field is empty.
2. Verify that there was no external additional authenticated data 2. Verify that there was no external additional authenticated data
supplied for this operation. supplied for this operation.
3. Determine the encryption key. This step is dependent on the 3. Determine the encryption key. This step is dependent on the
class of recipient algorithm being used. For: class of recipient algorithm being used. For:
No Recipients: The key to be used is determined by the algorithm No Recipients: The key to be used is determined by the algorithm
and key at the current layer. 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.
Direct and Direct Key Agreement: The key is determined by the Direct and Direct Key Agreement: The key is determined by the
key and algorithm in the recipient structure. The encryption key and algorithm in the recipient structure. The encryption
algorithm and size of the key to be used are inputs into the algorithm and size of the key to be used are inputs into the
KDF used for the recipient. (For direct, the KDF can be KDF used for the recipient. (For direct, the KDF can be
thought of as the identity operation.) thought of as the identity operation.) Examples of these
algorithms are found in Section 12.1.2 and Section 12.4.1.
Other: The key is randomly generated. Other: The key is randomly generated.
4. Call the encryption algorithm with K (the encryption key to use) 4. Call the encryption algorithm with K (the encryption key to use)
and the P (the plain text). Place the returned cipher text into and the P (the plain text). Place the returned cipher text into
the 'ciphertext' field of the structure. the 'ciphertext' field of the structure.
5. For recipients of the message, recursively perform the encryption 5. For recipients of the message, recursively perform the encryption
algorithm for that recipient, using K (the encryption key) as the algorithm for that recipient, using K (the encryption key) as the
plain text. plain text.
skipping to change at page 27, line 38 skipping to change at page 27, line 50
1. Verify that the 'protected' field is empty. 1. Verify that the 'protected' field is empty.
2. Verify that there was no external additional authenticated data 2. Verify that there was no external additional authenticated data
supplied for this operation. supplied for this operation.
3. Determine the decryption key. This step is dependent on the 3. Determine the decryption key. This step is dependent on the
class of recipient algorithm being used. For: class of recipient algorithm being used. For:
No Recipients: The key to be used is determined by the algorithm No Recipients: The key to be used is determined by the algorithm
and key at the current layer. 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.
Direct and Direct Key Agreement: The key is determined by the Direct and Direct Key Agreement: The key is determined by the
key and algorithm in the recipient structure. The encryption key and algorithm in the recipient structure. The encryption
algorithm and size of the key to be used are inputs into the algorithm and size of the key to be used are inputs into the
KDF used for the recipient. (For direct, the KDF can be KDF used for the recipient. (For direct, the KDF can be
thought of as the identity operation.) thought of as the identity operation.) Examples of these
algorithms are found in Section 12.1.2 and Section 12.4.1.
Other: The key is determined by decoding and decrypting one of Other: The key is determined by decoding and decrypting one of
the recipient structures. the recipient structures.
4. Call the decryption algorithm with K (the decryption key to use), 4. Call the decryption algorithm with K (the decryption key to use),
and C (the cipher text). and C (the cipher text).
6. MAC Objects 6. MAC Objects
COSE supports two different MAC structures. COSE_MAC0 is used when a COSE supports two different MAC structures. COSE_MAC0 is used when a
skipping to change at page 28, line 29 skipping to change at page 28, line 42
used. The first is just a check that the content has not been used. The first is just a check that the content has not been
changed since the MAC was computed. Any class of recipient algorithm 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 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 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 use the recipient algorithm to verify who sent it. The classes of
recipient algorithms that support this are those that use a pre- recipient algorithms that support this are those that use a pre-
shared secret or do static-static key agreement (without the key wrap shared secret or do static-static key agreement (without the key wrap
step). In both of these cases, the entity that created and sent the step). In both of these cases, the entity that created and sent the
message MAC can be validated. (This knowledge of sender assumes that message MAC can be validated. (This knowledge of sender assumes that
there are only two parties involved and you did not send the message there are only two parties involved and you did not send the message
yourself.) yourself.) The origination property can be obtained with both of the
MAC message structures.
6.1. MACed Message with Recipients 6.1. MACed Message with Recipients
The multiple recipient MACed message uses two structures, the The multiple recipient MACed message uses two structures, the
COSE_Mac structure defined in this section for carrying the body and 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 COSE_recipient structure (Section 5.1) to hold the key used for
the MAC computation. Examples of MACed messages can be found in the MAC computation. Examples of MACed messages can be found in
Appendix C.5. Appendix C.5.
The MAC structure can be encoded either tagged or untagged depending The MAC structure can be encoded either tagged or untagged depending
skipping to change at page 31, line 9 skipping to change at page 31, line 26
1. Create a MAC_structure and populate it with the appropriate 1. Create a MAC_structure and populate it with the appropriate
fields. fields.
2. Create the value ToBeMaced by encoding the MAC_structure to a 2. Create the value ToBeMaced by encoding the MAC_structure to a
byte stream, using the encoding described in Section 14. byte stream, using the encoding described in Section 14.
3. Call the MAC creation algorithm passing in K (the key to use), 3. Call the MAC creation algorithm passing in K (the key to use),
alg (the algorithm to MAC with) and ToBeMaced (the value to alg (the algorithm to MAC with) and ToBeMaced (the value to
compute the MAC on). compute the MAC on).
4. Place the resulting MAC in the 'tag' field of the COSE_Mac 4. Place the resulting MAC in the 'tag' field of the COSE_Mac or
structure. COSE_Mac0 structure.
5. Encrypt and encode the MAC key for each recipient of the message. 5. Encrypt and encode the MAC key for each recipient of the message.
How to verify a MAC are: How to verify a MAC are:
1. Create a MAC_structure object and populate it with the 1. Create a MAC_structure object and populate it with the
appropriate fields. appropriate fields.
2. Create the value ToBeMaced by encoding the MAC_structure to a 2. Create the value ToBeMaced by encoding the MAC_structure to a
byte stream, using the encoding described in Section 14. byte stream, using the encoding described in Section 14.
3. Obtain the cryptographic key from one of the recipients of the 3. Obtain the cryptographic key from one of the recipients of the
message. message.
4. Call the MAC creation algorithm passing in K (the key to use), 4. Call the MAC creation algorithm passing in K (the key to use),
alg (the algorithm to MAC with) and ToBeMaced (the value to alg (the algorithm to MAC with) and ToBeMaced (the value to
compute the MAC on). compute the MAC on).
5. Compare the MAC value to the 'tag' field of the COSE_Mac 5. Compare the MAC value to the 'tag' field of the COSE_Mac or
structure. COSE_Mac0 structure.
7. Key Objects 7. Key Objects
A COSE Key structure is built on a CBOR map object. The set of 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 common parameters that can appear in a COSE Key can be found in the
IANA "COSE Key Common Parameters" registry (Section 16.5). IANA "COSE Key Common Parameters" registry (Section 16.5).
Additional parameters defined for specific key types can be found in Additional parameters defined for specific key types can be found in
the IANA "COSE Key Type Parameters" registry (Section 16.6). the IANA "COSE Key Type Parameters" registry (Section 16.6).
A COSE Key Set uses a CBOR array object as its underlying type. The A COSE Key Set uses a CBOR array object as its underlying type. The
skipping to change at page 32, line 6 skipping to change at page 32, line 27
Each element in a key set MUST be processed independently. If one Each element in a key set MUST be processed independently. If one
element in a key set is either malformed or uses a key that is not element in a key set is either malformed or uses a key that is not
understood by an application, that key is ignored and the other keys understood by an application, that key is ignored and the other keys
are processed normally. are processed normally.
The element "kty" is a required element in a COSE_Key map. The element "kty" is a required element in a COSE_Key map.
The CDDL grammar describing COSE_Key and COSE_KeySet is: The CDDL grammar describing COSE_Key and COSE_KeySet is:
COSE_Key = { COSE_Key = {
key_kty => tstr / int, 1 => tstr / int, ; kty
? key_ops => [+ (tstr / int) ], ? 2 => bstr, ; kid
? key_alg => tstr / int, ? 3 => tstr / int, ; alg
? key_kid => bstr, ? 4 => [+ (tstr / int) ], ; key_ops
? key_baseIV => bstr, ? 5 => bstr, ; Base IV
* label => values * label => values
} }
COSE_KeySet = [+COSE_Key] COSE_KeySet = [+COSE_Key]
7.1. COSE Key Common Parameters 7.1. COSE Key Common Parameters
This document defines a set of common parameters for a 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 object. Table 3 provides a summary of the parameters defined in this
section. There are also parameters that are defined for specific key section. There are also parameters that are defined for specific key
skipping to change at page 34, line 39 skipping to change at page 35, line 39
| | | | | | | |
| MAC | 9 | The key is used for creating MACs. | | MAC | 9 | The key is used for creating MACs. |
| create | | | | create | | |
| | | | | | | |
| MAC | 10 | The key is used for validating MACs. | | MAC | 10 | The key is used for validating MACs. |
| verify | | | | verify | | |
+---------+-------+-------------------------------------------------+ +---------+-------+-------------------------------------------------+
Table 4: Key Operation Values Table 4: Key Operation Values
The following provides a CDDL fragment that duplicates the assignment
labels from Table 3.
;key_labels
key_kty=1
key_kid=2
key_alg=3
key_ops=4
key_baseIV=5
8. Signature Algorithms 8. Signature Algorithms
There are two signature algorithm schemes. The first is signature There are two signature algorithm schemes. The first is signature
with appendix. In this scheme, the message content is processed and with appendix. In this scheme, the message content is processed and
a signature is produced, the signature is called the appendix. This a signature is produced, the signature is called the appendix. This
is the scheme used by algorithms such as ECDSA and RSASSA-PSS. (In is the scheme used by algorithms such as ECDSA and RSASSA-PSS. (In
fact the SSA in RSASSA-PSS stands for Signature Scheme with fact the SSA in RSASSA-PSS stands for Signature Scheme with
Appendix.) Appendix.)
The signature functions for this scheme are: The signature functions for this scheme are:
skipping to change at page 38, line 12 skipping to change at page 38, line 47
secp256r1 (aka P-256) to using secp256k1. (Both are 256 bit secp256r1 (aka P-256) to using secp256k1. (Both are 256 bit
curves.) We current do not have any way to deal with this version curves.) We current do not have any way to deal with this version
of the attack except to restrict the overall set of curves that of the attack except to restrict the overall set of curves that
can be used. can be used.
o Change the hash function used to validate the signature: If one o Change the hash function used to validate the signature: If one
has either two different hash functions of the same length, or one has either two different hash functions of the same length, or one
can truncate a hash function down, then one could potentially find can truncate a hash function down, then one could potentially find
collisions between the hash functions rather than within a single collisions between the hash functions rather than within a single
hash function. (For example, truncating SHA-512 to 256 bits might hash function. (For example, truncating SHA-512 to 256 bits might
collide with a SHA-256 bit hash value.) This attack can be collide with a SHA-256 bit hash value.) As the hash algorithm is
mitigated by including the signature algorithm identifier in the part of the signature algorithm identifier, this attack is
data to be signed. mitigated by including signature algorithm identifier in the
protected header.
8.2. Edwards-curve Digital Signature Algorithms (EdDSA) 8.2. Edwards-curve Digital Signature Algorithms (EdDSA)
[I-D.irtf-cfrg-eddsa] describes the elliptic curve signature scheme [I-D.irtf-cfrg-eddsa] describes the elliptic curve signature scheme
Edwards-curve Digital Signature Algorithm (EdDSA). In that document, Edwards-curve Digital Signature Algorithm (EdDSA). In that document,
the signature algorithm is instantiated using parameters for the signature algorithm is instantiated using parameters for
edwards25519 and edwards448 curves. The document additionally edwards25519 and edwards448 curves. The document additionally
describes two variants of the EdDSA algorithm: Pure EdDSA, where no describes two variants of the EdDSA algorithm: Pure EdDSA, where no
hash function is applied to the content before signing and, HashEdDSA hash function is applied to the content before signing and, HashEdDSA
where a hash function is applied to the content before signing and where a hash function is applied to the content before signing and
the result of that hash function is signed. For use with COSE, only the result of that hash function is signed. For the EdDSA, the
the pure EdDSA version is used. This is because it is not expected content to be signed (either the message or the pre-hash value) is
that extremely large contents are going to be needed and, based on processed twice inside of the signature algorithm. For use with
the arrangement of the message structure, the entire message is going COSE, only the pure EdDSA version is used. This is because it is not
to need to be held in memory in order to create or verify a expected that extremely large contents are going to be needed and,
signature. Thus, the use of an incremental update process would not based on the arrangement of the message structure, the entire message
be useful. Applications can provide the same features by defining is going to need to be held in memory in order to create or verify a
the content of the message as a hash value and transporting the COSE signature. This means that there does not appear to be a need to be
object and the content as separate items. 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.
The algorithms defined in this document can be found in Table 6. A The algorithms defined in this document can be found in Table 6. A
single signature algorithm is defined, which can be used for multiple single signature algorithm is defined, which can be used for multiple
curves. curves.
+-------+-------+-------------+ +-------+-------+-------------+
| name | value | description | | name | value | description |
+-------+-------+-------------+ +-------+-------+-------------+
| EdDSA | -8 | EdDSA | | EdDSA | -8 | EdDSA |
+-------+-------+-------------+ +-------+-------+-------------+
skipping to change at page 39, line 49 skipping to change at page 40, line 42
The MAC functions are: The MAC functions are:
tag = MAC_Create(message content, key) tag = MAC_Create(message content, key)
valid = MAC_Verify(message content, key, tag) valid = MAC_Verify(message content, key, tag)
MAC algorithms can be based on either a block cipher algorithm (i.e., MAC algorithms can be based on either a block cipher algorithm (i.e.,
AES-MAC) or a hash algorithm (i.e., HMAC). This document defines a AES-MAC) or a hash algorithm (i.e., HMAC). This document defines a
MAC algorithm using each of these constructions. MAC algorithm using each of these constructions.
MAC algorithms are used in the COSE_Mac and COSE_Mac1 structures. MAC algorithms are used in the COSE_Mac and COSE_Mac0 structures.
9.1. Hash-based Message Authentication Codes (HMAC) 9.1. Hash-based Message Authentication Codes (HMAC)
The Hash-base Message Authentication Code algorithm (HMAC) The Hash-based Message Authentication Code algorithm (HMAC)
[RFC2104][RFC4231] was designed to deal with length extension [RFC2104][RFC4231] was designed to deal with length extension
attacks. The algorithm was also designed to allow for new hash attacks. The algorithm was also designed to allow for new hash
algorithms to be directly plugged in without changes to the hash algorithms to be directly plugged in without changes to the hash
function. The HMAC design process has been shown as solid since, function. The HMAC design process has been shown as solid since,
while the security of hash algorithms such as MD5 has decreased over 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 time, the security of HMAC combined with MD5 has not yet been shown
to be compromised [RFC6151]. to be compromised [RFC6151].
The HMAC algorithm is parameterized by an inner and outer padding, a The HMAC algorithm is parameterized by an inner and outer padding, a
hash function (h), and an authentication tag value length. For this hash function (h), and an authentication tag value length. For this
skipping to change at page 43, line 4 skipping to change at page 44, line 4
9.2.1. Security Considerations 9.2.1. Security Considerations
A number of attacks exist against CBC-MAC that need to be considered. A number of attacks exist against CBC-MAC that need to be considered.
o A single key must only be used for messages of a fixed and known 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 length. If this is not the case, an attacker will be able to
generate a message with a valid tag given two message, tag pairs. generate a message with a valid tag given two message, tag pairs.
This can be addressed by using different keys for different length This can be addressed by using different keys for different length
messages. The current structure mitigates this problem, as a messages. The current structure mitigates this problem, as a
specific encoding structure that includes lengths is build and specific encoding structure that includes lengths is built and
signed. (CMAC also addresses this issue.) signed. (CMAC also addresses this issue.)
o If the same key is used for both encryption and authentication o If the same key is used for both encryption and authentication
operations, using CBC modes an attacker can produce messages with operations, using CBC modes an attacker can produce messages with
a valid authentication code. a valid authentication code.
o If the IV can be modified, then messages can be forged. This is o If the IV can be modified, then messages can be forged. This is
addressed by fixing the IV to all zeros. addressed by fixing the IV to all zeros.
10. Content Encryption Algorithms 10. Content Encryption Algorithms
skipping to change at page 44, line 35 skipping to change at page 45, line 35
When using a COSE key for this algorithm, the following checks are When using a COSE key for this algorithm, the following checks are
made: made:
o The 'kty' field MUST be present and it MUST be 'Symmetric'. o The 'kty' field MUST be present and it MUST be 'Symmetric'.
o If the 'alg' field present, it MUST match the AES-GCM algorithm o If the 'alg' field present, it MUST match the AES-GCM algorithm
being used. being used.
o If the 'key_ops' field is present, it MUST include 'encrypt' or o If the 'key_ops' field is present, it MUST include 'encrypt' or
'key wrap' when encrypting. 'wrap key' when encrypting.
o If the 'key_ops' field is present, it MUST include 'decrypt' or o If the 'key_ops' field is present, it MUST include 'decrypt' or
'key unwrap' when decrypting. 'unwrap key' when decrypting.
10.1.1. Security Considerations 10.1.1. Security Considerations
When using AES-GCM, the following restrictions MUST be enforced: When using AES-GCM, the following restrictions MUST be enforced:
o The key and nonce pair MUST be unique for every message encrypted. o The key and nonce pair MUST be unique for every message encrypted.
o The total amount of data encrypted for a single key MUST NOT 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 exceed 2^39 - 256 bits. An explicit check is required only in
environments where it is expected that it might be exceeded. environments where it is expected that it might be exceeded.
skipping to change at page 48, line 14 skipping to change at page 49, line 14
When using a COSE key for this algorithm, the following checks are When using a COSE key for this algorithm, the following checks are
made: made:
o The 'kty' field MUST be present and it MUST be 'Symmetric'. o The 'kty' field MUST be present and it MUST be 'Symmetric'.
o If the 'alg' field present, it MUST match the AES-CCM algorithm o If the 'alg' field present, it MUST match the AES-CCM algorithm
being used. being used.
o If the 'key_ops' field is present, it MUST include 'encrypt' or o If the 'key_ops' field is present, it MUST include 'encrypt' or
'key wrap' when encrypting. 'wrap key' when encrypting.
o If the 'key_ops' field is present, it MUST include 'decrypt' or o If the 'key_ops' field is present, it MUST include 'decrypt' or
'key unwrap' when decrypting. 'unwrap key' when decrypting.
10.2.1. Security Considerations 10.2.1. Security Considerations
When using AES-CCM, the following restrictions MUST be enforced: When using AES-CCM, the following restrictions MUST be enforced:
o The key and nonce pair MUST be unique for every message encrypted. 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 The total number of times the AES block cipher is used MUST NOT 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 exceed 2^61 operations. This limitation is the sum of times the
block cipher is used in computing the MAC value and in performing block cipher is used in computing the MAC value and in performing
stream encryption operations. An explicit check is required only stream encryption operations. An explicit check is required only
in environments where it is expected that it might be exceeded. in environments where it is expected that it might be exceeded.
[RFC3610] additionally calls out one other consideration of note. It [RFC3610] additionally calls out one other consideration of note. It
is possible to do a pre-computation attack against the algorithm in is possible to do a pre-computation attack against the algorithm in
cases where portions of the plaintext are highly predictable. This cases where portions of the plaintext are highly predictable. This
skipping to change at page 49, line 26 skipping to change at page 50, line 27
Keys may be obtained either from a key structure or from a recipient Keys may be obtained either from a key structure or from a recipient
structure. Implementations encrypting and decrypting MUST validate structure. Implementations encrypting and decrypting MUST validate
that the key type, key length and algorithm are correct and that the key type, key length and algorithm are correct and
appropriate for the entities involved. appropriate for the entities involved.
When using a COSE key for this algorithm, the following checks are When using a COSE key for this algorithm, the following checks are
made: made:
o The 'kty' field MUST be present and it MUST be 'Symmetric'. o The 'kty' field MUST be present and it MUST be 'Symmetric'.
o If the 'alg' field present, it MUST match the ChaCha algorithm o If the 'alg' field present, it MUST match the ChaCha20/Poly1305
being used. algorithm being used.
o If the 'key_ops' field is present, it MUST include 'encrypt' or o If the 'key_ops' field is present, it MUST include 'encrypt' or
'key wrap' when encrypting. 'wrap key' when encrypting.
o If the 'key_ops' field is present, it MUST include 'decrypt' or o If the 'key_ops' field is present, it MUST include 'decrypt' or
'key unwrap' when decrypting. 'unwrap key' when decrypting.
10.3.1. Security Considerations 10.3.1. Security Considerations
The pair of key, nonce MUST be unique for every invocation of the The pair of key, nonce MUST be unique for every invocation of the
algorithm. Nonce counters are considered to be an acceptable way of algorithm. Nonce counters are considered to be an acceptable way of
ensuring that they are unique. ensuring that they are unique.
11. Key Derivation Functions (KDF) 11. Key Derivation Functions (KDF)
Key Derivation Functions (KDFs) are used to take some secret value Key Derivation Functions (KDFs) are used to take some secret value
skipping to change at page 54, line 34 skipping to change at page 55, line 34
determined from elsewhere. determined from elsewhere.
This option does not need to be specified and is set to nil in This option does not need to be specified and is set to nil in
that case that case
other This contains other information that is defined by the other This contains other information that is defined by the
protocol. protocol.
This option does not need to be specified and is set to nil in This option does not need to be specified and is set to nil in
that case that case
PartyVInfo This field holds information about party V. The content PartyVInfo This field holds information about party V. The content
of the structure are the same as for the PartyUInfo but for of the structure are the same as for the PartyUInfo but for party
partyV. V.
SuppPubInfo This field contains public information that is mutually SuppPubInfo This field contains public information that is mutually
known to both parties. known to both parties.
keyDataLength This is set to the number of bits of the desired keyDataLength This is set to the number of bits of the desired
output value. (This practice means if algorithm A can use two output value. (This practice means if algorithm A can use two
different key lengths, the key derived for longer key size will different key lengths, the key derived for longer key size will
not contain the key for shorter key size as a prefix.) not contain the key for shorter key size as a prefix.)
protected This field contains the protected parameter field. If protected This field contains the protected parameter field. If
there are no elements in the protected field, then use a zero there are no elements in the protected field, then use a zero
length bstr. length bstr.
other The field other is for free form data defined by the other This field is for free form data defined by the
application. An example is that an application could defined application. An example is that an application could define
two different strings to be placed here to generate different two different strings to be placed here to generate different
keys for a data stream vs a control stream. This field is keys for a data stream vs a control stream. This field is
optional and will only be present if the application defines a optional and will only be present if the application defines a
structure for this information. Applications that define this structure for this information. Applications that define this
SHOULD use CBOR to encode the data so that types and lengths SHOULD use CBOR to encode the data so that types and lengths
are correctly included. are correctly included.
SuppPrivInfo This field contains private information that is SuppPrivInfo This field contains private information that is
mutually known private information. An example of this mutually known private information. An example of this
information would be a pre-existing shared secret. (This could, information would be a pre-existing shared secret. (This could,
skipping to change at page 58, line 21 skipping to change at page 59, line 21
| direct+HKDF-SHA-512 | -11 | HKDF | Shared secret w/ HKDF | | direct+HKDF-SHA-512 | -11 | HKDF | Shared secret w/ HKDF |
| | | SHA-512 | and SHA-512 | | | | SHA-512 | and SHA-512 |
| | | | | | | | | |
| direct+HKDF-AES-128 | -12 | HKDF AES- | Shared secret w/ AES- | | direct+HKDF-AES-128 | -12 | HKDF AES- | Shared secret w/ AES- |
| | | MAC-128 | MAC 128-bit key | | | | MAC-128 | MAC 128-bit key |
| | | | | | | | | |
| direct+HKDF-AES-256 | -13 | HKDF AES- | Shared secret w/ AES- | | direct+HKDF-AES-256 | -13 | HKDF AES- | Shared secret w/ AES- |
| | | MAC-256 | MAC 256-bit key | | | | MAC-256 | MAC 256-bit key |
+---------------------+-------+-------------+-----------------------+ +---------------------+-------+-------------+-----------------------+
Table 16: Direct Key Table 16: Direct Key with KDF
When using a COSE key for this algorithm, the following checks are When using a COSE key for this algorithm, the following checks are
made: made:
o The 'kty' field MUST be present and it MUST be 'Symmetric'. o The 'kty' field MUST be present and it MUST be 'Symmetric'.
o If the 'alg' field present, it MUST match the algorithm being o If the 'alg' field present, it MUST match the algorithm being
used. used.
o If the 'key_ops' field is present, it MUST include 'deriveKey' or o If the 'key_ops' field is present, it MUST include 'deriveKey' or
skipping to change at page 60, line 6 skipping to change at page 61, line 6
When using a COSE key for this algorithm, the following checks are When using a COSE key for this algorithm, the following checks are
made: made:
o The 'kty' field MUST be present and it MUST be 'Symmetric'. o The 'kty' field MUST be present and it MUST be 'Symmetric'.
o If the 'alg' field is present, it MUST match the AES Key Wrap o If the 'alg' field is present, it MUST match the AES Key Wrap
algorithm being used. algorithm being used.
o If the 'key_ops' field is present, it MUST include 'encrypt' or o If the 'key_ops' field is present, it MUST include 'encrypt' or
'key wrap' when encrypting. 'wrap key' when encrypting.
o If the 'key_ops' field is present, it MUST include 'decrypt' or o If the 'key_ops' field is present, it MUST include 'decrypt' or
'key unwrap' when decrypting. 'unwrap key' when decrypting.
+--------+-------+----------+-----------------------------+ +--------+-------+----------+-----------------------------+
| name | value | key size | description | | name | value | key size | description |
+--------+-------+----------+-----------------------------+ +--------+-------+----------+-----------------------------+
| A128KW | -3 | 128 | AES Key Wrap w/ 128-bit key | | A128KW | -3 | 128 | AES Key Wrap w/ 128-bit key |
| | | | | | | | | |
| A192KW | -4 | 192 | AES Key Wrap w/ 192-bit key | | A192KW | -4 | 192 | AES Key Wrap w/ 192-bit key |
| | | | | | | | | |
| A256KW | -5 | 256 | AES Key Wrap w/ 256-bit key | | A256KW | -5 | 256 | AES Key Wrap w/ 256-bit key |
+--------+-------+----------+-----------------------------+ +--------+-------+----------+-----------------------------+
Table 17: AES Key Wrap Algorithm Values Table 17: AES Key Wrap Algorithm Values
12.2.1.1. Security Considerations for AES-KW 12.2.1.1. Security Considerations for AES-KW
The shared secret needs to have some method to be regularly updated The shared secret needs to have some method to be regularly updated
over time. The shared secret is the basis of trust. over time. The shared secret is the basis of trust.
12.3. Key Encryption 12.3. Key Transport
Key Encryption mode is also called key transport mode in some Key transport mode is also called key encryption mode in some
standards. Key Encryption mode differs from Key Wrap mode in that it standards. Key transport mode differs from key wrap mode in that it
uses an asymmetric encryption algorithm rather than a symmetric uses an asymmetric encryption algorithm rather than a symmetric
encryption algorithm to protect the key. This document does not encryption algorithm to protect the key. This document does not
define any Key Encryption mode algorithms. define any key transport mode algorithms.
When using a key encryption algorithm, the COSE_Encrypt structure for When using a key transport algorithm, the COSE_Encrypt structure for
the recipient is organized as follows: the recipient is organized as follows:
o The 'protected' field MUST be absent. o The 'protected' field MUST be absent.
o The plain text to be encrypted is the key from next layer down o The plain text to be encrypted is the key from next layer down
(usually the content layer). (usually the content layer).
o At a minimum, the 'unprotected' field MUST contain the 'alg' o At a minimum, the 'unprotected' field MUST contain the 'alg'
parameter and SHOULD contain a parameter identifying the parameter and SHOULD contain a parameter identifying the
asymmetric key. asymmetric key.
skipping to change at page 64, line 11 skipping to change at page 65, line 11
+-----------+-------+---------+------------+--------+---------------+ +-----------+-------+---------+------------+--------+---------------+
Table 18: ECDH Algorithm Values Table 18: ECDH Algorithm Values
+-----------+-------+----------+-----------+------------------------+ +-----------+-------+----------+-----------+------------------------+
| name | label | type | algorithm | description | | name | label | type | algorithm | description |
+-----------+-------+----------+-----------+------------------------+ +-----------+-------+----------+-----------+------------------------+
| ephemeral | -1 | COSE_Key | ECDH-ES | Ephemeral Public key | | ephemeral | -1 | COSE_Key | ECDH-ES | Ephemeral Public key |
| key | | | | for the sender | | key | | | | for the sender |
| | | | | | | | | | | |
| static | -2 | COSE_Key | ECDH-ES | Static Public key for | | static | -2 | COSE_Key | ECDH-SS | Static Public key for |
| key | | | | the sender | | key | | | | the sender |
| | | | | | | | | | | |
| static | -3 | bstr | ECDH-SS | Static Public key | | static | -3 | bstr | ECDH-SS | Static Public key |
| key id | | | | identifier for the | | key id | | | | identifier for the |
| | | | | sender | | | | | | sender |
+-----------+-------+----------+-----------+------------------------+ +-----------+-------+----------+-----------+------------------------+
Table 19: ECDH Algorithm Parameters Table 19: ECDH Algorithm Parameters
This document defines these algorithms to be used with the curves This document defines these algorithms to be used with the curves
skipping to change at page 66, line 46 skipping to change at page 67, line 46
| | | | | | wrap w/ 192 | | | | | | | wrap w/ 192 |
| | | | | | bit key | | | | | | | bit key |
| | | | | | | | | | | | | |
| ECDH-SS + | -34 | HKDF - | no | A256KW | ECDH SS w/ | | ECDH-SS + | -34 | HKDF - | no | A256KW | ECDH SS w/ |
| A256KW | | SHA-256 | | | Concat KDF | | A256KW | | SHA-256 | | | Concat KDF |
| | | | | | and AES Key | | | | | | | and AES Key |
| | | | | | wrap w/ 256 | | | | | | | wrap w/ 256 |
| | | | | | bit key | | | | | | | bit key |
+-----------+-------+---------+------------+--------+---------------+ +-----------+-------+---------+------------+--------+---------------+
Table 20: ECDH Algorithm Values Table 20: ECDH Algorithm Values with Key Wrap
When using a COSE key for this algorithm, the following checks are When using a COSE key for this algorithm, the following checks are
made: made:
o The 'kty' field MUST be present and it MUST be 'EC2' or 'OKP'. o The 'kty' field MUST be present and it MUST be 'EC2' or 'OKP'.
o If the 'alg' field present, it MUST match the Key Agreement o If the 'alg' field present, it MUST match the Key Agreement
algorithm being used. algorithm being used.
o If the 'key_ops' field is present, it MUST include 'derive key' or o If the 'key_ops' field is present, it MUST include 'derive key' or
skipping to change at page 70, line 31 skipping to change at page 71, line 31
+------+------+-------+-------+-------------------------------------+ +------+------+-------+-------+-------------------------------------+
| crv | 1 | -1 | int / | EC Curve identifier - Taken from | | crv | 1 | -1 | int / | EC Curve identifier - Taken from |
| | | | tstr | the COSE Key Common Parameters | | | | | tstr | the COSE Key Common Parameters |
| | | | | registry | | | | | | registry |
| | | | | | | | | | | |
| x | 1 | -2 | bstr | X Coordinate | | x | 1 | -2 | bstr | X Coordinate |
| | | | | | | | | | | |
| d | 1 | -4 | bstr | Private key | | d | 1 | -4 | bstr | Private key |
+------+------+-------+-------+-------------------------------------+ +------+------+-------+-------+-------------------------------------+
Table 24: EC Key Parameters Table 24: Octet Key Pair Parameters
13.3. Symmetric Keys 13.3. Symmetric Keys
Occasionally it is required that a symmetric key be transported Occasionally it is required that a symmetric key be transported
between entities. This key structure allows for that to happen. between entities. This key structure allows for that to happen.
For symmetric keys, the 'kty' member is set to 3 (Symmetric). The For symmetric keys, the 'kty' member is set to 3 (Symmetric). The
member that is defined for this key type is: member that is defined for this key type is:
k contains the value of the key. k contains the value of the key.
skipping to change at page 73, line 9 skipping to change at page 74, line 9
* Advertising in the certificate (capabilities extension) * Advertising in the certificate (capabilities extension)
[RFC4262]. [RFC4262].
* Minimum requirements for the S/MIME, which have been updated * Minimum requirements for the S/MIME, which have been updated
over time [RFC2633][RFC5751]. over time [RFC2633][RFC5751].
16. IANA Considerations 16. IANA Considerations
16.1. CBOR Tag assignment 16.1. CBOR Tag assignment
It is requested that IANA assign the following tags from the "Concise It is requested that IANA assign the following tags from the "CBOR
Binary Object Representation (CBOR) Tags" registry. It is requested Tags" registry. It is requested that the tags for COSE_Sign1,
that the tags for COSE_Sign1, COSE_Encrypt0, and COSE_Mac0 be COSE_Encrypt0, and COSE_Mac0 be assigned in the 1 to 23 value range
assigned in the 1 to 23 value range (one byte long when encoded). It (one byte long when encoded). It is requested that the tags for
is requested that the rest of the tags be assigned in the 24 to 255 COSE_Sign, COSE_Encrypt and COSE_MAC be assigned in the 24 to 255
value range (two bytes long when encoded). value range (two bytes long when encoded).
The tags to be assigned are in Table 1. The tags to be assigned are in Table 1.
16.2. COSE Header Parameters Registry 16.2. COSE Header Parameters Registry
It is requested that IANA create a new registry entitled "COSE Header It is requested that IANA create a new registry entitled "COSE Header
Parameters". The registry is to be created as Expert Review Parameters". The registry is to be created as Expert Review
Required. Expert review guidelines are provided in Section 16.10. Required. Expert review guidelines are provided in Section 16.11.
The columns of the registry are: The columns of the registry are:
name The name is present to make it easier to refer to and discuss 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. the registration entry. The value is not used in the protocol.
Names are to be unique in the table. Names are to be unique in the table.
label This is the value used for the label. The label can be either 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 an integer or a string. Registration in the table is based on the
value of the label requested. Integer values between 1 and 255 value of the label requested. Integer values between 1 and 255
and strings of length 1 are designated as Standards Track Document and strings of length 1 are designated as Standards Track Document
required. Integer values from 256 to 65535 and strings of length required. Integer values from 256 to 65535 and strings of length
2 are designated as Specification Required. Integer values of 2 are designated as Specification Required. Integer values of
greater than 65535 and strings of length greater than 2 are greater than 65535 and strings of length greater than 2 are
designated as expert review. Integer values in the range -1 to designated as expert review. Integer values in the range -1 to
-65536 are delegated to the "COSE Header Algorithm Labels" -65536 are delegated to the "COSE Header Algorithm Parameters"
registry. Integer values less than -65536 are marked as private registry. Integer values less than -65536 are marked as private
use. use.
value This contains the CBOR type for the value portion of the value This contains the CBOR type for the value portion of the
label. label.
value registry This contains a pointer to the registry used to value registry This contains a pointer to the registry used to
contain values where the set is limited. contain values where the set is limited.
description This contains a brief description of the header field. description This contains a brief description of the header field.
specification This contains a pointer to the specification defining specification This contains a pointer to the specification defining
the header field (where public). the header field (where public).
The initial contents of the registry can be found in Table 2 and The initial contents of the registry can be found in Table 2 and
Table 27. The specification column for all rows in that table should Table 27. The specification column for all rows in that table should
be this document. be this document.
Additionally, the label of 0 is to be marked as 'Reserved'. Additionally, the label of 0 is to be marked as 'Reserved'.
16.3. COSE Header Algorithm Labels Registry 16.3. COSE Header Algorithm Parameters Registry
It is requested that IANA create a new registry entitled "COSE Header It is requested that IANA create a new registry entitled "COSE Header
Algorithm Labels". The registry is to be created as Expert Review Algorithm Parameters". The registry is to be created as Expert
Required. Expert review guidelines are provided in Section 16.10. Review Required. Expert review guidelines are provided in
Section 16.11.
The columns of the registry are: The columns of the registry are:
name The name is present to make it easier to refer to and discuss 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. the registration entry. The value is not used in the protocol.
algorithm The algorithm(s) that this registry entry is used for. algorithm The algorithm(s) that this registry entry is used for.
This value is taken from the "COSE Algorithm Values" registry. This value is taken from the "COSE Algorithm Values" registry.
Multiple algorithms can be specified in this entry. For the Multiple algorithms can be specified in this entry. For the
table, the algorithm, label pair MUST be unique. table, the algorithm, label pair MUST be unique.
skipping to change at page 74, line 49 skipping to change at page 75, line 50
the header field (where public). the header field (where public).
The initial contents of the registry can be found in Table 13, The initial contents of the registry can be found in Table 13,
Table 14, and Table 19. The specification column for all rows in Table 14, and Table 19. The specification column for all rows in
that table should be this document. that table should be this document.
16.4. COSE Algorithms Registry 16.4. COSE Algorithms Registry
It is requested that IANA create a new registry entitled "COSE It is requested that IANA create a new registry entitled "COSE
Algorithms Registry". The registry is to be created as Expert Review Algorithms Registry". The registry is to be created as Expert Review
Required. Expert review guidelines are provided in Section 16.10. Required. Expert review guidelines are provided in Section 16.11.
The columns of the registry are: The columns of the registry are:
value The value to be used to identify this algorithm. Algorithm value The value to be used to identify this algorithm. Algorithm
values MUST be unique. The value can be a positive integer, a values MUST be unique. The value can be a positive integer, a
negative integer or a string. Integer values between -256 and 255 negative integer or a string. Integer values between -256 and 255
and strings of length 1 are designated as Standards Track Document and strings of length 1 are designated as Standards Track Document
required. Integer values from -65536 to 65535 and strings of required. Integer values from -65536 to 65535 and strings of
length 2 are designated as Specification Required. Integer values length 2 are designated as Specification Required. Integer values
of greater than 65535 and strings of length greater than 2 are of greater than 65535 and strings of length greater than 2 are
designated as expert review. Integer values less than -65536 are designated as expert review. Integer values less than -65536 are
marked as private use. marked as private use.
description A short description of the algorithm. description A short description of the algorithm.
specification A document where the algorithm is defined (if publicly specification A document where the algorithm is defined (if publicly
available). available).
The initial contents of the registry can be found in Table 10, The initial contents of the registry can be found in Table 10,
Table 9, Table 11, Table 5, Table 7, Table 8, Table 15, Table 16, Table 9, Table 11, Table 5, Table 7, Table 8, Table 15, Table 16,
Table 17, and Table 18. The specification column for all rows in Table 17, Table 6, Table 20 and Table 18. The specification column
that table should be this document. for all rows in that table should be this document.
NOTE: The assignment of algorithm identifiers in this document was NOTE: The assignment of algorithm identifiers in this document was
done so that positive numbers were used for the first layer objects done so that positive numbers were used for the first layer objects
(COSE_Sign, COSE_Sign1, COSE_Encrypt, COSE_Encrypt0, COSE_Mac, and (COSE_Sign, COSE_Sign1, COSE_Encrypt, COSE_Encrypt0, COSE_Mac, and
COSE_Mac0). Negative numbers were used for second layer objects COSE_Mac0). Negative numbers were used for second layer objects
(COSE_Signature and COSE_recipient). Expert reviewers should (COSE_Signature and COSE_recipient). Expert reviewers should
consider this practice, but are not expected to be restricted by this consider this practice, but are not expected to be restricted by this
precedent. precedent.
16.5. COSE Key Common Parameters Registry 16.5. COSE Key Common Parameters Registry
It is requested that IANA create a new registry entitled "COSE Key It is requested that IANA create a new registry entitled "COSE Key
Common Parameters" registry. The registry is to be created as Expert Common Parameters" registry. The registry is to be created as Expert
Review Required. Expert review guidelines are provided in Review Required. Expert review guidelines are provided in
Section 16.10. Section 16.11.
The columns of the registry are: The columns of the registry are:
name This is a descriptive name that enables easier reference to the name This is a descriptive name that enables easier reference to the
item. It is not used in the encoding. item. It is not used in the encoding.
label The value to be used to identify this algorithm. Key map label The value to be used to identify this algorithm. Key map
labels MUST be unique. The label can be a positive integer, a labels MUST be unique. The label can be a positive integer, a
negative integer or a string. Integer values between 0 and 255 negative integer or a string. Integer values between 0 and 255
and strings of length 1 are designated as Standards Track Document and strings of length 1 are designated as Standards Track Document
skipping to change at page 76, line 18 skipping to change at page 77, line 18
CBOR Type This field contains the CBOR type for the field. CBOR Type This field contains the CBOR type for the field.
registry This field denotes the registry that values come from, if registry This field denotes the registry that values come from, if
one exists. one exists.
description This field contains a brief description for the field. description This field contains a brief description for the field.
specification This contains a pointer to the public specification specification This contains a pointer to the public specification
for the field if one exists for the field if one exists
This registry will be initially populated by the values in This registry will be initially populated by the values in Table 3.
Section 7.1. The specification column for all of these entries will The specification column for all of these entries will be this
be this document. document.
16.6. COSE Key Type Parameters Registry 16.6. COSE Key Type Parameters Registry
It is requested that IANA create a new registry "COSE Key Type It is requested that IANA create a new registry "COSE Key Type
Parameters". The registry is to be created as Expert Review Parameters". The registry is to be created as Expert Review
Required. Expert review guidelines are provided in Section 16.10. Required. Expert review guidelines are provided in Section 16.11.
The columns of the table are: The columns of the table are:
key type This field contains a descriptive string of a key type. 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 This should be a value that is in the COSE Key Common Parameters
table and is placed in the 'kty' field of a COSE Key structure. table and is placed in the 'kty' field of a COSE Key structure.
name This is a descriptive name that enables easier reference to the name This is a descriptive name that enables easier reference to the
item. It is not used in the encoding. item. It is not used in the encoding.
skipping to change at page 76, line 48 skipping to change at page 77, line 48
range of values is from -256 to -1. Labels are expected to be range of values is from -256 to -1. Labels are expected to be
reused for different keys. reused for different keys.
CBOR type This field contains the CBOR type for the field. CBOR type This field contains the CBOR type for the field.
description This field contains a brief description for the field. description This field contains a brief description for the field.
specification This contains a pointer to the public specification specification This contains a pointer to the public specification
for the field if one exists. for the field if one exists.
This registry will be initially populated by the values in Table 23 This registry will be initially populated by the values in Table 23,
and Table 25. The specification column for all of these entries will Table 24, and Table 25. The specification column for all of these
be this document. entries will be this document.
16.7. COSE Elliptic Curve Parameters Registry 16.7. COSE Key Type Registry
It is requested that IANA create a new registry "COSE Key Type
Registry"> The registry is to be created as Expert Review Required.
Expert review guidelines are provided in Section 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.
specification This contains a pointer to the public specification
for the curve if one exists.
This registry will be initially populated by the values in Table 21.
The specification column for all of these entries will be this
document.
16.8. COSE Elliptic Curve Parameters Registry
It is requested that IANA create a new registry "COSE Elliptic Curve It is requested that IANA create a new registry "COSE Elliptic Curve
Parameters". The registry is to be created as Expert Review Parameters". The registry is to be created as Expert Review
Required. Expert review guidelines are provided in Section 16.10. Required. Expert review guidelines are provided in Section 16.11.
The columns of the table are: The columns of the table are:
name This is a descriptive name that enables easier reference to the name This is a descriptive name that enables easier reference to the
item. It is not used in the encoding. item. It is not used in the encoding.
value This is the value used to identify the curve. These values value This is the value used to identify the curve. These values
MUST be unique. The integer values from -256 to 255 are MUST be unique. The integer values from -256 to 255 are
designated as Standards Track Document Required. The integer designated as Standards Track Document Required. The integer
values from 256 to 65535 and -65536 to -257 are designated as values from 256 to 65535 and -65536 to -257 are designated as
skipping to change at page 77, line 32 skipping to change at page 79, line 8
private use. private use.
key type This designates the key type(s) that can be used with this key type This designates the key type(s) that can be used with this
curve. curve.
description This field contains a brief description of the curve. description This field contains a brief description of the curve.
specification This contains a pointer to the public specification specification This contains a pointer to the public specification
for the curve if one exists. for the curve if one exists.
This registry will be initially populated by the values in Table 21. This registry will be initially populated by the values in Table 22.
The specification column for all of these entries will be this The specification column for all of these entries will be this
document. document.
16.8. Media Type Registrations 16.9. Media Type Registrations
16.8.1. COSE Security Message 16.9.1. COSE Security Message
This section registers the "application/cose" media type in the This section registers the "application/cose" media type in the
"Media Types" registry. These media types are used to indicate that "Media Types" registry. These media types are used to indicate that
the content is a COSE_MSG. the content is a COSE message.
Type name: application Type name: application
Subtype name: cose Subtype name: cose
Required parameters: N/A Required parameters: N/A
Optional parameters: cose-type Optional parameters: cose-type
Encoding considerations: binary Encoding considerations: binary
skipping to change at page 78, line 27 skipping to change at page 80, line 4
* Magic number(s): N/A * Magic number(s): N/A
* File extension(s): cbor * File extension(s): cbor
* Macintosh file type code(s): N/A * Macintosh file type code(s): N/A
Person & email address to contact for further information: Person & email address to contact for further information:
iesg@ietf.org iesg@ietf.org
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: N/A Restrictions on usage: N/A
Author: Jim Schaad, ietf@augustcellars.com Author: Jim Schaad, ietf@augustcellars.com
Change Controller: IESG Change Controller: IESG
Provisional registration? No Provisional registration? No
16.8.2. COSE Key media type 16.9.2. COSE Key media type
This section registers the "application/cose-key" and "application/ This section registers the "application/cose-key" and "application/
cose-key-set" media types in the "Media Types" registry. These media cose-key-set" media types in the "Media Types" registry. These media
types are used to indicate, respectively, that content is a COSE_Key types are used to indicate, respectively, that content is a COSE_Key
or COSE_KeySet object. or COSE_KeySet object.
The template for registering "application/cose-key" is:
Type name: application Type name: application
Subtype name: cose-key Subtype name: cose-key
Required parameters: N/A Required parameters: N/A
Optional parameters: N/A Optional parameters: N/A
Encoding considerations: binary Encoding considerations: binary
Security considerations: See the Security Considerations section Security considerations: See the Security Considerations section
of RFC TBD. of RFC TBD.
Interoperability considerations: N/A Interoperability considerations: N/A
Published specification: RFC TBD Published specification: RFC TBD
Applications that use this media type: To be identified Applications that use this media type: To be identified
Fragment identifier considerations: N/A Fragment identifier considerations: N/A
skipping to change at page 79, line 36 skipping to change at page 81, line 14
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: N/A Restrictions on usage: N/A
Author: Jim Schaad, ietf@augustcellars.com Author: Jim Schaad, ietf@augustcellars.com
Change Controller: IESG Change Controller: IESG
Provisional registration? No Provisional registration? No
The template for registering "application/cose-key-set" is:
Type name: application Type name: application
Subtype name: cose-key-set Subtype name: cose-key-set
Required parameters: N/A Required parameters: N/A
Optional parameters: N/A Optional parameters: N/A
Encoding considerations: binary Encoding considerations: binary
skipping to change at page 80, line 22 skipping to change at page 82, line 4
* File extension(s): cbor * File extension(s): cbor
* Macintosh file type code(s): N/A * Macintosh file type code(s): N/A
Person & email address to contact for further information: Person & email address to contact for further information:
iesg@ietf.org iesg@ietf.org
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: N/A Restrictions on usage: N/A
Author: Jim Schaad, ietf@augustcellars.com Author: Jim Schaad, ietf@augustcellars.com
Change Controller: IESG Change Controller: IESG
Provisional registration? No Provisional registration? No
16.9. CoAP Content Format Registrations 16.10. CoAP Content-Format Registrations
This section registers a set of content formats for CoAP. ID IANA is requested to add the following entries to the "CoAP Content-
assignment in the 24-255 range is requested. Format" registry. ID assignment in the 24-255 range is requested.
+---------------------------------+----------+-------+--------------+ +---------------------------------+----------+-------+--------------+
| Media Type | Encoding | ID | Reference | | Media Type | Encoding | ID | Reference |
+---------------------------------+----------+-------+--------------+ +---------------------------------+----------+-------+--------------+
| application/cose; cose-type | | TBD10 | [This | | application/cose; cose-type | | TBD10 | [This |
| ="cose-sign" | | | Document] | | ="cose-sign" | | | Document] |
| | | | | | | | | |
| application/cose; cose-type | | TBD11 | [This | | application/cose; cose-type | | TBD11 | [This |
| ="cose-sign1" | | | Document] | | ="cose-sign1" | | | Document] |
| | | | | | | | | |
| application/cose; cose-type | | TBD12 | [This | | application/cose; cose-type | | TBD12 | [This |
| ="cose-encrypt" | | | Document] | | ="cose-encrypt" | | | Document] |
| | | | | | | | | |
| application/cose; cose-type | | TBD13 | [This | | application/cose; cose-type | | TBD13 | [This |
| ="cose-encrypt1" | | | Document] | | ="cose-encrypt0" | | | Document] |
| | | | | | | | | |
| application/cose; cose-type | | TBD14 | [This | | application/cose; cose-type | | TBD14 | [This |
| ="cose-mac" | | | Document] | | ="cose-mac" | | | Document] |
| | | | | | | | | |
| application/cose; cose-type | | TBD15 | [This | | application/cose; cose-type | | TBD15 | [This |
| ="cose-mac0" | | | Document] | | ="cose-mac0" | | | Document] |
| | | | | | | | | |
| application/cose-key | | TBD16 | [This | | application/cose-key | | TBD16 | [This |
| | | | Document] | | | | | Document] |
| | | | | | | | | |
| application/cose-key-set | | TBD17 | [This | | application/cose-key-set | | TBD17 | [This |
| | | | Document | | | | | Document |
+---------------------------------+----------+-------+--------------+ +---------------------------------+----------+-------+--------------+
Table 26 Table 26
16.10. Expert Review Instructions 16.11. Expert Review Instructions
All of the IANA registries established in this document are defined All of the IANA registries established in this document are defined
as expert review. This section gives some general guidelines for as expert review. This section gives some general guidelines for
what the experts should be looking for, but they are being designated what the experts should be looking for, but they are being designated
as experts for a reason so they should be given substantial latitude. as experts for a reason so they should be given substantial latitude.
Expert reviewers should take into consideration the following points: Expert reviewers should take into consideration the following points:
o Point squatting should be discouraged. Reviewers are encouraged o Point squatting should be discouraged. Reviewers are encouraged
to get sufficient information for registration requests to ensure to get sufficient information for registration requests to ensure
skipping to change at page 82, line 20 skipping to change at page 83, line 30
to be used outside of closed environments in an interoperable way. to be used outside of closed environments in an interoperable way.
When specifications are not provided, the description provided When specifications are not provided, the description provided
needs to have sufficient information to identify what the point is needs to have sufficient information to identify what the point is
being used for. being used for.
o Experts should take into account the expected usage of fields when o Experts should take into account the expected usage of fields when
approving point assignment. The fact that there is a range for approving point assignment. The fact that there is a range for
standards track documents does not mean that a standards track standards track documents does not mean that a standards track
document cannot have points assigned outside of that range. Some document cannot have points assigned outside of that range. Some
of the ranges are restricted in range, items that are not expected of the ranges are restricted in range, items that are not expected
to be common or are not expected to be used in restricted to be common or are not expected to be used in constrained
environments should be assigned to values which will encode to environments should be assigned to values which will encode to
longer byte strings. longer byte strings.
o When algorithms are registered, vanity registrations should be o When algorithms are registered, vanity registrations should be
discouraged. One way to do this is to require applications to discouraged. One way to do this is to require registrations to
provide additional documentation on security analysis of provide additional documentation on security analysis of the
algorithms. Another thing that should be considered is to request algorithm. Another thing that should be considered is to request
for an opinion on the algorithm from the Cryptographic Forum for an opinion on the algorithm from the Crypto Forum Research
Research Group. Algorithms that do not meet the security Group (CFRG). Algorithms that do not meet the security
requirements of the community and the messages structures should requirements of the community and the messages structures should
not be registered. not be registered.
17. Implementation Status 17. Implementation Status
This section records the status of known implementations of the This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC6982]. Internet-Draft, and is based on a proposal described in [RFC6982].
The description of implementations in this section is intended to The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to assist the IETF in its decision processes in progressing drafts to
skipping to change at page 84, line 23 skipping to change at page 85, line 32
18. Security Considerations 18. Security Considerations
There are a number of security considerations that need to be taken There are a number of security considerations that need to be taken
into account by implementers of this specification. The security into account by implementers of this specification. The security
considerations that are specific to an individual algorithm are considerations that are specific to an individual algorithm are
placed next to the description of the algorithm. While some placed next to the description of the algorithm. While some
considerations have been highlighted here, additional considerations considerations have been highlighted here, additional considerations
may be found in the documents listed in the references. may be found in the documents listed in the references.
Implementations need to protect the private key for any individuals. Implementations need to protect the private key material for any
There are some cases in this document that need to be highlighted on individuals. There are some cases in this document that need to be
this issue. highlighted on this issue.
o Using the same key for two different algorithms can leak o Using the same key for two different algorithms can leak
information about the key. It is therefore recommended that keys information about the key. It is therefore recommended that keys
be restricted to a single algorithm. be restricted to a single algorithm.
o Use of 'direct' as a recipient algorithm combined with a second o Use of 'direct' as a recipient algorithm combined with a second
recipient algorithm, either directly in a separate message, recipient algorithm, either directly in a separate message,
exposes the direct key to the second recipient. exposes the direct key to the second recipient.
o Several of the algorithms in this document have limits on the o Several of the algorithms in this document have limits on the
skipping to change at page 85, line 36 skipping to change at page 86, line 43
o Is the cryptographic algorithm acceptable in the current context? o Is the cryptographic algorithm acceptable in the current context?
o Have the restrictions associated with the key, such as algorithm o Have the restrictions associated with the key, such as algorithm
or freshness, been checked and are correct? or freshness, been checked and are correct?
o Is the request something that is reasonable, given the current o Is the request something that is reasonable, given the current
state of the application? state of the application?
o Have any security considerations that are part of the message been o Have any security considerations that are part of the message been
enforced (as specified by the application or crit parameter)? enforced (as specified by the application or 'crit' parameter)?
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 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.
One area that has been starting to get exposure is doing traffic One area that has been starting to get exposure is doing traffic
analysis of encrypted messages based on the length of the message. analysis of encrypted messages based on the length of the message.
This specification does not provide for a uniform method of providing This specification does not provide for a uniform method of providing
padding as part of the message structure. An observer can padding as part of the message structure. An observer can
distinguish between two different strings (for example, 'YES' and distinguish between two different strings (for example, 'YES' and
'NO') based on length for all of the content encryption algorithms 'NO') based on length for all of the content encryption algorithms
that are defined in this document. This means that it is up to that are defined in this document. This means that it is up to
applications to document how content padding is to be done in order applications to document how content padding is to be done in order
to prevent or discourage such analysis. (For example, the strings to prevent or discourage such analysis. (For example, the strings
skipping to change at page 90, line 51 skipping to change at page 92, line 21
requirement is stated so that there will never be a case where requirement is stated so that there will never be a case where
there is any ambiguity about the question of which algorithm there is any ambiguity about the question of which algorithm
should be used, the implicit or the explicit one. This applies should be used, the implicit or the explicit one. This applies
even if the transported algorithm identifier is a protected even if the transported algorithm identifier is a protected
attribute. This applies even if the transported algorithm is the attribute. This applies even if the transported algorithm is the
same as the implicit algorithm. same as the implicit algorithm.
o Applications need to define the set of information that is to be o Applications need to define the set of information that is to be
considered to be part of a context when omitting algorithm considered to be part of a context when omitting algorithm
identifiers. At a minimum, this would be the key identifier (if identifiers. At a minimum, this would be the key identifier (if
needed), the key, the algorithm, and the COSE structure it can be needed), the key, the algorithm, and the COSE structure it is used
used for. Applications should restrict the use of a single key to with. Applications should restrict the use of a single key to a
a single algorithm. As noted for some of the algorithms in this single algorithm. As noted for some of the algorithms in this
document, the use of the same key in different related algorithms document, the use of the same key in different related algorithms
can lead to leakage of information about the key, leakage about can lead to leakage of information about the key, leakage about
the data or the ability to perform forgeries. the data or the ability to perform forgeries.
o In many cases, applications that make the algorithm identifier o In many cases, applications that make the algorithm identifier
implicit will also want to make the context identifier implicit implicit will also want to make the context identifier implicit
for the same reason. That is, omitting the context identifier for the same reason. That is, omitting the context identifier
will decrease the message size (potentially significantly will decrease the message size (potentially significantly
depending on the length of the identifier). Applications that do depending on the length of the identifier). Applications that do
this will need to describe the circumstances where the context this will need to describe the circumstances where the context
skipping to change at page 93, line 34 skipping to change at page 94, line 49
required to infer which key is to be used from context rather than 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 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 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 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 the key identifier be part of the value signed as it does not serve a
cryptographic purpose. If the key validates the counter signature, cryptographic purpose. If the key validates the counter signature,
then it should be presumed that the entity associated with that key then it should be presumed that the entity associated with that key
produced the signature.) produced the signature.)
When computing the signature for the bare counter signature header, When computing the signature for the bare counter signature header,
the same Sig_structure defined in Section 4.4. The sign_protected the same Sig_structure defined in Section 4.4 is used. The
field is omitted, as there is no protected header field in in this sign_protected field is omitted, as there is no protected header
counter signature header. The value of "CounterSignature0" is placed field in in this counter signature header. The value of
in the context field of the Sig_stucture. "CounterSignature0" is placed in the context field of the
Sig_stucture.
+-------------------------------+-------+------------+-------------+ +-------------------+-------+--------+------------------------------+
| name | label | value type | description | | name | label | value | description |
+-------------------------------+-------+------------+-------------+ | | | type | |
| counter signature w/o headers | 9 | bstr | | +-------------------+-------+--------+------------------------------+
+-------------------------------+-------+------------+-------------+ | CounterSignature0 | 9 | bstr | Counter signature with |
| | | | implied signer and headers |
+-------------------+-------+--------+------------------------------+
Table 27 Table 27
Appendix B. Two Layers of Recipient Information Appendix B. Two Layers of Recipient Information
All of the currently defined recipient algorithms classes only use All of the currently defined recipient algorithms classes only use
two layers of the COSE_Encrypt structure. The first layer is the two layers of the COSE_Encrypt structure. The first layer is the
message content and the second layer is the content key encryption. message content and the second layer is the content key encryption.
However, if one uses a recipient algorithm such as RSA-KEM (see However, if one uses a recipient algorithm such as RSA-KEM (see
Appendix A of RSA-KEM [RFC5990]), then it makes sense to have three Appendix A of RSA-KEM [RFC5990]), then it makes sense to have three
skipping to change at page 96, line 42 skipping to change at page 97, line 42
using, it may be necessary to deal with &gt; as an entity.) using, it may be necessary to deal with &gt; as an entity.)
//artwork[@type='CDDL']/text() //artwork[@type='CDDL']/text()
C.1. Examples of Signed Message C.1. Examples of Signed Message
C.1.1. Single Signature C.1.1. Single Signature
This example uses the following: This example uses the following:
o Signature Algorithm: ECDSA w/ SHA-256, Curve P-256-1 o Signature Algorithm: ECDSA w/ SHA-256, Curve P-256
Size of binary file is 104 bytes Size of binary file is 104 bytes
991( 991(
[ [
/ protected / h'', / protected / h'',
/ unprotected / {}, / unprotected / {},
/ payload / 'This is the content.', / payload / 'This is the content.',
/ signatures / [ / signatures / [
[ [
/ protected / h'a10126' / { / protected / h'a10126' / {
skipping to change at page 97, line 29 skipping to change at page 98, line 29
be470355c9657ce0' be470355c9657ce0'
] ]
] ]
] ]
) )
C.1.2. Multiple Signers C.1.2. Multiple Signers
This example uses the following: This example uses the following:
o Signature Algorithm: ECDSA w/ SHA-256, Curve P-256-1 o Signature Algorithm: ECDSA w/ SHA-256, Curve P-256
o Signature Algorithm: ECDSA w/ SHA-512, Curve P-521 o Signature Algorithm: ECDSA w/ SHA-512, Curve P-521
Size of binary file is 278 bytes Size of binary file is 278 bytes
991( 991(
[ [
/ protected / h'', / protected / h'',
/ unprotected / {}, / unprotected / {},
/ payload / 'This is the content.', / payload / 'This is the content.',
/ signatures / [ / signatures / [
skipping to change at page 98, line 42 skipping to change at page 99, line 42
37942e8a8348cc91' 37942e8a8348cc91'
] ]
] ]
] ]
) )
C.1.3. Counter Signature C.1.3. Counter Signature
This example uses the following: This example uses the following:
o Signature Algorithm: ECDSA w/ SHA-256, Curve P-256-1 o Signature Algorithm: ECDSA w/ SHA-256, Curve P-256
o The same parameters are used for both the signature and the o The same parameters are used for both the signature and the
counter signature. counter signature.
Size of binary file is 181 bytes Size of binary file is 181 bytes
991( 991(
[ [
/ protected / h'', / protected / h'',
/ unprotected / { / unprotected / {
/ countersign / 7:[ / countersign / 7:[
skipping to change at page 99, line 41 skipping to change at page 100, line 41
be470355c9657ce0' be470355c9657ce0'
] ]
] ]
] ]
) )
C.1.4. Signature w/ Criticality C.1.4. Signature w/ Criticality
This example uses the following: This example uses the following:
o Signature Algorithm: ECDSA w/ SHA-256, Curve P-256-1 o Signature Algorithm: ECDSA w/ SHA-256, Curve P-256
o There is a criticality marker on the "reserved" header parameter o There is a criticality marker on the "reserved" header parameter
Size of binary file is 126 bytes Size of binary file is 126 bytes
991( 991(
[ [
/ protected / h'a2687265736572766564f40281687265736572766564' / / protected / h'a2687265736572766564f40281687265736572766564' /
{ {
"reserved":false, "reserved":false,
\ crit \ 2:[ \ crit \ 2:[
skipping to change at page 100, line 37 skipping to change at page 101, line 37
] ]
] ]
) )
C.2. Single Signer Examples C.2. Single Signer Examples
C.2.1. Single ECDSA signature C.2.1. Single ECDSA signature
This example uses the following: This example uses the following:
o Signature Algorithm: ECDSA w/ SHA-256, Curve P-256-1 o Signature Algorithm: ECDSA w/ SHA-256, Curve P-256
Size of binary file is 100 bytes Size of binary file is 100 bytes
997( 997(
[ [
/ protected / h'a10126' / { / protected / h'a10126' / {
\ alg \ 1:-7 \ ECDSA 256 \ \ alg \ 1:-7 \ ECDSA 256 \
} / , } / ,
/ unprotected / { / unprotected / {
/ kid / 4:'11' / kid / 4:'11'
}, },
 End of changes. 96 change blocks. 
257 lines changed or deleted 313 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/