tech-invite   World Map
3GPP     Specs     Glossaries     UICC       T+       IETF     RFCs     Groups     SIP     ABNFs       Search     Home

RFC 8152

 
 
 

CBOR Object Signing and Encryption (COSE)

Part 5 of 6, p. 72 to 90
Prev Section       Next Section

 


prevText      Top      ToC       Page 72 
13.  Key Object Parameters

   The COSE_Key object defines a way to hold a single key object.  It is
   still required that the members of individual key types be defined.
   This section of the document is where we define an initial set of
   members for specific key types.

   For each of the key types, we define both public and private members.
   The public members are what is transmitted to others for their usage.
   Private members allow for the archival of keys by individuals.
   However, there are some circumstances in which private keys may be
   distributed to entities in a protocol.  Examples include: entities
   that have poor random number generation, centralized key creation for
   multi-cast type operations, and protocols in which a shared secret is
   used as a bearer token for authorization purposes.

   Key types are identified by the 'kty' member of the COSE_Key object.
   In this document, we define four values for the member:

   +-----------+-------+-----------------------------------------------+
   | Name      | Value | Description                                   |
   +-----------+-------+-----------------------------------------------+
   | OKP       | 1     | Octet Key Pair                                |
   | EC2       | 2     | Elliptic Curve Keys w/ x- and y-coordinate    |
   |           |       | pair                                          |
   | Symmetric | 4     | Symmetric Keys                                |
   | Reserved  | 0     | This value is reserved                        |
   +-----------+-------+-----------------------------------------------+

                         Table 21: Key Type Values

Top      Up      ToC       Page 73 
13.1.  Elliptic Curve Keys

   Two different key structures are defined for elliptic curve keys.
   One version uses both an x-coordinate and a y-coordinate, potentially
   with point compression ('EC2').  This is the traditional EC point
   representation that is used in [RFC5480].  The other version uses
   only the x-coordinate as the y-coordinate is either to be recomputed
   or not needed for the key agreement operation ('OKP').

   Applications MUST check that the curve and the key type are
   consistent and reject a key if they are not.

    +---------+-------+----------+------------------------------------+
    | Name    | Value | Key Type | Description                        |
    +---------+-------+----------+------------------------------------+
    | P-256   | 1     | EC2      | NIST P-256 also known as secp256r1 |
    | P-384   | 2     | EC2      | NIST P-384 also known as secp384r1 |
    | P-521   | 3     | EC2      | NIST P-521 also known as secp521r1 |
    | X25519  | 4     | OKP      | X25519 for use w/ ECDH only        |
    | X448    | 5     | OKP      | X448 for use w/ ECDH only          |
    | Ed25519 | 6     | OKP      | Ed25519 for use w/ EdDSA only      |
    | Ed448   | 7     | OKP      | Ed448 for use w/ EdDSA only        |
    +---------+-------+----------+------------------------------------+

                         Table 22: Elliptic Curves

13.1.1.  Double Coordinate Curves

   The traditional way of sending ECs has been to send either both the
   x-coordinate and y-coordinate or the x-coordinate and a sign bit for
   the y-coordinate.  The latter encoding has not been recommended in
   the IETF due to potential IPR issues.  However, for operations in
   constrained environments, the ability to shrink a message by not
   sending the y-coordinate is potentially useful.

   For EC keys with both coordinates, the 'kty' member is set to 2
   (EC2).  The key parameters defined in this section are summarized in
   Table 23.  The members that are defined for this key type are:

   crv: This contains an identifier of the curve to be used with the
        key.  The curves defined in this document for this key type can
        be found in Table 22.  Other curves may be registered in the
        future, and private curves can be used as well.

   x:   This 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.

