CBOR Object Signing and Encryption (COSE): Additional Algorithms
draft-schaad-cose-more-algs-01

Versions: 00 01                                                         
Network Working Group                                          J. Schaad
Internet-Draft                                            August Cellars
Intended status: Informational                               22 May 2020
Expires: 23 November 2020


    CBOR Object Signing and Encryption (COSE): Additional Algorithms
                     draft-schaad-cose-more-algs-01

Abstract

   The CBOR Object Signing and Encryption (COSE) syntax
   [I-D.ietf-cose-rfc8152bis-struct] allows for adding additional
   algorithms to the registries.  This document adds one additional key
   wrap algorithm to the registry using the AES Wrap with Padding
   Algorithm [RFC5649].  This document adds Keccak Message
   Authentication Code (KMAC) algorithms as well as using KMAC as a Key
   Derivation Function (KDF).

Contributing to this document

   This note is to be removed before publishing as an RFC.

   The source for this draft is being maintained in GitHub.  Suggested
   changes should be submitted as pull requests at https://github.com/
   cose-wg/X509 Editorial changes can be managed in GitHub, but any
   substantial issues need to be discussed on the COSE mailing list.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 23 November 2020.







Schaad                  Expires 23 November 2020                [Page 1]


Internet-Draft               COSE Algorithms                    May 2020


Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Simplified BSD License text
   as described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Terminology  . . . . . . . . . . . . . . . .   3
     1.2.  Open Issues . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Signature Algorithms  . . . . . . . . . . . . . . . . . . . .   3
   3.  Message Authentication Code (MAC) Algorithms  . . . . . . . .   3
     3.1.  Keccak Message Authentication Code (KMAC) . . . . . . . .   4
   4.  AES Key Wrap with Padding . . . . . . . . . . . . . . . . . .   5
     4.1.  Security Considerations for AES-KW with Padding . . . . .   6
   5.  Key Derivation Functions (KDFs) . . . . . . . . . . . . . . .   6
     5.1.  KMAC KDF  . . . . . . . . . . . . . . . . . . . . . . . .   6
   6.  Content Key Distribution Methods  . . . . . . . . . . . . . .   8
     6.1.  Direct Key with KDF . . . . . . . . . . . . . . . . . . .   8
       6.1.1.  Security Considerations . . . . . . . . . . . . . . .   9
     6.2.  Direct ECDH . . . . . . . . . . . . . . . . . . . . . . .   9
     6.3.  ECDH with Key Wrap  . . . . . . . . . . . . . . . . . . .  10
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
     8.1.  Changes to the Algorithm Table  . . . . . . . . . . . . .  12
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   The CBOR Object Signing and Encryption (COSE) syntax
   [I-D.ietf-cose-rfc8152bis-struct] is defined to have an object based
   set of security primitives using CBOR [I-D.ietf-cbor-7049bis] for use
   in constrained environments.  COSE has algorithm agility so that
   documents like this one can register algorithms which are needed.

   In this document we add:




Schaad                  Expires 23 November 2020                [Page 2]


Internet-Draft               COSE Algorithms                    May 2020


   *  The AES Wrap with Padding algorithm.

   *  Keccak Message Authentication Code (KMAC) algorithms.

   *  KMAC as a Key Derivation Function (KDF) for direct and key
      agreement algorithms.

1.1.  Requirements Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

1.2.  Open Issues

   This section is to be removed before publishing as an RFC.

   *  Should 192-bit AES Key Wrap be omitted or just given a large
      identifier?  (John)

   *  Add the cSHAKE algorithms to the list?  (Bob)

   *  RESOLVED: A desire has been expressed to all for the use of AES
      Key Wrap with Padding as a content encryption algorithm.  This is
      not compatible with the requirement that all content encryption
      algorithms "support authentication of both the content and
      additional data."  AES Key Wrap is an AE not an AEAD algorithm.
      (Jim) Response: Russ said it was ok just to be a key wrap
      algorithm.

