On Jan 9, 2026, at 14:53, Anders Rundgren <[email protected]> wrote: > > 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 > :-)
I am not sure I understand where the contradiction is. In one message I was offering a (pretty solid) prediction for what Designated Experts will do here, in the other I explained why. (Any such contradiction is probably out of scope for the COSE WG.) > BTW, my CBOR implementations does not impose any particular limits on > integers, But you seem to want to impose limits on integers for COSE? I think I said why a partial implementation of COSE that does not support algorithm integer labels beyond int64 is not actually going to create a problem in practice. I also recommended against implementers coming up with unnecessary arbitrary limitations such as int32. > but specific "int65" support does IMO not make much sense: > https://cyberphone.github.io/CBOR.js/doc/index.html#jsnumbers.int This entire table is irrelevant here, as COSE hasn’t been defined with the CDDL names given there. OK, the “Constructor” column is confusing, because you seem to have an API discontinuity at a place where you don’t have any reason to have one (2**63 is not a special number in JavaScript, while 2**53 very much is.) Grüße, Carsten _______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
