• Extracted the sections dealing with specific algorithms and placed them into this document. The sections dealing with structure and general processing rules are placed in [RFC 9052].
• Made text clarifications and changes in terminology.
• Removed all of the details relating to countersignatures and placed them in [COUNTERSIGN].

Byte:

A synonym for octet.

Constrained Application Protocol (CoAP):

A specialized web transfer protocol for use in constrained systems. It is defined in [RFC 7252].

Encryption algorithms that provide an authentication check of the contents along with the encryption service. An example of an AE algorithm used in COSE is AES Key Wrap [RFC 3394]. These algorithms are used for key encryption, but Authenticated Encryption with Associated Data (AEAD) algorithms would be preferred.

Encryption algorithms that provide the same authentication service of the content as AE algorithms do, and also allow associated data that is not part of the encrypted body to be included in the authentication service. An example of an AEAD algorithm used in COSE is AES-GCM [RFC 5116]. These algorithms are used for content encryption and can be used for key encryption as well.

• A name for the algorithm for use in documents.
• The value used on the wire for the algorithm. One place this is used is the algorithm header parameter of a message.
• A short description so that the algorithm can be easily identified when scanning the IANA registry.

• The "kty" field MUST be present, and it MUST be "EC2".
• If the "alg" field is present, it MUST match the ECDSA signature algorithm being used.
• If the "key_ops" field is present, it MUST include "sign" when creating an ECDSA signature.
• If the "key_ops" field is present, it MUST include "verify" when verifying an ECDSA signature.

• Changing the curve used to validate the signature: If one changes the curve used to validate the signature, then potentially one could have two messages with the same signature, each computed under a different curve. The only requirements on the new curve are that its order be the same as the old one and that it be acceptable to the client. An example would be to change from using the curve secp256r1 (aka P-256) to using secp256k1. (Both are 256-bit curves.) We currently do not have any way to deal with this version of the attack except to restrict the overall set of curves that can be used.
• Changing the hash function used to validate the signature: If one either has two different hash functions of the same length or can truncate a hash function, then one could potentially find collisions between the hash functions rather than within a single hash function. For example, truncating SHA-512 to 256 bits might collide with a SHA-256 bit hash value. As the hash algorithm is part of the signature algorithm identifier, this attack is mitigated by including a signature algorithm identifier in the protected-header bucket.

• The "kty" field MUST be present, and it MUST be "OKP" (Octet Key Pair).
• The "crv" field MUST be present, and it MUST be a curve defined for this signature algorithm.
• If the "alg" field is present, it MUST match "EdDSA".
• If the "key_ops" field is present, it MUST include "sign" when creating an EdDSA signature.
• If the "key_ops" field is present, it MUST include "verify" when verifying an EdDSA signature.

• The "kty" field MUST be present, and it MUST be "Symmetric".
• If the "alg" field is present, it MUST match the HMAC algorithm being used.
• If the "key_ops" field is present, it MUST include "MAC create" when creating an HMAC authentication tag.
• If the "key_ops" field is present, it MUST include "MAC verify" when verifying an HMAC authentication tag.

• The "kty" field MUST be present, and it MUST be "Symmetric".
• If the "alg" field is present, it MUST match the AES-MAC algorithm being used.
• If the "key_ops" field is present, it MUST include "MAC create" when creating an AES-MAC authentication tag.
• If the "key_ops" field is present, it MUST include "MAC verify" when verifying an AES-MAC authentication tag.

• A single key must only be used for messages of a fixed or known length. If this is not the case, an attacker will be able to generate a message with a valid tag given two message and tag pairs. This can be addressed by using different keys for messages of different lengths. The current structure mitigates this problem, as a specific encoding structure that includes lengths is built and signed. (CMAC also addresses this issue.)
• In Cipher Block Chaining (CBC) mode, if the same key is used for both encryption and authentication operations, an attacker can produce messages with a valid authentication code.
• If the IV can be modified, then messages can be forged. This is addressed by fixing the IV to all zeros.

• The "kty" field MUST be present, and it MUST be "Symmetric".
• If the "alg" field is present, it MUST match the AES-GCM 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.

