RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 9 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."

Status: Held for Document Update (1)

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: 5533
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Jian Huang
Date Reported: 2018-10-18
Held for Document Update by: Benjamin Kaduk
Date Held: 2018-10-19

Section 3.1 says:

   alg:  This parameter is used to indicate the algorithm used for the
      security processing.  This parameter MUST be authenticated where
      the ability to do so exists.  This support is provided by AEAD
      algorithms or construction (COSE_Sign, COSE_Sign0, COSE_Mac, and
      COSE_Mac0).

It should say:

   alg:  This parameter is used to indicate the algorithm used for the
      security processing.  This parameter MUST be authenticated where
      the ability to do so exists.  This support is provided by AEAD
      algorithms or construction (COSE_Sign, COSE_Sign1, COSE_Mac, and
      COSE_Mac0).

Notes:

COSE_Sign0 is only mentioned once in the document, but COSE_Sign1 appears many times.

Report New Errata



Advanced Search