Draft: draft-schaad-cose-rfc8152bis-struct

Commentary: Doing a detailed read through and updating grammar , sentences and IANA
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)" RFC7049.  CBOR extended the data model of the JavaScript
Object Notation (JSON) RFC8259 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 to be both small in terms
of messages transport and implementation size and 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.
The description of the structure for the CBOR objects which are
transmitted over the wire.  Two objects are defined for
encryption, signing and message authentication.  One object is
defined for transporting keys and one for transporting groups of
keys.
The procedures used to compute build the inputs to the
cryptographic functions required for each of the structures.
A starting set of attributes that apply to the different security
objects.
This document does not contain the rules and procedures for using
specific cryptographic algorithms.  Details on specific algorithms
can be found in I-D.schaad-cose-rfc8152bis-algs and RFC8230.  Details
for additional algorithms are expected to be defined in future
documents.
One feature that is present in CMS RFC5652 that is not present in
this standard is a digest structure.  This omission is deliberate.
It is better for the structure to be defined in each document as
different protocols will want to include a different set of fields as
part of the structure.  While an algorithm identifier and the digesst
value are going to be common to all applications, the two values may
not always be adjacent as the algorithm could be defined once with
multiple values.  Applications may additionally want to defined
additional data fields as part of the stucture.  A common structure
is going to include a URI or other pointer to where the data that is
being hashed is kept, allowing this to be application specific.
When the words appear in lowercase, this interpretation does not
apply.
There is currently no standard CBOR grammar available for use by
specifications.  The CBOR structures are therefore described in
prose.
There was not a standard CBOR grammar available when COSE was
originally written.  For that reason the CBOR structures defined here
are described in prose.  Since that time CBOR Data Definition
Language (CDDL) I-D.ietf-cbor-cddl has been published as an RFC.  The
CBOR grammar presented in this document is compatible with CDDL.
As well as the prose description, a version of a CBOR grammar is
presented in CDDL.  Since CDDL has not been published in an RFC, this
grammar may not work with the final version of CDDL.  The CDDL
grammar is informational; the prose description is normative.
As well as the prose description, a version of a CBOR grammar is
presented in CDDL.  The CDDL grammar is informational; the prose
description is normative.
The presence of a label in a COSE map that is not a string or an
integer is an error.  Applications can either fail processing or
process messages with incorrect labels; however, they MUST NOT create
messages with incorrect labels.
The presence of a label in a COSE map that is not a string or an
integer is an error.  Applications can either fail processing or
process messages by ignoring incorrect labels; however, they MUST NOT
create messages with incorrect labels.
The content of the message.  The content is either the plaintext
or the ciphertext as appropriate.  The content may be detached,
but the location is still used.  The content is wrapped in a bstr
when present and is a nil value when detached.
COSE messages are also built using the concept of layers to separate
different types of cryptographic concepts.  As an example of how this
works, consider the COSE_Encrypt message (EnvelopedData).  This
message type is broken into two layers: the content layer and the
recipient layer.  In the content layer, the plaintext is encrypted
and information about the encrypted message is placed.  In the
recipient layer, the content encryption key (CEK) is encrypted and
information about how it is encrypted for each recipient is placed.
A single layer version of the encryption message COSE_Encrypt0
(EnvelopedData0) is provided for cases where the CEK is pre-shared.
The content of the message.  The content is either the plaintext
or the ciphertext as appropriate.  The content may be detached
(i.e. transported separately from the COSE structure), but the
location is still used.  The content is wrapped in a bstr when
present and is a nil value when detached.
COSE messages are built using the concept of layers to separate
different types of cryptographic concepts.  As an example of how this
works, consider the COSE_Encrypt message (EnvelopedData).  This
message type is broken into two layers: the content layer and the
recipient layer.  In the content layer, the plaintext is encrypted
and information about the encrypted message is placed.  In the
recipient layer, the content encryption key (CEK) is encrypted and
information about how it is encrypted for each recipient is placed.
A single layer version of the encryption message COSE_Encrypt0
(EnvelopedData0) is provided for cases where the CEK is pre-shared.
Contains parameters about the current layer that are to be
cryptographically protected.  This bucket MUST be empty if it is
not going to be included in a cryptographic computation.  This
bucket is encoded in the message as a binary object.  This value
is obtained by CBOR encoding the protected map and wrapping it in
a bstr object.  Senders SHOULD encode a zero-length map as a zero-
length string rather than as a zero-length map (encoded as h'a0').
The zero-length binary encoding is preferred because it is both
shorter and the version used in the serialization structures for
cryptographic computation.  After encoding the map, the value is
wrapped in the binary object.  Recipients MUST accept both a zero-
length binary value and a zero-length map encoded in the binary
value.  The wrapping allows for the encoding of the protected map
to be transported with a greater chance that it will not be
altered in transit.  (Badly behaved intermediates could decode and
re-encode, but this will result in a failure to verify unless the
re-encoded byte string is identical to the decoded byte string.)
This avoids the problem of all parties needing to be able to do a
common canonical encoding.
Contains parameters about the current layer that are
cryptographically protected.  This bucket MUST be empty if it is
not going to be included in a cryptographic computation.  This
bucket is encoded in the message as a binary object.  This value
is obtained by CBOR encoding the protected map and wrapping it in
a bstr object.  Senders SHOULD encode a zero-length map as a zero-
length byte string rather than as a zero-length map (encoded as
h'a0').  The zero-length binary encoding is preferred because it
is both shorter and the version used in the serialization
structures for cryptographic computation.  After encoding the map,
the value is wrapped in the binary object.  Recipients MUST accept
both a zero-length binary value and a zero-length map encoded in
the binary value.  The wrapping allows for the encoding of the
protected map to be transported with a greater chance that it will
not be altered in transit.  (Badly behaved intermediates could
decode and re-encode, but this will result in a failure to verify
unless the re-encoded byte string is identical to the decoded byte
string.)  This avoids the problem of all parties needing to be
able to do a common canonical encoding.
This parameter is used to indicate the algorithm used for the
security processing.  This parameter MUST be authenticated where
the ability to do so exists.  This support is provided by AEAD
algorithms or construction (COSE_Sign, COSE_Sign0, COSE_Mac, and
COSE_Mac0).  This authentication can be done either by placing the
header in the protected header bucket or as part of the externally
supplied data.  The value is taken from the "COSE Algorithms"
registry (see cose-algorithm-registry).
This parameter is used to indicate the algorithm used for the
security processing.  This parameter MUST be authenticated where
the ability to do so exists.  This support is provided by AEAD
algorithms or construction (COSE_Sign, COSE_Sign0, COSE_Mac, and
COSE_Mac0).  This authentication can be done either by placing the
parameter in the protected header bucket or as part of the
externally supplied data.  The value is taken from the "COSE
Algorithms" registry (see COSE.Algorithms).
sender can prevent a proxy from changing the set of values that it
will accept by including that value in the resulting authentication
tag.  However, it may also be desired to protect these values so that
if they are modified in transit, it can be detected.
If multiple items are included, applications need to ensure that
the same byte string is not produced if there are different
inputs.  This could occur by appending the strings 'AB' and 'CDE'
or by appending the strings 'ABC' and 'DE'.  This is usually
addressed by making fields a fixed width and/or encoding the
length of the field as part of the output.  Using options from
CoAP RFC7252 as an example, these fields use a TLV structure so
they can be concatenated without any problems.
sender can cause a failure at the server if a proxy, or an attacker,
changes the set of accept values by including the field in the
application supplied data.
If multiple items are included, applications need to ensure that
the same byte string cannot produced if there are different
inputs.  This could occur by appending the strings 'AB' and 'CDE'
or by appending the strings 'ABC' and 'DE'.  This is usually
addressed by making fields a fixed width and/or encoding the
length of the field as part of the output.  Using options from
CoAP RFC7252 as an example, these fields use a TLV structure so
they can be concatenated without any problems.
Applications need to ensure that the byte stream is going to be
the same on both sides.  Using options from CoAP might give a
problem if the same relative numbering is kept.  An intermediate
node could insert or remove an option, changing how the relative
number is done.  An application would need to specify that the
relative number must be re-encoded to be relative only to the
options that are in the external data.
Applications need to ensure that the byte string is going to be
the same on both sides.  Using options from CoAP might give a
problem if the same relative numbering is kept.  An intermediate
node could insert or remove an option, changing how the relative
number is done.  An application would need to specify that the
relative number must be re-encoded to be relative only to the
options that are in the external data.
In addition to performing the signature verification, the application
may also perform the appropriate checks to ensure that the key is
correctly paired with the signing identity and that the signing
identity is authorized before performing actions.
Counter signatures provide a method of associating a different
signature generated by different signers with 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 (i.e., a
Timestamp).  In this document, we allow for counter signatures to
exist in a greater number of environments.  As an example, it is
possible to place a counter signature in the unprotected attributes
of a COSE_Encrypt object.  This would allow for an intermediary to
either verify that the encrypted byte stream has not been modified,
without being able to decrypt it, or assert that an encrypted byte
stream either existed at a given time or passed through it in terms
of routing (i.e., a proxy signature).
In addition to performing the signature verification, the application
performs the appropriate checks to ensure that the key is correctly
paired with the signing identity and that the signing identity is
authorized before performing actions.
Counter signatures provide a method of associating a different
signature generated by different signers with 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 (e.g., a
Timestamp).  In this document, we allow for counter signatures to
exist in a greater number of environments.  As an example, it is
possible to place a counter signature in the unprotected attributes
of a COSE_Encrypt object.  This would allow for an intermediary to
either verify that the encrypted byte string has not been modified,
without being able to decrypt it, or assert that an encrypted byte
string either existed at a given time or passed through it in terms
of routing (e.g., a proxy signature).
The creation and validation of counter signatures over the different
items relies on the fact that the objects have the same structure.
The elements are 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 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_Encrypt structure, the body_protected and
payload items can be mapped into the Sig_structure in the same manner
as from the COSE_Sign structure.
The creation and validation of counter signatures over the different
items relies on the fact that the objects have the same structure.
The elements are 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 in a uniform manner to get the byte string
for processing a signature.  If the counter signature is going to be
computed over a COSE_Encrypt structure, the body_protected and
payload items can be mapped into the Sig_structure in the same manner
as from the COSE_Sign structure.
COSE supports two different encryption structures.  COSE_Encrypt0 is
used when a recipient structure is not needed because the key to be
used is known implicitly.  COSE_Encrypt is used the rest of the time.
This includes cases where there are multiple recipients or a
recipient algorithm other than direct is used.
COSE supports two different encryption structures.  COSE_Encrypt0 is
used when a recipient structure is not needed because the key to be
used is known implicitly.  COSE_Encrypt is used the rest of the time.
This includes cases where there are multiple recipients or a
recipient algorithm other than direct (i.e. pre-shared secret) is
used.
The same techniques and structures are used for encrypting both the
plaintext and the keys.  This is different from the approach used by
both "Cryptographic Message Syntax (CMS)" RFC5652 and "JSON Web
Encryption (JWE)" RFC7516 where different structures are used for the
content layer and for the recipient layer.  Two structures are
defined: COSE_Encrypt to hold the encrypted content and
COSE_recipient to hold the encrypted keys for recipients.  Examples
of encrypted messages can be found in EnvelopedExamples.
The same techniques and nearly the same structure is used for
encrypting both the plaintext and the keys.  This is different from
the approach used by both "Cryptographic Message Syntax (CMS)"
RFC5652 and "JSON Web Encryption (JWE)" RFC7516 where different
structures are used for the content layer and for the recipient
layer.  Two structures are defined: COSE_Encrypt to hold the
encrypted content and COSE_recipient to hold the encrypted keys for
recipients.  Examples of encrypted messages can be found in
EnvelopedExamples.
Encode the Enc_structure to a byte stream (Additional
Authenticated Data (AAD)), using the encoding described in CBOR-
Canonical.
Encode the Enc_structure to a byte string (Additional
Authenticated Data (AAD)), using the encoding described in CBOR-
Canonical.
The key is determined by the key and algorithm in the recipient
structure.  The encryption algorithm and size of the key to be
used are inputs into the KDF used for the recipient.  (For
direct, the KDF can be thought of as the identity operation.)
Examples of these algorithms are found in Sections !!! DIRECT-
KDF !!!  and !!! ECDH !!!  of I-D.schaad-cose-rfc8152bis-algs.
Encode the Enc_structure to a byte stream (AAD), using the
encoding described in CBOR-Canonical.
Encode the Enc_structure to a byte string (AAD), using the
encoding described in CBOR-Canonical.
The key is determined by the key and algorithm in the recipient
structure.  The encryption algorithm and size of the key to be
used are inputs into the KDF used for the recipient.  (For
direct, the KDF can be thought of as the identity operation.)
Examples of these algorithms are found in Sections !!! DIRECT-
KDF !!!  and !!! ECDH !!! .
Encrypt and encode the MAC key for each recipient of the message.
For COSE_Mac structures, encrypt and encode the MAC key for each
recipient of the message.
Obtain the cryptographic key from one of the recipients of the
message.
For COSE_Mac structures, obtain the cryptographic key from one of
the recipients of the message.
A COSE Key structure is built on a CBOR map object.  The set of
common parameters that can appear in a COSE Key can be found in the
IANA "COSE Key Common Parameters" registry (cose-key-map-registry).
Additional parameters defined for specific key types can be found in
the IANA "COSE Key Type Parameters" registry (cose-key-parameter-
registry).
A COSE Key structure is built on a CBOR map object.  The set of
common parameters that can appear in a COSE Key can be found in the
IANA "COSE Key Common Parameters" registry (cose-key-map-registry).
Additional parameters defined for specific key types can be found in
the IANA "COSE Key Type Parameters" registry (COSE.KeyParameters).
This parameter is used to identify the family of keys for this
structure and, thus, the set of key-type-specific parameters to be
found.  The set of values defined in this document can be found in
!!!! TABLE_KEY_TYPES !!! .  This parameter MUST be present in a
key object.  Implementations MUST verify that the key type is
appropriate for the algorithm being processed.  The key type MUST
be included as part of the trust decision process.
This parameter is used to identify the family of keys for this
structure and, thus, the set of key-type-specific parameters to be
found.  The set of values defined in this document can be found in
COSE.KeyTypes.  This parameter MUST be present in a key object.
Implementations MUST verify that the key type is appropriate for
the algorithm being processed.  The key type MUST be included as
part of the trust decision process.
Message Authentication Codes (MACs) provide data authentication and
integrity protection.  They provide either no or very limited data
origination.  A MAC, for example, can be used to prove the identity
of the sender to a third party.
Message Authentication Codes (MACs) provide data authentication and
integrity protection.  They provide either no or very limited data
origination.  A MAC, for example, cannot be used to prove the
identity of the sender to a third party.
General KDFs work well with the first type of secret, can do
reasonably well with the second type of secret, and generally do
poorly with the last type of secret.  None of the KDFs in this
section are designed to deal with the type of secrets that are used
for passwords.  Functions like PBES2 RFC8018 need to be used for that
type of secret.
The same KDF can be set up to deal with the first two types of
secrets in a different way.  The KDF defined in !!! HDKF !!!  is such
a function.  This is reflected in the set of algorithms defined for
the HMAC-based Extract-and-Expand Key Derivation Function (HKDF).
General KDFs work well with the first type of secret, can do
reasonably well with the second type of secret, and generally do
poorly with the last type of secret.  Functions like PBES2 RFC8018
need to be used for non-random secrets.
The same KDF can be set up to deal with the first two types of
secrets in a different way.  The KDF defined in !!! HDKF !!! (section
XXXX of I-D.schaad-cose-rfc8152bis-algs) is such a function.  This is
reflected in the set of algorithms defined around the HMAC-based
Extract-and-Expand Key Derivation Function (HKDF).
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 those 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.  The names of the recipient algorithm
classes used here are the same as those defined in RFC7516.  Other
specifications use different terms for the recipient algorithm
classes or do not support some of the recipient algorithm classes.
The 'recipients' field is normally absent, but can be used.
Applications MUST deal with a recipient field being present, not
being able to decrypt that recipient is an acceptable way of
dealing with it.  Failing to process the message is not an
acceptable way of dealing with it.
The 'recipients' field is normally absent, but can be used.
Applications MUST deal with a recipient field being present that
has an unsupported algorthms, not being able to decrypt that
recipient is an acceptable way of dealing with it.  Failing to
process the message is not an acceptable way of dealing with it.
Static-Static DH: where a static key is used for both the sender
and the recipient.  The use of static keys allows for the
recipient to get a weak version of data origination for the
message.  When static-static key agreement is used, then some
piece of unique data for the KDF is required to ensure that a
different key is created for each message.
Static-Static (SS) DH: where a static key is used for both the
sender and the recipient.  The use of static keys allows for the
recipient to get a weak version of data origination for the
message.  When static-static key agreement is used, then some
piece of unique data for the KDF is required to ensure that a
different key is created for each message.
This document is designed to provide a set of security services, but
not implementation requirements for specific usage.  The
interoperability requirements are provided for how each of the
individual services are used and how the algorithms are to be used
for interoperability.  The requirements about which algorithms and
which services are needed are deferred to each application.
An example of a profile can be found in OSCOAP where two profiles are
being developed.  One is for carrying content by itself, and the
other is for carrying content in combination with CoAP headers.
This document is designed to provide a set of security services, but
not impose algorithm implementation requirements for specific usage.
The interoperability requirements are provided for how each of the
individual services are used and how the algorithms are to be used
for interoperability.  The requirements about which algorithms and
which services are needed are deferred to each application.
An example of a profile can be found in I-D.ietf-core-object-security
where a profiles was developed for carrying content in combination
with CoAP headers.
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 encoded.  This document assumes
that the data will be provided as a byte stream.  More information
can be found in Extern_AAD.
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 also needs to define how the fixed portion of
the IV is determined.
When applications use externally defined authenticated data, they
need to define how that data is encoded.  This document assumes
that the data will be provided as a byte string.  More information
can be found in Extern_AAD.
IANA has assigned the following tags from the "CBOR Tags" registry.
The tags for COSE_Sign1, COSE_Encrypt0, and COSE_Mac0 were assigned
in the 1 to 23 value range (one byte long when encoded).  The tags
for COSE_Sign, COSE_Encrypt, and COSE_Mac were assigned in the 24 to
255 value range (two bytes long when encoded).
The tags assigned are in CBOR-Tags.
IANA has created a registry titled "COSE Header Parameters".  The
registry has been created to use the "Expert Review Required"
registration procedure RFC8126.  Guidelines for the experts are
provided in review.  It should be noted that, in addition to the
expert review, some portions of the registry require a specification,
potentially a Standards Track RFC, be supplied as well.
The name is present to make it easier to refer to and discuss the
registration entry.  The value is not used in the protocol.  Names
are to be unique in the table.
This is the value used for the label.  The label can be either an
integer or a string.  Registration in the table is based on the
value of the label requested.  Integer values between 1 and 255
and strings of length 1 are designated as "Standards Action".
Integer values from 256 to 65535 and strings of length 2 are
designated as "Specification Required".  Integer values of greater
than 65535 and strings of length greater than 2 are designated as
"Expert Review".  Integer values in the range -1 to -65536 are
"delegated to the COSE Header Algorithm Parameters registry".
Integer values less than -65536 are marked as private use.
This contains a pointer to the registry used to contain values
where the set is limited.
The initial contents of the registry is ...
IANA has created a registry titled "COSE Header Algorithm
Parameters".  The registry uses the "Expert Review Required"
registration procedure.  Expert review guidelines are provided in
review.
The name is present to make it easier to refer to and discuss the
registration entry.  The value is not used in the protocol.
The algorithm(s) that this registry entry is used for.  This value
is taken from the "COSE Algorithms" registry.  Multiple algorithms
can be specified in this entry.  For the table, the algorithm/
label pair MUST be unique.
This is the value used for the label.  The label is an integer in
the range of -1 to -65536.
IANA has created a registry titled "COSE Algorithms".  The registry
has been created to use the "Expert Review Required" registration
procedure.  Guidelines for the experts are provided in review.  It
should be noted that, in addition to the expert review, some portions
of the registry require a specification, potentially a Standards
Track RFC, be supplied as well.
IANA has created a registry titled "COSE Key Common Parameters".  The
registry has been created to use the "Expert Review Required"
registration procedure.  Guidelines for the experts are provided in
review.  It should be noted that, in addition to the expert review,
some portions of the registry require a specification, potentially a
Standards Track RFC, be supplied as well.
The value to be used to identify this algorithm.  Key map labels
MUST be unique.  The label can be a positive integer, a negative
integer, or a string.  Integer values between 0 and 255 and
strings of length 1 are designated as "Standards Action".  Integer
values from 256 to 65535 and strings of length 2 are designated as
"Specification Required".  Integer values of greater than 65535
and strings of length greater than 2 are designated as "Expert
Review".  Integer values in the range -65536 to -1 are "used for
key parameters specific to a single algorithm delegated to the
COSE Key Type Parameters registry".  Integer values less than
-65536 are marked as private use.
This field denotes the registry that values come from, if one
exists.
IANA has created a registry titled "COSE Key Type Parameters".  The
registry has been created to use the "Expert Review Required"
registration procedure.  Expert review guidelines are provided in
review.
This field contains a descriptive string of a key type.  This
should be a value that is in the "COSE Key Common Parameters"
registry and is placed in the 'kty' field of a COSE Key structure.
The label is to be unique for every value of key type.  The range
of values is from -65536 to -1.  Labels are expected to be reused
for different keys.
IANA has created a new registry titled "COSE Key Types".  The
registry has been created to use the "Expert Review Required"
registration procedure.  Expert review guidelines are provided in
review.
This is a descriptive name that enables easier reference to the
item.  The name MUST be unique.  It is not used in the encoding.
This is the value used to identify the curve.  These values MUST
be unique.  The value can be a positive integer, a negative
integer, or a string.
IANA has created a registry titled "COSE Elliptic Curves".  The
registry has been created to use the "Expert Review Required"
registration procedure.  Guidelines for the experts are provided in
review.  It should be noted that, in addition to the expert review,
some portions of the registry require a specification, potentially a
Standards Track RFC, be supplied as well.
IANA assigned tags in the "CBOR Tags" registry as part of processing
RFC8152.  IANA is requested to update the references from RFC8152 to
this document.
IANA created a registry titled "COSE Header Parameters" as part of
processing RFC8152.  The registry has been created to use the "Expert
Review Required" registration procedure RFC8126.
IANA created a registry titled "COSE Header Algorithm Parameters" as
part of processing RFC8152.  The registry has been created to use the
"Expert Review Required" registration procedure RFC8126.
IANA is requested to update the references from RFC8152 to this
document.  This document does not update the expert review guidelines
provided in RFC8152.
IANA created a registry titled "COSE Key Common Parameters" as part
of the processing of RFC8152.  The registry has been created to use
the "Expert Review Required" registration procedure RFC8126.
IANA has added the following entries to the "CoAP Content-Formats"
registry.
IANA added the following entries to the "CoAP Content-Formats"
registry while processing RFC8152.  IANA is requested to update the
reference value from RFC8152 to .
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)" RFC7049.  CBOR extended the data model of the JavaScript
Object Notation (JSON) RFC8259 by allowing for binary data, among
other changes.  CBOR is being adopted by several of the IETF working
groups dealing with the IoT world as their encoding of data
structures.  CBOR was designed specifically to be both small in terms
of messages transport and implementation size and 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.
The core COSE specification consists of two documents.  I-D.schaad-
cose-rfc8152bis-struct contains the serialization structures and the
procedures for using the different cryptographic algorithms.  This
document provides for an initial set of algorithms that are then use
with those structures.
The core COSE specification consists of two documents.  I-D.schaad-
cose-rfc8152bis-struct contains the serialization structures and the
procedures for using the different cryptographic algorithms.  This
document provides for an initial set of algorithms that are then use
with those structures.  Additional algorithms beyond what are in this
document are defined elsewhere.
Note: Use of this 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.
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.
The HMAC algorithm is parameterized by an inner and outer padding, a
hash function (h), and an authentication tag value length.  For this
specification, the inner and outer padding are fixed to the values
set in RFC2104.  The length of the authentication tag corresponds to
the difficulty of producing a forgery.  For use in constrained
environments, we define a set of HMAC algorithms that are truncated.
There are currently no known issues with truncation; however, the
security strength of the message tag is correspondingly reduced in
strength.  When truncating, the leftmost tag length bits are kept and
transmitted.
The HMAC algorithm is parameterized by an inner and outer padding, a
hash function (h), and an authentication tag value length.  For this
specification, the inner and outer padding are fixed to the values
set in RFC2104.  The length of the authentication tag corresponds to
the difficulty of producing a forgery.  For use in constrained
environments, we define one HMAC algorithms that is truncated.  There
are currently no known issues with truncation; however, the security
strength of the message tag is correspondingly reduced in strength.
When truncating, the leftmost tag length bits are kept and
transmitted.
This docuement defines the identifier and usages for three content
encryption algorithms.
This document defines the identifier and usages for three content
encryption algorithms.
ChaCha20 and Poly1305 combined together is an AEAD mode that is
defined in RFC7539.  This is an algorithm defined to be a cipher that
is not AES and thus would not suffer from any future weaknesses found
in AES.  These cryptographic functions are designed to be fast in
software-only implementations.
The ChaCha20/Poly1305 AEAD construction defined in RFC7539 has no
parameterization.  It takes a 256-bit key and a 96-bit nonce, as well
as the plaintext and additional data as inputs and produces the
ciphertext as an option.  We define one algorithm identifier for this
algorithm in Table-CHACHA.
ChaCha20 and Poly1305 combined together is an AEAD mode that is
defined in RFC8439.  This is an algorithm defined to be a cipher that
is not AES and thus would not suffer from any future weaknesses found
in AES.  These cryptographic functions are designed to be fast in
software-only implementations.
The ChaCha20/Poly1305 AEAD construction defined in RFC8439 has no
parameterization.  It takes a 256-bit key and a 96-bit nonce, as well
as the plaintext and additional data as inputs and produces the
ciphertext as an option.  We define one algorithm identifier for this
algorithm in Table-CHACHA.
IANA has created a new registry titled "COSE Algorithms".  The
registry has been created to use the "Expert Review Required"
registration procedure.  Guidelines for the experts are provided in
review.  It should be noted that, in addition to the expert review,
some portions of the registry require a specification, potentially a
Standards Track RFC, be supplied as well.
The initial contents of the registry can be found in Tables
table_ecdsa, table-eddsa-algs, table-hmac, table-aes-mac, table-AES-
GCM, table-AES-CCM, Table-CHACHA, table-direct, table-direct-kdf,
table_aes_keywrap, table-ecdh-es-table, and table-ecdh-es-table-wrap.
All of the entries in the "References" column of this registry point
to this document.  All of the entries in the "Recommended" column are
set to "Yes".
Additionally, the label of 0 is to be marked as 'Reserved'.
IANA created and populated the "COSE Algorithms" registry as part of
processing processing RFC8152.  IANA is requested to update the for
individual algorithms from RFC8152 to this document.
This document does not modify the guidance for designated experts.
IANA has created a new registry titled "COSE Elliptic Curves".  The
registry has been created to use the "Expert Review Required"
registration procedure.  Guidelines for the experts are provided in
review.  It should be noted that, in addition to the expert review,
some portions of the registry require a specification, potentially a
Standards Track RFC, be supplied as well.
This registry has been initially populated by the values in table-ec-
curves.  All of the entries in the "References" column of this
registry point to this document.  All of the entries in the
"Recommended" column are set to "Yes".
IANA created and populated the "COSE Elliptic Curves" registry as
part of processing RFC8152.  IANA is requested to change the
reference from RFC8152 to this document for all values in the
registry.
This document does not change the guidance for Designated Experts.