Subject: [COSE] [Technical Errata Reported] RFC8152 (6597)

From: RFC Errata System <[email-masked]>
Date: Thu, 3 Jun 2021 05:19:38 -0700 (PDT)

The following errata report has been submitted for RFC8152,
"CBOR Object Signing and Encryption (COSE)".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6597

--------------------------------------
Type: Technical
Reported by: Anders Rundgren <[email-masked]>

Section: 12.5.1.

Original Text
-------------
The RFC is unclear to whether Concat KDF or HKDF is to be used:

In table 20 there is an entry:
ECDH-ES +  -31   | HKDF -  | yes        | A256KW | ECDH ES w/    |
   | A256KW    |       | SHA-256 |            |        | Concat KDF    |
   |           |       |         |            |        | and AES Key   |
   |           |       |         |            |        | Wrap w/       |
   |           |       |         |            |        | 256-bit key  

That is, the table talks both about Concat and HKDF.

The IANA registry for this algorithm says Concat KDF

Jim's sample code for algorithm -31 says HKDF.

Corrected Text
--------------
I have no corrected text to offer since I don't have the answer to the question raised.

Concat is referred to once and without any external references.  In JOSE, Concat denotes a NIST standard which is quite different to HKDF.

Notes
-----
It is pretty vital for interoperability knowing if Concat KDF or HKDF is to be used.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC8152 (draft-ietf-cose-msg-24)
--------------------------------------
Title               : CBOR Object Signing and Encryption (COSE)
Publication Date    : July 2017
Author(s)           : J. Schaad
Category            : PROPOSED STANDARD
Source              : CBOR Object Signing and Encryption
Area                : Security
Stream              : IETF
Verifying Party     : IESG

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 3 Jun 2021 19:21:12 +0300

> "CBOR Object Signing and Encryption (COSE)".

Here is what I presume table 20 should be (modulo precise way HKDF with
SHA-256 should be written):

   +-----------+-------+---------+------------+--------+---------------+
   | Name      | Value | KDF     | Ephemeral- | Key    | Description   |
   |           |       |         | Static     | Wrap   |               |
   +-----------+-------+---------+------------+--------+---------------+
   | ECDH-ES + | -29   | HKDF -  | yes        | A128KW | ECDH ES w/    |
   | A128KW    |       | SHA-256 |            |        | HKDF SHA-256  |
   |           |       |         |            |        | and AES Key   |
   |           |       |         |            |        | Wrap w/       |
   |           |       |         |            |        | 128-bit key   |
   |           |       |         |            |        |               |
   | ECDH-ES + | -30   | HKDF -  | yes        | A192KW | ECDH ES w/    |
   | A192KW    |       | SHA-256 |            |        | HKDF SHA-256  |
   |           |       |         |            |        | and AES Key   |
   |           |       |         |            |        | Wrap w/       |
   |           |       |         |            |        | 192-bit key   |
   |           |       |         |            |        |               |
   | ECDH-ES + | -31   | HKDF -  | yes        | A256KW | ECDH ES w/    |
   | A256KW    |       | SHA-256 |            |        | HKDF SHA-256  |
   |           |       |         |            |        | and AES Key   |
   |           |       |         |            |        | Wrap w/       |
   |           |       |         |            |        | 256-bit key   |
   |           |       |         |            |        |               |
   | ECDH-SS + | -32   | HKDF -  | no         | A128KW | ECDH SS w/    |
   | A128KW    |       | SHA-256 |            |        | HKDF SHA-256  |
   |           |       |         |            |        | and AES Key   |
   |           |       |         |            |        | Wrap w/       |
   |           |       |         |            |        | 128-bit key   |
   |           |       |         |            |        |               |
   | ECDH-SS + | -33   | HKDF -  | no         | A192KW | ECDH SS w/    |
   | A192KW    |       | SHA-256 |            |        | HKDF SHA-256  |
   |           |       |         |            |        | and AES Key   |
   |           |       |         |            |        | Wrap w/       |
   |           |       |         |            |        | 192-bit key   |
   |           |       |         |            |        |               |
   | ECDH-SS + | -34   | HKDF -  | no         | A256KW | ECDH SS w/    |
   | A256KW    |       | SHA-256 |            |        | HKDF SHA-256  |
   |           |       |         |            |        | and AES Key   |
   |           |       |         |            |        | Wrap w/       |
   |           |       |         |            |        | 256-bit key   |
   +-----------+-------+---------+------------+--------+---------------+

That is, the value of KDF column is correct, and the description is
incorrect. In section 12.5, there is definition of how key encryption is
done, and it references functions "KDF" and "KeyWrap", which are
presumably the values of colums "KDF" and "Key Wrap".

Furthermore, if one supposed it was intended to be concat KDF, I do not
see anywhere what the hash function would be (for JWE, the text
specifies that the hash function is SHA-256).

And I note that draft-ietf-cose-rfc8152bis-algs-12 has table with the
same sort of inconsistency (table 16). Presumably that table should be
fixed before publication.

> It is pretty vital for interoperability knowing if Concat KDF or HKDF is to be used.

-Ilari

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 3 Jun 2021 18:44:02 +0200

Thanx Ilari,

So apparently both the RFC and the associated IANA registry entries are incorrect.

Fortunately, my code did this assumption as well :-)

A remaining issue is that ECDH-ES+A256KW is a different algorithm
in JOSE.  Jim has in his own code rather used
ECDH-ES-HKDF-256+A256KW which seems reasonable.  Maybe that
is stretching things too far?

rgds,
Anders