So, back in the day when a lot of signed content was text format, we needed canonicalization to make sure the receiver could reconstruct exactly what was sent after transformations in transit. We worried about line folding, line ending, character sets and such. In the binary CBOR world, we don’t have to worry about that at all. Yay! Transports that move CBOR around never do anything to what they carry. If they did things to what they carry, they probably wouldn’t work at all for CBOR.
So deterministic encoding (formally known as canonical encoding) is not required for signed payloads. COSE doesn’t require CDE or such for payloads. No CBOR signing format needs determinism or canonicalization for the payload. The use cases where CDE determinism is needed is when the signed data is *not* transmitted, but instead independently constructed by the sender and receiver. This is very rare. Also, note that CDE has been around since RFC 8949 (and as canonical encoding since RFC 7049). The new draft is just a clarification. LL > On Aug 19, 2024, at 12:20 AM, Anders Rundgren <[email protected]> > wrote: > > As you may know, the IETF is about to standardize Deterministically Encoded > CBOR: > https://datatracker.ietf.org/doc/draft-ietf-cbor-cde/ > > Although not a part of the plot, CBOR CDE enables signatures schemes which > are much simpler than COSE and preserves the original message structure. You > can try it on-line without any software installations: > https://test.webpki.org/csf-lab/home > > The primary target is the EU Identity Wallet when used for payments, but it > can of course be used everywhere where "signed CBOR" is requested. > > Anders > https://github.com/cyberphone/cbor-everywhere?tab=readme-ov-file#cryptographic-operations > > > _______________________________________________ > COSE mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
