I think the realistic and efficient thing is to assume CBOR libraries will have one interface for int64_t and other interfaces for integers of different flavors and larger ranges. As a data point, the EverCBOR library does this:
https://github.com/project-everest/everparse/blob/fd7d1f4aebb76f70aefb3c499d80bffe6c82d0d3/src/cbor/pulse/nondet/c/CBORNondet.h#L51 bool cbor_nondet_read_uint64(cbor_raw x, uint64_t *dest); bool cbor_nondet_read_int64(cbor_raw x, int64_t *dest); https://github.com/project-everest/everparse/blob/master/src/cbor/pulse/nondet/c/CBORNondet.h#L98 cbor_raw cbor_nondet_mk_uint64(uint64_t v); cbor_raw cbor_nondet_mk_neg_int64(uint64_t v); Thank you, Amaury ________________________________ From: Laurence Lundblade <[email protected]> Sent: 10 January 2026 21:49 To: Anders Rundgren <[email protected]> Cc: [email protected] <[email protected]> Subject: [EXTERNAL] [COSE] Re: Size/Range of COSE "alg" and CWT "iat" objects I think the realistic and efficient thing is to assume CBOR libraries will have one interface for int64_t and other interfaces for integers of different flavors and larger ranges. Even some languags that support big numbers well separate this, because the processing and storage internally is so different. Int64_t can be handled extremely efficient because CPU HW supports it extremely efficiently. Also, COSE is targeted at constrained environments. Int64_t alg IDs work great in that environment. String IDs don’t. LL > On Jan 9, 2026, at 12:56 AM, Anders Rundgren <[email protected]> > wrote: > > Hi CBOR/COSE enthusiasts! > > During the design of the (in)famous Embedded Signature specification and > associated implementations [*}, I stumbled over the type of the COSE > algorithm ID, in CDDL defined as "tstr/int". A problem is that my CBOR > implementations do not really support "int" since this effectively translates > to a 65-bit integer. A quick consultation with the associated IANA > Designated Expert (Carsten Bormann) revealed that IANA would not accept COSE > algorithm IDs even above the JavaScript 53-bit level. > > A similar issue arose with "iat" in CWT. Although it might be cool with > timestamps spanning billions of years forward and backward, this is not > particularly interoperable with current time APIs. > > To cope with such issues, my primary project (creating a cross-platform > profile for CBOR), defines a set of "standardized", presumably portable, CBOR > protocol primitives: > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-rundgren-cbor-core-24.html%23name-protocol-primitives&data=05%7C02%7CAmaury.Chamayou%40microsoft.com%7Ceaeb732ba1c547e8515208de5092221a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639036785749781781%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=zkKZnG%2FTF5V6LLZ9RMNj0g8d5LE8TM0W366zL5sL0Ks%3D&reserved=0<https://www.ietf.org/archive/id/draft-rundgren-cbor-core-24.html#name-protocol-primitives> > > For the COSE-derived solutions, the type of "alg" was set to int32 while > limiting "iat" to the range defined by the I-D: 0 ("1970‑01‑01T00:00:00Z") to > 253402300799 ("9999‑12‑31T23:59:59Z"). > > Anders > > *] > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftest.webpki.org%2Fcsf-lab&data=05%7C02%7CAmaury.Chamayou%40microsoft.com%7Ceaeb732ba1c547e8515208de5092221a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639036785749797878%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=IhOHQ5YbuRVHL47%2FkJH8CAUhrXuUbTmbRPg%2FpAHV%2FUY%3D&reserved=0<https://test.webpki.org/csf-lab> > > _______________________________________________ > COSE mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
