Re: [Secdispatch] Comments on draft-jordan-jws-ct-04.txt

[Carsten Bormann <[e-mail]>]

On 2021-07-27, at 17:08, Anders Rundgren <[e-mail]> wrote:
> 
> Another action could be to consider co-creating(!) an "I-CBOR" profile that would not only address documented CBOR interoperability issues for normal data exchange [1], but also make CBOR usable in cryptographic contexts without necessary embedding data-to-signed in bstr like COSE.

[Not in citation given.]

[1] discusses a case where, in two unimplemented extensions, application developers wanted to ship floating point values in the specific format they happen to have them.  That would have been fine, but it means there would have been a deviation from 4.2.1.  4.2.1 *is* the interoperable set of deterministic encoding rules; deviations are explicitly allowed, but indeed mean a deviation.

And then there is the old “canonical” encoding from 7049 that is described in 4.2.3 of 8949.  We are genuinely sorry about that, that was a design that got sufficient negative feedback from implementers over the years that we decided to upgrade it by providing a preferred deterministic serialization as well.  So I currently have exactly two implementations: cbor-canonical, which implements 7049’s old “canonical" serialization, and cbor-deterministic, which implements 8949’s deterministic serialization.  They are 44 lines each (and don’t differ much, obviously).  In my case, I can’t even implement “in the specific format I happen to have”, because I don’t have floating point values in specific formats; if this is ever needed, this could be supported by adding new application types for these formats, of course.

Grüße, Carsten