2.  Signature Algorithms

   This section is to be removed before publishing as an RFC.

   This document defines no new signature algorithms.

3.  Message Authentication Code (MAC) Algorithms












Schaad                  Expires 23 November 2020                [Page 3]


Internet-Draft               COSE Algorithms                    May 2020


3.1.  Keccak Message Authentication Code (KMAC)

   As part of the definition of the SHA-3 algorithms, NIST also defined
   a number of algorithms that are based on SHA-3 [NIST-800-185].  The
   Keccak Message Authentication Code (KMAC) is defined in that
   document.  KMAC has a big performance advantage when compared to
   Hash-Based Message Authentication Code (HMAC) [RFC2104] [RFC4231] as
   it was designed to deal with the length extension attacks that forced
   the two pass structure of HMAC.

   KMAC is parameterized with four inputs:

   *  K - the key used for authentication

   *  X - the byte string to be authenticated

   *  L - the size of the authentication value in bits.  This MUST be at
      least 64 and SHOULD be at least 128.

   *  S - customization string which shall be a zero length byte string.

   The algorithm identifier does not encode the length of the
   authentication tag, unlike the MAC algorithms defined in
   [I-D.ietf-cose-rfc8152bis-algs].  This is because shortened tags for
   those algorithms are generated by truncating a longer output.
   However, KMAC takes the resultant output length as one of the
   parameters and will generate different outputs depending on the
   length.  The length of the MAC code is therefore chosen by the
   sender, and the length is inferred from the actual tag by the
   validator.  If an attacker attempts to gain an advantage by
   shortening the tag, KMAC is not going to generate the correct tag.

        +----------+-------+------------------------+-------------+
        | Name     | Value | Description            | Recommended |
        +==========+=======+========================+=============+
        | KMAC 128 | TBD4  | KMAC w/ SHA-3 128-bits | Yes         |
        +----------+-------+------------------------+-------------+
        | KMAC 256 | TBD5  | KMAC w/ SHA-3 256-bits | Yes         |
        +----------+-------+------------------------+-------------+

                                  Table 1

   When using a COSE key for this algorithm, the following checks are
   made:

   *  The 'kty' field MUST be present, and it MUST be 'Symmetric'.





Schaad                  Expires 23 November 2020                [Page 4]


Internet-Draft               COSE Algorithms                    May 2020


   *  If the 'alg' field is present, it MUST match the KMAC algorithm
      being used.

   *  If the 'key_ops' field is present, it MUST include 'MAC create'
      when creating an KMAC authentication tag.

   *  If the 'key_ops' field is present, it MUST include 'MAC verify'
      when verifying an KMAC authentication tag.

   Implementations creating and validating MAC values MUST validate that
   the key type, key length, and algorithm are correct and appropriate
   for the entities involved.

4.  AES Key Wrap with Padding

   The AES Key Wrap with Padding is defined in [RFC5649].  This
   algorithm uses an AES key to wrap a value that is a multiple of 8
   bits.  As such, it can be used to wrap not only the key sizes for the
   content encryption algorithms, but additionally it can be used to
   encrypt off size keys that can be used with the keyed hash functions
   or key derivation functions.  The algorithm uses a single fixed
   parameter, the initial value.  This value is fixed in section 3 of
   [RFC5649], this is a different value from that used for the AES Key
   Wrap algorithm of [RFC3394].  There are no public parameters that
   very on a per-invocation bases.  This algorithm does not support
   additional data and thus the protected header field MUST be empty.

   +------------+-------+------+------------------------+-------------+
   | Name       | Value | Key  | Description            | Recommended |
   |            |       | Size |                        |             |
   +============+=======+======+========================+=============+
   | A128KW-Pad | TBD1  | 128  | AES Key Wrap w/padding | Yes         |
   |            |       |      | and a 128-bit key      |             |
   +------------+-------+------+------------------------+-------------+
   | A192KW-Pad | TBD2  | 192  | AES Key Wrap w/padding | No          |
   |            |       |      | and a 192-bit key      |             |
   +------------+-------+------+------------------------+-------------+
   | A256KW-Pad | TBD3  | 256  | AES Key Wrap w/padding | Yes         |
   |            |       |      | and a 256-bit key      |             |
   +------------+-------+------+------------------------+-------------+

                  Table 2: AES Key Wrap Algorithm Values

   When using a COSE key for this algorithm, the following checks are
   made:

   *  The 'kty' field MUST be present, and it MUST be 'Symmetric'.




