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

Commentary: Tell how to convert partial IV to a binary string
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 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 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.
Draft: draft-ietf-cose-msg

Commentary: Updates to expert review guidelines and application profiling .
Applications may define new header parameters for a specific
purpose.  Applications will often times select specific header
parameters to use or not to use.  For example, an application
would normally state a preference for using either the IV or the
partial IV parameter.  If the partial IV parameter is specified,
then the application would also need to define how the fixed
portion of the IV would be determined.
When applications use externally defined authenticated data, they
need to define how that data is to be defined.  This document
assumes that the data will be provided as a byte stream.  More
information can be found in Extern_AAD.
Point squatting should be discouraged.  Reviewers are encouraged
to get sufficient information for registration requests to ensure
that the usage is not going to duplicate one that is already
registered and that the point is likely to be used in deployments.
The zones tagged as private use are intended for testing purposes
and closed environments, code points should not be assigned for
testing.
Point squatting should be discouraged.  Reviewers are encouraged
to get sufficient information for registration requests to ensure
that the usage is not going to duplicate one that is already
registered and that the point is likely to be used in deployments.
The zones tagged as private use are intended for testing purposes
and closed environments, code points in other ranges should not be
assigned for testing.
When algorithms are registered, vanity registrations should be
discouraged.  One way to do this is to require applications to
provide additional documentation on security analysis of
algorithms.  Another thing that should be considered is to request
for an opinion on the algorithm from the Cryptographic Forum
Research Group.  Algorithm which do not meet the security
requirements of the community and the messages structures should
not be registered.
When algorithms are registered, vanity registrations should be
discouraged.  One way to do this is to require applications to
provide additional documentation on security analysis of
algorithms.  Another thing that should be considered is to request
for an opinion on the algorithm from the Cryptographic Forum
Research Group.  Algorithms which do not meet the security
requirements of the community and the messages structures should
not be registered.
Draft: draft-ietf-cose-msg

Commentary: It makes sense that we do not talk about creation time of the content . However the concept of having a time in the header is also very reasonable for things like countersignatures where one wants to make a timestamp as there is no content that the time marker can be placed in . We therefore change the text to make the time field be the time that the cryptographic operation was performed at .
This parameter provides the time the content was created.  For
signatures and recipient structures, this would be the time that
the signature or recipient key object was created.  For content
structures, this would be the time that the content was created.
The unsigned integer value is the number of seconds, excluding
leap seconds; after midnight UTC, January 1, 1970.
This parameter provides the time the content cryptographic
operation is performed.  For signatures and recipient structures,
this would be the time that the signature or recipient key object
was created.  For content structures, this would be the time that
the content structure was created.  The unsigned integer value is
the number of seconds, excluding leap seconds; after midnight UTC,
January 1, 1970.  The field is primarily intended to be to be used
for countersignatures, however it can additionally be used for
replay detection as well.
Draft: draft-ietf-cose-msg

Commentary: The sign encoding function should deal with other types of curves as well . Make the text refer to the SEC1 encoding function .
contains the x coordinate for the EC point.  The integer is
converted to an octet string as defined in SEC1.  Zero octets MUST
NOT be removed from the front of the octet string.
contains either the sign bit or the value of y coordinate for the
EC point.  When encoding the value y, the integer is converted to
an octet string (as defined in SEC1) and encoded as a CBOR bstr.
Leading zero octets MUST be preserved.  When encoding the sign of
y, the expression 'y > 0' is evaluated and encoded a CBOR boolean.
contains the x coordinate for the EC point.  The integer is
converted to an octet string as defined in SEC1.  Leading zero
octets MUST be preserved.
contains either the sign bit or the value of y coordinate for the
EC point.  When encoding the value y, the integer is converted to
an octet string (as defined in SEC1) and encoded as a CBOR bstr.
Leading zero octets MUST be preserved.  The compressed point
encoding is also supported.  Compute the sign bit as laid out in
the Elliptic-Curve-Point-to-Octet-String Conversion function of
SEC1.  If the sign bit is zero, then encode y as a CBOR false
value, otherwise encode y as a CBOR true value.  The encoding of
the infinity point is not supported.
Draft: draft-ietf-cose-msg

