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

Commentary: Pickup the corrected text from Alexey
This parameter is used to indicate the content type of the data in
the payload or cipher text fields.  Integers are from the "CoAP
Content-Formats" IANA registry table COAP.Formats.  Text values
following the syntax of Content-Type defined in Section 4.2 of
RFC6838 omitting the prefix string "Content-Type:".  Leading and
trailing whitespace is also omitted.  Textual content values along
with parameters and subparameters can be located using the IANA
"Media Types" registry.  Applications SHOULD provide this
parameter if the content structure is potentially ambiguous.
This parameter is used to indicate the content type of the data in
the payload or cipher text fields.  Integers are from the "CoAP
Content-Formats" IANA registry table COAP.Formats.  Text values
following the syntax of "<type-name>/<subtype-name>" where <type-
name> and <subtype-name> are defined in Section 4.2 of RFC6838.
Leading and trailing whitespace is also omitted.  Textual content
values along with parameters and subparameters can be located
using the IANA "Media Types" registry.  Applications SHOULD
provide this parameter if the content structure is potentially
ambiguous.
Draft: draft-ietf-cose-msg

Commentary: Not all , but the highlite ones have been modified
Recipient algorithms can be defined into a number of different
classes.  COSE has the ability to support many classes of recipient
algorithms.  In this section, a number of classes are listed and then
a set of algorithms are specified for each of the classes.  The names
of the recipient algorithm classes used here are the same as are
defined in RFC7516.  Other specifications use different terms for the
recipient algorithm classes or do not support some of the recipient
algorithm classes.
Content key distribution methods (recipient algorithms) can be
defined into a number of different classes.  COSE has the ability to
support many classes of recipient algorithms.  In this section, a
number of classes are listed and then a set of algorithms are
specified for each of the classes.  The names of the recipient
algorithm classes used here are the same as are defined in RFC7516.
Other specifications use different terms for the recipient algorithm
classes or do not support some of the recipient algorithm classes.
Draft: draft-ietf-cose-msg

Commentary: Round with Stephen .
This parameter is used to indicate the content type of the data in
the payload or cipher text fields.  Integers are from the "CoAP
Content-Formats" IANA registry table.  Text values following the
syntax of Content-Type defined in Section 5.1 of RFC2045 omitting
the prefix string "Content-Type:".  Leading and trailing
whitespace is also omitted.  Textual content values along with
parameters and subparameters can be located using the IANA "Media
Types" registry.  Applications SHOULD provide this parameter if
the content structure is potentially ambiguous.
This parameter is used to indicate the content type of the data in
the payload or cipher text fields.  Integers are from the "CoAP
Content-Formats" IANA registry table COAP.Formats.  Text values
following the syntax of Content-Type defined in Section 5.1 of
RFC2045 omitting the prefix string "Content-Type:".  Leading and
trailing whitespace is also omitted.  Textual content values along
with parameters and subparameters can be located using the IANA
"Media Types" registry.  Applications SHOULD provide this
parameter if the content structure is potentially ambiguous.
This parameter holds the Initialization Vector (IV) value.  For
some symmetric encryption algorithms this may be referred to as a
nonce.  As the IV is authenticated by the encryption process, it
can be placed in the unprotected header bucket.
This parameter holds the Initialization Vector (IV) value.  For
some symmetric encryption algorithms this may be referred to as a
nonce.  The IV can be placed in the unprotected header as
modifying the IV will cause the decryption to yield plaintext that
is readily detectable as garbled.
Draft: draft-ietf-cose-msg

