Subject: Re: [COSE] [cose-issues] Move “creation time” value to the payload (#13)

From: Mike Jones <[email-masked]>
Date: Mon, 15 Feb 2016 18:08:23 +0000

Yes, I’ll grant you that the content type value belongs because it’s generally useful and metadata *about* the payload.  Whereas, the creation time field is *part* of the payload.  It also duplicates the CWT issued-at field.  It still needs to be removed to address this issue.  Marking this one as “complete” is an incorrect categorization of the issue.

                                                          -- Mike

From: Jim Schaad [mailto:[email-masked]]
Sent: Tuesday, January 12, 2016 10:42 AM
To: Mike Jones <[email-masked]>
Cc: [email-masked]
Subject: RE: [cose-issues] Move “creation time” value to the payload (#13)

I cannot agree with your ”bright line test”.  I do not believe that this test makes any sense and I do not believe that you have really thought the implications of this rule through.

1.        If this is really the rule to be applied then it makes sense to say that this should be applied to all of the header fields, but that is not what you are doing.  To say that cryptographic rules are required would imply that you should be arguing that the “content type” header field should also be eliminated.  There are no cryptographic rules that are applied to this field either.  You have not been arguing for this field to be removed.

2.       The concept that an application could define a header parameter but this document cannot define the spec means that this is not a rule for the registry, but a rule for the specification.  However, the it makes complete sense for this specification to define those header fields that a significant portion of the community believes that might be useful for applications so that they are in a single specification and likely to be provided by general libraries rather than being in a secondary specification that everybody will need to find and see if it is implemented.

3.       As the specification outlines, there are cases in this document where this field can be used.  To wit counter signatures.  There are a number of other cases where this also makes sense that are not covered in this document because there does not seem to be any reason to cover them as they are deployment specific.  But this could include gateway and proxy signing.  List server signing (CoAP has this concept but calls it something different.) Additionally, the time that a statement is asserted at and the time that the cryptographic operation is done may be different even for a CWT so that if this field was used, it might not agree with the content of the CWT.

4.       The concept of synchronized clocks is not something that should be dismissed out of hand.  If you look at the sensor in my aunt’s backyard, it is a relatively large sensor and has a solar panel to power the battery.  This means that it could easily have a clock configured and potentially even be synchronized.  The size of a sensor varies a lot so that some will be able to have time and some will not.

Jim

From: Mike Jones [mailto:[email-masked]]
Sent: Monday, January 11, 2016 7:43 PM
To: Jim Schaad <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [cose-issues] Move “creation time” value to the payload (#13)

Fair enough.  But there’s nothing stopping the sensor application from defining a header parameter that does exactly what it needs to do, registering it, and using.  The “creation time” parameter implies synchronized clocks, which probably takes it out of applicability in the sensor space already.  There are lots of good application-specific choices.

The bright line test for me that says that this header parameter doesn’t belong in the crypto spec is that there are no cryptographic processing rules for it.  That says that it’s application data – not crypto data.  And as such, it should be defined by applications – not the crypto spec.

Please remove this parameter.

                                                          -- Mike

From: Jim Schaad [mailto:[email-masked]]
Sent: Monday, January 11, 2016 4:07 PM
To: Mike Jones <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [cose-issues] Move “creation time” value to the payload (#13)

I will point out that this is designed to wrap things other than CWT.  If you are wrapping a sensor reading then there is not a CWT involved at that point.

Jim

From: Mike Jones [mailto:[email-masked]]
Sent: Monday, January 11, 2016 12:28 PM
To: Jim Schaad <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [cose-issues] Move “creation time” value to the payload (#13)

I have now.  This still feels like unnecessary duplication of the CBOR Web Token (CWT) “iat” (issued at)<https://tools.ietf.org/html/draft-wahlstroem-ace-cbor-web-token-00#section-3.1.6> claim to me, but I’m curious what others think.

                                                          -- Mike

From: Jim Schaad [mailto:[email-masked]]
Sent: Friday, January 8, 2016 4:16 PM
To: Mike Jones <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [cose-issues] Move “creation time” value to the payload (#13)

Did you read the change in the text that was made at the same time?    It states that “The field is primarily intended to be to be used for countersignatures, however it can additionally be used for replay detection as well.”  It is not possible to put the time field in the content for a countersignature as there is no customizable content in that case.

From: Mike Jones [mailto:[email-masked]]
Sent: Thursday, January 07, 2016 6:34 AM
To: cose-wg/cose-issues <[email-masked]<mailto:[email-masked]>>
Cc: Jim Schaad <[email-masked]<mailto:[email-masked]>>
Subject: Re: [cose-issues] Move “creation time” value to the payload (#13)

Changing the name does not address the core issue that this field is solely for use as defined by particular applications and has no associated COSE processing rules. That says that it belongs in the CBOR Web Token draft, which defines application payload fields, rather than COSE messages spec.

This field also duplicates the CWT "issued at" value at https://tools.ietf.org/html/draft-wahlstroem-oauth-cbor-web-token-00#section-3.1.6. The "operation time" value should be deleted from this specification to eliminate this unnecessary duplication - not just renamed.

—
Reply to this email directly or view it on GitHub<https://github.com/cose-wg/cose-issues/issues/13#issuecomment-169680402>.

---

From: Ludwig Seitz <[email-masked]>
Date: Tue, 16 Feb 2016 10:34:15 +0100

On 02/15/2016 07:08 PM, Mike Jones wrote:
> Yes, I’ll grant you that the content type value belongs because it’s
> generally useful and metadata **about** the payload.  Whereas, the
> creation time field is **part** of the payload.  It also duplicates the
> CWT issued-at field.  It still needs to be removed to address this
> issue.  Marking this one as “complete” is an incorrect categorization of
> the issue.
>
>                                                            -- Mike

I find this distinction artificial. Creation time can just as well be 
seen as metadata about the payload as content type.
Furthermore, as you said, the 'issued-at' field is part of CWT (as in 
Cose-Oauth tokens). We plan to use Cose for a number of different 
payloads, where not all of those are CWTs.
Providing a standardized way to indicate the creation time of a Cose 
object (e.g. to allow for replay protection, expiration, and to protect 
against reordering) seems like a reasonable security objective to me.

If we instead push this down to the applications, we risk getting a 
number of different incompatible specifications.

Regards,

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 9251
http://www.sics.se