Top      Up      ToC       Page 74 
   y:   This contains either the sign bit or the value of the
        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.

   d:   This contains the private key.

   For public keys, it is REQUIRED that 'crv', 'x', and 'y' be present
   in the structure.  For private keys, it is REQUIRED that 'crv' and
   'd' be present in the structure.  For private keys, it is RECOMMENDED
   that 'x' and 'y' also be present, but they can be recomputed from the
   required elements and omitting them saves on space.

   +-------+------+-------+--------+-----------------------------------+
   | Key   | Name | Label | CBOR   | Description                       |
   | Type  |      |       | Type   |                                   |
   +-------+------+-------+--------+-----------------------------------+
   | 2     | crv  | -1    | int /  | EC identifier - Taken from the    |
   |       |      |       | tstr   | "COSE Elliptic Curves" registry   |
   | 2     | x    | -2    | bstr   | x-coordinate                      |
   | 2     | y    | -3    | bstr / | y-coordinate                      |
   |       |      |       | bool   |                                   |
   | 2     | d    | -4    | bstr   | Private key                       |
   +-------+------+-------+--------+-----------------------------------+

                        Table 23: EC Key Parameters

13.2.  Octet Key Pair

   A new key type is defined for Octet Key Pairs (OKP).  Do not assume
   that keys using this type are elliptic curves.  This key type could
   be used for other curve types (for example, mathematics based on
   hyper-elliptic surfaces).

   The key parameters defined in this section are summarized in
   Table 24.  The members that are defined for this key type are:

   crv: This contains an identifier of the curve to be used with the
        key.  The curves defined in this document for this key type can
        be found in Table 22.  Other curves may be registered in the
        future and private curves can be used as well.

Top      Up      ToC       Page 75 
   x:   This contains the x-coordinate for the EC point.  The octet
        string represents a little-endian encoding of x.

   d:   This contains the private key.

   For public keys, it is REQUIRED that 'crv' and 'x' be present in the
   structure.  For private keys, it is REQUIRED that 'crv' and 'd' be
   present in the structure.  For private keys, it is RECOMMENDED that
   'x' also be present, but it can be recomputed from the required
   elements and omitting it saves on space.

   +------+-------+-------+--------+-----------------------------------+
   | Name | Key   | Label | Type   | Description                       |
   |      | Type  |       |        |                                   |
   +------+-------+-------+--------+-----------------------------------+
   | crv  | 1     | -1    | int /  | EC identifier - Taken from the    |
   |      |       |       | tstr   | "COSE Key Common Parameters"      |
   |      |       |       |        | registry                          |
   | x    | 1     | -2    | bstr   | x-coordinate                      |
   | d    | 1     | -4    | bstr   | Private key                       |
   +------+-------+-------+--------+-----------------------------------+

                    Table 24: Octet Key Pair Parameters

13.3.  Symmetric Keys

   Occasionally it is required that a symmetric key be transported
   between entities.  This key structure allows for that to happen.

   For symmetric keys, the 'kty' member is set to 4 ('Symmetric').  The
   member that is defined for this key type is:

   k: This contains the value of the key.

   This key structure does not have a form that contains only public
   members.  As it is expected that this key structure is going to be
   transmitted, care must be taken that it is never transmitted
   accidentally or insecurely.  For symmetric keys, it is REQUIRED that
   'k' be present in the structure.

             +------+----------+-------+------+-------------+
             | Name | Key Type | Label | Type | Description |
             +------+----------+-------+------+-------------+
             | k    | 4        | -1    | bstr | Key Value   |
             +------+----------+-------+------+-------------+

                    Table 25: Symmetric Key Parameters

Top      Up      ToC       Page 76 
14.  CBOR Encoder Restrictions

   There has been an attempt to limit the number of places where the
   document needs to impose restrictions on how the CBOR Encoder needs
   to work.  We have managed to narrow it down to the following
   restrictions:

   o  The restriction applies to the encoding of the Sig_structure, the
      Enc_structure, and the MAC_structure.

   o  The rules for "Canonical CBOR" (Section 3.9 of RFC 7049) MUST be
      used in these locations.  The main rule that needs to be enforced
      is that all lengths in these structures MUST be encoded such that
      they are using definite lengths, and the minimum length encoding
      is used.

   o  Applications MUST NOT generate messages with the same label used
      twice as a key in a single map.  Applications MUST NOT parse and
      process messages with the same label used twice as a key in a
      single map.  Applications can enforce the parse and process
      requirement by using parsers that will fail the parse step or by
      using parsers that will pass all keys to the application, and the
      application can perform the check for duplicate keys.

15.  Application Profiling Considerations

   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.

   It is intended that a profile of this document be created that
   defines the interoperability requirements for that specific
   application.  This section provides a set of guidelines and topics
   that need to be considered when profiling this document.

   o  Applications need to determine the set of messages defined in this
      document that they will be using.  The set of messages corresponds
      fairly directly to the set of security services that are needed
      and to the security levels needed.