• The key and nonce pair MUST be unique for every message encrypted.
• The total number of messages encrypted for a single key MUST NOT exceed 2³² [SP800-38D]. An explicit check is required only in environments where it is expected that this limit might be exceeded.
• [RFC 8446] contains an analysis on the use of AES-CGM for its environment. Based on that recommendation, one should restrict the number of messages encrypted to 2^24.5.
• A more recent analysis in [ROBUST] indicates that the number of failed decryptions needs to be taken into account as part of determining when a key rollover is to be done. Following the recommendation in DTLS (Section 4.5.3 of RFC 9147), the number of failed message decryptions should be limited to 2³⁶.

16 bits (2):

This limits messages to 2¹⁶ bytes (64 KiB) in length. This is sufficiently long for messages in the constrained world. The nonce length is 13 bytes allowing for 2¹⁰⁴ possible values of the nonce without repeating.

64 bits (8):

This limits messages to 2⁶⁴ bytes in length. The nonce length is 7 bytes, allowing for 2⁵⁶ possible values of the nonce without repeating.

64 bits (8):

This produces a 64-bit authentication tag. This implies that there is a 1 in 2⁶⁴ chance that a modified message will authenticate.

128 bits (16):

This produces a 128-bit authentication tag. This implies that there is a 1 in 2¹²⁸ chance that a modified message will authenticate.

• The "kty" field MUST be present, and it MUST be "Symmetric".
• If the "alg" field is present, it MUST match the AES-CCM 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.

• The key and nonce pair MUST be unique for every message encrypted. Note that the value of L influences the number of unique nonces.
• The total number of times the AES block cipher is used MUST NOT exceed 2⁶¹ operations. This limit is the sum of times the block cipher is used in computing the MAC value and performing stream encryption operations. An explicit check is required only in environments where it is expected that this limit might be exceeded.
• [RFC 9147] contains an analysis on the use of AES-CCM for its environment. Based on that recommendation, one should restrict the number of messages encrypted to 2²³.
• In addition to the number of messages successfully decrypted, the number of failed decryptions needs to be tracked as well. Following the recommendation in DTLS (Section 4.5.3 of RFC 9147),the number of failed message decryptions should be limited to 2^23.5. If one is using the 64-bit tag, then the limits are significantly smaller if one wants to keep the same integrity limits. A protocol recommending this needs to analyze what level of integrity is acceptable for the smaller tag size. It may be that, to keep the desired level of integrity, one needs to rekey as often as every 2⁷ messages.

• The "kty" field MUST be present, and it MUST be "Symmetric".
• If the "alg" field is present, it MUST match the ChaCha20/Poly1305 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.

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 is used. While [RFC 5869] 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.

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 is used by the KDFs in this document.

PRF:

The underlying pseudorandom function to be used in the HKDF algorithm. The PRF is encoded into the HKDF algorithm selection.

• Fields can be defined by the application. This is commonly used to assign fixed names to parties, but it can be used for other items such as nonces.
• Fields can be defined by usage of the output. Examples of this are the algorithm and key size that are being generated.
• Fields can be defined by parameters from the message. We define a set of header parameters in Table 10 that can be used to carry the values associated with the context structure. Examples of this are identities and nonce values. These header parameters are designed to be placed in the unprotected bucket of the recipient structure; they do not need to be in the protected bucket, since they are already included in the cryptographic computation by virtue of being included in the context structure.

AlgorithmID:

This field indicates the algorithm for which the key material will be used. This normally is either a key wrap algorithm identifier or a content encryption algorithm identifier. The values are from the "COSE Algorithms" registry. This field is required to be present. The field exists in the context information so that a different key is generated for each algorithm even if all of the other context information is the same. In practice, this means if algorithm A is broken and thus finding the key is relatively easy, the key derived for algorithm B will not be the same as the key derived for algorithm A.

PartyUInfo:

This field holds information about PartyU. The PartyUInfo is encoded as a CBOR array. The elements of PartyUInfo are encoded in the order presented below. The elements of the PartyUInfo array are:

identity:

This contains the identity information for PartyU. The identities can be assigned in one of two manners. First, a protocol can assign identities based on roles. For example, the roles of "client" and "server" may be assigned to different entities in the protocol. Each entity would then use the correct label for the data it sends or receives. The second way for a protocol to assign identities is to use a name based on a naming system (i.e., DNS or X.509 names).

