Mandatory map fields not enforced?

[yaronf]

I have this CBOR (diag notation):

{1: 65535, 2: h'1122334455', 3: 6, }

It validates successfully with this CDDL:

var_header = {
        K_KEY_PROVIDER: uint,
        K_KEY_ID: bstr,
        ? K_KEY_VERSION: uint,
        ? K_AUX_DATA: bstr,
        ? K_NONCE : bstr,
        ? K_AUTH_TAG : bstr,
        ? K_AAD : bstr,
        *uint => any ; extensions
}

K_RESERVED = 0
K_KEY_PROVIDER = 1
K_KEY_ID = 2
K_KEY_VERSION = 3
K_AUX_DATA = 4
K_NONCE = 5
K_AUTH_TAG = 6
K_AAD = 7
        ; extend here

According to @cabo my CDDL is incorrect because it translates to textual, rather than integer, map keys, e.g. "K_NONCE" and not 5. My file is accepted because of the "extensions" line. However it should have failed validation anyway, because the first two fields (K_KEY_PROVIDER and K_KEY_ID) are mandatory in the schema, but missing from the CBOR file.

[yaronf]

Closing: not a bug. I corrected the CDDL to:

var_header = {
	K_KEY_PROVIDER => uint,
	K_KEY_ID => bstr,
	? K_KEY_VERSION => uint,
	? K_AUX_DATA => bstr,
	? K_NONCE  => bstr,
	? K_AUTH_TAG  => bstr,
	? K_AAD  => bstr,
	*uint => any ; extensions
}

K_RESERVED = 0
K_KEY_PROVIDER = 1
K_KEY_ID = 2
K_KEY_VERSION = 3
K_AUX_DATA = 4
K_NONCE = 5
K_AUTH_TAG = 6
K_AAD = 7
	; extend here

And everything works fine, including detection of mandatory fields.

[cabo]

The initial instance still should not validate with the initial CDDL, as the mandatory members are not present:

    K_KEY_PROVIDER: uint,
    K_KEY_ID: bstr,

(The rest of the behavior is fine, as Yaron mentioned.)

[cabo]

(hmm, can't reopen the issue.)

[anweiss]

Per #84 (comment), this is indeed still a bug. Will fix.

[yaronf]

Sorry, you didn't include any test cases in the PR, and I'm unable to generate any cases where the behavior is changed for the CBOR above and various variants. Specifically, the mandatory members are actually present in the CBOR at the top of this issue. Could you please include an example?

[anweiss]

@yaronf my apologies. Merging the PR auto closed the issue. This will be introduced into v0.8.7 of the CLI. Will update the docs and release notes.

var_header = {
        K_KEY_PROVIDER: uint,
        K_KEY_ID: bstr,
        ? K_KEY_VERSION: uint,
        ? K_AUX_DATA: bstr,
        ? K_NONCE : bstr,
        ? K_AUTH_TAG : bstr,
        ? K_AAD : bstr,
        *uint => any ; extensions
}

K_RESERVED = 0
K_KEY_PROVIDER = 1
K_KEY_ID = 2
K_KEY_VERSION = 3
K_AUX_DATA = 4
K_NONCE = 5
K_AUTH_TAG = 6
K_AAD = 7

should now validate the following:

{"K_KEY_PROVIDER": 65535, "K_KEY_ID": h'1122334455', "K_KEY_VERSION": 6, }

and this will now be denoted as invalid:

{1: 65535, 2: h'1122334455', 3: 6, }

The colon shortcut notation validates the map keys based on their text representation. When used with the double arrow notation, the keys are resolved to the type rules. Prior to merging #86, the CBOR validation implementation in the tool was not properly interpreting the colon shortcut notation.

[yaronf]

Yes, thank you. Agree. Though I had to read the RFC and two of its appendices quite thoroughly to get myself convinced. (Also IMHO this "syntactic sugar" is more pain than it's worth.)

[anweiss]

lol, yea I can't tell you how many times I've read through the RFC since I started this project a few years ago and I STILL misinterpret something.

[cabo]

On 2021-01-27, at 23:54, Yaron Sheffer ***@***.***> wrote: (Also IMHO this "syntactic sugar" is more pain than it's worth.)

This ticket may not be the place to argue that, but I’d say: It depends. For your typical JSON spec, it does make a difference in the noise factor. See https://tools.ietf.org/html/rfc8610#appendix-H for an example. For specs with CBOR integer labels like the one we are discussing here, it is indeed another thing that one needs to learn not to stumble over. Grüße, Carsten