Top      Up      ToC       Page 77 
   o  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.

   o  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 Section 4.3.

   o  Applications need to determine the set of security algorithms that
      are to be used.  When selecting the algorithms to be used as the
      mandatory-to-implement set, consideration should be given to
      choosing different types of algorithms when two are chosen for a
      specific purpose.  An example of this would be choosing HMAC-
      SHA512 and AES-CMAC as different MAC algorithms; the construction
      is vastly different between these two algorithms.  This means that
      a weakening of one algorithm would be unlikely to lead to a
      weakening of the other algorithms.  Of course, these algorithms do
      not provide the same level of security and thus may not be
      comparable for the desired security functionality.

   o  Applications may need to provide some type of negotiation or
      discovery method if multiple algorithms or message structures are
      permitted.  The method can be as simple as requiring
      preconfiguration of the set of algorithms to providing a discovery
      method built into the protocol.  S/MIME provided a number of
      different ways to approach the problem that applications could
      follow:

      *  Advertising in the message (S/MIME capabilities) [RFC5751].

      *  Advertising in the certificate (capabilities extension)
         [RFC4262].

      *  Minimum requirements for the S/MIME, which have been updated
         over time [RFC2633] [RFC5751] (note that [RFC2633] has been
         obsoleted by [RFC5751]).

Top      Up      ToC       Page 78 
16.  IANA Considerations

16.1.  CBOR Tag Assignment

   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 Table 1.

16.2.  COSE Header Parameters Registry

   IANA has created a new 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 Section 16.11.  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 columns of the registry are:

   Name:  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.

   Label:  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.

   Value Type:  This contains the CBOR type for the value portion of the
      label.

   Value Registry:  This contains a pointer to the registry used to
      contain values where the set is limited.

   Description:  This contains a brief description of the header field.

Top      Up      ToC       Page 79 
   Reference:  This contains a pointer to the specification defining the
      header field (where public).

   The initial contents of the registry can be found in Tables 2 and 27.
   All of the entries in the "References" column of this registry point
   to this document.

   Additionally, the label of 0 is to be marked as 'Reserved'.

16.3.  COSE Header Algorithm Parameters Registry

   IANA has created a new registry titled "COSE Header Algorithm
   Parameters".  The registry uses the "Expert Review Required"
   registration procedure.  Expert review guidelines are provided in
   Section 16.11.

   The columns of the registry are:

   Name:  The name is present to make it easier to refer to and discuss
      the registration entry.  The value is not used in the protocol.

   Algorithm:  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.

   Label:  This is the value used for the label.  The label is an
      integer in the range of -1 to -65536.

   Type:  This contains the CBOR type for the value portion of the
      label.

   Description:  This contains a brief description of the header field.

   Reference:  This contains a pointer to the specification defining the
      header field (where public).

   The initial contents of the registry can be found in Tables 13, 14,
   and 19.  All of the entries in the "References" column of this
   registry point to this document.

16.4.  COSE Algorithms Registry

   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

Top      Up      ToC       Page 80 
   Section 16.11.  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 columns of the registry are:

   Name:  A value that can be used to identify an algorithm in documents
      for easier comprehension.  The name SHOULD be unique.  However,
      the 'Value' field is what is used to identify the algorithm, not
      the 'name' field.

   Value:  The value to be used to identify this algorithm.  Algorithm
      values MUST be unique.  The value can be a positive integer, a
      negative integer, or a string.  Integer values between -256 and
      255 and strings of length 1 are designated as "Standards Action".
      Integer values from -65536 to 65535 and strings of length 2 are
      designated as "Specification Required".  Integer values greater
      than 65535 and strings of length greater than 2 are designated as
      "Expert Review".  Integer values less than -65536 are marked as
      private use.

   Description:  A short description of the algorithm.

   Reference:  A document where the algorithm is defined (if publicly
      available).

   Recommended:  Does the IETF have a consensus recommendation to use
      the algorithm?  The legal values are 'Yes', 'No', and
      'Deprecated'.

   The initial contents of the registry can be found in Tables 5, 6, 7,
   8, 9, 10, 11, 15, 16, 17, 18, and 20.  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'.

   NOTE: The assignment of algorithm identifiers in this document was
   done so that positive numbers were used for the first layer objects
   (COSE_Sign, COSE_Sign1, COSE_Encrypt, COSE_Encrypt0, COSE_Mac, and
   COSE_Mac0).  Negative numbers were used for second layer objects
   (COSE_Signature and COSE_recipient).  Expert reviewers should
   consider this practice, but are not expected to be restricted by this
   precedent.

