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

[Laurence Lundblade <[e-mail]>]

> On Mar 6, 2023, at 12:45 PM, Carsten Bormann <[e-mail]> wrote:
> 
> On 2023-03-06, at 19:22, Laurence Lundblade <[e-mail]> wrote:
>> 
>> Here’s a simple protocol to show that deterministic CBOR serialization is not required for signing.
> 
> A significant design decision of COSE was not to require onerous forms of deterministic CBOR to compute the signing input — for the subset of CBOR used for that, preferred encoding is sufficient.  Note that for this subset, preferred encoding *is* deterministic encoding.
> 
> Of course, you can compute the signing input using some other form, but why would you?  Preferred encoding is already available to you and its use reduces the attack surface.
> 
> Of course, if the signing input is generated (e.g., from data at rest) in a more complicated way than COSE does, full deterministic encoding can be useful.

Maybe the misunderstanding here is cleared by this distinction?

1) Signing input to the final signing algorithm (e.g. ECDSA+Hash, EdDSA,...) — the Sig_structure. It is deterministically serialized because the sender and receiver serialize it independently. It is never transmitted. This is internal to the design of COSE, is all good and well and is only of consequence to implementors of COSE internals (like me).

2) The COSE_Sign payload — This doesn’t have to be serialized in any particular way, doesn’t have to be well formed and doesn’t even have to be CBOR. It is transmitted so the receiver has exactly what the sender had. This is what my temperature sensor example was about.

Maybe you are talking about 1) and I’m talking about 2)?


To go further and kind of wrap the discussion around in a weird way, it seems to be the dCBOR folks are talking about payload as in 2), BUT they have situations where they payload bytes are not transmitted like 1).

LL