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

Commentary: Change the CDDL and the examples to be arrays
Each of the top-level security objects use a CBOR map as the base
structure.  Items in the map at the top level are identified by a
label.  The type of the value associated with the label is determined
by the definition of the label.
The set of labels present in a security object is not restricted to
those defined in this document.  However, it is not recommended that
additional fields be added to a structure unless this is going to be
done in a closed environment.  When new fields need to be added, it
is recommended that a new message type be created so that processing
of the field can be ensured.  Using an older structure with a new
field means that any security properties of the new field will not be
enforced.  Before a new field is added at the outer level, strong
consideration needs to be given to defining a new header field and
placing it into the protected headers.  Applications should make a
determination if non-standardized fields are going to be permitted.
It is suggested that libraries allow for an option to fail parsing if
non-standardized fields exist, this is especially true if they do not
allow for access to the fields in other ways.
Each of the top-level security objects use a CBOR array as the base
structure.
The top level of each of the COSE message structures are encoded as
maps.  We use an integer to distinguish between the different
security message types.  By searching for the integer under the label
identified by msg_type (which is in turn an integer), one can
determine which security message is being used and thus what syntax
is for the rest of the elements in the map.
The top level of each of the COSE message structures are encoded as
arrays.
We use the values in Top-Level-Keys as the labels in the COSE_Sign
map.  While other labels can be present in the map, it is not
generally a recommended practice.  The other labels can be either of
integer or string type, use of other types SHOULD be treated as an
error.
This table is initially populated by the table in Top-Level-Keys.
This section registers the "application/cose" and "application/
cose+cbor" media types in the "Media Types" registry.  [CREF22] 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.  [CREF21] These
media types are used to indicate that the content is a COSE_MSG.
Draft: draft-ietf-cose-msg

Commentary: Assign integer tags to the CCM modes that we are keeping . Remove the 192 - bit key CCM modes from the table . Update example using CCM
limits messages to 2^16 bytes in length.  The nonce length is 13
bytes allowing for 2^(13*8) possible values of the nonce without
repeating.
limits messages to 2^16 bytes (64Kbyte) in length.  This
sufficently long for messages in the constrainted world.  The
nonce length is 13 bytes allowing for 2^(13*8) possible values of
the nonce without repeating.
Draft: draft-ietf-cose-msg

Commentary: Just to make the dog bark
There currently is no standard CBOR grammar available for use by
specifications.  In this document, we use the grammar defined in the
CBOR data definition language (CDDL) I-D.greevenbosch-appsawg-cbor-
cddl.
NOTE[CREF2]: At some point we need to make some decisions about how
we are using CDDL in this document.  Since this draft has not been
moving forward at a great rate, changing all references on it to
informational is a good idea.  On the other hand, having some type of
syntax that can be examined by a machine to do syntax checking is a
big win.  The build system for this draft is currently using the
latest version of CDDL to check that the syntax of the examples is
correct.  Doing this has found problems in both the syntax checker,
the syntax and the examples.
Each of the top-level security objects use a CBOR map as the base
structure.  Items in the map at the top level are identified by a
label.  This document defines a number of labels in the IANA "COSE
Object Labels Registry" (defined in IANA-Top-Level-Keys).
Each of the top-level security objects use a CBOR map as the base
structure.  Items in the map at the top level are identified by a
label.  The type of the value associated with the label is determined
by the definition of the label.
Draft: draft-ietf-cose-msg

Commentary: Change names of files and cleanup old unused files Small changes in the main document .
M00TODO: Put in generalities about sigature algorithms and
parameters.
The second is a signature with message recovery.  (An example of such
an algorithm is [TBD].)  In this structure, the message content is
processed, but part of is included in the siguature.  Moving bytes of
the message content into the signature allows for an effectively
smaller signature, the signature size is still potentially large, but
the message content is shrunk.  This has implications for systems
implementing these algoritms and for applications that use them.  The
first is that the message content is not fully available until after
a signature has been validated.  Until that point the part of the
message contained inside of the signature is unrecoverable.  The
second is that the security analysis of the strength of the signature
is very much based on the structure of the message content.  Messages
which are highly predictable require additional randomness to be
supplied as part of the signature process, in the worst case it
because the same as doing a singature with appendix.  Thirdly, in the
event that multple signatures are applied to a message, all of the
signature algorithms are going to be required to consume the same
number of bytes of message content.
At this time, only signatures with appendixes are defined for use
with COSE, however considerable interest has been expressed in using
a signature with message recovery algorithm due to the effective size
reduction that is possible.  Implementations will need to keep this
in mind for later possible integration.
NOTE: Need to review the range assignments.  It does not necessarily
make sense as specification required uses 1 byte positive integers
and 2 byte strings.
The initial contents of the registry can be found in 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, and Header-Algorithm-Table.  The specification column for all
rows in that table should be this document.
This registry will be initially populated by the values in --Multiple
Tables--.  The specification column for all of these entries will be
this document.
This registry will be initially populated by the values in table-
ec1-keys, table-ec2-keys, table-rsa-keys, and table-symmetric-keys.
The specification column for all of these entries will be this
document.
Draft: draft-schaad-cose-msg

