Anders, > On Apr 13, 2025, at 3:18 PM, Anders Rundgren <[email protected]> > wrote: > > On 2025-04-13 20:40, Michael Prorock wrote: >> Very big +1 to Orie > > dCBOR (featuring Carsten Bormann and Laurence Lundblade as co-editors), was > explicitly designed to support cryptographic operations. dCBOR accomplishes > this through deterministic encoding which is not the same as canonicalization. > > Unlike canonicalization, deterministic encoding is trivial, a mere 300 lines > of JavaScript is needed for a full-blown CBOR encoder: > https://github.com/cyberphone/simple-cbor-encoder.js/blob/main/cde.js
I have to correct you again: dCBOR was designed to support determinism (the goal) at its level of abstraction by *canonicalization* (the method) of a number of common but fraught sources of indeterminism, including the ordering of “orderless” items like map keys, the representation of common numerical values, the normalization of UTF-8 strings, and constraining ill-defined concepts like NaNs. It does this by both *requiring* and *enforcing* certain constraints on what is acceptable. However, as I have always maintained, determinism as a goal is *never* “trivial" and must be supported at every level for applications that require it (consensus algorithms and secure/verifiable documents being two clear use cases). If you want to distinguish “canonicalization” from “determinism” and call one hard and the other easy, then you are going to have to clarify your terms and not introduce ambiguity through vagueness or conflation. Our position is that whatever terminology you adopt, determinism is a nontrivial goal, and requires careful, layered support for applications that require it. Since this was also directed to the COSE list, I recommend that if any of the participants there have questions about dCBOR, they direct them to myself or the other co-authors of the specification. ~ Wolf _______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