Top      Up      ToC       Page 81 
16.5.  COSE Key Common Parameters Registry

   IANA has created a new 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
   Section 16.11.  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 columns of the registry are:

   Name:  This is a descriptive name that enables easier reference to
      the item.  It is not used in the encoding.

   Label:  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.

   CBOR Type:  This field contains the CBOR type for the field.

   Value Registry:  This field denotes the registry that values come
      from, if one exists.

   Description:  This field contains a brief description for the field.

   Reference:  This contains a pointer to the public specification for
      the field if one exists.

   This registry has been initially populated by the values in Table 3.
   All of the entries in the "References" column of this registry point
   to this document.

16.6.  COSE Key Type Parameters Registry

   IANA has created a new 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
   Section 16.11.

Top      Up      ToC       Page 82 
   The columns of the table are:

   Key Type:  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.

   Name:  This is a descriptive name that enables easier reference to
      the item.  It is not used in the encoding.

   Label:  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.

   CBOR Type:  This field contains the CBOR type for the field.

   Description:  This field contains a brief description for the field.

   Reference:  This contains a pointer to the public specification for
      the field if one exists.

   This registry has been initially populated by the values in Tables
   23, 24, and 25.  All of the entries in the "References" column of
   this registry point to this document.

16.7.  COSE Key Types Registry

   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
   Section 16.11.

   The columns of this table are:

   Name:  This is a descriptive name that enables easier reference to
      the item.  The name MUST be unique.  It is not used in the
      encoding.

   Value:  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.

   Description:  This field contains a brief description of the curve.

   References:  This contains a pointer to the public specification for
      the curve if one exists.

Top      Up      ToC       Page 83 
   This registry has been initially populated by the values in Table 21.
   The specification column for all of these entries will be this
   document.

16.8.  COSE Elliptic Curves Registry

   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
   Section 16.11.  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 columns of the table are:

   Name:  This is a descriptive name that enables easier reference to
      the item.  It is not used in the encoding.

   Value:  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 Action".  The integer values from 256 to
      65535 and -65536 to -257 are designated as "Specification
      Required".  Integer values over 65535 are designated as "Expert
      Review".  Integer values less than -65536 are marked as private
      use.

   Key Type:  This designates the key type(s) that can be used with this
      curve.

   Description:  This field contains a brief description of the curve.

   Reference:  This contains a pointer to the public specification for
      the curve if one exists.

   Recommended:  Does the IETF have a consensus recommendation to use
      the algorithm?  The legal values are 'Yes', 'No', and
      'Deprecated'.

   This registry has been initially populated by the values in Table 22.
   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".

Top      Up      ToC       Page 84 
16.9.  Media Type Registrations

16.9.1.  COSE Security Message

   This section registers the 'application/cose' media type in the
   "Media Types" registry.  These media types are used to indicate that
   the content is a COSE message.

      Type name: application

      Subtype name: cose

      Required parameters: N/A

      Optional parameters: cose-type

      Encoding considerations: binary

      Security considerations: See the Security Considerations section
      of RFC 8152.

      Interoperability considerations: N/A

      Published specification: RFC 8152

      Applications that use this media type: IoT applications sending
      security content over HTTP(S) transports.

      Fragment identifier considerations: N/A

      Additional information:

      *  Deprecated alias names for this type: N/A

      *  Magic number(s): N/A

      *  File extension(s): cbor

      *  Macintosh file type code(s): N/A

      Person & email address to contact for further information:
      iesg@ietf.org

      Intended usage: COMMON

      Restrictions on usage: N/A

      Author: Jim Schaad, ietf@augustcellars.com

Top      Up      ToC       Page 85 
      Change Controller: IESG

      Provisional registration?  No

