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

[Laurence Lundblade <[e-mail]>]

I think RFC 8949 presents the idea of a [Generic Decoder] that accepts all serializations, but never a checking decoder. A checking decoder in RFC 8949 would be for either preferred serialization or [Section 4.2.1 deterministic].

It’s fine for something new and narrow like dCBOR or CBOR::Core to say that all decoders are checking decoders.

In theory, we could say that all preferred-plus and deterministic decoders must be checking decoders. In a way, it would be simpler to understand because the difference, which is subtle, would be eliminated. We would not be having this discussion at all.

I’ve not gone that direction because it is less aligned with RFC 8949, preferred serialization, and most decoder implementations. For example, most will accept all five serializations of the integer 1. A checking decoder for deterministic also adds a fair bit of code (on a constrained device) to check the sort order. 

LL

[Generic Decoder]: https://www.rfc-editor.org/rfc/rfc8949.html#name-generic-encoders-and-decode
[[Section 4.2.1 deterministic]: https://www.rfc-editor.org/rfc/rfc8949.html#name-core-deterministic-encoding



> On Aug 31, 2026, at 11:08 PM, Anders Rundgren <[e-mail]> wrote:
> 
> 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]
> 
> _______________________________________________
> CBOR mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]