Schaad                  Expires 23 November 2020                [Page 5]


Internet-Draft               COSE Algorithms                    May 2020


   *  If the 'alg' field is present, it MUST match the AES Key Wrap
      algorithm being used.

   *  If the 'key_ops' field is present, it MUST include 'encrypt' or
      'wrap key' when encrypting.

   *  If the 'key_ops' field is present, it MUST include 'decrypt' or
      'unwrap key' when decrypting.

4.1.  Security Considerations for AES-KW with Padding

   The shared secret needs to have some method to be regularly updated
   over time.  The shared secret is the basis of trust.

5.  Key Derivation Functions (KDFs)

5.1.  KMAC KDF

   KMAC can additionally be used as a key derivation function
   [NIST-800-56C].  KMAC has a big advantage over the HKDF function,
   defined in [HKDF], as it executes the hashing function once as
   opposed to either two or four times for HKDF w/ HMAC SHA-256.  This
   advantage may be offset by having SHA-256 in hardware and KMAC in
   software, so that should be one consideration in deciding which one
   to use.

   The KMAC-KDF algorithm takes these inputs:

   *  secret -- a shared value that is secret.  Secrets may be either
      previously shared or derived from operations like a Diffie-Hellman
      (DH) key agreement.

   *  salt -- an optional value that is used to change the generation
      process.  The salt value can be either public or private.  If the
      salt is public and carried in the message, then the 'salt'
      algorithm header parameter defined in Table 9 of
      [I-D.ietf-cose-rfc8152bis-algs] is used.  While [HKDF] suggests
      that the length of the salt be the same as the length of the
      underlying hash value, any positive salt length will improve the
      security as different key values will be generated.  This
      parameter is protected by being included in the key computation
      and does not need to be separately authenticated.  The salt value
      does not need to be unique for every message sent.

   *  length -- the number of bytes of output that need to be generated.






Schaad                  Expires 23 November 2020                [Page 6]


Internet-Draft               COSE Algorithms                    May 2020


   *  context information -- Information that describes the context in
      which the resulting value will be used.  Making this information
      specific to the context in which the material is going to be used
      ensures that the resulting material will always be tied to that
      usage.  The context structure defined in Section 5.2 of
      [I-D.ietf-cose-rfc8152bis-algs] is used by the KDFs in this
      document.

   Full details of how the key derivation works can be found in
   Section 4 of [NIST-800-56C].  A quick summary of the details is
   provided here for simplicity.  The KMAC function call is:

             Result = KMAC#(salt, x, outputBits, "KDF")

   where:

   *  salt is the same parameter as above

   *  x is built as _counter || Z || FixedInfo_.  Where counter is a
      4-byte unsigned integer of 0, Z is the secret, and FixedInfo is
      the context information.

   *  outputBits is length * 8

   One algorithm parameter is defined for the KMAC-KDF function.

   +------+-------+------+------------------------------+-------------+
   | Name | Label | Type | Algorithm                    | Description |
   +======+=======+======+==============================+=============+
   | salt | -20   | bstr | direct+KMAC-128-KDF,         | Random salt |
   |      |       |      | direct+KMAC-256-KDF, ECDH-   |             |
   |      |       |      | ES+KMAC-128-KDF, ECDH-       |             |
   |      |       |      | ES+KMAC-256-KDF, ECDH-       |             |
   |      |       |      | SS+KMAC-128-KDF, ECDH-       |             |
   |      |       |      | SS+KMAC-256-KDF ECDH-        |             |
   |      |       |      | ES+KMAC-128-KDF+A128KW,      |             |
   |      |       |      | ECDH-ES+KMAC-256-KDF+A128KW, |             |
   |      |       |      | ECDH-SS+KMAC-128-KDF+A128KW, |             |
   |      |       |      | ECDH-SS+KMAC-256-KDF+A128KW  |             |
   |      |       |      | ECDH-ES+KMAC-256-KDF+A256KW, |             |
   |      |       |      | ECDH-ES+KMAC-256-KDF+A256KW, |             |
   |      |       |      | ECDH-SS+KMAC-256-KDF+A256KW, |             |
   |      |       |      | ECDH-SS+KMAC-256-KDF+A256KW  |             |
   +------+-------+------+------------------------------+-------------+

                  Table 3: KMAC-KDF Algorithm Parameters





