jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-core-object-security

Commentary: Solves issue ( from review comments by : )
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 B):
The flag bits are registered in the OSCORE Octet registry specified
in oscore-octet.
Paragraph (version B):
It is requested that IANA create a new registry entitled "OSCORE
Octet".  The registry should be created with the Expert Review
policy.  Guidelines for the experts are provided in exp-instr.
Paragraph (version B):
bit position: This indicates the position of the bit in the OSCORE
Octet, starting at 0 for the most significant bit.  The bit
position must be an integer or a range of integers, in the range 0
to 63.
Paragraph (version B):
name: The name is present to make it easier to refer to and
discuss the registration entry.  The value is not used in the
protocol.  Names are to be unique in the table.
Paragraph (version B):
description: This contains a brief description of the use of the
bit.
Paragraph (version B):
specification: This contains a pointer to the specification
defining the entry.
Paragraph (version B):
The initial contents of the registry can be found in _table-flagbyte.
The specification column for all rows in that table should be this
document.  Additionally, the entry with Bit Position of 0 is to be
marked as 'Reserved'.  This entry is going to be specified in a
future document, and will be used to expand the OSCORE Octet in obj-
sec-value, so that entries 8-63 of the registry are defined.
Draft: draft-ietf-core-object-security

Commentary: I believe this is about the minimum change that we can make to avoid the need for a normative reference to draft - ietf - cbor - cddl , which might hold up the document in the RFC editor queue . 
 Thank you the only thing I can think of is adding a reference to CBOR in the appendix too , but that 's it .
Paragraph (version A):
Readers are expected to be familiar with the terms and concepts
described in CoAP RFC7252, Observe RFC7641, Blockwise RFC7959, COSE
RFC8152, CBOR RFC7049, CDDL I-D.ietf-cbor-cddl, and constrained
environments RFC7228.
Paragraph (version B):
Readers are expected to be familiar with the terms and concepts
described in CoAP RFC7252, Observe RFC7641, Blockwise RFC7959, COSE
RFC8152, CBOR RFC7049, CDDL I-D.ietf-cbor-cddl as summarized in cddl-
sum, and constrained environments RFC7228.
Draft: draft-ietf-core-object-security

Commentary: Removes the use of 2.05 for Fetch requests . See
Paragraph (version A):
The sending endpoint SHALL write the Code of the original CoAP
message into the plaintext of the COSE object plaintext.  After that,
the Outer Code of the OSCORE message SHALL be set to 0.02 (POST) for
requests and to 2.04 (Changed) for responses, except for Observe
messages.  For Observe messages, the Outer Code of the OSCORE message
SHALL be set to 0.05 (FETCH) for requests and to 2.05 (Content) for
responses.  This exception allows OSCORE to be compliant with the
Observe processing in OSCORE-unaware proxies.  The choice of POST and
FETCH (RFC8132) allows all OSCORE messages to have payload.
Paragraph (version B):
The sending endpoint SHALL write the Code of the original CoAP
message into the plaintext of the COSE object plaintext.  After that,
the Outer Code of the OSCORE message SHALL be set to 0.02 (POST) for
requests without Observe option, to 0.05 (FETCH) for requests with
Observe option, and to 2.04 (Changed) for responses.  Using FETCH
with Observe allows OSCORE to be compliant with the Observe
processing in OSCORE-unaware proxies.  The choice of POST and FETCH
(RFC8132) allows all OSCORE messages to have payload.
Draft: draft-ietf-core-object-security

Commentary: As suggested in 
 Need to update example as well 
 Not on expert on HTPP header formats , but are single quotes '' correct ? I think I have only seen double quotes " " in HTTP . 
 should be fixed now 
 " The value of the payload " It is called body in HTTP 
  suggested to not have an empty HTTP header ( legal but likely to create problems ) , instead use : " "
Paragraph (version A):
The presence of the Object-Security option, both in requests and
responses, is expressed in an HTTP header field named Object-Security
in the mapped request or response.  The value of the field is the
value of the Object-Security option obj-sec-value in base64url
encoding (Section 5 of RFC4648) without padding (see RFC7515
Appendix C for implementation notes for this encoding).  The value of
the payload is the OSCORE payload oscore-payl, also base64url-encoded
without padding.
Paragraph (version B):
the value of the CoAP Object-Security option obj-sec-value in
base64url encoding (Section 5 of RFC4648) without padding (see
RFC7515 Appendix C for implementation notes for this encoding).
Paragraph (version B):
The value of the body is the OSCORE payload oscore-payl.
Draft: draft-ietf-core-object-security

Commentary: This implements the change I suggested in , ie move everything but the ciphertext from CoAP payload to the option value . The text about kid being the last field is a draft , please modify if you have any better formulation .
Paragraph (version A):
The Object-Security option contains the OSCORE flag byte and for
requests, the Sender ID (see compression).  If the flag byte is all
zero (0x00) the Option value SHALL be empty (Option Length = 0).  An
endpoint receiving a CoAP message without payload, that also contains
an Object-Security option SHALL treat it as malformed and reject it.
Paragraph (version B):
The Object-Security option contains the OSCORE flag byte, the Sender
Sequence Number and the Sender ID when present, (see compression).
If the flag byte is all zero (0x00) and no other fields are present,
the Option value SHALL be empty (Option Length = 0).  An endpoint
receiving a CoAP message without payload, that also contains an
Object-Security option SHALL treat it as malformed and reject it.
Paragraph (version A):
The three least significant bits, n, encode the Partial IV
length.  If n = 0 then the Partial IV is not present in the
compressed COSE object.  The values n = 6 and n = 7 is
reserved.
Paragraph (version B):
The three least significant bits encode the Partial IV length
n.  If n = 0 then the Partial IV is not present in the
compressed COSE object.  The values n = 6 and n = 7 is
reserved.
Paragraph (version A):
The first n bytes encode the value of the Partial IV, if the
Partial IV is present (n > 0).
Paragraph (version A):
The following 1 byte encode the length of the Context Hint
(context-hint), s, if the Context Hint flag is set (h = 1).
Paragraph (version A):
The remaining bytes encode the ciphertext.
Paragraph (version B):
The following n bytes encode the value of the Partial IV, if the
Partial IV is present (n > 0).
Paragraph (version B):
The following 1 byte encode the length of the Context Hint
(context-hint) s, if the Context Hint flag is set (h = 1).
Paragraph (version B):
Note that the kid MUST be the last field of the object-security
value, even in case reserved bits are used and additional fields are
added to it.
Paragraph (version B):
The payload of the OSCORE message SHALL encode the ciphertext.
Draft: draft-ietf-core-object-security

Commentary: Not a grave issue , but it 's a leak of information that can be reduced to leaking unexpected reboots vs. leaking any reboot by being aware of it . 
 Thanks , I am just confused by the term " clean shutdown " here . What do you mean by that ? If I understand correctly the rest of your text , you are suggesting that to avoid leaking information about accidental reboots , the device keeps track of the node 's state constantly , so that when an accidental reboot happens , the node can re - instate the right seq . When does clean shutdown come into the picture ? 
 Typical devices can not tolerate the flash wear of writing the sequence number state on any package transmission ( that 's why there 's the " Seq + K " part in 6.3.1 ) , and that limitation wo n't go away just because it has privacy consequences . Accidental reboots will thus be leaked , but deliberate ones can be hidden by storing the fine - grained seqno state on flash . For example : Initial boot , everything is 0 Before sending package 1 , write " seqno=1000 " Send 999 more packages w/o writing Before sending package 1001 , write " seqno=2000 " Send some more packages w/o writing  , reboot ! Before sending seqno 2001 , write " seqno=3000 " ( this is a hard to prevent leak ) Send 49 more packages Shutdown requested , write " seqno=2050 " Reboot Before sending seqno=2051 , write " seqno=3050 " ( no reboot leaked )
Paragraph (version B):
Using the mechanisms described in seqno-replay-state reveals when a
device goes through a reboot.  This can be mitigated by the device
storing the precise state of sender sequence number and recipient
replay window on a clean shutdown.
Draft: draft-ietf-core-object-security

Commentary: , and 
 This goes against  's wish to have things in bits rather than bytes ... But HKDF uses octets and to combine the two parameters as wanted by Ludwig , they need the same unit . 
 Fixed in branch v-02 
 OSCOAP refers to HKDF [ RFC5869 ] , but it not clearly defined how the parameters map to HKDF - Extract and HKDF - Expand . E.g. IKM . Salt should be made optional . 
 In section 3.2.1 .  is defined as " the key / IV size of the AEAD algorithm " and outputlength as " is the size of the AEAD key / IV in bytes encoded as an 8 - bit unsigned integer " Is n't that essentially the same ? 
 I just created a v-02 branch for the next update . I 'll make an update as soon as possible trying to address this . 
 Fixed in brach v-02
Paragraph (version A):
Base Key (master_secret).  Variable length, uniformly random byte
string containing the key used to derive traffic keys and IVs.
Its value is immutable once the security context is established.
Paragraph (version B):
Master Secret.  Variable length, uniformly random byte string
containing the key used to derive traffic keys and IVs.  Its value
is immutable once the security context is established.
Paragraph (version B):
Master Salt (OPTIONAL).  Variable length byte string containing
the salt used to derive traffic keys and IVs.  Its value is
immutable once the security context is established.
Paragraph (version A):
The 3-tuple (Cid, Sender ID, Partial IV) is called Transaction
Identifier (Tid), and SHALL be unique for each Base Key. The Tid is
used as a unique challenge in the COSE object of the protected CoAP
request.  The Tid is part of the Additional Authenticated Data (AAD,
see sec-obj-cose) of the protected CoAP response message, which is
how responses are bound to requests.
Paragraph (version B):
The 3-tuple (Cid, Sender ID, Partial IV) is called Transaction
Identifier (Tid), and SHALL be unique for each Master Secret.  The
Tid is used as a unique challenge in the COSE object of the protected
CoAP request.  The Tid is part of the Additional Authenticated Data
(AAD, see sec-obj-cose) of the protected CoAP response message, which
is how responses are bound to requests.
Paragraph (version A):
For example, if the algorithm AES-CCM-64-64-128 (see Section 10.2 in
I-D.ietf-cose-msg) is used, output_length for the keys is 128 bits
and output_length for the IVs is 56 bits.
Paragraph (version B):
L is the key/IV size of the AEAD algorithm in octets without
leading zeroes.
Paragraph (version B):
For example, if the algorithm AES-CCM-64-64-128 (see Section 10.2 in
I-D.ietf-cose-msg) is used, L is 16 bytes for keys and 7 bytes for
IVs.
Draft: draft-ietf-core-object-security

Commentary: This should fix issue 
 As per Christian Amsüss ' message from 2017 - 01 - 04 we should clarify how we expect implementers to map sequence numbers to partial IV 's . I think that network - byte order is a good way .
Paragraph (version A):
The AEAD algorithm AES-CCM-64-64-128 defined in Section 10.2 of I-
D.ietf-cose-msg is mandatory to implement.  For AES-CCM-64-64-128 the
length of Sender Key and Recipient Key SHALL be 128 bits, the length
of nonce, Sender IV, and Recipient IV SHALL be 7 bytes, and the
maximum Sequence Number SHALL be 2^56-1.  The nonce is constructed as
described in Section 3.1 of I-D.ietf-cose-msg, i.e. by padding the
Partial IV (Sequence Number) with zeroes and XORing it with the
context IV (Sender IV or Recipient IV).
Paragraph (version B):
The AEAD algorithm AES-CCM-64-64-128 defined in Section 10.2 of I-
D.ietf-cose-msg is mandatory to implement.  For AES-CCM-64-64-128 the
length of Sender Key and Recipient Key SHALL be 128 bits, the length
of nonce, Sender IV, and Recipient IV SHALL be 7 bytes, and the
maximum Sequence Number SHALL be 2^56-1.  The nonce is constructed as
described in Section 3.1 of I-D.ietf-cose-msg, i.e. by padding the
Partial IV (Sequence Number in network byte order) with zeroes and
XORing it with the context IV (Sender IV or Recipient IV).
Paragraph (version A):
the AEAD nonce is created by XORing the Sender IV (context IV)
with the Sender Sequence Number (partial IV).
Paragraph (version B):
the AEAD nonce is created by XORing the Sender IV (context IV)
with the Sender Sequence Number in network byte order (partial
IV).
Draft: draft-ietf-core-object-security

Commentary: I do n't know why your commit got included . 
 I think I do : I modified the commit in order to add the description ( to close issues ) . Now there are 2 identical commits , one is the one above ( ) that does not close issues , the other is the one in the master branch ( ) 
 Thanks for your contribution
Paragraph (version B):
Applications need to use a padding scheme if the content of a message
can be determined solely from the length of the payload.  As an
example, the strings "YES" and "NO" even if encrypted can be
distinguished from each other as there is no padding supplied by the
current set of encryption algorithms.  Some information can be
determined even from looking at boundary conditions.  An example of
this would be returning an integer between 0 and 100 where lengths of
1, 2 and 3 will provide information about where in the range things
are.  Three different methods to deal with this are: 1) ensure that
all messages are the same length.  For example using 0 and 1 instead
of 'yes' and 'no'.  2) Use a character which is not part of the
responses to pad to a fixed length.  For example, pad with a space to
three characters.  3) Use the PKCS #7 style padding scheme where m
bytes are appended each having the value of m.  For example,
appending a 0 to "YES" and two 1's to "NO".  This style of padding
means that all values need to be padded.