Subject: [Cbor] Tag validity: embedded MIME vs. embedded CBOR

From: Carsten Bormann <[email-masked]>
Date: Wed, 3 Jul 2019 06:24:17 +0200

In 7049bis -06, there are several embedded formats that can be tagged.
Quoting:

* Tag 36 is for MIME messages (including all headers), as defined in
  {{RFC2045}}. A text string that isn't a valid MIME message is
  invalid.

[…]

Tag 24 (CBOR data item) can be used to tag the
embedded byte string as a data item encoded in CBOR format.  Contained
items that aren't byte strings are invalid.  Any contained byte string
is valid, even if it encodes an invalid or ill-formed CBOR item.

What is our position on embedded formats?  Why is MIME validity-checked and CBOR not?  I would expect a consistent answer here, one that also can guide new tag definitions.

Given that Tag validity checking is optional in a generic decoder (which we still need to properly write up; currently only the security considerations are clear about that), we can be a bit strict on the definition of validity here:  I’m leaning towards making CBOR well-formedness (or validity?) a prerequisite of tag 24 validity.

(Now https://github.com/cbor-wg/CBORbis/issues/86 .)

Grüße, Carsten

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 3 Jul 2019 17:04:11 +1200

> What is our position on embedded formats?  Why is MIME validity-checked and CBOR not?  I would expect a consistent answer here, one that also can guide new tag definitions.

However, Tag 24 is always going to be a slightly special case, isn't it? A CBOR implementation is surely able to check whether the embedded CBOR is valid. But a validator for some other embedded format may not even be available in a particular implementation.

> Given that Tag validity checking is optional in a generic decoder (which we still need to properly write up; currently only the security considerations are clear about that), we can be a bit strict…

Looking at the code I wrote for Tag 24 encoded values in GRASP objectives, I see that I effectively enforced that rule at the encoding stage, to avoid the risk of an exception at the decoding stage. So I think I agree with you.

   Brian

> _______________________________________________
> CBOR mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cbor
>