We define an algorithm parameter, "PartyU identity", that can be used to carry identity information in the message. However, identity information is often known as part of the protocol and can thus be inferred rather than made explicit. If identity information is carried in the message, applications SHOULD have a way of validating the supplied identity information. The identity information does not need to be specified and is set to nil in that case.

nonce:

This contains a nonce value. The nonce can be either implicit from the protocol or carried as a value in the unprotected header bucket.

We define an algorithm parameter, "PartyU nonce", that can be used to carry this value in the message; however, the nonce value could be determined by the application and its value obtained in a different manner.

This option does not need to be specified; if not needed, it is set to nil.

other:

This contains other information that is defined by the protocol. This option does not need to be specified; if not needed, it is set to nil.

PartyVInfo:

This field holds information about PartyV. The content of the structure is the same as for the PartyUInfo but for PartyV.

SuppPubInfo:

This field contains public information that is mutually known to both parties, and is encoded as a CBOR array.

keyDataLength:

This is set to the number of bits of the desired output value. This practice means if algorithm A can use two different key lengths, the key derived for the longer key size will not contain the key for the shorter key size as a prefix.

protected:

This field contains the protected parameter field. If there are no elements in the "protected" field, then use a zero-length bstr.

other:

This field is for free-form data defined by the application. For example, an application could define two different byte strings to be placed here to generate different keys for a data stream versus a control stream. This field is optional and will only be present if the application defines a structure for this information. Applications that define this SHOULD use CBOR to encode the data so that types and lengths are correctly included.

SuppPrivInfo:

This field contains private information that is mutually known private information. An example of this information would be a pre-existing shared secret. (This could, for example, be used in combination with an ECDH key agreement to provide a secondary proof of identity.) The field is optional and will only be present if the application defines a structure for this information. Applications that define this SHOULD use CBOR to encode the data so that types and lengths are correctly included.

PartyInfo = (
    identity : bstr / nil,
    nonce : bstr / int / nil,
    other : bstr / nil
)

COSE_KDF_Context = [
    AlgorithmID : int / tstr,
    PartyUInfo : [ PartyInfo ],
    PartyVInfo : [ PartyInfo ],
    SuppPubInfo : [
        keyDataLength : uint,
        protected : empty_or_serialized_map,
        ? other : bstr
    ],
    ? SuppPrivInfo : bstr
]

• These keys need to have some method of being regularly updated over time. All of the content encryption algorithms specified in this document have limits on how many times a key can be used without significant loss of security.
• These keys need to be dedicated to a single algorithm. There have been a number of attacks developed over time when a single key is used for multiple different algorithms. One example of this is the use of a single key for both the CBC encryption mode and the CBC-MAC authentication mode.
• Breaking one message means all messages are broken. If an adversary succeeds in determining the key for a single message, then the key for all messages is also determined.

• 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 "derive key" or "derive bits".

• The "kty" field MUST be present, and it MUST be "Symmetric".
• 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.

Curve Type/Curve:

The curve selected controls not only the size of the shared secret, but the mathematics for computing the shared secret. The curve selected also controls how a point in the curve is represented and what happens for the identity points on the curve. In this specification, we allow for a number of different curves to be used. A set of curves is defined in Table 18.

The math used to obtain the computed secret is based on the curve selected and not on the ECDH algorithm. For this reason, a new algorithm does not need to be defined for each of the curves.

Computed Secret to Shared Secret:

Once the computed secret is known, the resulting value needs to be converted to a byte string to run the KDF. The x-coordinate is used for all of the curves defined in this document. For curves X25519 and X448, the resulting value is used directly, as it is a byte string of a known length. For the P-256, P-384, and P-521 curves, the x-coordinate is run through the Integer-to-Octet-String primitive (I2OSP) function defined in [RFC 8017], using the same computation for n as is defined in Section 2.1.

Ephemeral-Static or Static-Static:

The key agreement process may be done using either a static or an ephemeral key for the sender's side. When using ephemeral keys, the sender MUST generate a new ephemeral key for every key agreement operation. The ephemeral key is placed in the "ephemeral key" parameter and MUST be present for all algorithm identifiers that use ephemeral keys. When using static keys, the sender MUST either generate a new random value or create a unique value for use as a KDF input. For the KDFs used, this means that either the "salt" parameter for HKDF (Table 9) or the "PartyU nonce" parameter for the context structure (Table 10) MUST be present (both can be present if desired). The value in the parameter MUST be unique for the pair of keys being used. It is acceptable to use a global counter that is incremented for every Static-Static operation and use the resulting value. Care must be taken that the counter is saved to permanent storage in a way that avoids reuse of that counter value. When using static keys, the static key should be identified to the recipient. The static key can be identified by providing either the key ("static key") or a key identifier for the static key ("static key id"). Both of these header parameters are defined in Table 15.

