Subject: [Cose] ISSUE: Use of integer rather than string tags

From: "Jim Schaad" <[email-masked]>
Date: Mon, 18 May 2015 14:05:42 -0700

Questions:
1.  Should we use integers only, integers and strings or strings only for
indexing of maps?
2.  Should we build one or more tables of values that allow for integers to
be used rather than strings?
3.  How many/what registries should be created or modified to indicate the
use of integer values and keys?

Discussion:

There has been a general assumption that we are going to use integer values
for keying of maps within COSE.  However there is an interesting question,
do we only use integer values or do we allow strings as well?  Allowing for
strings allows for easier creating of local keys and keys for testing
purposes than restricting the type to just integers.  However it might be
easier to go through the keys if strings are not allowed.  My presumption
has been that both are going to be allowed.

There is an interesting question of what registry tables we are going to
create to hold the keys and values in.  I believe that the following
locations of integer values exist that need to be assigned to tables.  If
you feel this list is incomplete then say so:

1.  Keys in top level maps.
2.  Keys associated with protected and unprotected header fields
3.  Values associated with top level keys
4.  Values associated with the various protected and unprotected header
keys.

It is probably that we need to enumerate the list of all of the header keys
and make a determination if we have a unique value table for that key or if
we are going to use a common table for that key.   As an example, it makes
sense that there would be a unique table that holds all of the algorithm
names in it.  However, if one looks at the curve names for EC, these names
could be placed in the algorithm name table, a separate curve table or in a
common table that is used for generic purposes. 

Another question is what document should the different tables be created or
updated in.  It makes sense that this document could update the algorithm
table.  However, that could also be done in the algorithm document that the
group is expected to create as well.  There has been a desire expressed to
update the mime-type table to have a column of integer values associated
with it.  This makes life much more fun as it is not clear that we want to
have a document do this, but rather just a document that is going to have a
procedure for doing so.   Such a proceeding would require some thought if
the one and two byte values are to be reserved for more commonly used mime
types.

Finally, are the values just positive integers or both positive and negative
integers.  Do we have reserved spaces for private usage in all of the tables
and, for new tables, what are the rules for updating the table.

This issue is somewhat open ended and some of the questions will more likely
be addressed as the procedure goes along and we start writing text for the
decisions that we are making.

Jim

---

From: Mike Jones <[email-masked]>
Date: Mon, 18 May 2015 21:28:39 +0000

Support both.  Lots of applications will have locally keys and using strings gives them an easy way to use collision-resistant names for these keys, rather than having to register everything - even keys that will never be meaningful outside the application - with IANA in order to avoid collisions.  Letting people use strings will thereby help us conserve a scarce resource - the short integer namespace.

				-- Mike

