RFC Errata
Found 8 records.
Status: Verified (6)
RFC 8152, "CBOR Object Signing and Encryption (COSE)", July 2017
Note: This RFC has been obsoleted by RFC 9052, RFC 9053
Source of RFC: cose (sec)
Errata ID: 5066
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jim Schaad
Date Reported: 2017-07-11
Verifier Name: Benjamin Kaduk
Date Verified: 2020-10-07
Section 14 says:
o The restriction applies to the encoding of the Sig_structure, the
Enc_structure, and the MAC_structure.
It should say:
o The restriction applies to the encoding of the COSE_KDF_Context,
Sig_structure, the Enc_structure, and the MAC_structure.
Notes:
When listing the set of structure that need to be canonically encoded, I missed this one.
Verifier Notes: this is being fixed in draft-ietf-cose-rfc8152bis-algs.
Errata ID: 5545
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Francesca Palombini
Date Reported: 2018-11-05
Verifier Name: Benjamin Kaduk
Date Verified: 2019-01-16
Section 7.1 says:
+---------+-------+----------------+------------+-------------------+
| Name | Label | CBOR Type | Value | Description |
| | | | Registry | |
+---------+-------+----------------+------------+-------------------+
| kty | 1 | tstr / int | COSE Key | Identification of |
| | | | Common | the key type |
| | | | Parameters | |
| | | | | |
| kid | 2 | bstr | | Key |
| | | | | identification |
| | | | | value -- match to |
| | | | | kid in message |
| | | | | |
| alg | 3 | tstr / int | COSE | Key usage |
| | | | Algorithms | restriction to |
| | | | | this algorithm |
| | | | | |
| key_ops | 4 | [+ (tstr/int)] | | Restrict set of |
| | | | | permissible |
| | | | | operations |
| | | | | |
| Base IV | 5 | bstr | | Base IV to be |
| | | | | xor-ed with |
| | | | | Partial IVs |
+---------+-------+----------------+------------+-------------------+
Table 3: Key Map Labels
It should say:
+---------+-------+----------------+------------+-------------------+
| Name | Label | CBOR Type | Value | Description |
| | | | Registry | |
+---------+-------+----------------+------------+-------------------+
| kty | 1 | tstr / int | COSE Key | Identification of |
| | | | Types | the key type |
| | | | | |
| | | | | |
| kid | 2 | bstr | | Key |
| | | | | identification |
| | | | | value -- match to |
| | | | | kid in message |
| | | | | |
| alg | 3 | tstr / int | COSE | Key usage |
| | | | Algorithms | restriction to |
| | | | | this algorithm |
| | | | | |
| key_ops | 4 | [+ (tstr/int)] | | Restrict set of |
| | | | | permissible |
| | | | | operations |
| | | | | |
| Base IV | 5 | bstr | | Base IV to be |
| | | | | xor-ed with |
| | | | | Partial IVs |
+---------+-------+----------------+------------+-------------------+
Table 3: Key Map Labels
Notes:
The value registry for kty should be COSE Key Types, as indicated in the text following Table 3. This change affects the IANA registry: https://www.iana.org/assignments/cose/cose.xhtml#key-common-parameters
Errata ID: 5650
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jim Schaad
Date Reported: 2019-03-11
Verifier Name: Benjamin Kaduk
Date Verified: 2019-03-11
Section Section 13.2 says:
| crv | 1 | -1 | int / | EC identifier - Taken from the | | | | | tstr | "COSE Key Common Parameters" | | | | | | registry |
It should say:
| crv | 1 | -1 | int / | EC identifier - Taken from the | | | | | tstr | "COSE Elliptic Curves" registry |
Notes:
The set of curve identifiers lives in the COSE Elliptic Curves registry and not in the COSE Key Common Parameters registry.
Errata ID: 5669
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Marco Tiloca
Date Reported: 2019-03-23
Verifier Name: Benjamin Kaduk
Date Verified: 2019-03-25
Section 16.7 says:
Value: This is the value used to identify the curve. These values MUST be unique. The value can be a positive integer, a negative integer, or a string. Description: This field contains a brief description of the curve. References: This contains a pointer to the public specification for the curve if one exists.
It should say:
Value: This is the value used to identify the key type. These values MUST be unique. The values are positive integers. Description: This field contains a brief description of the key type. References: This contains a pointer to the public specification for the key type if one exists.
Notes:
This Registry is about Key Types, but the current text refers to curves.
The value identifying a key type can be only a positive integer.
Errata ID: 6209
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: JimSchaad
Date Reported: 2020-06-16
Verifier Name: Benjamin Kaduk
Date Verified: 2020-06-17
Section 9 says:
can be used to prove the identity
It should say:
cannot be used to prove the identity
Notes:
MACs cannot be used to prove identity to a third party. There is a missing "not" in the sentence.
Errata ID: 6487
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Thomas Fossati
Date Reported: 2021-03-18
Verifier Name: Benjamin Kaduk
Date Verified: 2021-07-21
Section C.7 says:
In order the keys are: o An EC key with a kid of "meriadoc.brandybuck@buckland.example" o An EC key with a kid of "peregrin.took@tuckborough.example" o An EC key with a kid of "bilbo.baggins@hobbiton.example" o An EC key with a kid of "11"
It should say:
In order the keys are: o An EC key with a kid of "meriadoc.brandybuck@buckland.example" o An EC key with a kid of "11" o An EC key with a kid of "bilbo.baggins@hobbiton.example" o An EC key with a kid of "peregrin.took@tuckborough.example"
Notes:
The order of this list does not match the actual keys listed subsequently.
Status: Reported (2)
RFC 8152, "CBOR Object Signing and Encryption (COSE)", July 2017
Note: This RFC has been obsoleted by RFC 9052, RFC 9053
Source of RFC: cose (sec)
Errata ID: 6597
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Anders Rundgren
Date Reported: 2021-06-03
Section 12.5.1. says:
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.
It should say:
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.
Errata ID: 6909
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Thomas Fossati
Date Reported: 2022-03-31
Edited by: RFC Editor
Section 3.1 says:
Generic_Headers = (
? 1 => int / tstr, ; algorithm identifier
? 2 => [+label], ; criticality
? 3 => tstr / int, ; content type
? 4 => bstr, ; key identifier
? 5 => bstr, ; IV
? 6 => bstr ; Partial IV
)
It should say:
Generic_Headers = (
? 1 => int / tstr, ; algorithm identifier
? 2 => [+label], ; criticality
? 3 => tstr / int, ; content type
? 4 => bstr, ; key identifier
? ( 5 => bstr // ; IV
6 => bstr ) ; Partial IV
)
Notes:
Section 3.1 says: "The "Initialization Vector" and "Partial Initialization Vector" header parameters MUST NOT both be present in the same security layer."