Subject: Re: [Cose] Issue: Identification of the top level objects

From: Ludwig Seitz <[email-masked]>
Date: Wed, 06 May 2015 09:02:25 +0200

On 05/01/2015 12:58 AM, Jim Schaad wrote:
> Question:  Identification of objects:
> a)  CBOR Tag - either general or specific to each type
> b)  Required Identifier
> c)  Use the same techniques as JOSE
>
> Discussion:
>
> One of the things that I have never liked with the JOSE document is the
> method that is used to determine the type of object that one is dealing
> with.   I would lie to get this corrected so that it is simple to make this
> determination.

Why was it done this way in JOSE in the first place?

A CBOR tag sounds neat, can the CBOR experts tell us if there are any 
negative implications?

/Ludwig

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 06 May 2015 11:34:27 +0200

> Why was it done this way in JOSE in the first place?

Can't answer that one.

> A CBOR tag sounds neat, can the CBOR experts tell us if there are any

Well, first of all, there should be no security implications of any of
this, as this identification information is not protected.

So we should have full freedom in doing what fits our applications.

Many applications already know the type of the object to be expected
from the context, so there isn't even a need for self-describing
identification.  E.g., in a CoAP environment, we could simply have three
different media types for the different types of COSE object.

Other applications would indeed derive a benefit from a self-describing
property.  These applications may, again, from context, know that they
are handling a COSE object, but not which one.  This is the situation
that is addressed by the current draft, which includes an identifying
number right at the start of the top-level array.

If an application could be handling other objects than COSE ones, where
these other objects also are encoded in CBOR, would benefit from a CBOR
tag.  Usage of such a tag could be left optional to also benefit those
applications that already have the contextual information.

>From an encoding overhead point of view, not providing identifying
information is of course best.  The solution to put in a small integer
in the top-level array consistently costs a single byte, independent of
whether the information is needed or not (of course, in the latter case
there is still a diagnostic value of that redundancy).  A CBOR tag can
be encoded in a single byte, but there are only very few code points for
that (24 in total, of which 9 are allocated by RFC 7049).  So I would
expect us to go for a tag value that allows encoding in two bytes (there
are 217 of these code points left, so taking three or four should not be
a problem).  So the cost would be two bytes if needed, and zero bytes if
supplied by context.

For the purposes of draft-selander-ace-object-security-01.txt, the type
of the object should always be known from the context, so here going for
an optional tag could actually be used to save a byte.

Grüße, Carsten

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 6 May 2015 14:28:29 -0700

> c)  Use the same techniques as JOSE

(a) is OK, but (b) is more definitive. (c) is, as you point out, wasteful of program space.

I would more highly support (b) because it is a single byte whereas (a) might be one or more bytes.

--Paul Hoffman

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 7 May 2015 12:58:53 -0700

> -----Original Message-----
> From: Cose [mailto:[email-masked]] On Behalf Of Ludwig Seitz
> Sent: Wednesday, May 06, 2015 12:02 AM
> To: [email-masked]
> Subject: Re: [Cose] Issue: Identification of the top level objects
> 
> > One of the things that I have never liked with the JOSE document is
> > the method that is used to determine the type of object that one is
dealing
> Why was it done this way in JOSE in the first place?

The major focus of the JOSE working group tended to be on the compact
encoding and in this case it was deemed to not be necessary to have as the
number of separation characters gave adequate indication of the type of
message it was.  This was not as true for the JSON encoding where there were
some kind of kludgy methods of doing the identification.  There were several
attempts to get this clarified up, but the push back was too large among the
people who were only interested in the compact format.

Jim

---

From: ⌘ Matt Miller <[email-masked]>
Date: Mon, 11 May 2015 08:40:14 -0600

On 4/30/15 4:58 PM, Jim Schaad wrote:
> Question:  Identification of objects: a)  CBOR Tag - either
> general or specific to each type b)  Required Identifier c)  Use
> the same techniques as JOSE

I would prefer (b), but could live with (a). (b) makes an object that
is self-contained. I don't see a new top-level field with a simple
enumerated integer value to be that expensive, but would defer to the
rest of the group.

I object to (c). As does Jim, I find the JOSE technique to be overly
complex and really don't like it.

