[Cbor] Proposal for Deterministic CBOR (dCBOR) discussion at May 17th meeting

[Christopher Allen <[e-mail]>]

Re:

> CBOR one-hour Wednesday meeting on 17 May, at 14:00 UTC (16:00 CET).
>
> Information for this meeting is here:
> https://datatracker.ietf.org/meeting/interim-2023-cbor-08/session/cbor
>
 Dear CBOR Working Group Members,

We would like to propose an agenda for the upcoming CBOR meeting on the
17th to discuss certain issues related to dCBOR. We aim to be as
collaborative as possible and would like to discuss the pros and cons of
each issue in order to foster a productive discussion. It should be noted
that nothing in our proposal affects the CBOR RFC or the ways that CBOR is
commonly used in any way.

— Christopher Allen & Wolf McNally


# Proposed Agenda: Deterministic CBOR (dCBOR) Proposal

The recent update to the dCBOR Internet-Draft is the subject of this agenda:

https://www.ietf.org/archive/id/draft-mcnally-deterministic-cbor-01.html

Some of this draft is a restatement of what’s in the RFC as
recommendations, but making its deterministic factors requirements. Other
issues raised by the draft have been a subject of discussion. Our aim is to
reach a consensus on these issues.

## Numerical Reduction

Proposal: All numbers MUST be reduced to the smallest possible
representation. Failure to do so is a well-formness error.

Pros:

* Deterministic
* Generally smaller representation
* Not hard to implement (we already have reference implementations in Swift
and Rust)
* Support for larger numbers (e.g., BIGNUM) is allowed but not required
* Directly compatible with languages like Javascript and Ruby that have a
generic number type
* Generally removes cognitive load from the programmer
* Useful for Gordian Envelope and other protocols requiring determinism
* Can be ignored by other protocols that do not care about determinism

Cons:

* The current recommendations for "deterministic" encoding in the RFC do
not have the above requirements, and therefore CBOR encoded with only the
recommendations in the RFC will not necessarily conform to the requirements
for dCBOR.
* This includes the reference implementation at https://cbor.me and the
Java package at org.webpki.cbor.
   * Though all dCBOR must be CBOR; we do not believe the converse is true,
which may reduce this issue.
* Some integer values (such as 1099511627775 [0xffffffffff]) can actually
be larger than BIGNUM equivalents!

Alternative: The alternative would be to mandate that floats remain
unchanged, which trends away from the suggestions in §4.2 of RFC 8949 for
moving data to the shortest encoding possible and has the possibility of
damaging determinism, but which matches some current implementations:
   * Floats MUST be maintained as Floats, but otherwise all numbers MUST be
reduced to the smallest possible representation. Failure to do so is a
well-formness error.

## Adding dCBOR Support to Flagship Implementations and Tools

Proposal: Add a "deterministic" flag to existing implementations and tools
such as https://cbor.me and QCBOR.

Pros:

* Would encourage dCBOR adoption
* Would enable such tools to be be used by developers of protocols
requiring determinism, including Gordian Envelope
* Would not invalidate other CBOR implementations
* Would be opt-in, and so transparent to existing users and protocols that
do not care about determinism

Cons:

* Requires work to implement, test, document, and maintain

## Bringing the dCBOR specification under purview of the CBOR Working Group
and putting it on a track to RFC status.

Pros:

* Would be in line with the recommendation of IETF Dispatch.
* Would benefit the entire CBOR community.

Cons:

* Would require active participation from the CBOR WG.