- From: Bryan Newbold <bryan@blueskyweb.xyz>
- Date: Wed, 19 Feb 2025 17:59:37 -0800
- To: Manu Sporny <msporny@digitalbazaar.com>
- Cc: Will Abramson <wip.abramson@gmail.com>, Credentials Community Group <public-credentials@w3.org>, rgrant@rgrant.org
On Wed, Feb 19, 2025 at 12:16 PM Manu Sporny <msporny@digitalbazaar.com> wrote: > > On Wed, Feb 19, 2025 at 10:07 AM Will Abramson <wip.abramson@gmail.com> wrote: > > Is a draft of a Cryptosuite for producing Data Integrity proofs using Schnorr signatures with Secp256k1 keys according to the latest proposed recommendations from the VCDM. > > That's awesome, Will! It'll be nice to standardize a non-ECDSA / > Schnorr signature scheme. This all sounds good, and I'm supportive of this Schnorr Secp256k1 draft! Just to side-note for awareness, we use secp256k1 (along with secp256r1), with ECDSA, in both atproto and DID PLC. We use Multikey encoding for public keys. We do not restrict to "x-only" keys. For secp256k1 we use the 0xE7 code ([0xE7, 0x01] as a varint) in the Multikey encoding. We don't currently encode proofs (signatures) in DataIntegrityProof format anywhere in those systems. The signature/proof in DataIntegrityProof format in this proposed draft (data-integrity-schnorr-secp256k1) differentiates the signature type, so I don't think there would be room for confusion in the wild. > > One aspect of the spec that is worth drawing attention to is our definition of the secp256k1 x-only Multikey prefix - https://dcdpr.github.io/data-integrity-schnorr-secp256k1/#multikey. Should this be registered somewhere else? From the CID spec, it states anyone can define their own Multikey prefix so I figured this would be okay. But clearly we wouldn't want other keys to also use the same value > > Yes, the spec can define its own Multikey prefix, and my hope is that > we split the Multiformats stuff out of the CID spec eventually. I'll > note that the secp256k1 pubkey value is 0xe7 (don't know what the > varint encoding is off of the top of my head): > > https://github.com/multiformats/multicodec/blob/master/table.csv#L93 > > ... so you'll want to use that instead of the one you have in the spec, IIUC. I'm not an expert in this area, but if the fact that the keys are "x-only" is meaningful, it might be good to use a distinct prefix? I think you can submit a PR against the repository Manu linked to (github.com/multiformats/multicodec), to register it there. Though I don't think that is currently part of any formal or recognized SDO process. --bryan
Received on Thursday, 20 February 2025 01:59:52 UTC