Subject: [COSE] alg Header Parameter

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 31 Aug 2015 09:11:57 +0200

Hi Jim, Hi Brian,

Is it possible to make the alg parameter optional?

Reason: When a key id is used then all the necessary information,
including the algorithm, can be determined from the key id itself.

Table 1 ' Common Header Parameters' defines the alg parameter as follows:

   +----------+-------+----------+-----------------+-------------------+
   | name     | label | value    | value registry  | description       |
   |          |       | type     |                 |                   |
   +----------+-------+----------+-----------------+-------------------+
   | alg      | 1     | int /    | COSE Algorithm  | Integers are      |
   |          |       | tstr     | Registry        | taken from table  |
   |          |       |          |                 | --POINT TO        |
   |          |       |          |                 | REGISTRY--        |

I would prefer to only have one option to represent the value, namely as
an integer.

I also think that you could include a pointer to the appropriate
section. While the other text in this section points to Section 15.3 I
don't believe that this is actually correct.

Regarding the fields in the header parameter table I was wondering why
not to standardize the full list as listed in the table. Currently, a
number of entries are marked with a "*".

Regarding the nonce field do you expect it to also serve as a container
for sequence numbers or do you plan to add a separate field for it?

What about adding a timestamp field (for an alternative replay
protection mechanism for those cases where sequences numbers are not
appropriate)?

Ciao
Hannes

---

From: Ludwig Seitz <[email-masked]>
Date: Mon, 31 Aug 2015 10:18:36 +0200

On 2015-08-31 09:11, Hannes Tschofenig wrote:
[...]
> protection mechanism for those cases where sequences numbers are not

+1

The sequence numbers are being discussed in ACE for replay protection 
because _some_ IoT devices can not reliably measure time. Those that can 
use time should have a dedicated header option for this.

/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: "Jim Schaad" <[email-masked]>
Date: Mon, 31 Aug 2015 10:26:38 -0700

> -----Original Message-----
> From: COSE [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
> Sent: Monday, August 31, 2015 12:12 AM
> To: [email-masked]
> Subject: [COSE] alg Header Parameter
> 
> Hi Jim, Hi Brian,
> 
> Reason: When a key id is used then all the necessary information, including the
> algorithm, can be determined from the key id itself.

You have a much different view of key ids than what I do.  I do not believe that key ids are unique so I very leery of the idea that everything necessary can be determined from the key id.  Additionally, while it may be true in your context that algorithm can be determined from the key id, this is not going to be true in all contexts and potentially for all key ids.  

Also, my implementation does not manage the keys and therefore would not have access to the required information easily.  While it make sense to move keys into recipient structures, adding all of the other information would be a requirement of the application.  

> I would prefer to only have one option to represent the value, namely as an
> integer.
> 
> I also think that you could include a pointer to the appropriate section. While the
> other text in this section points to Section 15.3 I don't believe that this is actually
> correct.
No it was wrong - it should have been a pointer to 15.4, my anchor names were too close together.

> 
> Regarding the fields in the header parameter table I was wondering why not to
> standardize the full list as listed in the table. Currently, a number of entries are
> marked with a "*".

These are all items which I personally am not ready to say are going to make the final cut in the document.   Thus item 1 in the Open issues section below the table.

> 
> Regarding the nonce field do you expect it to also serve as a container for
> sequence numbers or do you plan to add a separate field for it?

My initial idea was that it would be able to hold sequence numbers, however I am no longer sure that I think that is correct.

> 
> What about adding a timestamp field (for an alternative replay protection
> mechanism for those cases where sequences numbers are not appropriate)?

I am very open to defining additional items that are expected to be commonly used.

In terms of timestamps.  How do you believe that they should be defined?  As only positive numbers? As strings? Using the Unix time format?

Jim

---

From: Mike Jones <[email-masked]>
Date: Mon, 31 Aug 2015 20:12:36 +0000

Replies inline below prefixed by Mike> ...

-----Original Message-----
From: COSE [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Monday, August 31, 2015 10:27 AM
To: 'Hannes Tschofenig'; [email-masked]
Subject: Re: [COSE] alg Header Parameter

> From: COSE [mailto:[email-masked]] On Behalf Of Hannes

> Tschofenig

> To: [email-masked]<mailto:[email-masked]>

Mike> I am also strongly against making "alg" optional, as Key IDs need not be unique.  Declaring the algorithm and restricting the recipient to using only that algorithm is key to some of the security guarantees provided by COSE.

> I would prefer to only have one option to represent the value, namely

> as an integer.

Mike> Custom algorithms are likely to be best represented as strings, at least during early deployment.  Once they're in widespread use, integers can be assigned via the registry.

> Regarding the nonce field do you expect it to also serve as a

> container for sequence numbers or do you plan to add a separate field for it?

> protection mechanism for those cases where sequences numbers are not appropriate)?

Mike> The timestamp is typically included in the message payload - not as a header parameter.  For instance, while JWT [RFC 7519] defines the "jti" (JWT ID) claim in http://tools.ietf.org/html/rfc7519#section-4.1.7, this is an optional part of the payload - not part of the header.  The header parameters should normally be just about declaring the cryptographic operations performed on the payload and not used as a general-purpose bag of additional application data, which this timestamp proposal feels like.

The fact that there's not any one clear choice for the representation of the timestamp provides a strong hint that this is the province of the application - not the crypto library.

Jim

> Hannes

_______________________________________________

COSE mailing list

[email-masked]<mailto:[email-masked]>

https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2fcose&data=01%7c01%7cMichael.Jones%40microsoft.com%7c04359d5c50104e8bf5c408d2b229b3cd%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ry%2fmKA939D2PsC8xJBTRb%2fRMvkWmELwU07VCoBbHGb8%3d