16.9.2.  COSE Key Media Type

   This section registers the 'application/cose-key' and 'application/
   cose-key-set' media types in the "Media Types" registry.  These media
   types are used to indicate, respectively, that content is a COSE_Key
   or COSE_KeySet object.

   The template for registering 'application/cose-key' is:

      Type name: application

      Subtype name: cose-key

      Required parameters: N/A

      Optional parameters: N/A

      Encoding considerations: binary

      Security considerations: See the Security Considerations section
      of RFC 8152.

      Interoperability considerations: N/A

      Published specification: RFC 8152

      Applications that use this media type: Distribution of COSE based
      keys for IoT applications.

      Fragment identifier considerations: N/A

      Additional information:

      *  Deprecated alias names for this type: N/A

      *  Magic number(s): N/A

      *  File extension(s): cbor

      *  Macintosh file type code(s): N/A

      Person & email address to contact for further information:
      iesg@ietf.org

Top      Up      ToC       Page 86 
      Intended usage: COMMON

      Restrictions on usage: N/A

      Author: Jim Schaad, ietf@augustcellars.com

      Change Controller: IESG

      Provisional registration?  No

   The template for registering 'application/cose-key-set' is:

      Type name: application

      Subtype name: cose-key-set

      Required parameters: N/A

      Optional parameters: N/A

      Encoding considerations: binary

      Security considerations: See the Security Considerations section
      of RFC 8152.

      Interoperability considerations: N/A

      Published specification: RFC 8152

      Applications that use this media type: Distribution of COSE based
      keys for IoT applications.

      Fragment identifier considerations: N/A

      Additional information:

      *  Deprecated alias names for this type: N/A

      *  Magic number(s): N/A

      *  File extension(s): cbor

      *  Macintosh file type code(s): N/A

      Person & email address to contact for further information:
      iesg@ietf.org

      Intended usage: COMMON

Top      Up      ToC       Page 87 
      Restrictions on usage: N/A

      Author: Jim Schaad, ietf@augustcellars.com

      Change Controller: IESG

      Provisional registration?  No

16.10.  CoAP Content-Formats Registry

   IANA has added the following entries to the "CoAP Content-Formats"
   registry.

   +--------------------------------------+----------+-----+-----------+
   | Media Type                           | Encoding | ID  | Reference |
   +--------------------------------------+----------+-----+-----------+
   | application/cose; cose-type="cose-   |          | 98  | [RFC8152] |
   | sign"                                |          |     |           |
   | application/cose; cose-type="cose-   |          | 18  | [RFC8152] |
   | sign1"                               |          |     |           |
   | application/cose; cose-type="cose-   |          | 96  | [RFC8152] |
   | encrypt"                             |          |     |           |
   | application/cose; cose-type="cose-   |          | 16  | [RFC8152] |
   | encrypt0"                            |          |     |           |
   | application/cose; cose-type="cose-   |          | 97  | [RFC8152] |
   | mac"                                 |          |     |           |
   | application/cose; cose-type="cose-   |          | 17  | [RFC8152] |
   | mac0"                                |          |     |           |
   | application/cose-key                 |          | 101 | [RFC8152] |
   | application/cose-key-set             |          | 102 | [RFC8152] |
   +--------------------------------------+----------+-----+-----------+

                  Table 26: CoAP Content-Formats for COSE

16.11.  Expert Review Instructions

   All of the IANA registries established in this document are defined
   as expert review.  This section gives some general guidelines for
   what the experts should be looking for, but they are being designated
   as experts for a reason, so they should be given substantial
   latitude.

   Expert reviewers should take into consideration the following points:

   o  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

Top      Up      ToC       Page 88 
      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.

   o  Specifications are required for the standards track range of point
      assignment.  Specifications should exist for specification
      required ranges, but early assignment before a specification is
      available is considered to be permissible.  Specifications are
      needed for the first-come, first-serve range if they are expected
      to be used outside of closed environments in an interoperable way.
      When specifications are not provided, the description provided
      needs to have sufficient information to identify what the point is
      being used for.

   o  Experts should take into account the expected usage of fields when
      approving point assignment.  The fact that there is a range for
      standards track documents does not mean that a standards track
      document cannot have points assigned outside of that range.  The
      length of the encoded value should be weighed against how many
      code points of that length are left, the size of device it will be
      used on, and the number of code points left that encode to that
      size.

   o  When algorithms are registered, vanity registrations should be
      discouraged.  One way to do this is to require registrations to
      provide additional documentation on security analysis of the
      algorithm.  Another thing that should be considered is requesting
      an opinion on the algorithm from the Crypto Forum Research Group
      (CFRG).  Algorithms that do not meet the security requirements of
      the community and the messages structures should not be
      registered.