Schaad                  Expires 23 November 2020                [Page 7]


Internet-Draft               COSE Algorithms                    May 2020


6.  Content Key Distribution Methods

6.1.  Direct Key with KDF

   These recipient algorithms take a common shared secret between the
   two parties and applies the KMAC-KDF function (Section 5.1), using
   the context structure defined in Section 5.2 of
   [I-D.ietf-cose-rfc8152bis-algs] to transform the shared secret into
   the CEK.  The 'protected' field can be of non-zero length.  Either
   the 'salt' parameter of KMAC-KDF or the 'PartyU nonce' parameter of
   the context structure MUST be present.  The salt/nonce parameter can
   be generated either randomly or deterministically.  The requirement
   is that it be a unique value for the shared secret in question.

   If the salt/nonce value is generated randomly, then it is suggested
   that the length of the random value be the same length as the KMAC-
   KDF.  While there is no way to guarantee that it will be unique,
   there is a high probability that it will be unique.  If the salt/
   nonce value is generated deterministically, it can be guaranteed to
   be unique, and thus there is no length requirement.

   A new IV must be used for each message if the same key is used.  The
   IV can be modified in a predictable manner, a random manner, or an
   unpredictable manner (i.e., encrypting a counter).

   The IV used for a key can also be generated from the same KMAC-KDF
   functionality as the key is generated.  If KMAC-KDF is used for
   generating the IV, the algorithm identifier is set to "IV-
   GENERATION".  Doing this requires that the context be modified for
   every IV generated to ensure that it is unique.

   When these algorithms are used, the key type MUST be 'symmetric'.

   The set of algorithms defined in this document can be found in
   Table 4.

    +-----------------+-------+----------+---------------------------+
    | Name            | Value | KDF      | Description               |
    +=================+=======+==========+===========================+
    | direct+KMAC-128 | TBD6  | KMAC-128 | Shared secret w/ KMAC-128 |
    +-----------------+-------+----------+---------------------------+
    | direct+KMAC-256 | TBD7  | KMAC-256 | Shared secret w/ KMAC-128 |
    +-----------------+-------+----------+---------------------------+

                       Table 4: Direct Key with KDF

   When using a COSE key for this algorithm, the following checks are
   made:



Schaad                  Expires 23 November 2020                [Page 8]


Internet-Draft               COSE Algorithms                    May 2020


   *  The 'kty' field MUST be present, and it MUST be 'Symmetric'.

   *  If the 'alg' field is present, it MUST match the algorithm being
      used.

   *  If the 'key_ops' field is present, it MUST include 'deriveKey' or
      'deriveBits'.

6.1.1.  Security Considerations

   The shared secret needs to have some method to be regularly updated
   over time.  The shared secret forms the basis of trust.  Although not
   used directly, it should still be subject to scheduled rotation.

   While these methods do not provide for perfect forward secrecy, as
   the same shared secret is used for all of the keys generated, if the
   key for any single message is discovered, only the message (or series
   of messages) using that derived key are compromised.  A new key
   derivation step will generate a new key that requires the same amount
   of work to get the key.

