Subject: [Rats] Tagging CBOR objects

From: Anders Rundgren <[email-masked]>
Date: Sat, 5 Feb 2022 09:50:34 +0100

Hi List,
This posting is related (but not limited to) the EAT media type discussion.

In ancient times XML schema and namespaces were used to qualify object types.

With JSON we lost the namespace but as always "nature finds a way", and for example the JSON-LD and Verified Credential folks have settled on using a dedicated "@context" key as a workaround:
   {
      "@context": "https://example.com/myobject",
       ... Actual object
   }

Using CBOR you get another method through the use of tags:
https://www.rfc-editor.org/rfc/rfc8949.html#name-tagging-of-items

Although working, this is less flexible than namespaces and @context.

So I'm thinking about defining a universal object type tag as an alternative to inventing and registering new tags to signal a specific object type.  Such a tag would work equally well for standards like EAT as for proprietary solutions.

The tag would enclose a CBOR object in its entirety:

    nnn("https://example.com/myobject", any valid CBOR object)

That is, the tag would be an array with two elements like big float.

WDYT?

Thanx,
Anders

---

From: "Smith, Ned" <[email-masked]>
Date: Sun, 6 Feb 2022 23:24:59 +0000

I assume the current form  nnn(any valid CBOR object) defaults to IANA as the @Context value where nnn is in the CBOR registry in IANA?

________________________________________
From: RATS <[email-masked]> on behalf of Anders Rundgren <[email-masked]>
Sent: Saturday, February 5, 2022 12:50 AM
To: [email-masked]
Subject: [Rats] Tagging CBOR objects

Hi List,

WDYT?

Thanx,
Anders

_______________________________________________
RATS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rats

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 7 Feb 2022 07:33:41 +0100

> I assume the current form  nnn(any valid CBOR object) defaults to IANA as the @Context value where nnn is in the CBOR registry in IANA?

Hi Ned,

I'm not sure I understood the question but yes, "nnn" would be a new IANA CBOR tag definition.

Since I haven't kept up with EAT, I took a short peek at the current draft.  There I found two things related to my bare bones proposal.

There is a CBOR tag like 601() identifying data as an EAT object.  In addition there there is a "profile-name" holding an URI or OID presumably identifying the actual content.

Although perfectly workable, this kind of solution is very specific which is something I would like to avoid (if possible).  Applied to EAT the proposed solution would be combination like this:

   nnn([<profile name>,<EAT data>])

Unless something like this is of no interest, I'm considering (for my own work...) to adopt a variant of the solution used by JSON-LD/Verified Credential which translated to CBOR
could be a top-level map key with the value 0 as the holder of the object type identifier:

   {
     0: "https://example.com/myobject",
     ... the actual object
   }

It is undoubtedly a bit ugly but it doesn't seem to break CWT :)  Using "@context" is also a viable alternative.

BTW, the recent thread about an "EAT media type", indicates that there are unresolved issues regarding EAT object type identification. I must admit that I don't understand why a URI/OID wouldn't be sufficient.  Using the proposed scheme a single end-point could dispatch any number of registered object types to the appropriate decoder/processor.

Cheers,
Anders

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 7 Feb 2022 09:24:40 -0800

Hi Anders,

I think your proposal for nnn(context, object) should be on the CBOR list, not here on RATS, because it is a general addition to CBOR for use beyond EAT. I think it’s the CBOR people you need to convince.

There is no tag specifically for EAT. Tag TBD601 is for UCCS, one of the forms of an EAT, the unsigned version of CWT (which is tag 61). The EAT document also registers tag TBD602 for the Detached EAT Bundle, another form of an EAT.

From an implementation point of view for small devices that might need to decode this, I think it’s better use a tag or a media type rather than something inside the object. If it’s inside the object, then you have to decode the object to dispatch to to the write decoder. Your nnn(context, object) does that. So does a tag (or a media type).

LL

> On Feb 6, 2022, at 10:33 PM, Anders Rundgren <[email-masked]> wrote:
>

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 8 Feb 2022 07:05:29 +0100

> Hi Anders,

Hi Laurence,
comments-in-line.

> I think your proposal for nnn(context, object) should be on the CBOR list, not here on RATS, because it is a general addition to CBOR for use beyond EAT. I think it’s the CBOR people you need to co…

That is of course correct.  However, the lack of consensus on how to identify evolving EAT objects made me believe that EAT maybe could serve as a starting point.  Developing stuff in "pure vacuum" is not very tempting.

> There is no tag specifically for EAT. Tag TBD601 is for UCCS, one of the forms of an EAT, the unsigned version of CWT (which is tag 61). The EAT document also registers tag TBD602 for the Detached…

How about profile-name?  Is that mainly for completeness or does it actually fill a purpose?

>  From an implementation point of view for small devices that might need to decode this, I think it’s better use a tag or a media type rather than something inside the object. If it’s inside the obj…

The idea (which has plenty of precursors), is to identify CBOR-formatted objects through a single top-level object type which if you use OIDs would add something like 10-15 bytes.  Since the proposed tag is intended to be universal, the media type would simply be "application/cbor".

An additional feature of self-contained typing schemes is that they permit objects to embed other potentially variant objects in a structured and interoperable way.

If you applied this to EAT, TBD601 & friends, profile-name, and "application/cwt" would be dropped.

This would indeed be a rather radical change so I don't expect any hoorays :) Maybe you could give it a thought before dismissing it?

The (IMO rather messy) alternative is probably that some future EAT developers take the media type extension route while others define new tags.  Yet another bunch may rely on content-sniffing or hope that "Postel's principle" still is valid.

Thanx,
Anders

Example:
https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat-11#appendix-A.1

Here with an OID "0.9.2342.19200300.100.1.48"

TBD122([/ object id / h'0992268993f22c640130', {
        / nonce /           10: h'948f8860d13a463e',
        / security-level /  14: 3, / secure-restricted /
        / secure-boot /     15: true,
        / debug-status /    16: 2, / disabled-since-boot /
        / manfests /        35: [
                                   / This is byte-string wrapped      /
                                   / payload CoSWID. It gives the TEE /
                                   / software name, the version and   /
                                   / the  name of the file it is in.  /
                                   h'da53574944a60064336132340c01016b
                                     41636d6520544545204f530d65332e31
                                     2e340282a2181f6b41636d6520544545
                                     204f53182101a2181f6b41636d652054
                                     4545204f5318210206a111a118186e61
                                     636d655f7465655f332e657865'
                            ]
}])

D8 7A                                   # tag(122)
    82                                   # array(2)
       4A                                # bytes(10)
          0992268993F22C640130           # "\t\x92&\x89\x93\xF2,d\u00010"
       A5                                # map(5)
          0A                             # unsigned(10)
          48                             # bytes(8)
             948F8860D13A463E            # "\x94\x8F\x88`\xD1:F>"
          0E                             # unsigned(14)
          03                             # unsigned(3)
          0F                             # unsigned(15)
          F5                             # primitive(21)
          10                             # unsigned(16)
          02                             # unsigned(2)
          18 23                          # unsigned(35)
          81                             # array(1)
             58 4D                       # bytes(77)
                DA53574944A60064336132340C01016B41636D6520544545204F530D65332E312E340282A2181F6B41636D6520544545204F53182101A2181F6B41636D652054636D655F7465655F332E657865 # "\xDASWID\xA6\u0000d3a24\f\u0001\u0001kAcme TEE OS\re3.1.4\u0002\x82\xA2\u0018\u001FkAcme TEE OS\u0018!\u0001\xA2\u0018\u001FkAcme Tcme_tee_3.exe"