Re: Secp256k1 key types standardizations

+1

________________________________
From: Pelle Braendgaard <pelle.braendgaard@consensys.net>
Sent: Thursday, March 29, 2018 7:52:31 AM
To: Kim Hamilton Duffy
Cc: Mike Lodder; Credentials Community Group
Subject: Re: Secp256k1 key types standardizations

I agree Kim,

So I think standardizing on "Secp256k1VerificationKey2018" would be the most consistent.

Pelle

On Wed, Mar 28, 2018 at 9:58 PM, Kim Hamilton Duffy <kim@learningmachine.com<mailto:kim@learningmachine.com>> wrote:
The other problem is the naming inconsistency. From the other 2 key ids in the registry, (below) and from DID hardening discussions around key "purpose". I'd expected the ids to follow a pattern, e.g. <curve-specific><purpose>Key<date>.

To clarify, I thought we decided that an entry in this registry would map to a specific combination of JWK parameters to help avoid the problem of algorithmic agility. (However, I did miss many of the later DID hardening calls.)

Given that the registry is brand new, I'd think we could impose this consistency before things get out of control. Or is that not possible or necessary in this case?

  *   Ed25519VerificationKey2018
  *   RsaVerificationKey2018
  *   EdDsaSAPublicKeySecp256k1

Either way, it's irritating to look at :)

On Wed, Mar 28, 2018 at 11:59 AM Mike Lodder <mike.lodder@evernym.com<mailto:mike.lodder@evernym.com>> wrote:
EdDsaSAPublicKeySecp256k1 is incorrect. EdDsa is only possible with Twisted Edward curves. This should be ECDSAPublicKeySecp256k1.

On Wed, Mar 28, 2018 at 12:48 PM, Kim Hamilton Duffy <kim@learningmachine.com<mailto:kim@learningmachine.com>> wrote:
We may have a naming issue in the current LD Cryptosuite Registry; note that we have a secp256k1key, but its identifier (EdDsaSAPublicKeySecp256k1) isn't consistent with the others in terms of specifying purpose.

For context, here's the list of key identifiers currently in the registry (https://w3c-ccg.github.io/ld-cryptosuite-registry/):

  *   Ed25519VerificationKey2018
  *   RsaVerificationKey2018
  *   EdDsaSAPublicKeySecp256k1 <<<

Example for EdDsaSAPublicKeySecp256k1 in the registry:

{
  "id": "did:example:123456789abcdefghi#keys-1",
  "type": "EdDsaSAPublicKeySecp256k1",
  "owner": "did:example:123456789abcdefghi",
  "publicKeyHex": "02b97c30de767f084ce3080168ee293053ba33b235d7116a3263d29f1450936b71"
}

The DID spec uses the type name you mentioned (Secp256k1VerificationKey2018) in the same context of a publicKey

 {
    "id": "did:example:123456789abcdefghi#keys-3",
    "type": "Secp256k1VerificationKey2018",
    "owner": "did:example:123456789abcdefghi",
    "publicKeyHex": "02b97c30de767f084ce3080168ee293053ba33b235d7116a3263d29f1450936b71"
  }]

Should we rename the identifier in the registry? Or does this have some purpose I'm missing

On Wed, Mar 28, 2018 at 10:46 AM Pelle Braendgaard <pelle.braendgaard@consensys.net<mailto:pelle.braendgaard@consensys.net>> wrote:
Hello guys,
I've lost count of all the variations of the secp256k1 key types I've seen. The latest in the DID spec is:

"Secp256k1VerificationKey2018"

Can we stick with that for now. I know we need to register it here https://w3c-ccg.github.io/ld-cryptosuite-registry/ but not quite sure of the process for that.

For authentication I would like to use the following type copying from the conventions for RSA:

"Secp256k1SignatureAuthentication2018"

Regards

Pelle

--
[https://docs.google.com/uc?export=download&id=0B7K0aMi-H09pbHpvZS1KOE9uUkk&revid=0B7K0aMi-H09pQjFqcENrRndSYlQ0OG16ZU9sSzlhMVpoZktVPQ]
Pelle Brændgaard // uPort Engineering Lead
pelle.braendgaard@consensys.net<mailto:pelle.braendgaard@consensys.net>
49 Bogart St, Suite 22, Brooklyn NY 11206<https://maps.google.com/?q=49+Bogart+St,+Suite+22,+Brooklyn+NY+11206&entry=gmail&source=g>
Web<https://consensys.net/> | Twitter<https://twitter.com/ConsenSys> | Facebook<https://www.facebook.com/consensussystems> | Linkedin<https://www.linkedin.com/company/consensus-systems-consensys-> | Newsletter<http://consensys.us11.list-manage.com/subscribe?u=947c9b18fc27e0b00fc2ad055&id=257df01285&utm_content=buffer1ce12&utm_medium=social&utm_source=facebook.com&utm_campaign=buffer>
--
Kim Hamilton Duffy
CTO & Principal Architect Learning Machine
Co-chair W3C Credentials Community Group
400 Main Street Building E19-732, Cambridge, MA 02139<https://maps.google.com/?q=732,+Cambridge,+MA+02139&entry=gmail&source=g>

kim@learningmachine.com<mailto:kim@learningmachine.com> | kimhd@mit.edu<mailto:kimhd@mit.edu>
425-652-0150<tel:(425)%20652-0150> | LearningMachine.com



--
Mike Lodder
Senior Crypto Engineer

[https://docs.google.com/uc?export=download&id=0B3PJABxCiUqscERvejdVYXRPVm8&revid=0B3PJABxCiUqsYzM1YUNtc0syT0dQWUpHSW15RXRNNTZkSkVZPQ]
--
Kim Hamilton Duffy
CTO & Principal Architect Learning Machine
Co-chair W3C Credentials Community Group
400 Main Street Building E19-732, Cambridge, MA 02139

kim@learningmachine.com<mailto:kim@learningmachine.com> | kimhd@mit.edu<mailto:kimhd@mit.edu>
425-652-0150<tel:(425)%20652-0150> | LearningMachine.com



--
[https://docs.google.com/uc?export=download&id=0B7K0aMi-H09pbHpvZS1KOE9uUkk&revid=0B7K0aMi-H09pQjFqcENrRndSYlQ0OG16ZU9sSzlhMVpoZktVPQ]
Pelle Brændgaard // uPort Engineering Lead
pelle.braendgaard@consensys.net<mailto:pelle.braendgaard@consensys.net>
49 Bogart St, Suite 22, Brooklyn NY 11206
Web<https://consensys.net/> | Twitter<https://twitter.com/ConsenSys> | Facebook<https://www.facebook.com/consensussystems> | Linkedin<https://www.linkedin.com/company/consensus-systems-consensys-> | Newsletter<http://consensys.us11.list-manage.com/subscribe?u=947c9b18fc27e0b00fc2ad055&id=257df01285&utm_content=buffer1ce12&utm_medium=social&utm_source=facebook.com&utm_campaign=buffer>