Commentary: Fix a couple of small errors
Concise Binary Object Representation (CBOR) is data format designed
for small code size and small message size.  There is a need for the
ability to have the basic security services defined for this data
format.  This document defines the CBOR Object Signing and Encyption
(COSE) specification.  This specification describes how to create and
process signature, message authentication codes and encryption using
CBOR for serialization.  This specification additionally specifies
how to represent cryptographic keys using CBOR.
Concise Binary Object Representation (CBOR) is data format designed
for small code size and small message size.  There is a need for the
ability to have the basic security services defined for this data
format.  This document defines the CBOR Object Signing and Encryption
(COSE) specification.  This specification describes how to create and
process signature, message authentication codes and encryption using
CBOR for serialization.  This specification additionally specifies
how to represent cryptographic keys using CBOR.
The 'kty' field MUST be present and it MUST be 'OKP'.
If the 'alg' field present, it MUST match the ChaCha algorithm
being used.
If the 'alg' field present, it MUST match the ChaCha20/Poly1305
algorithm being used.
This field holds information about party V.  The content of the
structure are the same as for the PartyUInfo but for partyV.
This field holds information about party V.  The content of the
structure are the same as for the PartyUInfo but for party V.
The Encoding column for all of the above registrations is empty.
Have any security considerations that are part of the message been
enforced (as specified by the application or crit parameter)?
Have any security considerations that are part of the message been
enforced (as specified by the application or 'crit' parameter)?
Draft: draft-ietf-cose-msg

Commentary: We change the title of the document Implement the suggested change from Carsten that we put nils in to unused elements in the ParytInfo structure . I was a bit more complete than the original suggestion but it is probably simpler to get right that way . 
 It may be better to use the CBOR tag 24 rather than a bstr wrapper for the protected attributes field . The major question that needs to be addressed is how this is treated by existing parsers - will they try and decode it anyway or will the wait to decode them later . It is going to be required that they are both decode later and immutable to changes if they run through an intermediary which will decode , modify and re - encode any of the top level information . I do n't believe that there is any benefits to using this rather than bstr for the payload field on signatures and macs since they could be any data type inside rather than a fixed one . 
 Did not correctly read the spec .
Concise Binary Object Representation (CBOR) is data format designed
for small code size and small message size.  There is a need for the
ability to have the basic security services defined for this data
format.  This document specifies processing for signatures, message
authentication codes, and encryption using CBOR.  This document also
specifies a representation for cryptographic keys using CBOR.
Concise Binary Object Representation (CBOR) is data format designed
for small code size and small message size.  There is a need for the
ability to have the basic security services defined for this data
format.  This document defines the CBOR Object Signing and Encyption
(COSE) specification.  This specification describes how to create and
process signature, message authentication codes and encryption using
CBOR for serialization.  This specifiction additionally specifies how
to representat cryptographic keys using CBOR.
identity information does not need to be specified and can be
left as absent.
identity information does not need to be specified and is set
to nil in that case.
This contains a nonce value.  The nonce can either be implicit
from the protocol or carried as a value in the unprotected
headers.
We define an algorithm parameter 'PartyU nonce' that can be
used to carry this value in the message However, the nonce
value could be determined by the application and the value
determined from elsewhere.
This item is optional and can be absent.
This contains other information that is defined by the
protocol.
This item is optional and can be absent.
Draft: draft-ietf-cose-msg

Commentary: Create MAC as separate key operations per issue 
 Should we attempt to add the MACverify and MACcreate elements to the key_ops field since we have decided to distinguish between a signature and a MAC - or do we keep the same signature / verify tags that are currently used in the JWK document ?
If the 'key_ops' field is present, it MUST include 'sign' when
creating an HMAC authentication tag.
If the 'key_ops' field is present, it MUST include 'verify' when
verifying an HMAC authentication tag.
If the 'key_ops' field is present, it MUST include 'MAC create'
when creating an HMAC authentication tag.
If the 'key_ops' field is present, it MUST include 'MAC verify'
when verifying an HMAC authentication tag.
If the 'key_ops' field is present, it MUST include 'sign' when
creating an AES-MAC authentication tag.
If the 'key_ops' field is present, it MUST include 'verify' when
verifying an AES-MAC authentication tag.
If the 'key_ops' field is present, it MUST include 'MAC create'
when creating an AES-MAC authentication tag.
If the 'key_ops' field is present, it MUST include 'MAC verify'
when verifying an AES-MAC authentication tag.
Draft: draft-ietf-cose-msg

