On 2026-01-09 13:24, Carsten Bormann wrote:
On 2026-01-09, at 09:56, 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.
(That is an unwise implementation decision, in particular on a platform that
already has the support for unlimited precision numbers and does need it from
2**53 upwards anyway.
I hope you don’t come here to summon support for such an unwise decision.)
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.
Well, I’m not in the business of making promises for IANA, but I do believe
designated experts would be wary about registrations that appear not to be made
with the intention of obtaining interoperability.
There is absolutely no point of going to an upper limit of a range available
for registration, so this problem will never occur for genuine registrations.
Now you are contradicting yourself:
https://mailarchive.ietf.org/arch/msg/cbor/blg0wyam6tYJFoZZT_t_wu07_qE/
"In this specific case, this is not a problem, as the valid values are
controlled by a registry and the DEs won’t register a value outside
of int64 (or even outside of smint53).
(Yes, you could use a private use value that is outside of int64;
more power to the strong CBOR-fu your private deployment will exhibit then
:-)
BTW, my CBOR implementations does not impose any particular limits on integers, but
specific "int65" support does IMO not make much sense:
https://cyberphone.github.io/CBOR.js/doc/index.html#jsnumbers.int
Anders
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.
Here we are in the area of data validation.
A COSE signature that claims to have been issued (iat=) on January 9 1939 will
fail any decent data validation, as should an iat= of January 9 4711.
Different implementations will have different policies about their concept of
the beginning of time or the maximum likely clock skew, but, again, we are
widely outside representation issues here.
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://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
Unwise.
int32 (the name int32 = -0x80000000 .. 0x7FFFFFFF recently became popular in
the CBOR WG) probably won’t hurt, but encouraging implementations to impose
arbitrary limits out of thin air (*) creates a thicket of interoperability
obstacles.
while limiting "iat" to the range defined by the I-D: 0 ("1970‑01‑01T00:00:00Z") to
253402300799 ("9999‑12‑31T23:59:59Z").
In data validation of CWT, I would not accept any iat before the time COSE
existed (first draft was 2015) or after “now” (with some generous, but
plausible, clock skew added).
Each of the claims exp and nbf will have their own data validation rules.
Grüße, Carsten
(*) Some implementers may breathe some way thinner air here — why not fail at
any algorithm outside -100000..100000? For the avoidance of doubt, please
don’t impose arbitrary limitations, but do fail on algorithms that are unknown
or not supported by the key material that your policies allow to be used.
_______________________________________________
COSE mailing list -- [email protected]
To unsubscribe send an email to [email protected]
