Re: Secp256k1 key types standardizations

I have submitted a pull request to reflect the corrected form.

On Fri, Mar 30, 2018 at 2:15 PM, Christopher Allen <
ChristopherA@lifewithalacrity.com> wrote:

> Just to make our lives a little more complicated, a EC public or private
> key’s signature can be either ECDSA (based on El Gamal) or Schnorr. Both
> keys are the same, the signatures are different. So if you are referring to
> a signature, not just a public key, you need to say which form.
>
> — Christopher Allen
>
>
> On Thu, Mar 29, 2018 at 10:20 PM, Kim Hamilton Duffy <
> kim@learningmachine.com> wrote:
>
>> I’ll open an issue on this.
>>
>> On Thu, Mar 29, 2018 at 9:25 AM Pelle Braendgaard <
>> pelle.braendgaard@consensys.net> wrote:
>>
>>> As long as we use the DER(?) format that most people are using we can
>>> handle both. It's encoded in the first byte.
>>>
>>> Pelle
>>>
>>>
>>> On Thu, Mar 29, 2018 at 9:07 AM, Christian Lundkvist <
>>> christian.lundkvist@consensys.net> wrote:
>>>
>>>>
>>>> I also agree that Secp256k1VerificationKey2018 sounds like the best fit
>>>> here.
>>>>
>>>> Another rabbit hole is the format of the key. We can have it in
>>>> compressed or uncompressed form, should this information be somewhere or
>>>> should it be inferred from the size of the key?
>>>>
>>>> Cheers,
>>>> Christian
>>>> On Thu, Mar 29, 2018 at 10:33 AM Mike Lodder <mike.lodder@evernym.com>
>>>> wrote:
>>>>
>>>>> +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> 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?
>>>>>>
>>>>>>    - Ed25519*VerificationKey2018*
>>>>>>    - Rsa*VerificationKey2018*
>>>>>>    - EdDsaSAPublicKeySecp256k1
>>>>>>
>>>>>> Either way, it's irritating to look at :)
>>>>>>
>>>>>> On Wed, Mar 28, 2018 at 11:59 AM Mike Lodder <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> 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> 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
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> *Pelle Brændgaard // uPort Engineering Lead*
>>>>>>>>> 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 | kimhd@mit.edu
>>>>>>>> 425-652-0150 <(425)%20652-0150> | LearningMachine.com
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Mike Lodder
>>>>>>> Senior Crypto Engineer
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>> 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 | kimhd@mit.edu
>>>>>> 425-652-0150 <(425)%20652-0150> | LearningMachine.com
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> *Pelle Brændgaard // uPort Engineering Lead*
>>>>> 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>
>>>>>
>>>>
>>>
>>>
>>> --
>>> *Pelle Brændgaard // uPort Engineering Lead*
>>> 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 | kimhd@mit.edu
>> 425-652-0150 <(425)%20652-0150> | LearningMachine.com
>>
>
>


-- 
Mike Lodder
Senior Crypto Engineer