draft-ietf-cose-msg-20.txt   draft-ietf-cose-msg-21.txt 
COSE Working Group J. Schaad COSE Working Group J. Schaad
Internet-Draft August Cellars Internet-Draft August Cellars
Intended status: Standards Track October 10, 2016 Intended status: Standards Track October 16, 2016
Expires: April 13, 2017 Expires: April 19, 2017
CBOR Object Signing and Encryption (COSE) CBOR Object Signing and Encryption (COSE)
draft-ietf-cose-msg-20 draft-ietf-cose-msg-21
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 basic security services defined for this data format. ability to have basic security services defined for this data format.
This document defines the CBOR Object Signing and Encryption (COSE) This document defines the CBOR Object Signing and Encryption (COSE)
specification. This specification describes how to create and 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 specification additionally specifies CBOR for serialization. This specification additionally specifies
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 April 13, 2017. This Internet-Draft will expire on April 19, 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 3, line 21 skipping to change at page 3, line 21
10.1. AES GCM . . . . . . . . . . . . . . . . . . . . . . . . 45 10.1. AES GCM . . . . . . . . . . . . . . . . . . . . . . . . 45
10.1.1. Security Considerations . . . . . . . . . . . . . . 46 10.1.1. Security Considerations . . . . . . . . . . . . . . 46
10.2. AES CCM . . . . . . . . . . . . . . . . . . . . . . . . 47 10.2. AES CCM . . . . . . . . . . . . . . . . . . . . . . . . 47
10.2.1. Security Considerations . . . . . . . . . . . . . . 50 10.2.1. Security Considerations . . . . . . . . . . . . . . 50
10.3. ChaCha20 and Poly1305 . . . . . . . . . . . . . . . . . 50 10.3. ChaCha20 and Poly1305 . . . . . . . . . . . . . . . . . 50
10.3.1. Security Considerations . . . . . . . . . . . . . . 51 10.3.1. Security Considerations . . . . . . . . . . . . . . 51
11. Key Derivation Functions (KDF) . . . . . . . . . . . . . . . 51 11. Key Derivation Functions (KDF) . . . . . . . . . . . . . . . 51
11.1. HMAC-based Extract-and-Expand Key Derivation Function 11.1. HMAC-based Extract-and-Expand Key Derivation Function
(HKDF) . . . . . . . . . . . . . . . . . . . . . . . . . 52 (HKDF) . . . . . . . . . . . . . . . . . . . . . . . . . 52
11.2. Context Information Structure . . . . . . . . . . . . . 54 11.2. Context Information Structure . . . . . . . . . . . . . 54
12. Content Key Distribution Methods . . . . . . . . . . . . . . 57 12. Content Key Distribution Methods . . . . . . . . . . . . . . 59
12.1. Direct Encryption . . . . . . . . . . . . . . . . . . . 58 12.1. Direct Encryption . . . . . . . . . . . . . . . . . . . 59
12.1.1. Direct Key . . . . . . . . . . . . . . . . . . . . . 58 12.1.1. Direct Key . . . . . . . . . . . . . . . . . . . . . 60
12.1.2. Direct Key with KDF . . . . . . . . . . . . . . . . 59 12.1.2. Direct Key with KDF . . . . . . . . . . . . . . . . 60
12.2. Key Wrapping . . . . . . . . . . . . . . . . . . . . . . 60 12.2. Key Wrapping . . . . . . . . . . . . . . . . . . . . . . 62
12.2.1. AES Key Wrapping . . . . . . . . . . . . . . . . . . 61 12.2.1. AES Key Wrapping . . . . . . . . . . . . . . . . . . 63
12.3. Key Transport . . . . . . . . . . . . . . . . . . . . . 62 12.3. Key Transport . . . . . . . . . . . . . . . . . . . . . 64
12.4. Direct Key Agreement . . . . . . . . . . . . . . . . . . 62 12.4. Direct Key Agreement . . . . . . . . . . . . . . . . . . 64
12.4.1. ECDH . . . . . . . . . . . . . . . . . . . . . . . . 63 12.4.1. ECDH . . . . . . . . . . . . . . . . . . . . . . . . 65
12.4.2. Security Considerations . . . . . . . . . . . . . . 66 12.4.2. Security Considerations . . . . . . . . . . . . . . 69
12.5. Key Agreement with Key Wrap . . . . . . . . . . . . . . 67 12.5. Key Agreement with Key Wrap . . . . . . . . . . . . . . 69
12.5.1. ECDH . . . . . . . . . . . . . . . . . . . . . . . . 67 12.5.1. ECDH . . . . . . . . . . . . . . . . . . . . . . . . 69
13. Key Object Parameters . . . . . . . . . . . . . . . . . . . . 69 13. Key Object Parameters . . . . . . . . . . . . . . . . . . . . 71
13.1. Elliptic Curve Keys . . . . . . . . . . . . . . . . . . 69 13.1. Elliptic Curve Keys . . . . . . . . . . . . . . . . . . 72
13.1.1. Double Coordinate Curves . . . . . . . . . . . . . . 70 13.1.1. Double Coordinate Curves . . . . . . . . . . . . . . 72
13.2. Octet Key Pair . . . . . . . . . . . . . . . . . . . . . 71 13.2. Octet Key Pair . . . . . . . . . . . . . . . . . . . . . 73
13.3. Symmetric Keys . . . . . . . . . . . . . . . . . . . . . 72 13.3. Symmetric Keys . . . . . . . . . . . . . . . . . . . . . 74
14. CBOR Encoder Restrictions . . . . . . . . . . . . . . . . . . 73 14. CBOR Encoder Restrictions . . . . . . . . . . . . . . . . . . 75
15. Application Profiling Considerations . . . . . . . . . . . . 73 15. Application Profiling Considerations . . . . . . . . . . . . 75
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 75 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 77
16.1. CBOR Tag assignment . . . . . . . . . . . . . . . . . . 75 16.1. CBOR Tag assignment . . . . . . . . . . . . . . . . . . 77
16.2. COSE Header Parameters Registry . . . . . . . . . . . . 75 16.2. COSE Header Parameters Registry . . . . . . . . . . . . 77
16.3. COSE Header Algorithm Parameters Registry . . . . . . . 76 16.3. COSE Header Algorithm Parameters Registry . . . . . . . 78
16.4. COSE Algorithms Registry . . . . . . . . . . . . . . . . 77 16.4. COSE Algorithms Registry . . . . . . . . . . . . . . . . 78
16.5. COSE Key Common Parameters Registry . . . . . . . . . . 77 16.5. COSE Key Common Parameters Registry . . . . . . . . . . 79
16.6. COSE Key Type Parameters Registry . . . . . . . . . . . 78 16.6. COSE Key Type Parameters Registry . . . . . . . . . . . 80
16.7. COSE Key Type Registry . . . . . . . . . . . . . . . . . 79 16.7. COSE Key Type Registry . . . . . . . . . . . . . . . . . 81
16.8. COSE Elliptic Curve Parameters Registry . . . . . . . . 79 16.8. COSE Elliptic Curve Parameters Registry . . . . . . . . 81
16.9. Media Type Registrations . . . . . . . . . . . . . . . . 80 16.9. Media Type Registrations . . . . . . . . . . . . . . . . 82
16.9.1. COSE Security Message . . . . . . . . . . . . . . . 80 16.9.1. COSE Security Message . . . . . . . . . . . . . . . 82
16.9.2. COSE Key media type . . . . . . . . . . . . . . . . 81 16.9.2. COSE Key media type . . . . . . . . . . . . . . . . 83
16.10. CoAP Content-Format Registrations . . . . . . . . . . . 83 16.10. CoAP Content-Format Registrations . . . . . . . . . . . 85
16.11. Expert Review Instructions . . . . . . . . . . . . . . . 84 16.11. Expert Review Instructions . . . . . . . . . . . . . . . 86
17. Implementation Status . . . . . . . . . . . . . . . . . . . . 85 17. Implementation Status . . . . . . . . . . . . . . . . . . . . 87
17.1. Author's Versions . . . . . . . . . . . . . . . . . . . 86 17.1. Author's Versions . . . . . . . . . . . . . . . . . . . 88
17.2. COSE Testing Library . . . . . . . . . . . . . . . . . . 86 17.2. COSE Testing Library . . . . . . . . . . . . . . . . . . 88
18. Security Considerations . . . . . . . . . . . . . . . . . . . 87 18. Security Considerations . . . . . . . . . . . . . . . . . . . 89
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 89 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 91
19.1. Normative References . . . . . . . . . . . . . . . . . . 89 19.1. Normative References . . . . . . . . . . . . . . . . . . 91
19.2. Informative References . . . . . . . . . . . . . . . . . 90 19.2. Informative References . . . . . . . . . . . . . . . . . 92
Appendix A. Making Mandatory Algorithm Header Optional . . . . . 93 Appendix A. Making Mandatory Algorithm Header Optional . . . . . 95
A.1. Algorithm Identification . . . . . . . . . . . . . . . . 93 A.1. Algorithm Identification . . . . . . . . . . . . . . . . 95
A.2. Counter Signature Without Headers . . . . . . . . . . . . 96 A.2. Counter Signature Without Headers . . . . . . . . . . . . 98
Appendix B. Two Layers of Recipient Information . . . . . . . . 97 Appendix B. Two Layers of Recipient Information . . . . . . . . 99
Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 99 Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 101
C.1. Examples of Signed Message . . . . . . . . . . . . . . . 100 C.1. Examples of Signed Message . . . . . . . . . . . . . . . 102
C.1.1. Single Signature . . . . . . . . . . . . . . . . . . 100 C.1.1. Single Signature . . . . . . . . . . . . . . . . . . 102
C.1.2. Multiple Signers . . . . . . . . . . . . . . . . . . 101 C.1.2. Multiple Signers . . . . . . . . . . . . . . . . . . 103
C.1.3. Counter Signature . . . . . . . . . . . . . . . . . . 102 C.1.3. Counter Signature . . . . . . . . . . . . . . . . . . 104
C.1.4. Signature w/ Criticality . . . . . . . . . . . . . . 103 C.1.4. Signature w/ Criticality . . . . . . . . . . . . . . 105
C.2. Single Signer Examples . . . . . . . . . . . . . . . . . 104 C.2. Single Signer Examples . . . . . . . . . . . . . . . . . 106
C.2.1. Single ECDSA signature . . . . . . . . . . . . . . . 104 C.2.1. Single ECDSA signature . . . . . . . . . . . . . . . 106
C.3. Examples of Enveloped Messages . . . . . . . . . . . . . 105 C.3. Examples of Enveloped Messages . . . . . . . . . . . . . 107
C.3.1. Direct ECDH . . . . . . . . . . . . . . . . . . . . . 105 C.3.1. Direct ECDH . . . . . . . . . . . . . . . . . . . . . 107
C.3.2. Direct plus Key Derivation . . . . . . . . . . . . . 106 C.3.2. Direct plus Key Derivation . . . . . . . . . . . . . 108
C.3.3. Counter Signature on Encrypted Content . . . . . . . 107 C.3.3. Counter Signature on Encrypted Content . . . . . . . 109
C.3.4. Encrypted Content with External Data . . . . . . . . 109 C.3.4. Encrypted Content with External Data . . . . . . . . 111
C.4. Examples of Encrypted Messages . . . . . . . . . . . . . 109 C.4. Examples of Encrypted Messages . . . . . . . . . . . . . 111
C.4.1. Simple Encrypted Message . . . . . . . . . . . . . . 109 C.4.1. Simple Encrypted Message . . . . . . . . . . . . . . 111
C.4.2. Encrypted Message w/ a Partial IV . . . . . . . . . . 110 C.4.2. Encrypted Message w/ a Partial IV . . . . . . . . . . 112
C.5. Examples of MACed messages . . . . . . . . . . . . . . . 110 C.5. Examples of MACed messages . . . . . . . . . . . . . . . 112
C.5.1. Shared Secret Direct MAC . . . . . . . . . . . . . . 110 C.5.1. Shared Secret Direct MAC . . . . . . . . . . . . . . 112
C.5.2. ECDH Direct MAC . . . . . . . . . . . . . . . . . . . 111 C.5.2. ECDH Direct MAC . . . . . . . . . . . . . . . . . . . 113
C.5.3. Wrapped MAC . . . . . . . . . . . . . . . . . . . . . 112 C.5.3. Wrapped MAC . . . . . . . . . . . . . . . . . . . . . 114
C.5.4. Multi-recipient MACed message . . . . . . . . . . . . 113 C.5.4. Multi-recipient MACed message . . . . . . . . . . . . 115
C.6. Examples of MAC0 messages . . . . . . . . . . . . . . . . 114 C.6. Examples of MAC0 messages . . . . . . . . . . . . . . . . 116
C.6.1. Shared Secret Direct MAC . . . . . . . . . . . . . . 114 C.6.1. Shared Secret Direct MAC . . . . . . . . . . . . . . 116
C.7. COSE Keys . . . . . . . . . . . . . . . . . . . . . . . . 115 C.7. COSE Keys . . . . . . . . . . . . . . . . . . . . . . . . 117
C.7.1. Public Keys . . . . . . . . . . . . . . . . . . . . . 115 C.7.1. Public Keys . . . . . . . . . . . . . . . . . . . . . 117
C.7.2. Private Keys . . . . . . . . . . . . . . . . . . . . 116 C.7.2. Private Keys . . . . . . . . . . . . . . . . . . . . 118
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 118 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 120
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 119 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 121
1. Introduction 1. Introduction
There has been an increased focus on small, constrained devices that There has been an increased focus on small, constrained devices that
make up the Internet of Things (IoT). One of the standards that has make up the Internet of Things (IoT). One of the standards that has
come out of this process is the Concise Binary Object Representation come out of this process is the Concise Binary Object Representation
(CBOR) [RFC7049]. CBOR extended the data model of the JavaScript (CBOR) [RFC7049]. CBOR extended the data model of the JavaScript
Object Notation (JSON) [RFC7159] by allowing for binary data, among Object Notation (JSON) [RFC7159] by allowing for binary data, among
other changes. CBOR is being adopted by several of the IETF working other changes. CBOR is being adopted by several of the IETF working
groups dealing with the IoT world as their encoding of data groups dealing with the IoT world as their encoding of data
skipping to change at page 14, line 4 skipping to change at page 14, line 4
located using the IANA "Media Types" registry. Applications located using the IANA "Media Types" registry. Applications
SHOULD provide this parameter if the content structure is SHOULD provide this parameter if the content structure is
potentially ambiguous. potentially ambiguous.
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 associated with this 'kid' same 'kid' value, so all of the keys may need to be checked to
may need to be checked. 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. This is not a identifier values are hints about which key to use. This is not a
security critical field. For this reason, it can be placed in the security critical field. For this reason, it can be placed in the
unprotected headers bucket. unprotected headers bucket.
IV: This parameter holds the Initialization Vector (IV) value. For IV: This parameter holds the Initialization Vector (IV) value. For
some symmetric encryption algorithms this may be referred to as a some symmetric encryption algorithms this may be referred to as a
nonce. The IV can be placed in the unprotected header as nonce. The IV can be placed in the unprotected header as
modifying the IV will cause the decryption to yield plaintext that modifying the IV will cause the decryption to yield plaintext that
is readily detectable as garbled. is readily detectable as garbled.
skipping to change at page 21, line 42 skipping to change at page 21, line 42
1. Create a Sig_structure object and populate it with the 1. Create a Sig_structure object and populate it with the
appropriate fields. appropriate fields.
2. Create the value ToBeSigned by encoding the Sig_structure to a 2. Create the value ToBeSigned by encoding the Sig_structure to a
byte string, using the encoding described in Section 14. byte string, using the encoding described in Section 14.
3. Call the signature verification algorithm passing in K (the key 3. Call the signature verification algorithm passing in K (the key
to verify with), alg (the algorithm used sign with), ToBeSigned to verify with), alg (the algorithm used sign with), ToBeSigned
(the value to sign), and sig (the signature to be verified). (the value to sign), and sig (the signature to be verified).
In addition to performing the signature verification, the application In addition to performing the signature verification, one must also
may also perform the appropriate checks to ensure that the key is perform the appropriate checks to ensure that the key is correctly
correctly paired with the signing identity and that the signing paired with the signing identity and that the signing identity is
identity is authorized before performing actions. authorized before performing actions.
4.5. Computing Counter Signatures 4.5. Computing Counter Signatures
Counter signatures provide a method of associating different Counter signatures provide a method of associating different
signature generated by different signers with some piece of content. signature generated by different signers with some piece of content.
This is normally used to provide a signature on a signature allowing This is normally used to provide a signature on a signature allowing
for a proof that a signature existed at a given time (i.e., a for a proof that a signature existed at a given time (i.e., a
Timestamp). In this document, we allow for counter signatures to Timestamp). In this document, we allow for counter signatures to
exist in a greater number of environments. As an example, it is exist in a greater number of environments. As an example, it is
possible to place a counter signature in the unprotected attributes possible to place a counter signature in the unprotected attributes
skipping to change at page 37, line 41 skipping to change at page 37, line 41
Signature algorithms are used with the COSE_Signature and COSE_Sign1 Signature algorithms are used with the COSE_Signature and COSE_Sign1
structures. At this time, only signatures with appendixes are structures. At this time, only signatures with appendixes are
defined for use with COSE, however considerable interest has been defined for use with COSE, however considerable interest has been
expressed in using a signature with message recovery algorithm due to expressed in using a signature with message recovery algorithm due to
the effective size reduction that is possible. Implementations will the effective size reduction that is possible. Implementations will
need to keep this in mind for later possible integration. need to keep this in mind for later possible integration.
8.1. ECDSA 8.1. ECDSA
ECDSA [DSS] defines a signature algorithm using ECC. Implementations ECDSA [DSS] defines a signature algorithm using ECC.
SHOULD use a deterministic version of ECDSA such as the one defined
in [RFC6979]. The use of a deterministic signature algorithms allows
for systems to avoid relying on random number generators in order to
avoid generating the same value of 'k' (the per-message random
value). Biased generation of the value be attacked and collisions
will lead to leaked keys. It additionally allows for doing
deterministic tests for the signature algorithm. The use of
deterministic ECDSA does not lessen the need to to have good random
number generation when creating the private key.
The ECDSA signature algorithm is parameterized with a hash function The ECDSA signature algorithm is parameterized with a hash function
(h). In the event that the length of the hash function output is (h). In the event that the length of the hash function output is
greater than the group of the key, the left-most bytes of the hash greater than the group of the key, the left-most bytes of the hash
output are used. output are used.
The algorithms defined in this document can be found in Table 5. The algorithms defined in this document can be found in Table 5.
+-------+-------+---------+------------------+ +-------+-------+---------+------------------+
| name | value | hash | description | | name | value | hash | description |
skipping to change at page 39, line 20 skipping to change at page 39, line 14
o If the 'key_ops' field is present, it MUST include 'verify' when o If the 'key_ops' field is present, it MUST include 'verify' when
verifying an ECDSA signature. verifying an ECDSA signature.
8.1.1. Security Considerations 8.1.1. Security Considerations
The security strength of the signature is no greater than the minimum The security strength of the signature is no greater than the minimum
of the security strength associated with the bit length of the key of the security strength associated with the bit length of the key
and the security strength of the hash function. and the security strength of the hash function.
Systems that have poor random number generation can leak their keys
by signing two different messages with the same value 'k' (the per-
message random value). [RFC6979] provides a method to deal with this
problem by making 'k' be deterministic based on the message content
rather than randomly generated. Applications that specify ECDSA
should evaluate the ability to get good random number generation and
require deterministic signatures where poor random number generation
exists.
Note: Use of this technique is a good idea even when good random Note: Use of this technique is a good idea even when good random
number generation exists. Doing so both reduces the possibility of number generation exists. Doing so both reduces the possibility of
having the same value of 'k' in two signature operations and allows having the same value of 'k' in two signature operations and allows
for reproducible signature values, which helps testing. for reproducible signature values, which helps testing.
There are two substitution attacks that can theoretically be mounted There are two substitution attacks that can theoretically be mounted
against the ECDSA signature algorithm. against the ECDSA signature algorithm.
o Changing the curve used to validate the signature: If one changes o Changing the curve used to validate the signature: If one changes
the curve used to validate the signature, then potentially one the curve used to validate the signature, then potentially one
skipping to change at page 54, line 5 skipping to change at page 54, line 5
| | | | | | | |
| HKDF AES- | AES-CBC-MAC-128 | HKDF using AES-MAC as the PRF | | HKDF AES- | AES-CBC-MAC-128 | HKDF using AES-MAC as the PRF |
| MAC-128 | | w/ 128-bit key | | MAC-128 | | w/ 128-bit key |
| | | | | | | |
| HKDF AES- | AES-CBC-MAC-256 | HKDF using AES-MAC as the PRF | | HKDF AES- | AES-CBC-MAC-256 | HKDF using AES-MAC as the PRF |
| MAC-256 | | w/ 256-bit key | | MAC-256 | | w/ 256-bit key |
+---------------+-----------------+---------------------------------+ +---------------+-----------------+---------------------------------+
Table 12: HKDF algorithms Table 12: HKDF algorithms
+------+-------+------+-------------+ +------+-------+------+-------------------------------+-------------+
| name | label | type | description | | name | label | type | algorithm | description |
+------+-------+------+-------------+ +------+-------+------+-------------------------------+-------------+
| salt | -20 | bstr | Random salt | | salt | -20 | bstr | direct+HKDF-SHA-256, direct | Random salt |
+------+-------+------+-------------+ | | | | +HKDF-SHA-512, direct+HKDF- | |
| | | | AES-128, direct+HKDF-AES-256, | |
| | | | ECDH-ES+HKDF-256, ECDH- | |
| | | | ES+HKDF-512, ECDH- | |
| | | | SS+HKDF-256, ECDH- | |
| | | | SS+HKDF-512, ECDH-ES+A128KW, | |
| | | | ECDH-ES+A192KW, ECDH- | |
| | | | ES+A256KW, ECDH-SS+A128KW, | |
| | | | ECDH-SS+A192KW, ECDH- | |
| | | | SS+A256KW | |
+------+-------+------+-------------------------------+-------------+
Table 13: HKDF Algorithm Parameters Table 13: HKDF Algorithm Parameters
11.2. Context Information Structure 11.2. Context Information Structure
The context information structure is used to ensure that the derived The context information structure is used to ensure that the derived
keying material is "bound" to the context of the transaction. The keying material is "bound" to the context of the transaction. The
context information structure used here is based on that defined in context information structure used here is based on that defined in
[SP800-56A]. By using CBOR for the encoding of the context [SP800-56A]. By using CBOR for the encoding of the context
information structure, we automatically get the same type and length information structure, we automatically get the same type and length
skipping to change at page 55, line 5 skipping to change at page 55, line 14
o Fields can be defined by parameters from the message. We define a o Fields can be defined by parameters from the message. We define a
set of parameters in Table 14 that can be used to carry the values set of parameters in Table 14 that can be used to carry the values
associated with the context structure. Examples of this are associated with the context structure. Examples of this are
identities and nonce values. These parameters are designed to be identities and nonce values. These parameters are designed to be
placed in the unprotected bucket of the recipient structure. placed in the unprotected bucket of the recipient structure.
(They do not need to be in the protected bucket since they already (They do not need to be in the protected bucket since they already
are included in the cryptographic computation by virtue of being are included in the cryptographic computation by virtue of being
included in the context structure.) included in the context structure.)
+---------------+-------+-----------+-------------------------------+ +----------+-------+------+---------------------------+-------------+
| name | label | type | description | | name | label | type | algorithm | description |
+---------------+-------+-----------+-------------------------------+ +----------+-------+------+---------------------------+-------------+
| PartyU | -21 | bstr | Party U identity Information | | PartyU | -21 | bstr | direct+HKDF-SHA-256, | Party U |
| identity | | | | | identity | | | direct+HKDF-SHA-512, | identity |
| | | | | | | | | direct+HKDF-AES-128, | Information |
| PartyU nonce | -22 | bstr / | Party U provided nonce | | | | | direct+HKDF-AES-256, | |
| | | int | | | | | | ECDH-ES+HKDF-256, ECDH- | |
| | | | | | | | | ES+HKDF-512, ECDH- | |
| PartyU other | -23 | bstr | Party U other provided | | | | | SS+HKDF-256, ECDH- | |
| | | | information | | | | | SS+HKDF-512, ECDH- | |
| | | | | | | | | ES+A128KW, ECDH- | |
| PartyV | -24 | bstr | Party V identity Information | | | | | ES+A192KW, ECDH- | |
| identity | | | | | | | | ES+A256KW, ECDH- | |
| | | | | | | | | SS+A128KW, ECDH- | |
| PartyV nonce | -25 | bstr / | Party V provided nonce | | | | | SS+A192KW, ECDH-SS+A256KW | |
| | | int | | | | | | | |
| | | | | | PartyU | -22 | bstr | direct+HKDF-SHA-256, | Party U |
| PartyV other | -26 | bstr | Party V other provided | | nonce | | / | direct+HKDF-SHA-512, | provided |
| | | | information | | | | int | direct+HKDF-AES-128, | nonce |
+---------------+-------+-----------+-------------------------------+ | | | | direct+HKDF-AES-256, | |
| | | | ECDH-ES+HKDF-256, ECDH- | |
| | | | ES+HKDF-512, ECDH- | |
| | | | SS+HKDF-256, ECDH- | |
| | | | SS+HKDF-512, ECDH- | |
| | | | ES+A128KW, ECDH- | |
| | | | ES+A192KW, ECDH- | |
| | | | ES+A256KW, ECDH- | |
| | | | SS+A128KW, ECDH- | |
| | | | SS+A192KW, ECDH-SS+A256KW | |
| | | | | |
| PartyU | -23 | bstr | direct+HKDF-SHA-256, | Party U |
| other | | | direct+HKDF-SHA-512, | other |
| | | | direct+HKDF-AES-128, | provided |
| | | | direct+HKDF-AES-256, | information |
| | | | ECDH-ES+HKDF-256, ECDH- | |
| | | | ES+HKDF-512, ECDH- | |
| | | | SS+HKDF-256, ECDH- | |
| | | | SS+HKDF-512, ECDH- | |
| | | | ES+A128KW, ECDH- | |
| | | | ES+A192KW, ECDH- | |
| | | | ES+A256KW, ECDH- | |
| | | | SS+A128KW, ECDH- | |
| | | | SS+A192KW, ECDH-SS+A256KW | |
| | | | | |
| PartyV | -24 | bstr | direct+HKDF-SHA-256, | Party V |
| identity | | | direct+HKDF-SHA-512, | identity |
| | | | direct+HKDF-AES-128, | Information |
| | | | direct+HKDF-AES-256, | |
| | | | ECDH-ES+HKDF-256, ECDH- | |
| | | | ES+HKDF-512, ECDH- | |
| | | | SS+HKDF-256, ECDH- | |
| | | | SS+HKDF-512, ECDH- | |
| | | | ES+A128KW, ECDH- | |
| | | | ES+A192KW, ECDH- | |
| | | | ES+A256KW, ECDH- | |
| | | | SS+A128KW, ECDH- | |
| | | | SS+A192KW, ECDH-SS+A256KW | |
| | | | | |
| PartyV | -25 | bstr | direct+HKDF-SHA-256, | Party V |
| nonce | | / | direct+HKDF-SHA-512, | provided |
| | | int | direct+HKDF-AES-128, | nonce |
| | | | direct+HKDF-AES-256, | |
| | | | ECDH-ES+HKDF-256, ECDH- | |
| | | | ES+HKDF-512, ECDH- | |
| | | | SS+HKDF-256, ECDH- | |
| | | | SS+HKDF-512, ECDH- | |
| | | | ES+A128KW, ECDH- | |
| | | | ES+A192KW, ECDH- | |
| | | | ES+A256KW, ECDH- | |
| | | | SS+A128KW, ECDH- | |
| | | | SS+A192KW, ECDH-SS+A256KW | |
| | | | | |
| PartyV | -26 | bstr | direct+HKDF-SHA-256, | Party V |
| other | | | direct+HKDF-SHA-512, | other |
| | | | direct+HKDF-AES-128, | provided |
| | | | direct+HKDF-AES-256, | information |
| | | | ECDH-ES+HKDF-256, ECDH- | |
| | | | ES+HKDF-512, ECDH- | |
| | | | SS+HKDF-256, ECDH- | |
| | | | SS+HKDF-512, ECDH- | |
| | | | ES+A128KW, ECDH- | |
| | | | ES+A192KW, ECDH- | |
| | | | ES+A256KW, ECDH- | |
| | | | SS+A128KW, ECDH- | |
| | | | SS+A192KW, ECDH-SS+A256KW | |
+----------+-------+------+---------------------------+-------------+
Table 14: Context Algorithm Parameters Table 14: Context Algorithm Parameters
We define a CBOR object to hold the context information. This object We define a CBOR object to hold the context information. This object
is referred to as COSE_KDF_Context. The object is based on a CBOR is referred to as COSE_KDF_Context. The object is based on a CBOR
array type. The fields in the array are: array type. The fields in the array are:
AlgorithmID This field indicates the algorithm for which the key AlgorithmID This field indicates the algorithm for which the key
material will be used. This normally is either a Key Wrap material will be used. This normally is either a Key Wrap
algorithm identifier or a Content Encryption algorithm identifier. algorithm identifier or a Content Encryption algorithm identifier.
The values are from the "COSE Algorithm Value" registry. This The values are from the "COSE Algorithm Value" registry. This
skipping to change at page 66, line 5 skipping to change at page 68, line 5
| | | | | | directly | | | | | | | directly |
| | | | | | | | | | | | | |
| ECDH-SS + | -28 | HKDF - | no | none | ECDH SS w/ | | ECDH-SS + | -28 | HKDF - | no | none | ECDH SS w/ |
| HKDF-512 | | SHA-512 | | | HKDF - | | HKDF-512 | | SHA-512 | | | HKDF - |
| | | | | | generate key | | | | | | | generate key |
| | | | | | directly | | | | | | | directly |
+-----------+-------+---------+------------+--------+---------------+ +-----------+-------+---------+------------+--------+---------------+
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+HKDF-256, | Ephemeral |
| key | | | | for the sender | | key | | | ECDH-ES+HKDF-512, | Public key |
| | | | | | | | | | ECDH-ES+A128KW, | for the |
| static | -2 | COSE_Key | ECDH-SS | Static Public key for | | | | | ECDH-ES+A192KW, | sender |
| key | | | | the sender | | | | | ECDH-ES+A256KW | |
| | | | | | | | | | | |
| static | -3 | bstr | ECDH-SS | Static Public key | | static | -2 | COSE_Key | ECDH-SS+HKDF-256, | Static |
| key id | | | | identifier for the | | key | | | ECDH-SS+HKDF-512, | Public key |
| | | | | sender | | | | | ECDH-SS+A128KW, | for the |
+-----------+-------+----------+-----------+------------------------+ | | | | ECDH-SS+A192KW, | sender |
| | | | ECDH-SS+A256KW | |
| | | | | |
| static | -3 | bstr | ECDH-SS+HKDF-256, | Static |
| key id | | | ECDH-SS+HKDF-512, | Public key |
| | | | ECDH-SS+A128KW, | identifier |
| | | | ECDH-SS+A192KW, | for the |
| | | | ECDH-SS+A256KW | sender |
+-----------+-------+----------+---------------------+--------------+
Table 19: ECDH Algorithm Parameters 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
P-256, P-384, P-521, X25519, and X448. Implementations MUST verify P-256, P-384, P-521, X25519, and X448. Implementations MUST verify
that the key type and curve are correct. Different curves are that the key type and curve are correct. Different curves are
restricted to different key types. Implementations MUST verify that restricted to different key types. Implementations MUST verify that
the curve and algorithm are appropriate for the entities involved. the curve and algorithm are 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
skipping to change at page 71, line 24 skipping to change at page 73, line 30
d contains the private key. d contains the private key.
For public keys, it is REQUIRED that 'crv', 'x' and 'y' be present in For public keys, it is REQUIRED that 'crv', 'x' and 'y' be present in
the structure. For private keys, it is REQUIRED that 'crv' and 'd' the structure. For private keys, it is REQUIRED that 'crv' and 'd'
be present in the structure. For private keys, it is RECOMMENDED be present in the structure. For private keys, it is RECOMMENDED
that 'x' and 'y' also be present, but they can be recomputed from the that 'x' and 'y' also be present, but they can be recomputed from the
required elements and omitting them saves on space. required elements and omitting them saves on space.
+------+-------+-------+---------+----------------------------------+ +------+-------+-------+---------+----------------------------------+
| name | key | value | type | description | | name | key | label | type | description |
| | type | | | | | | type | | | |
+------+-------+-------+---------+----------------------------------+ +------+-------+-------+---------+----------------------------------+
| crv | 2 | -1 | int / | EC Curve identifier - Taken from | | crv | 2 | -1 | int / | EC Curve identifier - Taken from |
| | | | tstr | the COSE Curves registry | | | | | tstr | the COSE Curves registry |
| | | | | | | | | | | |
| x | 2 | -2 | bstr | X Coordinate | | x | 2 | -2 | bstr | X Coordinate |
| | | | | | | | | | | |
| y | 2 | -3 | bstr / | Y Coordinate | | y | 2 | -3 | bstr / | Y Coordinate |
| | | | bool | | | | | | bool | |
| | | | | | | | | | | |
skipping to change at page 72, line 19 skipping to change at page 74, line 25
d contains the private key. d contains the private key.
For public keys, it is REQUIRED that 'crv' and 'x' be present in the For public keys, it is REQUIRED that 'crv' and 'x' be present in the
structure. For private keys, it is REQUIRED that 'crv' and 'd' be structure. For private keys, it is REQUIRED that 'crv' and 'd' be
present in the structure. For private keys, it is RECOMMENDED that present in the structure. For private keys, it is RECOMMENDED that
'x' also be present, but it can be recomputed from the required 'x' also be present, but it can be recomputed from the required
elements and omitting it saves on space. elements and omitting it saves on space.
+------+------+-------+-------+-------------------------------------+ +------+------+-------+-------+-------------------------------------+
| name | key | value | type | description | | name | key | label | type | description |
| | type | | | | | | type | | | |
+------+------+-------+-------+-------------------------------------+ +------+------+-------+-------+-------------------------------------+
| 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 |
+------+------+-------+-------+-------------------------------------+ +------+------+-------+-------+-------------------------------------+
skipping to change at page 73, line 6 skipping to change at page 75, line 8
k contains the value of the key. k contains the value of the key.
This key structure does not have a form that contains only public This key structure does not have a form that contains only public
members. As it is expected that this key structure is going to be members. As it is expected that this key structure is going to be
transmitted, care must be taking that it is never transmitted transmitted, care must be taking that it is never transmitted
accidentally or insecurely. For symmetric keys, it is REQUIRED that accidentally or insecurely. For symmetric keys, it is REQUIRED that
'k' be present in the structure. 'k' be present in the structure.
+------+----------+-------+------+-------------+ +------+----------+-------+------+-------------+
| name | key type | value | type | description | | name | key type | label | type | description |
+------+----------+-------+------+-------------+ +------+----------+-------+------+-------------+
| k | 4 | -1 | bstr | Key Value | | k | 4 | -1 | bstr | Key Value |
+------+----------+-------+------+-------------+ +------+----------+-------+------+-------------+
Table 25: Symmetric Key Parameters Table 25: Symmetric Key Parameters
14. CBOR Encoder Restrictions 14. CBOR Encoder Restrictions
There has been an attempt to limit the number of places where the There has been an attempt to limit the number of places where the
document needs to impose restrictions on how the CBOR Encoder needs document needs to impose restrictions on how the CBOR Encoder needs
skipping to change at page 76, line 37 skipping to change at page 78, line 39
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.
label This is the value used for the label. The label is an integer label This is the value used for the label. The label is an integer
in the range of -1 to -65536. in the range of -1 to -65536.
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
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 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
skipping to change at page 77, line 40 skipping to change at page 79, line 34
recommended: Does the IETF have a concensus recommendation to use recommended: Does the IETF have a concensus recommendation to use
the algorithm. The legal values are 'yes', 'no' and 'deprecated'. the algorithm. The legal values are 'yes', 'no' and 'deprecated'.
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, Table 6, Table 20 and Table 18. The specification column Table 17, Table 6, Table 20 and Table 18. The specification column
for all rows in the table should be this document. The recommneded for all rows in the table should be this document. The recommneded
column for all rows in the table are set to 'yes'. column for all rows in the table are set to 'yes'.
Additionally, the label of 0 is to be marked as 'Reserved'.
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
skipping to change at page 81, line 4 skipping to change at page 82, line 49
"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 message. 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
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: IoT applications sending Applications that use this media type: IoT applications sending
security content over HTTP(S) transports. security content over HTTP(S) transports.
skipping to change at page 82, line 4 skipping to change at page 83, line 49
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: 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
skipping to change at page 83, line 4 skipping to change at page 84, line 50
The template for registering "application/cose-key-set" is: 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
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: Distribution of COSE based Applications that use this media type: Distribution of COSE based
keys for IoT applications. keys for IoT applications.
skipping to change at page 97, line 19 skipping to change at page 99, line 19
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 is used. The the same Sig_structure defined in Section 4.4 is used. The
sign_protected field is omitted, as there is no protected header sign_protected field is omitted, as there is no protected header
field in in this counter signature header. The value of field in in this counter signature header. The value of
"CounterSignature0" is placed in the context field of the "CounterSignature0" is placed in the context field of the
Sig_stucture. Sig_stucture.
+-------------------+-------+--------+------------------------------+ +-------------------+-------+-------+-------+-----------------------+
| name | label | value | description | | name | label | value | value | description |
| | | type | | | | | type | | |
+-------------------+-------+--------+------------------------------+ +-------------------+-------+-------+-------+-----------------------+
| CounterSignature0 | 9 | bstr | Counter signature with | | CounterSignature0 | 9 | bstr | | Counter signature |
| | | | implied signer and headers | | | | | | 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
 End of changes. 24 change blocks. 
148 lines changed or deleted 231 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/