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

[Christopher Allen <[e-mail]>]

On Sun, Mar 5, 2023 at 12:58 PM Carsten Bormann <[e-mail]> wrote:

> On 2023-03-05, at 21:10, Laurence Lundblade <[e-mail]> wrote:
> > 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.
>
> If you want to do this, you indeed need deterministic encoding.
> (And, as I said, that is quite useful in test scripts.
> So if you don’t need the performance of simple preferred encoding, go
> ahead and make everything deterministic.)


This is exactly why we are require the 4.2 subset of deterministic CBOR.

Our Gordian Envelope supports a Merkle-like hash-tree encoding for complex
data structures (in particular a variety of graph structures) that are
signable in a form that allows for the issuer to elide/redact, or encrypt,
or externally reference data, or offer a proof-of-inclusion form that
offers herd-privacy to multiple subjects in the same hash-tree.

The verifier can verify the signatures even when some the data is missing.
But before accepting the verification still likely need to confirm some of
the data in portions that are elided. This might be from data they received
before, or by decrypting key portions, or out-of-band another way by a
reference. All three of these the payload must be recreated by the verifier
(based on their business requirements) and then confirmed against the
signature.

Thus our requirement for deterministic CBOR. The verifier (not the issuer)
may be storing the data to be confirmed against the signer data. They might
store it locally slightly differently, such as different number forms,
key-pair mapping strategies, and other ambiguity in ordering from the way
the issuer stored it.

We believe that a solution that supports these features will be essential
for modern privacy, as it supports EU and ISO principles for data
minimization, enables Progessive Trust (
https://www.blockchaincommons.com/musings/musings-progressive-trust/)
and Selective
Disclosure (
https://www.blockchaincommons.com/musings/musings-data-minimization/) &
Least Authority architectures, and makes meeting requirements of GDPR and
other privacy standards easier.

Gordian Envelope proves that these features are possible, and we know that
ISO mDOC (used for mobile drivers licenses) is also adding hash-list-based
selective disclosurefor similar reasons that we do (and is using CBOR as
well). We are open to changes to Gordian Envelope, or switch to adopt a
better standard, providing that they can meet our elision privacy
requirements.

Besides our intro article about Gordian Envelope (
https://www.blockchaincommons.com/introduction/Envelope-Intro/) you might
find our docs (and videos) on Elision and Proofs of Inclusion useful:
https://github.com/BlockchainCommons/Gordian/tree/master/Envelope

Our internet-draft is at
https://datatracker.ietf.org/doc/draft-mcnally-envelope/ and we are
planning to update it to -01 this week based on feedback received to date.

We would love to see the CBOR community consider taking this work item up.

In the meantime, what is required to get it added to the list of “related
drafts” section of this CBOR group?

— Christopher Allen