Subject: Re: [COSE] Assigning CBOR tags to key structures

From: Renzo Navas <[email-masked]>
Date: Fri, 7 Apr 2017 10:33:45 +0200

Hi all!
Sorry to revive this 1 and half year old topic.

In the end we finally have no CBOR Tag for COSE_Key and COSE_KeySet, I
could not find at IANA (nor on the cose rev 24 document) :(
Was it discarded at the end, why? or there is a chance to still get
the tag at IANA?

Regards !

Renzo

------------

PS: some more details of why this can be useful follow:

More details on the Use Case: transporting a symmetric key with
COSE_Key , it has to be protected, so wrapped on an Encrypt0 message
(Tag 16);
Would be nice have a tag to identify that the payload is a Cose_key
object; it is true at the moment I can design the app to always expect
a keyobjet as the payload of an encrypt0 ... ; but I'm cutting
flexibility, or we can design a custom cbor structure, but we are
loosing on interoperability.
I have a coap server, with limited ram, and I have actually size only
for for two coap resources, so I can see I will have to overload some
functionality of this resource, particularly this is a sort of
"/authz-info" ace resource, that I will use to do authenticated key
establishment (oauth pop token provisioning), and other stuff, so
probably quite overloaded.

On Sun, Oct 11, 2015 at 8:22 PM, Jim Schaad <[email-masked]> wrote:
> As a general rule, this makes sense to me.
>
> Jim
>
>
>> -----Original Message-----
>> From: Carsten Bormann [mailto:[email-masked]]
>> Sent: Sunday, October 11, 2015 2:32 AM
>> To: Jim Schaad <[email-masked]>
>> Cc: [email-masked]
>> Subject: Re: [COSE] Assigning CBOR tags to key structures
>>
>> I'd propose this rule:
>> If there is a media type, there should be a CBOR tag for those environments that
>> don't benefit from media types.
>> (And generally vice versa, unless we are using CBOR tags in other than top-level
>> positions.)
>>
>> Grüße, Carsten
>>
>>
>> Jim Schaad wrote:
>> > I am currently working on the IANA text for doing assignment of CBOR
>> > tags in COSE.
>> >
>> > There is a possibility to request tags for the KEY and KEY_SET maps in
>> > the document.  At the present time I have not done this.  Can anybody
>> > see a reason for asking for tags on these two elements other than
>> completeness?
>> > I.e. does anybody have a place where it would make sense to use the
>> > pre-defined tags rather than knowing either a key or key set is in
>> > this location (it is possible to distinguish between the two items
>> > based on the an array vs map tag.)
>> >
>> >
>> > Jim
>> >
>> >
>> > _______________________________________________
>> > COSE mailing list
>> > [email-masked]
>> > https://www.ietf.org/mailman/listinfo/cose
>> >
>
> _______________________________________________
> COSE mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cose

---

From: Jim Schaad <[email-masked]>
Date: Fri, 7 Apr 2017 09:04:47 -0700

There is a content type that was defined.  This can be used for the same purpose by including a content type in the protected properties.  This allows for identification of the content before doing the decryption.

jim

> From: Renzo Navas [mailto:[email-masked]]
> Sent: Friday, April 7, 2017 1:34 AM
> To: cose <[email-masked]>
> Cc: Carsten Bormann <[email-masked]>; Jim Schaad <[email-masked]>
> could not find at IANA (nor on the cose rev 24 document) :( Was it discarded
> at the end, why? or there is a chance to still get the tag at IANA?
> 
> Regards !
> 
> Renzo
> 
> 
> ------------
> 
> More details on the Use Case: transporting a symmetric key with COSE_Key , it
> has to be protected, so wrapped on an Encrypt0 message (Tag 16); Would be
> nice have a tag to identify that the payload is a Cose_key object; it is true at
> the moment I can design the app to always expect a keyobjet as the payload of
> an encrypt0 ... ; but I'm cutting flexibility, or we can design a custom cbor
> structure, but we are loosing on interoperability.
> I have a coap server, with limited ram, and I have actually size only for for two
> coap resources, so I can see I will have to overload some functionality of this
> resource, particularly this is a sort of "/authz-info" ace resource, that I will use
> to do authenticated key establishment (oauth pop token provisioning), and
> other stuff, so probably quite overloaded.
> 
> 
> 
> 
> >> If there is a media type, there should be a CBOR tag for those
> >> environments that don't benefit from media types.
> >> > I am currently working on the IANA text for doing assignment of
> >> > CBOR tags in COSE.
> >> >
> >> > There is a possibility to request tags for the KEY and KEY_SET maps
> >> > in the document.  At the present time I have not done this.  Can
> >> > anybody see a reason for asking for tags on these two elements
> >> > other than
> >> completeness?

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 7 Apr 2017 18:14:12 +0200

Hi Renzo,

where would you put such a tag?

Starting the encoded CBOR with a tag would amount to a magic number unless the media type already indicates that this is CBOR-encoded.  But then it could indicate that this is a application/cose-key in the first place (Content-Format 101):

https://www.iana.org/assignments/core-parameters/core-parameters.xhtml#content-formats

Grüße, Carsten

---

From: Renzo Navas <[email-masked]>
Date: Tue, 18 Apr 2017 11:46:48 +0200

Hello Cose ML!
(Sorry for the late reply, I didn't see the replies the same day; then
I was on holidays)

Jim:
thanks for the suggestion. Indeed I think I will go for this option to
keep the solution non-homebrew. I will  borrow from the CoAP
Content-Formats (application/cose-key : 101) and put this in the
protected headers.
I think this solution will be 3  bytes (1B content-type label + 2B to
represent "101") instead of 1 byte of the hypothetical CBOR Tag for
COSE-Key (19 or 20 looked nice).

Carsten:
I am using CoAP (..for now) but I want the least possible COSE
metadata on the CoAP header; to make the COSE message as agnostic as
possible of the transport (maybe we will transport this message
over-foo). In my particular case, I simply use the CoAP Content-format
60 to indicate that this is an "application/cbor" payload.
Then I use the CBOR-Tag 16 (COSE_Encrypt0), because indeed that is
what this CBOR message is. So even if I use CoAP metadata for COSE I
should indicate this message as "application/cose;
cose-type="cose-encrypt0" (16).

 My 'problem' arose when, once decrypted; the plaintext part of the
COSE_Encrypt0 contains , in some cases, a COSE_Key object; and I
simply wanted to indicate that with a 1-byte tag . Jim's suggestions
of content-type in protected header solves my problem indeed.

So maybe the question I want to ask to the ML is:

why you discarded defining the COSE_Key/COSE_KeySet CBOR tag? ( I see
the pretty tags 19 and 20 unassigned)

>environments that don't benefit from media types.
In the end, it's a matter of 2 bytes, 1 byte tag, vs 3 byte protected
header content-type.
The COSE messages are around 52 Bytes, so It's a matter of 4% longer
Messages/Energy.

I found it strange not to find a CBOR tag for a mayor COSE type.

These are my 2 cents,

Thank you for your quick reply Jim and Carsten!

Renzo

---

From: Renzo Navas <[email-masked]>
Date: Tue, 18 Apr 2017 11:51:52 +0200

clarification: when I wrote "The COSE  messages are around 52 Bytes.."
I wanted to say the COSE messages *of my particular application*; but
let's forget that.