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

[Joe Hildebrand <[e-mail]>]

This is close for me.  I'd like one more bit, which is that protocol designers can decide whether their protocol *requires* a checking decoder.  I agree that checking should not be the default.

— 
Joe Hildebrand

> On Aug 31, 2026, at 3:19 PM, Laurence Lundblade <[e-mail]> 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.
> 
> 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.
> 
>