Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8152

CBOR Object Signing and Encryption (COSE)

Pages: 121
Obsoleted by:  90529053
Part 5 of 6 – Pages 72 to 90
First   Prev   Next

Top   ToC   RFC8152 - Page 72   prevText

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   ToC   RFC8152 - 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   ToC   RFC8152 - 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   ToC   RFC8152 - 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   ToC   RFC8152 - 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   ToC   RFC8152 - 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   ToC   RFC8152 - 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   ToC   RFC8152 - 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   ToC   RFC8152 - 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   ToC   RFC8152 - 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   ToC   RFC8152 - 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   ToC   RFC8152 - 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   ToC   RFC8152 - 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   ToC   RFC8152 - 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   ToC   RFC8152 - 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   ToC   RFC8152 - 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   ToC   RFC8152 - 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   ToC   RFC8152 - 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   ToC   RFC8152 - 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