Commentary: Expand the fields for a COSE_Key structure
The "key_ops" element is preferred over the "use" element as the
information provided that way is more finely detailed about the
operations allowed.  It is strongly suggested that this element be
present for all keys.
Any item that is base64url encoded in JWK, is bstr encoded for
COSE.
Any item that is integer encoded in JWK, is int encoded for COSE.
Any item that is string (but not base64url) encoded in JWK, is
tstr encoded for COSE.
is always bstr encoded rather than tstr encoded.  This change
in encoding is due to the fact that frequently, values such as
a hash of the public key is used for a kid value.  Since the
field is defined as not having a specific structure, making it
binary rather than textual makes sense.
This table contains a list of all of the parameters defined for keys
that were defined by the JOSE document set.  In the table is the data
value type to be used for CBOR as well as the integer value that can
be used as a replacement for the name in order to further decrease
the size of the sent item.
This document defines a set of common map elements for a COSE Key
object.  table-key-labels provides a summary of the elements defined
in this section.  There are also a set of map elements that are
defined for a specific key type.  Key specific elements can be found
in Key-specific-labels.
This field is used to identify the family of keys for this
structure, and thus the set of fields to be found.  The set of
values can be found in table_key_types.
This field is used to restrict the algorithms that are to be used
with this key.  If this field is present in the key structure, the
application MUST verify that this algorithm matches the algorithm
for which the key is being used.  If the algorthms do not match,
then this key object MUST NOT be used to perform the cryptographic
operation.  Note that the same key can be in a different key
structure with a different or no algorithm specified, however this
is considered to be a poor security practice.
This field is used to give an identifier for a key.  The
identifier is not structured and can be anything from a user
provided string to a value computed on the public portion of the
key.  This field is intended for matching against a 'kid' field in
a message in order to filter down the set of keys that need to be
checked.
This field is defined to restrict the set of operations that a key
is to be used for.  The value of the field is an array of values
from table-key-ops.
Only the 'kty' field MUST be present in a key object.  All other
members may be omitted if their behavior is not needed.
The following provides a CDDL fragment which duplicates the
assignment labels from table-key-labels and table-key-ops.
Draft: draft-schaad-cose-msg

Commentary: MTI Algorithm requirements Expand RSASSA - PSS section Correct one coordinate EC for endian Hint to get binary versions of examples Correct kid to binary in the examples ( except for static public key one ) .
One of the standard issues that is specified in IETF cryptographic
algorithms is a requirement that a standard specify a set of minimal
algorithms that are required to be implemented.  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.
It is expected that COSE is going to be used in a wide variety of
applications and on a wide variety of devices.  Many of the
constrained devices are going to be setup to used a small fixed set
of algorithms, and this set of algorithms may not match those
available on a device.  We therefore have deferred to the application
protocols the decision of what to specify for mandatory algorithms.
M00TODO: Put in generalities about sigature algorithms and
parameters.
The RSASSA-PSS signature algorithm is defined in RFC3447.
The RSASSA-PSS signature algorithm is parametized with a hash
function, a mask generation function and a salt length (sLen).  For
this specification, the mask generation function is fixed to be MGF1
as defined in RFC3447.  It has been recommended that the same hash
function be used for hashing the data as well as in the mask
generation function, for this specification we following this
recommendation.  The salt length is the same length as the hash
function output.
This uses the hash algorithm SHA-256 for signature processing.
The value used for this algorithm is -10.  The key type used for
this algorithm is 'RSA'.
This uses the hash algorithm SHA-384 for signature processing.
The value used for this algorithm is "PS384".  The key type used
for this algorithm is 'RSA'.
This uses the hash algorithm SHA-512 for signature processing.
The value used for this algorithm is -11.  The key type used for
this algorithm is 'RSA'.
There are no algorithm parameters defined for these signature
algorithms.  A summary of the algorithm definitions can be found in
table-rsa-algs.
Key size.  is there a MUST for 2048? or do we need to specify a
minimum here?
contains either the sign bit or the value of y coordinate for the
EC point.  For the value, 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.  For the sign bit, the value is
true if the value of y is positive.
This registry will be initially populated by the values in
COSE_KEY_PARAM_KEYS.  The specification column for all of these
entries will be this document.
This registry will be initially populated by the values in --Multiple
Tables--.  The specification column for all of these entries will be
this document.
Draft: draft-schaad-cose

