draft-ietf-cose-rfc8152bis-algs-06.txt   draft-ietf-cose-rfc8152bis-algs-07.txt 
COSE Working Group J. Schaad COSE Working Group J. Schaad
Internet-Draft August Cellars Internet-Draft August Cellars
Obsoletes: 8152 (if approved) 4 November 2019 Obsoletes: 8152 (if approved) 9 March 2020
Intended status: Standards Track Intended status: Standards Track
Expires: 7 May 2020 Expires: 10 September 2020
CBOR Object Signing and Encryption (COSE): Initial Algorithms CBOR Object Signing and Encryption (COSE): Initial Algorithms
draft-ietf-cose-rfc8152bis-algs-06 draft-ietf-cose-rfc8152bis-algs-07
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 7 May 2020. This Internet-Draft will expire on 10 September 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 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
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
skipping to change at page 2, line 37 skipping to change at page 2, line 37
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Terminology . . . . . . . . . . . . . . . . 4 1.1. Requirements Terminology . . . . . . . . . . . . . . . . 4
1.2. Changes from RFC8152 . . . . . . . . . . . . . . . . . . 4 1.2. Changes from RFC8152 . . . . . . . . . . . . . . . . . . 4
1.3. Document Terminology . . . . . . . . . . . . . . . . . . 4 1.3. Document Terminology . . . . . . . . . . . . . . . . . . 4
1.4. CBOR Grammar . . . . . . . . . . . . . . . . . . . . . . 4 1.4. CBOR Grammar . . . . . . . . . . . . . . . . . . . . . . 4
1.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . 5 1.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Signature Algorithms . . . . . . . . . . . . . . . . . . . . 5 2. Signature Algorithms . . . . . . . . . . . . . . . . . . . . 5
2.1. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1. Security Considerations . . . . . . . . . . . . . . . 7 2.1.1. Security Considerations . . . . . . . . . . . . . . . 7
2.2. Edwards-Curve Digital Signature Algorithms 2.2. Edwards-Curve Digital Signature Algorithms (EdDSAs) . . . 8
(EdDSAs) . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1. Security Considerations . . . . . . . . . . . . . . . 9 2.2.1. Security Considerations . . . . . . . . . . . . . . . 9
3. Message Authentication Code (MAC) Algorithms . . . . . . . . 9 3. Message Authentication Code (MAC) Algorithms . . . . . . . . 9
3.1. Hash-Based Message Authentication Codes (HMACs) . . . . . 9 3.1. Hash-Based Message Authentication Codes (HMACs) . . . . . 9
3.1.1. Security Considerations . . . . . . . . . . . . . . . 11 3.1.1. Security Considerations . . . . . . . . . . . . . . . 11
3.2. AES Message Authentication Code (AES-CBC-MAC) . . . . . . 11 3.2. AES Message Authentication Code (AES-CBC-MAC) . . . . . . 11
3.2.1. Security Considerations . . . . . . . . . . . . . . . 12 3.2.1. Security Considerations . . . . . . . . . . . . . . . 12
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 . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.2. AES CCM . . . . . . . . . . . . . . . . . . . . . . . . . 14
skipping to change at page 3, line 24 skipping to change at page 3, line 23
6.3.1. Security Considerations . . . . . . . . . . . . . . . 33 6.3.1. Security Considerations . . . . . . . . . . . . . . . 33
6.4. ECDH with Key Wrap . . . . . . . . . . . . . . . . . . . 33 6.4. ECDH with Key Wrap . . . . . . . . . . . . . . . . . . . 33
7. Key Object Parameters . . . . . . . . . . . . . . . . . . . . 35 7. Key Object Parameters . . . . . . . . . . . . . . . . . . . . 35
7.1. Elliptic Curve Keys . . . . . . . . . . . . . . . . . . . 35 7.1. Elliptic Curve Keys . . . . . . . . . . . . . . . . . . . 35
7.1.1. Double Coordinate Curves . . . . . . . . . . . . . . 36 7.1.1. Double Coordinate Curves . . . . . . . . . . . . . . 36
7.2. Octet Key Pair . . . . . . . . . . . . . . . . . . . . . 37 7.2. Octet Key Pair . . . . . . . . . . . . . . . . . . . . . 37
7.3. Symmetric Keys . . . . . . . . . . . . . . . . . . . . . 38 7.3. Symmetric Keys . . . . . . . . . . . . . . . . . . . . . 38
8. COSE Capabilities . . . . . . . . . . . . . . . . . . . . . . 39 8. COSE Capabilities . . . . . . . . . . . . . . . . . . . . . . 39
8.1. Assignments for Existing Key Types . . . . . . . . . . . 39 8.1. Assignments for Existing Key Types . . . . . . . . . . . 39
8.2. Assignments for Existing Algorithms . . . . . . . . . . . 40 8.2. Assignments for Existing Algorithms . . . . . . . . . . . 40
9. CBOR Encoding Restrictions . . . . . . . . . . . . . . . . . 40 8.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 40
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 9. CBOR Encoding Restrictions . . . . . . . . . . . . . . . . . 41
10.1. Changes to "COSE Key Types" registry. . . . . . . . . . 40 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
10.2. Changes to "COSE Algorithms" registry . . . . . . . . . 41 10.1. Changes to "COSE Key Types" registry. . . . . . . . . . 41
11. Security Considerations . . . . . . . . . . . . . . . . . . . 41 10.2. Changes to "COSE Algorithms" registry . . . . . . . . . 42
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 10.3. Changes to the "COSE Key Type Parameters" registry . . . 42
12.1. Normative References . . . . . . . . . . . . . . . . . . 43 11. Security Considerations . . . . . . . . . . . . . . . . . . . 42
12.2. Informative References . . . . . . . . . . . . . . . . . 45 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 47 12.1. Normative References . . . . . . . . . . . . . . . . . . 44
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 47 12.2. Informative References . . . . . . . . . . . . . . . . . 46
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 48
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 48
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 4, line 22 skipping to change at page 4, line 23
"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
* Extract the sections dealing with specific algorithms into this * Extract the sections dealing with specific algorithms into this
document. The sections dealing with structure and general document. The sections dealing with structure and general
processing rules are placed in [I-D.ietf-cose-rfc8152bis-struct]. processing rules are placed in [I-D.ietf-cose-rfc8152bis-struct].
* Text clarifications and changes in terminology.
1.3. Document Terminology 1.3. Document Terminology
In this document, we use the following terminology: In this document, we use the following terminology:
Byte is a synonym for octet. Byte is a synonym for octet.
Constrained Application Protocol (CoAP) is a specialized web transfer Constrained Application Protocol (CoAP) is a specialized web transfer
protocol for use in constrained systems. It is defined in [RFC7252]. protocol for use in constrained systems. It is defined in [RFC7252].
Authenticated Encryption (AE) [RFC5116] algorithms are those Authenticated Encryption (AE) [RFC5116] algorithms are those
encryption algorithms that provide an authentication check of the encryption algorithms that provide an authentication check of the
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
'text string' is used for sequences of characters.
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/
skipping to change at page 5, line 20 skipping to change at page 5, line 20
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
Appendix 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.
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
skipping to change at page 6, line 32 skipping to change at page 6, line 32
it to work with other curves and points in the future. it to work with other curves and points in the future.
In order to promote interoperability, it is suggested that SHA-256 be In order to promote interoperability, it is suggested that SHA-256 be
used only with curve P-256, SHA-384 be used only with curve P-384, used only with curve P-256, SHA-384 be used only with curve P-384,
and SHA-512 be used with curve P-521. This is aligned with the and SHA-512 be used with curve P-521. This is aligned with the
recommendation in Section 4 of [RFC5480]. recommendation in Section 4 of [RFC5480].
The signature algorithm results in a pair of integers (R, S). These The signature algorithm results in a pair of integers (R, S). These
integers will be the same length as the length of the key used for integers will be the same length as the length of the key used for
the signature process. The signature is encoded by converting the the signature process. The signature is encoded by converting the
integers into bit strings of the same length as the key size. The integers into byte strings of the same length as the key size. The
length is rounded up to the nearest byte and is left padded with zero length is rounded up to the nearest byte and is left padded with zero
bits to get to the correct length. The two integers are then bits to get to the correct length. The two integers are then
concatenated together to form a byte string that is the resulting concatenated together to form a byte string that is the resulting
signature. signature.
Using the function defined in [RFC8017], the signature is: Using the function defined in [RFC8017], the signature is:
Signature = I2OSP(R, n) | I2OSP(S, n) Signature = I2OSP(R, n) | I2OSP(S, n)
where n = ceiling(key_length / 8) where n = ceiling(key_length / 8)
skipping to change at page 7, line 45 skipping to change at page 7, line 45
that can be used. that can be used.
* Change the hash function used to validate the signature: If one * Change the hash function used to validate the signature: If one
either has two different hash functions of the same length or can either has two different hash functions of the same length or can
truncate a hash function down, then one could potentially find truncate a hash function down, then one could potentially find
collisions between the hash functions rather than within a single collisions between the hash functions rather than within a single
hash function (for example, truncating SHA-512 to 256 bits might hash function (for example, truncating SHA-512 to 256 bits might
collide with a SHA-256 bit hash value). As the hash algorithm is collide with a SHA-256 bit hash value). As the hash algorithm is
part of the signature algorithm identifier, this attack is part of the signature algorithm identifier, this attack is
mitigated by including a signature algorithm identifier in the mitigated by including a signature algorithm identifier in the
protected header. protected header bucket.
2.2. Edwards-Curve Digital Signature Algorithms (EdDSAs) 2.2. Edwards-Curve Digital Signature Algorithms (EdDSAs)
[RFC8032] describes the elliptic curve signature scheme Edwards-curve [RFC8032] describes the elliptic curve signature scheme Edwards-curve
Digital Signature Algorithm (EdDSA). In that document, the signature Digital Signature Algorithm (EdDSA). In that document, the signature
algorithm is instantiated using parameters for edwards25519 and algorithm is instantiated using parameters for edwards25519 and
edwards448 curves. The document additionally describes two variants edwards448 curves. The document additionally describes two variants
of the EdDSA algorithm: Pure EdDSA, where no hash function is applied of the EdDSA algorithm: Pure EdDSA, where no hash function is applied
to the content before signing, and HashEdDSA, where a hash function to the content before signing, and HashEdDSA, where a hash function
is applied to the content before signing and the result of that hash is applied to the content before signing and the result of that hash
skipping to change at page 9, line 24 skipping to change at page 9, line 24
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
Appendix Section 9.2 of [I-D.ietf-cose-rfc8152bis-struct] contains a Part Section 9.2 of [I-D.ietf-cose-rfc8152bis-struct] contains a
generic description of MAC algorithms. This section defines the generic description of MAC algorithms. This section defines the
conventions for two MAC algorithms. conventions for two MAC 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
skipping to change at page 12, line 36 skipping to change at page 12, line 36
* 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
Appendix Section 9.3 of [I-D.ietf-cose-rfc8152bis-struct] contains a Part Section 9.3 of [I-D.ietf-cose-rfc8152bis-struct] contains a
generic description of Content Encryption algorithms. This document generic description of Content Encryption algorithms. This document
defines the identifier and usages for three content encryption defines the identifier 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.
skipping to change at page 18, line 47 skipping to change at page 18, line 47
'unwrap key' when decrypting. 'unwrap key' when decrypting.
4.3.1. Security Considerations 4.3.1. Security Considerations
The key and nonce 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)
Appendix Section 9.4 of [I-D.ietf-cose-rfc8152bis-struct] contains a Part Section 9.4 of [I-D.ietf-cose-rfc8152bis-struct] contains a
generic description of Key Derivation Functions. This document generic description of Key Derivation Functions. This document
defines a single context structure and a single KDF. These elements defines a single context structure and a single KDF. These elements
are used for all of the recipient algorithms defined in this document are used for all of the recipient algorithms defined in this document
that require a KDF process. These algorithms are defined in Sections that require a KDF process. These algorithms are defined in Sections
6.1.2, 6.3, and 6.4. 6.1.2, 6.3, and 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].
skipping to change at page 21, line 25 skipping to change at page 21, line 25
sources: sources:
* Fields can be defined by the application. This is commonly used * Fields can be defined by the application. This is commonly used
to assign fixed names to parties, but it can be used for other to assign fixed names to parties, but it can be used for other
items such as nonces. items such as nonces.
* Fields can be defined by usage of the output. Examples of this * Fields can be defined by usage of the output. Examples of this
are the algorithm and key size that are being generated. are the algorithm and key size that are being generated.
* Fields can be defined by parameters from the message. We define a * Fields can be defined by parameters from the message. We define a
set of parameters in Table 10 that can be used to carry the values set of header parameters in Table 10 that can be used to carry the
associated with the context structure. Examples of this are values associated with the context structure. Examples of this
identities and nonce values. These parameters are designed to be are identities and nonce values. These header parameters are
placed in the unprotected bucket of the recipient structure; they designed to be placed in the unprotected bucket of the recipient
do not need to be in the protected bucket since they already are structure; they do not need to be in the protected bucket since
included in the cryptographic computation by virtue of being they already are included in the cryptographic computation by
included in the context structure. virtue of being included in the context structure.
+----------+-------+------+---------------------------+-------------+ +----------+-------+------+---------------------------+-------------+
| Name | Label | Type | Algorithm | Description | | Name | Label | Type | Algorithm | Description |
+==========+=======+======+===========================+=============+ +==========+=======+======+===========================+=============+
| PartyU | -21 | bstr | direct+HKDF-SHA-256, | Party U | | PartyU | -21 | bstr | direct+HKDF-SHA-256, | Party U |
| identity | | | direct+HKDF-SHA-512, | identity | | identity | | | direct+HKDF-SHA-512, | identity |
| | | | direct+HKDF-AES-128, | information | | | | | direct+HKDF-AES-128, | information |
| | | | direct+HKDF-AES-256, | | | | | | direct+HKDF-AES-256, | |
| | | | ECDH-ES+HKDF-256, | | | | | | ECDH-ES+HKDF-256, | |
| | | | ECDH-ES+HKDF-512, | | | | | | ECDH-ES+HKDF-512, | |
skipping to change at page 24, line 25 skipping to change at page 24, line 25
used to carry identity information in the message. However, used to carry identity information in the message. However,
identity information is often known as part of the protocol and identity information is often known as part of the protocol and
can thus be inferred rather than made explicit. If identity can thus be inferred rather than made explicit. If identity
information is carried in the message, applications SHOULD have information is carried in the message, applications SHOULD have
a way of validating the supplied identity information. The a way of validating the supplied identity information. The
identity information does not need to be specified and is set identity information does not need to be specified and is set
to nil in that case. to nil in that case.
nonce: This contains a nonce value. The nonce can either be nonce: This contains a nonce value. The nonce can either be
implicit from the protocol or be carried as a value in the implicit from the protocol or be carried as a value in the
unprotected headers. unprotected header bucket.
We define an algorithm parameter 'PartyU nonce' that can be We define an algorithm parameter 'PartyU nonce' that can be
used to carry this value in the message; however, the nonce used to carry this value in the message; however, the nonce
value could be determined by the application and the value value could be determined by the application and the value
determined from elsewhere. determined from elsewhere.
This option does not need to be specified and is set to nil in This option does not need to be specified and is set to nil in
that case. that case.
other: This contains other information that is defined by the other: This contains other information that is defined by the
skipping to change at page 25, line 8 skipping to change at page 25, line 8
output value. This practice means if algorithm A can use two output value. This practice means if algorithm A can use two
different key lengths, the key derived for longer key size will different key lengths, the key derived for longer key size will
not contain the key for shorter key size as a prefix. not contain the key for shorter key size as a prefix.
protected: This field contains the protected parameter field. If protected: This field contains the protected parameter field. If
there are no elements in the protected field, then use a zero- there are no elements in the protected field, then use a zero-
length bstr. length bstr.
other: This field is for free form data defined by the other: This field is for free form data defined by the
application. An example is that an application could define application. An example is that an application could define
two different strings to be placed here to generate different two different byte strings to be placed here to generate
keys for a data stream versus a control stream. This field is different keys for a data stream versus a control stream. This
optional and will only be present if the application defines a field is optional and will only be present if the application
structure for this information. Applications that define this defines a structure for this information. Applications that
SHOULD use CBOR to encode the data so that types and lengths define this SHOULD use CBOR to encode the data so that types
are correctly included. 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 this mutually known private information. An example of this
information would be a preexisting shared secret. (This could, information would be a preexisting shared secret. (This could,
for example, be used in combination with an ECDH key agreement to for example, be used in combination with an ECDH key agreement to
provide a secondary proof of identity.) The field is optional and provide a secondary proof of identity.) The field is optional and
will only be present if the application defines a structure for will only be present if the application defines a structure for
this information. Applications that define this SHOULD use CBOR this information. Applications that define this SHOULD use CBOR
to encode the data so that types and lengths are correctly to encode the data so that types and lengths are correctly
included. included.
skipping to change at page 25, line 47 skipping to change at page 25, 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
Appendix Section 9.5 of [I-D.ietf-cose-rfc8152bis-struct] contains a Part Section 9.5 of [I-D.ietf-cose-rfc8152bis-struct] contains a
generic description of content key distribution methods. This generic description of content key distribution methods. This
document defines the identifiers and usage for a number of content document defines the identifiers and usage for a number of content
key distribution methods. key distribution methods.
6.1. Direct Encryption 6.1. Direct Encryption
Direct encryption algorithm is defined in Appendix Section 9.5.1 of Direct encryption algorithm is defined in Part Section 9.5.1 of
[I-D.ietf-cose-rfc8152bis-struct]. Information about how to fill in [I-D.ietf-cose-rfc8152bis-struct]. Information about how to fill in
the COSE_Recipient structure are detailed there. the COSE_Recipient structure are 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.
skipping to change at page 29, line 12 skipping to change at page 29, line 12
derivation step will generate a new key that requires the same amount derivation step will generate a new key that requires the same amount
of work to get the key. of work to get the key.
6.2. AES Key Wrap 6.2. AES Key Wrap
The AES Key Wrap algorithm is defined in [RFC3394]. This algorithm The AES Key Wrap algorithm is defined in [RFC3394]. This algorithm
uses an AES key to wrap a value that is a multiple of 64 bits. As uses an AES key to wrap a value that is a multiple of 64 bits. As
such, it can be used to wrap a key for any of the content encryption such, it can be used to wrap a key for any of the content encryption
algorithms defined in this document. The algorithm requires a single algorithms defined in this document. The algorithm requires a single
fixed parameter, the initial value. This is fixed to the value fixed parameter, the initial value. This is fixed to the value
specified in Section 2.2.3.1 of [RFC3394]. There are no public specified in Section 2.2.3.1 of [RFC3394]. There are no public key
parameters that vary on a per-invocation basis. The protected header parameters that vary on a per-invocation basis. The protected header
field MUST be empty. bucket MUST be empty.
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 30, line 50 skipping to change at page 30, line 50
create a unique value. For the KDFs used, this means either the create a unique value. For the KDFs used, this means either the
'salt' parameter for HKDF (Table 9) or the 'PartyU nonce' 'salt' parameter for HKDF (Table 9) or the 'PartyU nonce'
parameter for the context structure (Table 10) MUST be present parameter for the context structure (Table 10) MUST be present
(both can be present if desired). The value in the parameter MUST (both can be present if desired). The value in the parameter MUST
be unique for the pair of keys being used. It is acceptable to be unique for the pair of keys being used. It is acceptable to
use a global counter that is incremented for every static-static use a global counter that is incremented for every static-static
operation and use the resulting value. When using static keys, operation and use the resulting value. When using static keys,
the static key should be identified to the recipient. The static the static key should be identified to the recipient. The static
key can be identified either by providing the key ('static key') key can be identified either by providing the key ('static key')
or by providing a key identifier for the static key ('static key or by providing a key identifier for the static key ('static key
id'). Both of these parameters are defined in Table 15. id'). Both of these header parameters are defined in Table 15.
* Key Derivation Algorithm: The result of an ECDH key agreement * Key Derivation Algorithm: The result of an ECDH key agreement
process does not provide a uniformly random secret. As such, it process does not provide a uniformly random secret. As such, it
needs to be run through a KDF in order to produce a usable key. needs to be run through a KDF in order to produce a usable key.
Processing the secret through a KDF also allows for the Processing the secret through a KDF also allows for the
introduction of context material: how the key is going to be used introduction of context material: how the key is going to be used
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.
skipping to change at page 33, line 29 skipping to change at page 33, line 29
A proof of possession of the private key associated with the public A proof of possession of the private key associated with the public
key is recommended when a key is moved from untrusted to trusted key is recommended when a key is moved from untrusted to trusted
(either by the end user or by the entity that is responsible for (either by the end user or by the entity that is responsible for
making trust statements on keys). making trust statements on keys).
6.4. ECDH with Key Wrap 6.4. ECDH with Key Wrap
These algorithms are defined in Table 16. These algorithms are defined in Table 16.
ECDH with Key Agreement is parameterized by the same parameters as ECDH with Key Agreement is parameterized by the same header
for ECDH; see Section 6.3, with the following modifications: parameters as for ECDH; see Section 6.3, with the following
modifications:
* Key Wrap Algorithm: Any of the key wrap algorithms defined in * Key Wrap Algorithm: Any of the key wrap algorithms defined in
Section 6.2 are supported. The size of the key used for the key Section 6.2 are supported. The size of the key used for the key
wrap algorithm is fed into the KDF. The set of identifiers are wrap algorithm is fed into the KDF. The set of identifiers are
found in Table 16. found in Table 16.
+---------+-------+---------+------------+--------+----------------+ +---------+-------+---------+------------+--------+----------------+
| Name | Value | KDF | Ephemeral- | Key | Description | | Name | Value | KDF | Ephemeral- | Key | Description |
| | | | Static | Wrap | | | | | | Static | Wrap | |
+=========+=======+=========+============+========+================+ +=========+=======+=========+============+========+================+
skipping to change at page 36, line 44 skipping to change at page 36, line 44
For EC keys with both coordinates, the 'kty' member is set to 2 For EC keys with both coordinates, the 'kty' member is set to 2
(EC2). The key parameters defined in this section are summarized in (EC2). The key parameters defined in this section are summarized in
Table 19. The members that are defined for this key type are: Table 19. The members that are defined for this key type are:
crv: This contains an identifier of the curve to be used with the crv: This contains an identifier of the curve to be used with the
key. The curves defined in this document for this key type can key. The curves defined in this document for this key type can
be found in Table 18. Other curves may be registered in the be found in Table 18. Other curves may be registered in the
future, and private curves can be used as well. future, and private curves can be used as well.
x: This contains the x-coordinate for the EC point. The integer is x: This contains the x-coordinate for the EC point. The integer is
converted to an octet string as defined in [SEC1]. Leading zero converted to a byte string as defined in [SEC1]. Leading zero
octets MUST be preserved. octets MUST be preserved.
y: This contains either the sign bit or the value of the y: This contains either the sign bit or the value of the
y-coordinate for the EC point. When encoding the value y, the y-coordinate for the EC point. When encoding the value y, the
integer is converted to an octet string (as defined in [SEC1]) integer is converted to an byte string (as defined in [SEC1])
and encoded as a CBOR bstr. Leading zero octets MUST be and encoded as a CBOR bstr. Leading zero octets MUST be
preserved. The compressed point encoding is also supported. preserved. The compressed point encoding is also supported.
Compute the sign bit as laid out in the Elliptic-Curve-Point-to- Compute the sign bit as laid out in the Elliptic-Curve-Point-to-
Octet-String Conversion function of [SEC1]. If the sign bit is Octet-String Conversion function of [SEC1]. If the sign bit is
zero, then encode y as a CBOR false value; otherwise, encode y zero, then encode y as a CBOR false value; otherwise, encode y
as a CBOR true value. The encoding of the infinity point is not as a CBOR true value. The encoding of the infinity point is not
supported. supported.
d: This contains the private key. d: This contains the private key.
skipping to change at page 37, line 49 skipping to change at page 37, line 49
hyper-elliptic surfaces). hyper-elliptic surfaces).
The key parameters defined in this section are summarized in The key parameters defined in this section are summarized in
Table 20. The members that are defined for this key type are: Table 20. The members that are defined for this key type are:
crv: This contains an identifier of the curve to be used with the crv: This contains an identifier of the curve to be used with the
key. The curves defined in this document for this key type can key. The curves defined in this document for this key type can
be found in Table 18. Other curves may be registered in the be found in Table 18. Other curves may be registered in the
future and private curves can be used as well. future and private curves can be used as well.
x: This contains the x-coordinate for the EC point. The octet x: This contains the public key. The byte string contains the
string represents a little-endian encoding of x. public key as defined by the algorithm. (For X25591, internally
it is a little-endian integer.)
d: This contains the private key. d: This 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 | Label | Type | Description | | Name | Key | Label | Type | Description |
| | Type | | | | | | Type | | | |
+======+==========+=======+=======+=================================+ +======+==========+=======+=======+=================================+
| crv | 1 | -1 | int / | EC identifier - Taken from the | | crv | 1 | -1 | int / | EC identifier - Taken from the |
| | | | tstr | "COSE Elliptic Curves" registry | | | | | tstr | "COSE Elliptic Curves" registry |
+------+----------+-------+-------+---------------------------------+ +------+----------+-------+-------+---------------------------------+
| x | 1 | -2 | bstr | x-coordinate | | x | 1 | -2 | bstr | Public Key |
+------+----------+-------+-------+---------------------------------+ +------+----------+-------+-------+---------------------------------+
| d | 1 | -4 | bstr | Private key | | d | 1 | -4 | bstr | Private key |
+------+----------+-------+-------+---------------------------------+ +------+----------+-------+-------+---------------------------------+
Table 20: Octet Key Pair Parameters Table 20: Octet Key Pair Parameters
7.3. Symmetric Keys 7.3. Symmetric Keys
Occasionally it is required that a symmetric key be transported Occasionally it is required that a symmetric key be transported
between entities. This key structure allows for that to happen. between entities. This key structure allows for that to happen.
skipping to change at page 39, line 16 skipping to change at page 39, line 16
There are some situations that have been identified where There are some situations that have been identified where
identification of capabilities of an algorithm need to be specified. identification of capabilities of an algorithm need to be specified.
One example of this is in [I-D.ietf-core-oscore-groupcomm] where the One example of this is in [I-D.ietf-core-oscore-groupcomm] where the
capabilities of the counter signature algorithm are mixed into the capabilities of the counter signature algorithm are mixed into the
traffic key derivation process. This has a counterpart in the S/MIME traffic key derivation process. This has a counterpart in the S/MIME
specifications where SMIMECapabilities is defined in Section 2.5.2 of specifications where SMIMECapabilities is defined in Section 2.5.2 of
[RFC8551]. The concept is being pulled forward and defined now for [RFC8551]. The concept is being pulled forward and defined now for
COSE. COSE.
There is a presumption in the way that this is laid out is that the
algorithm identifier itself is not needed to be a part of this as it
is specified in a different location.
Two different types of capabilities are defined: Capabilities for Two different types of capabilities are defined: Capabilities for
algorithms and capabilities for key structures. Once defined by algorithms and capabilities for key structures. Once defined by
registration with IANA, the list capabilities is immutable. As a registration with IANA, the list capabilities is immutable. If it is
general rule, the capabilities are going to correspond to algorithm later found that a new capability is needed for a key type or an
or key fields, but they do not need to do so. An example of this is algorithm, it will require that a new code point be assigned to deal
the HSS-LMS key capabilities defined below where the hash algorithm with that. As a general rule, the capabilities are going to map to
used is included. algorithm specific header parameters or key parameters, but they do
not need to do so. An example of this is the HSS-LMS key
capabilities defined below where the hash algorithm used is included.
The capability structure is an array of values, the order being The capability structure is an array of values, the order being
dependent on the specific algorithm or key. For an algorithm, the dependent on the specific algorithm or key. For an algorithm, the
first element should always be a key type value, but the items that first element should always be a key type value, but the items that
are specific to a key should not be included in the algorithm are specific to a key should not be included in the algorithm
capabilities. This means that if one wishes to enumerate all of the capabilities. This means that if one wishes to enumerate all of the
capabilities for a device which implements ECDH, it requires multiple capabilities for a device which implements ECDH, it requires multiple
pairs of capability structures (algorithm, key) to deal with the pairs of capability structures (algorithm, key) to deal with the
different key types and curves that are supported. For a key, the different key types and curves that are supported. For a key, the
first element should also be a key type value, while this means that first element should also be a key type value, while this means that
skipping to change at page 39, line 44 skipping to change at page 39, line 50
are used, the key type is needed in order to understand the rest of are used, the key type is needed in order to understand the rest of
the values. the values.
8.1. Assignments for Existing Key Types 8.1. Assignments for Existing Key Types
There are a number of pre-existing key types, the following deals There are a number of pre-existing key types, the following deals
with creating the capability definition for those structures: with creating the capability definition for those structures:
* OKP, EC2: The list of capabilities is: * OKP, EC2: The list of capabilities is:
- The key type value, - The key type value. (1 for OKP or 2 for EC2.)
- One curve for that key type from the "COSE Elliptic Curve"
- One curve for that key type. registry.
* RSA: The list of capabilities is: * RSA: The list of capabilities is:
- The key type value. - The key type value (3).
* Symmetric: The list of capabilities is: * Symmetric: The list of capabilities is:
- The key type value. - The key type value (4).
* HSS-LMS: The list of capabilities is: * HSS-LMS: The list of capabilities is:
- The key type value, - The key type value (5),
- Algorithm identifier for the underlying hash function. - Algorithm identifier for the underlying hash function from the
"COSE Algorithms" registry.
8.2. Assignments for Existing Algorithms 8.2. Assignments for Existing Algorithms
For the current set of algorithms in the registry, those in this For the current set of algorithms in the registry, those in this
document as well as those in [RFC8230] and [I-D.ietf-cose-hash-sig], document as well as those in [RFC8230] and [I-D.ietf-cose-hash-sig],
the capabilities is set to the single entry of the key type that will the capabilities is set to the single entry of the key type (from the
be accepted. It is expected other algorithms will have no items or "COSE Key Types" Registry) that will be accepted. It is expected
multiple items. future registered algorithms could have zero, one, multiple items.
8.3. Examples
In this section a trio of examples are provided. In all three cases
the pair of capabilities is always provided as the algorithm and then
the key capabilities. For simplicity's sake, a CBOR sequence
[I-D.ietf-cbor-sequence] is used for the two arrays.
ECDSA with SHA-512 and a P-256 curve:
0x8102820201 / [2],[2, 1] /
ECDH-ES + A256KW with a P-256 curve:
0x8102820201 / [2],[2, 1] /
ECDH-ES + A256KW with an X25519 curve:
0x8101820104 / [1],[1, 4] /
9. CBOR Encoding Restrictions 9. CBOR Encoding 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
to work. We have managed to narrow it down to the following to work. We have managed to narrow it down to the following
restrictions: restrictions:
* The restriction applies to the encoding of the COSE_KDF_Context. * The restriction applies to the encoding of the COSE_KDF_Context.
skipping to change at page 40, line 48 skipping to change at page 41, line 32
requirement by using parsers that will fail the parse step or by requirement by using parsers that will fail the parse step or by
using parsers that will pass all keys to the application, and the using parsers that will pass all keys to the application, and the
application can perform the check for duplicate keys. application can perform the check for duplicate keys.
10. IANA Considerations 10. IANA Considerations
10.1. Changes to "COSE Key Types" registry. 10.1. Changes to "COSE Key Types" registry.
IANA is requested to create a new column in the "COSE Key Types" IANA is requested to create a new column in the "COSE Key Types"
registry. The new column is to be labeled "Capabilities". The new registry. The new column is to be labeled "Capabilities". The new
column is to be populated according the the entries in Table 22. column is to be populated according the entries in Table 22.
+------+-----------+---------------------+ +-------+-----------+--------------------------+
| Name | Value | Capabilities | | Value | Name | Capabilities |
+======+===========+=====================+ +=======+===========+==========================+
| 1 | OKP | kty, crv | | 1 | OKP | [kty(1), crv] |
+------+-----------+---------------------+ +-------+-----------+--------------------------+
| 2 | EC2 | kty, crv | | 2 | EC2 | [kty(2), crv] |
+------+-----------+---------------------+ +-------+-----------+--------------------------+
| 3 | RSA | kty | | 3 | RSA | [kty(3)] |
+------+-----------+---------------------+ +-------+-----------+--------------------------+
| 4 | Symmetric | kty | | 4 | Symmetric | [kty(4)] |
+------+-----------+---------------------+ +-------+-----------+--------------------------+
| 5 | HSS-LMS | kty, hash algorithm | | 5 | HSS-LMS | [kty(5), hash algorithm] |
+------+-----------+---------------------+ +-------+-----------+--------------------------+
Table 22: Key Type Capabilities Table 22: Key Type Capabilities
10.2. Changes to "COSE Algorithms" registry 10.2. Changes to "COSE Algorithms" registry
IANA is requested to create a new column in the "COSE Algorithms" IANA is requested to create a new column in the "COSE Algorithms"
registry. The new column is to be labeled "Capabilities". The new registry. The new column is to be labeled "Capabilities". The new
column is populated with "kty" for all current, non-provisional, column is populated with "[kty]" for all current, non-provisional,
registrations. It is expected that the documents which define those registrations. It is expected that the documents which define those
algorithms will be expanded to include this registration, if this is algorithms will be expanded to include this registration, if this is
not done then the DE should be consulted at the time of final not done then the DE should be consulted final registration for this
registration. document is done.
IANA is requested to update the reference column in the "COSE
Algorithms" registry to include [[This Document]] as a reference for
all rows where it is not already present. Note to IANA: There is an
action in [I-D.ietf-cose-rfc8152bis-struct] which also modifies data
in the reference column. That action should be applied first.
10.3. Changes to the "COSE Key Type Parameters" registry
IANA is required to modify the description to "Public Key" for the
line with "Key Type" of 2 and the "Name" of "x". See Table 20 which
has been modified with this change.
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.
skipping to change at page 43, line 23 skipping to change at page 44, line 17
unique and unpredictable; under these circumstances, it's reasonable unique and unpredictable; under these circumstances, it's reasonable
to use a counter for creation of the nonce. In cases where one wants to use a counter for creation of the nonce. In cases where one wants
the pattern of the nonce to be unpredictable as well as unique, one the pattern of the nonce to be unpredictable as well as unique, one
can use a key created for that purpose and encrypt the counter to can use a key created for that purpose and encrypt the counter to
produce the nonce value. produce the nonce value.
One area that has been starting to get exposure is doing traffic One area that has been starting to get exposure is doing traffic
analysis of encrypted messages based on the length of the message. analysis of encrypted messages based on the length of the message.
This specification does not provide for a uniform method of providing This specification does not provide for a uniform method of providing
padding as part of the message structure. An observer can padding as part of the message structure. An observer can
distinguish between two different strings (for example, 'YES' and distinguish between two different messages (for example, 'YES' and
'NO') based on the length for all of the content encryption 'NO') based on the length for all of the content encryption
algorithms that are defined in this document. This means that it is algorithms that are defined in this document. This means that it is
up to the applications to document how content padding is to be done up to the applications to document how content padding is to be done
in order to prevent or discourage such analysis. (For example, the in order to prevent or discourage such analysis. (For example, the
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-06, 11 September 2019, draft-ietf-cose-rfc8152bis-struct-07, 17 November 2019,
<https://tools.ietf.org/html/draft-ietf-cose-rfc8152bis- <https://tools.ietf.org/html/draft-ietf-cose-rfc8152bis-
struct-06>. struct-07>.
[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>.
skipping to change at page 46, line 42 skipping to change at page 47, line 37
[RFC8230] Jones, M., "Using RSA Algorithms with CBOR Object Signing [RFC8230] Jones, M., "Using RSA Algorithms with CBOR Object Signing
and Encryption (COSE) Messages", RFC 8230, and Encryption (COSE) Messages", RFC 8230,
DOI 10.17487/RFC8230, September 2017, DOI 10.17487/RFC8230, September 2017,
<https://www.rfc-editor.org/info/rfc8230>. <https://www.rfc-editor.org/info/rfc8230>.
[I-D.ietf-core-oscore-groupcomm] [I-D.ietf-core-oscore-groupcomm]
Tiloca, M., Selander, G., Palombini, F., and J. Park, Tiloca, M., Selander, G., Palombini, F., and J. Park,
"Group OSCORE - Secure Group Communication for CoAP", Work "Group OSCORE - Secure Group Communication for CoAP", Work
in Progress, Internet-Draft, draft-ietf-core-oscore- in Progress, Internet-Draft, draft-ietf-core-oscore-
groupcomm-05, 5 July 2019, <https://tools.ietf.org/html/ groupcomm-06, 4 November 2019,
draft-ietf-core-oscore-groupcomm-05>. <https://tools.ietf.org/html/draft-ietf-core-oscore-
groupcomm-06>.
[I-D.ietf-cose-hash-sig] [I-D.ietf-cose-hash-sig]
Housley, R., "Use of the HSS/LMS Hash-based Signature Housley, R., "Use of the HSS/LMS Hash-based Signature
Algorithm with CBOR Object Signing and Encryption (COSE)", Algorithm with CBOR Object Signing and Encryption (COSE)",
Work in Progress, Internet-Draft, draft-ietf-cose-hash- Work in Progress, Internet-Draft, draft-ietf-cose-hash-
sig-06, 1 November 2019, sig-09, 11 December 2019,
<https://tools.ietf.org/html/draft-ietf-cose-hash-sig-06>. <https://tools.ietf.org/html/draft-ietf-cose-hash-sig-09>.
[I-D.ietf-cbor-sequence]
Bormann, C., "Concise Binary Object Representation (CBOR)
Sequences", Work in Progress, Internet-Draft, draft-ietf-
cbor-sequence-02, 25 September 2019,
<https://tools.ietf.org/html/draft-ietf-cbor-sequence-02>.
[SP800-56A] [SP800-56A]
Barker, E., Chen, L., Roginsky, A., and M. Smid, Barker, E., Chen, L., Roginsky, A., and M. Smid,
"Recommendation for Pair-Wise Key Establishment Schemes "Recommendation for Pair-Wise Key Establishment Schemes
Using Discrete Logarithm Cryptography", Using Discrete Logarithm Cryptography",
DOI 10.6028/NIST.SP.800-56Ar2, NIST Special Publication DOI 10.6028/NIST.SP.800-56Ar2, NIST Special Publication
800-56A, Revision 2, May 2013, 800-56A, Revision 2, May 2013,
<http://nvlpubs.nist.gov/nistpubs/SpecialPublications/ <http://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-56Ar2.pdf>. NIST.SP.800-56Ar2.pdf>.
 End of changes. 46 change blocks. 
89 lines changed or deleted 142 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/