Subject: [Cose] Editorial: New term "label"

From: Carsten Bormann <[email-masked]>
Date: Sat, 13 Jun 2015 09:32:57 +0200

Justin Richer wrote:
> We’re starting a two week review period to determine a potential
> starting draft for the COSE work. 
> At the end of the two week period, the chairs will do a consensus call.

So you want to play this safe RFC 2418 wise.  OK.
But let's not get stuck with a month of dead time.
(Also, let's get the WG draft in before the I-D cutoff.)

I'm assuming we will actively work on Jim's draft during this time (for
most of us under the assumption that this will be the WG draft after the
various timeouts have passed).

In the next couple of weeks, I will post a number of change proposals,
some editorial, some at the level of encoding, and maybe some with
deeper impact.

Today's proposal is editorial, motivated by our overloading of the term
"key".
"Key" is used both as a cryptographic key (which is then further
specialized as COSE_Key), and as the thing indexing a map ("map key").
The latter are not only strings, but integers in COSE.  There often is a
need for "string or integer used in an identifying role", not just for
map keys, but also for algorithm identifiers etc.

So I propose we introduce the term "label" for these.  This allows us to
talk about labels and values in a map.  For these, and also for the
places where a label is used in the value position (e.g., under the
label kty) we don't constantly need to say "integer or string".
Introducing a CDDL production for label also simplifies the CDDL a lot.

I'll propose detailed text later today; just throwing out the idea now.

Grüße, Carsten

---

From: "Jim Schaad" <[email-masked]>
Date: Sat, 13 Jun 2015 07:38:04 -0700

> -----Original Message-----
> From: Cose [mailto:[email-masked]] On Behalf Of Carsten Bormann
> Sent: Saturday, June 13, 2015 12:33 AM
> To: [email-masked]
> Subject: [Cose] Editorial: New term "label"
> 
> Justin Richer wrote:
> I'm assuming we will actively work on Jim's draft during this time (for most
> of us under the assumption that this will be the WG draft after the various
> timeouts have passed).
> 
> In the next couple of weeks, I will post a number of change proposals, some
> editorial, some at the level of encoding, and maybe some with deeper
> impact.
> 
> "Key" is used both as a cryptographic key (which is then further specialized
> as COSE_Key), and as the thing indexing a map ("map key").
> The latter are not only strings, but integers in COSE.  There often is a need
> for "string or integer used in an identifying role", not just for map keys, but
> also for algorithm identifiers etc.
> 
> So I propose we introduce the term "label" for these.  This allows us to talk
> about labels and values in a map.  For these, and also for the places where a
> label is used in the value position (e.g., under the label kty) we don't
> constantly need to say "integer or string".

The idea of separating the uses of the word key and using different terms makes complete sense to me.  I agree that this would make things much easier. I am leery about the idea of using the same term in a generic manner for both map keys and map values as a general rule.  It makes sense for something like the 'crit' protected header where the value is intended to be a set of map keys, but for something like 'kty' where you are just using the type I don't know that I agree.

It might make more sense for us to define two different things:

*  label - replaces the term 'cbor map key'
*  iors - a locally defined cbor type of integer or string

I am not wedded to either of those terms if anybody comes up with something better.

Jim

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

---

From: Mike Jones <[email-masked]>
Date: Sat, 13 Jun 2015 16:17:47 +0000

Often, one talks of Name:Value pairs. That's intuitive, and matches the terminology used for JOSE & JWT.  I understand that it might be a bit odd when numbers are used as the Name.

I would be ok with using the term Label and Label:Value pairs if we explicitly provide a definition for our use of the term in the Terminology section.  (Indeed, that's what I thought Carsten was proposing.)

-- Mike
________________________________
From: Jim Schaad<mailto:[email-masked]>
Sent: ‎6/‎13/‎2015 7:38 AM
To: 'Carsten Bormann'<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Cose] Editorial: New term "label"

Jim

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 13 Jun 2015 18:46:37 +0200

Mike Jones wrote:
> I would be ok with using the term Label and Label:Value pairs if we
> explicitly provide a definition for our use of the term in the
> Terminology section.  (Indeed, that's what I thought Carsten was proposing.)

Right.  Below is the pertinent section 1 text in my current draft PR
(which is not yet quite finished).

Grüße, Carsten

## CBOR related terminology {#label}

In JSON, maps are called objects and only have one kind of map key: a
string.
In COSE, we use both strings and integers (both unsigned and negative
integers) as map keys, as well as data items to identify specific
choices.
The (negative and unsigned) integers are used for compactness of
encoding and easy comparison.
Since the word "key" is mainly used in its other meaning as a
cryptographic key, we use the term "label" for this usage of either an
integer or a string to identify map keys and choice data items.

~~~~ CDDL

label = int / tstr

~~~~

---

From: Mike Jones <[email-masked]>
Date: Sat, 13 Jun 2015 19:32:20 +0000

+1
________________________________
From: Carsten Bormann<mailto:[email-masked]>
Sent: ‎6/‎13/‎2015 9:46 AM
To: Mike Jones<mailto:[email-masked]>
Cc: Jim Schaad<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Cose] Editorial: New term "label"

Grüße, Carsten

~~~~ CDDL

label = int / tstr

~~~~

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 18 Jun 2015 12:15:18 -0700

Carsten,

Looking at your pull request, I find that you basically did do the one thing that I referred to in my original message about potentially having a new confusion develop.

Looking at your definition for COSE_KEY

Label => int / tstr

COSE_Key = {
    kty => label,
    ? key_ops => [+label ],
    ? alg => label,
     ? kid => bstr,
     * keys => values
 }

You are suggesting using label as the value portion of kty, key_ops and alg.   However the value that is placed in these fields is never used as a map key in any location.  We are therefore having the term lable (or at least the type) used both where it is referring to something that would be a key as well as something that is just a value.

I do believe that the use of label is completely correct for something type 'crit' as what it refers to is labels.  Thus
    crit => [+label] 
Is a totally reasonable CDDL for that item.

I would prefer to keep these the term for key and the type of int/tstr separate.

Jim

> From: Carsten Bormann [mailto:[email-masked]]
> Sent: Saturday, June 13, 2015 9:47 AM
> To: Mike Jones
> Cc: Jim Schaad; [email-masked]
> Right.  Below is the pertinent section 1 text in my current draft PR (which is
> not yet quite finished).
> 
> Grüße, Carsten
> 
> 
> integers) as map keys, as well as data items to identify specific choices.
> The (negative and unsigned) integers are used for compactness of encoding
> and easy comparison.
> Since the word "key" is mainly used in its other meaning as a cryptographic
> key, we use the term "label" for this usage of either an integer or a string to
> identify map keys and choice data items.
> 
> ~~~~ CDDL
> 
> label = int / tstr
> 
> ~~~~