-----Original Message-----
From: Cose [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Monday, May 18, 2015 2:06 PM
To: [email-masked]
Subject: [Cose] ISSUE: Use of integer rather than string tags

Questions:
1.  Should we use integers only, integers and strings or strings only for indexing of maps?
2.  Should we build one or more tables of values that allow for integers to be used rather than strings?
3.  How many/what registries should be created or modified to indicate the use of integer values and keys?

Discussion:

There has been a general assumption that we are going to use integer values for keying of maps within COSE.  However there is an interesting question, do we only use integer values or do we allow strings as well?  Allowing for strings allows for easier creating of local keys and keys for testing purposes than restricting the type to just integers.  However it might be easier to go through the keys if strings are not allowed.  My presumption has been that both are going to be allowed.

There is an interesting question of what registry tables we are going to create to hold the keys and values in.  I believe that the following locations of integer values exist that need to be assigned to tables.  If you feel this list is incomplete then say so:

1.  Keys in top level maps.
2.  Keys associated with protected and unprotected header fields 3.  Values associated with top level keys 4.  Values associated with the various protected and unprotected header keys.

It is probably that we need to enumerate the list of all of the header keys and make a determination if we have a unique value table for that key or if
we are going to use a common table for that key.   As an example, it makes
sense that there would be a unique table that holds all of the algorithm names in it.  However, if one looks at the curve names for EC, these names could be placed in the algorithm name table, a separate curve table or in a common table that is used for generic purposes. 

Another question is what document should the different tables be created or updated in.  It makes sense that this document could update the algorithm table.  However, that could also be done in the algorithm document that the group is expected to create as well.  There has been a desire expressed to update the mime-type table to have a column of integer values associated with it.  This makes life much more fun as it is not clear that we want to have a document do this, but rather just a document that is going to have a
procedure for doing so.   Such a proceeding would require some thought if
the one and two byte values are to be reserved for more commonly used mime types.

Finally, are the values just positive integers or both positive and negative integers.  Do we have reserved spaces for private usage in all of the tables and, for new tables, what are the rules for updating the table.

This issue is somewhat open ended and some of the questions will more likely be addressed as the procedure goes along and we start writing text for the decisions that we are making.

Jim

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

---

From: Derek Atkins <[email-masked]>
Date: Wed, 20 May 2015 14:25:16 -0400

Hi Jim,

> 1.  Should we use integers only, integers and strings or strings only for

We should allow both integers and strings.

> be used rather than strings?

Yes.

> use of integer values and keys?

We probably need "separate" registries for known keys/values in each of
the maps we create.

> common table that is used for generic purposes. 

It depends whether we want to have to say something like:

alg => {ec_sha2 => p256}  instead of alg => es256

Similar for AES.  Do we need one registry with 'aes' and another with
known "key sizes" (128, 256), or just two algorithm entries, aes128 and
aes256?  I would argue that it's "easier" to just have a single
algorithm registry where "cipher-family" and "parameter" are combined.

This does mean if we choose to include a dozen different ECC curves then
we'd need a dozen entries in this table.

Note also that I say this as a purveyor of a crypto algorithm where even
just saying the parameter level (eg 2^128 level security) is not
sufficient to nail down the actual parameters to use, as there are an
infinite number of potential parameters at every security level.  But
like everyone else I would need to nail down parameter sets.

> the one and two byte values are to be reserved for more commonly used mime

I'm fine with this all being defined in a single COSE spec document.  I
don't feel we need to break it apart into multiple documents like JOSE
did.  Indeed, I would argue that a single cohesive document is easier to
follow than what JOSE did.

> and, for new tables, what are the rules for updating the table.

For cleverness I think we can use both positives and negatives.  We
should reserve all 1-byte-resulting numbers.  We should have some
reserved spaces for private usage.  As for the rules, I think the
single-byte numbers should be Standard Required and the multi-byte
numbers can be Expert Review.

> decisions that we are making.

:)

> Jim

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

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 20 May 2015 12:29:10 -0700

> From: Derek Atkins [mailto:[email-masked]]
> Sent: Wednesday, May 20, 2015 11:25 AM
> To: Jim Schaad
> Cc: [email-masked]
> Subject: Re: [Cose] ISSUE: Use of integer rather than string tags
> 
> Hi Jim,
> 
the
> maps we create.
> 
> > Discussion:
> >
> > There has been a general assumption that we are going to use integer
> > values for keying of maps within COSE.  However there is an
> > interesting question, do we only use integer values or do we allow
> > strings as well?  Allowing for strings allows for easier creating of
> > local keys and keys for testing purposes than restricting the type to
> > just integers.  However it might be easier to go through the keys if
> > strings are not allowed.  My presumption has been that both are going to
be
> allowed.
> >
> > There is an interesting question of what registry tables we are going
> > to create to hold the keys and values in.  I believe that the
> > following locations of integer values exist that need to be assigned
> > to tables.  If you feel this list is incomplete then say so:
> >
> > 2.  Keys associated with protected and unprotected header fields 3.
> > Values associated with top level keys 4.  Values associated with the
> > various protected and unprotected header keys.
> >
> > It is probably that we need to enumerate the list of all of the header
> > keys and make a determination if we have a unique value table for that
key
> or if
> > sense that there would be a unique table that holds all of the
> > algorithm names in it.  However, if one looks at the curve names for
> > EC, these names could be placed in the algorithm name table, a
> > separate curve table or in a common table that is used for generic
purposes.
> alg => {ec_sha2 => p256}  instead of alg => es256

