Add secp256k to context (did-v0.11.jsonld).

[peacekeeper]

sec:EcdsaSecp256k1Signature2019, sec:SchnorrSecp256k1Signature2019, sec:Secp256k1VerificationKey2018

[peacekeeper]

This is aligned with https://github.com/w3c-ccg/ld-cryptosuite-registry/pull/12, in order to harmonize the use of Secp256k1VerificationKey2018 across all Bitcoin- and Ethereum-based DID methods.

[dlongley]

@peacekeeper,

These changes seem to imply that Secp256k1VerificationKey2018 could be used with more than one signature scheme -- as there are not separate key types being added here for each signature type. If so, that runs against the goal of strongly binding keys to specific signature schemes. Was that intentional and if it was, why?

[peacekeeper]

strongly binding keys to specific signature schemes. Was that intentional and if it was, why?

@dlongley, as both you and @ChristopherA have explained (see https://github.com/w3c-ccg/ld-cryptosuite-registry/pull/4#issuecomment-377651551), the same Secp256k1VerificationKey2018 key can be used for both EcdsaSecp256k1Signature2019 and SchnorrSecp256k1Signature2019.

Are you saying we need two different key types for strong binding? If so, what should they be?

We could also temporarily remove Schnorr and for now only get EcdsaSecp256k1Signature2019 and Secp256k1VerificationKey2018 added into the JSON-LD context?

[dlongley]

@peacekeeper,

@dlongley, as both you and @ChristopherA have explained (see w3c-ccg/ld-cryptosuite-registry#4 (comment)), the same Secp256k1VerificationKey2018 key can be used for both EcdsaSecp256k1Signature2019 and SchnorrSecp256k1Signature2019.

While it's true that the same key can technically be used to create either type of signature, that doesn't mean it's a good idea to do it. I'm not aware of any attacks in so doing -- but it seems like there could be some theoretical collision.

Are you saying we need two different key types for strong binding? If so, what should they be?

Well, I thought that was the general plan -- to be super paranoid about this sort of thing because there aren't that many signature schemes and so minting a new key type for each one isn't that big of a deal. That way there's no feasible chance that an attacker could find a collision and specify a different signature scheme to fake a signature with the same key. This is one reason we have RsaVerificationKey2018 to go along with RsaSignature2018 -- when you could, of course, reuse an RSA key for some other RSA signature scheme. The strongly bound types allow the user to express that binding and cause applications to abort when the signature and key type don't agree -- even if the key material is technically compatible.

EcdsaSecp256k1Signature2019 would have a EcdsaSecp256k1VerificationKey2019 paired with it and SchnorrSecp256k1Signature2019 would have a SchnorrSecp256k1VerificationKey2019 paired with it.

We could also temporarily remove Schnorr and for now only get EcdsaSecp256k1Signature2019 and Secp256k1VerificationKey2018 added into the JSON-LD context?

We could, but I think the verification key would be better named EcdsaSecp256k1VerificationKey2019 if we want to follow the above principle and naming scheme. If the community doesn't agree or has already written software that this would break, I can accept that as the risk is probably quite small. But I did think there was a general consensus that we should bind these things moving forward as a matter of policy and general practice -- as opposed to considering what is mathematically possible. Allowing users to mix and match various schemes, algorithms, and keys because they "work" was something we wanted to avoid, but perhaps there are gradations where it's acceptable.

[ChristopherA]

EcdsaSecp256k1Signature2019 would have a EcdsaSecp256k1VerificationKey2019 paired with it and SchnorrSecp256k1Signature2019 would have a SchnorrSecp256k1VerificationKey2019 paired with it.

I believe this is the right answer.

— Christopher Allen

[peacekeeper]

EcdsaSecp256k1Signature2019 would have a EcdsaSecp256k1VerificationKey2019 paired with it and SchnorrSecp256k1Signature2019 would have a SchnorrSecp256k1VerificationKey2019 paired with it.

I believe this is the right answer.

— Christopher Allen

But in this case, which public key(s) would a btcr DID Document contain? EcdsaSecp256k1VerificationKey2019 or SchnorrSecp256k1VerificationKey2019 or both?

[ChristopherA]

Right now BTCR only supports EcdsaSecp256k1VerificationKey2019

— Christopher Allen

[kimdhamilton]

@dlongley do you object to @ChristopherA's suggestion? After catching up on this thread, I think that's the right call.

Someone pointed out an apparent contradiction in a statement you wrote here, but I note that it was over a year ago, and your reasoning in this thread seems to support @ChristopherA's suggestion

[dlongley]

@kimdhamilton,

@dlongley do you object to @ChristopherA's suggestion? After catching up on this thread, I think that's the right call.

Nope, what he quoted was from me, so we're on the same page. :)

[peacekeeper]

Updated PR to now add the following terms:

• EcdsaSecp256k1Signature2019
• EcdsaSecp256k1VerificationKey2019
• SchnorrSecp256k1Signature2019
• SchnorrSecp256k1VerificationKey2019