Commentary: Also pickup the last WGLC from Francesca 
 Currently not a good header for that bullet 
 Fixed in
Curve Type/Curve: The curve selected controls not only the size of
the shared secret, but the mathematics for computing the shared
secret.  The curve selected also controls how a point in the curve
is represented and what happens for the identity points on the
curve.  In this specification, we allow for a number of different
curves to be used.  A set of curves are defined in table-ec-
curves.
Since the only the math is changed by changing the curve, the
curve is not fixed for any of the algorithm identifiers we define.
Shared Secret to Byte String: Once the shared secret is computed
using the correct mathematics, the resulting value needs to be
converted to a byte string to run the KDF function.  The X
coordinate is used for all of the curves defined in this document.
For curves X25519 and X448, the resulting value is used directly
as it is a byte string of a known length.  For the P-256, P-384
and P-521 curves, the X coordinate is run through the I2OSP
function defined in RFC3447 using the same computation for n as is
defined in ECDSA.
Curve Type/Curve: The curve selected controls not only the size of
the shared secret, but the mathematics for computing the shared
secret.  The curve selected also controls how a point in the curve
is represented and what happens for the identity points on the
curve.  In this specification, we allow for a number of different
curves to be used.  A set of curves are defined in table-ec-
curves.
The math used to obtain the computed secret is based on the curve
selected and not on the ECDH algorithm.  For this reason, a new
algorithm does not need to be defined for each of the curves.
Computed Secret to Shared Secret: Once the computed secret is
known, the resulting value needs to be converted to a byte string
to run the KDF function.  The X coordinate is used for all of the
curves defined in this document.  For curves X25519 and X448, the
resulting value is used directly as it is a byte string of a known
length.  For the P-256, P-384 and P-521 curves, the X coordinate
is run through the I2OSP function defined in RFC3447 using the
same computation for n as is defined in ECDSA.
Draft: draft-ietf-cose-msg

Commentary: This is basically the text that Ludwig agreed to . Will seek second confirmation for issue 
 In Section 13.2 . there is the following text : " This key structure contains only private key information , care must be taken that it is never transmitted accidentally . For public keys , there are no required fields . For private keys , it is REQUIRED that ' k ' be present in the structure . " This should probably read something like this : " This key structure only contains secret ( or symmetric ) key information , care must be taken that it is never transmitted accidentally . For symmetric keys , it is REQUIRED that ' k ' be present in the structure . " 
 What if we change it to be This key structure does not have a form that contains only public members . For symmetric keys , it is REQUIRED that ' k ' be present in the structure . 
 I really have nothing against the " care must be taken ... " part . I 'd actually tend to leave it in , but feel free to rephrase that as you see fit .
This key structure contains only private key information; care must
be taken that it is never transmitted accidentally.  For public keys,
there are no required fields.  For private keys, it is REQUIRED that
'k' be present in the structure.
This key structure does not have a form which contains only public
members.  As it is expected that this key structure is going to be
transmitted, care must be taking that it is never transmitted
accidentally or insecurely.  For symmetric keys, it is REQUIRED that
'k' be present in the structure.
Draft: draft-ietf-cose-msg