Key Derivation Algorithm:

The result of an ECDH key agreement process does not provide a uniformly random secret. As such, it needs to be run through a KDF in order to produce a usable key. Processing the secret through a KDF also allows for the introduction of context material: how the key is going to be used and one-time material for Static-Static key agreement. All of the algorithms defined in this document use one of the HKDF algorithms defined in Section 5.1 with the context structure defined in Section 5.2.

Key Wrap Algorithm:

No key wrap algorithm is used. This is represented in Table 14 as "none". The key size for the context structure is the content layer encryption algorithm size.

• 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.

Key Wrap Algorithm:

Any of the key wrap algorithms defined in Section 6.2 are supported. The size of the key used for the key wrap algorithm is fed into the KDF. The set of identifiers is found in Table 16.

• 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.

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 18. 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 a byte string as defined in [SEC1]. Leading-zero octets MUST be preserved.

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 a byte string (as defined in [SEC1]) and encoded as a CBOR bstr. Leading-zero octets MUST be preserved. 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.

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 18. Other curves may be registered in the future, and private curves can be used as well.

x:

This contains the public key. The byte string contains the public key as defined by the algorithm. (For X25519, internally it is a little-endian integer.)

d:

This contains the private key.

k:

This contains the value of the key.

• OKP, EC2: The list of capabilities is:
  • The key type value. (1 for OKP or 2 for EC2.)
  • One curve for that key type from the "COSE Elliptic Curves" registry.
• RSA: The list of capabilities is:
  • The key type value (3).
• Symmetric: The list of capabilities is:
  • The key type value (4).
• HSS-LMS: The list of capabilities is:
  • The key type value (5).
  • Algorithm identifier for the underlying hash function from the "COSE Algorithms" registry.
• WalnutDSA: The list of capabilities is:
  • The key type value (6).
  • The N value (group and matrix size) for the key, a uint.
  • The q value (finite field order) for the key, a uint.

• Only an algorithm capability: This is useful if the protocol wants to require a specific algorithm, such as ES256, but it is agnostic about which curve is being used. This requires that the algorithm identifier be specified in the protocol. See the first example.
• Only a key type capability: This is useful if the protocol wants to require a specific key type and curve, such as P-256, but will accept any algorithm using that curve (e.g., both ECDSA and ECDH). See the second example.
• Both algorithm and key type capabilities: This is used if the protocol needs to nail down all of the options surrounding an algorithm -- e.g., EdDSA with the curve Ed25519. As with the first example, the algorithm identifier needs to be specified in the protocol. See the third example, which just concatenates the two capabilities together.

Algorithm ES256

0x8102                 / [2 \ EC2 \ ] /

Key type EC2 with P-256 curve:

0x820201               / [2 \ EC2 \, 1 \ P-256 \] /

ECDH-ES + A256KW with an X25519 curve:

0x8101820104           / [1 \ OKP \],[1 \ OKP \, 4 \ X25519 \] /

[
 [-8 / EdDSA /,
   [1 / OKP key type /],
   [
     [1 / OKP /, 6 / Ed25519 / ],
     [1 /OKP/, 7 /Ed448 /]
   ]
 ],
 [-7 / ECDSA with SHA-256/,
   [2 /EC2 key type/],
   [
     [2 /EC2/, 1 /P-256/],
     [2 /EC2/, 3 /P-521/]
   ]
 ],
 [ -31 / ECDH-ES+A256KW/,
   [
     [ 2 /EC2/],
     [1 /OKP/ ]
   ],
   [
     [2 /EC2/, 1 /P-256/],
     [1 /OKP/, 4 / X25519/ ]
   ]
 ],
 [ 1 / A128GCM /,
   [ 4 / Symmetric / ],
   [ 4 / Symmetric /]
 ]
]