6.2.  Direct ECDH

   This document adds to the set of Direct ECDH algorithms which were
   defined in Section 6.3 of [I-D.ietf-cose-rfc8152bis-algs].  This is
   done by adding a changing the KDF used to derive the shared secret.

   +----------+-------+----------+------------+------+-----------------+
   | Name     | Value | KDF      | Ephemeral- | Key  | Description     |
   |          |       |          | Static     | Wrap |                 |
   +==========+=======+==========+============+======+=================+
   | ECDH-ES  | TBD8  | KMAC-128 | yes        | none | ECDH ES w/      |
   | +        |       |          |            |      | KMAC -          |
   | KMAC-128 |       |          |            |      | generate key    |
   |          |       |          |            |      | directly        |
   +----------+-------+----------+------------+------+-----------------+
   | ECDH-ES  | TBD9  | KMAC-256 | yes        | none | ECDH ES w/      |
   | +        |       |          |            |      | KMAC -          |
   | KMAC-256 |       |          |            |      | generate key    |
   |          |       |          |            |      | directly        |
   +----------+-------+----------+------------+------+-----------------+

                       Table 5: ECDH Algorithm Values

   Both of these algorithms use the same set of the ECDH Algorithm
   Parameters as their HKDF counterparts.





Schaad                  Expires 23 November 2020                [Page 9]


Internet-Draft               COSE Algorithms                    May 2020


   This document defines these algorithms to be used with the curves
   P-256, P-384, P-521, X25519, and X448.  Implementations MUST verify
   that the key type and curve are correct.  Different curves are
   restricted to different key types.  Implementations MUST verify that
   the curve and algorithm are appropriate for the entities involved.

   When using a COSE key for this algorithm, the following checks are
   made:

   *  The 'kty' field MUST be present, and it MUST be 'EC2' or 'OKP'.

   *  If the 'alg' field is present, it MUST match the key agreement
      algorithm being used.

   *  If the 'key_ops' field is present, it MUST include 'derive key' or
      'derive bits' for the private key.

   *  If the 'key_ops' field is present, it MUST be empty for the public
      key.

6.3.  ECDH with Key Wrap

   This document adds to the set of Direct ECDH algorithms which were
   defined in Section 6.4 of [I-D.ietf-cose-rfc8152bis-algs].  This is
   done by adding a changing the KDF used to derive the shared secret.


























Schaad                  Expires 23 November 2020               [Page 10]


Internet-Draft               COSE Algorithms                    May 2020


    +----------+-------+----------+------------+--------+-------------+
    | Name     | Value | KDF      | Ephemeral- | Key    | Description |
    |          |       |          | Static     | Wrap   |             |
    +==========+=======+==========+============+========+=============+
    | ECDH-ES  | TBD10 | KMAC-128 | yes        | A128KW | ECDH ES w/  |
    | +        |       |          |            |        | KMAC-128    |
    | KMAC-128 |       |          |            |        | and AES Key |
    | + A128KW |       |          |            |        | Wrap w/     |
    |          |       |          |            |        | 128-bit key |
    +----------+-------+----------+------------+--------+-------------+
    | ECDH-ES  | TBD11 | KMAC-256 | yes        | A256KW | ECDH ES w/  |
    | +        |       |          |            |        | KMAC-256    |
    | KMAC-256 |       |          |            |        | and AES Key |
    | + A256KW |       |          |            |        | Wrap w/     |
    |          |       |          |            |        | 256-bit key |
    +----------+-------+----------+------------+--------+-------------+
    | ECDH-SS  | TBD12 | KMAC-128 | yes        | A128KW | ECDH SS w/  |
    | +        |       |          |            |        | KMAC-128    |
    | KMAC-128 |       |          |            |        | and AES Key |
    | + A128KW |       |          |            |        | Wrap w/     |
    |          |       |          |            |        | 128-bit key |
    +----------+-------+----------+------------+--------+-------------+
    | ECDH-SS  | TBD13 | KMAC-256 | yes        | A256KW | ECDH SS w/  |
    | +        |       |          |            |        | KMAC-256    |
    | KMAC-256 |       |          |            |        | and AES Key |
    | + A256KW |       |          |            |        | Wrap w/     |
    |          |       |          |            |        | 256-bit key |
    +----------+-------+----------+------------+--------+-------------+

                Table 6: ECDH Algorithm Values with Key Wrap

   When using a COSE key for this algorithm, the following checks are
   made:

   *  The 'kty' field MUST be present, and it MUST be 'EC2' or 'OKP'.

   *  If the 'alg' field is present, it MUST match the key agreement
      algorithm being used.

   *  If the 'key_ops' field is present, it MUST include 'derive key' or
      'derive bits' for the private key.

   *  If the 'key_ops' field is present, it MUST be empty for the public
      key.