Commentary: Response to note from Göran Selander 1 ) we need to say where the secret is derived from 2 ) how it is formatted , and 3 ) why we are not using KA and  in the KDF step .
Shared Secret to Byte String: Once the shared secret is computed
using the correct mathematics, the resulting value needs to be
converted to a byte string to run the KDF function.  The X
coordinate is used for all of the curves defined in this document.
For curves X25519 and X448, the resulting value is used directly
as it is a byte string of a known length.  For the P-256, P-384
and P-521 curves, the X coordinate is run through the I2OSP
function defined in RFC3447 using the same computation for n as is
defined in ECDSA.
Some method of checking that points provided from external entities
are valid.  For the 'EC2' key format, this can be done by checking
that the x and y values form a point on the curve.  For the 'OKP'
format, there is no simple way to do point validation.
Consideration was given to requiring that the public keys of both
entities be provided as part of the key derivation process.  (As
recommended in section 6.1 of RFC7748.)  This was not done as COSE is
used in a store and forward format rather than in on line key
exchange.  In order for this to be a problem, either the receiver
public key has to be chosen maliciously or the sender has to be
malicious.  In either case, all security evaporates anyway.
Draft: draft-ietf-cose-msg

Commentary: Get the first cut of A.2 out
This document is a product of the COSE working group of the IETF.
Draft: draft-ietf-cose-msg

Commentary: Deal with issues 61 and 54 from the issues tracker . Also pickup a typo from Göran .
This parameter is defined to carry the base portion of an IV.  It
is designed to be used with the partial IV header parameter
defined in cose-headers.  This field provides the ability to
associate a partial IV with a key that is then modified on a per
message basis with the parital IV.
Care needs to be taken that this is only used as part of a key
distribution algorithm that will ensure that it will be given only
to parties that will use it correctly.  This is due to the fact
that many of the content encryption algorithms defined for COSE
require that IVs be unique for every message.  Use of this field
will easily allow for this rule to be broken if not used
carefully.  This field MUST be ignored unless an application
specifically calls for its use.
It is requested that IANA assign the following tags from the "Concise
Binary Object Representation (CBOR) Tags" registry.  It is requested
that the tags be assigned in the 24 to 255 value range.
It is requested that IANA assign the following tags from the "Concise
Binary Object Representation (CBOR) Tags" registry.  It is requested
that the tags for COSE_Sign1, COSE_Encrypted and COSE_Mac0 be
assigned in the 1 to 23 value range (i.e. one byte long when
encoded).  It is requested that the rest of the tags be assigned in
the 24 to 255 value range (i.e. two bytes long when encoded).
Draft: draft-ietf-cose-msg

Commentary: This was inspired by the IV computation for TLS . It may or may not make things more secure . The old behavior is easy to get by making the context IV have trailing zeros .
This parameter holds a part of the IV value.  When using the
COSE_Encrypted structure, frequently a portion of the IV is part
of the context associated with the key value.  This field is used
to carry the portion of the IV that changes for each message.  As
the IV is authenticated by the encryption process, this value can
be placed in the unprotected header bucket.  The 'Initialization
Vector' and 'Partial Initialization Vector' parameters MUST NOT be
present in the same security layer.
The final IV is generated by concatenating the fixed portion of
the IV, a zero string and the changing portion of the IV.  The
length of the zero string is computed by taking the required IV
length and subtracting the lengths of the fixed and changing IV
portions.
Left pad the partial IV with zeros to the length of IV.
XOR the padded partial IV with the context IV.
Draft: draft-ietf-cose-msg

