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

Commentary: Add capabilities per chairs
There are no IANA actions.  The required actions are in I-D.ietf-
cose-rfc8152bis-struct.
There are some situations that have been identified where
identification of capabilities of an algorithm need to be specified.
One example of this is in I-D.ietf-core-oscore-groupcomm where the
capabilities of the counter signature algorithm are mixed into the
traffic key derivation process.  This has a counterpart in the S/MIME
specifications where SMIMECapabilities is defined in RFC8551.  The
concept is being pulled forward and defined now for COSE.
Two different types of capabilities are defined: Capabilities for
algorithms and capabilities for key structures.  Once defined by
registration with IANA, the list capabilities is immutable.  As a
general rule, the capabilities are going to correspond to algorithm
or key fields, but they do not need to do so.  An example of this is
the HSS-LMS key capabilities defined below where the hash algorithm
used is included.
The capability structure is an array of values, the order being
dependent on the specific algorithm or key.  For an algorithm, the
first element should always be a key type value, but the items that
are specific to a key should not be included in the algorithm
capabilities.  This means that if one wishes to enumerate all of the
capabilities for a device which implements ECDH, it requires multiple
pairs of capability structures (algorithm, key) to deal with the
different key types and curves that are supported.  For a key, the
first element should also be a key type value, while this means that
this value will be duplicated if both an algorithm and key capability
are used, the key type is needed in order to understand the rest of
the values.
For the current set of algorithms in the registry, those in this
document as well as those in RFC8230 and I-D.ietf-cose-hash-sig, the
capabilities is set to the single entry of the key type that will be
accepted.  It is expected other algorithms will have no items or
multiple items.
IANA is requested to create a new column in the "COSE Key Types"
registry.  The new column is to be labeled "Capabilities".  The new
column is to be populated according the the entries in initial-kty-
caps.
IANA is requested to create a new column in the "COSE Algorithms"
registry.  The new column is to be labeled "Capabilities".  The new
column is populated with "kty" for all current, non-provisional,
registrations.  It is expected that the documents which define those
algorithms will be expanded to include this registration, if this is
not done then the DE should be consulted at the time of final
registration.
Draft: draft-ietf-cose-rfc8152bis-algs

Commentary: Rename for adoption .
Note: Use of deterministic signatures is a good idea even when good
random number generation exists.  Doing so both reduces the
possibility of having the same value of 'k' in two signature
operations and allows for reproducible signature values, which helps
testing.
Note: Use of a deterministic signature technique is a good idea even
when good random number generation exists.  Doing so both reduces the
possibility of having the same value of 'k' in two signature
operations and allows for reproducible signature values, which helps
testing.