Commentary: Update the examples to match the current spec ( mostly ) .
NOTE: Need to review the range assignments.  It does not necessarily
make sense as specification required uses 1 byte positive integers
and 2 byte strings.
Draft: draft-schaad-cose

Commentary: Change all of the references to point to the final JOSE documents
In this section we describe the structure and methods to be used when
doing an encryption in COSE.  In COSE, we use the same techniques and
structures for encrypting both the plain text and the keys used to
protect the text.  This is different from the approach used by both
RFC5652 and I-D.ietf-jose-json-web-encryption where different
structures are used for the plain text and for the different key
management techniques.
In this section we describe the structure and methods to be used when
doing an encryption in COSE.  In COSE, we use the same techniques and
structures for encrypting both the plain text and the keys used to
protect the text.  This is different from the approach used by both
RFC5652 and RFC7516 where different structures are used for the plain
text and for the different key management techniques.
The names of the key management methods used here are the same as are
defined in I-D.ietf-jose-json-web-key.  Other specifications use
different terms for the key management methods or do not support some
of the key management methods.
At the moment we do not have any key management methods that allow
for the use of protected headers.  This may be changed in the future
if, for example, the AES-GCM Key wrap method defined in I-D.ietf-
jose-json-web-algorithms were extended to allow for authenticated
data.  In that event the use of the 'protected' field, which is
current forbidden below, would be permitted.
The names of the key management methods used here are the same as are
defined in RFC7517.  Other specifications use different terms for the
key management methods or do not support some of the key management
methods.
At the moment we do not have any key management methods that allow
for the use of protected headers.  This may be changed in the future
if, for example, the AES-GCM Key wrap method defined in RFC7518 were
extended to allow for authenticated data.  In that event the use of
the 'protected' field, which is current forbidden below, would be
permitted.
For COSE we use the same set of fields that were defined in I-D.ietf-
jose-json-web-key.
The element "kty" is a required element in a COSE_Key map.
All other elements are optional and not all of the elements listed in
I-D.ietf-jose-json-web-key or I-D.ietf-jose-json-web-algorithms have
been listed here even though they can all appear in a COSE_Key map.
For COSE we use the same set of fields that were defined in RFC7517.
The element "kty" is a required element in a COSE_Key map.
All other elements are optional and not all of the elements listed in
RFC7517 or RFC7518 have been listed here even though they can all
appear in a COSE_Key map.
Draft: draft-schaad-cose

Commentary: Fix install instructions in the README for kramdown - xml2rfc Update COSE spec for tagging discussion Update Issues document for closed and newly opened discussion issues . 
  has suggested that we could eliminate the need for the COSE_MSG structure if we were to get tags assigned from CBOR for these structures . Should this be done ? 
 a ) CBOR Tag - either general or specific to each type b ) Required Identifier c ) Use the same techniques as  There was no support for option C. There was support for Option B There was some support for Option A , but only if it was optional .   suggested that we should use the header parameter ' typ ' , I responded to this message saying that it was not clear that this was a correct use of the field based on the description in the  document . At this point I will keep the field as mandatory and outside of the headers field . I am planning on doing the IANA request for a CBOR Tag and to keep the tag as being optional in the grammar and text . 
 Closed in  request
Where we would need to define the latter two as tagged arrays like is
currently done for COSE_SignedMessage.
There is no space savings in CBOR, this is strictly about using CBOR
paradymes.  It is not clear what would happen if a JOSE serialization
appeared, but that is probably not interesting.  If this path is
used, then there is no extensibility for new messages types.  They
would need to be defined on their own.
There are IANA considerations to be filled in.
It is requested that IANA assign a new tag from the "Concise Binary
Object Represetion (CBOR) Tags" registry.  It is requested that the
tag be assigned in the 0 to 23 value range.
Semantics: COSE security message.
Draft: draft-schaad-cose

Commentary: Following discussions on the mailing list . Removing the ability to have flattened encoding for signers and recipients . 
 Closes issue 
 JOSE now allows for a single recipient to be encoded at the same level as the content . While COSE does not allow for quite the same way of encoding this it would be possible to do something similar . Current syntax is " recipients : COSEencrypta\ null ; " Do so would allow for a single recipient to be appended to the end of the current array of values rather than creating two array sub - encodings in CBOR . This encoding saves 2 bytes in the event of a single recipient at the expense of needing to pass in an offset in the array structure when parsing it . Not really that hard to do from a programmers point of view . 
 Open for group discussion 
 Based on the messages , there seems to be no support for combining the two maps together into a single map . I have therefore removed that from my working copy of the draft . There was one request for allowing option b ( where a single recipient can be represented as a single map entry rather than as an array of a single map ) . I have looked at code size , and there does not seem to be a lot of code associated with this option , but as there was no outcry for this option I have not included it . Unless others have opinions that they believe need to be expressed , I am closing this issue .
