Subject: [Cbor] Strict mode

From: Laurence Lundblade <[email-masked]>
Date: Wed, 20 Mar 2019 11:27:00 -0700

Hi again,

So strict mode seems to be the middle of these three:
• well-formed (vs. syntactic error). Not well-formed is now MUST NOT generate/accept.
• valid (vs. semantic error). Protocol encoders now MUST generate valid CBOR.
• expected (vs. unexpected by application). This is application-specific and often expressed in CDDL

I went through the whole CBOR spec and identified almost 20 valid/invalid checks that a decoder could perform. For example, valid UTF-8, tag 1 dates are integer or float, key duplication, base64 uses only allowed base64 characters, MIME data is valid MIME syntax…  Some of these are cheap, easy and obvious. Others are quite expensive and difficult. 

So strict mode seems somewhat of an implied smorgasbord of checks that a generic decoder might perform or not perform. In many cases it will be much cheaper and easier to implement these checks in the next layer up. They might already be there too, so it would be waste for a generic decoder to perform them. For example, a base64 encoder will probably check for allowed base64 characters.

I think it is kind of interesting to describe a CBOR firewall and that such a thing might be useful. I think it is more than strict mode though. It needs to check for well-formed CBOR. If it is generic it should check for as many invalid things as possible. It should also be described as a secondary defense and that the main decoder for a protocol should never rely on it. See section 9.

My thought for the document would be to list all of the almost 20 valid/invalid checks in 4.4 Other Decoding Errors with some discussion on how and when they might be implemented. Then remove mention of the specific valid/invalid checks in 4.11 Strict Mode Decoding. That is kind of duplicate text now. Then make section 4.11 about CBOR Firewalls.

LL