Found 5 records.
Status: Reported (3)
RFC 8392, "CBOR Web Token (CWT)", May 2018
Source of RFC: ace (sec)
Errata ID: 7982
Status: Reported
Type: Technical
Publication Format(s) : TEXT
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.
Errata ID: 8617
Status: Reported
Type: Technical
Publication Format(s) : TEXT
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.
Errata ID: 8655
Status: Reported
Type: Technical
Publication Format(s) : TEXT
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 (2)
RFC 8392, "CBOR Web Token (CWT)", May 2018
Source of RFC: ace (sec)
Errata ID: 5710
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Felipe Gasper
Date Reported: 2019-04-29
Held for Document Update by: Paul Wouters
Date Held: 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.
Errata ID: 5852
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Laurence Lundblade
Date Reported: 2019-09-03
Held for Document Update by: Benjamin Kaduk
Date Held: 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.