---

From: "Derek Atkins" <[email-masked]>
Date: Thu, 18 Jun 2015 15:39:12 -0400

Jim,

Do you think you'd prefer something that looks more like:

label => int / tstr
value => int / tstr

COSE_Key = {
    kty => value,
    ? key_ops => [+value ],
    ? alg => value,
    ? kid => bstr,
    * keys => values
 }

(I'm not sure if "value" is the appropriate name to use, and I'm not sure
if "keys" should be changed to "label" in the last line)

-derek

On Thu, June 18, 2015 3:15 pm, Jim Schaad wrote:
> Carsten,
>
> Looking at your pull request, I find that you basically did do the one
> thing that I referred to in my original message about potentially having a
> new confusion develop.
>
> You are suggesting using label as the value portion of kty, key_ops and
> alg.   However the value that is placed in these fields is never used as a
> map key in any location.  We are therefore having the term lable (or at
> least the type) used both where it is referring to something that would be
> a key as well as something that is just a value.
>
> I do believe that the use of label is completely correct for something
> type 'crit' as what it refers to is labels.  Thus
>     crit => [+label]
>> cryptographic

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

---

From: Mike Jones <[email-masked]>
Date: Thu, 18 Jun 2015 19:53:36 +0000

Value can be any CBOR type, including arrays, structures, Booleans, and null, not just int or tstr.

-----Original Message-----
From: Cose [mailto:[email-masked]] On Behalf Of Derek Atkins
Sent: Thursday, June 18, 2015 12:39 PM
To: Jim Schaad
Cc: 'Carsten Bormann'; [email-masked]
Subject: Re: [Cose] Editorial: New term "label"

Jim,

label => int / tstr
value => int / tstr

COSE_Key = {
    kty => value,
    ? key_ops => [+value ],
    ? alg => value,
    ? kid => bstr,
    * keys => values
 }

(I'm not sure if "value" is the appropriate name to use, and I'm not sure if "keys" should be changed to "label" in the last line)

-derek

On Thu, June 18, 2015 3:15 pm, Jim Schaad wrote:
> thing that I referred to in my original message about potentially 
> having a new confusion develop.
>
> map key in any location.  We are therefore having the term lable (or 
> at least the type) used both where it is referring to something that 
> would be a key as well as something that is just a value.
>
>> cryptographic key, we use the term "label" for this usage of either 
>> an integer or a string to identify map keys and choice data items.
>>
>> ~~~~ CDDL
>>
>> label = int / tstr
>>
>> ~~~~
>

---

From: "Derek Atkins" <[email-masked]>
Date: Thu, 18 Jun 2015 16:02:19 -0400

Would you rather I called it "int_or_string_value"?

The kty label can only have an int or tstr value, but we don't want to
label it "label".

-derek

---

From: Mike Jones <[email-masked]>
Date: Thu, 18 Jun 2015 20:16:13 +0000

I think I'm missing something here. I thought that what we were discussing in this thread was a proposal to use the term "label" for CBOR object keys in our specs, so that objects would be described as containing label:value pairs.

This is true of all labels - not just kty labels.  So I don't know why you wouldn't want to call a specific label a label, assuming we adopt that terminology.

-- Mike
________________________________
From: Derek Atkins<mailto:[email-masked]>
Sent: ‎6/‎18/‎2015 1:02 PM
To: Mike Jones<mailto:[email-masked]>
Cc: Jim Schaad<mailto:[email-masked]>; 'Carsten Bormann'<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Cose] Editorial: New term "label"

