[Cbor] Re: Working Group Last Call on Serialization draft

[Anders Rundgren <[e-mail]>]

On 2026-08-31 22:19, Laurence Lundblade wrote:
> Joe, I don’t quite get what you are after here yet. Which sections are inadequate?
> 
> I am thinking of adding this text to the decoder requirements for both preferred-plus and deterministic:
> 
>     The above requirements are what the decoder MUST accept. A decoder complying to these requirements can also accept other well-formed serializations if it is being liberal in what it accepts. If a decoder chooses to accept only these requirements, then it is a “checking decoder” as described in appendix H.
> 
> I don’t think any CBOR library should default to a checking decoder. It should be a mode that is selectable when and end-end protocol specifies it, or a particular deployment wants it.

This is where it (IMO) gets wrong.  Wolf's dCBOR decoders as well as my CBOR::Core decoders are checking.  In the CBOR::Core case there is also an option for accepting non-deterministically encoded objects, not for being "liberal" à la Postel, but to cope with "legacy" CBOR.

The same goes for non-trivial NaNs.  That non-trival NaNs are permitted in some modes and outlawed in other modes seems like an "opinion". An implementation could (like CBOR::Core), equally well support a common policy for all modes it supports.

However, since the WG seems hellbent on creating "The Ultimate Guide to CBOR Serialization, Library Implementation, and Application/Protocol Design", I guess this is as good as it gets.

Note: these remarks are "for the record" only.  Publishing may proceed.

Anders

> 
> It’s never an input validation security issue. Non-checking decoders must do bullet-proof input validation.
> 
> LL
> 
> 
>> On Aug 18, 2026, at 12:05 PM, Joe Hildebrand <[e-mail]> wrote:
>>
>> - (most important) Make it clear in each section whether the rules apply to encoders or decoders.
>> - Make it clear that it is up to the protocol designer what to do when decoding inputs that are not in the expected encoding. This is good for protocols where encoding errors (attacks?) might have security consequences.  A couple of examples or criteria could help protocol designers decide.  There is some text in appendix H but it isn't directive enough.
>> - Make a note that even if the protocol designer did not specify that checking should be done, it may make sense to check on inputs on non-constrained devices to increase the likelihood of finding encoding errors before crashing constrained devices.
> 
> 
> _______________________________________________
> CBOR mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]