Remove the flattened mode of encoding.  Forcing the use of an
array of recipients at all times forces the message size to be two
bytes larger, but one gets a corresponding decrease in the
implementation size that should compenstate for this.
is either a single signature or an array of signature values.
A single signature value can be represented using either data
type.  Implementations MUST be able to parse both data types.
is an array of signature items.  Each of these items uses the
COSE_signature structure for its representation.
A single COSE_encrypt element, encoded as an extension to the
containing COSE_encrypt element, for a single recipient.  Single
recipients can be encoded either this way or as a single array
element.
Draft: draft-schaad-cose

Commentary: Fix some additional errors found in the CDDL descriptions . It is still not completely correct so automatic testing is not turned on yet . Also some of the examples were out of date to the expected syntax so they got some updates .
indicates which of the security structures is in this block.
contains the top level fields for the security service provided.
The type in this field is based on the value of the field
msg_type.
The top level of each of the COSE message structures are encoded as
arrays.
We use an integer to distingish bettwen the different security
message types.  By looking at the integer in the first element, one
can determine which security message is being used and thus what the
syntax is for the rest of the elements in the array.
Implementations SHOULD be prepared to find an integer in the location
which does not correspond to the values 0 to 2.  If this is found
then the client MUST stop attempting to parse the structure and fail.
Clients need to recognize that the set of values could be extended at
a later date, but should not provide a security service based on
guesses of what is there.
Where we would need to define the latter two as tagged arrays like is
currently done for COSE_SignedMessage.
There is no space savings in CBOR, this is strictly about using CBOR
paradymes.  It is not clear what would happen if a JOSE serialization
appeared, but that is probably not interesting.  If this path is
used, then there is no extensibility for new messages types.  They
would need to be defined on their own.
Draft: draft-schaad-cose

Commentary: The majority of changes prior to the examples section are to address typos or what I saw as inconsistencies . I will admit I was n't as diligent as I should have been on those , but I need to take another pass on the document . The examples were reformatted to minimize side scrolling -- and likely fit within the TXT representation .
Switch from using a map to using an array at the message level.
While this change means that it is no longer possible to new named
parameters to the top level message, it also means that there is
not a need to define how older implementations are defined to
behave when new fields are present.  Most of the reasons that a
new field would need to be defined are adequately addressed by
defining a new parameter instead.
Switch from using a map to using an array at the message level.
While this change means that it is no longer possible to add new
named parameters to the top level message, it also means that
there is not a need to define how older implementations are
defined to behave when new fields are present.  Most of the
reasons that a new field would need to be defined are adequately
addressed by defining a new parameter instead.
One of the by products of using the same technique for encrypting and
encoding both the content and the keys using the various key
management techniques, is a requirement that all of the key
management techniques use an Authenticated Encryption (AE) algorithm.
(For the purpose of this document we use a slightly loose definition
of AE algorithms.)  When encrypting the plain text, it is normal to
use an Authenticated Encryption with Additional Data (AEAD)
algorithm.  For key management, either AE or AEAD algorithms can be
used.  See AE-algo for more details about the different types of
algorithms.
One of the byproducts of using the same technique for encrypting and
encoding both the content and the keys using the various key
management techniques, is a requirement that all of the key
management techniques use an Authenticated Encryption (AE) algorithm.
(For the purpose of this document we use a slightly loose definition
of AE algorithms.)  When encrypting the plain text, it is normal to
use an Authenticated Encryption with Additional Data (AEAD)
algorithm.  For key management, either AE or AEAD algorithms can be
used.  See AE-algo for more details about the different types of
algorithms.
Copy the add field from the COSE_Encrypt structure to the
Enc_Structure.
Encrypt the plain text and place it in the ciphertext field.  The
AAD value is passed in as part of the encryption process.
Copy the 'aad' field from the COSE_Encrypt structure to the
Enc_Structure.
Encrypt the plain text and place it in the 'ciphertext' field.
The AAD value is passed in as part of the encryption process.
Verify that the protected field is empty.
Verify that the aad field is empty.
Encrypt the plain text and place in the ciphertext field.
Verify that the 'protected' field is empty.
Verify that the 'aad' field is empty.
Encrypt the plain text and place in the 'ciphertext' field.