w3c-ccg / multihash

An IETF Internet Draft for the Multihash data format

The Multihash Data Format

This specification describes a data model for expressing the output of cryptographic hash functions.

Cryptographic hash functions often have multiple output sizes and encodings. This variability makes it difficult for applications to examine a series of bytes and determine which hash function produced them. Multihash is a universal data format for encoding outputs from hash functions. It is useful to write applications that can simultaneously support different hash function outputs as well as upgrade their use of hashes over time; Multihash is intended to address these needs.

You can view an HTML version of the specification here:

https://w3c-ccg.github.io/multihash/

We encourage contributions meeting the Contribution Guidelines. While we prefer the creation of issues and Pull Requests in the GitHub repository, discussions often occur on the public-credentials mailing list as well.

Other useful links

• Multiformats Website
• Multihash Website
• Public group email archive

multihash's Issues

Add digest-algorithm iana considerations

I wish: IANA considerations for adding algorithm to digest-algorithms IANA table

Extra "of" in "maximum length of of nine bytes"

This is found in page 4, 3 lines down from "Table 1".

Replace "intecates" with "indicates" on page 4

In page 4 is the following phrase: "The most significant bit in each output byte intecates". I think the last word in the quoted phrase should be "indicates".

registry is underspecified

See RFC 8126 quick overview and its details. In particular:

• field "Codec" should better be named "algorithm" or "hash function type", or the name "codec" should also be used elsewhere in the document. It should be stated that its values consist of lowercase letters a-z, 0-9, and - only
• field "Identifier (hex)" should be named "value" and make clear that its value is given as hexadecimal value. Is the prefix 0x relevant? uppercase or lowercase?
• meaning of field "Status" is not defined

Have you considered using CBOR?

A CBOR equivalent of the SHA-256 hash might be

# tag (279;"SHA-256 hash") , byte array(32), data
0xd90117 5820  41dd7b6443542e75701aa98a0c235951a28a0d851b11564d20022ab11d2589a8

While this uses three more bytes than the example given in the document, it has the advantage of not requiring some additional parser and being usable directly in a CBOR document without additional bytes for framing as a byte array or tagging as a multihash.

multibase is not defined

Section "D.2. The 'mh' Digest Algorithm" refers to a "multibase-serialized value of a multihash-supported algorithm". I understand the intent, but the potential new readers of the RFC may not be familiar with multibase, as it is not defined or referenced elsewhere in the document. Could this pose an issue?

URL to github.io page is broken

Currently, it still points to dcvg, which 404s out. Trying the obvious fix didn't. I did get an xml page, but it doesn't render.

multihash: URI scheme

Initially raised in this thread:

https://lists.w3.org/Archives/Public/public-credentials/2022Aug/0025.html

I wonder if there would be value in a multihash: URI scheme

I'm just checking what it would look like. I would assume multihash:// rather than mh:// which seems not as descriptive

Reason for raising this is that I'd like to test an implementation. And if we can loosely agree on what a scheme might look like, it would help with future proofing.

Appreciate the authors are busy with other things, so I'll start implementing on the assumption that there's no objection to multihash://. However if you had a moment to reply or thumbs up (or down!) this comment, that would be helpful.