Errata

Status:

Reported

Type:

Technical

Reported By:

Christian Amsüss

Date Reported:

2024-06-11

Section A.2.2 says:

     / kid /  4: h'53796d6d6574726963323536' / 'Symmetric256' /,

It should say:

     / kid /  2: h'53796d6d6574726963323536' / 'Symmetric256' /,

Notes:

The hex above the diagnostic notation encodes for index 2 before the 'Symmetric256' value. The use of CBOR value 2 to mean "kid" is also consistent with the examples around it.

As this is a mix-up between the "kid" key from COSE Key Common Parameters and COSE Header parameters, a check through the whole document for whether the right numeric values are used might be due. The use of 2 here and 4 in A.3 and A.4 seems right to me -- but I keep mixing those up myself, which was why I was looking into this example in the first place.

Status:

Reported

Type:

Technical

Reported By:

Rohan Mahy

Date Reported:

2025-10-29

Section 2 says:

   NumericDate
      The "NumericDate" term in this specification has the same meaning
      and processing rules as the JWT "NumericDate" term defined in
      Section 2 of [RFC7519], except that it is represented as a CBOR
      numeric date (from Section 2.4.1 of [RFC7049]) instead of a JSON
      number.  The encoding is modified so that the leading tag 1
      (epoch-based date/time) MUST be omitted.

It should say:

   NumericDate
      The "NumericDate" term in this specification has the same meaning
      and processing rules as the JWT "NumericDate" term defined in
      Section 2 of [RFC7519], except that it is represented as a finite
      CBOR numeric date (from Section 2.4.1 of [RFC7049]) instead of a
      JSON number.  The encoding is modified so that the leading tag 1
      (epoch-based date/time) MUST be omitted.

Notes:

Section 2.4.1 of RFC7049 says that the value is a negative or positive integer or a floating point *number* (which does not include NaN floating pointing point values), but it does not say anything about floating point positive and negative infinity. This is likely to be missed by most implementers of RFC 8392.


A JWT "NumericDate" was intended to mimic a value which can be expressed in JSON. JSON does not allow infinite values.

In addition, exp, nbf, and iat all share the same type. The iat is the "issued at" date. The idea of a creation date with an infinite value is nonsensical.

Status:

Reported

Type:

Technical

Reported By:

Dridi Boukelmoune

Date Reported:

2025-11-25

Section A.2.2 says:

a4205820403697de87af64611c1d32a05dab0fe1fcb715a86ab435f1ec99192d
795693880104024c53796d6d6574726963323536030a

It should say:

a4205820403697de87af64611c1d32a05dab0fe1fcb715a86ab435f1ec99192d
795693880104024c53796d6d65747269633235360304

Notes:

The key advertises algorithm number 10 (AES-CCM-16-64-128) instead of 4 (HMAC 256/64). The last byte needs to change from 0a to 04 to match the "/ alg /  3: 4 / HMAC 256/64 /" CBOR diagnostic.

Status:

Held for Document Update

Type:

Technical

Reported By:

Felipe Gasper

Date Reported:

2019-04-29

Held for Document Update by:

Paul Wouters

Date Held for Document Update:

2024-01-17

Section 1.1 says:

In JSON, maps are called objects and only have one kind of map key: a
   string.  CBOR uses strings, negative integers, and unsigned integers
   as map keys.

It should say:

In JSON, maps are called objects and only have one kind of map key:
a string.  CBOR allows other data types, such as strings, negative
integers, and unsigned integers, as map keys.

Notes:

The text as it stands risks an interpretation that CBOR limits map keys to integers and strings; per discussion on the CBOR mailing list, this is not the case.

Status:

Held for Document Update

Type:

Editorial

Reported By:

Laurence Lundblade

Date Reported:

2019-09-03

Held for Document Update by:

Benjamin Kaduk

Date Held for Document Update:

2019-09-05

Section A.3 says:

   d28443a10126a104524173796d6d657472696345434453413235365850a701756
   36f61703a2f2f61732e6578616d706c652e636f6d02656572696b77037818636f
   61703a2f2f6c696768742e6578616d706c652e636f6d041a5612aeb0051a5610d
   9f0061a5610d9f007420b7158405427c1ff28d23fbad1f29c4c7c6a555e601d6f
   a29f9179bc3d7438bacaca5acd08c8d4d4f96131680c429a01f85951ecee743a5
   2b9b63632c57209120e1c9e30

It should say:

   d28443a10126a104524173796d6d657472696345434453413235365850a70175
   636f61703a2f2f61732e6578616d706c652e636f6d02656572696b7703781863
   6f61703a2f2f6c696768742e6578616d706c652e636f6d041a5612aeb0051a56
   10d9f0061a5610d9f007420b7158405427c1ff28d23fbad1f29c4c7c6a555e60
   1d6fa29f9179bc3d7438bacaca5acd08c8d4d4f96131680c429a01f85951ecee
   743a52b9b63632c57209120e1c9e30

Notes:

The ASCII representation of binary bytes in Figure 10 is wrapped
on an odd number of ASCII characters. Since there are two ASCII
characters per binary bytes this splits the last byte over two
lines. 

The CBOR playground (http://cbor.me) cannot handle this and
errors out. 

This is slightly confusing for readers.

The actual bytes values are correct by all the checks I did.