My assumption has been that we are going to use a similar naming scheme to
that followed by JOSE.

alg=> ec_sha2 - but the curve is defined in the key used.   Thus ec_sha2 can
be used for any of the NIST curves and any other curve that follows the same
point convention.

This means that we are going to get two versions of ECDH - one for the
current {x,y} points and a new one for the {x} only points.

In terms of doing something like ECHD - there are a number of other items
that are defined in the algorithm id, i.e. not Chinese menu, that will lead
to some proliferation of algorithms.  But not as badly as TLS where a
complete set of all algorithms are combined in a single suite value.

Jim

> Similar for AES.  Do we need one registry with 'aes' and another with
known
> "key sizes" (128, 256), or just two algorithm entries, aes128 and aes256?
I
> would argue that it's "easier" to just have a single algorithm registry
where
> "cipher-family" and "parameter" are combined.
> 
we'd
> need a dozen entries in this table.
> 
just
> saying the parameter level (eg 2^128 level security) is not sufficient to
nailsimi
> down the actual parameters to use, as there are an infinite number of
potential
> parameters at every security level.  But like everyone else I would need
to nail
> down parameter sets.
> 
> > Another question is what document should the different tables be
> > created or updated in.  It makes sense that this document could update
> > the algorithm table.  However, that could also be done in the
> > algorithm document that the group is expected to create as well.
> > There has been a desire expressed to update the mime-type table to
> > have a column of integer values associated with it.  This makes life
> > much more fun as it is not clear that we want to have a document do
this, but
> rather just a document that is going to have a
don't feel
> we need to break it apart into multiple documents like JOSE did.  Indeed,
I
> would argue that a single cohesive document is easier to follow than what
JOSE
> did.
> 
> > Finally, are the values just positive integers or both positive and
> > negative integers.  Do we have reserved spaces for private usage in
> > all of the tables and, for new tables, what are the rules for updating
the table.
> 
> For cleverness I think we can use both positives and negatives.  We should
> reserve all 1-byte-resulting numbers.  We should have some reserved spaces
> for private usage.  As for the rules, I think the single-byte numbers
should be
> Standard Required and the multi-byte numbers can be Expert Review.
> 
> > This issue is somewhat open ended and some of the questions will more
> > likely be addressed as the procedure goes along and we start writing
> > text for the decisions that we are making.
> 
> :)
> 
> > Jim
> 
> -derek
> --

---

From: Derek Atkins <[email-masked]>
Date: Fri, 22 May 2015 11:32:29 -0400

> complete set of all algorithms are combined in a single suite value.

