draft-ietf-cose-rfc8152bis-algs-08.txt   draft-ietf-cose-rfc8152bis-algs-09.txt 
COSE Working Group J. Schaad COSE Working Group J. Schaad
Internet-Draft August Cellars Internet-Draft August Cellars
Obsoletes: 8152 (if approved) 14 May 2020 Obsoletes: 8152 (if approved) 2 June 2020
Intended status: Standards Track Intended status: Standards Track
Expires: 15 November 2020 Expires: 4 December 2020
CBOR Object Signing and Encryption (COSE): Initial Algorithms CBOR Object Signing and Encryption (COSE): Initial Algorithms
draft-ietf-cose-rfc8152bis-algs-08 draft-ietf-cose-rfc8152bis-algs-09
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 15 November 2020. This Internet-Draft will expire on 4 December 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 3, line 30 skipping to change at page 3, line 30
7.3. Symmetric Keys . . . . . . . . . . . . . . . . . . . . . 39 7.3. Symmetric Keys . . . . . . . . . . . . . . . . . . . . . 39
8. COSE Capabilities . . . . . . . . . . . . . . . . . . . . . . 40 8. COSE Capabilities . . . . . . . . . . . . . . . . . . . . . . 40
8.1. Assignments for Existing Key Types . . . . . . . . . . . 40 8.1. Assignments for Existing Key Types . . . . . . . . . . . 40
8.2. Assignments for Existing Algorithms . . . . . . . . . . . 41 8.2. Assignments for Existing Algorithms . . . . . . . . . . . 41
8.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 41 8.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 41
9. CBOR Encoding Restrictions . . . . . . . . . . . . . . . . . 42 9. CBOR Encoding Restrictions . . . . . . . . . . . . . . . . . 42
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
10.1. Changes to "COSE Key Types" registry. . . . . . . . . . 42 10.1. Changes to "COSE Key Types" registry. . . . . . . . . . 42
10.2. Changes to "COSE Algorithms" registry . . . . . . . . . 43 10.2. Changes to "COSE Algorithms" registry . . . . . . . . . 43
10.3. Changes to the "COSE Key Type Parameters" registry . . . 43 10.3. Changes to the "COSE Key Type Parameters" registry . . . 43
11. Security Considerations . . . . . . . . . . . . . . . . . . . 43 11. Security Considerations . . . . . . . . . . . . . . . . . . . 44
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 46
12.1. Normative References . . . . . . . . . . . . . . . . . . 45 12.1. Normative References . . . . . . . . . . . . . . . . . . 46
12.2. Informative References . . . . . . . . . . . . . . . . . 47 12.2. Informative References . . . . . . . . . . . . . . . . . 48
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 49 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 50
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 49 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 50
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
skipping to change at page 5, line 5 skipping to change at page 4, line 49
plain text contents as part of the encryption service. plain text contents as part of the encryption service.
Authenticated Encryption with Associated Data (AEAD) [RFC5116] Authenticated Encryption with Associated Data (AEAD) [RFC5116]
algorithms provide the same content authentication service as AE algorithms provide the same content authentication service as AE
algorithms, but they additionally provide for authentication of non- algorithms, but they additionally provide for authentication of non-
encrypted data as well. encrypted data as well.
The term 'byte string' is used for sequences of bytes, while the term The term 'byte string' is used for sequences of bytes, while the term
'text string' is used for sequences of characters. 'text string' is used for sequences of characters.
The tables for algorithms contain the following columns:
* A name for use in documents for the algorithms.
* The value used on the wire for the algorithm. One place this is
used is the algorithm header parameter of a message.
* A short description so that the algorithm can be easily identified
when scanning the IANA registry.
Additional columns may be present in the table depending on the
algorithms.
1.4. CBOR Grammar 1.4. CBOR Grammar
At the time that [RFC8152] was initially published, the CBOR Data At the time that [RFC8152] was initially published, the CBOR Data
Definition Language (CDDL) [RFC8610] had not yet been published. Definition Language (CDDL) [RFC8610] had not yet been published.
This document uses a variant of CDDL which is described in This document uses a variant of CDDL which is described in
[I-D.ietf-cose-rfc8152bis-struct] [I-D.ietf-cose-rfc8152bis-struct]
1.5. Examples 1.5. Examples
A GitHub project has been created at <https://github.com/cose-wg/ A GitHub project has been created at <https://github.com/cose-wg/
Examples> that contains a set of testing examples as well. Each Examples> that contains a set of testing examples as well. Each
example is found in a JSON file that contains the inputs used to example is found in a JSON file that contains the inputs used to
create the example, some of the intermediate values that can be used create the example, some of the intermediate values that can be used
in debugging the example and the output of the example presented in for debugging, and the output of the example. The results are
both a hex and a CBOR diagnostic notation format. Some of the encoded using both hexadecimal and CBOR diagnostic notation format.
examples at the site are designed failure testing cases; these are
Some of the examples are designed to test failure case; 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
Part Section 9.1 of [I-D.ietf-cose-rfc8152bis-struct] contains a Part Section 9.1 of [I-D.ietf-cose-rfc8152bis-struct] contains a
generic description of signature algorithms. The document defines generic description of signature algorithms. The document defines
signature algorithm identifiers for two signature algorithms. signature algorithm identifiers for two signature algorithms.
skipping to change at page 10, line 23 skipping to change at page 10, line 23
+-------------+-------+---------+------------+----------------------+ +-------------+-------+---------+------------+----------------------+
| HMAC | 6 | SHA-384 | 384 | HMAC w/ SHA-384 | | HMAC | 6 | SHA-384 | 384 | HMAC w/ SHA-384 |
| 384/384 | | | | | | 384/384 | | | | |
+-------------+-------+---------+------------+----------------------+ +-------------+-------+---------+------------+----------------------+
| HMAC | 7 | SHA-512 | 512 | HMAC w/ SHA-512 | | HMAC | 7 | SHA-512 | 512 | HMAC w/ SHA-512 |
| 512/512 | | | | | | 512/512 | | | | |
+-------------+-------+---------+------------+----------------------+ +-------------+-------+---------+------------+----------------------+
Table 3: HMAC Algorithm Values Table 3: HMAC Algorithm Values
Some recipient algorithms carry the key while others derive a key Some recipient algorithms transport the key, while others derive a
from secret data. For those algorithms that carry the key (such as key from secret data. For those algorithms that transport the key
AES Key Wrap), the size of the HMAC key SHOULD be the same size as (such as AES Key Wrap), the size of the HMAC key SHOULD be the same
the underlying hash function. For those algorithms that derive the size as the underlying hash function. For those algorithms that
key (such as ECDH), the derived key MUST be the same size as the derive the key (such as ECDH), the derived key MUST be the same size
underlying hash function. as the underlying hash function.
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:
* The 'kty' field MUST be present, and it MUST be 'Symmetric'. * The 'kty' field MUST be present, and it MUST be 'Symmetric'.
* If the 'alg' field is present, it MUST match the HMAC algorithm * If the 'alg' field is present, it MUST match the HMAC algorithm
being used. being used.
* If the 'key_ops' field is present, it MUST include 'MAC create' * If the 'key_ops' field is present, it MUST include 'MAC create'
skipping to change at page 16, line 5 skipping to change at page 16, line 5
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 modified message implies that there is a 1 in 2^64 chance that a 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 modified message implies that there is a 1 in 2^128 chance that a modified message
will authenticate. will authenticate.
+--------------------+-------+----+-----+-----+---------------------+ +--------------------+-------+----+-----+--------+---------------+
| Name | Value | L | M | k | Description | | Name | Value | L | M | Key | Description |
+====================+=======+====+=====+=====+=====================+ | | | | | Length | |
| AES-CCM-16-64-128 | 10 | 16 | 64 | 128 | AES-CCM mode | +====================+=======+====+=====+========+===============+
| | | | | | 128-bit key, | | AES-CCM-16-64-128 | 10 | 16 | 64 | 128 | AES-CCM mode |
| | | | | | 64-bit tag, | | | | | | | 128-bit key, |
| | | | | | 13-byte nonce | | | | | | | 64-bit tag, |
+--------------------+-------+----+-----+-----+---------------------+ | | | | | | 13-byte nonce |
| AES-CCM-16-64-256 | 11 | 16 | 64 | 256 | AES-CCM mode | +--------------------+-------+----+-----+--------+---------------+
| | | | | | 256-bit key, | | AES-CCM-16-64-256 | 11 | 16 | 64 | 256 | AES-CCM mode |
| | | | | | 64-bit tag, | | | | | | | 256-bit key, |
| | | | | | 13-byte nonce | | | | | | | 64-bit tag, |
+--------------------+-------+----+-----+-----+---------------------+ | | | | | | 13-byte nonce |
| AES-CCM-64-64-128 | 12 | 64 | 64 | 128 | AES-CCM mode | +--------------------+-------+----+-----+--------+---------------+
| | | | | | 128-bit key, | | AES-CCM-64-64-128 | 12 | 64 | 64 | 128 | AES-CCM mode |
| | | | | | 64-bit tag, | | | | | | | 128-bit key, |
| | | | | | 7-byte nonce | | | | | | | 64-bit tag, |
+--------------------+-------+----+-----+-----+---------------------+ | | | | | | 7-byte nonce |
| AES-CCM-64-64-256 | 13 | 64 | 64 | 256 | AES-CCM mode | +--------------------+-------+----+-----+--------+---------------+
| | | | | | 256-bit key, | | AES-CCM-64-64-256 | 13 | 64 | 64 | 256 | AES-CCM mode |
| | | | | | 64-bit tag, | | | | | | | 256-bit key, |
| | | | | | 7-byte nonce | | | | | | | 64-bit tag, |
+--------------------+-------+----+-----+-----+---------------------+ | | | | | | 7-byte nonce |
| AES-CCM-16-128-128 | 30 | 16 | 128 | 128 | AES-CCM mode | +--------------------+-------+----+-----+--------+---------------+
| | | | | | 128-bit key, | | AES-CCM-16-128-128 | 30 | 16 | 128 | 128 | AES-CCM mode |
| | | | | | 128-bit tag, | | | | | | | 128-bit key, |
| | | | | | 13-byte nonce | | | | | | | 128-bit tag, |
+--------------------+-------+----+-----+-----+---------------------+ | | | | | | 13-byte nonce |
| AES-CCM-16-128-256 | 31 | 16 | 128 | 256 | AES-CCM mode | +--------------------+-------+----+-----+--------+---------------+
| | | | | | 256-bit key, | | AES-CCM-16-128-256 | 31 | 16 | 128 | 256 | AES-CCM mode |
| | | | | | 128-bit tag, | | | | | | | 256-bit key, |
| | | | | | 13-byte nonce | | | | | | | 128-bit tag, |
+--------------------+-------+----+-----+-----+---------------------+ | | | | | | 13-byte nonce |
| AES-CCM-64-128-128 | 32 | 64 | 128 | 128 | AES-CCM mode | +--------------------+-------+----+-----+--------+---------------+
| | | | | | 128-bit key, | | AES-CCM-64-128-128 | 32 | 64 | 128 | 128 | AES-CCM mode |
| | | | | | 128-bit tag, | | | | | | | 128-bit key, |
| | | | | | 7-byte nonce | | | | | | | 128-bit tag, |
+--------------------+-------+----+-----+-----+---------------------+ | | | | | | 7-byte nonce |
| AES-CCM-64-128-256 | 33 | 64 | 128 | 256 | AES-CCM mode | +--------------------+-------+----+-----+--------+---------------+
| | | | | | 256-bit key, | | AES-CCM-64-128-256 | 33 | 64 | 128 | 256 | AES-CCM mode |
| | | | | | 128-bit tag, | | | | | | | 256-bit key, |
| | | | | | 7-byte nonce | | | | | | | 128-bit tag, |
+--------------------+-------+----+-----+-----+---------------------+ | | | | | | 7-byte nonce |
+--------------------+-------+----+-----+--------+---------------+
Table 6: Algorithm Values for AES-CCM Table 6: Algorithm Values for AES-CCM
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:
* The 'kty' field MUST be present, and it MUST be 'Symmetric'. * The 'kty' field MUST be present, and it MUST be 'Symmetric'.
skipping to change at page 43, line 35 skipping to change at page 43, line 35
+==========+===============+=============+============+=============+ +==========+===============+=============+============+=============+
| IV | IV-GENERATION |Reserved for | [[THIS | No | | IV | IV-GENERATION |Reserved for | [[THIS | No |
|Generation| | doing IV | DOCUMENT]] | | |Generation| | doing IV | DOCUMENT]] | |
| | | generation | | | | | | generation | | |
| | |for symmetric| | | | | |for symmetric| | |
| | | algorithms. | | | | | | algorithms. | | |
+----------+---------------+-------------+------------+-------------+ +----------+---------------+-------------+------------+-------------+
Table 23 Table 23
The capabilities column for this registration is to be empty.
10.3. Changes to the "COSE Key Type Parameters" registry 10.3. Changes to the "COSE Key Type Parameters" registry
IANA is requested to modify the description to "Public Key" for the IANA is requested to modify the description to "Public Key" for the
line with "Key Type" of 2 and the "Name" of "x". See Table 20 which line with "Key Type" of 2 and the "Name" of "x". See Table 20 which
has been modified with this change. has been modified with this change.
IANA is requested to update the references in the table from RFC8152
to [[This Document]].
11. Security Considerations 11. 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 material for any Implementations need to protect the private key material for any
skipping to change at page 45, line 42 skipping to change at page 46, line 18
in order to prevent or discourage such analysis. (For example, the in order to prevent or discourage such analysis. (For example, the
text strings could be defined as 'YES' and 'NO '.) text strings could be defined as 'YES' and 'NO '.)
12. References 12. References
12.1. Normative References 12.1. Normative References
[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", Work in Progress, Internet-Draft, Structures and Process", Work in Progress, Internet-Draft,
draft-ietf-cose-rfc8152bis-struct-08, 9 March 2020, draft-ietf-cose-rfc8152bis-struct-09, 14 May 2020,
<https://tools.ietf.org/html/draft-ietf-cose-rfc8152bis- <https://tools.ietf.org/html/draft-ietf-cose-rfc8152bis-
struct-08>. struct-09>.
[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,
DOI 10.17487/RFC2104, February 1997, DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>. <https://www.rfc-editor.org/info/rfc2104>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
 End of changes. 14 change blocks. 
65 lines changed or deleted 85 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/