Subject: [Cose] msg_type

From: Carsten Bormann <[email-masked]>
Date: Wed, 01 Jul 2015 09:20:52 +0200

In the current draft, top-level entities have a field called msg_type.

When we moved back to maps (did that ever really get decided?), that
created one implementation inconvenience:  Since CBOR (as with JSON)
does not define the sequence of entries in a map, the msg_type can occur
anywhere in the map.  Such as at the end.

I'm again proposing to get rid of msg_type.

In many applications, the msg_type will be known from context.
(Since msg_type is not protected, there is no security value to having
it either.)
In the other applications, we would be better of with CBOR tags for the
types: These always occur before the data structure being tagged.
(If they are taken from the specification required space, the tags take
exactly the two bytes a msg_type field would take.)

One nice side effect would be that the top-level encrypt structure looks
exactly like the structure for one recipient, which might save some code
(and makes the spec look so much better ;-).

Grüße, Carsten

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 1 Jul 2015 11:28:10 -0700

> -----Original Message-----
> From: Cose [mailto:[email-masked]] On Behalf Of Carsten Bormann
> Sent: Wednesday, July 01, 2015 12:21 AM
> To: [email-masked]
> Subject: [Cose] msg_type
> 

The sense of the mailing list was to move to maps.  I am still trying to work out some better arguments for going back to arrays as I feel it is a cleaner structure.  I am trying to figure out how much of my current implementation experience is based on language/library vs the difference in the COSE structure.

Jim

> (Since msg_type is not protected, there is no security value to having it
> either.) In the other applications, we would be better of with CBOR tags for
> the
> _______________________________________________
> Cose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cose