17.  Security Considerations

   There are a number of security considerations that need to be taken
   into account by implementers of this specification.  The security
   considerations that are specific to an individual algorithm are
   placed next to the description of the algorithm.  While some
   considerations have been highlighted here, additional considerations
   may be found in the documents listed in the references.

   Implementations need to protect the private key material for any
   individuals.  There are some cases in this document that need to be
   highlighted on this issue.

   o  Using the same key for two different algorithms can leak
      information about the key.  It is therefore recommended that keys
      be restricted to a single algorithm.

Top      Up      ToC       Page 89 
   o  Use of 'direct' as a recipient algorithm combined with a second
      recipient algorithm exposes the direct key to the second
      recipient.

   o  Several of the algorithms in this document have limits on the
      number of times that a key can be used without leaking information
      about the key.

   The use of ECDH and direct plus KDF (with no key wrap) will not
   directly lead to the private key being leaked; the one way function
   of the KDF will prevent that.  There is, however, a different issue
   that needs to be addressed.  Having two recipients requires that the
   CEK be shared between two recipients.  The second recipient therefore
   has a CEK that was derived from material that can be used for the
   weak proof of origin.  The second recipient could create a message
   using the same CEK and send it to the first recipient; the first
   recipient would, for either static-static ECDH or direct plus KDF,
   make an assumption that the CEK could be used for proof of origin
   even though it is from the wrong entity.  If the key wrap step is
   added, then no proof of origin is implied and this is not an issue.

   Although it has been mentioned before, the use of a single key for
   multiple algorithms has been demonstrated in some cases to leak
   information about a key, provide the opportunity for attackers to
   forge integrity tags, or gain information about encrypted content.
   Binding a key to a single algorithm prevents these problems.  Key
   creators and key consumers are strongly encouraged not only to create
   new keys for each different algorithm, but to include that selection
   of algorithm in any distribution of key material and strictly enforce
   the matching of algorithms in the key structure to algorithms in the
   message structure.  In addition to checking that algorithms are
   correct, the key form needs to be checked as well.  Do not use an
   'EC2' key where an 'OKP' key is expected.

   Before using a key for transmission, or before acting on information
   received, a trust decision on a key needs to be made.  Is the data or
   action something that the entity associated with the key has a right
   to see or a right to request?  A number of factors are associated
   with this trust decision.  Some of the ones that are highlighted here
   are:

   o  What are the permissions associated with the key owner?

   o  Is the cryptographic algorithm acceptable in the current context?

   o  Have the restrictions associated with the key, such as algorithm
      or freshness, been checked and are they correct?

Top      Up      ToC       Page 90 
   o  Is the request something that is reasonable, given the current
      state of the application?

   o  Have any security considerations that are part of the message been
      enforced (as specified by the application or 'crit' parameter)?

   There are a large number of algorithms presented in this document
   that use nonce values.  For all of the nonces defined in this
   document, there is some type of restriction on the nonce being a
   unique value either for a key or for some other conditions.  In all
   of these cases, there is no known requirement on the nonce being both
   unique and unpredictable; under these circumstances, it's reasonable
   to use a counter for creation of the nonce.  In cases where one wants
   the pattern of the nonce to be unpredictable as well as unique, one
   can use a key created for that purpose and encrypt the counter to
   produce the nonce value.

   One area that has been starting to get exposure is doing traffic
   analysis of encrypted messages based on the length of the message.
   This specification does not provide for a uniform method of providing
   padding as part of the message structure.  An observer can
   distinguish between two different strings (for example, 'YES' and
   'NO') based on the length for all of the content encryption
   algorithms that are defined in this document.  This means that it is
   up to the applications to document how content padding is to be done
   in order to prevent or discourage such analysis.  (For example, the
   strings could be defined as 'YES' and 'NO '.)



(page 90 continued on part 6)

Next Section