Draft: draft-ietf-core-object-security

Commentary: Solves issue ( from review comments by : ) 
 According to  , the change of always including a Partial IV for notifications ( both successful or errors ) complicates the code too much , although it simplifies the spec , so he proposes to revert that change .
Mailing list commentary: 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 do n't plan to set an outer option . In section 5.4 you have the text requestpiv : 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 requestpiv 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 i d.
Paragraph (version A):
The server SHALL include a new Partial IV in responses (with or
without the Observe option) to Observe registrations.
Paragraph (version B):
The server SHALL include a new Partial IV in responses (with or
without the Observe option) to Observe registrations, except for the
first response where Partial IV MAY be omitted.
Paragraph (version A):
If the server accepts an Observe registration, a Partial IV MUST be
included in all notifications (both successful and error).  To
protect against replay, the client SHALL maintain a Notification
Number for each Observation it registers.  The Notification Number is
a non-negative integer containing the largest Partial IV of the
received notifications for the associated Observe registration.
Further details of replay protection of notifications are specified
in replay-notifications.
Paragraph (version B):
If the server accepts an Observe registration, a Partial IV MUST be
included in all notifications (both successful and error), except for
the first one where Partial IV MAY be omitted.  To protect against
replay, the client SHALL maintain a Notification Number for each
Observation it registers.  The Notification Number is a non-negative
integer containing the largest Partial IV of the received
notifications for the associated Observe registration.  Further
details of replay protection of notifications are specified in
replay-notifications.
Paragraph (version A):
A client MUST consider the notification with the highest Partial IV
as the freshest, regardless of the order of arrival.  In order to
support existing Observe implementations the OSCORE client
implementation MAY set the Observe value to the three least
significant bytes of the Partial IV.
Paragraph (version B):
A client MUST consider the notification with the highest Partial IV
as the freshest, regardless of the order of arrival.  In order to
support existing Observe implementations the OSCORE client
implementation MAY set the Observe value to the three least
significant bytes of the Partial IV; such an implementation needs to
make sure that the Observe value for an observe notification without
Partial IV is smaller than a notification with Partial IV.
Paragraph (version A):
The Notification Number is initialized to the Partial IV of the first
successfully verified notification in response to the registration
request.  A client receiving a notification SHALL compare the Partial
IV with the Notification Number associated to that Observe
registration.  The client MUST stop processing notifications with a
Partial IV which has been previously received.  Applications MAY
decide that a client only processes notifications which have greater
Partial IV than the Notification Number.
Paragraph (version B):
The Notification Number is initialized to the Partial IV of the first
successfully verified notification in response to the registration
request.  A client MUST only accept at most one Observe notifications
without Partial IV, and treat it as the oldest notification received.
A client receiving a notification containing a Partial IV SHALL
compare the Partial IV with the Notification Number associated to
that Observe registration.  The client MUST stop processing
notifications with a Partial IV which has been previously received.
Applications MAY decide that a client only processes notifications
which have greater Partial IV than the Notification Number.
Paragraph (version A):
A.  If the request was a registration, encode the Partial IV (Sender
Sequence Number in network byte order) and increment the Sender
Sequence Number by one.  Compute the AEAD nonce from the Sender ID,
Common IV, and Partial IV, then go to 4.
Paragraph (version B):
Encode the Partial IV (Sender Sequence Number in network
byte order) and increment the Sender Sequence Number by one.
Compute the AEAD nonce from the Sender ID, Common IV, and
Partial IV.
Paragraph (version B):
Then go to 4.
Paragraph (version B):
encode the Partial IV (Sender Sequence Number in network byte
order) and increment the Sender Sequence Number by one.
Compute the AEAD nonce from the Sender ID, Common IV, and
Partial IV, then go to 4.
Paragraph (version A):
If the Partial IV is not present in the response, and either the
client has previously received a successful notification to the
registration (active observation) or Inner Observe is present,
then go to 8.
Paragraph (version B):
If the Partial IV is not present in the response, and Inner
Observe is present, and the nonce from the request was already
used once, then go to 8.