RFC 9054

CBOR Object Signing and Encryption (COSE): Hash Algorithms

📅 published August 2022, from ietf

RFC 9054 🦋 CBOR Object Signing and Encryption (COSE): Hash Algorithms ✨

okay bestie, this is RFC 9054 💖 It's by J. Schaad from August Cellars, dated August 2022, and it's Informational (so it's published for info, not as a Standards Track spec). The ISSN is 2070-1721. The header doesn't list anything it obsoletes or updates, so it's a fresh one 🌸

Abstract

COSE (the CBOR Object Signing and Encryption syntax, see RFC 9052) doesn't define any direct methods for using hash algorithms 💅 But there are times when hash algorithms show up anyway, like indirect signatures, where the hash of one or more contents gets signed, and identifying an X.509 certificate or another object with a fingerprint. This document defines hash algorithms that are identified by COSE algorithm identifiers ✨

Status of This Memo

This document is not an Internet Standards Track specification; it is published for informational purposes.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9054.

Copyright (c) 2022 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

Table of Contents

1.  Introduction
  1.1.  Requirements Terminology
2.  Hash Algorithm Usage
  2.1.  Example CBOR Hash Structure
3.  Hash Algorithm Identifiers
  3.1.  SHA-1 Hash Algorithm
  3.2.  SHA-2 Hash Algorithms
  3.3.  SHAKE Algorithms
4.  IANA Considerations
  4.1.  COSE Algorithm Registry
5.  Security Considerations
6.  References
  6.1.  Normative References
  6.2.  Informative References
Author's Address

1. Introduction ✨

So COSE [RFC9052] doesn't come with any direct hash-algorithm methods 💅 It also doesn't define a structure for encoding a digested object, the kind of thing the DigestedData ASN.1 structure in [CMS] does. And that was on purpose! A structure that's just a digest identifier, the content, and a digest value doesn't give you any strong security service by itself. Plus, an application is going to be better off defining its own structure, so it can carry any extra data that needs hashing, along with ways of getting that data 🧚

Okay but also, there are definitely times when having some standard hash algorithms defined for COSE with a common identifier makes so much sense 🫶 Two of the big use cases are:

  • Indirect signing of content, and
  • Object identification.

Indirect signing is the vibe where the content itself doesn't get signed. Instead, you compute a hash of the content, and that hash value (along with an identifier for the hash algorithm) goes into the content that actually gets signed. This means you can validate a signature without downloading all of the content first 🔥 The signature can be checked against all of the hash values and pointers to the associated contents. Then you download those parts, compute the hash of each one, and compare it to the hash value in the signed content. This is even more important in a constrained environment, since the device might not need all of the content that's signed. An example of how this is used can be found in Section 5.4 of [SUIT-MANIFEST].

Using hashes to identify objects has been super common. One of the main things a hash function identifies in a secure message is a certificate. Two examples of this can be found in [ESS] and the COSE equivalents in [COSE-x509] 🌈

1.1. Requirements Terminology

Here's the key-word bit 🎀

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.

2. Hash Algorithm Usage 🌸

Like we said in the last section, hash functions are super versatile. Some uses need a hash function to be cryptographically strong. Those include direct and indirect signatures, which means using the hash as part of the signature, or using the hash as part of the body that gets signed. Other uses of hash functions might not need the same level of strength.

This document contains some hash functions that are not designed to be used for cryptographic operations. An application that uses a hash function needs to carefully evaluate exactly which hash properties it needs, and which hash functions are going to provide them. Applications should also make sure that being able to change hash functions is part of the base design, because cryptographic advances are sure to reduce the strength of any given hash function [BCP201] 💀

A hash function is a map from one, normally large, bit string to a second, usually smaller, bit string. Since the number of possible input values is way bigger than the number of possible output values, collisions are inevitable 🙈 The trick is making sure it's really hard to find two values that map to the same output value. A "Collision Attack" is when an attacker can find two different messages with the same hash value. A hash function that is susceptible to practical collision attacks SHOULD NOT be used for a cryptographic purpose. If theoretical collision attacks are discovered against a given hash function, that SHOULD trigger protocol maintainers and users to review whether the algorithm is still suitable, if alternatives are available and migration is viable. The only reason to use such a hash function is when there is absolutely no other choice (e.g., a Hardware Security Module (HSM) that cannot be replaced), and only after looking closely at the possible security issues. Cryptographic purposes include creating signatures or using hashes for indirect signatures. These functions may still be usable for noncryptographic purposes 🔥

Heads up: a hash function that falls to practical collision attacks SHOULD NOT be used for anything cryptographic. Only use one in the rare no-other-choice situation, and only after checking the security issues.

An example of a noncryptographic use of a hash is filtering a collection of values to find a set of possible candidates. Then the candidates can be checked to see whether they can successfully be used. A simple example is the classic fingerprint of a certificate. If the fingerprint is used to verify that it's the correct certificate, then that usage is cryptographic and is subject to the warning above about collision attacks. But if the fingerprint is used to sort through a collection of certificates to find ones that might be used to verify a signature, a simple filter is enough. In that case, you still need to confirm that the public key validates the signature (and that the certificate is trusted), and any certificates whose key doesn't validate the signature can be discarded as false positives 👑

To tell these two cases apart, a new value in the Recommended column of the "COSE Algorithms" registry has been added. "Filter Only" indicates that the only purpose of a hash function should be to filter results; it is not intended for applications that require a cryptographically strong algorithm 🦋

2.1. Example CBOR Hash Structure

[COSE] didn't provide a default structure for holding a hash value, both because no separate hash algorithms were defined and because the way the structure is set up is frequently application specific. There are four fields that often get included in a hash structure:

  • The hash algorithm identifier.
  • The hash value.
  • A pointer to the value that was hashed. This could be a pointer to a file, an object that can be obtained from the network, a pointer to someplace in the message, or something very application specific.
  • Additional data. This can be as simple as a random value (i.e., salt) to make finding hash collisions slightly harder (because the payload handed to the application could have been selected to have a collision), or as complicated as a set of processing instructions used with the object that is pointed to. The additional data can be handled in a number of ways, such as prepending or appending it to the content, but it is strongly suggested that either it be a fixed known size, or the lengths of the pieces being hashed be included so that the resulting byte string has a unique interpretation as the additional data. (Encoding as a CBOR array accomplishes this requirement.) 🍓

An example of a structure that lets all of the above fields exist looks like this 🧁

COSE_Hash_V = (
    1 : int / tstr, # Algorithm identifier
    2 : bstr, # Hash value
    ? 3 : tstr, # Location of object that was hashed
    ? 4 : any   # object containing other details and things
    )

Below is an alternative structure for when you're searching a group of objects for a matching hash value. In that case, the location isn't needed, and adding extra data to the hash would be counterproductive. So the structure looks like this 💜

COSE_Hash_Find = [
    hashAlg : int / tstr,
    hashValue : bstr
]

3. Hash Algorithm Identifiers ✨

3.1. SHA-1 Hash Algorithm 🦋

okay so SHA-1 has a whole story 😭. It was designed by the United States National Security Agency and published in 1995 [RFC3174]. Since then, people have poked at it SO much, and a successful collision attack now exists [SHA-1-collision]. The IETF officially started discouraging SHA-1 in [RFC6194] 💀.

Despite all that drama, SHA-1 still shows up in real life, so it makes sense to give it a code point anyway 🫶. Some situations involve historic HSMs where SHA-1 is the only thing implemented. In other cases, the SHA-1 value is used for filtering, so collision resistance isn't needed there 🌸.

Because of the known issues with SHA-1, and because it should no longer be used, this algorithm gets registered with the recommendation of "Filter Only" 🎀. That gives guidance on when it's safe to use, while discouraging people from using it where it isn't safe. Very responsible, very iconic ✨.

The COSE capabilities for this algorithm is an empty array.

+=====+======+=============+==============+===========+=============+
|Name |Value | Description | Capabilities | Reference | Recommended |
+=====+======+=============+==============+===========+=============+
|SHA-1|-14   | SHA-1 Hash  | []           | RFC 9054  | Filter Only |
+-----+------+-------------+--------------+-----------+-------------+

                    Table 1: SHA-1 Hash Algorithm

3.2. SHA-2 Hash Algorithms 💖

The SHA-2 family [FIPS-180-4] was also designed by the NSA, and it was published in 2001 🌈. Over time, some extra algorithms were added to the original set to deal with length-extension attacks and some performance issues 🔥. SHA-3 has been published since then, but SHA-2 is still everywhere, so it's definitely not going anywhere 👑.

There are a bunch of different parameters for the SHA-2 hash functions. The set chosen for this document is based on those parameters and the trade-offs that come with them 🧚.

  • SHA-256/64 is a truncated hash 🍓. The truncation is designed to allow for a smaller transmission size, but the trade-off is that the odds of a collision go up proportionally. Using this hash function requires analysis of the potential problems a collision could cause, or it has to be limited to cases where the purpose of the hash is noncryptographic 🙈.

The second option is the case for some scenarios in [COSE-x509], specifically when the hash value is used to pick among possible certificates. If there are multiple choices left, each choice can be tested by using the public key 🔍.

  • SHA-256 is probably the most common hash function in use right now 💅. It's an efficient hash algorithm for 32-bit hardware ⭐.
  • SHA-384 and SHA-512 hash functions are efficient for 64-bit hardware 💜.
  • SHA-512/256 runs more efficiently on 64-bit hardware but offers the same security level as SHA-256 🦋.
NOTE: SHA-256/64 is a simple truncation of SHA-256 to 64 bits, defined in this specification. SHA-512/256 is a modified variant of SHA-512 truncated to 256 bits, as defined in [FIPS-180-4].

The COSE capabilities array for these algorithms is empty.

+===========+=====+===========+==============+=========+============+
|Name       |Value|Description| Capabilities |Reference|Recommended |
+===========+=====+===========+==============+=========+============+
|SHA-256/64 |-15  |SHA-2      | []           |RFC 9054 |Filter Only |
|           |     |256-bit    |              |         |            |
|           |     |Hash       |              |         |            |
|           |     |truncated  |              |         |            |
|           |     |to 64-bits |              |         |            |
+-----------+-----+-----------+--------------+---------+------------+
|SHA-256    |-16  |SHA-2      | []           |RFC 9054 |Yes         |
|           |     |256-bit    |              |         |            |
|           |     |Hash       |              |         |            |
+-----------+-----+-----------+--------------+---------+------------+
|SHA-384    |-43  |SHA-2      | []           |RFC 9054 |Yes         |
|           |     |384-bit    |              |         |            |
|           |     |Hash       |              |         |            |
+-----------+-----+-----------+--------------+---------+------------+
|SHA-512    |-44  |SHA-2      | []           |RFC 9054 |Yes         |
|           |     |512-bit    |              |         |            |
|           |     |Hash       |              |         |            |
+-----------+-----+-----------+--------------+---------+------------+
|SHA-512/256|-17  |SHA-2      | []           |RFC 9054 |Yes         |
|           |     |512-bit    |              |         |            |
|           |     |Hash       |              |         |            |
|           |     |truncated  |              |         |            |
|           |     |to 256-bits|              |         |            |
+-----------+-----+-----------+--------------+---------+------------+

                    Table 2: SHA-2 Hash Algorithms

3.3. SHAKE Algorithms 🧚‍♀️

The SHA-3 family [FIPS-202] came out of a competition run by NIST 🏆. The pair known as SHAKE-128 and SHAKE-256 are the SHA-3 instances currently being standardized in the IETF, and that's the whole reason they're included in this document 🫶.

SHA-3 is structured very differently from SHA-2, so it's basically a different vibe 🌸.

Unlike the SHA-2 hash functions, no algorithm identifier is created for shorter lengths. The stored hash value is 256 bits for SHAKE-128 and 512 bits for SHAKE-256 ✨.

The COSE capabilities array for these algorithms is empty.

+========+=====+=============+==============+=========+=============+
|Name    |Value|Description  | Capabilities |Reference| Recommended |
+========+=====+=============+==============+=========+=============+
|SHAKE128|-18  |SHAKE-128    | []           |RFC 9054 | Yes         |
|        |     |256-bit Hash |              |         |             |
|        |     |Value        |              |         |             |
+--------+-----+-------------+--------------+---------+-------------+
|SHAKE256|-45  |SHAKE-256    | []           |RFC 9054 | Yes         |
|        |     |512-bit Hash |              |         |             |
|        |     |Value        |              |         |             |
+--------+-----+-------------+--------------+---------+-------------+

                    Table 3: SHAKE Hash Functions

4. IANA Considerations 📋

4.1. COSE Algorithm Registry 💅

IANA has registered the following algorithms in the "COSE Algorithms" registry (https://www.iana.org/assignments/cose/) 🌈.

  • The SHA-1 hash function found in Table 1.
  • The set of SHA-2 hash functions found in Table 2.
  • The set of SHAKE hash functions found in Table 3.

Lots of the hash values produced are pretty long, so using a two-byte algorithm identifier seems reasonable 🙌. SHA-1 is tagged as "Filter Only", so a longer algorithm identifier is appropriate even though its hash value is shorter 🤔.

IANA has added "Filter Only" to the set of legal values for the Recommended column 🎀. This value is only to be used for hash functions, and it indicates that the hash isn't to be used for purposes that require collision resistance 🚫. Because of this addition, IANA has added this document as a reference for the "COSE Algorithms" registry 🦋.

5. Security Considerations 🚨

Okay, this section is SERIOUS, bestie 😭🔐. Protocols need to do a careful analysis of which properties of a hash function they actually need, and how those properties map onto possible attacks 🕵️‍♀️. You have to tell apart the uses that need cryptographic properties, like collision resistance, from the uses that only need properties tied to object identification 🧩.

The different attacks depend on who or what is being protected. Is the originator the attacker, or is it a third party? That's the difference between collision resistance and second pre-image resistance 👀. As a general rule, longer hash values are "better" than short ones, but trade-offs involving transmission size, timeliness, and security all need to be part of this analysis ⏳. In many cases the value being hashed is public, so (first) pre-image resistance isn't part of the analysis 🌸.

Algorithm agility needs to be considered a requirement for any use of hash functions [BCP201] 🔁. As with any cryptographic function, hash functions are under constant attack, and the cryptographic strength of hash algorithms will be reduced over time 💀🔥. Plan accordingly, besties!

6. References 📚

6.1. Normative References 💜

[FIPS-180-4]
           NIST, "Secure Hash Standard", FIPS PUB 180-4,
           DOI 10.6028/NIST.FIPS.180-4, August 2015,
           <https://doi.org/10.6028/NIST.FIPS.180-4>.

[FIPS-202] Dworkin, M.J., "SHA-3 Standard: Permutation-Based Hash and
           Extendable-Output Functions", FIPS PUB 202,
           DOI 10.6028/NIST.FIPS.202, August 2015,
           <https://doi.org/10.6028/NIST.FIPS.202>.

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

[RFC3174]  Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1
           (SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001,
           <https://www.rfc-editor.org/info/rfc3174>.

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

[RFC9052]  Schaad, J., "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>.

6.2. Informative References 📚✨

Okay bestie, this is the bonus reading list 🤓 Every one of these is a cute little rabbit hole if you want more context.

Author's Address 🦋💖

Jim Schaad August Cellars

📦 where this page comes from