[Cbor] Re: Soliciting unresolved points around dCBOR

[Christian Amsüss <[e-mail]>]

On Mon, Jun 17, 2024 at 02:48:34PM +0200, Anders Rundgren wrote:
> To get any further, the dCBOR advocates should provide a simple
> example showing a Gordian-like operation that fails using CDE "as is".

That may be a useful exercise indeed.

To my understanding, the goal of using deterministic CBOR encodings in
the first place is to ensure that consumers can ingest Gordian data,
store them in their native format by value, and re-encode Gordian to get
bit-identical data for cryptographic purposes.

(Were there not the aspect of independent storage, we wouldn't need even
deterministic encoding, but could just always reuse the original
encoding for verification.)

Numeric reduction comes into play when different parties use different
data types internally. No matter whether it is a database with a u64
column or a database with a f32 column, if both receive the array [1, 1,
2, 3, 5], store it and re-serialize, they wind up with the same data.
This is what I understand the desired benefit of numeric reduction to
be.

Now I still do not agree with the design of such a system: Since by
design the semantics of array doesn't include typing information
(otherwise the application could tell the serializer whether it's floats
or ints), the collaboration of the u64 and the f32 tool will work until
it fails when a value is produced that is not understood by one of them
(at which point that party can't ingest the data any more). I'd prefer
to have arrays (or other fields) with clear semantics that fail on
general mismatch and then are guaranteed to succeed at runtime.

But to the best of my understanding, such a design is what (correctly,
albeit on to me undesirable premises) motivates numeric reduction.

BR
c (once more, chair hat off)

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom