Subject: [COSE] [Technical Errata Reported] RFC8152 (5669)

From: RFC Errata System <[email-masked]>
Date: Sat, 23 Mar 2019 10:26:49 -0700 (PDT)

The following errata report has been submitted for RFC8152,
"CBOR Object Signing and Encryption (COSE)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5669

--------------------------------------
Type: Technical
Reported by: Marco Tiloca <[email-masked]>

Section: 16.7

Original Text
-------------
Value:  This is the value used to identify the curve.  These values
   MUST be unique.  The value can be a positive integer, a negative
   integer, or a string.

Description:  This field contains a brief description of the curve.

References:  This contains a pointer to the public specification for
   the curve if one exists.

Corrected Text
--------------
Value:  This is the value used to identify the key type.  These values
   MUST be unique.  The values are positive integers.

Description:  This field contains a brief description of the key type.

References:  This contains a pointer to the public specification for
   the key type if one exists.

Notes
-----
This Registry is about Key Types, but the current text refers to curves.

The value identifying a key type can be only a positive integer.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC8152 (draft-ietf-cose-msg-24)
--------------------------------------
Title               : CBOR Object Signing and Encryption (COSE)
Publication Date    : July 2017
Author(s)           : J. Schaad
Category            : PROPOSED STANDARD
Source              : CBOR Object Signing and Encryption
Area                : Security
Stream              : IETF
Verifying Party     : IESG

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 23 Mar 2019 17:11:19 -0500

> "CBOR Object Signing and Encryption (COSE)".

This seems pretty straightforward, but I'm not entirely sure how to confirm
that the key types are always positive integers (with 0 reserved).

Thanks,

Ben

---

From: Jim Schaad <[email-masked]>
Date: Sun, 24 Mar 2019 09:27:50 +0100

In the CBOR encoding it is pretty simple as non-negative integers and
negative integers are encoded as separate types.

Jim

> -----Original Message-----
> From: Benjamin Kaduk <[email-masked]>
> Sent: Saturday, March 23, 2019 11:11 PM
> To: RFC Errata System <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Technical Errata Reported] RFC8152 (5669)
> 
> > The following errata report has been submitted for RFC8152, "CBOR
> > Object Signing and Encryption (COSE)".
> >

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 24 Mar 2019 08:48:08 -0500

> negative integers are encoded as separate types.

Right.  But if I look at, e.g.,

   COSE_Key = {
       1 => tstr / int,          ; kty
       ? 2 => bstr,              ; kid
       ? 3 => tstr / int,        ; alg
       ? 4 => [+ (tstr / int) ], ; key_ops
       ? 5 => bstr,              ; Base IV
       * label => values
   }

that has 'kty' as tstr / int, and 'int' is defined as either an unsigned
integer or a negative integer, so that doesn't really force it to be in the
unsigned space.

(I'm not terribly sure that that's the right CDDL in which values from the
registry go, though.)

-Ben

---

From: Jim Schaad <[email-masked]>
Date: Sun, 24 Mar 2019 15:16:02 +0100

Yeah, that is a cut and paste error.  I just make everything be the generic
type and forgot to clean them down.

Should do that as part of the bis update.

Jim

> Sent: Sunday, March 24, 2019 2:48 PM
> To: Jim Schaad <[email-masked]>
> Cc: 'RFC Errata System' <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]
integer or a
> negative integer, so that doesn't really force it to be in the unsigned
space.

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 25 Mar 2019 15:49:36 -0500

> Should do that as part of the bis update.

Okay.  So it sounds like we do intend for this to be uint, so I should take
the errata as-is?

Thanks,

Ben

---

From: Jim Schaad <[email-masked]>
Date: Mon, 25 Mar 2019 22:36:45 +0100

Yes, I will then make the appropriate edits and ensure that everything is
right, even if it is not exactly what the errata says.

> Sent: Monday, March 25, 2019 9:50 PM
> > Yeah, that is a cut and paste error.  I just make everything be the
> > generic type and forgot to clean them down.
> >
> Okay.  So it sounds like we do intend for this to be uint, so I should
take the
> errata as-is?
> > > > In the CBOR encoding it is pretty simple as non-negative integers
> > > > and negative integers are encoded as separate types.
> > >
> > > (I'm not terribly sure that that's the right CDDL in which values
> > > from the registry go, though.)
> > >
> > > -Ben
> >