Commentary: Fill in two missing examples . Do the CDDL merging for the MAC structure .
In order to get a consistent encoding of the data to be
authenticated, the MAC_structure is used to have a canonical form.
The MAC_structure is a CBOR array.
Create a MAC_structure and copy the protected and payload fields
from the COSE_Mac structure.
The CDDL fragment which represents the above text for COSE_Mac
follows.
A text string that identifies the structure that is being encoded.
This string is "MAC" for the COSE_Mac struture.
The protected attributes from the COSE_MAC structure.  If there
are no protected attributes, a zero length binary string is to be
encoded.
The payload to be MAC-ed encoded in a bstr type.  The payload is
placed here independent of how it is transported.
Create a MAC_structure and fill in the fields.
The following provides a CDDL fragment which duplicates the
assignment labels from table-key-labels and table-key-ops.
The following CDDL fragment corresponds to the text above.
One of the issues that needs to be addressed is a requirement that a
standard specify a set of algorithms that are required to be
implemented.  [CREF9] This is done to promote interoperability as it
provides a minimal set of algorithms that all devices can be sure
will exist at both ends.  However, we have elected not to specify a
set of mandatory algorithms in this document.
One of the issues that needs to be addressed is a requirement that a
standard specify a set of algorithms that are required to be
implemented.  [CREF8] This is done to promote interoperability as it
provides a minimal set of algorithms that all devices can be sure
will exist at both ends.  However, we have elected not to specify a
set of mandatory algorithms in this document.
Draft: draft-ietf-cose-msg

Commentary: Show how context strings are going to work . Do some of the CDDL integration work
The signature structure can be encoded either with or without a tag
depending on the context it will be used in.  The signature structure
is identified by the CBOR tag TBD1.  The CDDL fragment that
represents this is.
The CDDL fragment which represents the above text for COSE_Sign
follows.
The CDDL fragment which represents the above text for COSE_signature
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.
Create a CBOR array and populate it with the appropriate fields.
For body_protected and sign_protected, if the map is empty, a bstr
of length zero is used.
The CDDL fragment which describes the above text is.
Create a Sig_structure and populate it with the appropriate
fields.  For body_protected and sign_protected, if the map is
empty, a bstr of length zero is used.
The COSE Enveloped structure can be encoded either with or without a
tag depending on the context it will be used in.  The COSE Enveloped
structure is identified by the CBOR tag TBD2.  The CDDL fragment that
represents this is.
The COSE_Encrypted structure can be encoded either with or without a
tag depending on the context it will be used in.  The COSE_Encrypted
structure is identified by the CBOR tag TBD3.  The CDDL fragment that
represents this is.
The encryption algorithm for AEAD algorithms is fairly simple.  In
order to get a consistent encoding of the data to be authenticated,
the Enc_structure is used to have canonical form of the AAD.  The
Enc_structure is a CBOR array.
Copy the protected header field from the message to be sent to the
first location in the Enc_structure.
The encryption algorithm for AEAD algorithms is fairly simple.
Create a CBOR array (Enc_structure) to encode the authenticated
data.
for the the content encryption of an encrypted data structure.
for the first level of an enveloped data structure (i.e. for
content encryption).
for a recipient encoding to be placed in an enveloped data
structure.
for a recipient encoding to be placed in a MAC message
structure.
Copy the protected header field from the message to be sent to the
second location in the Enc_structure.
Draft: draft-ietf-cose-msg

Commentary: Update the build system per
In JSON, maps are called objects and only have one kind of map key: a
string.  In COSE, we use both strings and integers (both negative and
non-negative integers) as map keys, as well as data items to identify
specific choices.  The integers (both positive and negative) are used
for compactness of encoding and easy comparison.  (Generally, in this
document the value zero is going to be reserved and not used.)  Since
the work "key" is mainly used in its other meaning, as a
cryptographic key, we use the term "label" for this usage of either
an integer or a string to identify map keys and choose data items.
In JSON, maps are called objects and only have one kind of map key: a
string.  In COSE, we use both strings and integers (both negative and
non-negative integers) as map keys.  The integers are used for
compactness of encoding and easy comparison.  (Generally, in this
document the value zero is going to be reserved and not used.)  Since
the work "key" is mainly used in its other meaning, as a
cryptographic key, we use the term "label" for this usage as a map
keys.
Draft: draft-ietf-cose-msg

