Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Merged
merged 3 commits into from Jun 11, 2019

Conversation

@peacekeeper
Copy link
Member

commented Jun 3, 2019

sec:EcdsaSecp256k1Signature2019, sec:SchnorrSecp256k1Signature2019, sec:Secp256k1VerificationKey2018

@peacekeeper peacekeeper requested review from msporny and talltree as code owners Jun 3, 2019

Add secp256k to context (did-v0.11.jsonld).
sec:EcdsaSecp256k1Signature2019, sec:SchnorrSecp256k1Signature2019, sec:Secp256k1VerificationKey2018

@peacekeeper peacekeeper force-pushed the peacekeeper-context-secp256k1 branch from 66eba80 to e6db49f Jun 3, 2019

@peacekeeper

This comment has been minimized.

Copy link
Member Author

commented Jun 3, 2019

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

@@ -14,6 +14,9 @@
"Ed25519VerificationKey2018": "sec:Ed25519VerificationKey2018",
"RsaSignature2018": "sec:RsaSignature2018",
"RsaVerificationKey2018": "sec:RsaVerificationKey2018",
"EcdsaSecp256k1Signature2019": "sec:EcdsaSecp256k1Signature2019",

This comment has been minimized.

Copy link
@davidlehn

davidlehn Jun 3, 2019

Contributor

Move this line up to be in alpha order.

This comment has been minimized.

Copy link
@peacekeeper

peacekeeper Jun 4, 2019

Author Member

Done

@dlongley

This comment has been minimized.

Copy link
Contributor

commented Jun 4, 2019

@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

This comment has been minimized.

Copy link
Member Author

commented Jun 4, 2019

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

@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.

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

This comment has been minimized.

Copy link
Contributor

commented Jun 4, 2019

@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

This comment has been minimized.

Copy link
Contributor

commented Jun 4, 2019

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

This comment has been minimized.

Copy link
Member Author

commented Jun 5, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Jun 5, 2019

Right now BTCR only supports EcdsaSecp256k1VerificationKey2019

— Christopher Allen

@kimdhamilton

This comment has been minimized.

Copy link
Contributor

commented Jun 7, 2019

@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

This comment has been minimized.

Copy link
Contributor

commented Jun 7, 2019

@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

This comment has been minimized.

Copy link
Member Author

commented Jun 8, 2019

Updated PR to now add the following terms:

  • EcdsaSecp256k1Signature2019
  • EcdsaSecp256k1VerificationKey2019
  • SchnorrSecp256k1Signature2019
  • SchnorrSecp256k1VerificationKey2019

@peacekeeper peacekeeper merged commit a17d86b into gh-pages Jun 11, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.