Re: [Cbor] Deterministic CBOR as a possible DISPATCH item

[Laurence Lundblade <[e-mail]>]

> On Mar 5, 2023, at 5:29 AM, Carsten Bormann <[e-mail]> wrote:
> 
>> Determinism is one such good practice when it comes to creating cryptographically enhanced documents.
> 
> Determinism is mostly unneeded in interchanged data items.
> (It is needed for signing inputs, which are therefore best designed to make determinism inexpensive.)
> It still is nice to have, e.g., for test scripts.

I don’t think determinism is required for signing.

When the signed data is transmitted with the signature, then the receiver has the exact bytes that were signed and can verify the signature. For example, determinism is not needed for COSE_Sign payloads.

There are a few rare cases where determinism is needed for signing:

1) The signed data data is not transmitted. It is instead constructed separately by the sender when signing and the receiver when verifying. The Sig_structure internal to COSE is an example of this.

2) The data is transformed in transmit. An example of this email signing like S/MIME because the old email protocols are text-based and change line endings and such. Both the sender and receiver have to be able to construct the same canonical representation because you can’t rely on the transport to not change it. I don’t think this happens when CBOR is transmitted.

So to me, CBOR determinism is technically only needed in rare circumstances.


All that said, I can still see why it might be good to have something like dCBOR standardized in a way that 8949 doesn’t. Sometimes it is nice to be able to do a binary comparison of two encoded structures.The variability in CBOR serialization does seem to cause a lot of discussion and confusion (e.g., in work on EAT). Because of the variability, there isn’t guaranteed interoperability between CBOR implementations. I’d speculate that this is slowing the adoption of CBOR.

I recall always preferring DER to BER, but that was mostly because the difference was confusing, I needed to get my code working quickly and I didn’t want to take the time to understand what it was about and what I’d need to do to support BER in my code.

Another thing here is that the use cases where the CBOR serialization variations are needed are rare and implementing deterministic encoding is not that hard, though sorting map keys can require some memory.

Also, I agree that we want to be strict these days — Postel was wrong <https://datatracker.ietf.org/doc/html/draft-thomson-postel-was-wrong-03>.

LL


P.S. I am not opposed to fixing QCBOR encoding of subnormals. I just have been working on other things. Note also that QCBOR doesn’t use floating point for half-precision, so the fix is a bit more work.