-derek

On Thu, June 18, 2015 3:53 pm, Mike Jones wrote:
>        [email-masked]             www.ihtfp.com<http://www.ihtfp.com>

--
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com<http://www.ihtfp.com>
       Computer and Internet Security Consultant

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 18 Jun 2015 13:16:55 -0700

Yes that is more what I would like to see, although the problem is that value is a bit too restrictive.  I would want to distinguish between cases where the value is going to be either an int/tstr or it can be any cbor type object.  Value vs values is probably not a good distinguisher.

torn => int/tstring
label=> torn

(torn is a really bad name for this.  I wish I could come up with something good.  Tint does not work nor does tori.  Perhaps if I stop trying to encode the type and use something like simple_value.)

I would agree that the last line needs to be changed as well.   That got missed in the pull request.

Jim

> From: Derek Atkins [mailto:[email-masked]]
> (I'm not sure if "value" is the appropriate name to use, and I'm not sure if
> "keys" should be changed to "label" in the last line)
> 
> -derek
>

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 18 Jun 2015 13:27:22 -0700

If you look at the CDDL rule

Cose_key: {

kty=>label

}

you end up with 

kty is the key in a map.  We want to refer to this as the label of the field in the map.  So ‘kty’ is a label.   The type of the label in the map is restricted to being an integer (negative or non-negative) or a string.

label is the value associated with the key ‘kty’ in the map. We also want to restrict the types allowed to being either an integer or a string.

If we use the term ‘label’ to represent both the map key and the type of the map value, there is a potential for getting confused here.  I want to make these distinguishable by allowing for one term for the map key and one term for the type object.

Jim

From: Mike Jones [mailto:[email-masked]] 
Sent: Thursday, June 18, 2015 1:16 PM
To: Derek Atkins
Cc: Jim Schaad; 'Carsten Bormann'; [email-masked]
Subject: RE: [Cose] Editorial: New term "label"

-- Mike

  _____  

From: Derek Atkins <mailto:[email-masked]> 
Sent: ‎6/‎18/‎2015 1:02 PM
To: Mike Jones <mailto:[email-masked]> 
Cc: Jim Schaad <mailto:[email-masked]> ; 'Carsten Bormann' <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> 
Subject: Re: [Cose] Editorial: New term "label"

-derek

On Thu, June 18, 2015 3:53 pm, Mike Jones wrote:
> Cc: 'Carsten Bormann'; [email-masked] <mailto:[email-masked]> 
>>> Cc: Jim Schaad; [email-masked] <mailto:[email-masked]> 
>> [email-masked] <mailto:[email-masked]> 
>        [email-masked] <mailto:[email-masked]>              www.ihtfp.com <http://www.ihtfp.com> 
> [email-masked] <mailto:[email-masked]> 

-- 
       Derek Atkins                 617-623-3745
       [email-masked] <mailto:[email-masked]>              www.ihtfp.com <http://www.ihtfp.com> 
       Computer and Internet Security Consultant

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

---

From: Mike Jones <[email-masked]>
Date: Thu, 18 Jun 2015 20:36:01 +0000

Ok. Then introduce a string-or-int production and define label as that. Maybe that's what you were thinking already. :-)
________________________________
From: Jim Schaad<mailto:[email-masked]>
Sent: ‎6/‎18/‎2015 1:27 PM
To: Mike Jones<mailto:[email-masked]>; 'Derek Atkins'<mailto:[email-masked]>
Cc: 'Carsten Bormann'<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Cose] Editorial: New term "label"

Cose_key: {
kty=>label
}

you end up with

Jim

-- Mike

-derek

On Thu, June 18, 2015 3:53 pm, Mike Jones wrote:
> Cc: 'Carsten Bormann'; [email-masked]<mailto:[email-masked]>
>>> Cc: Jim Schaad; [email-masked]<mailto:[email-masked]>
>>> Grü?e, Carsten
>> [email-masked]<mailto:[email-masked]>
>        [email-masked]<mailto:[email-masked]>             www.ihtfp.com<http://www.ihtfp.com>
> [email-masked]<mailto:[email-masked]>

--
       Derek Atkins                 617-623-3745
       [email-masked]<mailto:[email-masked]>             www.ihtfp.com<http://www.ihtfp.com>
       Computer and Internet Security Consultant

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

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 18 Jun 2015 23:38:39 +0200

Mike Jones wrote:
> Ok. Then introduce a string-or-int production and define label as that.
> Maybe that's what you were thinking already. :-)

Indeed.

My text proposal is at

https://github.com/cabo/cose-spec/blob/editorial/draft-schaad-cose.md#cbor-related-terminology-label

(and below). (Unfortunately, github's flavor of markdown is somewhat
limited; this should still be mostly readable except for the tables.)

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 18 Jun 2015 23:42:43 +0200

Oh, and we can always use another term for a label that is not in a map
key position.
"designator" is the most bureaucratic term I could find (not yet used in
the below text proposal).

Grüße, Carsten