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

[Vadim Goncharov <[e-mail]>]

On Mon, 31 Aug 2026 23:39:28 -0700
Laurence Lundblade <[e-mail]> wrote:

> 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. 

Moreover, the "checking" definition is vague. One could say that checking, if
employed, must be not only for deterministic/preferred parts (or at least
have different [configurable] levels), but be related to equally important for
application things, from tag correctness up to schema conformance. For
example, a decoder might check that tag 32 is really tstr (per IANA registry)
and that contents of this tstr (URL) actually conforms to RFC 3986. This is
not purely theoretical question because some decoders already do automatical
instantiation from tag 32 to e.g. URI::URL native class of platform. But here
be dragons: there can be e.g. 32(simple(0)) for entirely legitimate reason of
CBOR text in question being packed. This is long-standing problem of so called
"stand-in tags" in [cbor-packed], likely out of scope for serialization draft.

Therefore, absence of "MUST" on checking is the right decision (even more code
on non-constrained devices).

> 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]  
> 
> 
> _______________________________________________
> CBOR mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]



-- 
WBR, @nuclight