Commentary: Everybody but me seems to want a single signer structure . Here it is .
COSE supports two different signature structures.  COSE_Sign allows
for one or more signers to be applied to a single content.
COSE_Sign1 is restricted to a single signer.
Note: When a signature with message recovery algorithm is used
(SigAlgs), the maximum number of bytes that can be recovered is
the length of the payload.  The size of the payload is reduced by
the number of bytes that will be recovered.  If all of the bytes
of the payload are consumed, then the payload is encoded as a zero
length binary string rather than as being absent.
is described in full-signature.
contains the computed signature value.  The type of the field is a
bstr.
The CDDL fragment which represents the above text for COSE_Sign1
follows.
A text string identifying the context that this signature is being
used in.  This string will be "Signature" for signatures using the
COSE_Signature structure and "CounterSignature" for signatures
used as counter signature attributes.
The protected attributes from the signer structure encoded in a
bstr type.
for signatures using the COSE_Signature structure.
for signatures using the COSE_Sign1 structure.
for signatures used as counter signature attributes.
The protected attributes from the signer structure encoded in a
bstr type.  This field is omitted for the COSE_Sign1 signature
structure.
COSE supports two different encryption structures.  COSE_Enveloped is
used when the key needs to be explicitly identified.  This structure
supports the use of recipient structures to allow for random content
encryption keys to be used.  COSE_Enveloped is used when a recipient
structure is not needed because the key to be used is known
implicitly.
It should be noted that only signature algorithm with appendix (see
SigAlgs) should be used for counter signatures.  This is because the
body should be able to be processed without having to evaluate the
countersignature, and this is not possible for signature schemes with
message recovery.
COSE supports two different encryption structures.  COSE_Enveloped is
used when the key needs to be explicitly identified.  This structure
supports the use of recipient structures to allow for random content
encryption keys to be used.  COSE_Encrypted is used when a recipient
structure is not needed because the key to be used is known
implicitly.
Draft: draft-ietf-cose-msg

Commentary: Updated tool had a typo to get the wrong type attribute .
The following provides a CDDL fragment which duplicates the
assignment labels from table-key-labels.
Draft: draft-ietf-cose-msg

Commentary: Need to have a fixed width of the IV for simplicity of code
This parameter holds a part of the IV value.  When using the
COSE_Encrypted structure, frequently a portion of the IV is part
of the context associated with the key value.  This field is used
to carry the portion of the IV that changes for each message.  The
IV used for the cryptographic computation is constructed by
concatenating the fixed portion of the IV and the changing portion
of the IV in order.  (The partial IV being treated as a network
order integer converted to a binary string for this purpose.)  As
the IV is authenticated by the encryption process, this value can
be placed in the unprotected header bucket.
This parameter holds a part of the IV value.  When using the
COSE_Encrypted structure, frequently a portion of the IV is part
of the context associated with the key value.  This field is used
to carry the portion of the IV that changes for each message.  The
IV used for the cryptographic computation is constructed by
concatenating the fixed portion of the IV and the changing portion
of the IV.  (The partial IV being treated as a network order
integer converted to a four byte string for this purpose.)  As the
IV is authenticated by the encryption process, this value can be
placed in the unprotected header bucket.
Draft: draft-ietf-cose-msg

Commentary: Everybody but me wants a MAC w/o recipients . 
 There also needs to be an equivalent no - recipient signature version . Thanks . 
 That string does not even parse . 
 Should the kid attribute be a binary value rather than a string value ? 
 No arguments that binary should not be the only type for this , some questions that binary is useful based on  experience . Definite arguement that binary is required . Doing two types is probably a bad idea .
COSE supports two different MAC structures.  COSE_MAC is used when
the key needs to be explicitly identified.  The structure supports
the use of recipient structures to allow for random content
encryption keys to be used.  COSE_MAC0 is used when the a recipient
structure is not needed because the key to be used is implicitly
known.
In this section we describe the structure and methods to be used when
doing MAC authentication for those cases where the recipient is
implicitly known.
The MAC message uses the COSE_Mac0 structure defined in this section
for carrying the body.
contains the serialized content to be MACed.  If the payload is
not present in the message, the application is required to supply
the payload separately.  The payload is wrapped in a bstr to
ensure that it is transported without changes.  If the payload is
transported separately, then a null CBOR object is placed in this
location and it is the responsibility of the application to ensure
that it will be transported without changes.
contains the MAC value.
A text string that identifies the structure that is being encoded.
This string is "MAC" for the COSE_Mac struture.
A text string that identifies the structure that is being encoded.
This string is "MAC" for the COSE_Mac structure.  This string is
"MAC0" for the COSE_Mac0 structure.