• The first element indicates that the entity supports EdDSA with curves Ed25519 and Ed448.
• The second element indicates that the entity supports ECDSA with SHA-256 with curves P-256 and P-521.
• The third element indicates that the entity supports Ephemeral-Static ECDH using AES256 key wrap. The entity can support the P-256 curve with an EC2 key type and the X25519 curve with an OKP key type.
• The last element indicates that the entity supports AES-GCM of 128 bits for content encryption.

• The restriction applies to the encoding of the COSE_KDF_Context.
• Encoding MUST be done using definite lengths, and the length of the (encoded) argument MUST be the minimum possible length. This means that the integer 1 is encoded as "0x01" and not "0x1801".
• 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.

• 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 an existing registration and that the code point is likely to be used in deployments. The ranges tagged as private use are intended for testing purposes and closed environments; code points in other ranges should not be assigned for testing.
• Standards Track or BCP RFCs are required to register a code point in the Standards Action range. Specifications should exist for Specification Required ranges, but early assignment before an RFC is available is considered to be permissible. Specifications are needed for the first-come, first-served range if the points 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.
• Experts should take into account the expected usage of fields when approving code point assignment. The fact that the Standards Action range is only available to 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 and the size of device it will be used on.
• 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 are expected to meet the security requirements of the community and the requirements of the message structures in order to be suitable for registration.

• Use of 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.
• Use of "direct" as a recipient algorithm combined with a second recipient algorithm exposes the direct key to the second recipient; Section 8.5 of RFC 9052 forbids combining "direct" recipient algorithms with other modes.
• 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.

• What are the permissions associated with the key owner?
• Is the cryptographic algorithm acceptable in the current context?
• Have the restrictions associated with the key, such as algorithm or freshness, been checked, and are they correct?
• Is the request something that is reasonable, given the current state of the application?
• Have any security considerations that are part of the message been enforced (as specified by the application or "crit" header parameter)?

[AES-GCM]

M Dworkin, "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC", NIST Special Publication 800-38D, DOI 10.6028/NIST.SP.800-38D, November 2007,
<https://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf>.

[DSS]

National Institute of Standards and Technology, "Digital Signature Standard (DSS)", FIPS PUB 186-4, DOI 10.6028/NIST.FIPS.186-4, July 2013,
<https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf>.

[MAC]

A. Menezes, P. van Oorschot, and S. Vanstone, "Handbook of Applied Cryptography", 1996,
<https://cacr.uwaterloo.ca/hac/>.

[RFC2104]

H. Krawczyk, M. Bellare, 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]

S. Bradner, "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>.

[RFC3394]

J. Schaad, 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>.

[RFC3610]

D. Whiting, R. Housley, and N. Ferguson, "Counter with CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September 2003,
<https://www.rfc-editor.org/info/rfc3610>.

[RFC5869]

H. Krawczyk, 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>.

[RFC6090]

D. McGrew, K. Igoe, and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, DOI 10.17487/RFC6090, February 2011,
<https://www.rfc-editor.org/info/rfc6090>.

[RFC6979]

T. Pornin, "Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 2013,
<https://www.rfc-editor.org/info/rfc6979>.

[RFC7748]

A. Langley, M. Hamburg, and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, January 2016,
<https://www.rfc-editor.org/info/rfc7748>.

[RFC8017]

K. Moriarty, B. Kaliski, J. Jonsson, and A. Rusch, "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, DOI 10.17487/RFC8017, November 2016,
<https://www.rfc-editor.org/info/rfc8017>.

[RFC8032]

S. Josefsson, and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>.

[RFC8174]

B. Leiba, "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>.

[RFC8439]

Y. Nir, and A. Langley, "ChaCha20 and Poly1305 for IETF Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018,
<https://www.rfc-editor.org/info/rfc8439>.

[RFC9052]

J Schaad, "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022,
<https://www.rfc-editor.org/info/rfc9052>.

[SEC1]

Certicom Research, "SEC 1: Elliptic Curve Cryptography", May 2009,
<https://www.secg.org/sec1-v2.pdf>.

[STD94]

C. Bormann, and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, December 2020,
<https://www.rfc-editor.org/info/std94>.

[CFRG-DET-SIGS]

