[Cbor] draft-mcnally-deterministic-cbor: rationale for not going with pre-encoded data (was: Updated Drafts for dCBOR I-D and Gordian Envelope Structured Data Format I-D [...])

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

Hello Wolf, hello Christopher,

this got cut a bit short during today's interim, so taking it to the
list:

On Mon, May 08, 2023 at 10:40:21AM -0700, Christopher Allen wrote:
> The first IETF Internet-Draft, “Gordian dCBOR: Deterministic CBOR
> Implementation Practices,” offers specifications and guidelines for dCBOR
> implementers. You can find the updated version of the draft at the
> following link:
> https://www.ietf.org/archive/id/draft-mcnally-deterministic-cbor-01.html

I'd like to understand (and see explained in the document) why
deterministic encoding is this important for the purpose of signatures
-- given that any verifier of the signature will also at some point have
received the original data to verify. A common pattern (used eg. in
COSE) is to encode the data to be signed in a byte string, and sign over
that. (In the case of partially erasable data, it'd probably be a
nesting of byte strings, but at the level where non-bstr data comes in,
it'd be encoded at least once).

You mentioned some points I didn't get completely:

* It's harder with multi-signatures.

  I don't quite understand how so; at least when reading
  multi-signatures as countersignatures, COSE seems not to have issues
  with it.

* It's known to cause problems with JWT.

  Yes. But JSON is not CBOR -- JSON data can't be used in-place, whereas
  CBOR data is unescaped and can be processed directly. To stick with
  the Rust examples you mentioned, decoding a CBOR data structure that's
  encoded with several times nesting will still allow you to get a
  str reference into data that's in the deepest item without copying.

* People pass data into their graph storage and export out again.

  That's an argument I can understand, but the point above on it not
  being JSON applies as well. While keeping the JSON around would
  roughly duplicating the amount of RAM used, encoded CBOR can share
  much data between a triple store and the originally signed data.

  For example, looking at how CoRAL data might be encoded in such a
  triple store, the creation of the graph tables would primarily verify
  that the CBOR in the document is indeed valid, and then be a table of
  pointers into that data. (Currently CoRAL is described to be
  serialized as a tree. An encoding as triples is being considered, but
  the ordering of the triples would not be lexicographic but following
  some tree walk).

If this was all well thought through, and deterministic encoding is
really the only way to go, I'm all for it -- I'd just like to make sure
the alternatives have been explored, and that that process is
documented.

BR
c

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