Commentary: Both have been called for and are now there for discussion
This parameter provides the time the content was created.  For
signatures and recipient structures, this would be the time that
the signature or recipient key object was created.  For content
structures, this would be the time that the content was created.
The unsigned integer value is the number of seconds, excluding
leap seconds; after midnight UTC, January 1, 1970.
This parameter provides a counter field.  The use of this
parameter is application specific.
Draft: draft-ietf-cose-msg

Commentary: We are going to use binary strings not big numbers for big numbers to avoid leading zero removal .
A COSE Key Set uses a CBOR array object as its underlying type.  The
values of the array elements are COSE Keys.  A Key Set MUST have at
least one element in the array.
contains the x coordinate for the EC point.  The integer is
converted to an octet string as defined in SEC1.  Zero octets MUST
NOT be removed from the front of the octet string.
This document defines a key structure for both the public and private
halves of RSA keys.  Together, an RSA public key and an RSA private
key form an RSA key pair.
Draft: draft-ietf-cose-msg

Commentary: Create IANA considerations for : 1 ) key and keyset CBOR tags 2 ) COAP Content Format registrations
This section registers the "application/cose" and "application/
cose+cbor" media types in the "Media Types" registry.  [CREF11] These
media types are used to indicate that the content is a COSE_MSG.
This section registers a set of content formats for CoAP.  ID
assignment in the 24-255 range requested.
Draft: draft-ietf-cose-msg

Commentary: Remove ZIP from the document
Do we want to have a zip/compression header standardized in this
document?
Draft: draft-ietf-cose-msg

Commentary: Update to get me current .
The signature structure allows for one or more signatures to be
applied to a message payload.  There are provisions for parameters
about the content and parameters about the signature to be carried
along with the signature itself.  These parameters may be
authenticated by the signature, or just present.  Examples of
parameters about the content would be the type of content, when the
content was created, and who created the content.  Examples of
parameters about the signature would be the algorithm and key used to
create the signature, when the signature was created, and counter-
signatures.
The signature structure allows for one or more signatures to be
applied to a message payload.  There are provisions for parameters
about the content and parameters about the signature to be carried
along with the signature itself.  These parameters may be
authenticated by the signature, or just present.  Examples of
parameters about the content would be the type of content, when the
content was created, and who created the content.  [CREF9] Examples
of parameters about the signature would be the algorithm and key used
to create the signature, when the signature was created, and counter-
signatures.
contains an identifier of the curve to be used with the key.
[CREF13] The curves defined in this document for this key type can
be found in table-ec-curves.  Other curves may be registered in
the future and private curves can be used as well.
contains an identifier of the curve to be used with the key.
[CREF14] The curves defined in this document for this key type can
be found in table-ec-curves.  Other curves may be registered in
the future and private curves can be used as well.
This section registers the "application/cose" and "application/
cose+cbor" media types in the "Media Types" registry.  [CREF16] These
media types are used to indicate that the content is a COSE_MSG.
This section registers the "application/cose" and "application/
cose+cbor" media types in the "Media Types" registry.  [CREF17] These
media types are used to indicate that the content is a COSE_MSG.
Draft: draft-ietf-cose-msg

Commentary: Create a counter signatuer attribute
This parameter holds a counter signature value.  Counter
signatures provide a method of having a second party sign some
data, the counter signature can occur as an unprotected attribute
in any of the following structures: COSE_Sign, COSE_signature,
COSE_enveloped, COSE_recipient, COSE_encryptedData, COSE_mac.
These structures all have the same basic structure so that a
consistent calculation of the counter signature can be computed.
Details on computing counter signatures are found in
counter_signature.
Counter signatures provide a method of having a different signature
occur on some piece of content.  This is normally used to provide a
signature on a signature allowing for a proof that a signature
existed at a given time.  In this document we allow for counter
signatures to exist in a greater number of environments.  A counter
signature can exist, for example, on a COSE_encyptedData object and
allow for a signature to be present on the encrypted content of a
message.
The creation and validation of counter signatures over the different
items relies on the fact that the structure all of our objects have
the same structure.  The first element may be a message type, this is
followed by a set of protected attributes, a set of unprotected
attributes and a body in that order.  This means that the
Sig_structure can be used for in a uniform manner to get the byte
stream for processing a signature.  If the counter signature is going
to be computed over a COSE_encryptedData structure, the
body_protected and payload items can be mapped into the Sig_structure
in the same manner as from the COSE_Sign structure.
While one can create a counter signature for a COSE_Sign structure,
there is not much of a point to doing so.  It is equivalent to create
a new COSE_signature structure and placing it in the signatures
array.  It is strongly suggested that it not be done, but it is not
banned.
Draft: draft-ietf-cose-msg

