Subject: [core] Reading -13

From: Jim Schaad <[email-masked]>
Date: Wed, 11 Jul 2018 10:31:43 -0700

* Section 4.1.3.1 - I am unclear why an OSCORE error response can be cached
by an OSCORE unaware intermediate would be cached, but a success message is
never going to be cached.  Based on this, I don't plan to set an outer
Max-Age option.

* In section 5.4 you have the text

request_piv: contains the value of the 'Partial IV' in the COSE object of
the request (see Section 5), with one exception: in case of protection or
verification of Observe cancellations, the request_piv contains the value of
the 'Partial IV' in the COSE object of the corresponding registration (see
Section 4.1.3.5.1).

I am unclear how/why this is different for observations.   A cancelation is
a message, so the IV is the request.  A re-registration is a request
message, any response would correspond to that request.  The only
interesting question has to do with updating the MID on a re-registration
but not how PIVs work for this field.

* Section 6.1 - Is a registry needed for the leading byte of compression?
Behavior if bits 0, 1, or 2 is set in the flags byte on decode?

* Section C - given the way that my system is implemented, it would be nice
if the outputs included the first full IV to be used for both the sender and
the recipient.  That would allow for a test that the combination of ids and
common ivs is done correctly.  In my case I do not have the shared IV
available for testing as I immediately or in the id.

---

From: Francesca Palombini <[email-masked]>
Date: Tue, 24 Jul 2018 18:08:52 +0000

Hi all,

I just wanted to point to the wg that, following discussion in Montreal, I have now compiled the modifications in 5 different pull requests (inline for links), to simplify the review. Jim has already started reviewing those, please feel free to follow the discussion on the github!  https://github.com/core-wg/oscoap/ 

Thanks Jim for the review and for the useful discussion in Montreal!

Francesca

> -----Original Message-----
> From: Jim Schaad <[email-masked]>
> Sent: den 11 juli 2018 19:32
> To: [email-masked]
> Cc: 'Core' <[email-masked]>
> Subject: Reading -13
> 
> by an OSCORE unaware intermediate would be cached, but a success
> message is never going to be cached.  Based on this, I don't plan to set an
> outer Max-Age option.
> 

Clarified in https://github.com/core-wg/oscoap/pull/235

> request_piv: contains the value of the 'Partial IV' in the COSE object of the
> request (see Section 5), with one exception: in case of protection or
> a message, so the IV is the request.  A re-registration is a request message,
> any response would correspond to that request.  The only interesting
> question has to do with updating the MID on a re-registration but not how
> PIVs work for this field.
> 

Cancellations do not have special processing of request_piv in https://github.com/core-wg/oscoap/pull/236

> Behavior if bits 0, 1, or 2 is set in the flags byte on decode?

Adding a registry in https://github.com/core-wg/oscoap/pull/237

> * Section C - given the way that my system is implemented, it would be nice if
> the outputs included the first full IV to be used for both the sender and the
> recipient.  That would allow for a test that the combination of ids and

Adding the nonces for the test vectors in https://github.com/core-wg/oscoap/pull/239

---

From: Christian Amsüss <[email-masked]>
Date: Wed, 25 Jul 2018 11:39:49 +0200

Hello Francesca,

this all looks very ready to me, especially with the changes after Jim's
comments.

I very much appreciate dropping the request_piv carry-over to
cancellations and the option to send first responses by using the
request PIV (minute comments sent directly to the PR).

Looking forward to updating my implementation, the next interop, and the
publication of OSCORE
Christian

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom