jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-cose-countersign

Commentary: These all looks like straightforward and necessary changes .
There has been an increased focus on small, constrained devices that
make up the Internet of Things (IoT).  One of the standards that has
come out of this process is "Concise Binary Object Representation
(CBOR)" I-D.ietf-cbor-7049bis.  CBOR extended the data model of the
JavaScript Object Notation (JSON) STD90 by allowing for binary data,
among other changes.  CBOR has been adopted by several of the IETF
working groups dealing with the IoT world as their encoding of data
structures.  CBOR was designed specifically both to be small in terms
of messages transported and implementation size and to be a schema-
free decoder.  A need exists to provide message security services for
IoT, and using CBOR as the message-encoding format makes sense.
There has been an increased focus on small, constrained devices that
make up the Internet of Things (IoT).  One of the standards that has
come out of this process is "Concise Binary Object Representation
(CBOR)" RFC8949.  CBOR extended the data model of the JavaScript
Object Notation (JSON) STD90 by allowing for binary data, among other
changes.  CBOR has been adopted by several of the IETF working groups
dealing with the IoT world as their encoding of data structures.
CBOR was designed specifically both to be small in terms of messages
transported and implementation size and to be a schema-free decoder.
A need exists to provide message security services for IoT, and using
CBOR as the message-encoding format makes sense.
in I-D.ietf-core-groupcomm-bis.
in I-D.ietf-core-oscore-groupcomm.
In order to always regenerate the same byte string for the "to be
signed" value, the deterministic encoding rules defined in I-D.ietf-
cbor-7049bis.  These rules match the ones laid out in I-D.ietf-cose-
rfc8152bis-struct.
In order to always regenerate the same byte string for the "to be
signed" value, the deterministic encoding rules defined in RFC8949.
These rules match the ones laid out in I-D.ietf-cose-rfc8152bis-
struct.
Draft: draft-ietf-cose-countersign

Commentary: < tWhen either COSEEncrypt and COSEMac is used and more than two parties share the key , data origin authentication is not provided . Any party that knows the message - authentication key can compute a valid authentication tag ; therefore , the contents could originate from any one of the parties that share the key.</t < tCountersignatures of COSEEncrypt and COSEMac with short authentication tags do not provide the security properties associated with the same algorithm used in COSESign . To provide 128 - bit security against collision attacks , the tag length MUST be at least 256 - bits . A countersignature of a COSEMac with AES - MAC 256/128 provides at most 64 bits of integrity protection . Similarly , a countersignature of a COSE_Encrypt with AES - CCM-16 - 64 - 128 provides at most 32 bits bits of integrity protection.</t
When either COSE_Encrypt and COSE_Mac is used and more than two
parties share the key, data origin authentication is not provided.
Any party that knows the message-authentication key can compute a
valid authentication tag; therefore, the contents could originate
from any one of the parties that share the key.
Countersignatures of COSE_Encrypt and COSE_Mac with short
authentication tags do not provide the security properties associated
with the same algorithm used in COSE_Sign.  To provide 128-bit
security against collision attacks, the tag length MUST be at least
256-bits.  A countersignature of a COSE_Mac with AES-MAC 256/128
provides at most 64 bits of integrity protection.  Similarly, a
countersignature of a COSE_Encrypt with AES-CCM-16-64-128 provides at
most 32 bits bits of integrity protection.
Draft: draft-ietf-cose-countersign

Commentary: Remove the sections from the Examples Applenix that were blank , clean up the Security Considerations , and narrow the table in the IANA considerations . 
 Looks good to me ! Thanks ! Let us know if you want us to merge it or you plan to do that yourself .
An example of a countersignature on a signature can be found in
Appendix_B_1_3.  An example of a countersignature in an encryption
object can be found in Appendix_B_3_3.
An example of a countersignature on a signature can be found in
Appendix_A_1_1.  An example of a countersignature in an encryption
object can be found in Appendix_A_2_1.
IANA is requested to register the following new items in the
registry.
IANA is requested to register the following new items in the
registry.  For these entries, the Value Registry column will be blank
and the Reference column will be .
TODO - review and trim as needed.
Although it has been mentioned before, the use of a single key for
multiple algorithms has been demonstrated in some cases to leak
information about that key, provide the opportunity for attackers to
forge integrity tags, or gain information about encrypted content.
Binding a key to a single algorithm prevents these problems.  Key
creators and key consumers are strongly encouraged not only to create
new keys for each different algorithm, but to include that selection
of algorithm in any distribution of key material and strictly enforce
the matching of algorithms in the key structure to algorithms in the
message structure.  In addition to checking that algorithms are
correct, the key form needs to be checked as well.  Do not use an
'EC2' key where an 'OKP' key is expected.
Although it has been mentioned before, the use of a single key for
multiple algorithms has been demonstrated in some cases to leak
information about that key, provide the opportunity for attackers to
forge integrity tags, or gain information about encrypted content.
Binding a key to a single algorithm prevents these problems.
Key creators and key consumers are strongly encouraged not only to
create new keys for each different algorithm, but to include that
selection of algorithm in any distribution of key material and
strictly enforce the matching of algorithms in the key structure to
algorithms in the message structure.  In addition to checking that
algorithms are correct, the key form needs to be checked as well.  Do
not use an 'EC2' key where an 'OKP' key is expected.
Draft: draft-ietf-cose-countersign

Commentary: Add   as a document editor . No changes to the body of the document .
The source for this draft is being maintained in GitHub.  Suggested
changes should be submitted as pull requests at <https://github.com/
cose-wg/cose-rfc8152bis>.  Instructions are on that page as well.
Editorial changes can be managed in GitHub, but any substantial
issues need to be discussed on the COSE mailing list.
The source for this draft is being maintained in GitHub.  Suggested
changes should be submitted as pull requests at <https://github.com/
cose-wg/countersign>.  Instructions are on that page as well.
Editorial changes can be managed in GitHub, but any substantial
issues need to be discussed on the COSE mailing list.