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. > 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]
