draft-ietf-cose-rfc8152bis-algs-04.txt   draft-ietf-cose-rfc8152bis-algs-05.txt 
COSE Working Group J. Schaad COSE Working Group J. Schaad
Internet-Draft August Cellars Internet-Draft August Cellars
Obsoletes8152 (if approved) August 18, 2019 Obsoletes: 8152 (if approved) September 11, 2019
Intended status: Standards Track Intended status: Standards Track
Expires: February 19, 2020 Expires: March 14, 2020
CBOR Object Signing and Encryption (COSE): Initial Algorithms CBOR Object Signing and Encryption (COSE): Initial Algorithms
draft-ietf-cose-rfc8152bis-algs-04 draft-ietf-cose-rfc8152bis-algs-05
Abstract Abstract
Concise Binary Object Representation (CBOR) is a data format designed Concise Binary Object Representation (CBOR) is a 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)
protocol. This specification describes how to create and process protocol. This specification describes how to create and process
signatures, message authentication codes, and encryption using CBOR signatures, message authentication codes, and encryption using CBOR
for serialization. COSE additionally describes how to represent for serialization. COSE additionally describes how to represent
skipping to change at page 2, line 10 skipping to change at page 2, line 10
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 February 19, 2020. This Internet-Draft will expire on 14 March 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 52 skipping to change at page 2, line 52
3.1.1. Security Considerations . . . . . . . . . . . . . . . 10 3.1.1. Security Considerations . . . . . . . . . . . . . . . 10
3.2. AES Message Authentication Code (AES-CBC-MAC) . . . . . . 10 3.2. AES Message Authentication Code (AES-CBC-MAC) . . . . . . 10
3.2.1. Security Considerations . . . . . . . . . . . . . . . 11 3.2.1. Security Considerations . . . . . . . . . . . . . . . 11
4. Content Encryption Algorithms . . . . . . . . . . . . . . . . 12 4. Content Encryption Algorithms . . . . . . . . . . . . . . . . 12
4.1. AES GCM . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. AES GCM . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1.1. Security Considerations . . . . . . . . . . . . . . . 13 4.1.1. Security Considerations . . . . . . . . . . . . . . . 13
4.2. AES CCM . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2. AES CCM . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2.1. Security Considerations . . . . . . . . . . . . . . . 16 4.2.1. Security Considerations . . . . . . . . . . . . . . . 16
4.3. ChaCha20 and Poly1305 . . . . . . . . . . . . . . . . . . 16 4.3. ChaCha20 and Poly1305 . . . . . . . . . . . . . . . . . . 16
4.3.1. Security Considerations . . . . . . . . . . . . . . . 17 4.3.1. Security Considerations . . . . . . . . . . . . . . . 17
5. Key Derivation Functions (KDFs) . . . . . . . . . . . . . . . 18 5. Key Derivation Functions (KDFs) . . . . . . . . . . . . . . . 17
5.1. HMAC-Based Extract-and-Expand Key Derivation Function 5.1. HMAC-Based Extract-and-Expand Key Derivation Function
(HKDF) . . . . . . . . . . . . . . . . . . . . . . . . . 18 (HKDF) . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.2. Context Information Structure . . . . . . . . . . . . . . 20 5.2. Context Information Structure . . . . . . . . . . . . . . 19
6. Content Key Distribution Methods . . . . . . . . . . . . . . 25 6. Content Key Distribution Methods . . . . . . . . . . . . . . 24
6.1. Direct Encryption . . . . . . . . . . . . . . . . . . . . 25 6.1. Direct Encryption . . . . . . . . . . . . . . . . . . . . 25
6.1.1. Direct Key . . . . . . . . . . . . . . . . . . . . . 25 6.1.1. Direct Key . . . . . . . . . . . . . . . . . . . . . 25
6.1.2. Direct Key with KDF . . . . . . . . . . . . . . . . . 26 6.1.2. Direct Key with KDF . . . . . . . . . . . . . . . . . 26
6.2. AES Key Wrap . . . . . . . . . . . . . . . . . . . . . . 28 6.2. AES Key Wrap . . . . . . . . . . . . . . . . . . . . . . 28
6.2.1. Security Considerations for AES-KW . . . . . . . . . 29 6.2.1. Security Considerations for AES-KW . . . . . . . . . 28
6.3. Direct ECDH . . . . . . . . . . . . . . . . . . . . . . . 29 6.3. Direct ECDH . . . . . . . . . . . . . . . . . . . . . . . 29
6.3.1. Security Considerations . . . . . . . . . . . . . . . 32 6.3.1. Security Considerations . . . . . . . . . . . . . . . 32
6.4. ECDH with Key Wrap . . . . . . . . . . . . . . . . . . . 32 6.4. ECDH with Key Wrap . . . . . . . . . . . . . . . . . . . 32
7. Key Object Parameters . . . . . . . . . . . . . . . . . . . . 34 7. Key Object Parameters . . . . . . . . . . . . . . . . . . . . 34
7.1. Elliptic Curve Keys . . . . . . . . . . . . . . . . . . . 35 7.1. Elliptic Curve Keys . . . . . . . . . . . . . . . . . . . 34
7.1.1. Double Coordinate Curves . . . . . . . . . . . . . . 35 7.1.1. Double Coordinate Curves . . . . . . . . . . . . . . 35
7.2. Octet Key Pair . . . . . . . . . . . . . . . . . . . . . 37 7.2. Octet Key Pair . . . . . . . . . . . . . . . . . . . . . 36
7.3. Symmetric Keys . . . . . . . . . . . . . . . . . . . . . 37 7.3. Symmetric Keys . . . . . . . . . . . . . . . . . . . . . 37
8. CBOR Encoding Restrictions . . . . . . . . . . . . . . . . . 38 8. CBOR Encoding Restrictions . . . . . . . . . . . . . . . . . 38
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
10. Security Considerations . . . . . . . . . . . . . . . . . . . 39 10. Security Considerations . . . . . . . . . . . . . . . . . . . 38
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
11.1. Normative References . . . . . . . . . . . . . . . . . . 40 11.1. Normative References . . . . . . . . . . . . . . . . . . 40
11.2. Informative References . . . . . . . . . . . . . . . . . 42 11.2. Informative References . . . . . . . . . . . . . . . . . 42
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 44 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 43
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 44 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 44
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 "Concise Binary Object Representation come out of this process is "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) [RFC8259] by allowing for binary data, among Object Notation (JSON) [RFC8259] 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
structures. CBOR was designed specifically to be both small in terms structures. CBOR was designed specifically to be both small in terms
of messages transport and implementation size and be a schema-free of messages transport and implementation size and be a schema-free
decoder. A need exists to provide message security services for IoT, decoder. A need exists to provide message security services for IoT,
and using CBOR as the message-encoding format makes sense. and using CBOR as the message-encoding format makes sense.
The core COSE specification consists of two documents. The core COSE specification consists of two documents.
[I-D.ietf-cose-rfc8152bis-struct] contains the serialization [I-D.ietf-cose-rfc8152bis-struct] contains the serialization
structures and the procedures for using the different cryptographic structures and the procedures for using the different cryptographic
algorithms. This document provides for an initial set of algorithms algorithms. This document provides an initial set of algorithms for
that are then use with those structures. Additional algorithms use with those structures. Additional algorithms beyond what are in
beyond what are in this document are defined elsewhere. this document are defined elsewhere.
1.1. Requirements Terminology 1.1. Requirements Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
1.2. Changes from RFC8152 1.2. Changes from RFC8152
skipping to change at page 5, line 10 skipping to change at page 5, line 10
create the example, some of the intermediate values that can be used create the example, some of the intermediate values that can be used
in debugging the example and the output of the example presented in in debugging the example and the output of the example presented in
both a hex and a CBOR diagnostic notation format. Some of the both a hex and a CBOR diagnostic notation format. Some of the
examples at the site are designed failure testing cases; these are examples at the site are designed failure testing cases; these are
clearly marked as such in the JSON file. If errors in the examples clearly marked as such in the JSON file. If errors in the examples
in this document are found, the examples on GitHub will be updated, in this document are found, the examples on GitHub will be updated,
and a note to that effect will be placed in the JSON file. and a note to that effect will be placed in the JSON file.
2. Signature Algorithms 2. Signature Algorithms
Section 9.1 of [I-D.ietf-cose-rfc8152bis-struct] Appendix Section 9.1 of [I-D.ietf-cose-rfc8152bis-struct] contains a
[I-D.ietf-cose-rfc8152bis-struct] contains a generic description of generic description of signature algorithms. The document defines
signature algorithms. The document defines signature algorithm signature algorithm identifiers for two signature algorithms.
identifiers for two signature algorithms.
2.1. ECDSA 2.1. ECDSA
ECDSA [DSS] defines a signature algorithm using ECC. Implementations ECDSA [DSS] defines a signature algorithm using ECC. Implementations
SHOULD use a deterministic version of ECDSA such as the one defined SHOULD use a deterministic version of ECDSA such as the one defined
in [RFC6979]. The use of a deterministic signature algorithm allows in [RFC6979]. The use of a deterministic signature algorithm allows
for systems to avoid relying on random number generators in order to for systems to avoid relying on random number generators in order to
avoid generating the same value of 'k' (the per-message random avoid generating the same value of 'k' (the per-message random
value). Biased generation of the value 'k' can be attacked, and value). Biased generation of the value 'k' can be attacked, and
collisions of this value leads to leaked keys. It additionally collisions of this value leads to leaked keys. It additionally
skipping to change at page 8, line 47 skipping to change at page 8, line 45
and Elliptic Curve Diffie-Hellman (ECDH); for this reason, they and Elliptic Curve Diffie-Hellman (ECDH); for this reason, they
should not be used with the other algorithm. should not be used with the other algorithm.
If batch signature verification is performed, a well-seeded If batch signature verification is performed, a well-seeded
cryptographic random number generator is REQUIRED. Signing and non- cryptographic random number generator is REQUIRED. Signing and non-
batch signature verification are deterministic operations and do not batch signature verification are deterministic operations and do not
need random numbers of any kind. need random numbers of any kind.
3. Message Authentication Code (MAC) Algorithms 3. Message Authentication Code (MAC) Algorithms
Section 9.2 of [I-D.ietf-cose-rfc8152bis-struct] Appendix Section 9.2 of [I-D.ietf-cose-rfc8152bis-struct] contains a
[I-D.ietf-cose-rfc8152bis-struct] contains a generic description of generic description of MAC algorithms. This section defines the
MAC algorithms. This section defines the conventions for two MAC conventions for two MAC algorithms.
algorithms.
3.1. Hash-Based Message Authentication Codes (HMACs) 3.1. Hash-Based Message Authentication Codes (HMACs)
HMAC [RFC2104] [RFC4231] was designed to deal with length extension HMAC [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
specification, the inner and outer padding are fixed to the values specification, the inner and outer padding are fixed to the values
set in [RFC2104]. The length of the authentication tag corresponds set in [RFC2104]. The length of the authentication tag corresponds
to the difficulty of producing a forgery. For use in constrained to the difficulty of producing a forgery. For use in constrained
environments, we define one HMAC algorithms that is truncated. There environments, we define one HMAC algorithm that is truncated. There
are currently no known issues with truncation; however, the security are currently no known issues with truncation; however, the security
strength of the message tag is correspondingly reduced in strength. strength of the message tag is correspondingly reduced in strength.
When truncating, the leftmost tag length bits are kept and When truncating, the leftmost tag length bits are kept and
transmitted. transmitted.
The algorithms defined in this document can be found in Table 3. The algorithms defined in this document can be found in Table 3.
+-------------+-------+---------+------------+----------------------+ +-------------+-------+---------+------------+----------------------+
| Name | Value | Hash | Tag Length | Description | | Name | Value | Hash | Tag Length | Description |
+=============+=======+=========+============+======================+ +=============+=======+=========+============+======================+
skipping to change at page 12, line 16 skipping to change at page 12, line 16
* Cipher Block Chaining (CBC) mode, if the same key is used for both * Cipher Block Chaining (CBC) mode, if the same key is used for both
encryption and authentication operations, an attacker can produce encryption and authentication operations, an attacker can produce
messages with a valid authentication code. messages with a valid authentication code.
* If the IV can be modified, then messages can be forged. This is * 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.
4. Content Encryption Algorithms 4. Content Encryption Algorithms
Section 9.3 of [I-D.ietf-cose-rfc8152bis-struct] Appendix Section 9.3 of [I-D.ietf-cose-rfc8152bis-struct] contains a
[I-D.ietf-cose-rfc8152bis-struct] contains a generic description of generic description of Content Encryption algorithms. This document
Content Encryption algorithms. This document defines the identifier defines the identifier and usages for three content encryption
and usages for three content encryption algorithms. algorithms.
4.1. AES GCM 4.1. AES GCM
The Galois/Counter Mode (GCM) mode is a generic authenticated The Galois/Counter Mode (GCM) mode is a generic authenticated
encryption block cipher mode defined in [AES-GCM]. The GCM mode is encryption block cipher mode defined in [AES-GCM]. The GCM mode is
combined with the AES block encryption algorithm to define an AEAD combined with the AES block encryption algorithm to define an AEAD
cipher. cipher.
The GCM mode is parameterized by the size of the authentication tag The GCM mode is parameterized by the size of the authentication tag
and the size of the nonce. This document fixes the size of the nonce and the size of the nonce. This document fixes the size of the nonce
skipping to change at page 14, line 22 skipping to change at page 14, line 22
L and M. Constrained devices are usually operating in situations L and M. Constrained devices are usually operating in situations
where they use short messages and want to avoid doing recipient- where they use short messages and want to avoid doing recipient-
specific cryptographic operations. This favors smaller values of specific cryptographic operations. This favors smaller values of
both L and M. Less-constrained devices will want to be able to use both L and M. Less-constrained devices will want to be able to use
larger messages and are more willing to generate new keys for every larger messages and are more willing to generate new keys for every
operation. This favors larger values of L and M. operation. This favors larger values of L and M.
The following values are used for L: The following values are used for L:
16 bits (2): This limits messages to 2^16 bytes (64 KiB) in length. 16 bits (2): This limits messages to 2^16 bytes (64 KiB) in length.
This is sufficiently long for messages in the This is sufficiently long for messages in the constrained world.
constrained world. The nonce length is 13 bytes The nonce length is 13 bytes allowing for 2^104 possible values of
allowing for 2^104 possible values of the nonce without the nonce without repeating.
repeating.
64 bits (8): This limits messages to 2^64 bytes in length. The 64 bits (8): This limits messages to 2^64 bytes in length. The
nonce length is 7 bytes allowing for 2^56 possible nonce length is 7 bytes allowing for 2^56 possible values of the
values of the nonce without repeating. nonce without repeating.
The following values are used for M: The following values are used for M:
64 bits (8): This produces a 64-bit authentication tag. This 64 bits (8): This produces a 64-bit authentication tag. This
implies that there is a 1 in 2^64 chance that a implies that there is a 1 in 2^64 chance that a modified message
modified message will authenticate. will authenticate.
128 bits (16): This produces a 128-bit authentication tag. This 128 bits (16): This produces a 128-bit authentication tag. This
implies that there is a 1 in 2^128 chance that a implies that there is a 1 in 2^128 chance that a modified message
modified message will authenticate. will authenticate.
+--------------------+-------+----+-----+-----+---------------------+ +--------------------+-------+----+-----+-----+---------------------+
| Name | Value | L | M | k | Description | | Name | Value | L | M | k | Description |
+====================+=======+====+=====+=====+=====================+ +====================+=======+====+=====+=====+=====================+
| AES-CCM-16-64-128 | 10 | 16 | 64 | 128 | AES-CCM mode | | AES-CCM-16-64-128 | 10 | 16 | 64 | 128 | AES-CCM mode |
| | | | | | 128-bit key, | | | | | | | 128-bit key, |
| | | | | | 64-bit tag, | | | | | | | 64-bit tag, |
| | | | | | 13-byte nonce | | | | | | | 13-byte nonce |
+--------------------+-------+----+-----+-----+---------------------+ +--------------------+-------+----+-----+-----+---------------------+
| AES-CCM-16-64-256 | 11 | 16 | 64 | 256 | AES-CCM mode | | AES-CCM-16-64-256 | 11 | 16 | 64 | 256 | AES-CCM mode |
skipping to change at page 17, line 41 skipping to change at page 17, line 41
algorithm being used. algorithm being used.
* If the 'key_ops' field is present, it MUST include 'encrypt' or * If the 'key_ops' field is present, it MUST include 'encrypt' or
'wrap key' when encrypting. 'wrap key' when encrypting.
* If the 'key_ops' field is present, it MUST include 'decrypt' or * If the 'key_ops' field is present, it MUST include 'decrypt' or
'unwrap key' when decrypting. 'unwrap key' when decrypting.
4.3.1. Security Considerations 4.3.1. Security Considerations
The key and nounce values MUST be a unique pair for every invocation The key and nonce values MUST be a unique pair for every invocation
of the algorithm. Nonce counters are considered to be an acceptable of the algorithm. Nonce counters are considered to be an acceptable
way of ensuring that they are unique. way of ensuring that they are unique.
5. Key Derivation Functions (KDFs) 5. Key Derivation Functions (KDFs)
Section 9.4 of [I-D.ietf-cose-rfc8152bis-struct] Appendix Section 9.4 of [I-D.ietf-cose-rfc8152bis-struct] contains a
[I-D.ietf-cose-rfc8152bis-struct] contains a generic description of generic description of Key Derivation Functions. This document
Key Derivation Functions. This document defines a single context defines a single context structure and a single KDF. These elements
structure and a single KDF. These elements are used for all of the are used for all of the recipient algorithms defined in this document
recipient algorithms defined in this document that require a KDF that require a KDF process. These algorithms are defined in Sections
process. These algorithms are defined in Sections 6.1.2, 6.3, and 6.1.2, 6.3, and 6.4.
6.4.
5.1. HMAC-Based Extract-and-Expand Key Derivation Function (HKDF) 5.1. HMAC-Based Extract-and-Expand Key Derivation Function (HKDF)
The HKDF key derivation algorithm is defined in [RFC5869]. The HKDF key derivation algorithm is defined in [RFC5869].
The HKDF algorithm takes these inputs: The HKDF algorithm takes these inputs:
secret -- a shared value that is secret. Secrets may be either secret -- a shared value that is secret. Secrets may be either
previously shared or derived from operations like a Diffie-Hellman previously shared or derived from operations like a Diffie-Hellman
(DH) key agreement. (DH) key agreement.
salt -- an optional value that is used to change the generation salt -- an optional value that is used to change the generation
process. The salt value can be either public or private. If the process. The salt value can be either public or private. If the
salt is public and carried in the message, then the 'salt' salt is public and carried in the message, then the 'salt'
algorithm header parameter defined in Table 9 is used. While algorithm header parameter defined in Table 9 is used. While
[RFC5869] suggests that the length of the salt be the same as the [RFC5869] suggests that the length of the salt be the same as the
length of the underlying hash value, any amount of salt will length of the underlying hash value, any positive salt length will
improve the security as different key values will be generated. improve the security as different key values will be generated.
This parameter is protected by being included in the key This parameter is protected by being included in the key
computation and does not need to be separately authenticated. The computation and does not need to be separately authenticated. The
salt value does not need to be unique for every message sent. salt value does not need to be unique for every message sent.
length -- the number of bytes of output that need to be generated. length -- the number of bytes of output that need to be generated.
context information -- Information that describes the context in context information -- Information that describes the context in
which the resulting value will be used. Making this information which the resulting value will be used. Making this information
specific to the context in which the material is going to be used specific to the context in which the material is going to be used
skipping to change at page 22, line 48 skipping to change at page 22, line 36
| | | | ECDH-SS+A192KW, | | | | | | ECDH-SS+A192KW, | |
| | | | ECDH-SS+A256KW | | | | | | ECDH-SS+A256KW | |
+----------+-------+------+---------------------------+-------------+ +----------+-------+------+---------------------------+-------------+
Table 10: Context Algorithm Parameters Table 10: 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 material will be used. This normally is either a key wrap
wrap algorithm identifier or a content encryption algorithm identifier or a content encryption algorithm identifier.
algorithm identifier. The values are from the "COSE The values are from the "COSE Algorithms" registry. This field is
Algorithms" registry. This field is required to be required to be present. The field exists in the context
present. The field exists in the context information information so that a different key is generated for each
so that if the same environment is used for different algorithm even of all of the other context information is the
algorithms, then completely different keys will be same. In practice, this means if algorithm A is broken and thus
generated for each of those algorithms. This practice finding the key is relatively easy, the key derived for algorithm
means if algorithm A is broken and thus is easier to B will not be the same as the key derived for algorithm A.
find, the key derived for algorithm B will not be the
same as the key derived for algorithm A.
PartyUInfo: This field holds information about party U. The PartyUInfo: This field holds information about party U. The
PartyUInfo is encoded as a CBOR array. The elements PartyUInfo is encoded as a CBOR array. The elements of PartyUInfo
of PartyUInfo are encoded in the order presented. The are encoded in the order presented below. The elements of the
elements of the PartyUInfo array are: PartyUInfo array are:
identity: This contains the identity information for identity: This contains the identity information for party U.
party U. The identities can be assigned in The identities can be assigned in one of two manners. First, a
one of two manners. First, a protocol can protocol can assign identities based on roles. For example,
assign identities based on roles. For the roles of "client" and "server" may be assigned to different
example, the roles of "client" and "server" entities in the protocol. Each entity would then use the
may be assigned to different entities in correct label for the data they send or receive. The second
the protocol. Each entity would then use way for a protocol to assign identities is to use a name based
the correct label for the data they send or on a naming system (i.e., DNS, X.509 names).
receive. The second way for a protocol to
assign identities is to use a name based on
a naming system (i.e., DNS, X.509 names).
We define an algorithm parameter 'PartyU We define an algorithm parameter 'PartyU identity' that can be
identity' that can be used to carry used to carry identity information in the message. However,
identity information in the message. identity information is often known as part of the protocol and
However, identity information is often can thus be inferred rather than made explicit. If identity
known as part of the protocol and can thus information is carried in the message, applications SHOULD have
be inferred rather than made explicit. If a way of validating the supplied identity information. The
identity information is carried in the identity information does not need to be specified and is set
message, applications SHOULD have a way of to nil in that case.
validating the supplied identity
information. The identity information does
not need to be specified and is set to nil
in that case.
nonce: This contains a nonce value. The nonce can nonce: This contains a nonce value. The nonce can either be
either be implicit from the protocol or be implicit from the protocol or be carried as a value in the
carried as a value in the unprotected unprotected headers.
headers.
We define an algorithm parameter 'PartyU We define an algorithm parameter 'PartyU nonce' that can be
nonce' that can be used to carry this value used to carry this value in the message; however, the nonce
in the message; however, the nonce value value could be determined by the application and the value
could be determined by the application and determined from elsewhere.
the value determined from elsewhere.
This option does not need to be specified This option does not need to be specified and is set to nil in
and is set to nil in that case. that case.
other: This contains other information that is other: This contains other information that is defined by the
defined by the protocol. This option does protocol. This option does not need to be specified and is set
not need to be specified and is set to nil to nil in that case.
in that case.
PartyVInfo: This field holds information about party V. The PartyVInfo: This field holds information about party V. The content
content of the structure is the same as for the of the structure is the same as for the PartyUInfo but for party
PartyUInfo but for party V. V.
SuppPubInfo: This field contains public information that is SuppPubInfo: This field contains public information that is mutually
mutually known to both parties. known to both parties.
keyDataLength: This is set to the number of bits of keyDataLength: This is set to the number of bits of the desired
the desired output value. This output value. This practice means if algorithm A can use two
practice means if algorithm A can use different key lengths, the key derived for longer key size will
two different key lengths, the key not contain the key for shorter key size as a prefix.
derived for longer key size will not
contain the key for shorter key size
as a prefix.
protected: This field contains the protected protected: This field contains the protected parameter field. If
parameter field. If there are no there are no elements in the protected field, then use a zero-
elements in the protected field, then length bstr.
use a zero-length bstr.
other: This field is for free form data other: This field is for free form data defined by the
defined by the application. An application. An example is that an application could define
example is that an application could two different strings to be placed here to generate different
define two different strings to be keys for a data stream versus a control stream. This field is
placed here to generate different keys optional and will only be present if the application defines a
for a data stream versus a control structure for this information. Applications that define this
stream. This field is optional and SHOULD use CBOR to encode the data so that types and lengths
will only be present if the are correctly included.
application defines a structure for
this information. Applications that
define this SHOULD use CBOR to encode
the data so that types and lengths are
correctly included.
SuppPrivInfo: This field contains private information that is SuppPrivInfo: This field contains private information that is
mutually known private information. An example of mutually known private information. An example of this
this information would be a preexisting shared secret. information would be a preexisting shared secret. (This could,
(This could, for example, be used in combination with for example, be used in combination with an ECDH key agreement to
an ECDH key agreement to provide a secondary proof of provide a secondary proof of identity.) The field is optional and
identity.) The field is optional and will only be will only be present if the application defines a structure for
present if the application defines a structure for this information. Applications that define this SHOULD use CBOR
this information. Applications that define this to encode the data so that types and lengths are correctly
SHOULD use CBOR to encode the data so that types and included.
lengths are correctly included.
The following CDDL fragment corresponds to the text above. The following CDDL fragment corresponds to the text above.
PartyInfo = ( PartyInfo = (
identity : bstr / nil, identity : bstr / nil,
nonce : bstr / int / nil, nonce : bstr / int / nil,
other : bstr / nil other : bstr / nil
) )
COSE_KDF_Context = [ COSE_KDF_Context = [
skipping to change at page 25, line 33 skipping to change at page 24, line 47
SuppPubInfo : [ SuppPubInfo : [
keyDataLength : uint, keyDataLength : uint,
protected : empty_or_serialized_map, protected : empty_or_serialized_map,
? other : bstr ? other : bstr
], ],
? SuppPrivInfo : bstr ? SuppPrivInfo : bstr
] ]
6. Content Key Distribution Methods 6. Content Key Distribution Methods
Section 9.5 of [I-D.ietf-cose-rfc8152bis-struct] Appendix Section 9.5 of [I-D.ietf-cose-rfc8152bis-struct] contains a
[I-D.ietf-cose-rfc8152bis-struct] contains a generic description of generic description of content key distribution methods. This
content key distribution methods. This document defines the document defines the identifiers and usage for a number of content
identifiers and usage for a number of content key distribution key distribution methods.
methods.
6.1. Direct Encryption 6.1. Direct Encryption
Direct encryption algorithm is defined in Section 9.5.1 of Direct encryption algorithm is defined in Appendix Section 9.5.1 of
[I-D.ietf-cose-rfc8152bis-struct] [I-D.ietf-cose-rfc8152bis-struct]. [I-D.ietf-cose-rfc8152bis-struct]. Information about how to fill in
Information about how to fill in the COSE_Recipient structure are the COSE_Recipient structure are detailed there.
detailed there.
6.1.1. Direct Key 6.1.1. Direct Key
This recipient algorithm is the simplest; the identified key is This recipient algorithm is the simplest; the identified key is
directly used as the key for the next layer down in the message. directly used as the key for the next layer down in the message.
There are no algorithm parameters defined for this algorithm. The There are no algorithm parameters defined for this algorithm. The
algorithm identifier value is assigned in Table 11. algorithm identifier value is assigned in Table 11.
When this algorithm is used, the protected field MUST be zero length. When this algorithm is used, the protected field MUST be zero length.
The key type MUST be 'Symmetric'. The key type MUST be 'Symmetric'.
skipping to change at page 30, line 35 skipping to change at page 30, line 20
and one-time material for static-static key agreement. All of the and one-time material for static-static key agreement. All of the
algorithms defined in this document use one of the HKDF algorithms algorithms defined in this document use one of the HKDF algorithms
defined in Section 5.1 with the context structure defined in defined in Section 5.1 with the context structure defined in
Section 5.2. Section 5.2.
* Key Wrap Algorithm: No key wrap algorithm is used. This is * Key Wrap Algorithm: No key wrap algorithm is used. This is
represented in Table 14 as 'none'. The key size for the context represented in Table 14 as 'none'. The key size for the context
structure is the content layer encryption algorithm size. structure is the content layer encryption algorithm size.
COSE does not have an Ephemeral-Ephemeral version defined. The COSE does not have an Ephemeral-Ephemeral version defined. The
reason for this is that COSE is not an an online protocol by itself reason for this is that COSE is not an online protocol by itself and
and thus does not have a method to establish ephemeral secrets on thus does not have a method to establish ephemeral secrets on both
both sides. The expectation is that a protocol would establish the sides. The expectation is that a protocol would establish the
secrets for both sides, and then they would be used as static-static secrets for both sides, and then they would be used as static-static
for the purposes of COSE, or that the protocol would generate a for the purposes of COSE, or that the protocol would generate a
shared secret and a direct encryption would be used. shared secret and a direct encryption would be used.
The set of direct ECDH algorithms defined in this document are found The set of direct ECDH algorithms defined in this document are found
in Table 14. in Table 14.
+-----------+-------+---------+------------+------+-----------------+ +-----------+-------+---------+------------+------+-----------------+
| Name | Value | KDF | Ephemeral- | Key | Description | | Name | Value | KDF | Ephemeral- | Key | Description |
| | | | Static | Wrap | | | | | | Static | Wrap | |
skipping to change at page 41, line 21 skipping to change at page 40, line 50
800-38D.pdf>. 800-38D.pdf>.
[DSS] National Institute of Standards and Technology, "Digital [DSS] National Institute of Standards and Technology, "Digital
Signature Standard (DSS)", DOI 10.6028/NIST.FIPS.186-4, Signature Standard (DSS)", DOI 10.6028/NIST.FIPS.186-4,
FIPS PUB 186-4, July 2013, FIPS PUB 186-4, July 2013,
<http://nvlpubs.nist.gov/nistpubs/FIPS/ <http://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.186-4.pdf>. NIST.FIPS.186-4.pdf>.
[I-D.ietf-cose-rfc8152bis-struct] [I-D.ietf-cose-rfc8152bis-struct]
Schaad, J., "CBOR Object Signing and Encryption (COSE): Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", draft-ietf-cose-rfc8152bis- Structures and Process", Internet Draft, draft-ietf-cose-
struct-05 (work in progress), August 18, 2019, rfc8152bis-struct-05, August 18, 2019,
<https://www.ietf.org/archive/id/draft-ietf-cose- <https://www.ietf.org/archive/id/draft-ietf-cose-
rfc8152bis-struct-05>. rfc8152bis-struct-05>.
[MAC] National Institute of Standards and Technology, "Computer [MAC] National Institute of Standards and Technology, "Computer
Data Authentication", FIPS PUB 113, May 1985, Data Authentication", FIPS PUB 113, May 1985,
<http://csrc.nist.gov/publications/fips/fips113/ <http://csrc.nist.gov/publications/fips/fips113/
fips113.html>. fips113.html>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
 End of changes. 41 change blocks. 
154 lines changed or deleted 126 lines changed or added

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