- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Sun, 3 Aug 2025 16:48:39 -0400
- To: Credentials Community Group <public-credentials@w3.org>
On Sun, Aug 3, 2025 at 3:08 PM Christopher Allen <ChristopherA@lifewithalacrity.com> wrote: > Which brings me to a question that might clarify things: > > In Multikey, does the integrity check (if any) cover the type prefix as well, or only the raw key bytes? There is no integrity check in Multikey, that's at a "lower layer"... it's in the bytes that follow the Multikey header. Multikey allows for proper architectural layering and is agnostic to whether a particular community wants to include an integrity check or not. So, you can have a Multikey header that says: The next X bytes are to be interpreted as a raw FOO_TYPE public key. You could also, simultaneously, have a Multikey header that says: The next X bytes are to be interpreted as a FOO_TYPE public key with Y bytes of trailing CRC. > If it covers the prefix, then the type and encoding are further entangled — meaning any change in type affects both interpretation and the integrity of the encoding. That’s the layering concern I’m trying to highlight. I'm still not quite following... or rather, I can read your statement in a variety of ways depending on your definition of "prefix" (do you mean the Multikey header? or a "raw key" header? or a data integrity header?), "type" (do you mean the semantic type? do you mean the Multikey type? Or do you mean some other type?), "encoding" (do you mean the raw key binary encoding? or the serialization of the key after an integrity check has been applied? or do you mean the final base-encoding?). In an effort to not have to define all those words, here's the structure of a Multikey: [MULTIKEY_HEADER][BYTES] The MULTIKEY_HEADER can express things like the following: * The next 33 BYTES are a raw secp256k1 public key as defined in SEC 1: Elliptic Curve Cryptography. * The next 37 BYTES are a raw secp256k1 public key as as defined in SEC 1: Elliptic Curve Cryptography with a trailing CRC-32 checksum as defined in ISO 802-3 (Ethernet standard) ... and so on. I don't think they're "entangled", as you say, but I'm still not quite sure if we're talking about the same things. Perhaps the above helps clarify the architectural layering? Note that at no point did I mention base-encoding (which is at another layer "above" -- at the Multibase layer). -- manu -- Manu Sporny - https://www.linkedin.com/in/manusporny/ Founder/CEO - Digital Bazaar, Inc. https://www.digitalbazaar.com/
Received on Sunday, 3 August 2025 20:49:19 UTC