- -- 
- - m&m

Matt Miller < [email-masked] >
Cisco Systems, Inc.

---

From: Mike Jones <[email-masked]>
Date: Mon, 11 May 2015 14:47:45 +0000

JOSE already defines a "typ" header parameter for exactly this purpose, which uses MIME Types.  Let's just use it, rather than inventing something different.  The value of divergence in this case isn't worth the divergence, at least as I see it.

				Cheers,
				-- Mike

-----Original Message-----
From: Cose [mailto:[email-masked]] On Behalf Of ? Matt Miller
Sent: Monday, May 11, 2015 3:40 PM
To: Jim Schaad; [email-masked]
Subject: Re: [Cose] Issue: Identification of the top level objects

On 4/30/15 4:58 PM, Jim Schaad wrote:
> Question:  Identification of objects: a)  CBOR Tag - either general or 
> specific to each type b)  Required Identifier c)  Use the same 
> techniques as JOSE

I would prefer (b), but could live with (a). (b) makes an object that is self-contained. I don't see a new top-level field with a simple enumerated integer value to be that expensive, but would defer to the rest of the group.

I object to (c). As does Jim, I find the JOSE technique to be overly complex and really don't like it.

- --
- - m&m

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

---

From: Derek Atkins <[email-masked]>
Date: Mon, 11 May 2015 11:15:33 -0400

> complex and really don't like it.

+1

In my use case I'm nesting a bunch of objects so it would be useful to
have them be tagged compactly.

-derek

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 11 May 2015 14:13:49 -0700

Of course in the world of JOSE, using this header cannot be done with a simple single call. 

First it can be placed in either the protected or unprotected headers meaning that you have a couple of places to look.

Second while the headers are called "protected" and "unprotected" and are at the top level for an encrypted message.  For a signed message the headers are called "protected" and "header" and are part of the signature field, meaning that there two different levels that need to be looked at.

Finally, the description for "typ" in JWS states

This is intended for use by the application when more than one kind
   of object could be present in an application data structure that can
   contain a JWS; the application can use this value to disambiguate
   among the different kinds of objects that might be present.

Which is not the same as saying it should be used to disambiguate between an encrypted message, a MAC-ed message and a signed message.

Without some changes, I am not sure that this really maps to the same thing we are trying to accomplish.

Jim

> From: Mike Jones [mailto:[email-masked]]
> Sent: Monday, May 11, 2015 7:48 AM
> To: ⌘ Matt Miller; Jim Schaad; [email-masked]
> Subject: RE: [Cose] Issue: Identification of the top level objects
> 
> JOSE already defines a "typ" header parameter for exactly this purpose,
> which uses MIME Types.  Let's just use it, rather than inventing something
> different.  The value of divergence in this case isn't worth the divergence, at
> least as I see it.
> 
> 				Cheers,
> 				-- Mike
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> I would prefer (b), but could live with (a). (b) makes an object that is self-
> contained. I don't see a new top-level field with a simple enumerated integer
> value to be that expensive, but would defer to the rest of the group.
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
> Comment: GPGTools - https://gpgtools.org
> 
> iQEcBAEBCgAGBQJVUL9OAAoJEDWi+S0W7cO1D00H/iqK2od3xeJHtUDeCKDXj
> VWZ
> zs5Wen1AxYoDzvErNZX3RM7Tpi7zHkOje+YhV+qFbQ04RgFKaXlrrje1uF0pCzp
> C
> YxWgCmp9cSQviU3o6sbjQ1F0ZoO5tYXOY7FS6ZJx8ZqIMjMhR1zwlF/fOgQc+d
> XH
> adF1WruOXNuVVjcvq3FfuMYxUoH/4aW2Tx0RR3s/Rf1DCSBQH6irJTebS4Ph2a
> lr
> QDn8H2y1rfLNWKN16XT8Tz9YlCKzhy3Db0SWamGQIXWRt31qMdayj7edQJ1Q
> 1a1h
> EexAaCOE8Bgp7KLefWH8rIo9LrDt0asj7KRJvuIGeDXhKMScQeVW1Ygkh0XrJH
> Q=
> =tl1m
> -----END PGP SIGNATURE-----
>