Commentary: Define enveloped data vs encrypted data difference
COSE supports two different encryption structures.  OOSE_enveloped is
used when the key needs to be explicilty identified.  This structure
supports the use of recipient structures to allow for random content
encryption keys to be used..  COSE_encrypted is used when the a
recipient structure is not needed because the key to be used is known
implicitly.
contains the recipient information.  It is required that at least
one recipient MUST be present for the content encryption layer.
contains the encrypted plain text encoded as a bstr.  If the
ciphertext is to be transported independently of the control
information about the encryption process (i.e. detached content)
then the field is encoded as a null object.
contains an array of recipient information structures.  The type
for the recipient information structure is a COSE_recipient.
contains the encrypted key encoded as a bstr.  If there is not an
encrypted key, then this field is encoded as a nil type.
contains an array of recipient information structures.  The type
for the recipient information structure is a COSE_recipient.  If
there are no recipient information structures, this element is
absent.
The encrypted structure does not have the ability to specify
recipients of the message.  The structure assumes that the recipient
of the object will already know the identity of the key to be used in
order to decrypt the message.  If a key needs to be identified to the
recipient, the enveloped structure is used.
identifies this as providing the encrypted data security service.
This value MUST be mg_type_encrypted (4).
Draft: draft-ietf-cose-msg

Commentary: Create a EC curve registry
The initial contents of the registry can be found in:
HKDF_Alg_Params, KDF_Context_Alg_Params, table-ecdh-es-parameter-
table, and Header-Algorithm-Table.  The specification column for all
rows in that table should be this document.
The initial contents of the registry can be found in:
HKDF_Alg_Params, KDF_Context_Alg_Params, table-ecdh-es-parameter-
table.  The specification column for all rows in that table should be
this document.
It is requested that IANA create a new registry "COSE Elliptic Curve
Parameters".
This is a descriptive name that enables easier reference to the
item.  It is not used in the encoding.
This is the value used to identify the curve.  These values MUST
be unique.  The integer values from -256 to 255 are designated as
Standards Track Document Required.  The the integer values from
256 to 65535 and -65536 to -257 are designated as Specification
Required.  Integer values over 65535 are designated as first come
first serve.  Integer values less than -65536 are marked as
private use.
This designates the key type(s) that can be used with this curve.
This field contains a brief description of the curve.
This contains a pointer to the public specification for the curve
if one exists.
This registry will be initially populated by the values in
table_key_types.  The specification column for all of these entries
will be this document.
Draft: draft-ietf-cose-msg

Commentary: Do a pass to correct constants Auto generate the key sets for the examples
The GCM mode is is a generic authenticated encryption block cipher
mode defined in AES-GCM.  The GCM mode is combined with the AES block
encryption algorithm to define a an AEAD cipher.
The GCM mode is parameterized with by the size of the authentication
tag.  The size of the authentication tag is limited to a small set of
values.  For this document however, the size of the authentication
tag is fixed at 128-bits.
The set of algorithms defined in this document are in table-AES-GCM.
The key and nonce pair MUST be unique for every message encrypted.
The total amount of data encrypted MUST NOT exceed 2^39 - 256 bits
.  An explicit check is required only in environments where it is
expected that it might be exceeded.
See RFC5869.
The HKDF key derivation algorithm is defined in RFC5869.
salt - an optional public value that is used to change the
generation process.  If specified, the salt is carried using the
'salt' algorithm parameter.  While RFC5869 suggests that the
length of the salt be the same as the length of the underlying
hash value, any amount of salt will improve the security as
different key values will be generated.  The 'salt' parameter is
encoded as a binary string.  This parameter is protected by being
included in the key computation and does not need to be separately
authenticated.
salt - an optional public value that is used to change the
generation process.  If specified, the salt is carried using the
'salt' algorithm parameter.  While RFC5869 suggests that the
length of the salt be the same as the length of the underlying
hash value, any amount of salt will improve the security as
different key values will be generated.  A parameter to carry the
salt is defined in HKDF_Alg_Params.  This parameter is protected
by being included in the key computation and does not need to be
separately authenticated.
context information - Information that describes the context in
which the resulting value will be used.  Making this information
specific to the context that the material is going to be used
ensures that the resulting material will always be unique.