Use multiformat to represent hash and public key (and signature?) values

[vdods]

Multiformat has an extensive list of data types and encodings, which would allow compact representation of relevant cryptographic primitives. This is a reasonably widely used format (e.g. in IPFS for hash-valued content identifiers), and is reasonably well-defined, and is extensible.

Use multiformat instead of KERIHash and KERIVerifier, since the latter two are more limited in the kinds of hashes and key types they can represent.

Question: Does multiformat specify formats for cryptographic signatures? E.g. ed25519-sha-512, secp256k1-sha-256, etc? multicodec? I'm not finding an obvious listing.

[vdods]

Followup notes:

• https://crates.io/crates/multibase - popular Rust crate supporting multibase
• https://crates.io/crates/multihash - popular Rust crate supporting multihash
• https://github.com/cryptidtech/multisig and https://github.com/cryptidtech/multikey seem to be the only Rust implementations of multisig and multikey.

Other considerations for use of multiformat:

• How widely are the various components (multibase, multihash, multikey, multisig) supported in other programming languages? I.e. how difficult would it be to create a did:webplus implementation (even just the DID resolution portion) in a given target language, if multiformats were used?

[bumblefudge]

Oh, sorry, I seemed to have "watched" this repo after the initial issue was opened and only just saw this with today's followup.

Background

Multiformats is pretty easy to implement a tiny subset of in different languages-- there ARE libraries in every major language that implement some chunky subset of the multicodec table, although in some languages the various subsets like multihash and multiaddr are implemented separately (with different processing steps and ergonomic/efficiency tradeoffs appropriately).

multibase and multikey are two special cases-- multibasing is an optional step (and technically is NOT a "subregistry" of multicodecs in the IANA sense of registries and subregistries). In most languages/IPFS contexts, the multibase library is broken out from the multiformats/multiaddr/multihash library, and not exported where it isn't used. think of it as a transport-layer convenience, where ASCII is needed; everywhere binary formats and streams are fine, it's not used. since a few years before CIDv1, it's been the case in practice (and only recently in the official specs) that CIDs are officially a binary format, with multibase a recommended (but optional) transformation for contexts like the HTTP where ASCII makes more sense.

multikey is a special case for the simple reason that it was never structural in IFPS (due to IPNS and other ways of representing keys) so it was never really spec'd out. the W3C CCG and DID WG specs use publicKeyMultibase which is not really specified in multiformats or used in IPFS.

the cryptidtech implementations are intended as a general-purpose crates, but I haven't reviewed them in detail. i CAN say that cryptidtech is intimately aware of the KERI approach and I think it dave huseby would be more than happy to walk you through any nits or cornercases of expressing KERI signature formats or canonicalization through those crates. I don't know if parity with KERI is a goal of those libraries specifically but the use-cases of webplus and keri are familiar to their designer so it wouldn't take him/them very long to answer well-formulated questions.

i trust them to be loyal to the spec and work for all the test vectors in the multiformats repos, but admittedly the conformance regimen for all this is... those test vectors. mostly corner cases that arise in IPFS get filtered up to multiformats eventually, but multikey doesn't have that implementation history so i'm not as confident we've found all the corner-cases yet. presumably if a multiformats WG forms at IETF there would be that feedback loop for any multi- libraries/microprotocols that members of the WG volunteer to implement and cross-test.

Concrete next steps

how difficult would it be to create a did:webplus implementation (even just the DID resolution portion) in a given target language, if multiformats were used?

not very hard, I think-- there is implementation history across many languages on the multihash and CID side of things, so the core mechanisms are pretty language-agnostic and mature at this point. the harder part is just the universal quirks of representing keys and signatures, which doesn't necessarily go away if you use some other toolchain or family of formats from, e.g. CBOR or JW* traditions.

[bumblefudge]

Does multiformat specify formats for cryptographic signatures? E.g. ed25519-sha-512, secp256k1-sha-256, etc? multicodec? I'm not finding an obvious listing.

this is... an ongoing debate among implementers. some companies got together and proposed defining together a dictionary of IPLD-formatted (i.e. multiformats-encoded) signatures, but that project is still unstable and on hold at the moment, because those use-cases are mostly downstream of the UCAN project that is also at a bit of a breaking-change juncture. I can point you towards libraries that mostly conform to it... but it's probably not helpful in the sense that you probably want to build webplus on a definitive v1 spec with test vectors :D

you could just use cryptidtech's multisig, or one of the varsig variants, or do your own thing, but note that any of these might change under you as well, as multisig hasn't had as much multi-stakeholder refinement as the other multis. sad but true!