Schaad                  Expires 23 November 2020               [Page 11]


Internet-Draft               COSE Algorithms                    May 2020


7.  Security Considerations

   Decide on this - TBD

8.  IANA Considerations

8.1.  Changes to the Algorithm Table

   IANA is requested to add new items to the "COSE Algorithms" registry.
   The content to be added can be found in Table 2.  For all items to be
   added, the Reference column should be set to this document.

9.  References

9.1.  Normative References

   [I-D.ietf-cose-rfc8152bis-struct]
              Schaad, J., "CBOR Object Signing and Encryption (COSE):
              Structures and Process", Work in Progress, Internet-Draft,
              draft-ietf-cose-rfc8152bis-struct-08, 9 March 2020,
              <https://tools.ietf.org/html/draft-ietf-cose-rfc8152bis-
              struct-08>.

   [I-D.ietf-cose-rfc8152bis-algs]
              Schaad, J., "CBOR Object Signing and Encryption (COSE):
              Initial Algorithms", Work in Progress, Internet-Draft,
              draft-ietf-cose-rfc8152bis-algs-07, 9 March 2020,
              <https://tools.ietf.org/html/draft-ietf-cose-rfc8152bis-
              algs-07>.

   [I-D.ietf-cbor-7049bis]
              Bormann, C. and P. Hoffman, "Concise Binary Object
              Representation (CBOR)", Work in Progress, Internet-Draft,
              draft-ietf-cbor-7049bis-13, 8 March 2020,
              <https://tools.ietf.org/html/draft-ietf-cbor-7049bis-13>.

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              DOI 10.17487/RFC2104, February 1997,
              <https://www.rfc-editor.org/info/rfc2104>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.






Schaad                  Expires 23 November 2020               [Page 12]


Internet-Draft               COSE Algorithms                    May 2020


   [RFC4231]  Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA-
              224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512",
              RFC 4231, DOI 10.17487/RFC4231, December 2005,
              <https://www.rfc-editor.org/info/rfc4231>.

   [HKDF]     Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
              Key Derivation Function (HKDF)", RFC 5869,
              DOI 10.17487/RFC5869, May 2010,
              <https://www.rfc-editor.org/info/rfc5869>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC5649]  Housley, R. and M. Dworkin, "Advanced Encryption Standard
              (AES) Key Wrap with Padding Algorithm", RFC 5649,
              DOI 10.17487/RFC5649, September 2009,
              <https://www.rfc-editor.org/info/rfc5649>.

   [RFC3394]  Schaad, J. and R. Housley, "Advanced Encryption Standard
              (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394,
              September 2002, <https://www.rfc-editor.org/info/rfc3394>.

   [NIST-800-185]
              Kelsey, J., Change, S., and R. Perlner, "SHA-3 Derived
              Functions: cSHAKE, KMAC, TupleHash, ParallelHash",
              December 2016,
              <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
              NIST.SP.800-185.pdf>.

   [NIST-800-56C]
              Barker, E., Chen, L., and R. Davis, "Recommendation for
              Key-Derivation Methods in Key-Establishment Schemes"",
              March 2020,
              <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
              NIST.SP.800-56Cr2-draft.pdf>.

Author's Address

   Jim Schaad
   August Cellars

   Email: ietf@augustcellars.com








Schaad                  Expires 23 November 2020               [Page 13]