Ericsson, , , and , "Deterministic ECDSA and EdDSA Signatures with Additional Randomness", Internet-Draft draft-mattsson-cfrg-det-sigs-with-noise-04, February 2022,
<https://datatracker.ietf.org/doc/html/draft-mattsson-cfrg-det-sigs-with-noise-04>.

[COUNTERSIGN]

Vigil Security, LLC, , and , "CBOR Object Signing and Encryption (COSE): Countersignatures", Internet-Draft draft-ietf-cose-countersign-08, August 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-cose-countersign-08>.

[GitHub-Examples]

"GitHub Examples of COSE", June 2020,
<https://github.com/cose-wg/Examples>.

[HKDF]

IBM T.J. Watson Research Center, H. Krawczyk, "Cryptographic Extraction and Key Derivation: The HKDF Scheme", 2010,
<https://eprint.iacr.org/2010/264.pdf>.

[OSCORE-GROUPCOMM]

Universitaet Duisburg-Essen, , , , , and , "Group OSCORE - Secure Group Communication for CoAP", Internet-Draft draft-ietf-core-oscore-groupcomm-14, March 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-groupcomm-14>.

[RFC4231]

M. Nystrom, "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>.

[RFC4493]

JH. Song, R. Poovendran, J. Lee, and T. Iwata, "The AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June 2006,
<https://www.rfc-editor.org/info/rfc4493>.

[RFC5116]

D. McGrew, "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
<https://www.rfc-editor.org/info/rfc5116>.

[RFC5480]

S. Turner, D. Brown, K. Yiu, R. Housley, and T. Polk, "Elliptic Curve Cryptography Subject Public Key Information", RFC 5480, DOI 10.17487/RFC5480, March 2009,
<https://www.rfc-editor.org/info/rfc5480>.

[RFC6151]

S. Turner, and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, DOI 10.17487/RFC6151, March 2011,
<https://www.rfc-editor.org/info/rfc6151>.

[RFC7252]

Z. Shelby, K. Hartke, and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>.

[RFC7518]

M. Jones, "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015,
<https://www.rfc-editor.org/info/rfc7518>.

[RFC8126]

M. Cotton, B. Leiba, and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.

[RFC8152]

J. Schaad, "CBOR Object Signing and Encryption (COSE)", RFC 8152, DOI 10.17487/RFC8152, July 2017,
<https://www.rfc-editor.org/info/rfc8152>.

[RFC8230]

M. Jones, "Using RSA Algorithms with CBOR Object Signing and Encryption (COSE) Messages", RFC 8230, DOI 10.17487/RFC8230, September 2017,
<https://www.rfc-editor.org/info/rfc8230>.

[RFC8446]

E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.

[RFC8551]

J. Schaad, B. Ramsdell, and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification", RFC 8551, DOI 10.17487/RFC8551, April 2019,
<https://www.rfc-editor.org/info/rfc8551>.

[RFC8610]

H. Birkholz, C. Vigano, and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019,
<https://www.rfc-editor.org/info/rfc8610>.

[RFC8778]

R. Housley, "Use of the HSS/LMS Hash-Based Signature Algorithm with CBOR Object Signing and Encryption (COSE)", RFC 8778, DOI 10.17487/RFC8778, April 2020,
<https://www.rfc-editor.org/info/rfc8778>.

[RFC9021]

D. Atkins, "Use of the Walnut Digital Signature Algorithm with CBOR Object Signing and Encryption (COSE)", RFC 9021, DOI 10.17487/RFC9021, May 2021,
<https://www.rfc-editor.org/info/rfc9021>.

[RFC9147]

E. Rescorla, H. Tschofenig, and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
<https://www.rfc-editor.org/info/rfc9147>.

[ROBUST]

M. Fischlin, F. Günther, and C. Janson, "Robust Channels: Handling Unreliable Networks in the Record Layers of QUIC and DTLS", Feb 2020,
<https://eprint.iacr.org/2020/718.pdf>.

[SP800-38D]

M. Dworkin, "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC", NIST Special Publication 800-38D, November 2007,
<https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf>.

[SP800-56A]

E. Barker, L. Chen, A. Roginsky, A. Vassilev, and R. Davis, "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography", DOI 10.6028/NIST.SP.800-56Ar3, April 2018,
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar2.pdf>.

[STD90]

T. Bray, "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, December 2017,
<https://www.rfc-editor.org/info/std90>.

Jim Schaad