Hi Mike, On 14. Apr 2025, at 02:47, Michael Jones <[email protected]> wrote: > > I agree with Orie's and Mike P.'s earlier comments. We should steer > completely clear of any form of canonicalization, because of the > complications and interop problems that it causes.
This went to both CBOR and COSE, so my question is: Who is “we”? For COSE, I’d probably agree with the general sentiment, but not because of deterministic encoding. (COSE does use a form of deterministic encoding [1] to derive its signing/MACing inputs, but here we got a choice to design the input so that becomes totally non-problematic. COSE key thumbprint uses a more complete of deterministic encoding constraints [2]; we should not have done that if we’d be following your rule.) For CBOR, certainly not. A good approach to deterministic encoding has been part of CBOR from the start. (If you are serious about doing something that requires deterministic encoding, CBOR is a rather good choice, without introducing the problems that plague the text-based data representation formats.) Embedded signatures require more than deterministic encoding (and, strictly speaking, not even that): They require transforms for embedding and then erasing the signature(s), and that’s where there are “interesting" problems. Signing (or digesting!) data at rest requires a good dose of ALDR rules plus deterministic encoding to derive the signing/digesting inputs from the data at rest; CBOR has the deterministic encoding covered for you if you want to tackle that problem area [and you may never need to see actual CBOR-encoded data on the wire]. Grüße, Carsten [1]: https://www.rfc-editor.org/rfc/rfc9052#name-cbor-encoding-restrictions [2]: https://www.rfc-editor.org/rfc/rfc9679.html#name-cose-key-thumbprint _______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