I am fine with this approach (although I thought JOSE combined the EC
with the Signature and Key Size, e.g. { alg: ES256 }?

-derek

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 22 May 2015 12:53:20 -0700

-----Original Message-----
From: Derek Atkins [mailto:[email-masked]] 
Sent: Friday, May 22, 2015 8:32 AM
To: Jim Schaad
Cc: 'Derek Atkins'; [email-masked]
Subject: Re: [Cose] ISSUE: Use of integer rather than string tags

"Jim Schaad" <[email-masked]> writes:

> My assumption has been that we are going to use a similar naming 
> scheme to that followed by JOSE.
>
> be used for any of the NIST curves and any other curve that follows 
> the same point convention.
>
> In terms of doing something like ECHD - there are a number of other 
> items that are defined in the algorithm id, i.e. not Chinese menu, 
> that will lead to some proliferation of algorithms.  But not as badly 
> as TLS where a complete set of all algorithms are combined in a single
suite value.

I am fine with this approach (although I thought JOSE combined the EC with
the Signature and Key Size, e.g. { alg: ES256 }?

[JLS] No that is actually hash size.

jim

-derek

---

From: Mike Jones <[email-masked]>
Date: Fri, 22 May 2015 20:06:17 +0000

Derek, you're right that JOSE chose to use string identifiers for algorithms, rather than structured identifiers.  That means that algorithm processing just requires table lookup, rather than structure parsing.  There are no modifiers or additional algorithm parameters specified separately, by design.  One of the ways that the working group tried to "keep simple things simple".

				Cheers,
				-- Mike

-----Original Message-----
From: Cose [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Friday, May 22, 2015 12:53 PM
To: 'Derek Atkins'
Cc: [email-masked]
Subject: Re: [Cose] ISSUE: Use of integer rather than string tags

-----Original Message-----
From: Derek Atkins [mailto:[email-masked]]
Sent: Friday, May 22, 2015 8:32 AM
To: Jim Schaad
Cc: 'Derek Atkins'; [email-masked]
Subject: Re: [Cose] ISSUE: Use of integer rather than string tags

suite value.

I am fine with this approach (although I thought JOSE combined the EC with the Signature and Key Size, e.g. { alg: ES256 }?

jim

-derek

---

From: Derek Atkins <[email-masked]>
Date: Tue, 26 May 2015 16:34:01 -0400

Mike Jones <[email-masked]> writes:

> Derek, you're right that JOSE chose to use string identifiers for
> algorithms, rather than structured identifiers.  That means that
> algorithm processing just requires table lookup, rather than structure
> parsing.  There are no modifiers or additional algorithm parameters
> specified separately, by design.  One of the ways that the working
> group tried to "keep simple things simple".

So for "ES256" is that always ECC P-256 with SHA-2 256?  Is there, e.g.,
no way to specify a different 256-bit curve, or a different hash
algorithm?

-derek

---

From: Mike Jones <[email-masked]>
Date: Fri, 29 May 2015 19:55:45 +0000

Correct.  If you want to specify a different curve or different hash algorithm, you'd register a new identifier in the IANA JSON Web Signature and Encryption Algorithms registry http://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms that corresponds to the new combination you want to use (assuming that is, that the combination you want hasn't already been registered).

				-- Mike

-----Original Message-----
From: Derek Atkins [mailto:[email-masked]] 
Sent: Tuesday, May 26, 2015 1:34 PM
To: Mike Jones
Cc: Jim Schaad; [email-masked]
Subject: Re: [Cose] ISSUE: Use of integer rather than string tags

> group tried to "keep simple things simple".

So for "ES256" is that always ECC P-256 with SHA-2 256?  Is there, e.g., no way to specify a different 256-bit curve, or a different hash algorithm?

-derek

>> This means that we are going to get two versions of ECDH - one for 
>> the current {x,y} points and a new one for the {x} only points.
>>

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 29 May 2015 13:47:03 -0700

When looking at this at the times the spec was being written, I did not
correctly remember what limitations that NIST had put on ECDSA.  I therefore
pushed to have the curve fixed.  It turns out that we probably should have
used the same criteria that NIST used which was that the hash had to be at
least as large as the strength of the curve.

Jim

> From: Mike Jones [mailto:[email-masked]]
> Sent: Friday, May 29, 2015 12:56 PM
> To: Derek Atkins
> Subject: RE: [Cose] ISSUE: Use of integer rather than string tags
> 
> Correct.  If you want to specify a different curve or different hash
algorithm,
> you'd register a new identifier in the IANA JSON Web Signature and
Encryption
> Algorithms registry http://www.iana.org/assignments/jose/jose.xhtml#web-
> signature-encryption-algorithms that corresponds to the new combination
you
> want to use (assuming that is, that the combination you want hasn't
already
> been registered).
no way
> to specify a different 256-bit curve, or a different hash algorithm?
> 
> > 				Cheers,
> > 				-- Mike
> 
> -derek
> 
> >> alg=> ec_sha2 - but the curve is defined in the key used.   Thus
ec_sha2
> > can
with